Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what is the general standard OpenID Connect of SSO". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Brief introduction

OpenID Connect, referred to as OIDC for short, has become a general standard for single sign-on and identity management on Internet. It builds an identity layer on OAuth3, which is an identity authentication standard protocol based on OAuth3 protocol.

OAuth3 actually only does authorization, while OpenID Connect adds authentication on top of authorization.

The advantage of OIDC is a simple JSON-based identity token (JWT) and full compatibility with the OAuth3 protocol.

Today we will introduce the specific principles of OIDC.

What is OpenID Connect?

Released in 2014, OpenID Connect is a simple identity layer based on the OAuth 2.0 protocol that allows clients to authenticate end users and obtain information about users based on authentication performed by an authorized server or identity provider (IdP).

OpenID Connect provides RESTful HTTP API and uses Json as the data delivery format.

We talked about the SAML protocol based on XML format before, and OpenID Connect has become the de facto standard because of its more concise data exchange format.

Let's take a look at the basic flow of OpenID connect:

RP (client) sends an authentication request to OpenID Provider (OP).

OP authenticates the End User and obtains the corresponding authorization.

OP returns an ID Token or access Token to RP.

RP uses access token to request user information from UserInfo Endpoint.

UserInfo Endpoint returns the corresponding user information to RP.

ID Token

ID Token is like a user's ID card. It exists in JWT format and is signed by OP to ensure its security.

The way to get the ID Token is to send an authentication request to the OP.

Because ID Token exists in JWT format, JWT can be divided into three parts, Header,Payload and Signature.

Here we focus on the json content of Payload:

{"sub": "alice", "iss": "https://openid.flydean.com"," aud ":" client-12345 "," nonce ":" n-0S6_WzA2Mj "," auth_time ": 1311280969," acr ":" c2id.loa.hisec "," iat ": 1311280970," exp ": 1311281970}

Sub = Subject Identifier: must be. Unique identity of the EU provided by iss; the maximum length is 255ASCII characters

Iss = Issuer Identifier: must be. Provide a unique identification of the person who authenticates the information. It's usually the host+path part of Url.

Aud = Audience (s): must. Identify the audience of the ID-Token. Must include client_id of OAuth3

A random string provided by nonce:RP when sending a request to mitigate replay attacks or to correlate the Session information of ID-Token and RP itself.

Auth_time = the time when the AuthenticationTime:EU completed the authentication. This Claim is required if RP sends an authentication request with the parameter of max_age.

Acr = Authentication Context Class Reference: optional. Represents an authentication context reference value that can be used to identify the authentication context class.

Iat = Issued At Time: must be. The time the JWT was built.

Exp = Expiration time: must be. Expiration time of ID-Token

The one above is ID Token's standard Claims.

Request ID Token

Now that we know what ID Token is, how does the RP client in OpenID Connect request an ID Token?

Although OpenID Connect does not specify how the user should actually be authenticated, it is up to the provider to decide. But we usually use Web browsers to perform the authentication steps.

The browser redirects the user to the authentication window of the authentication server, and after entering the user name and password, the user requests ID token through the OAuth 2.0 protocol.

There are three ways to get ID Token using OAuth 2.0:

Authorization Code mode

The steps of the Authorization Code process are as follows:

The client prepares the authentication request, which contains the required parameters

The client sends a request to the authorization server

The authorization server authenticates the most popular users.

Authorization service is unified / authorized by the end user

The authorization server sends the end user back to the client with the authorization code

The client requests a response from the Token endpoint using the authorization code

The client receives the response, and the Body of the response is contained in the ID Token and Access Token

The client verifies the ID Token and obtains some identity information of the user

Implicit authorization

The figure above is an example of implicit authorization. Unlike the Authorization Code model, the authentication server returns an access token fragment, only this fragment, we can not get access token.

Here we need to make an additional request to the client resource server, and the server will return a script script through which we parse the access token fragment to get the final access token.

Mixed mode

Mixed mode is rarely used, which is a mixture of the first two modes, which allows token values to be obtained from the front end and back end, respectively.

What can ID Token do?

So what can we do with the requested ID Token?

Stateless session, by storing the token in the browser's cookie, we can achieve lightweight stateless sessions.

There is no need to store session information on the server side, we just need to verify the token on the server side.

Token can be passed to a third party, because token itself is not sensitive information, so we can pass token to other applications or back-end services.

Token interaction, we can use ID Token to request access token in the IdP server, thus achieving the purpose of interactive token.

Example of Open Connect Authentication Code Authorization

Here we give an example of using authentication code to authorize the acquisition of ID token.

RP initializes a user authentication by redirecting to OpenID Provider's OAuth 2.0 authentication terminal.

Here is an example of redirection:

HTTP/1.1 302 FoundLocation: https://openid.flydean.com/login? Response_type=code & scope=openid & client_id=s6BhdRkqt3 & state=af0ifjsldkj & redirect_uri=https%3A%2F%2Fclient.flydean.com%2Fcb

Response_type: because we are in authentication code mode, we choose code here.

Scope:openid indicates that the request is openid.

Client_id:RP 's client id,OP uses this client_id to identify whether it is a recognizable RP. You can register or make an appointment in advance.

A state standard generated by state:RP, mainly to prevent attacks.

Redirect_uri: the link that jumps after the authentication is completed.

On the op side, it will detect whether a valid user session already exists, otherwise the user login interface will pop up and let the user log in.

After a successful login, client will be redirected to redirect_uri with the authentication code:

HTTP/1.1 302 FoundLocation: https://client.flydean.com/cb? Code=SplxlOBeZQQYbYS6WxSbIA & state=af0ifjsldkj

Use code to get ID token

The code returned above is only an intermediate product. RP needs to submit the code to OP in exchange for ID token.

This time we will directly use a back-end POST request:

POST / token HTTP/1.1Host: openid.flydean.comContent-Type: application/x-www-form-urlencodedAuthorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JWgrant_type=authorization_code & code=SplxlOBeZQQYbYS6WxSbIA & redirect_uri=https%3A%2F%2Fclient.flydean.com%2Fcb

Grant_type:authorization_code indicates that it is in authorization code format.

Code is the code obtained in the previous step.

Redirect_uri is callback url.

If successful, OP returns a JSON object with ID token, access token, or refresh token:

HTTP/1.1 200 OKContent-Type: application/jsonCache-Control: no-storePragma: no-cache {"id_token": "eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q Jp6IcmD3HP99Obi1PRs-cwh4LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg"access_token": "SlAV32hkKG", "token_type": "Bearer", "expires_in": 3600,}

The format of ID token is JWT.

User Info

The ID token we obtained already contains some very useful claims information.

In fact, ID Token can also contain other user info information:

Such as name,profile,picture,email,gender,birthdate,phone_number,address and other useful information.

We can add additional scope to the token request:

HTTP/1.1 302 FoundLocation: https://openid.flydean.com/login? Response_type=code & scope=openid%20email & client_id=s6BhdRkqt3 & state=af0ifjsldkj & redirect_uri=https%3A%2F%2Fclient.flydean.com%2Fcb

For example, in the above example, we added additional email information, then OP will add the email option to the token.

For example:

{"sub": "alice", "email": "alice@wonderland.net", "email_verified": true, "name": "Alice Adams", "given_name": "Alice", "family_name": "Adams" So much for the introduction of "phone_number": "+ 86 1888888888888", "profile": "https://flydean.com/users/alice"}" what is the general standard OpenID Connect of SSO". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.