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).

Relationship between OAuth2, OIDC & SAML

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.

Terminology & definitions

While OAuth2, SAML and OIDC have their similarities, their terminology differs:

SAML	OAuth2	OIDC	Simplified
Service Provider (SP)	Resource Server (RS)	Relying Party (RP)	Service
Identity Provider (IdP)	Authorization Server (AS)	OpenID Provider (OP)	IdP
Principal	Resource Owner (RO)	End-user	End-user

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.

OAuth2 Client types

OAuth2 defines two types of clients in section 2.1. The client types determine which OAuth2 Grants are available.

• 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.

• Public clients are incapable of protecting issued credentials and incapable of secure authentication. In general, clients which runs on the end-users device, for example mobile apps and web pages with JavaScript, are considered to be public clients.

Note: Confidential clients MUST authenticate against the authorization server as dictated in the RFCs section 3.2.1. and section 2.3. Optionally this requirement can be extended to public clients as well.

OAuth2 Grants and OIDC Flows

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.

Other things to add

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.

• Authorization Code with Proof Key for Code Exchange (PKCE) RFC 7636.

• Sender Contraint on Auth0 blog: RFC 8705 and DPoP

SAML