In February 2021, the WeChat team made an interface adjustment for small program login and user information access, a move that unprecedentedly shook up almost all small program developers and generated a lot of reactions in the small program community.

As an access party, this paper will discuss the design purpose of WeChat’s new authorization login mechanism, the adaptation scheme and the impact on the product from both product and technical perspectives.

History: authorization, login and access to user information

Before the introduction of WeChat, the OAuth model from Twitter was popular enough. In the OAuth model, if business B wants to operate the user’s data in business A, it needs to first jump to business A’s page, let the user confirm with business A directly, called Authorization, get the code issued by business A to business B, and jump back to business B. After that, business B uses this exchange code to contact business A directly through the backend, and get a series of credentials used to After that, Business B uses this redemption code to contact Business A directly through the backend to obtain a series of credentials for operating the data of Business A at one time and save them, and then it can use these credentials to invoke the operations in Business A.

In the OAuth model, the acronym Auth stands for two layers: “Authorization” refers to the process where the user directly contacts Business A to confirm the operation, while “Authentication” refers to the subsequent process where Business A verifies the access rights of Business B.

The WeChat public web development implements this model:

For authorization, the public page needs to jump to the authorization page provided by WeChat first, and the user clicks to confirm the authorization (if there is no need to obtain user information, or if the user is already authorized, or has already followed the service number, there is no need to confirm, but still need to make this jump), the authorization page will jump back to the public page business, and bring the code to the page parameters; after that, the business side needs to exchange the OpenID/UnionID and an access_token credential through the back-end interception or After that, the business side needs to exchange the OpenID/UnionID and an access_token credential issued by WeChat through the business’s own backend by means of back-end interception or front-end Ajax request.

For login, the essence is to distinguish users and issue login states.OpenID/UnionID represents the user’s identity information in WeChat, allowing the business backend to distinguish between the same and different users. The business backend can issue existing login state information for the same user and access data previously generated by the same user; for different users, it can create new account information, issue new login states, etc.

For getting user information, the backend can use access_token to request it from WeChat.

Small program old authorization login

In WeChat applets, because the WeChat client has control, there is no longer a need to jump between third-party business and WeChat, as long as the interface provided by WeChat is called, the WeChat client can ensure the validity of the authorization, so the authorized login is simpler compared to web development, but this also means that WeChat can change the behavior of the interface at any time. Until now, the behavior of the small program authorized login has been changed twice.

When the applet was first launched, WeChat provided two interfaces, wx.login and wx.getUserInfo, for logging in and authorizing access to user information, respectively. where wx.login is silent and returns directly the code that can be exchanged for the OpenID and the session_key used to decrypt the data. wx.getUserInfo will pop up the authorization popup, and after authorization, it will return the encrypted user data, which can be decrypted by the backend with session_key. The purpose of encryption is to prevent users from tampering with information, thus limiting the creation of offending avatar nicknames, which is beyond the scope of this paper.

Shortly thereafter, wx.getUserInfo was changed to no longer actively populate authorization, but to silently fail in the absence of authorization; authorization was triggered using a special button component provided by WeChat, in order to stop some applets from popping up authorization upon launch or overrunning to obtain user information when it was not needed. For some applets that use WebView, the change requires a native authorization page to be adapted because the WebView page cannot carry the native button component.

The old set of authorization login process has its cumbersome parts, but for a long time, we have forgotten one of the biggest convenience points: after one authorization, the applet can get the user’s information silently at any time. When a user changes his nickname or avatar, as long as he opens the authorized applet, the applet can directly get the modified information without the user’s authorization again.

Product form for new license registration

From the official documentation, it can be seen that there are two main points of change after the adjustment of the small program authorization login mechanism.

  • In the wx.login interface, the user’s UnionID can now be obtained directly without authorization, which actually fixes the previous bug, and encourages each applet business not to exceed the limit to obtain user information as much as possible, following the principle of permission minimization.
  • wx.getUserProfile interface has been added to replace the original wx.getUserInfo. The new interface will actively populate the authorization, but can only get the current nickname avatar at once, and still needs to be called after the user clicks.。

From a product perspective, these two points each bring different changes.

The first point is that for businesses that need to obtain UnionID, it can make the ability to log in silently truly available. It allows users to use as many features as possible without authorizing a nickname avatar, prompting authorization only when needed, which helps a lot with the conversion rate of the login process for the product itself, and also helps WeChat protect user privacy, which is a win-win move.

The second change can be seen as an attempt by WeChat to anonymize user information. Previously, WeChat introduced a custom nickname avatar feature, which allows you to set a custom nickname avatar when you authorize it, distinct from WeChat’s own nickname avatar, to achieve a certain level of anonymity; however, because the old authorization login interface was a one-time authorization, users could not modify their custom nickname avatar once it was set. Therefore, in order to be able to change the one-time authorization to a per-authorization, WeChat allows developers to actively adapt to this behavior by adding a new interface.

According to WeChat, after April 13, new releases that support wx.getUserProfile can no longer use wx.getUserInfo, otherwise they will receive the default nickname avatar. This change can also be seen in advance from the WeChat Developer Tools: the avatar obtained will become a default avatar and the nickname will change to “WeChat User”.

And adapting this interface also means that product interaction needs to change, because after this, an authorization can only get a one-time nickname and avatar, when the user has modified the WeChat nickname avatar, the small program business not only can not silently get to the modified nickname avatar, there is absolutely no way to know that the avatar nickname has changed, all must be achieved by re-authorization.

For the applet business that needs to get user nickname and avatar, we explored a more reasonable way to adapt it: simulate the original authorization once and provide an entrance to modify the avatar and nickname manually. By modifying the login logic, the original authorization interaction can be simulated as much as possible, and the authorization will only be made at the first use, but after this authorization, the nickname and avatar will not be updated again; therefore, it is necessary to provide the entrance to manually modify the avatar and nickname, so that users can expect the behavior of “the avatar and nickname will not be automatically synchronized, but can be updated or modified manually”.

Technical Adaptation Solution: Document applet as an example

In the document applet, the original login interface is two-in-one, that is, the front-end first call finished wx.login and wx.getUserInfo, get the code and encrypted user information, and then together call the back-end interface, the back-end query existing users or create new users, and update the user avatar nickname information.

In the context of the new authorized login, such a back-end interface is no longer sufficient. In order to restore the original authorization interaction as much as possible, we need to determine whether the user is authorized or not, and then decide whether to invoke authorization and upload the user’s nickname avatar based on whether the user already has a nickname avatar. In addition, when the user chooses to manually update the nickname avatar, an interface is also required to upload the updated user’s nickname avatar.

Therefore, in order to keep the interface design reasonable, we split the login interface into two interfaces and implement them with the interface for obtaining business user information.

  • the front-end calls wx.login, gets the code, and calls the back-end login interface to get the login state issued in advance.
  • The front-end calls the existing interface to get the business user information, determines whether the business has already obtained a nickname avatar, and if there is already a nickname avatar, directly saves the login state in 1, and the login is completed.
  • pop-up authorization if the nickname avatar has not been obtained yet, and after authorization, call the back-end upload nickname avatar interface to save the obtained nickname avatar.
  • According to the product interaction design, when the user chooses to update the nickname avatar, repeat the steps in 3 to authorize and update the nickname avatar.

Since wx.getUserProfile only returns information such as nicknames and avatars in plaintext, we also need to connect the interface for uploading nicknames and avatars with content security to prevent users from arbitrarily uploading non-compliant nickname and avatar information.

In addition, in the case of QQ applets and PC/Mac WeChat applets, the new authorization login interface may not be supported, so we need to make compatibility with the non-supported wx.getUserProfile interface and use the original authorization login logic instead.

Summary

This paper discusses the new authorization login mechanism for WeChat applets. Under the new mechanism, authorization is limited to a one-time operation to obtain user information, thus encouraging developers to request as little authorization as possible while allowing a certain degree of user privacy protection. For the product form, this requires the product to strengthen the customizability of user avatar nicknames in the interaction; from the development perspective, it requires a certain amount of effort to adapt to the specific business situation.

At the same time, we can also see some details of the problems inside and outside the small program authorization login: frequent changes in the interface, the adaptation period is too hasty, which will lead to developers tired of adaptation and negative emotions towards the platform; in addition, compared to the avatar nickname and other conventional information customization, the real user privacy of cell phone number, real name identity and other information still needs to be more strictly controlled in order to go further in the direction of privacy and security. In addition, the information that really belongs to users’ privacy, such as mobile phone number and real name identity, still needs to be more strictly controlled in order to go further in the direction of privacy and security.

The applet is a platform made for control, but we prefer such control to restrain unruly developers, to control products that are bent on marketing and lack practicality, and to let go of projects polished with heart and soul to go further.