OIDC is an authentication layer based on OAuth2, so that the client knows the authorized End User, and provides a user’s authentication information Id Token while the client gets access_token. Widely used in microservices, open platforms, SSO, three-party login authorization and other scenarios.

OIDC key terms

  1. EU Abbreviation for End User, which refers to an end user.
  2. RP Abbreviation for Relying Party, which refers to the trusted client in OAuth2, the consumer of authentication and authorization information.
  3. OP Abbreviation for OpenID Provider, which refers to a service that has the ability to provide EU authentication (such as the authorization service in OAuth2) and is used to provide EU authentication information to the RP.

For other terms, see the list of OIDC terms.

OIDC Protocol Cluster

OIDC contains a number of specifications, the smallest of which is OIDC Core, the diagram below is an older one and is a bit out of date, but it will help you understand OIDC to some extent.

OIDC Protocol Cluster

  • Core OIDC Core, defines the core process of OIDC, how to authenticate on OAuth 2.0 and use declarations to communicate information about the end user (EU).
  • Discovery defines how clients can dynamically discover information about OpenID Providers (OPs).
  • Dynamic Registration Defines how a client can dynamically register to an OpenID provider.
  • OAuth 2.0 Multiple Response Types defines several specific new OAuth 2.0 response types.
  • OAuth 2.0 Form Post Response Mode defines how OAuth 2.0 authorization response parameters (including OpenID Connect authentication response parameters) are returned via the User Agent using the HTML form values automatically submitted by HTTP POST.
  • RP-Initiated Logout Defines how the RP requests to OP to exit an EU.
  • Session Management Session management, used to standardize how the OIDC service manages Session information.
  • Front-Channel Logout A front-end based logout mechanism that enables the RP to logout without using the OP’s iframe.
  • Back-Channel Logout A back-end based logout mechanism that defines how logout is done through interaction between RP and OP.
  • OpenID Connect Federation Federation authentication, defines how OP and RP sets can establish trust by using a federation operator.
  • Initiating User Registration via OpenID Connect defines the prompt=create authentication request parameter.

Two Web-based RP Implementation Guides

Migration Specification

  • OpenID 2.0 to OpenID Connect Migration 1.0 OpenID Authentication 2.0 is a popular federated authentication protocol, OpenID Connect is a new version of OpenID Authentication and this specification defines how to migrate to the new OpenID Connect is a new version of OpenID Authentication, and the specification defines how to migrate to the new OpenID Connect.

There are still some drafts in the process of incubation, so I won’t go into them here.

OIDC Core Process

OIDC is abstracted into the following 5 steps, as shown in the figure.

OIDC Core Process

  1. RP (client) sends a request to OpenID provider (OP).
  2. OP authenticates the end user and obtains authorization.
  3. OP responds with an ID token, usually an access token.
  4. RP can send requests with access tokens to UserInfo endpoints.
  5. UserInfo endpoints return claims about the end user.

In contrast to OAuth2, RP is the OAuth2 client, where the request sent is not an authorization request, but an authentication (AuthN) request; OP is also the OAuth2 authorization server, which needs to provide EU (resource owner) claims and an authentication token Id Token on top of the OAuth2.

The OIDC authentication authorization process must include the authorization scope openid.

Id Token

An Id Token is a concept specific to OIDC, which is a JWT token containing user information (claims), as follows.

1

eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiYXpwIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwiaXNzIjoiaHR0cDpcL1wvbG9jYWxob3N0OjkwMDAiLCJleHAiOjE2NTM2MjUxMjgsImlhdCI6MTY1MzYyMzMyOCwibm9uY2UiOiJXNm5LeTlxZnFWMkRvSDN1TDVGVGNVOUVGR2k4dWlqay1lcDIyV3RGQ2NZIn0.VDBOF867LnQIB52XGkSMT6hAu0NpyJsPA3soIAt3WWb4dwDmdiMrq5xpRuewURknmBmhZaJHT2QETEFWGhwB5gnq4kw4yPlvOpUuKxqfPsr9plA0HV_mQF9WFearRmVI12hGBrgj0Htgf4I5K6Nz8c4K0ibrdmcHSwonrb856TVep0Ne1cr21tOcmYmptgGco_vNsKvPsua0Hxff56_ikGDYonY5y7q6leFP5F9LAKUgRjPdhXM6OzdpHfP8XkiiPor9A1WWW0VhxmxCGe7dfQF_0QFYtmWnAymSS1PExUz4KdKGjPKtPanZe6ufym-5-ErSc-kH0mWi6AxvYt_5VQ

Let’s take a look at the decoding of both the header and payload sections.

Head:

1
2
3
4
5

{
  "x5t#S256": "SxqqdWYxT7BZrdH-uVpgAHfX2q34qPyxx4onX6mv-qI",
  "kid": "felord.cn",
  "alg": "RS256"
}

The header contains the regular JWT Header information and is compliant with the JOSE specification.

Payload:

1
2
3
4
5
6
7
8
9

{
  "sub": "user",
  "aud": "e2fa7e64-249b-46f0-ae1d-797610e88615",
  "azp": "e2fa7e64-249b-46f0-ae1d-797610e88615",
  "iss": "http://localhost:9000",
  "exp": 1653625128,
  "iat": 1653623328,
  "nonce": "W6nKy9qfqV2DoH3uL5FTcU9EFGi8uijk-ep22WtFCcY"
}

From the above, the payload contains a series of claims, which have the following meanings.

The JWT specification defines seven reserved claims that are not required, but are recommended to allow interoperability with third-party applications. These are:

  • iss (issuer): Issuer of the JWT
  • sub (subject): Subject of the JWT (the user)
  • aud (audience): Recipient for which the JWT is intended
  • exp (expiration time): Time after which the JWT expires
  • nbf (not before time): Time before which the JWT must not be accepted for processing
  • iat (issued at time): Time at which the JWT was issued; can be used to determine age of the JWT
  • jti (JWT ID): Unique identifier; can be used to prevent the JWT from being replayed (allows a token to be used only once)

You can see a full list of reserved claims at the IANA JSON Web Token Claims Registry.

How to perform OIDC authentication

The authentication flow of OIDC is mainly extended by several authorization flows of OAuth2, there are three kinds as follows.

  • Authorization Code Flow based on OAuth2 authorization code flow for OIDC authentication authorization
  • Implicit Flow is based on the OAuth2 implicit flow, since OAuth2.1 removed the implicit flow, this should be removed as well.
  • Hybrid Flow is based on a hybrid flow of the above two, and should also be removed.

The reason why there is no client credentials pattern is that client credentials are designed to be used for interaction between clients and End User has nothing to do with it. So the focus is on Authorization Code Flow.

Please note that OIDC must use JWT as the token style.

User Information Endpoint

OIDC also provides the User Information endpoint, which is a resource endpoint. It is requested as follows.

1
2
3

GET /userinfo HTTP/1.1
Host: localhost:9000
Authorization: Bearer eyJ4NXQjUzI1NiI6IlN4cXFkV1l4VDdCWnJkSC11VnBnQUhmWDJxMzRxUHl4eDRvblg2bXYtcUkiLCJraWQiOiJqb3NlIiwiYWxnIjoiUlMyNTYifQ.eyJzdWIiOiJ1c2VyIiwiYXVkIjoiZTJmYTdlNjQtMjQ5Yi00NmYwLWFlMWQtNzk3NjEwZTg4NjE1IiwibmJmIjoxNjUzNTQ2OTUwLCJzY29wZSI6WyJvcGVuaWQiLCJtZXNzYWdlLnJlYWQiLCJtZXNzYWdlLndyaXRlIl0sImlzcyI6Imh0dHA6XC9cL2xvY2FsaG9zdDo5MDAwIiwiZXhwIjoxNjUzNTQ3MjUwLCJpYXQiOjE2NTM1NDY5NTB9.MxySV9FwP3JVdThc7DkoROfseEPW1fRXRD1ljWN05keCzwaiAwvRap-QyA5gYJewpid7fOFwnD5ETDns3-ia_QHRYp5RIPWnc-cb__9_JITTpLso_AiXpwxCr6TxrKt5Ax_jzkL9_MGrHQl7BqUpCAecc_NccS4WAR6pmIiNexAMrXusn2a5VodFxv18BpgRv_dJ9w_a3tmYXBWAC1apSoXXlpaI96NIprXOUnJWyKGlYS1VsXc6YMYArDBOamvtFD74L9UaTLCj1n5GU1FKlTGE061c07eKFk91O9IgOc5YR0Uzu-VNhea0NB5SlwImhUJSE4Ab11RlJD_eg0Oc9g

It can also be a POST request. The basic return values are as follows.

1
2
3
4
5
6

HTTP/1.1 200 OK
Content-Type: application/json

{
    "sub": "felord.cn"
}

If you also want to return user information such as email address, avatar, nickname, real name, etc., you need to carry an additional scope.

Summary

There is a lot more to OIDC, beginners can just master the basic functions above, for more features you need to refer to the official OIDC documentation. OIDC is much more versatile than the native OAuth2, it is a completely open standard and is compatible with some other IDP protocols.

Reference https://mp.weixin.qq.com/s/9AV8QCG9mzUmmRvO0zBKeg