Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.corbado.com/llms.txt

Use this file to discover all available pages before exploring further.

Try Demo

Talk to Adoption Engineer

Whitepaper
For security reasons, some of our Web UI components and SDK methods require a so-called connect token to authorize actions that modify user data. Specifically, you will need to provide a connect token for the following: A connect token is a short-lived, single-use token that securely ties a user’s context (e.g., which account is being updated) to a particular action (such as passkey creation, listing, or deletion). Whenever a flow needs to safely reference a specific user’s account for passkey management, a connect token is required. These tokens are created on your server (server-to-server via the Corbado Backend API) and then passed to the relevant front-end component or SDK method.
  1. Frontend requests a connect token: Your web or native/mobile application makes a secure API call to your backend to request a connect token.
  2. Backend generates a connect token: Your backend makes a secure API call to Corbado’s /v2/connectTokens endpoint (see API Reference). This call identifies the user (for example, through a customerIdentifier) and specifies the intended action ("passkey-append", "passkey-list", or "passkey-delete").
  3. Token includes user-specific data: The response from Corbado includes a unique connect token (e.g., ctk1_sxmexzS7RFBaJSA4V4kBFPs45bkxMK). This token tells the Corbado Web UI Component or SDK method precisely which user and action it is authorized for (e.g., “create a new passkey for user 123”).
  4. Frontend consumes the connect token: On the frontend or native/mobile application, the Corbado Web UI Component or SDK method receives the token and initiates the passkey flow. During this process, Corbado checks the token’s validity.
  5. Short-lived & single use: Each connect token expires after a short period (configurable in Corbado’s systems) and is valid for one passkey operation (e.g., a single passkey creation). Once expired or used, it cannot be reused. This design helps prevent replay attacks and unauthorized reuse.
In summary, every time a passkey management flow runs (like passkey creation or passkey deletion), your backend will need to generate a connect token for the specific user and action.