Introduction to the

In modern websites, we often encounter the use of OAuth authorization, for example, there is a relatively small number of websites, users need to log in, but it is very troublesome to directly let users register, users may lose because of this reason, then the website can use OAuth authorization, Use github or other third-party websites for authentication and authorization to obtain relevant user information, thus avoiding the user registration step.

Of course, it is likely that after obtaining user information authorized on the third party website, some necessary information needs to be filled in for binding on the website, such as mobile phone number, user name and so on.

But this is much more convenient than simple registration, and easy for users to accept.

Today, we will explain the composition of OAuth 2.0 authorization framework, hope you enjoy.

The constitution of the request

In the traditional CS mode authorization system, if we want to access restricted resources with the help of the third-party system, the third-party system needs to obtain the user name and password of the restricted resource server to access the resource server, which is obviously very insecure.

How do we do that in OAuth2?

Let’s start with a flow chart for authorization in OAuth2:

Generally, there are four roles in OAuth2.

Resource Owner: Represents the owner of a resource, which can be authorized by providing a user name, password, or other means. Usually comes alone.

Resource Server: represents the server that ultimately needs to access the resource. For example, github obtained user information after authorization.

Client: The client used to interact instead of the Resource owner.

Authorization Server: A server for authorization that generates corresponding Access tokens.

The process goes like this:

The Client initiates an authorization request to the Resource Owner. The Resource Owner enters the corresponding authentication information and returns the authorization grant to the Client.

The client then requests the authorization grant to the authorization server and returns the Access token.

The client can then request the Resource server with the Access token and obtain the restricted resource.

refresh Token

To be safe, access tokens always have an expiration date, so what happens if the token expires?

The method is refresh Token:

Let’s take a look at the refresh Token flowchart:

A, B, C, and D are the same as those mentioned above.

If the access token expires during subsequent resource access, the client sends a refresh token request to the authentication service.

The authentication server then returns the new Access token again.

Authorization Code model

In the pattern described above, the Client stores Authorization Grant information and uses this information to authorize the server to request Access tokens.

The Client directly stores Authorization Grant information and communicates with the Authorization server, which imposes certain security restrictions on the Client.

In a Web environment, the client is accessed by user-Agent (Web browser). What should I do?

Here we introduce an Authorization Code pattern.

The Client initiates a request through the user-Agent and has a forward link attached. After the authentication information is provided, the authorization server returns the authorization code instead of the token. After receiving the code, the client can obtain the Access token or Refresh token by using this code.

The authorization flow chart above can be illustrated with a concrete example where resource Owner is the resource we want to access. An Authorization Server is a third-party Authorization Server, such as github’s Authorization service. User-agent is the browser.

Ok, let’s start the specific process:

For example, if the user wants to obtain the information of www.flydean.com but needs to log in, the login interface of Github will be jumped to. We enter the user name and password of Github. Github will return an Authorization Code to our server, such as www.flydean.com/?code=code. After receiving the Code, the client will request Github in the background to verify the validity of the Code. If the Code is valid, Github will return the access token, and the client can use the Access token to access github resource server resources.

Here is an example of a concrete access token return value:

HTTP/1.1 200 OK Content-type: Application /json; charset=UTF-8 Cache-Control: no-store Pragma: no-cache { "access_token":"2YotnFZFEjr1zCsicMWpAA", "token_type":"example", "expires_in":3600, "refresh_token":"tGzv3JOkF0XG5Qx2TlKWIA", "example_parameter":"example_value" }Copy the code

Implicit authorization

In all of the modes mentioned above, clients need to communicate directly with the authorization server to obtain access tokens. Is there any way to obtain access tokens without directly communicating with the authorization server?

Let’s talk about implicit authorization.

The figure above is an example of implicit Authorization. Unlike the Authorization Code pattern, the Authorization server returns an Access token fragment, only this fragment, we cannot obtain the Access token.

Here we need to make an additional request to the Client Resource server, which will return a script script, through which we parse the Access Token fragment to get the final Access token.

Resource Owner Authorization password authentication

This pattern typically occurs when the Resource owner trusts the client.

Let’s take a look at the flow chart:

In this mode, the user hands the password to the client, and the client uses the saved username and password to request resources from the authorization server.

Client Authentication and Authorization

In this mode, the client has a certain authorization scope and can directly obtain the access token from the authorization server through authentication and authorization by the client.

Github’s OAuth2 authentication process

In the general process described above, many roles can be merged.

Next, let’s explain how to use Github’s OAuth2 for authorization.

To use Github’s OAuth2, you need to register the OAuth service on Github first.

Click the register button, input the relevant information, we can complete the registration.

The important thing here is the callback URL, which we use to pass authorization information.

After successful registration, you will get a Client ID and Client Secret.

Github’s authorization steps are divided into three parts:

The user goes to the github authentication page for authorization

In this section, we need to jump to github’s licensing page:

https://github.com/login/oauth/authorize
Copy the code

Above is the link to the jump page, which can take the following parameters:

Client_id: the required parameter, which is the client ID obtained by registering the app above.

Redirect_uri: Optional. If this parameter is not set, the callback URI provided at registration will be used.

Login: Specifies an authentication user name. This parameter is optional.

Scope: Github permission scope.

State: is a random number used to prevent cross-site attacks.

Allow_signup: Whether registration is allowed during authentication.

Take a look at the jump page:

The user is redirected to the resource page

When the user authorizes, it adjusts to the callback page with the code:

http://www.flydean.com/login?code=b14a2dd57f11b2310f42
Copy the code

After the application gets the code, it obtains the access token by calling the following request:

POST https://github.com/login/oauth/access_token
Copy the code

The post request takes the required parameters client_id, client_secret, and code, as well as two optional parameters redirect_URI and state.

By default, we get the following response:

access_token=e72e16c7e42f292c6912e7710c838347ae178b4a&token_type=bearer
Copy the code

The application gets access token to get github user information

Once we have the Access token, we need to put the token in the request head to request user information:

Authorization: token OAUTH-TOKEN
GET https://api.github.com/user
Copy the code

conclusion

OAuth2 is a very common protocol, is also very convenient, the main purpose is to enable the third party server can obtain user information within the scope of authorization. I hope you enjoy it.

Author: Flydean program stuff

Link to this article: www.flydean.com/oauth-2-0-i…

Source: Flydean’s blog

Welcome to pay attention to my public number: “procedures those things” the most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know the small skills you find!