How OAuth2.0 Powers Third‑Party Login: From WeChat to Secure Token Flows

Third‑Party Authorization Login Overview

Third‑party authorization login lets users sign in to a new app by granting access to an existing account (e.g., WeChat, QQ, Sina) instead of creating a new password, simplifying registration and improving conversion.

For users: quick, password‑free login.

For developers: immediate access to basic profile data for personalization.

WeChat Authorization Login Example

A user taps the WeChat login button in an app, is redirected to the WeChat client, authorizes the app, and is sent back with a successful login indication. After the first authorization, WeChat records the consent, so subsequent logins skip the consent step.

Revoking WeChat Authorization

Users can navigate to WeChat → Settings → Personal Info → Authorization Management to view and revoke app permissions; revoked apps will require explicit consent on the next login attempt.

OAuth2.0 Protocol Standard

WeChat’s mobile login is built on the OAuth2.0 standard, an industry‑wide protocol that enables third‑party apps to access protected resources without handling user credentials directly.

Key Roles

Resource Owner : the user who owns the protected data.

Resource Server : stores the protected resources and validates access tokens.

Client : the application (mobile, web, desktop) requesting access on behalf of the user.

Authorization Server : authenticates the user and issues access tokens.

Important Terminology

Access Token : credential issued by the authorization server that grants the client access to resources.

Authorization Endpoint : URL where the client redirects the resource owner to grant consent.

Token Endpoint : URL where the client exchanges an authorization code (or other grant) for an access token.

OAuth2.0 Workflow Overview

Client requests authorization from the resource owner.

Resource owner grants permission and the client receives an authorization credential.

Client sends the credential to the authorization server’s token endpoint.

Authorization server validates the request and issues an access token.

Client presents the access token to the resource server.

Resource server validates the token and returns the protected resource.

Analogy: a visitor card issued at a building’s front desk represents the access token, allowing limited‑area entry for a defined period.

OAuth2.0 Grant Types

Password Grant (Resource Owner Password Credentials)

Client collects username/password and sends them to the token endpoint. Suitable only when the client is highly trusted.

// Token endpoint example
POST https://api.serviceprovider.com/auth/token

grant_type=password
username=USERNAME
password=PASSWORD
client_id=CLIENT_ID
client_secret=CLIENT_SECRET // optional

{
  "access_token": ACCESS_TOKEN
}

Client Credentials Grant

Client authenticates directly with its own ID and secret, without user involvement. Ideal for service‑to‑service communication.

// Token request
POST https://api.serviceprovider.com/auth/token

grant_type=client_credentials
client_id=CLIENT_ID
client_secret=CLIENT_SECRET // optional

{
  "access_token": ACCESS_TOKEN
}

Implicit Grant

Designed for browser‑only (SPA) applications; the token is returned directly in the URL fragment, avoiding a separate authorization‑code exchange.

// Authorization request (no client_secret)
https://image-storage-service.com/auth?
response_type=token&client_id=CLIENT_ID&scope=read_user_images&redirect_uri=https://your-app.com/callback

After user consent, the browser redirects to redirect_uri#access_token=ACCESS_TOKEN. The SPA extracts the token from the fragment.

Note: Returning the token in the fragment reduces exposure to man‑in‑the‑middle attacks because the fragment is not sent to the server.

Authorization Code Grant

Most secure flow for apps with a backend. The client first obtains an authorization code, then exchanges it for an access token.

High security: separates code and token exchange.

Supports backend processing of sensitive data.

Widely used in web and mobile apps.

Fine‑grained permission control.

WeChat Mobile App Authorization Code Flow

1. Register the app on the WeChat Open Platform to obtain AppId and AppSecret. AppId uniquely identifies the app. AppSecret authenticates the app.

2. Request user authorization via the WeChat SDK (iOS and Android examples below).

// iOS example
SendAuthReq *req = [[SendAuthReq alloc] init];
req.scope = @"snsapi_userinfo";
req.state = @"wechat_sdk_demo_test";
[WXApi sendReq:req];

// Android example
SendAuth.Req req = new SendAuth.Req();
req.scope = "snsapi_userinfo";
req.state = "wechat_sdk_demo_test";
api.sendReq(req);

3. After user consent, WeChat returns an authorization code to the app.

4. The app sends the code to its backend, which calls the token endpoint:

https://api.weixin.qq.com/sns/oauth2/access_token?appid=APPID&secret=SECRET&code=CODE&grant_type=authorization_code

{
  "access_token": ACCESS_TOKEN,
  "expires_in": 7200,
  "refresh_token": REFRESH_TOKEN,
  "openid": OPENID,
  "scope": "snsapi_userinfo",
  "unionid": UNIONID
}

5. Backend uses the access token to call WeChat’s user‑info APIs.

Token Refresh

When an access token expires, the client can use the refresh_token to obtain a new access token without user interaction, improving user experience and security.

Extends access without re‑login.

Limits exposure because short‑lived access tokens reduce attack windows.

Allows centralized revocation of refresh tokens.

Refresh tokens should be stored securely on the server side; leaking them would allow an attacker to obtain fresh access tokens indefinitely.

Summary

OAuth2.0 is an industry‑standard protocol for delegating access to protected resources.

WeChat mobile and web logins are implementations of OAuth2.0.

Four grant types exist; WeChat currently supports the Authorization Code Grant for secure mobile/web login.

Access tokens grant resource access; refresh tokens enable seamless token renewal.