Now scanning code login is a very common login method. When a user needs to log in to a website, the website will provide a login method by scanning the code. The user opens the corresponding mobile App, scans the TWO-DIMENSIONAL code displayed on the website, and then confirms the login in the App. After the website detects that the user has confirmed the login, the login page will be redirected to the successful login page. In this form, scan login is to synchronize the user’s login status in the mobile App to the website. This article will take a look at how this synchronization happens.
Scan code login in the same product
Suppose you have a product, the product through the mobile client App and the PC application provides users with services, in order to facilitate users to log in on the PC, the function of the product provides a sweep login code, namely the PC application show a login qr code, users use mobile terminal App scan code and confirm the login, and then the user can login successfully on the PC. In this case, mobile App and PC App belong to the same product, which is a common product form. Wechat, Weibo and Zhihu are all representatives of this product form.
For the sake of introduction, let’s assume that the PC application is a Web site. Here’s how this login works:
As shown in the figure above, the whole process is relatively simple, which is roughly divided into the following steps:
1, the user initiated two-dimensional code login: at this time the site will be a two-dimensional code, and the two-dimensional code corresponding to the logo saved, in order to track the two-dimensional code scan status, and then the two-dimensional code page back to the browser; The browser first displays the QR code and then polls the scan status as instructed by the Javascript script. The so-called polling is that the browser calls the API of the website every few seconds to query the qr code scanning login result, and carries the QR code identifier when querying. Some articles say that WebSocket can be used here. Although WebSocket responds in a timely manner, most schemes still choose polling or long polling from the consideration of compatibility and complexity. After all, it doesn’t matter if the communication is slightly delayed at this time.
2. Scan code to confirm login: The user opens the mobile App, uses the built-in scanning function of the App to scan the TWO-DIMENSIONAL code displayed in the browser, and then the App extracts the login information in the two-dimensional code to display the login confirmation page. This page can be the App Native page or the remote H5 page. The Native page is used here. After the user clicks the confirm or Agree button, the App submits the QR code information and the current user’s Token to the website API. After the website API confirms that the user’s Token is valid, it updates the status of the QR code identifier created in Step 1 to “Confirm login” and binds the current user.
3. Verify login success: In Step 1, the QR code login page starts a poll for scanning code status. If the user has “confirmed login”, the website generates a QR code bound to the user’s login Session when polling to access the WEBSITE API, and then returns a login success message. Here login state maintenance is based on the Session mechanism, but it can also be replaced by other mechanisms, such as JWT.
To ensure login security, it is necessary to take some security measures, which may include the following:
-
The information carried by the TWO-DIMENSIONAL code is processed in accordance with certain rules. The App can verify when scanning code, so as to avoid any scanning code to request login;
-
The two-dimensional code set an expiration time, expiration automatically deleted, so that the occupied resources remain within a reasonable range;
-
Limit the qr code to be used only once to prevent replay attacks;
-
Two-dimensional code using long enough random string, to prevent malicious exhaustive occupation;
-
HTTPS protects login data from eavesdropping and tampering.
Scan code login for third-party applications
Now a lot of sites in addition to provide their own account login way, also provides WeChat flicking login code, weibo login code, it is very convenient for users, but a lot of sites in order to get the user phone number, login for the first time also need to use mobile phone verification code to log in again, the user will be a bit of a feeling of being deceived, But that’s not what this article is about.
Here to wechat scan code to log in to a website as an example, a website is a third-party application, the so-called third party is relative to wechat itself. Compared with the scanning code login in the same product, the website using wechat scanning code login is a little more complicated, because it involves the login security between different applications. Here’s how this logon works in detail. The sequence diagram is quite long, but with a little patience you can figure it out completely and even implement a similar third-party scan logon scheme yourself.
Some key points are highlighted here:
1. Step 3 Generate wechat login request record: After the user scans the code and agrees to log in, the browser in Step 25 will redirect to the third-party application. If a login request record is not created before, the website cannot confirm that the login is initiated by itself, which may lead to cross-site request forgery attacks. For example, use wechat to log in the TWO-DIMENSIONAL Code of an application to defraud the user of authorization, and then finally jump back to other sites, which can only passively accept, although the next verification of authorization Code fails, wechat may think that there is some problem with the third-party application, and it is difficult to be blocked. Therefore, after the third-party application creates a login request record, it needs to spline the record identifier into the URL for accessing the wechat login QR code. Wechat will return this identifier as it is after the user agrees to log in. The third-party application in Step 26 can verify whether this identifier is valid.
2. Step 17 Display the application name and request authorization information: Because wechat supports many third-party applications, users need to be clearly informed of which application they are logging in and what information the application can access, which are all necessary information for users to make login decisions. Therefore, after scanning the code, the wechat mobile terminal needs to go to the wechat open platform to query the third-party application information corresponding to the TWO-DIMENSIONAL code.
3. Step 24 Temporary login authorization Code: wechat open Platform does not directly return the information of the login user to the browser, because the third-party application still needs to authorize the user and maintain the session state, which is suitable for the application server to handle. Moreover, it is not safe to directly return user information to the browser, and there is no guarantee that the QR code login request is initiated through the designated third-party application. The third-party application will carry the authorization Code, AppId and AppSecret of the application in Step 27, and then send a login request to wechat open platform. The temporary authorization Code can only be used once, and it can not be used again if it is saved, and can only be used for the specified application (i.e. bound with AppId). AppSecret is extracted from the server to verify the identity of the application. These measures ensure the security of wechat authorized login. However, user information is not directly returned after verification, but an Access token is returned. The application can use this token to request the interface to obtain user information. This is because the open platform provides many interfaces, and access to these interfaces requires authorization. Therefore, an Access token is issued to third-party applications, and this authorized login method is called OAuth 2.0. For security reasons, the access token has a short validity period. Generally, open platforms issue a Refresh token. After the Access token expires, third-party applications can replace the refresh token with a new Access token. If the Refresh token also expires or the user cancels authorization, the user cannot obtain a new Access token. In this case, the third-party application should log out the user. These tokens cannot be leaked, so they must be stored on the server side of third-party applications.
Here is an interesting question: why does wechat’s QR code login page Url not contain the signature of a third-party app?
Take the Url of the wechat login TWO-DIMENSIONAL code page of Geek Time as an example:
Open.weixin.qq.com/connect/qrc…
Where appID is the application Id allocated to geeks by wechat Open platform; Redirect_uri is the geek-time URL that wechat calls back after the user is authorized to log in. Although it looks very long, it actually hops between pages in geek-time. State is a login ID generated by Geek Time. Different states will generate different TWO-DIMENSIONAL codes. Wechat will take this state when calling back geek Time.
In this URL, there is only the AppID of Geek Time, but no signature of Geek Time. That is to say, wechat will generate the login TWO-DIMENSIONAL code of Geek Time, but it does not verify whether the login request of Geek Time is initiated by Geek Time. Then anyone can generate the wechat login TWO-DIMENSIONAL code page of Geek Time. That doesn’t seem very rigorous.
Is it safe? An attacker can easy access to an application login WeChat qr Code, and then obtain the user login authorization (this is relatively simple, get a fake web site, or directly words fool, users will probably not see Saul Code confirm content), again through the browser intercept or DNS attack to the temporary authorization Code, It’s relatively easy to skip over checking to apply State. However, when verifying the temporary authorization Code to wechat, you must carry App Secret, which is difficult, unless the third-party App developers themselves leak this core Secret. On the whole, the protection of user information is safe, and attackers basically cannot get access tokens to access user information. If this signature is added to the URL, the protection of user information is not strengthened, and the authorization Code is still easy to obtain; In addition, the signature generally relies on App Secret. If App Secret is leaked, the signature will lose its significance.
What if someone constantly generates a wechat login QR code for an app? This is another type of attack, wechat can take some traffic limiting measures, or even directly block some IP, which has no impact on normal users.
Wechat QR code login variant
In addition to jumping to the QR code login page, wechat also provides a way to embed the QR code in third-party websites. The qR Code is generated by the wechat JS SDK and displayed in the designated area of the web page. After the user scans the Code and agrees to log in, the wechat JS SDK initiates a redirection or opens the application callback page in iframe to transfer the temporary authorization Code and application State, and the subsequent process is the same.
In addition, if the third-party application here is a mobile App, the wechat open platform also supports the method of scanning Code login. The difference is that the wechat SDK needs to be integrated, and the qr Code is obtained and the user authorization Code is received through the SDK callback, and the subsequent process is the same.
The above is the main content of this article, in view of my talent and learning, if there are mistakes welcome correction.
For more architecture knowledge, please pay attention to the public account firefly architecture. Original content, reproduced please indicate the source.