What is OIDC and How Does It Work?

OpenID Connect (OIDC) is a protocol built on top of OAuth 2.0 to delegate authentication in a REST-like manner.

If OAuth is about authorization (what an entity can access), OIDC is about who they are.

In practice, OIDC provides a standardized way to implement single sign-on (SSO), which allows users to verify their identity across multiple platforms with a single account. It specifies an authentication flow and defines how identity providers share end-user verifiable information elements (called claims).

Let’s see how OIDC works internally.

How Does OIDC Work?

OIDC is an expanded OAuth workflow:

• Between an end-user, acting as the OAuth resource owner.
• A service acting as the OAuth client that wants to authenticate the end user.
• An identity provider, often called an OpenID Provider or OP,  acts as the OAuth authorization server. It authenticates the user on behalf of the service and provides tokens to access the user’s identity information.
• The protected resource is the identity provider’s API serving the user’s identity claims.

Simplified, OIDC works like this:

As an expansion to OAuth, the client receives an ID token alongside the OAuth access token. This ID token contains some user information and is both issued and signed by the identity provider. The client can use the access token on the identity provider’s API to retrieve more identity claims.

It’s worth noting that OIDC does not replace OAuth, as it focuses only on user authentication. If an OAuth authorization server uses OIDC to authenticate a user, this usually takes place in a secondary flow between the authorization server and the identity provider.

To learn more about OAuth, check “What is OAuth and how does it work?”

Also consider checking “OAuth vs. OIDC: What’s the Difference and When Should You Use Each?”

Now that we’ve covered the basics, let’s discuss OIDC in more detail.

What Are OIDC Identity Providers?

As we’ve seen, OIDC identity providers are the entity that:

• Verifies a user’s identity at the request of a client service.
• Provides identity claims via signed identity tokens and a standard API.

Think of the “Sign in with…” and “SSO” buttons available on websites.

Most consumer-oriented identity providers, like Google and Apple, offer a basic service that lets users log in to third-party services with their provider accounts.

However, in the corporate world, identity providers like Okta also allow IT departments to centralize employee access to services and manage application access and assignments.

OIDC is widely used for modern web and cloud application sign-on.

What Are OIDC ID Tokens?

OIDC ID tokens are JSON web tokens (JWTs) with important information about the user.

The following is a minimal example payload for an ID token, composed of several “claims”:

{
"iss": "http://server.example.com",
"sub": "248289761001",
"aud": "s6BhdRkqt3",
"nonce": "n-0S6_WzA2Mj",
"exp": 1311281970,
"iat": 1311280970
}

Let’s see the meaning of each field:

• iss: Issuer Identifier, a URL of the entity that issued and signed this particular ID token.
• sub: Subject, a unique identifier for the end-user. 
• aud: Audience, a string identifying the service requesting the claims. It must contain the service’s OAuth client_id.
• nonce: a random string generated by the client and returned for verification.
• exp: expiration time, a timestamp indicating when the token is no longer accepted.
• iat: issued at, a timestamp indicating when the token was issued.

ID tokens can contain additional claims about the user. There is a list of standard claims for information like the user’s name, email, phone number, and more.

Taking one step back, OIDC ID tokens are sent to the clients alongside an OAuth access token. Identity Providers usually send them to clients within the id_token field:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "access_token": "SlAV32hkKG",
  "token_type": "Bearer",
  "refresh_token": "8xLOxBtZp8",
  "expires_in": 3600,
  "id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzcyI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZfV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5NzAKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6qJp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJNqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7TpdQyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoSK5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"
}

JWTs encode their payload in base64url along with a header and a signature:

The client can use the sub field from the id_token to identify the user.

Clients may also want some extra data to fill the user’s profile. They can use the rest of the access token to retrieve this information from the /userinfo endpoint on the identity provider.

They can use the access token to retrieve this information from the /userinfo endpoint on the identity provider.” 

It’s important to note that the id_token is meant to be consumed by the client and shouldn’t be sent back to the provider, nor shared with other services.

How Does OIDC Authenticate Using an Authorization Code Flow?

Now that we’ve explained how user data is shared with the client, let’s cover the steps OIDC follows to perform authentication using OAuth’s authorization code flow. 

OIDC also defines implicit and hybrid flows, though modern applications generally favor the authorization code flow.

1-4 Authenticating and Consenting

The user starts the flow by requesting authentication from the client. (Step 1)

The client application then redirects the user to the Identity Provider (aka OpenID Provider) authorization endpoint. (Steps 2 and 3)

In the Authenticate screen (Login), the user enters their credentials and sends them to the Identity Provider. The client should never see this data. (Step 4)

When the client redirected to the Identity Provider endpoint in step 2, it provided some key parameters:

• client_id: A unique identifier of the application requesting access.
• redirect_uri: Where to redirect the user’s browser once the authentication process is complete.
• scopes: What areas of the user’s info the client wants to access. The standard scopes for the OIDC userinfo endpoint are: openid, profile, email, address, and phone.
• nonce: a random value that will later be embedded in the returned ID token to prevent replay attacks.
• state: As an anti-tampering measure (against CSRF), the client sends a random string that the authentication server will communicate back. If it matches, the client will know it’s him who requested access.

5-7 Obtaining the Token

The flow continues as in a regular OAuth flow, where the identity provider redirects the user’s browser to the client with an auth_code, which the client will exchange for an access token. (Step 5)

Then, the client sends back the auth_code along with its client_secret, kind of like the client’s password. (Step 6).

The authentication server checks that the auth_code matches the one sent in step 5 and that the client_secret is correct, then generates and sends the access token. (Step 7)

What OIDC adds over OAuth 2.0 in this step is that the access token response also includes an id_token field containing a JWT with the identity claims, as we saw before.

Once the client receives the ID token, it validates that:

• iss matches the Identity Provider.
• exp timestamp is in the future.
• nonce matches the string sent in the first steps.

The client must also validate the JWT’s signature.

8-10 Retrieving the User Info

The sub field in the ID token is enough to identify the user.

However, the client may want to retrieve extra data. For example, a name and a picture to fill the user’s profile on first access.

If this information is not available in the ID token received at step 7, the client can request additional information stored in the identity provider by calling the /userinfo endpoint.

Note that this call is done from the client and uses the access token, not the ID token. (Step 8)

GET /userinfo HTTP/1.1
Host: server.aembit.com
Authorization: Bearer <access token>
…

Which returns a JSON object with additional claims:  (Step 9)

{
  "sub": "37272",
  "name": "Michel Grant",
  "email": "mgrant@example.com",
  "birthdate": "1981-11-08"
}

Finally, the client returns a page to the user. For example, the app’s home page, or the specific page the user was trying to access. (Step 10).

OIDC for Agentic Entities

Agents are AI-based systems capable of making decisions, adapting to situations, and acting autonomously and independently. As such, agents also need mechanisms to establish identity and obtain authorized access to resources. 

But the original design for authentication flows was intended for human entities. The standard OIDC Authorization Code Flow expects a human in the loop; that’s why it involves a redirect and a credentials screen. Take into account that, since OIDC is built on top of OAuth, many of the problems with agentic entities in OAuth apply here as well.

For this purpose, OpenID Connect for Agents (OIDC-A) is a recent proposal to extend identity and authentication for LLM-based agents, featuring:

• Agentic Identity Claims: with ID tokens in JWT similar to those in humans, with fields like agent_type and agent_model.
• Delegation chain: when we want to send an ID and authorization from one agent to another (multi-hop), OIDC-A records the delegation chain so all hops can be traced.
• Agent Attestation: To prove the agent is behaving properly, attestation data can indicate their integrity and trustworthiness.

Learn More About OIDC

If you want to keep learning about OIDC, you can check the following articles from the Aembit blog:

• OAuth vs. OIDC: What’s the Difference and When Should You Use Each?
• How to create an OIDC 1.0 Identity Provider | DOCS
• About the OIDC ID Token Credential Provider | DOCS

Additionally, you can check the following links from external sites:

• How OpenID Connect Works
• RFC 6749 – The OAuth 2.0 Authorization Framework
• Identity Management for Agentic AI
• OpenID Connect for Agents (OIDC-A) 1.0: A Standard Extension for LLM-Based Agent Identity and Authorization