Complete sign-in on your server

Your backend turns a successful WeChat authorization into a session for your application. It owns the login attempt, credential lookup, account mapping, and final session issuance.

This guide assumes that your authorized backend receives the AppSecret supplied by NextAppMarket and performs the provider exchange. The route names used by your app to call that backend are part of your own API.

1. Create a login attempt

Generate a cryptographically random state, store it with the initiating session, intended WeChat AppID, expiry, and operation (sign_in or link_account), and return it to the app. Keep account-linking attempts bound to an already authenticated user.

Example state generation in Node.js:

import { randomBytes } from 'node:crypto';

const state = randomBytes(32).toString('base64url');
// Persist the state and its initiating session before returning it.

2. Validate the callback

Require a successful SDK result, the authorization code, and the matching state. Look up the stored attempt, check its expiry and session binding, and claim it atomically so concurrent callbacks cannot complete it twice.

The backend chooses the AppID and AppSecret from that trusted attempt. Do not accept an arbitrary credential or account-linking target from the callback body.

3. Exchange the code

The mobile OAuth exchange uses WeChat's GET /sns/oauth2/access_token endpoint with appid, secret, code, and grant_type=authorization_code. Perform it on your server using the assigned AppID and AppSecret.

A successful response supplies the authorized identity and provider token information. Check both the HTTP result and the provider JSON error fields before using it. Keep tokens on the backend and avoid logging the complete request URL, which includes a secret.

Treat the authorization code as a short-lived, single-use value. If exchange completion is uncertain, check whether your attempt already completed before asking the customer to authorize again. Do not repeatedly reuse a rejected or expired code.

4. Resolve the account

Use the verified identity returned by the exchange. Store an application-scoped mapping for the WeChat AppID and openid. If unionid is returned, use it only within the verified Open Platform account scope that applies to your applications; do not assume it is always present or globally unique across unrelated registrations.

For account linking, require an authenticated local account and reject a WeChat identity already linked to another account unless your explicit account-recovery process resolves the conflict. A matching display name or avatar is not evidence that two accounts belong to the same person.

5. Issue your application's session

Complete the account update and login-attempt state atomically, then issue your application's session using your normal session controls. Return only what the app needs to establish that session. Fetch optional WeChat profile data only when the granted scope and your product require it.

Keep the provider access token separate from your app's session token. A customer logging out of your app should end the local session and clear the app's saved session credentials.

Verify completion

Test a new user, an existing user, a repeated callback, a mismatched state, an expired attempt, and a linking conflict. Each successful attempt should resolve to exactly one local account.

Provider reference: WeChat mobile login flow. Exact provider token fields and expiry values should be read from the response and the SDK/service documentation applicable to your assigned application.