Web authentication Mode--oauth 2.0 Protocol (1)

Introduced

The OAuth protocol is used to troubleshoot authentication issues when third-party applications access HTTP service. For example, a video site supports users by logging in and then getting the image information on the user.

In this scene.

Serves as the HTTP service role.

Video sites are third-party applications

While the video site from the acquisition of user images, the need for certification is the authentication problem here

When a user logs on, the authentication information required to access the image on the user in the video site is the way OAuth solves the authentication problem.

noun definitions

The following roles are defined in the OAuth protocol:

Resource owner: The owners of the resources, such as the users here

Resource server: Servers that store resources, such as servers here

Authorization Server: is responsible for authenticating users and generating authentication information that is required to access resource server.

Client: The application requesting resources from the resource server. such as the video site here. (Website backstage)

User-agent: User agent, such as browser

Overall process

The overall certification process is as follows:

Figure 1

A:client Request authentication information to resource owner

B:resource Owner provides authentication information (e.g., username and password)

C: Submit the authentication information to authorization server for authentication

D: Authentication passed, Authorization server returns access Token

E:client access to protected resources in resource server through access token

The steps, a, B, can occur on the client, or the client navigates the user to the authorization server.

In step e, depending on the type of access token, Resource server may be validating itself or calling Authroization server for validation.

OAuth is actually creating an abstraction layer (Authorization Server).

It is primarily responsible for two things: validating the user, producing a unified access to resource server authentication information.

The way to verify the user can be a variety (username/password, phone verification code ...), so this abstraction layer unifies the various authentication methods here as Access tokens. This resource server masks the diversity of user authentication and simplifies the logic.

Licensing mode

The most important thing in the above process is actually step ABCD, which generates an access Token by collecting the resource owner's authentication information. This process is called resource owner's authorization to the client. OAuth defines four modes of authorization:

Authorization Code Mode

Simplified mode

Password mode

Clent Authentication Mode

Authorization Code Mode

The flowchart is as follows

The Authorization Code mode is one of the most rigorous of the four modes. The client first wants to register on the authorization server and gets an ID. (This allows only the allowed client to authenticate via OAuth, enhancing security)

In the above steps:

A client navigates the user to the authorize endpoint of the authorization server, with ClientID (so that authorization server can authenticate the client), The jump URL after authentication is complete.

The HTTP request is as follows:

GET https://sample.com/authroize?response_type=code&clientid=xxx&redirect_uri=https:// Www.client.com/oauthcallback.aspx

B users enter their own authentication information on the Authroization Server page.

C Authorization Server provides the authorization code in the form of query string by navigating the user to the URL specified in step a.

The Http response information is as follows:

http/1.1 302 Foundlocation:https: // www.client.com/oauthcallback.aspx?code=xxx

After the D client obtains the authorization code, it calls the interface of the authorization sever (both the incoming authorization code and the jump Url,authroization server pair authentication to ensure security)

The HTTP request is as follows:

POST www.example.com/token Contentapplication/x-www-form-urlencodedgrant_type =authorization_code&code=xxx&redirect_uri=https://www.client.com/ Oauthcallback.aspx

E Authorization Server returns access token to the Client,client store and is used in subsequent requests.

Response as follows:

http/1.1application/json;charset=utf-8no-storepragma:no-cache{       "Access_token": "2yotnfzfejr1zcsicmwpaa",       "Token_type": "Example", "expires_in": 3600, " Refresh_token ":" Tgzv3jokf0xg5qx2tlkwia "," Example_parameter ":" Example_value "}    

In this process,

1. Client does not have access to the user's authentication information (username/password)

2. User-agent did not contact access Token.

3. Pairing the authorization code with the jump URL to verify

All of this enhances the security of the entire process.

Simplified mode

Simplified mode, which is a simplified version of the authorization Code mode. The flowchart is as follows:

The difference between this and the authorization code pattern is:

1. In step a, direct request for token instead of code

Get/authorize?response_type=token&client_id=s6bhdrkqt3&redirect_uri=https%3a%2f% 2FCLIENT%2EEXAMPLE%2ECOM%2FCB http/1.1Host:www.example.com

2. In step c, Authorization server directly comes with access token in the jump URL, skipping the authorization code link. However, access tokens are not represented as query string, but rather as fragment (the hash portion of the URL)

Http Response:

http/1.1302  foundlocation:http://client.com/cb#access_token= 2YOTNFZFEJR1ZCSICMWPAA&token_type=example&expires_in=3600

3. According to the definition of HTTP protocol, when redirect, fragment will not be uploaded to the Web server, so the client wants access token, must return a JS script in the response of the jump URL in the browser to read access Token is then sent to the client. (It's not quite clear why OAuth has to put access tokens into a hash instead of a query string)

Password mode

The flowchart is as follows:

In the password mode, Resource owner enters authentication information directly on the client's page. The access token is then acquired through the client. The client cannot store the authentication information entered by the resource owner during the entire process. But there is no way to enforce the agreement, only rely on the trust of the client. So this is a way for resource owner to be less secure.

The request for step B is as follows:

Post/token http/1.1Host:server.example.comContentapplication/x-www-form-   urlencodedgrant_type=password&username=johndoe&password=a3ddj3w

Step c is response as follows:

http/1.1  $okcontent-type:Application/json;charset=utf-8Cache-control:no-Storepragma:no-Cache {"Access_token":"2YOTNFZFEJR1ZCSICMWPAA",       "Token_type":"Example",       "expires_in":3600,       "Refresh_token":"Tgzv3jokf0xg5qx2tlkwia"}

Client Authentication Mode

The flowchart is as follows:

In fact, this method should not be used in the OAuth application scenario. This mode uses the client's own authentication information on the authorization server to obtain access tokens. That is to say the client as a resource owner, then the specific use of the client user is irrelevant.

Extended mode

The way in which access tokens are obtained is determined by the Grant_type in the token request. So authorization server can use this field to extend more ways to get access tokens.

Refresh Access tokens

when you get access tokens from these four modes, we get a refresh token at the same time. access tokens have an expiration date (e.g. 30 minutes). After the expiry date, the use will be an error. This time can be applied to refresh token to find authorization server regain access token, this process does not need resource owner's participation, belongs to the silent execution.

The specific requests are as follows:

/token http/1.1Host:server.example.comContentapplication/x-www-form-urlencoded grant_type=Refresh_token&refresh_token=tgzv3jokf0xg5qx2tlkwia

Verify Access Token

Access tokens are finally sent to resource server, so resource server validates access tokens. And the specific verification method depends on the type of token.

1. If token is a string that does not contain specific information. Resource server can only give this token to authorization server to parse the user information.

2. If token is a string containing specific user information (e.g. JWT). Resource server can parse tokens to get the user information on its own.

Authorization Server and resource server

Authorization Server and resource server can be on the same server. It can also be on a different server.

1. On the same server

In this case, the third-party application and the HTTP service are actually the same application, that is, any HTTP application's own user authentication can apply the OAuth protocol. In this case, Authorization server is a module of the application.

2. On different servers

There are more scenarios for this scenario. Authorization server can correspond to multiple resource servers, so that all resource servers can use Authorization server as the user authentication information provider. Sso,open IDs can be used in this scenario.

Reference: RFC6749

CS Mode application with OAuth

The previous discussion is about the Web application of BS. The application of CS mode (Communication protocol is HTTP) is also possible with the OAuth protocol.

Take common app development as an example:

The backstage service of the app is actually resource server, we can deploy authorization server separately or with resource server, or a module of background service. However, because the app is a product of its own development, it belongs to the trusted client. Therefore, the password mode can be used. Other modes involve URL jumps, independent verification pages, etc. it's a little too complicated.

However, if the app's background is to be an open platform for other apps to call, it needs to support other modes. Because the jump occurs in the browser, the implementation of the app can be more complex in this case.

Web authentication Mode--oauth 2.0 Protocol (1)