OpenID Connect
An identity authentication layer built on top of OAuth 2.0 that introduces an ID Token in JWT format to prove user identity to the client. It is widely used in single sign-on and federated identity authentication scenarios.
Core Facts
JWT (JSON Web Token) is an open standard (RFC 7519).
OpenID Connect is an identity layer built on top of OAuth 2.0 that introduces an ID Token, typically in JWT format, for proving user identity to the client.
OAuth 2.0专门处理授权委托，OpenID Connect在OAuth 2.0之上叠加身份验证层，SAML多用于企业联邦身份场景
Timeline (last 90 days)
Traditional identity providers (IdPs) are designed for human users and rely on mechanisms such as account passwords and multi-factor authentication, with common standards including SAML, OAuth 2.0 and OpenID Connect.
At the protocol level, SSO usually relies on standards such as SAML 2.0, OpenID Connect (OIDC), or CAS.
Identity provider (IdP) registration is usually based on the OAuth 2.0 or OpenID Connect protocol, with AWS as the service provider trusting these identity sources.
The reason EMA can consolidate authorization into the IdP is the premise that the enterprise has already unified employee identities with an IdP; after an application integrates with the IdP, user login follows the SAML or OpenID Connect standard, with identity assertions issued by the IdP.
In OIDC, email is merely an attribute declared by the provider and may be unverified; email_verified indicates that the provider has confirmed that the email is controlled by the current user, while sub or provider_user_id is the stable and hard-to-forge identity identifier.
JalOS's GitHub Actions workflow obtains short-lived AWS temporary credentials via OpenID Connect (OIDC) rather than storing long-term access keys.
OIDC is an authentication protocol based on OAuth 2.0 that, in CI/CD contexts, can request temporary credentials typically valid for 15 minutes to 1 hour; these credentials are bound to a specific repository, branch, and workflow, expire after use, and are recommended by both AWS and GitHub as a production-grade credential management approach.
OAuth 2.0 and OpenID Connect (OIDC) are based on JSON and JWT, have a smaller protocol surface area, a clearer binding relationship between signatures and data, and a smaller attack surface than SAML.
The white paper advocates extending mature protocols such as OAuth 2.0 and OpenID Connect to adapt to agent scenarios, rather than overturning existing standards.
The identity federation space experienced competition among SAML, OpenID, and WS-Federation, with OpenID Connect ultimately prevailing in consumer internet scenarios and SAML continuing in enterprise scenarios.
20 more timeline events
All Facts (20)
JWT (JSON Web Token) is an open standard (RFC 7519).
80%VerifiedOpenID Connect is an identity layer built on top of OAuth 2.0 that introduces an ID Token, typically in JWT format, for proving user identity to the client.
75%VerifiedOAuth 2.0专门处理授权委托，OpenID Connect在OAuth 2.0之上叠加身份验证层，SAML多用于企业联邦身份场景
65%UnverifiedCommon SSO implementation protocols include SAML 2.0, OAuth 2.0, and OpenID Connect (OIDC).
60%UnverifiedTraditional identity providers (IdPs) are designed for human users and rely on mechanisms such as account passwords and multi-factor authentication, with common standards including SAML, OAuth 2.0 and OpenID Connect.
50%UnverifiedAt the protocol level, SSO usually relies on standards such as SAML 2.0, OpenID Connect (OIDC), or CAS.
50%UnverifiedIdentity provider (IdP) registration is usually based on the OAuth 2.0 or OpenID Connect protocol, with AWS as the service provider trusting these identity sources.
50%UnverifiedThe reason EMA can consolidate authorization into the IdP is the premise that the enterprise has already unified employee identities with an IdP; after an application integrates with the IdP, user login follows the SAML or OpenID Connect standard, with identity assertions issued by the IdP.
50%UnverifiedIn OIDC, email is merely an attribute declared by the provider and may be unverified; email_verified indicates that the provider has confirmed that the email is controlled by the current user, while sub or provider_user_id is the stable and hard-to-forge identity identifier.
50%UnverifiedOIDC is an authentication protocol based on OAuth 2.0 that, in CI/CD contexts, can request temporary credentials typically valid for 15 minutes to 1 hour; these credentials are bound to a specific repository, branch, and workflow, expire after use, and are recommended by both AWS and GitHub as a production-grade credential management approach.
50%UnverifiedJalOS's GitHub Actions workflow obtains short-lived AWS temporary credentials via OpenID Connect (OIDC) rather than storing long-term access keys.
50%UnverifiedOAuth 2.0 and OpenID Connect (OIDC) are based on JSON and JWT, have a smaller protocol surface area, a clearer binding relationship between signatures and data, and a smaller attack surface than SAML.
50%UnverifiedThe white paper advocates extending mature protocols such as OAuth 2.0 and OpenID Connect to adapt to agent scenarios, rather than overturning existing standards.
50%UnverifiedThe identity federation space experienced competition among SAML, OpenID, and WS-Federation, with OpenID Connect ultimately prevailing in consumer internet scenarios and SAML continuing in enterprise scenarios.
50%UnverifiedIn recent years, the industry has increasingly favored adopting JSON-based OAuth 2.0 and OpenID Connect (OIDC) as identity authentication and authorization solutions.
50%UnverifiedStandard protocols such as OIDC do not impose mandatory specifications for multi-tenant scenarios, and implementations vary considerably across platforms.
50%UnverifiedBoth OAuth and OpenID Connect assume that the MCP client has already been registered with the server or authorization server.
50%UnverifiedSigstore is an open-source project backed by the Linux Foundation, designed to provide a keyless signing mechanism for software packages based on OpenID Connect.
50%UnverifiedDespite all identity providers claiming to comply with OIDC specifications, significant differences exist in actual implementations.
50%UnverifiedThe OIDC specification leaves room for interpretation on certain details, and different providers interpret them differently based on their own technical architecture and security considerations.
50%