Identity & access management · Social login · 4 min read
OpenID to OpenID Connect: What Changed and Why It Matters
Short answer
OpenID Connect replaced OpenID 2.0 by building identity on top of OAuth 2.0: instead of XML-free but custom redirect messages and URL-based identifiers, it returns a signed JWT ID token, uses standard discovery and works for web, mobile and API clients alike.
Key takeaways
- OpenID Connect Core 1.0 was finalized by the OpenID Foundation in February 2014 and was published as ISO/IEC 26131 in 2024.
- The ID token is a JWT with iss, sub, aud, exp, iat and, when requested, nonce; clients must validate all of them.
- OpenID 2.0 is obsolete; major providers shut down their OpenID 2.0 endpoints years ago.
In 2011, OpenID meant OpenID 2.0: a decentralized protocol in which you could sign in to a site by typing a URL that represented you. The ideas were good and adoption was real, but developers found it fiddly, and it did not fit mobile apps or APIs. The successor, OpenID Connect, kept the name and the goal and changed nearly everything else.
What was OpenID 2.0?
OpenID 2.0, finalized in 2007, let a user prove control of an identifier URL by redirecting through their OpenID provider, which returned a signed assertion in URL parameters.
A site using OpenID 2.0 had to perform discovery on the user's URL (via Yadis or HTML link tags), set up an association with the provider using a Diffie-Hellman exchange, redirect the user, and check a signature over a set of openid.* parameters. Attribute exchange was a separate extension. Each piece worked, but the total was a lot of custom code, and libraries varied in quality.
Large providers supported it for a while and then retired their OpenID 2.0 endpoints in favor of OpenID Connect. Today you will meet OpenID 2.0 only in old systems and history lessons.
What does OpenID Connect do differently?
OpenID Connect is a thin identity layer on OAuth 2.0: the client asks for the openid scope and receives an ID token, a signed JWT that says who signed in.
The main changes:
- Built on OAuth 2.0. The same authorization endpoint, token endpoint and flows developers already used for APIs.
- JWT ID tokens. Claims such as
iss,sub,aud,exp,iat,auth_timeandnonce, signed with keys published at ajwks_uri. - Discovery. A JSON document at
/.well-known/openid-configurationlists endpoints, supported algorithms and scopes. - UserInfo endpoint. A simple REST call returns profile claims.
- Works everywhere. Server-side web apps, single-page apps, native mobile apps and devices without browsers all have a defined way to use it.
The core specification was finalized in February 2014. In 2024 it was also published as an international standard, ISO/IEC 26131, along with related OpenID Connect specifications.
What must a client check in an ID token?
At minimum: the signature, that iss is the expected issuer, that aud contains your client ID, that exp is in the future, and that nonce matches the value you sent.
| Claim | Meaning | Check |
|---|---|---|
iss |
Issuer | Exact match with the provider's issuer |
sub |
Subject | Store with iss as the account key |
aud |
Audience | Must contain your client_id |
exp |
Expiry | Must be in the future |
iat |
Issued at | Sanity check against your clock |
nonce |
Replay protection | Must equal what you sent |
azp |
Authorized party | Must be your client if present with multiple audiences |
Use a maintained library; do not hand-roll the checks. To see what a provider actually returns, decode a test token in the JWT Decoder.
How do I build an OpenID Connect sign-in request?
Send the browser to the authorization endpoint with response_type=code, your client_id, a registered redirect_uri, scope=openid plus any profile scopes, a random state, a nonce and a PKCE code_challenge.
The Authorization URL Builder assembles that URL and flags missing pieces, such as a nonce on a flow that returns an ID token from the authorization endpoint. After the redirect, the client exchanges the code at the token endpoint with its PKCE verifier and receives the ID token.
Can I migrate users from OpenID 2.0 identifiers?
Yes. The OpenID Foundation published a migration specification so a provider can return the old OpenID 2.0 identifier alongside the new sub, letting relying parties link accounts.
If you still have a user table keyed on OpenID 2.0 URLs, that specification is the documented path. Otherwise, link accounts on a verified email address with care, since an email address alone is a weaker key than issuer plus subject. Our social login guide covers account linking in more detail.
Questions
Is OpenID Connect the same as OAuth?
No. OAuth 2.0 is for authorization: getting an access token to call an API. OpenID Connect adds authentication on top, with the ID token and the UserInfo endpoint, so a client can learn who the user is.
Do I need the openid scope?
Yes. Including openid in the scope parameter is what turns an OAuth authorization request into an OpenID Connect request. Without it, you get no ID token.
What happened to OpenID URLs as identifiers?
OpenID 2.0 let users type a URL that identified them. OpenID Connect dropped that in practice; users pick a provider, and the stable identifier is the pair of issuer and sub claim.
Sources
Tagged: OpenID Connect, OpenID, OAuth, Identity, Single sign-on, Social networking