Skip to main content
Authentication is new. Didit turns the product on for your application. Until then, every runtime route for that application returns 404. The Authentication SDK packages are not published yet, so use the hosted flow and the HTTP contract on these pages.
Authentication signs your customers into your application. It is separate from signing into the Didit console or creating a Didit developer account. It is also separate from 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 from each product’s own result.

​
How it works

Each application gets its own sign-in origin and its own token issuer. Live and sandbox applications are separate: they have separate origins, settings and identities. The flow is OAuth 2.0 authorization code with PKCE (S256 only):
  1. Your app opens {origin}/sign-in with redirect_uri, state, code_challenge and code_challenge_method=S256.
  2. The hosted page signs the person in or up with the methods you enabled, including any required second factor.
  3. The browser returns to your redirect_uri with code and state.
  4. Your app exchanges the code at POST {origin}/token/ for an access token, an ID token and a refresh token.
See tokens and JWKS for the token contract and sign-in methods for each method.

​
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. Ask Didit to turn on Authentication for your application. Test in a sandbox application first.
  2. Register exact redirect_uris (up to 50) and the browser allowed_origins (up to 50) that call the runtime API. Redirects must use HTTPS. Wildcards, fragments and credentials are rejected. http://localhost is accepted only for sandbox applications.
  3. Enable the sign-in methods you want to offer. Didit ID Wallet is always on.
  4. Choose your session and password settings (see below).
  5. Test sign-up, sign-in, forgot password, MFA, session expiry and logout before you go live.
A passkey belongs to its origin. If you later activate a custom domain, people must enroll their passkeys again.

​
Application settings

You manage these settings in the console, or with an authorized console session that has write:authentication.

​
Keep one person across products

Every identity carries a vendor_data value. It is the external_id you supplied when you imported the person, or the Didit identity ID otherwise. It appears in the access token, the ID token and GET session/. Use the same value as vendor_data when you create verification sessions and submit transactions. Authentication events then land on the same person in the console as their verifications and transactions. See events and webhooks. Derive vendor_data on your backend from a verified token, never from an unchecked browser field. Use the shared integration prompt for any combination. Read bot protection for the policies that run at sign-in.