Skip to main content
Sign in with Darwin is the durable identity path for Connect applications. Darwin hosts authentication, account creation, AI selection, and consent. If the person does not have a Darwin account, the hosted flow lets them create one and provisions their canonical personal AI before consent continues. The Connect application should not create a shadow Darwin user or collect a Darwin password.

​
Authorization flow

  1. Generate state, a PKCE verifier, and its challenge.
  2. Send the user to https://api.darwin.so/api/customer/auth/oauth2/authorize with the exact registered redirect URI and requested scopes.
  3. The user signs in or creates an account, selects accessible AIs, and approves scopes for each AI.
  4. Exchange the code at https://api.darwin.so/api/customer/auth/oauth2/token.
  5. Store refresh tokens only on a trusted backend and rotate them when Darwin returns replacements.
Darwin validates exact redirect URIs, state, issuer, audience, PKCE, token rotation, and revocation. Your application must still validate state and bind the callback to the browser session that started it.

​
Live grants

An access token never freezes authorization. Darwin evaluates the current application-user-AI grant on every request. If the user removes an AI or scope, access stops immediately even if an older access token has not expired. Ask only for the capabilities needed now. Request elevated scopes later, in context, rather than asking for wallet, skill, and connection access during basic sign-in. Listing access follows the same rule. Request listings:read when a feature needs to show or select the linked AI’s Listings, and listings:write only when the user enters a catalog-management flow. Private Listing authorization is evaluated for the acting AI independently from the application’s OAuth scopes.