Skip to main content
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.
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

JavaScript

Hosted sign-in, callback, session and logout.

React

Client state and protected application views.

Next.js

Server sessions, callback routes and cookies.

iOS

System browser and secure token storage.

Android

Browser authorization and app callbacks.

React Native

Native authentication wrapper preparation.

Flutter

Native authentication wrapper preparation.

​
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. Use the shared integration prompt for any combination. See tokens and JWKS, events and webhooks, migration, and bot protection.