From OpenID to OpenID Connect: what changed in 2014

In February 2014 the OpenID Foundation published OpenID Connect 1.0. The name suggests an upgrade, but the protocol was a fresh start. It kept the ideas that had worked in OpenID 2.0 and rebuilt almost everything else, and it is now the technology behind most ‘Sign in with’ buttons.

Why a new protocol, not version 3

By 2010 the problems of OpenID 2.0 were well known: hard for users, awkward for developers, poor on mobile, and weak against phishing. The causes are covered in Why OpenID 2.0 faded. Meanwhile developers had adopted OAuth, a way to let an app access a user’s data at another service without handing over the password. OAuth 2.0 became an IETF standard in 2012. It was designed for access, not login, but developers used it for login anyway, and often did so unsafely.

The OpenID community’s answer was to stop competing with OAuth and build on it. OpenID Connect adds exactly one thing to OAuth 2.0: a standard way to say who has logged in. How that differs from raw OAuth is explained in OpenID vs OAuth.

What was kept

• The two main roles. A provider authenticates the user, and a relying party relies on the result. The vocabulary survived the move.
• Redirect-based login. The user still signs in at the provider, not at the app, so the app never sees the password.
• Discovery and registration ideas. Connect defines a standard way to find a provider’s endpoints and settings, in a simple JSON document, and for apps to register with a provider.

What was replaced

• The user’s identifier. In OpenID 2.0, a user typed a URL or provider name. In Connect, the app shows a button or asks for an email address, and the provider is chosen by the app. This answered the biggest usability complaint.
• The message format. OpenID 2.0 used its own key-value encoding and XRDS documents. Connect uses JSON and signed JSON Web Tokens, which developers already handled well.
• The result. The central result is the ID token, a signed statement from the provider saying who authenticated, when, and for which app. It can be checked without calling the provider again.
• Mobile and API use. Because Connect sits on OAuth 2.0, the same login can give an app an access token for APIs. Native mobile apps and single-page web apps became first-class citizens.

The technical walk-through is in OpenID Connect explained, and the token basics in OAuth 2.0.

What did not carry over

OpenID Connect and OpenID 2.0 do not interoperate. A website that supported OpenID 2.0 had to be rewritten to accept Connect. The foundation published a migration guide, but in practice providers moved on their own schedules. Google, for example, shifted its login to OpenID Connect and retired its OpenID 2.0 endpoint in the following years. The protocol you meet in an app today is almost certainly Connect, which makes the older protocol, described in OpenID 2.0, a historical subject.

Did it fix the problems?

Largely, yes. Users no longer type URLs, mobile apps work, and developers have libraries in every language. Connect has been the standard way for enterprises to do single sign-on and for consumer sites to offer social login.

It did not fix everything. The provider still sees every login. A login still proves only that you control an account, not that you are a certain person. And OpenID Connect depends on a few large providers, which is the issue the wallet tries to address.

Connect and the EU wallet

The EU Digital Identity Wallet does not use OpenID Connect to issue or present credentials. It uses two newer protocols from the same foundation, OpenID4VP for presenting credentials and OpenID4VCI for issuing them, which reuse OAuth 2.0 and JSON building blocks that Connect popularised. The line from the old protocol to the wallet is drawn in From OpenID to the EU wallet. For the larger chronology, see the OpenID timeline.

Dates from the OpenID Foundation and IETF publications; checked October 2026.