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.
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.
The OAuth2 authorization can established in configurations called grants:
Authorization Code Grant
Resource Owner Password Credential Grant*
Client Credential Grant
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
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.
Authorization Code with Proof Key for Code Exchange (PKCE) RFC 7636.