OpenID Connect explained: login on top of OAuth 2.0

OpenID Connect (OIDC) is a standard that lets an application find out who a user is by asking a provider the user already trusts, such as a company directory, Google or a national login service. The user signs in at the provider, and the provider tells the application the result in a signed message. The application never handles the user’s password.

What OpenID Connect is for

Before OIDC, every website kept its own list of usernames and passwords. That meant dozens of passwords, dozens of databases to leak, and dozens of account recovery processes. OIDC moves the login to one place, the OpenID Provider, and lets many applications, called relying parties, rely on it. The same idea powers single sign-on at work and the social login buttons on consumer sites.

OIDC is deliberately small. It adds one thing to OAuth 2.0: a standard way to say “this user was authenticated, here is who they are”. OAuth 2.0 alone only grants access to resources and says nothing about identity. The difference is the subject of OpenID vs OAuth.

Where it comes from

The first OpenID appeared in 2005, and OpenID Authentication 2.0 was approved in December 2007. It was elegant but hard for ordinary users and developers, and big platforms went their own way with proprietary social logins. The OpenID Foundation published OpenID Connect 1.0 in February 2014, built on OAuth 2.0 and JSON Web Tokens, and it became the successor. The story is told in From OpenID to OpenID Connect, and the original protocol is described in OpenID 2.0.

The roles

Role	What it does	Everyday example
End user	Person who wants to sign in	You
Relying party (RP)	The app that wants to know who you are	A news site, a company intranet
OpenID Provider (OP)	Authenticates you and issues tokens	Your employer’s login, Google, a national eID portal

More background on the app side is in What is a relying party?.

How a login works, step by step

The recommended path is the authorisation code flow, protected by PKCE.

1. You click “Sign in” in the app. The app redirects your browser to the provider and asks for the openid scope, usually with profile or email.
2. The provider authenticates you with whatever method it offers: password, passkey, hardware key, or a mobile eID.
3. The provider asks whether you agree to share the requested data with this app.
4. The provider redirects you back to the app with a short-lived authorisation code.
5. The app, from its server, exchanges the code at the provider’s token endpoint and receives an ID token and an access token.
6. The app validates the ID token and creates a session for you. If it needs more data, it can call the UserInfo endpoint.

A simplified authorisation request looks like this:

GET /authorize?response_type=code
  &client_id=shop-app
  &redirect_uri=https://shop.example/callback
  &scope=openid%20email
  &state=af0ifjsldkj
  &nonce=n-0S6_WzA2Mj
  &code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
  &code_challenge_method=S256

The ID token

The ID token is a JSON Web Token (JWT, RFC 7519) signed by the provider. Its payload carries a few standard claims:

{
  "iss": "https://login.example.org",
  "sub": "248289761001",
  "aud": "shop-app",
  "exp": 1790000000,
  "iat": 1789996400,
  "nonce": "n-0S6_WzA2Mj"
}

iss names the provider, sub is a stable identifier for the user at that provider, aud names the app the token is meant for, and nonce ties the token to the original request. The app must check the signature, the issuer, the audience and the expiry before it trusts the token.

Everyday examples

• A university login that works for the library, the learning platform and the mail service.
• A company that lets staff open dozens of cloud tools after one sign-in.
• A shop that offers “Continue with Google” or “Sign in with Apple” (see sign in with Google or Apple).
• A national or municipal portal that accepts a state eID by acting as an OpenID Provider.

Security aspects

• Use the code flow with PKCE. The old implicit flow, which returned tokens in the browser URL, is discouraged in current security guidance such as RFC 9700.
• Check state and nonce. They protect against cross-site request forgery and token replay.
• Match the redirect URI exactly. Loose matching lets attackers steal codes.
• Validate the token fully. Signature, iss, aud, exp and nonce all matter.
• Privacy. The provider learns every app you sign in to. That is the price of centralised login, and a point where the EU wallet’s design differs.
• Provider as single point of failure. If the provider account is lost or compromised, every connected app is affected. Strong sign-in at the provider, ideally a passkey, matters most.

Typical setup mistakes

In practice OIDC integrations rarely fail because of the protocol itself. They fail on small things: a redirect URI that differs by a trailing slash, an unchecked audience in the token, signing keys of the provider that were rotated, or server clocks that are off by minutes. Checking these four points solves most problems quickly.

Status and versions

OpenID Connect Core 1.0 was approved in February 2014 and has since been maintained through corrections (“errata”). The family also includes Discovery (a .well-known/openid-configuration document), Dynamic Client Registration, and logout specifications. All are listed at openid.net/specs. The OpenID Foundation runs a certification programme for implementations. There is no “OIDC 2.0” announced as a replacement; the surrounding OAuth framework is being consolidated as OAuth 2.1, which is still a draft as of October 2026.

How it relates to the other standards

OIDC builds on OAuth 2.0. In large organisations it often runs next to SAML, the older XML-based enterprise standard that solves a similar login problem. The newer OpenID4VP and OpenID4VCI protocols for digital wallets share the OAuth and JWT foundation but solve a different problem: presenting and issuing credentials rather than logging in.

Role in the EUDI Wallet

The EU Digital Identity Wallet is not an OpenID Provider in the classic sense. Its credentials are issued with OpenID4VCI and shown with OpenID4VP, not delivered as ID tokens. OIDC remains relevant around it: many online services will keep OIDC for their own accounts and may put a wallet login in front of an OIDC provider, so users meet both worlds.