WeChat web page authorization

If the user accesses a third-party webpage in the WeChat client, the official account can pass the WeChat webpage authorization mechanism , to obtain basic user information and then implement business logic.

Instructions on the web page authorization callback domain name

1. Before the WeChat official account requests user web page authorization, developers need to go to the "Development-" on the official website of the public platform. In the configuration options of "Interface Permission - Web Service - Web Account - Web Authorization to Obtain User Basic Information", modify the authorization callback domain name. Please note that the domain name (which is a string) is filled in here, not the URL, so please do not add protocol headers such as http://;

2. The authorization callback domain name configuration specification is the full domain name, for example, if required The domain name authorized by the web page is: www.qq.com. After configuration, the pages under this domain name http://www.qq.com/music.html and http://www.qq.com/login.html can all use OAuth2. .0 authentication. But http://pay.qq.com, http://music.qq.com, http://qq.com cannot perform OAuth2.0 authentication

3. If the official account login is authorized to If a third-party developer manages it, there is no need to make any settings. The third party can replace the official account to implement web page authorization

Explanation on the difference between the two scopes of web page authorization

1. The web page authorization initiated with snsapi_base as the scope is used to obtain the openid of the user who enters the page, and is Silently authorize and automatically jump to the callback page. What the user perceives is that he directly enters the callback page (often a business page)

2. The web page authorization initiated with snsapi_userinfo as the scope is used to obtain the user's basic information. However, this kind of authorization requires the user to manually agree, and since the user has agreed, there is no need to pay attention, and the user's basic information can be obtained after authorization.

3. The "Interface for Obtaining User Basic Information" in the user management interface can obtain the user's basic information based on the user's OpenID only after the user interacts with the official account or pushes the following event. This interface, including other WeChat interfaces, requires the user (i.e. openid) to follow the official account before it can be called successfully.

About the difference between web page authorization access_token and ordinary access_token

1. WeChat web page authorization is implemented through the OAuth2.0 mechanism. After the user authorizes the official account Afterwards, the official account can obtain a web page authorization-specific interface call credential (web page authorization access_token). Through the web page authorization access_token, the post-authorization interface call can be made, such as obtaining basic user information;

2. For other WeChat interfaces, you need to obtain the ordinary access_token call through the "Get access_token" interface in basic support.

About the UnionID mechanism

1. Please note that web page authorization to obtain basic user information also follows the UnionID mechanism. That is, if a developer needs to unify user accounts between multiple official accounts, or between official accounts and mobile applications, they need to go to the WeChat open platform (open.weixin.qq.com) to bind the official account before they can use UnionID mechanism to meet the above needs.

2. Description of the role of the UnionID mechanism: If a developer has multiple mobile applications, website applications and public accounts, the user can be distinguished by obtaining the unionid in the user's basic information, because the same user cannot Different applications (mobile applications, website applications and public accounts) under the same WeChat open platform have the same unionid.

About silent authorization in special scenarios

1. As mentioned above, for web page authorization with snsapi_base as the scope, the user is authorized silently No perception;

2. For users who have followed the official account, if the user enters the official account's web authorization page from the official account's session or custom menu, even if the scope is snsapi_userinfo, it is silent authorization. No perception.

Specifically, the web page authorization process is divided into four steps:

1. Guide the user to enter the authorization page to agree to the authorization and obtain the code

2. Exchange the code for the web page authorization access_token (with the basic The access_token in support is different)

3. If necessary, developers can refresh the web page authorization access_token to avoid expiration

4. Obtain user basic information through web page authorization access_token and openid (supports UnionID mechanism)

Step 1: The user agrees to authorize and obtain the code

Make sure that the WeChat public account is authorized Under the premise of the permissions of the scope (scope parameter) (after the service account obtains the advanced interface, it will have snsapi_base and snsapi_userinfo in the scope parameter by default), guide the followers to open the following page:

Special note: Due to the high security level of authorization operations, when initiating an authorization request, WeChat will perform a regular strong matching check on the authorization link. If the order of the parameters of the link is No, the authorization page will not be accessible normally

Special note: the jump callback redirect_uri should use an https link to ensure the security of the authorization code.

Parameter Description

##stateNo After redirection, the state parameter will be carried. Developers can fill in the parameter value of a-zA-Z0-9, up to 128 bytes #wechat_redirect YesWhether you open it directly or do a 302 redirection of the page, you must bring this parameter

The following picture shows the authorization page when scope is equal to snsapi_userinfo:

After the user agrees to the authorization

If the user After agreeing to the authorization, the page will jump to redirect_uri/?code=CODE&state=STATE.

Step 2: Exchange the webpage authorization access_token through the code

First of all, please note that what is exchanged through the code here is a special webpage authorization access_token, which is the same as the basic The access_token in support (the access_token is used to call other interfaces) is different. Official accounts can obtain web page authorization access_token through the following interface. If the scope of web page authorization is snsapi_base, in this step, while obtaining the web page authorization access_token, the openid is also obtained, and the snsapi_base style web page authorization process ends here.

Special note: Since the secret of the public account and the obtained access_token have a very high security level, they must only be saved on the server and are not allowed to be passed to the client. Subsequent steps such as refreshing access_token and obtaining user information through access_token must also be initiated from the server.

Request method

Parameter Description

Parameter	Is it necessary	Description
appid	Yes	The unique identifier of the official account
redirect_uri	is the callback link address for	redirection after authorization. Please use urlencode to modify the link. Processing
response_type	is the	return type, please fill in the code
scope	is	application authorization scope, snsapi_base (the authorization page does not pop up, jumps directly, and can only obtain the user's openid), snsapi_userinfo (the authorization page pops up, and the nickname, gender, and location can be obtained through openid.Moreover, Even if the user is not paying attention, as long as the user authorizes it, the information can be obtained)

of the official account

Parameter	Is it necessary	Description
appid	is the unique identifier of the	official account
secret	is the appsecret
code	is	Fill in the code parameter obtained in the first step
grant_type	Yes	fill in authorization_code

Return instructions

The JSON data packet returned when correct is as follows:

##access_tokenWeb page authorization interface call credential, note: this access_token is different from The basic supported access_tokens are differentexpires_inAccess_token interface call credential timeout, unit (second)refresh_tokenUser refresh access_tokenopenidThe user’s unique identifier. Please note that when the user does not follow the official account, accessing the official account’s webpage will also generate A unique OpenID for a user and official account##scope

When an error occurs, WeChat will return the JSON data packet as follows (the example is an invalid Code error):

Step 3: Refresh access_token (if necessary)

Since access_token has a short validity period, when access_token times out, you can use refresh_token to refresh , refresh_token is valid for 30 days. When refresh_token expires, the user needs to re-authorize.

Request method

Parameters	Description
The scope of user authorization, separated by commas (,)

Parameter	Is it necessary	Description
appid	Yes	The unique identifier of the public account
grant_type	is	, filled in as refresh_token
refresh_token	is	Fill in the refresh_token parameter obtained through access_token

Return instructions

The JSON data packet returned when correct is as follows:

##access_tokenWeb page authorization interface call credential, note: this access_token is different from The basic supported access_tokens are differentexpires_inAccess_token interface call credential timeout, unit (second)refresh_tokenUser refresh access_token##openid##scopeUser authorization Scope, separated by commas (,)

When an error occurs, WeChat will return the JSON data packet as follows (the example is an invalid code error):

Step 4: Pull user information (the scope needs to be snsapi_userinfo)

If the web page authorization scope is snsapi_userinfo, the developer can User information is pulled through access_token and openid.

Request method

Parameter description

Parameters	Description
User unique identification

Parameter	Description
access_token	Web page authorization interface Call credentials, note: this access_token is different from the basic supported access_token
openid	The user’s unique identification
lang	Return to the country and region language version, zh_CN simplified, zh_TW traditional, en English

Return instructions

Parameters	Description
openid	The user’s unique identifier
nickname	User nickname
sex	The gender of the user, when the value is 1, it is male, when the value is 2, it is female , when the value is 0, it is unknown
province	The province filled in by the user’s personal information
city	City filled in for ordinary users’ personal information
country	Country, such as China is CN
headimgurl	User avatar, the last value represents the square avatar size (0, 46, 64, 96, 132 values ​​are available, 0 represents a 640*640 square avatar), this item is empty when the user does not have an avatar. If the user changes their avatar, the original avatar URL will be invalid.
privilege	User privilege information, json array, such as WeChat Woka user is (chinaunicom)
unionid	This field will only appear after the user binds the official account to the WeChat open platform account.

When an error occurs, WeChat will return the JSON data packet as follows (the example is invalid openid):

Attachment: Verify whether the authorization certificate (access_token) is valid

Request method

Parameter description

##openidThe user’s unique identification

Parameter	Description
access_token	Web page authorization interface Call credentials, note: this access_token is different from the basic supported access_token

Return instructions