How does OpenID Connect extend the OAuth 2.0 protocol flow, and what are the RP and the OP?
Adding openid to the scope turns the OAuth authorization request into an authentication request; the token response then additionally contains an ID token, and a UserInfo endpoint is added. The OAuth client is called the relying party (RP), the OAuth authorization server the OpenID Provider (OP).
* The OAuth flow stays the same; OIDC adds the openid scope, the ID token and the UserInfo endpoint (green). *
The extensions, in flow order:
- Authentication request: the ordinary authorization request with
scope=openid .... That one scope value activates OIDC. - Authorization grant: unchanged. The user authenticates at the provider (for example with username and password) and consents.
- Grant to the token endpoint: unchanged.
- Tokens: access token (plus optional refresh token) plus the ID token.
- API access: the access token is used at the resource server as before, and at the new UserInfo endpoint to fetch claims about the user.
Terminology: every OAuth 2.0 client that uses OIDC is a relying party (RP) (for example a media service or a third-party portal). Every OAuth 2.0 authorization server that implements OIDC is an OpenID Provider (OP). The service provider typically runs the OP, the UserInfo endpoint and its own resource servers together.
Go deeper:
OpenID Connect Core 1.0: Overview — the abstract OIDC flow between RP and OP.- OpenID Connect Core 1.0: Terminology — the precise definitions of RP, OP, ID token and claims.