> ## 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. # Android quickstart > Prepare Android Authentication: hosted login, callback validation, secure sessions and links to verification and monitoring. Early access: **DiditAuth for Android** 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. Use a system browser tab for hosted login and validate the returning app link. Native passkeys require the configured relying-party domain and platform credential flow. ## Implement the hosted flow Open a system browser tab 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](/authentication/quickstarts/javascript) 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 platform-protected encrypted 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](/authentication/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 [Android verification SDK](/integration/native-sdks/android-sdk) when you need Identity verification. Follow [SDK transaction submission](/transaction-monitoring/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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.