Skip to main content
Early access: didit_auth is release-dependent. Distribution coordinates, versions and callable signatures are not confirmed here. Do not install a guessed package or use the Identity verification SDK as an Authentication SDK.

​
Prepare the application

  1. Confirm that Authentication is enabled for your Didit application and obtain its runtime URL.
  2. Register an exact callback URL supported by your application and the runtime. Validate app-link ownership; do not assume arbitrary custom URL schemes are accepted.
  3. Keep sandbox and live configuration separate, including callback handling and stored credentials.
  4. Choose your stable person mapping before connecting verification or monitoring.
Configure and test callback links separately on iOS and Android. The Authentication wrapper is separate from didit_sdk, which handles verification.

​
Implement the hosted flow

Open the native system authentication browser with the configured runtime’s sign-in/ URL. Supply a fresh random state, an S256 PKCE challenge and your registered redirect_uri. Keep the verifier in your app for that attempt only. The JavaScript quickstart shows the underlying protocol; use platform cryptography and URL handling rather than browser globals in native code. On callback, verify state, transaction lifetime and callback destination before exchanging the single-use code at token/. Use the original verifier and exact redirect URI. Canceling or dismissing the browser is not a successful login. Store refresh tokens in native platform-protected storage; never in a plain preferences file, analytics or crash logs. Validate the current session using GET session/ with the end-user Bearer token. Serialize refresh, replace both tokens together, and clear user-specific state after sign-out. See tokens and JWKS for the request contract and refresh-reuse behavior.

​
Native SDK release preview

The native Authentication modules are planned to provide sign-in, current-session access, token retrieval, sign-out and step-up, with automatic device signals. Native passkeys and protected token storage are part of that release. Wrapper APIs will follow their published platform contracts; do not copy guessed constructor arguments or method signatures from a design example. Until the module is released, keep its adapter disabled or use a reviewed implementation of the hosted protocol for your enabled application. Do not advertise a working native Authentication quickstart based only on package installation.

​
Connect verification and monitoring

Your backend derives vendor_data from the authenticated person. It creates verification sessions or mints scoped monitoring tokens for that person. Return only the session credential or scoped token to your app; the API key stays on the server. Use the Flutter verification SDK when you need Identity verification. Follow SDK transaction submission for monitoring support on your platform. Treat sign-in, verification and transaction decisions separately.

​
Verify the integration

Test returning to a cold app, background and foreground transitions, browser cancellation, a mismatched callback, code replay, token expiry, concurrent refresh, MFA, logout and signing in as another user. Test passkey enrollment and sign-in on supported devices once that release is available. A device-only check remains unverified until it runs on the target platform.