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.

Relationship between OAuth2, OIDC & SAML

OAuth2 handles authorization only. Becuase of this OIDC was created with the intent of adding standardized authentication on top of OAuth2.
Becuase of this, only OIDC is comparable to SAML. While SAML-tickets are based on XML, OIDC-tickets are based on JSON. In addition SAML is written specifically for usage in a web browser by performing refirects 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:
Service Provider (SP)
Resource Server (RS)
Relying Party (RP)
Identity Provider (IdP)
Authorization Server (AS)
OpenID Provider (OP)
Resource Owner (RO)
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: Grants 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 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 reccomended 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.