简体中文
OAuth and identity

Third-party account authorization boundary

Use the official authorization domain, PKCE S256, and isolated app grants without exposing account credentials to a proxy.

Third-party account authorization boundary

Status: the OAuth authorization description, token exchange, revocation contracts, and DPoP are in the verified public-only artifact. A real app, official authorization domain, and redirect URI still require platform enablement. This page provides no curl command, server URL, or speculative token example.

Users enter their email, password, and MFA only on the official Ayalink authorization domain. A third party must not proxy, embed, or imitate the Ayalink sign-in page, collect account factors, or receive or forward the Ayalink global-session Cookie. Third-party authorization is limited to Authorization Code with PKCE: every attempt uses high-entropy state, nonce, and code_verifier, only S256, and an exactly registered HTTPS redirect_uri.

A session is not a grant

The Ayalink global session serves Ayalink-owned domains only. A third-party app grant is separate, minimal, and revocable. It is constrained to a specific app, installation, store/resource, audience, and user-approved scopes. It cannot become a platform session or prove ownership of another store or resource.

Do not put access tokens, refresh tokens, authorization codes, or verifiers in URLs, localStorage, sessionStorage, IndexedDB, analytics, logs, error reports, support tickets, or recordings. For a durable session, use a same-origin BFF. The BFF stores only its own app grant and gives its frontend an HttpOnly, Secure, appropriately SameSite application-session Cookie. It never forwards an Ayalink Cookie and never asks for an Ayalink password or MFA.

Phishing warning and recovery

A malicious proxy can copy the page appearance, use a look-alike domain, terminate TLS, inject scripts, and record every input. Before authorizing, check the official authorization domain in the browser address bar. Never enter Ayalink credentials through chat, email, or a third-party page. If compromise is suspected, close the page, revoke the affected app/installation grant from an official entry point, sign out of Ayalink sessions, update the password and reconfigure MFA, then report through the official security channel. Never send a token, Cookie, or verification code to a third party.

DPoP is declared by the public contract. Refresh-token rotation, token-family replay detection, and a user grant-management entry point are still not declared by the artifact, so do not design a production dependency around them. Use the API Reference for executable methods, paths, and schemas.

Copyright © 2026