OpenID Connect (OIDC)

OIDC extends the OAuth 2.0 authorization framework to provide federated identity and authentication. While OAuth 2.0 is designed for delegated access to resources, OIDC adds a standardized way to obtain identity information about the user. It does this by returning a signed ID Token (a JSON Web Token or JWT) containing verifiable claims about the user's identity, such as their email or subject identifier.

The core artifacts of OIDC are the ID Token and the UserInfo endpoint. The ID Token is a cryptographically signed JWT containing standard claims about the authenticated user. For additional user profile information, clients can call the UserInfo endpoint with a valid Access Token. This separation allows for a basic identity assertion (ID Token) and optional, richer profile data (UserInfo).

OIDC defines specific authentication flows (like Authorization Code Flow, Implicit Flow) built on OAuth 2.0 grants. It also introduces standard scopes to request specific identity data. Key scopes include:

• openid: Required for all OIDC requests.
• profile: Requests access to default profile claims.
• email: Requests the user's email address and verification status.
• address: Requests the user's physical address.

OIDC defines clear roles in the authentication process:

• Relying Party (RP): The client application (e.g., a dApp or web service) that needs to verify the user's identity.
• Identity Provider (IdP): The OpenID Provider (OP) or authorization server (e.g., Google, Auth0) that authenticates the user and issues ID Tokens.
• End-User: The individual whose identity is being verified. The RP trusts the IdP's authentication.

A unique OIDC feature is the Self-Issued OpenID Provider (SIOP), which allows an individual to act as their own IdP using a Decentralized Identifier (DID). The user signs the ID Token with a key they control (e.g., from a wallet), enabling decentralized identity and user-centric data control without a centralized authority. This is foundational for Verifiable Credentials and Web3 login patterns.

OIDC relies on public key cryptography for trust. The IdP's public keys are published at a JWKS (JSON Web Key Set) URI. The Relying Party uses these keys to verify the signature on the ID Token, ensuring it was issued by a trusted provider and hasn't been tampered with. This provides non-repudiation and protects against token injection attacks.

The ID Token is a JSON Web Token (JWT) containing verified claims about the authenticated user's identity. It is the primary artifact of OIDC, providing stateless authentication.

• Standard Claims: Includes sub (subject identifier), iss (issuer), aud (audience), and exp (expiration).
• User Info: May contain name, email, and picture.
• Signature: Cryptographically signed by the Identity Provider (IdP) to ensure integrity.

OIDC extends the OAuth 2.0 authorization framework to handle authentication. It uses the same flows (Authorization Code, Implicit) but adds the ID Token.

• Access Token: Grants delegated access to protected resources (APIs), as in standard OAuth.
• Authentication Request: Uses the openid scope to signal OIDC intent.
• Hybrid Flow: Combines ID and Access Tokens in a single response for efficiency.

An OIDC transaction involves three primary roles:

• End-User: The individual whose identity is being verified.
• Relying Party (RP): The client application (e.g., a dApp or web service) requesting authentication.
• OpenID Provider (OP): The identity provider (e.g., Google, Auth0) that authenticates the user and issues tokens.

The OP's configuration is discovered via its OpenID Provider Configuration Document.

A standardized OIDC API endpoint (/userinfo) that returns claims about the authenticated user. It is accessed with a valid Access Token.

• Supplemental Data: While the ID Token contains basic claims, the UserInfo endpoint can provide a more comprehensive user profile.
• Protected Resource: The endpoint itself is a protected OAuth 2.0 resource, ensuring only authorized clients can access the data.
• JSON Response: Returns claims in a JSON object, enabling extensibility.

A protocol allowing clients to register with an OpenID Provider dynamically, without manual configuration. This is essential for decentralized or multi-tenant applications.

• Registration Endpoint: Clients POST a JSON object describing themselves to the OP's /registration endpoint.
• Client Metadata: Includes redirect_uris, grant_types, and response_types.
• Client Credentials: The OP returns a unique client_id and often a client_secret.

OIDC defines a standard flow for identity verification. The key steps are:

• User Authentication: The user authenticates with an OpenID Provider (OP).
• ID Token Issuance: The OP issues a signed JWT (JSON Web Token) called an ID Token containing verified claims about the user.
• Token Response: The Relying Party (RP) receives the ID Token and optionally an Access Token.
• Claims Verification: The RP validates the ID Token's signature and issuer to trust the user's identity.

OIDC introduces two primary artifacts for conveying identity information:

• ID Token: A signed JWT containing standard claims like sub (subject identifier), iss (issuer), aud (audience), and exp (expiration). It is the core proof of authentication.
• UserInfo Endpoint: A protected OAuth 2.0 resource endpoint. An RP can use a valid Access Token to call this endpoint and fetch additional user attributes (e.g., name, email, picture) beyond the base set in the ID Token.

OIDC is not a separate protocol but an extension of OAuth 2.0. It uses OAuth 2.0 flows (Authorization Code, Implicit, etc.) to obtain tokens, then adds identity-specific semantics:

• The openid scope is mandatory to initiate an OIDC request.
• The response includes the ID Token in addition to standard OAuth tokens.
• This allows a single protocol to handle both authorization (OAuth 2.0) and authentication (OIDC).

OIDC is the backbone of modern single sign-on (SSO) and identity federation:

• Enterprise SSO: Employees use corporate credentials (e.g., via Azure AD, Okta) to log into third-party SaaS applications.
• Social Login: "Sign in with Google" or "Log in with Apple" buttons use OIDC to authenticate users and share basic profile data.
• Mobile & Native Apps: Provides a secure, standardized way for apps to authenticate users without handling passwords directly.

While both are identity protocols, OIDC is designed for modern applications:

• Protocol Foundation: OIDC is built on OAuth 2.0 and uses JSON/REST. SAML is XML-based and uses its own SOAP-like messages.
• Token Format: OIDC uses lightweight, self-contained JWTs. SAML uses larger SAML Assertions in XML.
• Use Case Fit: OIDC is optimized for mobile, single-page apps (SPAs), and APIs. SAML is historically dominant in enterprise web SSO. Many identity providers now support both.

Secure OIDC implementation requires adherence to several key practices:

• Token Validation: RPs must always validate the ID Token's signature, iss, aud, and exp claims.
• PKCE (Proof Key for Code Exchange): Essential for public clients (like mobile apps) to prevent authorization code interception attacks.
• Use nonce: Protect against replay attacks by including and checking a unique nonce parameter in authentication requests.
• Secure Storage: Access and Refresh Tokens must be stored securely on the client side, following platform-specific guidelines.

OIDC supports dynamic client registration, allowing dApps to register with an Identity Provider (IdP) on-the-fly. This introduces risks:

• Malicious clients can be registered to phish user credentials.
• Poorly configured IdPs may allow overly permissive redirect URIs, enabling authorization code interception.
• Mitigation requires strict redirect URI validation, use of pre-registered clients, and optional software statements for attested metadata.

The authorization code flow is vulnerable to manipulation of the redirect_uri parameter. Attackers can:

• Substitute a URI they control to intercept the authorization code.
• Exploit open redirectors on the client's domain.
• Best practices include:
  • Exact matching of pre-registered redirect URIs.
  • Using PKCE (Proof Key for Code Exchange) to bind the code to the initial request.
  • Avoiding the use of the implicit flow (fragment-based response).

The Relying Party (RP) or client application must securely manage the authenticated session. Critical aspects are:

• Implementing secure session cookies (HttpOnly, Secure, SameSite attributes).
• Setting appropriate session timeouts and implementing token refresh logic.
• Protecting against Cross-Site Request Forgery (CSRF) during the authorization flow using the state parameter.
• Properly handling logout and token revocation by calling the IdP's end-session endpoint.

For enterprise or regulated DeFi applications, comprehensive logging is essential for security audits and compliance (e.g., GDPR, SOC2). Key logged events should include:

• All authentication and consent events with user/subject identifiers.
• Token issuance and validation failures.
• Admin actions on client registrations.
• Care must be taken to anonymize or pseudonymize logs to protect user privacy while maintaining audit trails.

Single Sign-On (SSO) is an authentication scheme that allows a user to log in with a single set of credentials to access multiple, independent software systems. OIDC is a modern, REST/JSON-friendly protocol used to implement SSO.

• Mechanism: Centralizes authentication at an Identity Provider (IdP).
• User Experience: Eliminates the need for separate passwords for each application.
• OIDC Role: Provides the standardized, API-first method for achieving web and mobile SSO.

An Identity Provider (IdP) is a trusted system that creates, maintains, and manages digital identity information while providing authentication services to relying applications. In OIDC, the IdP is called the OpenID Provider (OP).

• Core Functions: Authenticates users and issues ID Tokens and Access Tokens.
• Examples: Auth0, Okta, Keycloak, and social logins (Google, Microsoft).
• Trust Relationship: Applications (Relying Parties) trust the IdP to verify a user's identity.

In OIDC, a Relying Party (RP) is the client application that relies on the OpenID Provider (OP) to authenticate the end-user. It is the OIDC-specific term for what OAuth 2.0 calls a "client."

• Role: Requests authentication and receives the ID Token from the OP.
• Responsibility: Must validate the ID Token's signature and claims.
• Example: A web or mobile application that uses "Login with Google" is an RP.