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:

SAML

OAuth2

OIDC

Service Provider (SP)

Resource Server (RS)

Relying Party (RP)

Identity Provider (IdP)

Authorization Server (AS)

OpenID Provider (OP)

User-Agent

Client

User-Agent

Principal

Resource Owner (RO)

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