By Hao Lee [email protected]

The topic of this article is Internet companies and those technology stacks related to login, divided into three parts. Single sign-on, Oauth2.0 and sweep login. You can’t cover all login systems, but it should be easy to master these three login techniques and understand the others.

Single sign-on (sso)

Meaning of single sign-on

Internet companies are also the concept of a few years ago, more than ten years ago, a company, a server, a domain name is often the case. But now, a company has multiple departments, multiple lines of business, and each department has its own service, and each set of services corresponds to a domain name. For companies, each department doesn’t want to spend time developing a separate login system; Personally, I have logged in service A of your company, and I do not want to log in again when USING service B. So single sign-on came into being.

How to design single sign-on

If your company asks you to design a login system, the following design plan will only drive users crazy.

So, in the following scenario, if you were to log in to design, how would you design? ‘

There are two approaches to single sign-on

Single sign-on system based on cookie sharing

  1. Visit a.ke.com, check no login status (token)
  2. my-login.ke.com?redirectUrl=a.ke.com
  3. After a successful login, the token is injected into the ke.com domain
  4. If b.ke.com logs in again and finds a token, an asynchronous request is sent to verify that the token is valid, and an HTML string is returned, that is, the main page of B.ke.com.

But what’s wrong with this single sign-on approach?

As enterprises expand and businesses expand, secondary domain names may be different. In this case, single sign-on based on cookie sharing will be invalid.

** The scheme that spells the token onto the redirect URL

  1. A.ke.com login: no login status (token)
  2. my-login.ke.com?redirectUrl=a.ke.com
  3. My-login.ke.com Injecting the token in the domain
  4. a.ke.com?token=xxx
  5. Token is injected into the a.ke.com domain
  6. b.lianjia.com
  7. An existing token exists under my-login.ke.com
  8. b.lianjia.com?token=xxx
  9. B.lianjia.com to inject tokens

Sso to Demo

In order to facilitate readers to deeply understand the principle of single sign-on, the author provides a small demo of single sign-on. Personally, I very recommend readers to clone this demo git and run it, which is more profound than the understanding formed by only reading the article.

The demo technology stack

  1. Native nodejs
    • The parameters of the post
    •   set-cookie domain
    • The form type = “hidden”
  2. Ejs template engine
    • SSR server rendering

So let me expand a little bit on a couple of things that are worth talking about in the demo. The process of retrieving parameters in a POST request is not one time. Instead, the server needs to retrieve chunk of parameters several times and merge them together. This is because the server does not know how many parameters are in the request (post parameters are not capped like GET parameters, and the number of parameters can be very large). The other is the domain field of set-cookie, which tells the browser which domain the server wants to inject the cookie to be valid only under. Another point is the meaning of the type=’hidden’ attribute, which is a way to pass parameters to the server in a transparent way to the user.

This small demo also uses server-side rendering knowledge. Here is a brief introduction to the difference between client rendering and server rendering, client rendering refers to the first time to get HTML from the server, there is no data in HTML, when JS loading, JS will send asynchronous request for data, and then update HTML. Server-side rendering means that the server returns HTML directly with data.

link

  1. Github.com/Ethan199412…

The 2.0 principle

Meaning of OAuth 2.0

Here are two typical OAuth 2.0 scenarios:

Let’s think about the following situation:

I am a small company called B+, and I want to use the housing information of shells to analyze and process the data to some degree. Then I need users to log in shells and call some open API of shells to obtain user data, but the users certainly do not want me to directly obtain their user name and password on shells.

This is where we need to use Oauth.

First party, second party and third party

I want to start with two questions.

In the case of B+, who is the third party?

In the Douban example, who is the third party?

In fact, there is no official statement on the Internet that clearly states the first, second and third parties. In general, a third party is an application that uses someone else’s data. So, if we log in to the shell with B+ to get data from the shell, the third party refers to B+. In the example of Douban’s wechat login, Douban needs to log in tO wechat to obtain user information. According to the above definition, it seems that Douban is the third party, but for Douban, you can say that wechat login is the third party login. So don’t confuse who is a third party in the OAuth standard with the idea of logging in with a third party.

Principles of OAuth 2.0

Let’s go back to our first example. If you’re shell’s third party login person, and you ask the developer of B+ to enter the user name and password directly on their login page, the service of B+ directly sends the user name and password as user credentials to get the data of shell?

The answer must be no, because for the customer, his shell user name and password are equal to B+ directly, if B+ record the shell user name and password, then the user information is easy to be leaked or even trade.

So we need a way for the first party to have access to the third party’s data without directly accessing the user’s username and password. This approach is OAuth2.0

Easy version OAuth 2.0

  1. Users visit www.b-plus.com and click to log in to Shell
  2. login.beike.com?redirectUrl=www.b-plus.com
  3. www.b-plus.com?token=xxx

At this point, when users want to obtain wechat data, they do not need to log in, and at the same time, they do not need a user name and password. However, since the token is placed on the URL, it is not secure, and if the token is intercepted during transmission, it can still be used to obtain the user information of the shell.

Oauth 2.0 authorization code mode

  1. User access www.b-plus.com
  2. login.beike.com?redirectUrl=www.b-plus.com
  3. www.b-plus.com?code=xxx
  4. The service gets the code, and the service sends an Ajax request to get the token. The code is valid once, and only the first person can exchange the code for the token

Oauth2.0 based on authorization code mode is the most mature and most commonly used oAuth authentication mode.

What does OAuth 2.0 offer for certification

  • Response_type: authorization type, for authorization code mode oauth, write code
  • Client_id: indicates the client ID, which is used as the unique identifier of third-party applications
  • Redirect_url: Where does the authentication server send code or token
  • Scope: Which permissions are applied for. If no permission is applied, the default permission is applied

A key concept

The following concepts are important in learning OAuth 2.0.

  • Third Party Application: the one who wants to access other people’s data (B+)
  • Resource Owner: The person (user) who owns the user information
  • Authorization Server: The Authorization Server of Shell in this example
  • Resource Server: Resource Server, where the shell provides data and interfaces

The second function of redirectUrl

Obviously, the first function of redirecting urls is well understood. This is where a third party gets the code and token provided by the authentication server. However, it actually has the second meaning, that is, the authentication server will judge whether the request with code and the request with token are sent by the same person according to whether they are consistent. If they are consistent, the authentication server will give the token. If they are inconsistent, the authentication server will not give the token.

If the user obtains the token for the first time, how many times is the redirected URL known to the authentication server? How many times has the redirected URL been compared by the authentication server?

Know three times, the first time, users in the authentication server to register third-party information to fill in once; The second time, authentication server to obtain the application code request to take out the parameters of the redirect URL, and registered redirect URL comparison; For the third time, when obtaining the token request, the authentication server retrieves the redirect URL in the parameter and compares it with the redirect URL in the code request. So the answer is know it three times and compare it twice.

AccessToken and RefreshToken

These two tokens are actually very easy to understand, accessToken as the only proof to get data from the data server, it is destined to be placed in every request, you think about it, since frequent interaction in the network, it is relatively higher risk. Assuming that this accessToken has an infinite lifetime, this means that once accessed by hackers, access to accessToken is equivalent to access to user names and passwords. Therefore, one of the characteristics of accessToken is that it has strict timeliness. Once it expires, accessToken is no longer recognized by the authentication server. However, frequent login will affect user experience, so the third party will use the refreshToken kept locally to obtain a new accessToken. The whole process is transparent to the user.

A picture to help you remember the principle of Oauth2.0

Oauth 2.0 user name and password is a bit like the substitution reaction in high school chemistry. You need to take the user name and password (Fe) to the authentication server (CuSO4CuSO_4CuSO4) and change it to a code (Cu). Then use this code (Cu) to authenticate the server (AgCl) in exchange for a token (Ag).

Scan qr code to log in

Key steps

  1. PC request QR code
  2. The service returns the code ID
  3. The PC displays the QR code by code ID
  4. The PC polls the STATUS of the QR code
  5. The phone scans the QR code to get the code ID
  6. Send token and code ID to service
  7. Confirm login on the mobile phone
  8. In the PC polling, the STATUS of the QR code is login and the TOKEN is obtained on the PC.
  9. The PC obtains the token and can use the service

Because the SCANNING process uses HTTP protocol, the PC can only use polling (note the difference with Web socket) to learn the status of the TWO-DIMENSIONAL code stored on the server.

The resources

【 1 】 wikipedia en.wikipedia.org/wiki/Single…

[2] huawei cloud www.huaweicloud.com/articles/11…

[3] Jane books www.jianshu.com/p/75edcc05a…

[4] nguyen other www.ruanyifeng.com/blog/2014/0…

【5】 oauth.com www.oauth.com/oauth2-serv…

[6] github.com/Ethan199412…