Why oAuth

If you’re an early adopter of the Web, you should be aware of the changes in the way you sign up for websites:

  • In the early days, you need to enter your username and password, then enter your email address, complete registration verification based on your email address, and then use your username and password to log in. Because mailboxes were relatively popular at that time. I was studying computer science in college, and the first task assigned by the teacher was to register an email address.
  • Later mobile phone popularity, website registration login is to enter the mobile phone number, receive verification code to verify registration login
  • Later, you can log in directly based on the way of tripartite authorization of wechat, Weibo and QQ

You’ll find it increasingly easy to register and log in:

  • In the early days, you had to register your account and password for every site you wanted to log in to, the same account and password, in case one password was stolen and the rest were stolen. Different account numbers and passwords. It’s hard to remember. Then came the software for helping people manage passwords. I don’t remember what it was called.
  • With a mobile phone number, you can log in temporarily based on a verification code, but entering a verification code each time is a hassle
  • The way of three-party authorization (also known as oAuth) only needs to click “confirm authorization”, that is, you can log in and access, eliminating the trouble of registration, verification and login

It can be seen that now wechat, Weibo and QQ, which have a large user base, have replaced the original mailbox and mobile phone and become the infrastructure for registration and login. And much safer:

  • Sign up via email. If you visit some shady website and your email is compromised, you will receive a lot of spam
  • Sign up with your phone number, and when your phone number is leaked, you’ll get a bunch of crank calls
  • OAuth will not have the problem of leakage, unless wechat, Weibo, QQ leaked your information!

You also don’t need to remember a bunch of passwords, just remember the passwords of wechat, Weibo and QQ accounts.

On the other hand, for developers, it also eliminates the management of the account system, and only needs to follow the oAuth specification to access wechat, Weibo, QQ, which reduces the development cost.

Understanding oAuth’s role, let’s take a look at the implementation of oAuth.

The concept of the request

Some time ago, the China Literature Group contract incident made a stir, one of the main problems is the ownership of resources, the contract stipulates that the works written by the author belongs to China Literature Group! Netizens immediately exploded, that works in the author or China Literature group ownership? The answer is given in the oAuth protocol.

OAuth defines four roles:

  • Resource owner: In most cases, this is the user.

  • Resource Server: Refers to the server used by the service provider to provide services.

  • Client: a tripartite application that requires users to authorize access

  • Authorization Server: A server used by service providers to process authorization and authentication.

The operation flow of OAuth 2.0 is shown as follows:

Suppose we want to log on to a third-party website by reading text:

  • When the Resource Owner opens the Site, the Site requests authorization from the Resource Owner
  • The Resource Owner consents to the Site’s authorization, and the Site receives the authorization certificate. The authorization method here depends on how the Web site requests and what the Authorization server supports. OAuth2.0 protocol defines four modes, including authorization code mode, simplified mode, password mode and client mode, which will be explained later. You can also customize it.
  • Using the authorization obtained in the previous step, the Site requests a token from the Authentication Server
  • After authenticating the Site, the Authentication Server confirms that it is correct and agrees to issue the token
  • The Website uses the token to request resources from the Resource Server
  • The Resource Server confirms that the token is correct and agrees to open resources to the Site

It’s obvious in the process:

  • The “website” is the Client

  • “Authentication server” is AuthorizationServer, belongs to reading

  • “ResourceServer” is ResourceServer, also belongs to reading

  • The “resource owner” is the user. When you replace “resource owner” with China Literature, the process is clearly broken.

As can be seen from the above process, the “third party website” did not obtain any sensitive information of users in the whole process, and the obtained information can only be obtained after users’ active authorization, which ensures security and convenience.

The classification of the request

The following describes the specific authorization modes one by one. Before you begin, a few more concepts need to be understood:

  • User-agent: The User Agent. In most cases, it can be directly understood as the browser

  • Web Hosted Client Resource: A web-hosted Client Resource, which can be interpreted as a server hosting Web scripts

Authorization Code Grant

The authorization code mode is the most complete authorization mode with the most rigorous procedures. Through the background server of the Client, it interacts with the authentication server of the service provider to exchange tokens. The specific process is as follows:

  • The “user” accesses the “client” based on the browser, and the “client” redirects to the corresponding page of the “Authentication Server”. A “Redirection URI” is attached to the boot parameter, pointing to the “Client” page

  • User select whether to authorize or not

  • After authorization, the Authentication Server directs the browser back to the Client page based on the Redirect URI, along with an authorization code

  • After receiving the authorization code, the “client” applies for a token from the “authentication server” through the background server, carrying the authorization code and the “Redirect URL”

  • When the “Authentication server” verifies that it is correct, it sends a token (AccessToken) and an update token (RefreshToken) to the “client”.

The function of the Update Token is explained below

Implicit Grant

In simplified mode, the user directly applies for a token from the authentication server in the browser, bypassing the step of “authorization code”. All steps are done in the browser, the token is visible to the user, and the client does not require authentication. The specific process is as follows:

  • The “user” accesses the “client” based on the browser, and the “client” redirects to the corresponding page of the “Authentication Server”. A “Redirection URI” is attached to the boot parameter, pointing to the “Client” page

  • User select whether to authorize or not

  • After authorization, the Authentication server directs the browser back to the Client page based on the Redirect URI, with access tokens in the Fragment of the URI

  • The Client browser sends a request to Web Hosted Client Resource based on the command. The request does not contain the Fragment received in the previous step. The browser saves the Fragment locally

  • The “Web Hosted Client Resource” returns a Web page (usually a page containing a script, which should be easy to understand if you understand JSONP) that can parse the access token from the Fragment

  • The browser executes the script to retrieve the token

  • The browser issues the license to the client

Resource Owner Password Credentials Grant

Compared with the preceding two authorization modes, the password mode is less secure because users need to provide their own user name and password to the client. The client uses this information to request authorization from the “service provider.” Although the protocol states that the client can’t store account passwords, you probably won’t use this mode unless you really trust the client.

The specific process of this authorization mode is as follows:

  • The User provides the user name and password to the client

  • The client sends the username and password to the Authentication server to request the token

  • After authentication, the Authentication Server returns the access token

The Client Credentials Grant mode

In client mode, users register with the client directly, and the client requests the service provider to provide services in its own name. The specific process is as follows:

  • The client authenticates to the Authentication server and asks for an access token

  • After authentication, the Authentication Server returns the access token

Update the token

In the above process, the data returned by the authentication server after authentication has an update token in addition to the access token. Now that we know that we can access resources by accessing tokens, what does updating tokens do?

As we all know, there is a timeout period for web login, and this is no exception. Access tokens also have a timeout period. The update token is used to get a new access token after the access token expires.

  • The client authenticates the Authorization server to obtain the Access token.

  • After authenticating the Client, Authorization Server issues and refreshes the access token.

  • The client requests resources from the Resource Server with an access token

  • The Resource Server validates the access token and, if valid, provides the service.

  • Repeat steps 3 and 4 until the access token expires

  • When the access token is invalid, Resource Server returns an invalid token error

  • The “client” authenticates to the authorization server and carries a refresh token to request a new access token

  • The Authorization Server validates the client identity and the refresh token and, if valid, issues a new access token (and optionally a new refresh token)

Finally added

One step that is actually missing from the above process is registering the client. If you are authorized to log in via wechat, Weibo or QQ, you should be aware that before accessing, we need to apply for our application on their open platform, and we will be given an appId and an appSecrect upon successful application.

This appId is used to uniquely identify the client. AppSecrect is in the authorization mode, when the client background interacts with the authorization server, it needs to provide the code and appId together to replace the access token.

conclusion

This paper explains the function of oAuth and combs the specific flow of oAuth.

Reference documentation

  • The OAuth 2.0 Authorization Framework www.ietf.org/rfc/rfc6749…

Public name: Abstract thinking