Web - OAuth2 authentication process

Posted by wutanggrenade on Thu, 03 Mar 2022 19:06:40 +0100

The difference between a token and a password

Tokens and password s work the same way and can enter the system, but there are several main differences:

	token	Password
Effective duration	Automatic expiration of tokens	Long-term validity without user modification
Who can revoke	Data owner revocation invalidates	Cancellation is not generally allowed
Permission Scope	Tokens have permissions to restrict operations	Generally full permissions

Note: Once you know the token, you can enter the system. Generally, the system will not re-confirm the identity, so tokens must be kept secret, and the consequences of leaking a token are the same as leaking a password. This is why tokens generally have a short expiration time.

Authentication process

(A) After the user opens the client, the client requests authorization from the user.

(B) The user agrees to authorize the client.

(D) The authentication server, after authenticating the client, confirms that it is correct and agrees to issue a token.

(E) Clients use tokens to request resources from the resource server.

(F) The resource server confirms that the token is correct and agrees to open the resource to the client.

You can also refer to the following figure to help understand.

Give an example

Simulate the Authorization and Authentication Process for Users to Log on to Jingdong using Third Party Wechat

Dead work:

Before Jingdong can support the third party login of WeChat, it needs to register on the open platform of WeChat, and WeChat will issue a client to Jingdong. ID and app secert keys

Technological process:

Users visit the official website of Jingdong to log in and jump to the login page. At this time, Jingdong requests user authorization

At this time, the user chooses a third-party WeChat login and jumps to the following link. It also displays a two-dimensional code that provides user scanner login. User needs to agree to log in and generate code

https://open.weixin.qq.com/connect/qrconnect?appid=wx827225356b689e24&state=45451A684ED6970EEE1692B2C496DB7DDF432EBC9B5C30CAC583E22FA6391A2B37D033535639574F25A84B9DDDC72546&redirect_uri=https%3A%2F%2Fqq.jd.com%2Fnew%2Fwx%2Fcallback.action%3Fview%3Dnull%26uuid%3Db37301f413f74cac980757a5d3b885b9&response_type=code&scope=snsapi_login#wechat_redirect

There are mainly the following parameters

appid: Client id
state: Represents the client's current state
redirect_uri:https%3A%2F%2Fqq.jd.com%2Fnew%2Fwx%2Fcallback.action%3Fview%3Dnull%26uuid%3Db37301f413f74cac980757a5d3b885b9
response_type: code //Delegates are authorized using Authorization Number Mode
scope: snsapi_login#wechat_redirect //scope of permission to apply for

All the user needs to do at this point is sweep the code to log in

If the user logs in successfully, WeChat's authorization server will redirect back to the client's URI with an authorization code and the previously provided local state.

https://qq.jd.com/new/wx/callback.action?view=null&uuid=b37301f413f74cac980757a5d3b885b9&code=001y0oyV0nwdq229vKzV05pdyV0y0oyA&state=45451A684ED6970EEE1692B2C496DB7DDF432EBC9B5C30CAC583E22FA6391A2B37D033535639574F25A84B9DDDC72546

The main parameters are

uuid: b37301f413f74cac980757a5d3b885b9
code: Generated code，For next acquisition tokenn

When Jingdong receives the authorization number, it attaches the first redirected URI and requests a token from the WeChat authorization server. At this time, the request parameters include

client_id: Application in WeChat Open Platform Application ID
client_secret: Provided in WeChat Open Platform Application APP Secret
grant_type: Need to be filled in authorization_code
code: Obtained in the previous step code
redirect_uri: Callback addresses, which need to be associated with the callback addresses in the registration application and the first step redirect_uri Consistent parameters

In a word, the simplified step is: Jingdong gets the code code code of the successful user login authorization and requests the authorization server of WeChat in exchange for token. Responses are available for reference

{
 "access_token": "ACCESS_TOKEN",//Value of Token
 "expires_in": 1234,//Expiration Time
 "uid":"12341234"//UID of the currently authorized user.
}

Finally, Jingdong used the acquired token to request resources for WeChat development

Four Authorization Methods

authorization-code

Third-party applications apply for an authorization code before using it to obtain a token.
implicit

Allows tokens to be issued directly to the front end. This approach does not have an authorization number as an intermediate step, so it is called "implicit"
password

If you trust an app highly, RFC 6749 also allows users to tell the app their user name and password directly. The app uses your password to request a token, which is called password.
client credentials

Applies to command-line applications that do not have a front-end, that is, requesting a token from the command line.

First, A applies to make a request to B from the command line.
```
https://oauth.b.com/token?
grant_type=client_credentials&
client_id=CLIENT_ID&
client_secret=CLIENT_SECRET
```
In the URL above, grant_ The type parameter equals client_credentials means credentials, client_id and client_ Sec is used to let B confirm A's identity.

The second step is to return the token directly after Web site B validation has passed.

The token given in this way is for third-party applications, not for users, which means it is possible for multiple users to share the same token.

Note: Either way of authorization, before a third party can apply for a token, it must go to the system for a record, state its identity, and then get two identities: client ID and client secret. This is to prevent tokens from being abused. Third-party applications that have not been documented will not get tokens.

Reference resources

https://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html

Topics: Web Development oauth2

Programmer Think