SSOGEN / Learn / What Is OpenID Connect? The ID Token, Scopes and Flows

Learn

What Is OpenID Connect? The ID Token, Scopes and Flows

OpenID Connect adds a sign-in layer to OAuth 2.0, so an application learns who a person is through a signed ID token.

Updated Oct 8, 2026

The three pieces OIDC adds to OAuth 2.0.

What is OpenID Connect? OpenID Connect, usually shortened to OIDC, is a standard that lets an application verify who a user is and obtain basic profile information. The OpenID Connect Core 1.0 specification calls it a simple identity layer on top of the OAuth 2.0 protocol.

OAuth 2.0 grants an application access to a resource but does not say who signed in. OIDC adds that piece: a signed statement of the user’s identity, called the ID token.

If you are choosing between the two, read OIDC vs OAuth.

OpenID Connect sign-in with PKCE

The roles

OIDC reuses OAuth’s vocabulary and renames two of its parties:

Client. The application, also called the relying party (RP).
OpenID provider. The system that authenticates the user (OP): the OAuth authorization server with extra duties.
End user. The person signing in.

Your organization’s identity provider, Microsoft Entra ID or SSOGEN can each act as the OP.

The ID token

The ID token is a JSON Web Token (JWT): three base64url sections separated by dots.

The middle section holds the claims, and the last holds the provider’s signature. Core section 2 requires these claims in every ID token.

Claim	Meaning	Acme Corp example
`iss`	The issuer: who created the token	`https://sso.acme.example`
`sub`	A stable identifier for the person at this issuer	`u_8f21c4`
`aud`	The client the token is for; must contain the client ID	`acme-wiki`
`exp`	When the token expires	Unix time
`iat`	When it was issued	Unix time

Other claims are optional but common:

nonce. Ties the token to the request that started the sign-in.
auth_time and acr. auth_time records when the user actually authenticated, and acr how strongly.
email and name. Released when the client requests the matching scopes.

Decoded, an ID token for Maria Lopez looks like this.

{
  "iss": "https://sso.acme.example",
  "sub": "u_8f21c4",
  "aud": "acme-wiki",
  "exp": 1791471600,
  "iat": 1791471300,
  "nonce": "n-0S6_WzA2Mj",
  "email": "maria.lopez@acme.example",
  "name": "Maria Lopez"
}

Use sub, scoped to iss, as the user’s identity. Email addresses and names change; sub does not.

Scopes

Scopes tell the provider what the client is asking for. openid is mandatory: without it the request is plain OAuth and no ID token is returned. The specification also defines:

profile, email, address and phone. Each of these releases a group of claims.
offline_access. Requests a refresh token.

Request only the scopes the application uses. The client can also fetch the claims for a scope from the UserInfo endpoint with the access token.

The flows

Core defines three ways to obtain tokens. They differ in which tokens the authorization endpoint returns and which the token endpoint returns.

Flow	Tokens delivered	Today
Authorization code (Core section 3.1)	Code from the authorization endpoint; ID and access tokens from the token endpoint	The one to use, with PKCE
Implicit (section 3.2)	All tokens straight from the authorization endpoint	OAuth security guidance, RFC 9700 section 2.1.2, says clients should not use flows that put access tokens in the authorization response
Hybrid (section 3.3)	Some tokens from each	Rare

The authorization code flow runs in three steps:

The client redirects the user to the provider with its client_id, redirect_uri, scope and a nonce.
The provider authenticates the user and redirects back with a short-lived code.
The client’s server redeems the code at the token endpoint and receives the ID token and an access token.

Discovery

Endpoint addresses are rarely entered by hand.

A provider that supports OpenID Connect Discovery publishes a JSON document at the issuer address plus /.well-known/openid-configuration. The document lists:

Endpoints. The issuer, authorization_endpoint and token_endpoint.
Keys. The jwks_uri, which holds the public keys for checking signatures.
Support. The supported scopes and algorithms.

The specification requires the issuer in that document to be identical to the address it was fetched from. This prevents one provider from impersonating another.

What the client must check

Before trusting an ID token, the client must verify five things (Core section 3.1.3.7):

Signature. It matches the provider’s keys.
iss. It is the expected issuer.
aud. It contains the client’s own client ID.
exp. It has not passed.
nonce. It equals the value the client sent.

A standard OIDC library performs these checks.

The common mistakes come from bypassing it:

Accepting a token without checking aud, so a token issued to another application works.
Reusing one nonce or not sending one.
Using email instead of sub as the account key.
Expecting email_verified when the provider does not assert it.
Redirect URIs that differ by a trailing slash from the registered value.

How SSOGEN handles OIDC

As an OpenID provider, SSOGEN serves its discovery document at /.well-known/openid-configuration. It registers each application with a client ID and exact https:// redirect addresses, matched character for character with no wildcards.

Flow. The authorization code flow only, with PKCE using the S256 method required on every sign-in. There is no implicit or hybrid flow.
Scopes. SSOGEN honors openid, profile and email.
Email. SSOGEN never sends email_verified, because it does not verify addresses itself.
New applications. A new application is a public client that proves itself with PKCE.
Web applications. Web applications with a server can add a client secret or key.
Service applications. Programs with no person present register as service applications that use client credentials.
Token lifetime. Access tokens for a sign-in are short-lived: a person’s access token lasts 60 seconds.

Questions people ask

Is OpenID Connect the same as OAuth?

No. OIDC is built on OAuth 2.0 and adds the ID token and a standard way to ask who signed in.

Can OIDC be used for SSO?

Yes. Several applications can trust one OpenID provider, so one sign-in opens them all.

Is OIDC the same as the old OpenID?

No. OpenID Connect is a different protocol that shares its name with earlier OpenID versions.

Does OIDC need a client secret?

Not always. Public clients such as single-page and mobile applications use PKCE with no secret.

Where to go next

SSOGEN as a provider. SSOGEN as an OpenID Connect provider is described in OpenID Connect provider.
Related concepts. Compare OIDC vs OAuth or read what is OAuth 2.0.
Connect an application. See register an OpenID Connect application, and choose how to connect an application if SAML might fit better.
The wider picture. Start with what is SSO.
A nonce or state value. Make one with the random string generator.

Sources, all read 2026-10-09: OpenID Connect Core 1.0, OpenID Connect Discovery 1.0, RFC 9700.