Hubbry Logo
OpenIDOpenIDMain
Open search
OpenID
Community hub
OpenID
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
OpenID
OpenID
OpenID
View on Wikipedia
from Wikipedia

Logo

OpenID is an open standard and decentralized authentication protocol promoted by the non-profit OpenID Foundation. It allows users to be authenticated by co-operating sites (known as relying parties, or RP) using a third-party identity provider (IDP) service, eliminating the need for webmasters to provide their own ad hoc login systems, and allowing users to log in to multiple unrelated websites without having to have a separate identity and password for each.[1] Users create accounts by selecting an OpenID identity provider,[1] and then use those accounts to sign on to any website that accepts OpenID authentication. Several large organizations either issue or accept OpenIDs on their websites.[2]

The OpenID standard provides a framework for the communication that must take place between the identity provider and the OpenID acceptor (the "relying party").[3] An extension to the standard (the OpenID Attribute Exchange) facilitates the transfer of user attributes, such as name and gender, from the OpenID identity provider to the relying party (each relying party may request a different set of attributes, depending on its requirements).[4] The OpenID protocol does not rely on a central authority to authenticate a user's identity. Moreover, neither services nor the OpenID standard may mandate a specific means by which to authenticate users, allowing for approaches ranging from the common (such as passwords) to the novel (such as smart cards or biometrics).

The final version of OpenID is OpenID 2.0, finalized and published in December 2007.[5] The term OpenID may also refer to an identifier as specified in the OpenID standard; these identifiers take the form of a unique Uniform Resource Identifier (URI), and are managed by some "OpenID provider" that handles authentication.[1]

Adoption

[edit]

As of March 2016, there are over 1 billion OpenID-enabled accounts on the Internet (see below) and approximately 1,100,934 sites have integrated OpenID consumer support:[6] AOL, Flickr, Google, Amazon.com, Canonical (provider name Ubuntu One), LiveJournal, Microsoft (provider name Microsoft account), Mixi, Myspace, Novell, OpenStreetMap, Orange, Sears, Sun, Telecom Italia, Universal Music Group, VeriSign, WordPress, Yahoo!, the BBC,[7] IBM,[8] PayPal,[9] and Steam,[10] although some of those organizations also have their own authentication management.

Many if not all of the larger organizations require users to provide authentication in the form of an existing email account or mobile phone number in order to sign up for an account (which then can be used as an OpenID identity). There are several smaller entities that accept sign-ups with no extra identity details required.

Facebook did use OpenID in the past, but moved to Facebook Connect.[11] Blogger also used OpenID, but since May 2018 no longer supports it.[12]

Technical overview

[edit]

OpenID is a decentralized authentication protocol that allows users to authenticate with multiple websites using a single set of credentials, eliminating the need for separate usernames and passwords for each website. OpenID authenticates a user with an identity provider (IDP), who then provides the user with a unique identifier (called an OpenID). This identifier can then be used to authenticate the user with any website that supports OpenID.

When a user visits a website that supports OpenID authentication, the website will redirect the user to their chosen IDP. The IDP will then prompt the user to authenticate themselves (e.g., by entering a username and password). Once the user is authenticated, the IDP will generate an OpenID and send it back to the website. The website can then use this OpenID to authenticate the user without needing to know their actual credentials.

OpenID is built on top of several existing standards, including HTTP, HTML, and XML. OpenID relies on a number of technologies, including a discovery mechanism that allows websites to find the IDP associated with a particular OpenID, as well as security mechanisms to protect against phishing and other attacks.[13]

One of the key benefits of OpenID is that it allows users to control their own identity information, rather than relying on individual websites to store and manage their login credentials. This can be particularly important in cases where websites are vulnerable to security breaches or where users are concerned about the privacy of their personal information.

OpenID has been widely adopted by a number of large websites and service providers, including Google, Yahoo!, and PayPal. The protocol is also used by a number of open source projects and frameworks, including Ruby on Rails and Django.

Logging in

[edit]

The end user interacts with a relying party (such as a website) that provides an option to specify an OpenID for the purposes of authentication; an end user typically has previously registered an OpenID (e.g. alice.openid.example.org) with an OpenID provider (e.g. openid.example.org).[1]

The relying party typically transforms the OpenID into a canonical URL form (e.g. http://alice.openid.example.org/).

  • With OpenID 1.0, the relying party then requests the HTML resource identified by the URL and reads an HTML link tag to discover the OpenID provider's URL (e.g. http://openid.example.org/openid-auth.php). The relying party also discovers whether to use a delegated identity (see below).
  • With OpenID 2.0, the relying party discovers the OpenID provider URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml; this document may be available at the target URL and is always available for a target XRI.

There are two modes in which the relying party may communicate with the OpenID provider:

  • checkid_immediate, in which the relying party requests that the OpenID provider not interact with the end user. All communication is relayed through the end user's user-agent without explicitly notifying the end user.
  • checkid_setup, in which the end user communicates with the OpenID provider via the same user-agent used to access the relying party.

The checkid_immediate mode can fall back to the checkid_setup mode if the operation cannot be automated.

First, the relying party and the OpenID provider (optionally) establish a shared secret, referenced by an associate handle, which the relying party then stores. If using the checkid_setup mode, the relying party redirects the end user's user-agent to the OpenID provider so the end user can authenticate directly with the OpenID provider.

The method of authentication may vary, but typically, an OpenID provider prompts the end user for a password or some cryptographic token, and then asks whether the end user trusts the relying party to receive the necessary identity details.

If the end user declines the OpenID provider's request to trust the relying party, then the user-agent is redirected back to the relying party with a message indicating that authentication was rejected; the relying party in turn refuses to authenticate the end user.

If the end user accepts the OpenID provider's request to trust the relying party, then the user-agent is redirected back to the relying party along with the end user's credentials. That relying party must then confirm that the credentials really came from the OpenID provider. If the relying party and OpenID provider had previously established a shared secret, then the relying party can validate the identity of the OpenID provider by comparing its copy of the shared secret against the one received along with the end user's credentials; such a relying party is called stateful because it stores the shared secret between sessions. In contrast, a stateless or dumb relying party must make one more background request (check_authentication) to ensure that the data indeed came from the OpenID provider.

After the OpenID has been verified, authentication is considered successful and the end user is considered logged into the relying party under the identity specified by the given OpenID (e.g. alice.openid.example.org). The relying party typically then stores the end user's OpenID along with the end user's other session information.

Identifiers

[edit]

To obtain an OpenID-enabled URL that can be used to log into OpenID-enabled websites, a user registers an OpenID identifier with an identity provider. Identity providers offer the ability to register a URL (typically a third-level domain, e.g. username.example.com) that will automatically be configured with OpenID authentication service.

Once they have registered an OpenID, a user can also use an existing URL under their own control (such as a blog or home page) as an alias or "delegated identity". They simply insert the appropriate OpenID tags in the HTML[14] or serve a Yadis document.[15]

Starting with OpenID Authentication 2.0 (and some 1.1 implementations), there are two types of identifiers that can be used with OpenID: URLs and XRIs.

XRIs are a new form of Internet identifier designed specifically for cross-domain digital identity. For example, XRIs come in two forms—i-names and i-numbers—that are usually registered simultaneously as synonyms. I-names are reassignable (like domain names), while i-numbers are never reassigned. When an XRI i-name is used as an OpenID identifier, it is immediately resolved to the synonymous i-number (the CanonicalID element of the XRDS document). This i-number is the OpenID identifier stored by the relying party. In this way, both the user and the relying party are protected from the end user's OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.

OpenID Foundation

[edit]

The OpenID Foundation (OIDF) promotes and enhances the OpenID community and technologies. The OIDF is a non-profit international standards development organization of individual developers, government agencies and companies who wish to promote and protect OpenID. The OpenID Foundation was formed in June 2007 and serves as a public trust organization representing an open community of developers, vendors and users. OIDF assists the community by providing needed infrastructure and help in promoting and supporting adoption of OpenID. This includes managing intellectual property and trade marks as well a fostering viral growth and global participation in OpenID.

People

[edit]

The OpenID Foundation's board of directors has six community board members and eight corporate board members:[16]

Chapters

[edit]

OIDF is a global organization to promote digital identity and to encourage the further adoption of OpenID, the OIDF has encouraged the creation of member chapters. Member chapters are officially part of the Foundation and work within their own constituency to support the development and adoption of OpenID as a framework for user-centric identity on the internet.

Intellectual property and contribution agreements

[edit]

The OIDF ensures that OpenID specifications are freely implementable therefore the OIDF requires all contributors to sign a contribution agreement. This agreement both grants a copyright license to the Foundation to publish the collective specifications and includes a patent non-assertion agreement. The non-assertion agreement states that the contributor will not sue someone for implementing OpenID specifications.

[edit]

The OpenID trademark in the United States was assigned to the OpenID Foundation in March 2008.[17] It had been registered by NetMesh Inc. before the OpenID Foundation was operational.[18][19] In Europe, as of August 31, 2007, the OpenID trademark is registered to the OpenID Europe Foundation.[20]

The OpenID logo was designed by Randy "ydnar" Reddig, who in 2005 had expressed plans to transfer the rights to an OpenID organization.[21]

Since the original announcement of OpenID, the official site has stated:[22]

Nobody should own this. Nobody's planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there's no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we're all a part of the community.

Sun Microsystems, VeriSign and a number of smaller companies involved in OpenID have issued patent non-assertion covenants covering OpenID 1.1 specifications. The covenants state that the companies will not assert any of their patents against OpenID implementations and will revoke their promises from anyone who threatens, or asserts, patents against OpenID implementors.[23][24]

Security

[edit]

Authentication bugs

[edit]

In March, 2012, a research paper[25] reported two generic security issues in OpenID. Both issues allow an attacker to sign in to a victim's relying party accounts. For the first issue, OpenID and Google (an Identity Provider of OpenID) both published security advisories to address it.[26][27] Google's advisory says "An attacker could forge an OpenID request that doesn't ask for the user's email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn't notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account." The research paper claims that many popular websites have been confirmed vulnerable, including Yahoo! Mail, smartsheet.com, Zoho, manymoon.com, diigo.com. The researchers have notified the affected parties, who have then fixed their vulnerable code.

For the second issue, the paper called it "Data Type Confusion Logic Flaw", which also allows attackers to sign in to victims' RP accounts. Google and PayPal were initially confirmed vulnerable. OpenID published a vulnerability report[28] on the flaw. The report says Google and PayPal have applied fixes, and suggest other OpenID vendors to check their implementations.

Phishing

[edit]

Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks.[29][30][31] For example, a malicious relaying party may forward the end user to a bogus identity provider authentication page asking that end user to input their credentials. On completion of this, the malicious party (who in this case also controls the bogus authentication page) could then have access to the end user's account with the identity provider, and then use that end user's OpenID to log into other services.

In an attempt to combat possible phishing attacks, some OpenID providers mandate that the end user needs to be authenticated with them prior to an attempt to authenticate with the relying party.[32] This relies on the end user knowing the policy of the identity provider. In December 2008, the OpenID Foundation approved version 1.0 of the Provider Authentication Policy Extension (PAPE), which "enables Relying Parties to request that OpenID Providers employ specified authentication policies when authenticating users and for OpenID Providers to inform the Relying Parties which policies were actually used."[33]

Privacy and trust issues

[edit]

Other security issues identified with OpenID involve lack of privacy and failure to address the trust problem.[34] However, this problem is not unique to OpenID and is simply the state of the Internet as commonly used.[citation needed]

The Identity Provider does, however, get a log of your OpenID logins; they know when you logged into what website, making cross-site tracking much easier. A compromised OpenID account is also likely to be a more serious breach of privacy than a compromised account on a single site.

Authentication hijacking in unsecured connection

[edit]

Another important vulnerability is present in the last step in the authentication scheme when TLS/SSL are not used: the redirect-URL from the identity provider to the relying party. The problem with this redirect is the fact that anyone who can obtain this URL (e.g. by sniffing the wire) can replay it and get logged into the site as the victim user. Some of the identity providers use nonces (a number used just once) to allow a user to log into the site once and fail all the consecutive attempts. The nonce solution works if the user is the first one to use the URL. However, a fast attacker who is sniffing the wire can obtain the URL and immediately reset a user's TCP connection (as an attacker is sniffing the wire and knows the required TCP sequence numbers) and then execute the replay attack as described above. Thus nonces only protect against passive attackers, but cannot prevent active attackers from executing the replay attack.[35] Use of TLS/SSL in the authentication process can significantly reduce this risk.

This can be restated as: 

  IF (Both RP1 and RP2 have Bob as a client) AND       // a common case
     (Bob uses the same IDP with both RP1 and RP2) AND // a common case
     (RP1 does not use VPN/SSL/TLS to secure their connection with the client) // preventable!
  THEN
    RP2 could obtain credentials sufficient to impersonate Bob with RP1
  END-IF

Covert Redirect

[edit]

On May 1, 2014, a bug dubbed "Covert Redirect related to OAuth 2.0 and OpenID" was disclosed.[36][37] It was discovered by mathematics doctoral student Wang Jing at the School of Physical and Mathematical Sciences, Nanyang Technological University, Singapore.[38][39][40]

The announcement of OpenID is: "'Covert Redirect', publicized in May 2014, is an instance of attackers using open redirectors – a well-known threat, with well-known means of prevention. The OpenID Connect protocol mandates strict measures that preclude open redirectors to prevent this vulnerability."[41]

"The general consensus, so far, is that Covert Redirect is not as bad, but still a threat. Understanding what makes it dangerous requires a basic understanding of Open Redirect, and how it can be exploited."[42]

A patch was not immediately made available. Ori Eisen, founder, chairman and chief innovation officer at 41st Parameter told Sue Marquette Poremba, "In any distributed system, we are counting of the good nature of the participants to do the right thing. In cases like OAuth and OpenID, the distribution is so vast that it is unreasonable to expect each and every website to patch up in the near future".[43]

History

[edit]

The original OpenID authentication protocol was developed in May 2005[44] by Brad Fitzpatrick, creator of popular community website LiveJournal, while working at Six Apart.[45] Initially referred to as Yadis (an acronym for "Yet another distributed identity system"),[46] it was named OpenID after the openid.net domain name was given to Six Apart to use for the project.[47] OpenID support was soon implemented on LiveJournal and fellow LiveJournal engine community DeadJournal for blog post comments and quickly gained attention in the digital identity community.[48][49] Web developer JanRain was an early supporter of OpenID, providing OpenID software libraries and expanding its business around OpenID-based services.

In late June, discussions started between OpenID users and developers from enterprise software company NetMesh, leading to collaboration on interoperability between OpenID and NetMesh's similar Light-weight Identity (LID) protocol. The direct result of the collaboration was the Yadis discovery protocol, adopting the name originally used for OpenID. The new Yadis was announced on October 24, 2005.[50] After a discussion at the 2005 Internet Identity Workshop a few days later, XRI/i-names developers joined the Yadis project,[51] contributing their Extensible Resource Descriptor Sequence (XRDS) format for utilization in the protocol.[52]

In December, developers at Sxip Identity began discussions with the OpenID/Yadis community[53] after announcing a shift in the development of version 2.0 of its Simple Extensible Identity Protocol (SXIP) to URL-based identities like LID and OpenID.[54] In March 2006, JanRain developed a Simple Registration (SREG) extension for OpenID enabling primitive profile-exchange[55] and in April submitted a proposal to formalize extensions to OpenID. The same month, work had also begun on incorporating full XRI support into OpenID.[56] Around early May, key OpenID developer David Recordon left Six Apart, joining VeriSign to focus more on digital identity and guidance for the OpenID spec.[49][57] By early June, the major differences between the SXIP 2.0 and OpenID projects were resolved with the agreement to support multiple personas in OpenID by submission of an identity provider URL rather than a full identity URL. With this, as well as the addition of extensions and XRI support underway, OpenID was evolving into a full-fledged digital identity framework, with Recordon proclaiming "We see OpenID as being an umbrella for the framework that encompasses the layers for identifiers, discovery, authentication and a messaging services layer that sits atop and this entire thing has sort of been dubbed 'OpenID 2.0'.[58] " In late July, Sxip began to merge its Digital Identity Exchange (DIX) protocol into OpenID, submitting initial drafts of the OpenID Attribute Exchange (AX) extension in August. Late in 2006, a ZDNet opinion piece made the case for OpenID to users, web site operators and entrepreneurs.[59]

On January 31, 2007, Symantec announced support for OpenID in its Identity Initiative products and services.[60] A week later, on February 6 Microsoft made a joint announcement with JanRain, Sxip, and VeriSign to collaborate on interoperability between OpenID and Microsoft's Windows CardSpace digital identity platform, with particular focus on developing a phishing-resistant authentication solution for OpenID. As part of the collaboration, Microsoft pledged to support OpenID in its future identity server products and JanRain, Sxip, and VeriSign pledged to add support for Microsoft's Information Card profile to their future identity solutions.[61] In mid-February, AOL announced that an experimental OpenID provider service was functional for all AOL and AOL Instant Messenger (AIM) accounts.[62]

In May, Sun Microsystems began working with the OpenID community, announcing an OpenID program,[63] as well as entering a non-assertion covenant with the OpenID community, pledging not to assert any of its patents against implementations of OpenID.[23] In June, OpenID leadership formed the OpenID Foundation, an Oregon-based public benefit corporation for managing the OpenID brand and property.[64] The same month, an independent OpenID Europe Foundation was formed in Belgium[65] by Snorri Giorgetti. By early December, non-assertion agreements were collected by the major contributors to the protocol and the final OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0 specifications were ratified on December 5.[66]

In mid-January 2008, Yahoo! announced initial OpenID 2.0 support, both as a provider and as a relying party, releasing the provider service by the end of the month.[67] In early February, Google, IBM, Microsoft, VeriSign and Yahoo! joined the OpenID Foundation as corporate board members.[68] Around early May, SourceForge, Inc. introduced OpenID provider and relying party support to leading open source software development website SourceForge.net.[69] In late July, popular social network service MySpace announced support for OpenID as a provider.[70] In late October, Google launched support as an OpenID provider and Microsoft announced that Windows Live ID would support OpenID.[71] In November, JanRain announced a free hosted service, RPX Basic, that allows websites to begin accepting OpenIDs for registration and login without having to install, integrate and configure the OpenID open source libraries.[72]

In January 2009, PayPal joined the OpenID Foundation as a corporate member, followed shortly by Facebook in February. The OpenID Foundation formed an executive committee and appointed Don Thibeau as executive director. In March, MySpace launched their previously announced OpenID provider service, enabling all MySpace users to use their MySpace URL as an OpenID. In May, Facebook launched their relying party functionality,[73][74] letting users use an automatic login-enabled OpenID account (e.g. Google) to log into Facebook.[75]

In September 2013, Janrain announced that MyOpenID.com would be shut down on February 1, 2014; a pie chart showed Facebook and Google dominate the social login space as of Q2 2013.[76] Facebook has since left OpenID; it is no longer a sponsor, represented on the board, or permitting OpenID logins.[16][77]

In May 2016, Symantec announced that they would be discontinuing their pip.verisignlabs.com OpenID personal identity portal service.[78][79]

In March 2018, Stack Overflow announced an end to OpenID support, citing insufficient usage to justify the cost. In the announcement, it was stated that based on activity, users strongly preferred Facebook, Google, and e-mail/password based account authentication.[80]

OpenID versus pseudo-authentication using OAuth

[edit]

OpenID is a way to use a single set of user credentials to access multiple sites, while OAuth facilitates the authorization of one site to access and use information related to the user's account on another site. Although OAuth is not an authentication protocol, it can be used as part of one.

Authentication in the context of a user accessing an application tells an application who the current user is and whether or not they're present. [...] Authentication is all about the user and their presence with the application, and an internet-scale authentication protocol needs to be able to do this across network and security boundaries.

However, OAuth tells the application none of that. OAuth says absolutely nothing about the user, nor does it say how the user proved their presence or even if they're still there. As far as an OAuth client is concerned, it asked for a token, got a token, and eventually used that token to access some API. It doesn't know anything about who authorized the application or if there was even a user there at all. In fact, much of the point of OAuth is about giving this delegated access for use in situations where the user is not present on the connection between the client and the resource being accessed. This is great for client authorization, but it's really bad for authentication where the whole point is figuring out if the user is there or not (and who they are).[81]

The following drawing highlights the differences between using OpenID versus OAuth for authentication. Note that with OpenID, the process starts with the application asking the user for their identity (typically an OpenID URI), whereas in the case of OAuth, the application directly requests a limited access OAuth Token (valet key) to access the APIs (enter the house) on user's behalf. If the user can grant that access, the application can retrieve the unique identifier for establishing the profile (identity) using the APIs.

OpenID vs. Pseudo-Authentication using OAuth

Attack against pseudo-authentication

[edit]

OpenID provides a cryptographic verification mechanism that prevents the attack below against users who misuse OAuth for authentication.

Note that the valet key does not describe the user in any way, it only provides limited access rights, to some house (which is not even necessarily the user's, they just had a key). Therefore if the key becomes compromised (the user is malicious and managed to steal the key to someone else's house), then the user can impersonate the house owner to the application who requested their authenticity. If the key is compromised by any point in the chain of trust, a malicious user may intercept it and use it to impersonate user X for any application relying on OAuth2 for pseudo authentication against the same OAuth authorization server. Conversely, the notarized letter contains the user's signature, which can be checked by the requesting application against the user, so this attack is not viable. [82]

Verifying the letter

[edit]

The letter can use public-key cryptography to be authenticated.

  • The requesting application provides its encryption public key to the user, which provides it to the authentication server.
  • The authentication server encrypts a document containing an encryption key which corresponds to a one-way hash of a secret the user knows (e.g. passphrase) for challenge–response using the application's public key.
  • The user passes the encrypted document back to the application, which decrypts it.
  • The application encrypts a random phrase using the received encryption key, and asks that the user do the same, then compares the results, if they match, the user is authentic.

OpenID Connect (OIDC)

[edit]

Published in February 2014[83] by the OpenID Foundation, OpenID Connect (OIDC) is the third generation of OpenID technology. It is an authentication layer on top of the OAuth 2.0 authorization framework.[84] It allows computing clients to verify the identity of an end user based on the authentication performed by an authorization server, as well as to obtain the basic profile information about the end user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format.

OpenID Connect allows a range of parties, including web-based, mobile and JavaScript clients, to request and receive information about authenticated sessions and end users. The OpenID Connect specification is extensible, supporting optional features such as encryption of identity data, discovery of OpenID providers, and session management.

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

OpenID

View on Grokipedia
from Grokipedia
OpenID is a family of open standards for decentralized and , allowing users to log in to multiple websites and applications using a single set of credentials managed by an identity provider, such as , Apple, or , without the need to share passwords or create new accounts at each . OpenID originated in 2005 with version 1.0, initiated by Brad Fitzpatrick, and OpenID Authentication 2.0 was finalized in December 2007 by the OpenID Foundation, a non-profit established in June 2007 to promote interoperable identity protocols; it aimed to enable users to prove control over a across the web without relying on centralized authorities. The protocol evolved significantly with the introduction of OpenID Connect 1.0 in February 2014, which builds upon the OAuth 2.0 framework to provide a simple identity layer for verifying end-user identities and obtaining basic profile information in a RESTful manner, supporting web, mobile, and clients. Key features of OpenID include user consent for , privacy-preserving configurations, and extensibility through specifications like discovery and , ensuring secure and interoperable without storing user secrets at relying parties. OpenID Connect specifications have been published as ISO/IEC standards in 2024 and is widely adopted, powering sign-ins for billions of users across millions of applications globally, with programs promoting conformance and ecosystem growth.

Overview

Definition and Purpose

OpenID is an open standard for decentralized digital identity authentication that enables users to sign in to multiple independent websites using a single, user-controlled identifier, without the need to share passwords or other credentials with relying parties. This protocol allows end users to prove ownership or control of a unique identifier, such as a URL—through interactions with an OpenID provider, fostering a user-centric approach to identity management across the web. The primary purpose of OpenID is to facilitate decentralized (SSO), permitting users to authenticate once with their chosen and then access various services without repeated logins, thereby reducing and streamlining the overall . Key benefits include enhanced user control over personal identity data, the absence of a mandatory central to manage identities, and broad between diverse online services and providers, which promotes portability and flexibility in digital interactions. OpenID was developed in the early , with its initial release in , to address the escalating challenge of users managing an ever-increasing number of distinct usernames and passwords for different websites amid the rapid growth of the and web-based applications. This motivation stemmed from the recognition that traditional site-specific created significant barriers and risks due to credential reuse and weak password practices. Over time, OpenID has evolved, with OpenID Connect emerging as its successor and current standard to incorporate modern enhancements like integration with OAuth 2.0 for broader applicability in web, mobile, and API contexts; the original OpenID Authentication 2.0 is now considered legacy.

Core Components

OpenID's architecture revolves around three primary roles that facilitate decentralized authentication. The OpenID Provider (OP) serves as the identity issuer, operating as a server that authenticates users and issues assertions about their identity, typically accessible via an OP Endpoint URL using HTTP or protocols. The (RP) functions as the service or web application that relies on the OP for authentication, seeking verifiable proof that the end user controls a specific identifier without managing identities itself. At the center is the End User, the individual who owns and controls the identifier, choosing their preferred OP to manage their across services. Supporting these roles are key elements that enable interaction in a web-based environment. The User-Agent, commonly the end user's , acts as the intermediary, facilitating communication between the RP, OP, and end user through standard HTTP/1.1-compliant requests and responses. Discovery mechanisms provide a high-level means for RPs to locate an end user's OP without prior configuration. The protocol is layered on established web standards to ensure and extensibility. It builds upon HTTP and URI conventions for all communications, using standardized formats for requests and responses, with support for extensions. Unlike centralized identity systems, OpenID adopts a decentralized model that empowers end users to select any compatible OP, eliminating the need for a single authority and allowing identifiers to remain portable across providers. This user-centric approach originated from early specifications aimed at enabling portable without . For details on modern implementations, see the OpenID Connect section.

Technical Specifications

Discovery and Identifiers

In OpenID Authentication 2.0, serve as the starting point for the authentication process, allowing end users to claim control over a unique resource without sharing credentials directly. These primarily consist of HTTP or URLs, such as http://example.com/, which represent user-controlled web resources, or XRIs (Extensible Resource Identifiers), which provide a structured syntax for persistent global identifiers like i-names or i-numbers. XRIs, defined by the XRI Technical Committee at OASIS, enable abstraction over various identity schemes but require resolution to a for use in OpenID. Additionally, are categorized as claimed identifiers, which are user-owned and verified through the protocol (e.g., a personal URL like http://myblog.com/), or OP-local identifiers, which are specific to an OpenID Provider (OP) and may not be directly controlled by the user (e.g., https://user123.op.example.com/). The discovery process in OpenID 2.0 enables a relying party (RP) to locate the OP endpoint and related services associated with a provided identifier, using a series of HTTP fetches and document parsing. For URL identifiers, the process begins with normalization: the input is stripped of fragments (e.g., #section is removed), prefixed with http:// if no scheme is present, and treated as an absolute URI per RFC 3986 rules; relative references or those starting with www. are resolved accordingly to avoid duplicates. The RP then performs HTML-based discovery by fetching the normalized URL and scanning the HTML <head> for <link> elements, such as <link rel="openid2.provider" href="https://op.example.com/openid" rel="nofollow"> to identify the OP endpoint or <link rel="openid2.local_id" href="https://user.op.example.com" rel="nofollow"> for an OP-local alias. If Yadis discovery (via HTTP headers like X-Yadis-Location) succeeds, an XRDS document is retrieved, containing <XRD> elements with <Service> tags that specify types like http://specs.openid.net/auth/2.0/server for the OP endpoint URI. For XRI identifiers, discovery routes through XRI resolution services to obtain an XRDS document, including a <CanonicalID> element for persistence. This entire process relies on HTTP redirection (e.g., 302 or 303 status codes) to follow chains and resolve the final endpoint, ensuring the RP obtains verifiable service details without prior knowledge of the OP. Claimed identifiers differ from delegated setups in that the former directly assert user ownership, with the RP verifying control by completing the full flow against the claimed 's discovered OP. In delegation, users maintain a personal claimed identifier (e.g., their website ) while offloading to a trusted OP via an OP-local identifier, configured during discovery through XRDS <LocalID> elements or <link rel="openid2.local_id"> tags; this allows portability without altering the user's primary identity. For instance, a user might delegate http://[example.com](/page/Example.com)/ to an OP at https://myop.com/, where the RP treats the claimed as authoritative but authenticates via the delegated endpoint. XRI support in OpenID 2.0 facilitated such delegations with persistent canonical forms, though it was not incorporated into later standards like OpenID Connect 1.0, effectively deprecating its use in modern implementations.

Authentication Flow

The OpenID authentication flow enables a (RP) to verify that an controls a specific identifier without requiring the RP to store credentials or access the user's details directly. This process relies on a series of HTTP redirects and signed messages exchanged between the user's browser (), the RP, and the OpenID provider (OP). The flow begins when the user supplies an identifier—such as a URL or XRI—to the RP, typically through a login form. In the basic authentication flow, the RP first normalizes the user-supplied identifier (for example, by prepending "http://" if absent) and performs discovery to locate the OP's endpoint and the claimed identifier. The RP then optionally establishes an association with the OP using Diffie-Hellman key exchange over a direct connection to create a for message signing, enhancing security without relying on long-term keys. Next, the RP redirects the user's browser to the OP's authentication endpoint with an indirect request message containing parameters like the mode ("checkid_setup" or "checkid_immediate"), the claimed identifier, a return-to for the RP, and a nonce to prevent replay attacks. At the OP, the user authenticates—using methods like passwords or , though the specifics are implementation-dependent—and grants permission for the RP to receive the identity assertion. The OP then redirects the browser back to the RP's return-to with a response message. The response includes either a positive assertion, confirming the user's control of the claimed identifier, or a negative assertion indicating failure (e.g., due to cancellation). Positive assertions are digitally signed using HMAC-SHA1 or HMAC-SHA256 with the shared secret from the association, containing fields such as the signed parameters, the claimed identifier, the OP endpoint, and a timestamp. The RP verifies the assertion by checking the return-to URL matches the request, validating the signature against the association (or by directly querying the OP if no association exists), ensuring the nonce is unique, and confirming the discovered endpoint details. This verification completes the flow, allowing the RP to establish a session with the user. OpenID 2.0 does not mandate message encryption beyond HTTPS transport, though Diffie-Hellman secures the association secret exchange. OpenID supports different modes to accommodate various use cases. In "check_id_immediate" mode, the OP attempts to respond without user interaction, returning a positive assertion if prior exists or a negative one otherwise; this is useful for seamless check-ins. The "check_id_setup" mode requires full user interaction at the OP for and approval, making it the standard for initial logins. A direct mode allows RPs and OPs to communicate without user-agent involvement, primarily for establishing associations or verifying assertions post-redirect. The introduction of indirect identifiers in OpenID 1.1 allowed users to select their OP dynamically during the flow, using special values like "http://specs.openid.net/auth/2.0/identifier_select" in requests, which streamlined discovery for delegated identities. Assertions in OpenID 2.0 consist of these signed, tamper-evident messages that convey minimal identity claims, focusing on proof of control rather than rich attributes.

Providers and Relying Parties

In OpenID Authentication 2.0, the OpenID Provider (OP) serves as the entity responsible for managing user identities and handling requests from relying parties. The OP facilitates user registration, though the specific methods for identifying authorized users fall outside the protocol's scope, allowing providers to implement their own mechanisms for account creation and management. Upon receiving an request, the OP authenticates the end-user's identity and obtains their approval for sharing identity information, subsequently redirecting the user's with either a positive or negative assertion to confirm the outcome. To ensure the integrity of these assertions, the OP signs them using established associations, such as those based on HMAC-SHA1 or HMAC-SHA256 algorithms, or through private associations in stateless modes. Additionally, the OP hosts an endpoint URL—typically over HTTP or —for processing protocol messages, which is discovered by relying parties through mechanisms like XRDS documents or rel tags. The (RP), in contrast, acts as the service or application seeking to authenticate users via OpenID, initiating the process by normalizing the user-supplied identifier, such as a URL or XRI. The RP then performs discovery on this identifier using Yadis protocols or HTML-based methods to locate the appropriate OP endpoint URL. To secure the exchange, the RP may establish shared associations with the OP, often using Diffie-Hellman , and sends signed requests to the OP. Upon receiving the OP's response, the RP verifies critical elements including the return URL, previously discovered information, nonces to prevent replay attacks, and the signatures on assertions, either directly with the OP or via pre-established associations. This verification enables seamless integration of OpenID into web applications, allowing RPs to delegate without storing user credentials. Interoperability between OPs and RPs is facilitated by standardized protocol endpoints and open-source libraries that simplify implementation. For instance, OP endpoints commonly use paths like "/openid/server" to handle authentication requests, as outlined in the specification. Libraries such as JanRain's PHP-based toolkit and DotNetOpenAuth for .NET provide comprehensive support for both OP and RP roles, enabling developers to build compatible systems with features like association management and extension handling. These tools ensure adherence to OpenID 2.0 while supporting backward compatibility with earlier versions like 1.1. An early example of an OP was MyOpenID, a free service launched by JanRain that allowed users to create OpenID identities but ceased operations in 2014. Modern implementations continue to rely on such libraries for OpenID 2.0 support, though the protocol has largely been superseded by OpenID Connect.

History and Evolution

Early Development

OpenID originated in 2005 when , founder of the blogging platform and an employee of Six Apart, developed it as a solution to the challenges of distributed across websites. At the time, faced issues with comment spam and the need for users to maintain multiple logins for different services, prompting Fitzpatrick to create a lightweight, decentralized system where users could authenticate using a single URL-based identity without sharing passwords or requiring central coordination. This approach aimed to enable interoperability among blogging platforms like , TypePad, and , leveraging simple discovery mechanisms to verify identity ownership. The first specification, OpenID 1.0, was published in May 2005 and emphasized basic URL-based through one-time signed assertions, eliminating the need for SSL, public keys, or browser plugins. It allowed static sites to act as identity providers with minimal infrastructure, using TypeKey—Six Apart's service—as the inaugural OpenID provider to demonstrate practical implementation. Development was community-driven via a on openid.net, fostering contributions from developers interested in open identity standards, while Six Apart provided core support through its platforms. In December 2006, OpenID 1.1 was released, building on the initial version by introducing extensions for delegation (allowing users to point to third-party providers via HTML links) and improving compatibility with AJAX-based interfaces for smoother user experiences. This update addressed early limitations in stateless operation and caching, enabling broader adoption among early relying parties. Microsoft offered partial support during this phase, signaling growing industry interest, though full integration came later; meanwhile, integrations with platforms like Blogger and Flickr began emerging, showcasing OpenID's potential for comment authentication and user verification on photo-sharing and blogging sites.

Specification Milestones

The OpenID specifications evolved through a series of formal releases under the OpenID Foundation, which was established in June 2007 to oversee standardization and intellectual property policies for the protocol. The foundational milestone came with OpenID Authentication 2.0, finalized on December 5, 2007, which built upon earlier informal developments like the Yadis project for and introduced enhancements such as support for Extensible Resource Identifiers (XRIs) alongside URLs as user identifiers. This version emphasized decentralized authentication without requiring relying parties to store user credentials, while incorporating mechanisms for improved and . Accompanying the core authentication spec, the OpenID Attribute Exchange (AX) 1.0 extension was also released on December 5, 2007, enabling the secure exchange of user attributes—such as names or email addresses—between OpenID providers and relying parties during . To address phishing risks, the Provider Authentication Policy Extension (PAPE) 1.0 was finalized on December 30, 2008, allowing relying parties to request specific authentication policies, like multi-factor methods, from providers and receive confirmation of their application. The (UI) Extension 1.0, released in 2008, further refined by specifying modes for authentication interfaces, such as popup windows or embedded iframes, to streamline interactions across devices. As OpenID matured, certain elements faced to align with evolving web standards and security practices. XRIs, initially integrated in OpenID 2.0 for abstract identifiers, were phased out in the 2010s following the disbandment of the OASIS XRI Technical Committee in 2015, due to limited adoption and maintenance challenges. This shift culminated in the transition toward OpenID Connect, an identity layer built on OAuth 2.0, with its core specification finalized on February 26, 2014, effectively superseding OpenID 2.0 for modern implementations while providing backward migration paths.

OpenID Foundation

Organizational Structure

The OpenID Foundation was established in 2007 as a non-profit organization dedicated to stewarding the development and maintenance of OpenID specifications, ensuring their open availability to promote interoperable digital identity solutions. The Foundation's governance is led by a Board of Directors, comprising up to 38 members categorized into sustaining directors appointed by sustaining members, community directors elected for two-year staggered terms, and corporate directors elected annually based on membership size. Operational activities are conducted through specialized working groups, such as the AB/Connect Working Group for OpenID Connect specifications, the FAPI Working Group for financial-grade API profiles, and the Shared Signals Working Group for security event sharing, all operating on a consensus-driven model open to contributors via a standard contribution agreement. Membership is structured into three primary classes—sustaining, individual, and corporate—with the Board able to define additional tiers; participation is accessible to private entities, governments, non-profits, and individuals, though not required for contributing to working groups. Key operations include a specification development process managed by working groups in three phases: drafts for initial proposals, implementer's drafts for testing and refinement, and final specifications upon consensus approval, with all outputs freely available under an open copyright license. The Foundation administers certification programs featuring self-certification and conformance test suites for standards like OpenID Connect and Financial-grade API, adopted by entities including the UK and Brazilian governments to verify ecosystem compliance. International chapters, governed by a national chapters policy, support localized adoption and profiling, with examples including the OpenID Foundation Japan. As of 2025, the active international chapter is OpenID Foundation Japan (OIDF-J). Headquartered in San Ramon, California, United States, the Foundation tracks specification progress through periodic updates, board elections, and public announcements.

Key Contributors and Chapters

Brad Fitzpatrick is recognized as the founder of OpenID, having developed the initial authentication protocol in May 2005 while working as the creator of the community website. His contributions extended to evangelism efforts, including a prominent presentation on OpenID at the Internet Identity Workshop (IIW) in October 2005, which helped build early community momentum. David Recordon served as an early advocate and key collaborator in OpenID's development, co-authoring the OpenID Authentication 1.1 specification in 2006 alongside Fitzpatrick. As a founding board member of the OpenID Foundation established in 2007, Recordon played a pivotal role in promoting the protocol through global outreach and specification finalization, including announcing the completion of OpenID 2.0 in 2007. His work also bridged OpenID with related standards like . Mike Jones has been a longstanding technical leader in the OpenID ecosystem, serving on the OpenID Foundation's since 2008 and architecting the globally adopted OpenID certification program. As a principal contributor to the OpenID Connect working group, Jones co-authored core specifications and continues to drive updates, including federation enhancements, through his role as board secretary and active participation in foundation workshops. The OpenID Foundation supports international chapters to localize efforts, host events, and adapt specifications for regional needs. The chapter, known as OpenID Foundation Japan (OIDF-J), was announced in February 2008 in collaboration with eleven technology companies and formally established in April 2008, focusing on education, interoperability testing, and events like the recurring OpenID Summit , which celebrated OpenID Connect's tenth anniversary in 2024. As of 2025, OIDF-J remains the active international chapter, contributing to the Connect working group by providing localized feedback and hosting interops that influenced profiles for mobile and . An earlier European effort, the independent OpenID Europe Foundation formed in 2007 in , handled initial trademark registrations but is no longer active as a chapter. The OpenID Foundation's policies govern the development and use of its specifications, ensuring while protecting contributors and implementers. Specifications, including Work Group Drafts, Implementers' Drafts, and Final Specifications, are licensed under the OpenID Copyright , which provides a perpetual, irrevocable, non-exclusive, , worldwide copyright to reproduce, distribute, publicly display, publicly perform, and create derivative works for the purpose of developing and implementing compliant products. This requires attribution to the OpenID Foundation and applies to all OIDF-approved specifications, promoting widespread adoption without restrictive terms. For , the Intellectual Property Rights (IPR) Policy mandates that contributors grant a , worldwide, non-exclusive patent covering Necessary Claims—defined as claims essential to implementing the specifications—to the Foundation, other contributors, and implementers. The contribution process is structured to maintain openness and mitigate legal risks through formal agreements. All individuals or entities submitting contributions must execute the OpenID Foundation's standard Contribution Agreement, which incorporates the IPR Policy and Process Document by reference, granting the Foundation necessary and rights while affirming the contributor's ownership of their submissions. This agreement ensures that contributions can be integrated into specifications without encumbrances, with contributors promising not to assert patent claims against compliant implementations, thereby facilitating collaborative development. Unlike some standards bodies, the current IPR Policy does not require disclosure of potential essential patents, placing the onus on participants to act in . On March 1, 2012, the OpenID Foundation Board unanimously approved a patent pledge statement for inclusion in all specifications, explicitly granting implementers a under any Foundation-owned patents essential to compliance, further reducing barriers to adoption. Regarding trademarks, the Foundation secured the OpenID trademark in the United States in March 2008, resolving early community discussions on ownership and usage, and later formalized the OpenID Trademark and Service Mark License Policy in 2013 to guide acceptable branding practices. Implementations of OpenID protocols must comply with applicable privacy regulations, such as the EU's (GDPR), particularly for handling user consent and personal data in flows, as outlined in the Foundation's . As of 2025, the OpenID Foundation has faced no major lawsuits related to its specifications or policies.

Adoption and Implementations

Major Providers and Users

OpenID's early adoption in the mid-2000s was driven by several prominent providers, including MyOpenID, which operated from 2005 until its shutdown on February 1, 2014, after being acquired by Janrain. and Yahoo also served as key OpenID 2.0 providers during this period, enabling users to authenticate across sites with their existing accounts, though both discontinued support in the 2010s. Specifically, Yahoo ended OpenID 2.0 support by mid-2015 as part of a broader migration to OpenID Connect. By 2025, OpenID 2.0 provider support has significantly diminished, with major players like terminating it on April 20, 2015, to prioritize OpenID Connect. maintains legacy compatibility through OpenID Connect implementations but no longer actively supports pure OpenID 2.0. Niche providers persist, such as IndieAuth.net, which offers OpenID compatibility via endpoints like openid.indieauth.com for decentralized authentication in personal websites and indie web tools. OpenID 2.0 usage has continued to decline due to and the rise of more secure alternatives. In contrast, OpenID Connect has seen widespread adoption by 2025, with major providers including , , and Apple enabling single sign-on for billions of users across web, mobile, and applications. As of August 2025, over 82,000 verified companies utilize OpenID Connect implementations, reflecting its role in powering secure authentications globally. Early relying parties included platforms like , which integrated OpenID 2.0 through plugins for user logins starting in the late 2000s, and , a strong early advocate that launched with OpenID support in 2008 to enable federated authentication. However, discontinued OpenID logins on July 25, 2018, shifting to other methods like . Current integrations remain in select forums and wikis, often via legacy plugins or hybrid setups, but adoption has waned as sites migrate to OpenID Connect for enhanced security and interoperability.

Use Cases and Integration Examples

OpenID facilitates (SSO) scenarios where users can authenticate to blogs, forums, and platforms using a single set of credentials from an OpenID provider, eliminating the need for site-specific accounts. This approach reduces and enhances user convenience across services. For instance, users could log into multiple websites by providing their OpenID identifier, such as a URL from a trusted provider, allowing seamless access without repeated registrations. A notable early example occurred in 2008 when enabled OpenID for commenting on Blogger posts, permitting users to sign in with their existing OpenID credentials to participate in discussions. Similarly, the trialed an OpenID system that integrated Yahoo logins for comment authentication on its platforms, demonstrating practical application in media forums to simplify user interactions. In contexts, OpenID supported SSO integrations that allowed customers to access shopping carts and accounts across affiliated sites using one identity, streamlining transactions while maintaining decentralized control. In enterprise environments prior to the widespread adoption of OpenID Connect around 2014, OpenID 2.0 enabled internal identity federation by allowing organizations to link authentication across internal applications and services without centralized credential storage. Large enterprises like and utilized OpenID for federated SSO, where employees could access intranets, collaboration tools, and legacy systems via a unified , improving efficiency in pre-cloud infrastructures. Integration examples include content management systems configured as relying parties. The Drupal OpenID SSO Relying Party module, released in 2011, enables Drupal sites to authenticate users against a central OpenID provider, redirecting login requests for SSO across networked installations. For WordPress, early plugins such as the OpenID plugin (version 2.1.3 and prior) allowed site administrators to set up relying party functionality by incorporating OpenID URL fields in user profiles, facilitating authentication via external providers. Hybrid setups with social logins were common, as providers like and Yahoo offered OpenID services, enabling users to leverage social accounts as OpenID identifiers for broader SSO compatibility. In modern applications as of 2025, OpenID Connect supports diverse use cases, including "Sign in with " or "Sign in with Apple" for consumer apps, enabling secure profile data access and SSO across platforms. Enterprise integrations, such as those using certified OpenID Connect providers like AD, facilitate federated access to cloud services and APIs for millions of organizations. Niche open-source projects continue to support legacy OpenID 2.0 compatibility; for example, the Gluu Server incorporates OpenID support for SSO in community-driven deployments, allowing developers to federate access in custom forums and tools while maintaining with older specifications.

Security and Privacy

Common Vulnerabilities

One notable in early OpenID implementations involved manipulation of requests due to the lack of authenticity and guarantees, leading to (RP) confusion about the (IdP) involved in the flow. This issue, identified around 2008 in OpenID 2.0 evaluations, allowed adversaries to forge or alter requests, potentially enabling unauthorized access by tricking the RP into accepting invalid responses. In OpenID 1.0, nonce reuse flaws permitted replay attacks, as many RPs failed to properly validate nonce values in authentication responses, allowing intercepted messages to be reused against the same or other sites. Empirical of implementations revealed that inadequate nonce checking exposed users to repeated exploitation of captured authentication data, undermining the protocol's resistance to passive . Phishing attacks targeting OpenID often exploited OP impersonation through similar domains, where attackers registered lookalike URLs (e.g., using attacks or slight variations) to mimic legitimate IdPs and capture user credentials during login redirects. In 2007, IdP selection attacks further compounded this risk, as demonstrated by CVE-2007-1652, where remote attackers could forcibly log users into OpenID-enabled sites via crafted web pages that exploited cached tokens, disclosing and adding unauthorized sites to trusted lists without user consent. Privacy concerns in OpenID arose from unintended attribute disclosure via the Attribute Exchange (AX) extension, where some implementations did not verify signed AX data, allowing attackers to modify or inject attributes during and expose sensitive to malicious RPs without detection. This flaw, highlighted in a advisory, enabled low-effort impersonation or data leakage, particularly when high-trust attributes from IdPs were not properly authenticated. The protocol's trust model assumptions introduced additional vulnerabilities, relying on RPs to inherently trust OPs for without robust verification of OP or user-selected IdPs, which could lead to exploitation if a malicious OP was chosen or compromised. This decentralized trust structure assumed low assurance levels suitable only for non-critical applications, leaving higher-stakes scenarios exposed to issues like association poisoning or identity recycling when assumptions about secure OP-RP communication failed. A prominent specific event was the 2014 Covert Redirect vulnerability, an open redirector attack affecting OpenID's redirect-based flows, where attackers altered the redirect_uri parameter to bypass validation and redirect users to malicious sites, potentially exposing codes or during . This issue, analogous to but embedded in the protocol's URI handling, impacted OpenID-enabled sites by allowing covert exfiltration of user sessions without altering core credentials. Authentication hijacking over HTTP represented another critical exposure, as OpenID's redirect mechanisms in unsecured connections enabled man-in-the-middle attacks, where adversaries intercepted and replayed authentication responses to hijack sessions or add malicious identities to user accounts. Early implementations, such as certain WordPress OpenID plugins, lacked protections like CSRF tokens, facilitating such hijacks by exploiting HTTP's lack of encryption to manipulate OpenID URLs and force unauthorized logins. In February 2025, the OpenID Foundation disclosed a vulnerability (CVE-2025-27370) due to ambiguities in JWT audience values in OpenID Connect's private_key_jwt client authentication, potentially allowing malicious authorization servers to inject attacker-controlled audiences into tokens, compromising security objectives like token integrity. No known exploits occurred, but it prompted spec updates. Additional 2025 vulnerabilities include CVE-2025-59363 in , where API keys could access OIDC client secrets, risking exposure in shared credential environments (patched in version 2025.3.0), and CVE-2025-12466 in Drupal's Simple OAuth module, enabling bypass via alternate paths in OpenID Connect flows. Persistent misconfigurations like nOAuth in continue to affect ~9% of SaaS apps integrating OpenID flows, enabling account takeovers as of June 2025.

Mitigation Strategies and Best Practices

To secure OpenID implementations, relying parties (RPs) and openID providers (OPs) must prioritize the use of for all endpoints, including discovery, requests, and responses, to prevent and man-in-the-middle attacks; this involves employing SSL/TLS with certificates from trusted authorities and ensuring HTTP URLs redirect to equivalents. Strict validation of message signatures is essential, utilizing HMAC-SHA256 (preferred over HMAC-SHA1) and associations established via Diffie-Hellman key exchange to verify the authenticity of responses, with RPs either storing associations or performing direct verification against the OP. For enhanced authentication assurance, implement the Provider Authentication Policy Extension (PAPE) to request and enforce (MFA), where RPs specify policies such as "Multi-Factor" (e.g., knowledge factor like a PIN combined with possession factor like a soft token) or "Multi-Factor Physical" (e.g., hardware token) in requests, and OPs respond with details of the applied method to confirm compliance. RPs should verify OP endpoints by discovering them through XRDS documents (ensuring digital signatures per XMLDSIG to detect tampering) and validating that response origins match the discovered URLs, thereby mitigating risks from rogue providers. User education plays a critical role, with OPs and RPs advising end-users to access sites only via top-level browser windows and recognize attempts by verifying domain authenticity before entering credentials. Attribute filtering is a key privacy strategy, where RPs request only necessary attributes via extensions like Attribute Exchange (AX) and OPs limit disclosure to the minimum required, reducing exposure of sensitive data such as or full names unless explicitly consented. Following OpenID Foundation (OIDF) guidelines established post-2014, RPs must rigorously validate redirect URIs (openID.return_to) by ensuring exact matches against pre-registered values, rejecting any deviations to counter open redirector risks in flows. Useful tools include the OIDF's conformance testing suites and certification checklists, which guide implementers through validation for , covering aspects like endpoint protection and enforcement; certified implementations demonstrate adherence to these standards. To monitor for replay attacks, RPs should track nonces in positive assertions and timestamps in responses, rejecting duplicates or those outside a defined validity window (e.g., via session storage), while OPs apply to curb denial-of-service attempts. In 2025, OIDF profiles emphasize mandatory adoption of TLS 1.3 for all connections to leverage its improved against downgrade and protocol attacks, superseding older TLS versions in OpenID deployments.

OpenID Connect

Relation to OpenID 2.0

OpenID Connect (OIDC) serves as an identity layer on top of the OAuth 2.0 authorization framework, enabling clients to verify the identity of end-users and obtain basic profile information through standardized authentication mechanisms. Finalized by the OpenID Foundation (OIDF) in February 2014 with the release of the OIDC Core 1.0 specification, it represents a modern evolution in decentralized identity protocols designed for enhanced interoperability and security in and mobile applications. In contrast to OpenID 2.0, the preceding iteration of the OpenID protocol finalized in December 2007, OIDC introduces significant architectural shifts to address limitations in scalability, security, and ease of implementation. OpenID 2.0 relied on signed messages formatted in a key-value encoding scheme, where responses were authenticated using mechanisms like HMAC-SHA1 signatures over associations between relying parties and providers. OIDC, however, employs -based structures throughout, with identity assertions delivered via JSON Web Tokens (JWTs) as ID tokens that compactly encode claims such as the issuer, subject, and authentication timestamp in a self-contained, verifiable format. This JWT approach facilitates stateless verification and reduces reliance on shared secrets, marking a departure from OpenID 2.0's more cumbersome direct communication and verification flows. OIDC does not provide direct with OpenID 2.0, as it operates on a fundamentally different protocol stack built atop OAuth 2.0 rather than extending the older specification's direct model. Instead, OIDC supersedes OpenID 2.0 for new deployments, encouraging migration to leverage its improved privacy features, such as selective disclosure of claims, and broader ecosystem support. The OIDF has designated OpenID 2.0 as obsolete, with libraries and implementations for the legacy protocol maintained separately from active OIDC development. The OIDC Core 1.0 specification has undergone maintenance updates to incorporate errata and clarifications, including errata set 2 released in December 2023, ensuring ongoing robustness without altering core semantics. By 2025, OIDC Core 1.0 achieved further international standardization as Recommendation X.1285 in May 2025, underscoring its global adoption and stability as the preferred successor to OpenID 2.0.

Key Features and Flows

OpenID Connect (OIDC) introduces several core features that build upon OAuth 2.0 to provide robust identity layer functionality. The ID Token is a (JWT) that conveys claims about the authentication of an End-User by the OpenID Provider (OP), including standard claims such as (iss), subject (sub), audience (aud), and expiration time (exp). This token is digitally signed to ensure integrity and authenticity, with the recommended signing algorithm being RS256 unless otherwise specified. The UserInfo Endpoint allows a (RP) to retrieve additional claims about the authenticated End-User by presenting a valid , supporting both signed and unsigned responses for flexibility in deployment. For dynamic discovery, OIDC relies on the discovery document published by the OP at the path /.well-known/openid-configuration, which provides metadata such as endpoint URIs, supported scopes, and claim types to facilitate interoperability without hardcoding configurations. OIDC defines several authentication flows tailored to different client types and security requirements, all initiated via the Authorization Endpoint. The Authorization Code Flow, the most secure and recommended for confidential clients, involves the RP redirecting the End-User to the OP for authentication, after which the OP issues an authorization code that the RP exchanges at the Token Endpoint for an Access Token and ID Token; this flow is enhanced by Proof Key for Code Exchange (PKCE) to mitigate authorization code interception attacks for public clients. The Implicit Flow, which directly returns the ID Token and optionally the Access Token in the redirect URI fragment, has been deprecated in favor of more secure alternatives due to vulnerabilities like token leakage in browser histories. The Hybrid Flow combines elements of the previous two by returning an authorization code alongside tokens in the initial redirect, allowing immediate partial access while deferring full token issuance to the Token Endpoint for added security. For machine-to-machine scenarios without user involvement, the Client Credentials Flow enables clients to obtain an Access Token directly from the Token Endpoint using client authentication, though it does not issue ID Tokens as it lacks End-User context. To ensure conformance and interoperability, OIDC 1.0 specifies mandatory profiles for OPs and RPs, including support for RS256 ID Token signing, the prompt and display parameters, and the max_age claim for authentication freshness; dynamic OPs must additionally implement discovery, dynamic client registration, and the UserInfo Endpoint. Extensions to OIDC address specialized use cases, particularly in high-security environments. The Financial-grade API (FAPI) profiles, such as FAPI 2.0, impose stringent security requirements on top of OIDC and OAuth 2.0, including mutual TLS for client authentication, sender-constrained tokens via DPoP, and precise error handling to protect financial APIs against advanced threats. The Shared Signals Framework (SSF) 1.0, finalized in 2025, enables OPs and RPs to share privacy-preserving security events—such as authentication attempts or risk incidents—via secure webhooks or push notifications, using Security Event Tokens (SETs) to enhance real-time threat detection across ecosystems. Furthermore, the OpenID for Verifiable Presentations 1.0 specification, approved in 2025, integrates OIDC with decentralized identifiers by allowing RPs to request and receive Verifiable Credentials as presentations through OAuth-protected endpoints, supporting selective disclosure and tamper-evident proofs for privacy-focused identity verification.

Comparisons with Other Protocols

Versus OAuth-Based Authentication

OpenID is fundamentally an designed to verify a user's identity, enabling relying parties to confirm "who you are" through decentralized identifiers and signed assertions from an OpenID provider. In contrast, —both versions 1.0 and 2.0—is an authorization framework focused on delegating access to protected resources, determining "what you can do" by issuing access tokens that grant scoped permissions without disclosing user credentials. This distinction means OAuth was not engineered for identity verification; its tokens represent resource access rights rather than authenticated identity claims, unlike OpenID 2.0's cryptographically signed assertions that explicitly attest to the user's identifier. A common misuse of OAuth involves "pseudo-authentication," where developers repurpose its authorization flows to simulate by requesting identity-related scopes (e.g., or profile) and assuming the token holder's identity based on returned claims, without robust verification. This approach lacks the direct identity attestation of OpenID, exposing systems to risks such as insufficient proof of user control over the associated account. In a notable analysis, pseudo-authentication was critiqued for enabling potential account takeover on untrusted sites, as access tokens could grant excessive privileges—like reading private messages—without confirming the user's real at the provider, exemplified by Twitter's OAuth implementation allowing direct message access until restricted in May . To address these limitations, best practices recommend avoiding raw for purposes and instead adopting OpenID Connect (OIDC), which extends OAuth 2.0 with standardized identity tokens and verification mechanisms to ensure secure, verifiable user . This layered approach mitigates the verification gaps in pseudo- while leveraging OAuth's authorization strengths.

Integration with Emerging Standards

OpenID Connect facilitates integration with FIDO2 and standards to enable , allowing relying parties to leverage biometric or hardware-based authenticators for secure user verification without traditional passwords. This synergy combines OpenID Connect's identity layer with FIDO2's cryptographic credentials, supporting scenarios like in federated environments where end-users authenticate via platform authenticators such as fingerprints or security keys. The Self-Issued OpenID Provider (SIOP) v2 specification extends OpenID Connect to support decentralized identities, enabling end-users to control their own OpenID Providers without relying on centralized issuers. In SIOP, users generate self-signed ID Tokens to authenticate directly with relying parties, promoting user-centric identity management and compatibility with wallet-based systems for presenting claims across devices. OpenID for Verifiable Presentations 1.0, approved as a final specification in July 2025, integrates OpenID Connect with verifiable credentials protocols, allowing holders to present cryptographically signed credentials as verifiable presentations during authentication flows. This enables selective disclosure of attributes, such as proofs of age or qualifications, while maintaining privacy through zero-knowledge proofs, and supports interoperability with W3C standards for digital wallets and decentralized identifiers. The OpenID Federation 1.0 specification, at draft 44 as of October 2025, establishes dynamic trust frameworks for large-scale ecosystems by enabling entities to discover and validate metadata through hierarchical authorities, facilitating scalable without pre-configured trust anchors. This allows OpenID Providers and relying parties to establish trust on-demand, supporting use cases like cross-border identity verification in and enterprise settings. The Shared Signals Framework 1.0, finalized in August 2025, enhances OpenID Connect by standardizing real-time sharing of security events and risk signals between peers, such as attempts or account compromises, to enable coordinated responses. It uses event tokens to transmit signals like Continuous Access Evaluation Profile (CAEP) notifications, improving session security in distributed systems. OpenID Connect maintains compatibility with SAML through profiles like FastFed, which define subsets of SAML specifications for federated provisioning and interoperability, allowing hybrid deployments where SAML assertions can be bridged to OpenID flows. This ensures seamless transitions in enterprise environments supporting both protocols for .

Recent Developments

New Specifications and Frameworks

In recent years, the OpenID Foundation (OIDF) has advanced the OpenID ecosystem through specifications that enhance trust negotiation and in federated environments. The OpenID Federation 1.0 specification, reaching draft 44 in October 2025, introduces improved mechanisms for entities to establish trust via third-party intermediaries, incorporating features motivated by large-scale government use cases such as those in . This draft refines metadata handling, policies, and endpoint discovery to support scalable, dynamic trust relationships without relying on static bilateral agreements. A significant 2025 milestone is the finalization of the Shared Signals Framework (SSF) 1.0 in September, which standardizes the secure, real-time delivery of events across connected identity systems. Complementing SSF, the OpenID Continuous Access Evaluation Profile (CAEP) 1.0 enables near-instantaneous revocation and evaluation of access based on events like token compromise or risk signals, addressing previous gaps in real-time sharing within OpenID Connect (OIDC) deployments. These specifications, approved as Final by the OIDF in September 2025, facilitate proactive responses in distributed architectures. Advancements in verifiable technologies have also progressed, with OpenID for Verifiable Presentations (OID4VP) 1.0 entering public review from April 24 to June 23, 2025, and achieving Final Specification status on July 10, 2025. This protocol builds on OIDC to request and present securely, enabling privacy-preserving identity proofs without disclosing unnecessary data. Similarly, OpenID for Verifiable Credential Issuance 1.0 (OID4VCI) underwent public review from June 29 to August 28, 2025, and achieved Final Specification status on September 16, 2025, to standardize credential issuance flows. To bolster privacy in authorization processes, updates to OIDC have integrated the OAuth 2.0 Rich Authorization Requests (RAR) extension, as outlined in RFC 9396, allowing clients to specify fine-grained authorization details while emphasizing privacy-preserving designs that minimize exposure of sensitive user information. OIDF's 2025 specifications reached Final status for shared signals and verifiable credentials, while OpenID Federation 1.0 continues to progress toward finalization, collectively mitigating limitations in real-time data sharing and trust establishment across OpenID implementations. In November 2025, the OIDF published two papers proposing a standardized framework for integrating U.S. mobile driver's licenses (mDLs) as , facilitating their acceptance by financial institutions and advancing mobile ID within the OpenID .

Community Events and Ecosystem Growth

The OpenID Foundation (OIDF) organized a hybrid workshop on October 20, 2025, at Cisco's offices in , immediately preceding the Fall 2025 Internet Identity Workshop (IIW), to facilitate discussions on ongoing specifications and among developers and stakeholders. This event, accessible both in-person and online, highlighted progress in OpenID standards and drew participation from global contributors to advance collaborative testing and adoption strategies. At Authenticate 2025 in October, the OIDF hosted an interoperability event for the Shared Signals Framework (SSF), where eight leading vendors successfully demonstrated real-time security event sharing using the finalized SSF 1.0, Client Authentication Event Protocol (CAEP) 1.0, and Related and Independent Security Considerations (RISC) 1.0 specifications. This milestone testing underscored the framework's ability to enable secure coordination across identity systems, marking a key step in practical deployment. During Identiverse 2025 in June, the OIDF Board presented a "Take on the Landscape" session, providing insights into evolving identity standards and fostering dialogue on integration challenges among over 250 speakers and attendees focused on and privacy. At the European Identity and Cloud Conference (EIC) 2025 in May, the OIDF delivered updates on its progress, emphasizing multiple specifications advancing to final status and enhanced interoperability testing initiatives to support global deployment. These efforts reflect a focus on rigorous , with events like the April 2025 interop in validating implementations against certification profiles. The OpenID ecosystem has seen growing adoption in Customer Identity and Access Management (CIAM) platforms, where OpenID Connect serves as a foundational protocol for secure authentication in customer-facing applications. OIDF news in 2025 highlighted the finalization of key specifications, including SSF 1.0, CAEP 1.0, and RISC 1.0 in September, which enable real-time threat sharing and bolster Zero Trust architectures across sectors. Working group participation has increased, with expanded involvement in groups like Digital Credentials Protocols, evidenced by formal security analyses and interop demonstrations involving multiple issuers and wallets. Reports from 2025 events indicate rising global uptake of OpenID standards, particularly in open banking and enterprise ecosystems, driven by conformance certifications and collaborative testing.

References

  1. https://openid.net/developers/
  2. https://openid.net/specs/openid-authentication-2_0.html
  3. https://openid.net/foundation/
  4. https://openid.net/specs/openid-connect-core-1_0.html
  5. https://openid.net/10-years-on-openidconnect-published-as-iso-spec/
  6. https://openid.net/developers/how-connect-works/
  7. https://openid.net/certification/
  8. https://openid.net/
  9. http://blog.facilelogin.com/2014/10/brief-history-of-openid-connect.html
  10. https://epublications.regis.edu/cgi/viewcontent.cgi?article=1629&context=theses
  11. https://openid.net/developers/libraries-for-obsolete-specifications/
  12. https://thenextweb.com/news/myopenid-to-shut-down
  13. https://www.danga.com/words/openid-pres.pdf
  14. https://slashdot.org/story/05/07/05/2020221/livejournal-founder-launches-openid-system
  15. https://openid.net/specs/openid-authentication-2_0-pre11.html
  16. https://openid.net/specs/openid-authentication-1_1.html
  17. https://brad.livejournal.com/2147610.html
  18. https://openid.net/the-openid-foundation-launches-the-openid-connect-standard/
  19. https://openid.net/specs/openid-attribute-exchange-1_0.html
  20. https://openid.net/specs/openid-provider-authentication-policy-extension-1_0.html
  21. https://openid.net/specs/openid-connect-core-1_0-final.html
  22. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xri
  23. https://openid.net/wp-content/uploads/2023/11/OIDF-Org-Doc-Bylaws-Final-11-16-2023.pdf
  24. https://openid.net/foundation/board/
  25. https://openid.net/wg/connect/
  26. https://openid.net/wg/fapi/
  27. https://openid.net/wg/sharedsignals/
  28. https://openid.net/foundation/benefits-members/
  29. https://openid.net/developers/specs/
  30. https://openid.net/wordpress-content/uploads/2017/06/OIDF-Policy-Process-Document-Final-6-19-2017.pdf
  31. https://openid.net/developers/certified-openid-connect-implementations/
  32. https://openid.net/foundation/national-chapters-policy/
  33. https://openid.net/openid_foundation_local_chapters/
  34. https://openid.net/2025-openid-board-of-directors/
  35. https://decentralized-id.com/history/2000s/
  36. https://www.windley.com/archives/2005/11/iiw2005_talks.shtml
  37. https://self-issued.info/?p=48
  38. https://www.kuppingercole.com/events/eic2023/speakers/497
  39. https://self-issued.info/?p=2592
  40. https://openid.net/policies/
  41. https://openid.net/wp-content/uploads/2024/10/OIDF-Policy_IPR-Policy_Final_2024-10-19.pdf
  42. https://openid.net/intellectual-property/openid-foundation-contribution-agreements/
  43. http://openid.net/wordpress-content/uploads/2012/04/OIDF-Specification-License-Out-Resolution-OIDF-BOARD-APPROVED-March-1-2012.pdf
  44. https://openid.net/openid-trademark-and-service-mark-license/
  45. https://openid.net/wp-content/uploads/2023/08/OIDF_Privacy-Policy_Final_2023-08-14.pdf
  46. https://tech.slashdot.org/story/13/09/04/228229/myopenid-to-shut-down-in-february
  47. https://evertpot.com/replacing-myopenid/
  48. https://lists.openid.net/pipermail/openid-general/2008-January/013416.html
  49. https://developers.googleblog.com/reminder-to-migrate-to-oauth-20-or-openid-connect/
  50. https://developer.paypal.com/docs/log-in-with-paypal/
  51. https://indieauth.com/openid
  52. https://openid.net/industry-leaders-lead-google-asks-developers-to-migrate-from-openid-2-0-to-openid-connect/
  53. https://data.landbase.com/technology/openid-connect/
  54. https://stackoverflow.blog/2010/04/13/openid-one-year-later/
  55. https://meta.stackexchange.com/questions/307647/support-for-openid-ended-on-july-25-2018
  56. https://wordpress.org/plugins/openid-connect-server/
  57. https://planergy.com/blog/saml-vs-oauth-vs-openid/
  58. https://www.okta.com/blog/identity-security/exploration-of-open-identity-standards/
  59. http://news.bbc.co.uk/2/hi/technology/7234499.stm
  60. https://www.drupal.org/project/openid_sso_relying
  61. https://www.gnucitizen.org/blog/hijacking-openid-enabled-accounts/
  62. https://learn.microsoft.com/en-us/entra/identity-platform/v2-protocols-oidc
  63. https://www.sciencedirect.com/science/article/abs/pii/S0167404812000387
  64. https://www.blackhat.com/presentations/bh-usa-07/Tsyrklevich/Whitepaper/bh-usa-07-tsyrklevich-WP.pdf
  65. https://nvd.nist.gov/vuln/detail/CVE-2007-1652
  66. https://www.helpnetsecurity.com/2011/05/06/openid-attribute-exchange-flaw/
  67. https://inria.hal.science/hal-01054399/document
  68. https://oauth.net/advisories/2014-1-covert-redirect/
  69. https://openid.net/notice-of-a-security-vulnerability/
  70. https://nvd.nist.gov/vuln/detail/CVE-2025-27370
  71. https://thehackernews.com/2025/10/onelogin-bug-let-attackers-use-api-keys.html
  72. https://nvd.nist.gov/vuln/detail/CVE-2025-12466
  73. https://thehackernews.com/2025/06/noauth-vulnerability-still-affects-9-of.html
  74. https://nat.sakimura.org/2014/05/08/covert-redirect-is-not-new/
  75. https://openid.net/specs/openid-igov-oauth2-1_0-08.html
  76. https://openid.net/openid-connect-core-1-0-now-published-as-itu-standard/
  77. https://www.itu.int/epublications/publication/itu-t-x-1285-2025-05-openid-connect-core-1-0-errata-set-2
  78. https://openid.net/specs/openid-connect-core-1_0.html#IDToken
  79. https://openid.net/specs/openid-connect-core-1_0.html#IDTokenValidation
  80. https://openid.net/specs/openid-connect-core-1_0.html#UserInfoEndpoint
  81. https://openid.net/specs/openid-connect-discovery-1_0.html
  82. https://openid.net/specs/openid-connect-core-1_0.html#CodeFlow
  83. https://openid.net/specs/openid-connect-core-1_0.html#ImplicitFlow
  84. https://openid.net/specs/openid-connect-core-1_0.html#HybridFlow
  85. https://openid.net/specs/openid-connect-core-1_0.html#ClientCredentials
  86. https://openid.net/specs/openid-connect-core-1_0.html#RFCConformance
  87. https://openid.net/specs/fapi-security-profile-2_0-final.html
  88. https://openid.net/specs/openid-sharedsignals-framework-1_0.html
  89. https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
  90. https://nat.sakimura.org/2011/05/15/dummys-guide-for-the-difference-between-oauth-authentication-and-openid/
  91. https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/Federation.html
  92. https://6b.health/insight/how-to-integrate-nhs-cis2-authentication-using-oidc-fido2-webauthn/
  93. https://openid.net/specs/openid-connect-self-issued-v2-1_0.html
  94. https://openid.net/specs/openid-connect-self-issued-v2-1_0-ID1.html
  95. https://openid.net/openid-for-verifiable-presentations-1-0-final-specification-approved/
  96. https://openid.net/specs/openid-federation-1_0.html
  97. https://self-issued.info/?p=2756
  98. https://openid.net/press-release-openid-foundation-finalizes-global-standards-for-real-time-identity-security/
  99. https://openid.net/specs/fastfed-saml-1_0-02.html
  100. https://openid.net/specs/openid-caep-1_0-ID2.html
  101. https://openid.net/public-review-period-for-proposed-openid-verifiable-presentations-final-specification/
  102. https://openid.net/public-review-period-for-proposed-openid-for-verifiable-credential-issuance-1-final-specification/
  103. https://openid.net/openid-for-verifiable-credential-issuance-1-final-specification-approved/
  104. https://datatracker.ietf.org/doc/html/rfc9396
  105. https://www.biometricupdate.com/202511/openid-foundation-publishes-papers-on-standardizing-us-mdls-as-verifiable-credentials
  106. https://openid.net/registration-open-for-openid-foundation-hybrid-workshop-at-cisco-on-mon-20th-october-2025/
  107. https://www.youtube.com/watch?v=71vAv3bgIR0
  108. https://openid.net/top-firms-test-interoperability-of-final-ssf-and-caep/
  109. https://openid.net/shared-signals-interop-event-at-authenticate-2025-call-for-participation/
  110. https://openid.net/openid-foundation-takes-the-stage-at-identiverse-2025/
  111. https://www.kuppingercole.com/sessions/5814
  112. https://openid.net/openid-federation-interop-apr-28-30-2025/
  113. https://guptadeepak.com/customer-identity-hub/openid-connect-core-concepts-ciam
  114. https://openid.net/wg/digital-credentials-protocols/
  115. https://openid.net/wp-content/uploads/2025/05/Pre-EIC-Workshop-06May2025.pdf
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.