When there are more and more Internet applications, each application implements its own identity storage, authentication and authorization, users need to register and login repeatedly on the application, which is a bad experience, and user identity information cannot be shared and synchronized among multiple applications. When using enterprise applications, companies provide a series of applications and have to switch between registration and login despite being operated by the same user.

Is there a way that I can register an account with a proxy site, and if I log in to other sites, the other sites can go to the proxy site to get the information. As long as the proxy site is alive enough, then it is always possible to skip a lot of tedious registration and login processes.

These ideas emerged during the evolution of technologies such as WS-Federation, SAML2.0, OpenID, OAuth, OIDC…

OpenID & OAuth development history

OpenID & OAuth development history

There are also some revisions and extensions that are not reflected here, mainly to focus on the fact that OpenID and OAuth are not the same.

  • OpenID is oriented to authentication, which authenticates the user’s identity to determine whether it is valid.
  • OAuth is oriented to the authorization process, after the current user identity is known to be legitimate, control the resources that the user can access and consider protecting the resources being accessed.

OpenID

OpenID is a decentralized online authentication system. For OpenID-enabled websites, users do not need to remember traditional authentication tokens such as usernames and passwords. Instead, they only need to register in advance with a website that acts as an OpenID identity provider (IdP). OpenID is decentralized, so any website can use OpenID as a way for users to log in, and any website can act as an OpenID identity provider. openID solves the registration problem without relying on a centralized website to confirm a digital identity.

OpenID provides users with a unified network identity that adheres to the OpenID network identity. When an application website(In OpenId terminology it is called Relying Parties, or RP) that adheres to the OpenID protocol requires users to log in, it directs them to a third-party OpenID identity provider((called OpenID identity provider in OpenId terminology, i.e. OP)) for authentication, and if they pass the authentication, they can log in successfully. This saves the trouble and tedium of registering and logging in for each application site. It solves the problem mentioned at the beginning that each application needs to complete the registration and login process independently and needs to implement and maintain an independent user database.

OAuth

OAuth is an authorization protocol that addresses the fact that an application can access certain authorized resources of a user on another application, but this application does not need to know the password of the user’s account on the other application, i.e., it can access controlled resources on the other application without revealing the user’s credentials to the other application.

  • November 2006, when Brian Cook was working on an OpenID implementation of Twitter. At the same time, the social bookmarking site Ma.gnolia needed a solution to allow members using OpenID to grant Dashboard access to their service. Thus Cook, Chris Messina and Larry Halff from Ma.gnolia met with David Recolton to discuss using OpenID for delegated authorization on Twitter and the Ma.gnolia API. However, their discussion concluded that OpenID did not have an open standard for completing API access delegation.
  • In April 2007, the OAuth Discussion Group was formed and this group of implementers wrote a draft proposal for an open protocol. DeWitt Clinton from Google learned about the OAuth project and expressed his interest in supporting the effort.
  • In July 2007, the team drafted the initial specification. Eran Hammer-Lahav then joined the team and coordinated many of the OAuth drafts, creating a more formal specification.
  • In October 2007, the final draft of OAuth Core 1.0 was released.
  • In November 2008, at the 73rd meeting of the Internet Engineering Task Force in Minneapolis, a BoF discussion of OAuth was held to incorporate the protocol into the IETF for further normalization work. This meeting was well attended, and there was broad support for the topic of formally mandating an OAuth working group in the IETF.
  • In April 2010, the OAuth 1.0 protocol was published as RFC 5849, an informal RFC.
  • In October 2012, OAuth 2.0 was released, formally published as RFC 6749. OAuth 2.0 is the next version of the OAuth protocol, but is not backward compatible with OAuth 1.0. OAuth 2.0 focuses on simplicity for client developers, while providing specialized authentication processes for web applications, desktop applications, cell phones, and smart devices.

Open ID Connect

The OpenID team originally wanted users to use OpenID for authentication, but since the authorization process includes authentication as part of the process, authorization means going through the authentication process. As a result, some users opted for the simplicity of OAuth authentication and the advantages of “the task of managing user credentials can be delegated to an external service” and “because the new user registration process can be omitted, the barriers to using the service become lower”. The trend of using OAuth 2.0 as authentication became popular as it quickly took over.

The OpenID team had to admit that users preferred OAuth 2.0, so they defined a new identity specification on top of OAuth O pen ID C onnect (OIDC), which is based on OAuth 2.0 with minor extensions, building the identity layer on top of OAuth 2.0 so that it can be used as an authentication protocol.

Open ID

That is, OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0.

OpenID+OAuth 2.0=OpenID Connect

OIDC Key Terms

  • Claim: Declaration information, presented in a brief format (such as the format on an ID card).
  • Claims Provider: Declaration information provider (e.g. Authorization Server in OAuth 2.0 is able to return Id token, which carries the declaration information).
  • End-User(EU) : Human participant (the person who completes the authentication activity).
  • ID Token: A declaration (Claim) containing EU identity information, stored and delivered in JWT (Json Web Token) format. jWT has features such as self-containedness, compactness, and tamper-proof mechanism. JWT is self-contained, compact and tamper-proof, so that ID Token can be securely passed to third-party applications and easily verified.
  • OpenID Provider (OP) : The service provider that provides authentication, the Authorization Server (Authorization Server) in OAuth 2.0, used to provide authentication services and return Claim information to third-party applications (Relying Party).
  • Relying Party (RP): trusted third-party application (Client in OAuth2.0) that requires the EU to complete authentication and obtain Claim information from the OP.
  • UserInfo Endpoint : An interface for user information that can return the identity information of the current user when the RP requests this interface using an Access token.

OIDC Key Terms

OIDC Protocol Cluster

OIDC consists of a series of specification documents, including a core document and several optional supported documents to provide extended support.

  • Core: mandatory. Defines the functionality of the OIDC core, building authentication on top of OAuth 2.0, and the use of declarations (such as a brief description on an ID card) to convey user information.
  • Discovery: optional. Defines how third-party applications can dynamically discover OIDC service provider metadata documents (e.g., the address of the service provided, the encryption method used, the type of authorization supported, etc.).
  • DynamicRegistraation: optional. Defines how the third party application registers to the OIDC identity provider.
  • OAuth 2.0 Multiple Response Types: defines several new for OAuth 2.0 response methods (the original common authorization code code, implicit authorization token on top of the id_token and a mix of code, token and id_token).
  • OAuth 2.0 Form Post Response Mode: optional. Extends OAuth 2.0 response parameters with those required for OIDC. Provides a mode based on form form response information passed to third-party applications using the post request type, with the response parameters stored in the body in application/x-www-form-urlencoded format.
  • RP-Initiated Logout: Optional. Defines the mechanism for how a third-party application logs out the currently logged-in user.
  • Session Management: Optional. Defines how to manage the session data of logged-in users on the OIDC so that when a user on the OP logs out, it can also be easily logged out on the RP.
  • Front-Channel Logout: optional. Front-Channel Logout based mechanism, so that third-party applications do not need to embed the authentication service provider’s iframe to logout.
  • Back-Channel Logout: optional. Based on the back-end logout mechanism, defines how RP and OP communicate directly to complete logout.
  • OpenID Connect Federation: optional. Defines the mechanism how to establish reliable trust between OP and RP.
  • Initiating User Registration via OpenID Connect: Optional. Provides a mechanism to allow a way to be able to register users on the OP when instructed to do so by the RP. As shown in the figure below, the upper part describes the protocol cluster of OIDC and the core specification of the most central part of it. The lower part is used as the other protocol specifications that support OIDC.

open id connect

For these protocols, it may look confusing, just briefly understand the concept, the actual development of these will gradually come to the surface.

OIDC & OpenID 2.0 Differences

  • OpenID Connect performs many of the same tasks as OpenID 2.0, but the API is more user-friendly and can be used in both native and mobile applications.
  • OpenID Connect defines optional mechanisms for reliable signatures and encryption.
  • Integration of OAuth 1.0a and OpenID 2.0 requires extensions, while OIDC itself integrates with OAuth 2.0.

OIDC & OAuth2.0 differences

OIDC still uses the authorization server in OAuth to give the user authentication information to the third-party application in the form of Id token, the third-party application can verify the user ID and get the basic information of the user from it as well as access the user details through the authorization process of OAuth2.0. As shown in the figure below, the authentication protocols such as WS-Fed and OIDC are used for the user authentication part, and the OAuth2.0 protocol is used for the access control of resources.

oauth2

The Id token in OIDC and the core Access token in OAuth2.0 each have different validity or focus parts.

  • OAuth2 provides Access Token to address the issue of authorizing third party applications to access protected resources.
  • OIDC follows the OAuth2.0 protocol flow and provides ID Token on top of that to address the issue of third-party applications identifying users.

OAuth2 OIDC

OIDC abstraction process

The OIDC process consists of the following 5 main steps.

  1. a third party application (RP) sends an authentication request to the authentication service provider (OP).
  2. the user authenticates and selects authorization content on the authentication page.
  3. the authentication service provider (OP) verifies the authentication request and sends Id token and Access token to the third party application (RP).
  4. the third party application can use the Access token to request user information or other resources within the authorization.
  5. the resource service verifies the Access token and returns the user information or resources.

OIDC process

Process, in OAuth2.0 in the authorization code mode and implicit authorization mode, OIDC and OAuth2.0 is the same, but there are several authorization modes in some cases, in OIDC does not exist, when the user does not need to go through the authentication process to get Access token, such as the following two modes.

  • Resource Owner Password Credentials Grant (Resource Owner Password Credentials Grant): Third-party applications can obtain the user’s login credentials can directly request Access token from the authorization server, so that the process of identifying the user’s identity is eliminated.
  • Client Credentials Grant: This is to identify the client, the direct participants are not added to the process, and there is no identification of who the user is.

Several authentication methods of OIDC

OIDC’s authentication flow is mainly extended from several authorization flows of OAuth2, mainly the following 3 types.

  • Authorization Code Flow: Based on OAuth2’s authorization code flow, an Id token is added on top of the original code for Access token.
  • Implicit Flow: Based on OAuth2’s Implicit Flow, an Id token is added to the original redirection from the authorization server to the third-party application that returns only the Access token.
  • Hybrid Flow: Hybrid Flow (Authorization Code Flow) and Implicit Flow (Implici Flow), which can control the return position of Id token and the presence or absence of Access token according to the different parameters configuration. Note: As above, Refresh token is omitted to focus on Id token and Access token.

Authorization code flow

  1. The third-party application redirects to the authentication page of the authorization server (OP) through the browser to authenticate the user and perform the authorization process. The parameters used in the redirection are based on most of the parameters in OAuth 2.0. The main ones are as follows

    • scope: mandatory. The scope of the selected authorization, when it is an OIDC request, you need to include the openid option, as shown in the following example.
    • response_type: mandatory. Response type method, when using the authorization code process, for code.
    • client_id: Required. The id value obtained by the third-party application by registering with the authorization server in advance.
    • redirect_uri: Mandatory. Redirects to the address of the RP after the OP authentication authorization is completed.
    • state: Recommended. A string provided by the third-party application (RP) that the authorization server (OP) will return to the third-party application (RP) as is, to block CSRF attacks. The above parameters are commonly used in the authorization code process, in fact there are many other parameters that can be used according to different scenarios. Additional parameter information https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

    Authorization code flow

  2. When the user finishes filling in the authentication information and executing the authorization operation, the authorization server (OP) reviews the user’s authentication information and verifies the authorization scope. After validation, it redirects to the callback address (redirect_uri in step 1) specified by the third party application (RP), and appends the code and state parameters as query parameters to the callback address.

    Authorization code flow

  3. The third-party application (RP) requests the Token EndPoint of the authentication service provider via code in exchange for a Token.

    Authorization code flow

    Token EndPoint then returns the response Token, which appends a id_token field in addition to some of the data specified by OAuth2.

    1
2
3
4
5
6
7

    {
    "access_token": "SlAV32hkKG",
    "token_type": "Bearer",
    "refresh_token": "8xLOxBtZp8",
    "expires_in": 3600,
    "id_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c"
}

  4. Request user information or resources within the license.

    Authorization code flow

Implicit process

In OAuth 2.0, the response_type used for implicit authorization is token, while in OIDC, it changes to id_token token or only id_token, and when only id_token is used, no Access token is returned. The rest of the parameters are the same as the implicit authorization in OAuth 2.0. However, OIDC adds an additional parameter nonce compared to OAuth2.0 implicit process

  • nonce: required. String value to associate a third-party application session with an Id token and to mitigate replay attacks. The value is passed unmodified from the authentication request into the Id token. To prevent an attacker from guessing the value, sufficient entropy must be present in the random value.

Note: The difference between the state of OAuth 2.0 and the nonce of OIDC in the implicit process

https://stackoverflow.com/questions/46844285/difference-between-oauth-2-0-state-and-openid-nonce-parameter-why-state-cou

  1. The third-party application (RP) carries parameters to jump to the authentication authorization page of the authorization server (OP) and waits for the user to authenticate and execute the authorization.

    Implicit process

  2. When the authorization server (OP) completes the review of user authentication information and verification of authorization scope, it redirects back to the third-party application (RP) and returns id token, access token according to the response_type at the time of request (not returned when only id_token is set). Note the hash part of the url (after #).

    Implicit process

  3. This is followed by a request for user information or resources within the license.

Hybrid process

This is a combination of an authorization code and an implicit flow, where part of the token comes from the authorization server (OP) when it redirects to the third-party application (RP), and part of it comes from the third-party application (RP) when it makes a request to the authorization server (OP). In this process, the response_type can be mixed, such as code id_token, code token or code id_token token.

  1. The third party application (RP) initiates an authentication request to the authorization server (OP). Here the combination of authorization code and implicitly only id_token is used.

    Hybrid process

  2. When the authorization server (OP) finishes reviewing user authentication information and verifying the scope of authorization, it redirects back to the third-party application (RP) and returns id token and access token according to the response_type of the request (not returned when only id_token is set).

    • access_token: When there is a token option in response_type, access_token will be returned.
    • id_token: When there is an id_token option in response_type, then id_token will be returned.
    • code: this is mandatory in mixed processes, so code is always returned.

    Hybrid process

  3. The third-party application (RP) requests the authorization server (OP) to exchange Token via code. this is the same as the authorization code process now.

Id token format

The ID Token returned by the authentication service needs to strictly adhere to the definition of JWT (JSON Web Token), the following are the details of the definition of JWT (JSON Web Token).

  • iss=Issuer Identifier : Required. Unique identifier of the authentication service, a case-sensitive https URL that does not contain query and fragment components.

  • sub=Subject Identifier : Required. iss provides an identifier for the end user, unique within iss, up to 255 ASCII characters, case-sensitive.

  • aud=Audience(s) : Required. Identifies the audience of the ID Token, must contain the client_id of OAuth2, case-sensitive string array.

  • exp=Expiration time : Required. ID Token after this time will be invalidated.

  • iat=Issued At Time : Required. time of the JWT build.

  • auth_time=AuthenticationTime : The time when the end user completes authentication.

  • nonce : Random string provided when sending an authentication request, used to mitigate replay attacks, can also be used to associate client-side Sessions. if nonce exists, third-party applications must verify the nonce.

  • acr=Authentication Context Class Reference : Optional. Indicates an authentication context reference value that can be used to identify the authentication context class.

  • amr=Authentication Methods References : Optional. Indicates a set of authentication methods.

  • azpAuthorized party : Optional. Used in conjunction with aud. This value is used only if the authenticated party and the audience (aud) do not match, and is rarely used in general. The following is an example of a typical ID Token.

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

    {
    "exp": 1614187991,
    "iss": "https://authorization-server.com/oauth",
    "sub": "a0903223-a120-91e0-c342-10bd237c24c1",
    "aud": "client1",
    "iat": 1614151991,
    "auth_time": 0,
    "nonce": "n-0S6_WzA2Mj",
    "acr": "1",
    "azp": "client1",
    "nbf": 0,
    "typ": "ID",
    "session_state": "150df80e-92a1-4b0c-a5c5-8c858eb5a848",
    "userId": "123456",
    "preferred_username": "testera",
    "given_name": "tester",
    "family_name": "a",
    "email": "testera@myweb.com"
}

See OpenID Connect Core 1.0 for a more detailed definition of ID Token.