OpenID Connect (OIDC)

OIDC enables zero-configuration federation through the OpenID Connect Discovery specification. Providers publish a JSON document at /.well-known/openid-configuration that advertises all required endpoints, supported scopes, response types, and cryptographic keys.

• Metadata Fields: The discovery document includes authorization_endpoint, token_endpoint, userinfo_endpoint, jwks_uri, and issuer.
• Dynamic Client Registration: Clients can programmatically register themselves with the provider by POSTing metadata to the registration_endpoint, receiving a client_id and client_secret in response. This is critical for automating the onboarding of AI development tools and CI/CD pipelines.

OIDC provides mechanisms for managing user sessions across federated applications:

• RP-Initiated Logout: A relying party (RP) can redirect the user's browser to the end_session_endpoint to terminate the session at the OpenID Provider (OP), optionally specifying a post_logout_redirect_uri.
• Session Management: An RP can monitor the user's session state at the OP using a hidden iframe and the check_session_iframe endpoint, enabling single logout across multiple applications.
• Front-Channel Logout: The OP renders iframes for each registered RP to clear local sessions.
• Back-Channel Logout: The OP sends a direct HTTP POST containing a logout token to each RP's registered backchannel_logout_uri, enabling server-side session termination without browser interaction.

The authorization framework upon which OIDC is built. While OIDC handles authentication (who you are), OAuth 2.0 governs delegated authorization (what you can access). In AI contexts, OAuth 2.0 issues access tokens that scoped AI agents use to call enterprise APIs on behalf of users.

• Defines four grant types: authorization code, client credentials, implicit, resource owner password
• Issues bearer tokens with configurable scopes and lifetimes
• Enables third-party AI services to act without exposing user credentials

The token format that OIDC uses to transmit identity claims. An ID Token is a JWT containing user profile information signed by the identity provider. AI gateways validate JWT signatures to establish trust without querying the authorization server on every request.

• Three-part structure: header, payload, signature
• Claims include sub, iss, aud, exp, and iat
• Supports RS256 and ES256 asymmetric signing algorithms for distributed verification

The XML-based predecessor to OIDC for enterprise single sign-on. SAML remains prevalent in legacy corporate identity providers but lacks the API-friendly JSON structure that makes OIDC ideal for modern AI development platforms and microservices architectures.

• Uses XML assertions instead of JSON tokens
• Typically browser-profile focused with POST bindings
• Often bridged to OIDC via identity provider translation layers

A complementary standard that enables real-time session revocation based on critical events. While OIDC establishes identity at login, CAEP terminates access instantly when risk conditions change—essential for protecting AI training data from compromised sessions.

• Part of the Shared Signals and Events (SSE) framework
• Pushes security events rather than requiring polling
• Integrates with OIDC sessions to enforce just-in-time revocation

A phishing-resistant authentication standard that eliminates shared secrets. FIDO2 uses public-key cryptography with hardware-bound credentials, providing the strong user verification that OIDC identity providers can require before issuing tokens for sensitive AI infrastructure access.

• WebAuthn browser API + CTAP protocol for external authenticators
• Private keys never leave the user's device
• Counters signature replay attacks that could compromise OIDC flows

A protocol mechanism defined in RFC 7662 that allows resource servers to query the authorization server about a token's current state. AI API gateways use introspection to validate that an OIDC-derived access token is still active and has not been revoked before permitting data retrieval.

• Returns token metadata: active status, scope, client_id, expiry
• Prevents reliance on stale cached token state
• Critical for enforcing real-time revocation in zero-trust architectures