Comment on page
OAuth2 and OIDC
The content on this page is based on the RFC for OAuth 2.0 (RFC 6749), the specification for OAuth 2.0 PKCE (RFC 7636) and the specification for OIDC, OpenID Connect Core 1.0. In addition, the RFC-drafts for OAuth 2.1 and OAuth 2.0 Security BCP has been taken into account as well as documentation from www.oauth.com (1, 2).
OAuth2 is not an authentication protocol. Instead it is a protocol for delegating access through authorization.
OIDC adds an authentication layer on top of OAuth2 by introducing an additional ID token. Because of this, only OIDC is comparable to SAML.
The structure of the tickets also differs:
- SAML-tickets must be in XML,
- The ID-token in OIDC must be a JWT.
- The Access and Refresh Tokens from OAuth2 can () be a JWT
In addition SAML is written specifically for usage in a web browser by performing redirects using pre-populated HTML-forms while OIDC is more agnostic, making it more compatible with native apps.
While OAuth2, SAML and OIDC have their similarities, their terminology differs:
The terms have the following definitions:
- SP/RS/RP: Validates the access token and accepts/rejects the client's request to the resource.
- IdP/AS/OP: Issues tokens. Note that AS in OAuth2 does not issue identities. Only IdP and OP provides authentication as a service.
- User-agent/Client: Requests the access token in order to access the resource server.
- Principal/RO/End-user: Is granted permission to access the resource server with an access token.
- Confidential clients are capable of maintaining confidentiallity of issued credentials and capable of stablishing a secure client authentication. In general, confidential clients are only applications running on secure web servers.
The OAuth2 authorization can established in configurations called grants:
- Authorization Code Grant
- Implicit Grant*
- Resource Owner Password Credential Grant*
- Client Credential Grant
According to the RFC (see section 1.2), Authorization Code Grant is the preferred and most common method of obtaining an authorization grant.
Warning: In order to protect against authroization code injections, PKCE (defined in RFC 7636) is recommended for all client types.
Note (*): Both Implicit Grant and Resource Owner Password Credential Grant has been deprecated in the OAuth 2.1 draft.
While any grant defined in the OAuth2 can configured to be used with OIDC, only the following flows are part of the OIDC Core specification.
- Authorization Code Flow
- Implicit Flow
- Hybrid Flow
As such, usage of any other grant type from the OAuth2 RFC is actually a deviation from the OIDC specification.
OIDC adds an additional token called an ID token and standardizes areas that OAuth 2.0 leaves up to choice, such as scopes, endpoint discovery, and dynamic registration of clients.