Configuring Origins for a Native Authenticator App
This page expands on the Origins field section of the main Passkey Authentication configuration guide, specifically for deployments where passkeys are registered and used through a custom native application on Android and/or iOS, rather than (or in addition to) a web browser.
When a passkey ceremony is initiated from a native app instead of a browser, the "origin" reported to the relying party is no longer a normal https:// web address. Both Android and iOS have their own conventions for representing "this request came from a trusted native app" as an origin value — and both require the app to prove, via a small JSON file hosted on your domain, that it is actually allowed to act on that domain's behalf.
You'll need to add these native-app origin values to the Origins field (one per line, alongside any normal web origins you use) so that Trivore ID accepts passkey requests coming from the app.
Android origins
For a native Android app, the origin is not the website's URL — it's derived from the SHA-256 hash of the app's signing certificate, in the form:
android:apk-key-hash:<base64url-encoded SHA-256 fingerprint>
This value is unique per signing key, so in practice you will typically have one entry per build variant — for example, one for your debug/development signing key and one for your production release signing key. If the app is signed with multiple certificates (e.g. Play App Signing plus a local upload key), each one needs its own android:apk-key-hash:... entry in Origins.
Before Android will allow the app to participate in passkey ceremonies for your domain at all, you must also publish a Digital Asset Links file at:
https://<your-domain>/.well-known/assetlinks.json
declaring your app's package name and signing certificate fingerprint(s), with the delegate_permission/common.get_login_creds permission. Android verifies this file to confirm your domain and app are linked before it will hand your app's requests to the relying party.
References:
iOS origins
iOS handles this differently: a native app's passkey requests use the same origin as your website (i.e. https://<your-domain>) — there is no special ios:...-style origin scheme. Instead of encoding trust into the origin value itself, iOS establishes trust through Associated Domains: the app declares which web domains it's associated with, and your server publishes a matching file confirming the association.
To enable this, you host a file at:
https://<your-domain>/.well-known/apple-app-site-association
which lists the app's identifier (Team ID/App ID prefix + bundle identifier) under a webcredentials entry. The app must also declare the domain (prefixed with webcredentials:) under the Associated Domains capability in its own configuration.
Because the reported origin is simply your normal https://<your-domain> web origin, you generally don't need to add a separate entry to the Origins field for iOS — as long as that origin is already covered by your existing configuration (either explicitly listed, or via the default https://<identifier> origin described in the main Origins section).
References:
- Supporting passkeys – Apple Developer Documentation
- Connecting to a service with passkeys – Apple Developer Documentation
Summary
| Platform | Origin format | Extra requirement |
|---|---|---|
| Android | android:apk-key-hash:<hash> (one per signing certificate) | assetlinks.json published on your domain |
| iOS | Same as your web origin, https://<your-domain> | apple-app-site-association file + Associated Domains capability in the app |
Set up the Digital Asset Links (Android) and Associated Domains (iOS) files first — without them, the platform will refuse to let your app perform passkey ceremonies at all, regardless of what's configured in Trivore ID's Origins field.