Account

Start from the application’s own login request

This is the OIDC Authorization Code flow. Login involves the browser, the business backend and Account. The backend first retains a short-lived original request with state, nonce and PKCE code-exchange protection, then directs the browser to Account’s authentication interface. Completion returns only to the application’s exact registered callback. Different applications may use independent domains.

The backend binds the callback to its original request, redeems the one-use code and verifies signature, issuer, audience, nonce and lifetime. Only then does it create its own session. An uncertain exchange requires a new login from the originating application; it grants no permission to resend a possibly consumed code or adopt another page’s request.

Keep login context and secrets in the application backend

Integration requires an explicit HTTPS issuer, confidential-client credentials, exact registered callback addresses and the requested identity claims. The browser visits the authentication interface; the application backend retains the original login context and exchanges tokens. The client secret is not part of frontend assets.

The backend generates independent state, nonce and PKCE material for every login and binds it to the initiating browser. Discovery, verification keys, HTTP transport and the eventual business session remain responsibilities of the integrating application. Access to the login page alone is not a complete integration.

1. Register the application and return location

   Select the issuer, client and exact callback address. Broad domain matching or redirect rules do not replace byte-exact callback matching.

2. Retain the original browser request

   Create a short-lived login context with fixed state, nonce, PKCE and browser binding, then begin the authorization redirect.

3. Create a session only after full verification

   Validate the original callback, exchange the code once and verify the signature and all required claims. The application then creates its own session.

Give every credential an explicit owner

An Account identity is never reused. Users can authenticate with passkeys or WeChat, Alipay, Douyin, Google, GitHub and Microsoft. External credentials are verified using the stable subject and identity scope defined by each provider. Email addresses, display names and profile information do not merge accounts.

An account can hold multiple passkeys and at most one identity for each external provider. Credential addition binds to the original authenticated account; it cannot create a replacement account or transfer an already owned identity. Removing provider configuration or changing application identifiers preserves historical namespaces, while current usability requires a separate configuration decision.

Use each proof only for its original action

Login intents and external addition flows have fixed deadlines. Reading a page or beginning another step does not extend them. Passkey challenges also bind the original browser, purpose and exact origin. A provider callback atomically claims its own flow before exchanging the provider code, so concurrent callbacks cannot dispatch the same exchange twice.

Passkeys require user verification and checks of signature, origin, the website’s RP ID and counter transition. An ordinary external callback does not establish fresh user authentication. Reauthentication or an unmet authentication-age requirement needs a new local passkey event, with the time taken from that actual verification.

Handle cancellation, expiry and uncertainty within the original login

A cancellation or provider error still requires checking that callback state belongs to the original browser request. An error on one page must not close another page’s login or borrow a different unexpired context. Adding a credential likewise remains bound to the original account.

When the code exchange is uncertain, do not create a verified session or redeem the possibly used code again. Preserve that result and let the user start a new login from the original application. Refreshing a page or waiting for network recovery does not extend the old flow’s fixed expiry.

• Admission condition: both the original callback and token are verified

  Issuer, audience, nonce, validity and signature must be checked while retaining the original browser binding before an application session can be created.

• Unsupported conclusion: an external return proves fresh authentication

  An ordinary OAuth callback does not prove a new local user verification. A request for fresh authentication needs the corresponding actual evidence.

• Check next: credential purpose and recipient

  ID Tokens, UserInfo access and machine authorization perform different tasks. Sharing an account does not make them interchangeable.

Issue different authority for different recipients

An ID Token identifies the account to its registered application. A UserInfo grant reads current identity information for the same account and client. A machine grant permits a backend to call the Transact payment service within an allowed scope. The three credentials have distinct purposes, resources and audiences and are not interchangeable.

Paid state is a persistent account flag. After the first confirmed positive collection, Transact requests that it be set; Account projects it into claims only for configured clients. Claim issuance makes no payment-system query and owns no amounts, balances, reserves or refund decisions. The permanent application-account association is established only when the original authorization code is successfully redeemed.

Keep restriction and maintenance within their authority

Operators can inspect accounts, application associations and credential configuration compatibility, and change local restrictions. Restrictions apply at actual authentication admission and commit boundaries, while users retain their own logout action. Other products’ sessions, issued offline ID Tokens and machine grants keep their independent authority.

Expired authentication records are reclaimed in bounded pages through a due-candidate index, preserving accounts, credentials, valid grants and paid state. Verification concerns include original-browser binding, concurrent first logins, duplicate callbacks, late proofs, overlapping verification keys and cleanup whose work does not become a full scan as the live-session population grows.