OpenID Connect (OIDC)

is an extension of Open Authorization (OAuth) adding delegated authentication (i.e. allowing Client application(s) to obtain a Resource Owner’s information)
is not backward compatible with OpenID 2 (or 1 for that matter). OpenID Connect is effectively version 3 of the OpenID specification

OIDC Entities

Click here to expand...

authentication/authorization/delegation entities/actors:

Entity/Actor

Description

Resource Owner (RO)

End-User

Principal

the entity that is in control of the data exposed by the API, typically an end-user

Client

Relying-Party (RP)

the mobile app, website, etc. that wants to access data on behalf of the Resource Owner

Authorization/OAuth Server/Service (AS)

Identity-Provider (IdP)

OpenID Provider

a combination or sometimes a separation of:

Authentication Server - deals with authenticating the End-User

Security Token Service (STS) or Token Endpoint - issues tokens (e.g. Access Tokens, Refresh Tokens, ID Tokens)

Resource/UserInfo Server/Provider (RS)

Service-Provider (SP)

the service/application/resource:

that exposes the protected resource/API and requires authentication/authorization of any principal wishing to access it

agrees to trust the Identity-Provider to authenticateClient

NOTE: This 1 of many Grant Flows (above portrays Implicit Flow of OAuth & OpenID Connect)

Link to original

Entity/Actor	Description
Resource Owner (RO) End-User Principal	the entity that is in control of the data exposed by the API, typically an end-user
Client Relying-Party (RP)	the mobile app, website, etc. that wants to access data on behalf of the Resource Owner
Authorization/OAuth Server/Service (AS) Identity-Provider (IdP) OpenID Provider	a combination or sometimes a separation of: Authentication Server - deals with authenticating the End-User Security Token Service (STS) or Token Endpoint - issues tokens (e.g. Access Tokens, Refresh Tokens, ID Tokens)
Resource/UserInfo Server/Provider (RS) Service-Provider (SP)	the service/application/resource: that exposes the protected resource/API and requires authentication/authorization of any principal wishing to access it agrees to trust the Identity-Provider to authenticateClient

OIDC Terms

Terms	Description
Claim	a piece of information asserted about an entity OIDC defines a number of standard claims e.g. the name claim represents an End-User’s full name in displayable format
Scope	a collection of claims OIDC defines a number of standard scopes that a Relying Party can request about an authentication event or End-User. For example, the profile scope contains claims such as: name, family_name, given_name, etc
Access Token	intended for the Client to make protected calls to the Resource Holder on behalf of the Resource Owner
Refresh Token	intended for the Client to obtain a new Access Token from the Security Token Service (STS)
ID Token	intended for the Client to know about the Resource Owner Unlike Access Tokens and Refresh Tokens that are opaque to the client, ID Tokens contains information about the resource owner for the client introduced in OpenID Connect (OIDC)
UserInfo	is the Resource Holder, in which a request presented with a valid Access Token would be consumed

OIDC Flows

OpenID Connect defines different types of authentication flow to cater to different Client types

Flow

Description

Token Flow (Implicit Flow)

front-channel only (less secure)

required for client apps that have no “back end” logic on the web server, like a Javascript app

OAuth 2.0 flow in which all tokens (e.g. Access Token, Refresh Token, ID Token) are returned from the Authorization Endpoint, and neither the Token Endpoint nor an Authorization Code are used

Code Flow (Authentication Code Flow)

front-channel and back-channel (more secure)

designed for client apps that have a back end that can communicate with the IdP away from prying eyes

OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint and all tokens (e.g. Access Token, Refresh Token, ID Token) is returned from the Token Endpoint

Hybrid Flow

OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint

Link to original

／var／log marcus chiu

Explorer

OpenID Connect (OIDC)

OpenID Connect (OIDC)

OIDC Entities

OIDC Terms

OIDC Flows

Flow	Description
Token Flow (Implicit Flow)	front-channel only (less secure) required for client apps that have no “back end” logic on the web server, like a Javascript app OAuth 2.0 flow in which all tokens (e.g. Access Token, Refresh Token, ID Token) are returned from the Authorization Endpoint, and neither the Token Endpoint nor an Authorization Code are used
Code Flow (Authentication Code Flow)	front-channel and back-channel (more secure) designed for client apps that have a back end that can communicate with the IdP away from prying eyes OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint and all tokens (e.g. Access Token, Refresh Token, ID Token) is returned from the Token Endpoint
Hybrid Flow	OAuth 2.0 flow in which an Authorization Code is returned from the Authorization Endpoint, some tokens are returned from the Authorization Endpoint, and others are returned from the Token Endpoint

／var／logmarcus chiu

Explorer

OpenID Connect (OIDC)

OpenID Connect (OIDC)

OIDC Entities

OIDC Terms

OIDC Flows

／var／log marcus chiu