Christian's Docs
OAuth2 and OIDC
The content on this page is based on the RFC for OAuth 2.0, RFC 6749, and the specification for OIDC, OpenID Connect Core 1.0. In addition, the RFC-drafts for OAuth 2.1 and OAuth 2.0 Security Best Practice has been taken into account.

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