> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Authentication

> Add end-user sign-in to your application and connect it to identity verification and transaction monitoring.

<Warning>
  Authentication is in early access. The hosted runtime described here requires an enabled application and confirmed runtime URL. The new Authentication SDKs, per-application JWT issuer, automatic monitoring events and advanced bot protection are release-dependent. Do not assume they are available because a package or capability appears in this guide.
</Warning>

Authentication signs your customers into **your application**. It is separate from signing into the Didit console, creating a Didit developer account, and verifying someone's identity.

Use Authentication alone, or combine it with Identity verification and Transaction monitoring. Signing in does not approve a verification or authorize a payment. Your backend makes those decisions using the relevant product's verified result.

## Choose your platform

<CardGroup cols={2}>
  <Card title="JavaScript" href="/authentication/quickstarts/javascript" icon="code">Hosted sign-in, callback, session and logout.</Card>
  <Card title="React" href="/authentication/quickstarts/react" icon="code">Client state and protected application views.</Card>
  <Card title="Next.js" href="/authentication/quickstarts/nextjs" icon="code">Server sessions, callback routes and cookies.</Card>
  <Card title="iOS" href="/authentication/quickstarts/ios" icon="mobile">System browser and secure token storage.</Card>
  <Card title="Android" href="/authentication/quickstarts/android" icon="mobile">Browser authorization and app callbacks.</Card>
  <Card title="React Native" href="/authentication/quickstarts/react-native" icon="mobile">Native authentication wrapper preparation.</Card>
  <Card title="Flutter" href="/authentication/quickstarts/flutter" icon="mobile">Native authentication wrapper preparation.</Card>
</CardGroup>

## Prepare your application

1. Confirm that Authentication is enabled for your Didit application. Keep sandbox and live applications, origins, redirects and identities separate.
2. Register exact callback URLs and browser origins. Do not use wildcard redirects. Local HTTP callbacks are for sandbox only.
3. Obtain the runtime base URL for that application. The current runtime uses `/auth/v2/authentication/{application_id}/` on your confirmed authentication origin. Do not construct a hosted subdomain from an application name.
4. Enable the sign-in methods you intend to offer. Hosted sign-in presents configured methods and handles required second factors.
5. Test sign-up, sign-in, forgot password, MFA, session expiry and logout before enabling the flow for customers.

Hosted methods include password, email code, magic link, passkey, phone, Didit ID Wallet and organization SSO when configured. A passkey belongs to its relying-party domain; changing the hosted domain can require enrolling it again. Never promise that existing passkeys migrate across domains.

## Keep one person across products

Choose a stable, non-sensitive identifier from your own user system. Use that value for `vendor_data` in verification sessions and scoped monitoring tokens. Derive it on your backend from the authenticated user, never from an unchecked browser field.

The release-dependent Authentication identity contract uses your `external_id` at creation or import as `vendor_data`, or the Didit identity ID when you do not supply one. Once events exist, this link cannot change. The current opaque-token runtime does not return `vendor_data`; maintain an explicit server-side mapping from its verified `sub` until the new contract is enabled. Do not send an undocumented `external_id` to an authorization request.

| Product combination | What you build |
| - | - |
| Identity verification | Create a verification session and consume the decision. |
| Transaction monitoring | Submit transactions or application events for your own authenticated users. |
| Authentication | Sign in, validate sessions and sign out. |
| Identity verification + Transaction monitoring | Reuse the same `vendor_data` for checks and transactions. |
| Identity verification + Authentication | Start verification after sign-in when your policy requires it. |
| Transaction monitoring + Authentication | Bind scoped monitoring tokens to the signed-in person. |
| All three | Use the same person mapping while handling each product's decision separately. |

Use the [shared integration prompt](/integration/integration-prompt) for any combination. See [tokens and JWKS](/authentication/tokens-and-jwks), [events and webhooks](/authentication/events-and-webhooks), [migration](/authentication/migration), and [bot protection](/authentication/bot-protection).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.