WeChat OAuth2.0 Mobile Application Login Integration Guide

Reference: WeChat Open Platform documentation (https://open.weixin.qq.com/cgi-bin/showdocument?action=dir_list&t=resource/res_list&verify=1&id=open1419317851&token=&lang=zh_CN).

Preparation : Mobile app WeChat login is built on the OAuth2.0 standard. Before integration, register a developer account on the WeChat Open Platform, obtain an approved mobile app with its AppID and AppSecret, and apply for WeChat login approval.

Only native login is provided; the user must have the WeChat client installed.

Android recommendation : Always display the WeChat login button and guide users to install the WeChat client if it is missing.

iOS recommendation : Use the SDK’s isWXAppInstalled function to detect the client; hide the WeChat login button for users without the client and offer alternative login methods.

Authorization process : WeChat OAuth2.0 login lets users securely log in to third‑party apps, after which the app receives an access_token that can be used to call WeChat Open Platform APIs for basic user information and other functions.

The current flow supports the authorization_code mode, suitable for server‑side applications. The overall steps are:

Third‑party initiates a WeChat login request; after user consent, WeChat redirects back with a temporary authorization code ( code ).

The server exchanges the code , AppID , and AppSecret for an access_token via the API.

Using the access_token , the server calls further APIs to obtain user data or perform actions.

Step 1 – Request code : The mobile app uses the WeChat SDK to launch the WeChat client for authorization. After the user approves, the client returns a code to the app, which then forwards it to its own server.

Required parameters:

appid (required) – the unique application identifier.

scope (required) – e.g., snsapi_userinfo to obtain user info.

state (optional) – a random string to maintain request state and mitigate CSRF attacks.

Sample response:

ppid: wxd477edab60670232
scope: snsapi_userinfo
state: wechat_sdk_demo

Error codes: ERR_OK = 0 (user agrees), ERR_AUTH_DENIED = -4 (user denies), ERR_USER_CANCEL = -2 (user cancels).

Additional returned fields include code , state , lang , and country .

Step 2 – Exchange code for access_token : Send a GET request to:

https://api.weixin.qq.com/sns/oauth2/access_token?appid=YOUR_APPID&secret=YOUR_APPSECRET&code=CODE_FROM_STEP1&grant_type=authorization_code

Parameters:

appid (required) – your AppID.

secret (required) – your AppSecret.

code (required) – the authorization code obtained in step 1.

grant_type (required) – must be authorization_code .

Sample JSON response:

{
  "access_token":"ACCESS_TOKEN",
  "expires_in":7200,
  "refresh_token":"REFRESH_TOKEN",
  "openid":"OPENID",
  "scope":"SCOPE",
  "unionid":"o6_bmasdasdsad6_2sgVt7hMZOPfL"
}

Field meanings:

access_token – API call credential.

expires_in – validity period in seconds.

refresh_token – token to refresh the access token.

openid – unique identifier of the authorized user.

scope – granted permission scopes.

unionid – appears only if the user has linked a public account.

Step 3 – Retrieve user info : Call the user‑info endpoint with a valid access_token :

https://api.weixin.qq.com/sns/userinfo?access_token=ACCESS_TOKEN&openid=OPENID&lang=zh_CN

Required conditions:

The access_token must be valid and not expired.

The user must have granted the requested scope .

Typical response fields include nickname , openid , and unionid .

Step 4 – WeChat login and phone‑number binding : After login, check the is_bind flag. If false, direct the user to a phone‑binding page and call the binding API; if true, return a login token.

Login API example:

http://url/1.0/user/wechat/login

Sample response:

{"code":0,"msg":"成功","data":{"token":"","is_bind":false}}

Phone‑binding API example (parameters omitted for brevity).

Step 5 – Re‑login : When a user logs in again, the client sends the previously obtained access_token . The server validates it with WeChat; if valid, no new authorization is needed, otherwise a fresh authorization flow is triggered.

Step 6 – Test cases : The document lists 18 test scenarios covering first‑time login, repeated login, phone‑number binding, cross‑account binding, network conditions, and failure handling.

Disclaimer : For more original articles, visit the "FunTester" album (https://mp.weixin.qq.com/s?__biz=MzU4MTE2NDEyMQ==&mid=2247485855&idx=2&sn=b0e6f7304039de579352adeb7a69905d&scene=21#wechat_redirect). Collaboration inquiries can be sent to [email protected] .

Featured links: Interface testing album, Performance testing topics, Programming mindset article, Java performance guide, Selenium parallel testing best practices, UI testing plan, Software testing outsourcing, etc.