OpenID 2.0 explained: the original decentralised login

OpenID 2.0 was an open standard that let you use one web address as your identity on many websites. Instead of creating a username and password for each site, you typed a URL you controlled, such as alice.example.org, and the site asked the service behind that URL to confirm that you really were its owner. It was finalised in December 2007 and has since been replaced by OpenID Connect.

What was OpenID?

OpenID started in 2005 as a way to prove ownership of a blog address, created by a developer working on the LiveJournal blogging service. The idea was simple and radical: identity should not belong to one company. Anyone could run a provider, anyone could accept logins, and users could choose their provider freely, or even run their own.

This is the sense in which OpenID was decentralised: there was no central registry and no prior agreement between a website and a provider. The specification text is archived on the OpenID Foundation site.

How did OpenID 2.0 work?

Three roles were involved: the user, the OpenID Provider (OP) that authenticates the user, and the Relying Party (RP), the website that wants a login. Our page on the relying party follows the term from here to the present day.

1. Enter the identifier. The user types an OpenID, a URL or an XRI, on the website’s login form.
2. Discovery. The relying party fetches that URL and finds out which provider is responsible. OpenID 2.0 used the Yadis protocol and XRDS documents, with a fallback to <link> tags in the page’s HTML. The result is the provider’s endpoint address.
3. Association (optional). The relying party and provider can agree on a shared secret using Diffie-Hellman key exchange. Without it, the relying party later asks the provider to verify the response (‘stateless’ or ‘dumb’ mode).
4. Redirect. The browser is sent to the provider with an authentication request carrying openid.* parameters.
5. Authentication. The provider logs the user in, with a password or other means, and asks for permission to share the identity with that site.
6. Response. The provider redirects back with a signed assertion, again as URL parameters.
7. Verification. The relying party checks the signature, the nonce and that the provider was authoritative for the identifier.

Delegation

Delegation let you keep a personal URL while using a third-party provider. On your own page you placed two HTML links, in OpenID 1.x openid.server and openid.delegate, and in 2.0 openid2.provider and openid2.local_id. Relying parties followed them to your provider. If you later changed provider, your OpenID stayed the same.

Identifier Select

OpenID 2.0 also introduced identifier select: the user types only the provider’s address, for example a large web company, and the provider fills in the user’s actual identifier. This made login friendlier, but changed the identity model: the user no longer controlled the URL.

Extensions

Core OpenID only said that you control an identifier. Extensions such as Simple Registration and Attribute Exchange transported profile data like name and email. Their use varied between providers, which later hurt interoperability.

Why was it replaced?

• Usability. Typing a URL as a username confused ordinary users. Buttons for major providers were easier, but that undermined the open idea.
• Phishing. A malicious relying party could redirect users to a fake provider page that looked real.
• Complexity. Discovery, association, extensions and the XRDS format were heavy for developers.
• No mobile and API story. OpenID gave websites a login but no standard way to access user data through APIs. OAuth filled this gap, and developers began to combine them.
• Competition. Proprietary social logins offered simpler flows and reached huge user bases.

OpenID Connect, finalised in February 2014, kept the goal and dropped the design. It builds on OAuth 2.0, uses JSON and signed tokens, and gives relying parties standard claims. The history pages Why OpenID faded, From OpenID to OpenID Connect and the OpenID timeline tell the story in detail.

Shutdowns and what remains

Google announced on 21 April 2015 that support for OpenID 2.0, along with several other older authentication methods, had ended and told developers to migrate to OpenID Connect or OAuth 2.0. Stack Exchange removed OpenID login on 25 July 2018, citing very low use. Some services still accept OpenID 2.0 today, with Steam as the most visible example in the gaming world.

Treat any remaining OpenID 2.0 endpoint with caution: libraries are often unmaintained, and the protocol lacks modern protections.

Examples

• Personal URL login. A blogger used their own site as an OpenID and delegated to a provider, so comments on other blogs showed their site.
• Provider login. A user clicked a button for a large provider, and the relying party used identifier select to receive a per-site identifier.
• Steam web login. Third-party sites let you sign in with a Steam account through OpenID 2.0 and receive a Steam ID in return.

Security notes for anyone who still meets it

• Verify the openid.return_to, nonce and signed fields; replay and tampering attacks were common implementation bugs.
• Do not trust unsigned attributes.
• Prefer HTTPS everywhere; early deployments used plain HTTP.
• Plan a migration to OpenID Connect, or to passkeys for user-facing logins.

How does it fit into today’s landscape?

Today’s alternatives are described on the EUDI Wallet overview. The core idea of OpenID, that people should choose who vouches for them and carry that choice between services, has returned in a different form in the wallet model, where you hold the credentials yourself.

Status in October 2026

OpenID 2.0 is a legacy standard that is not maintained for new use. The OpenID Foundation focuses on OpenID Connect and newer work such as OpenID for Verifiable Credentials. We are an independent guide and are not affiliated with the OpenID Foundation.