Passkey setup

Passkeys require a verified association between your native app and its relying party domain. Configure the platform association file, app signing, and the OwnID Console before adding an authentication or enrollment flow.

OwnID Android SDK supports API 23+, but Android passkeys require API 28+.
OwnID iOS SDK supports iOS 13+, but passkeys require iOS 16+.

Configure your platform

Android
iOS

OwnID uses Android Credential Manager for passkey creation and authentication.

Add Credential Manager

Use the current AndroidX Credentials version for both artifacts:

build.gradle.kts

dependencies {
    implementation("androidx.credentials:credentials:<latest-version>")
    implementation("androidx.credentials:credentials-play-services-auth:<latest-version>")
}

See the AndroidX Credentials release notes for version-specific changes.

Publish Digital Asset Links

Host assetlinks.json at this exact URL:

https://<relying-party-domain>/.well-known/assetlinks.json

The endpoint must be public over HTTPS, return HTTP 200 with a JSON content type, and must not redirect. Allow automated retrieval of /.well-known/assetlinks.json; if the domain uses robots.txt, make sure it does not block /.well-known/.

assetlinks.json

[
  {
    "relation": [
      "delegate_permission/common.handle_all_urls",
      "delegate_permission/common.get_login_creds"
    ],
    "target": {
      "namespace": "android_app",
      "package_name": "<android_application_id>",
      "sha256_cert_fingerprints": [
        "<sha256_signing_certificate_fingerprint>"
      ]
    }
  }
]

Cover every signed app variant

Add an entry for every application ID and SHA-256 signing certificate that should use passkeys, including relevant debug, release, and product-flavor builds.You can inspect a keystore certificate with:

keytool -list -v -keystore <path-to-keystore>

See Android’s Credential Manager prerequisites and Digital Asset Links guidance for validation requirements.

OwnID uses Apple’s AuthenticationServices framework for passkey creation and authentication.

Add the Associated Domains capability

In Xcode, open your app target, select Signing & Capabilities, and add Associated Domains. Add the relying party domain without a protocol or path:

webcredentials:<relying-party-domain>

Xcode Associated Domains capability with a webcredentials domain entry — Associated Domains capability configured for web credentials

Enable Associated Domains for the matching App ID in Apple Developer as well. If the app uses manual signing, regenerate and install its provisioning profiles after enabling the capability.

Publish the Apple App Site Association file

Host the extensionless file at this exact URL:

https://<relying-party-domain>/.well-known/apple-app-site-association

The endpoint must be public over HTTPS, return HTTP 200 with a JSON content type, must not redirect, and its uncompressed content must stay at or below 128 KB.

apple-app-site-association

{
  "webcredentials": {
    "apps": [
      "<APP_ID_PREFIX>.<BUNDLE_ID>"
    ]
  }
}

Verify the signed application identifier

Add every app target that should use passkeys. Each <APP_ID_PREFIX>.<BUNDLE_ID> value must match the signed app’s application-identifier entitlement.The App ID prefix is often your Apple Team ID, but it can differ. Use the prefix from the signed app or provisioning profile.

See Apple’s Supporting associated domains and Associated Domains entitlement references for signing and validation requirements.

Configure the OwnID Console

Use the Android application ID and signing certificate fingerprint or iOS bundle ID that corresponds to the values in each association file.

Open the native app settings

OwnID Console Native Apps configuration screen — Native Apps configuration in the OwnID Console

Add platform identifiers

Android
iOS

Enter the Android application ID and SHA-256 signing certificate fingerprint. They must match an entry in assetlinks.json.

Save the configuration

Save your changes before testing passkey creation or authentication.

Verify the association

The association files must be publicly accessible in every environment where passkeys are tested or used. The endpoints must not require a password, Basic Auth, SSO, cookies, VPN access, mTLS, an IP allowlist, or an interactive WAF or bot-protection challenge.

Verify the association files on the exact HTTPS host used as the relying party domain.

Android
iOS

Fetch the association file directly without following redirects:

https://<relying-party-domain>/.well-known/assetlinks.json

Confirm that the endpoint:

Returns HTTP 200 with Content-Type: application/json
Does not redirect
Returns valid JSON rather than an HTML login or error page
Is accessible from a public network without authentication or VPN access
Allows automated retrieval and is not blocked by robots.txt

Confirm that the Android application ID and certificate fingerprints match the installed build and the OwnID Console configuration.Validate the hosted file with Google’s Statement List Generator and Tester. Select Credential Sharing as the relation type.

Fetch the association file directly without following redirects:

https://<relying-party-domain>/.well-known/apple-app-site-association

Confirm that the endpoint:

Returns HTTP 200 with a JSON content type
Does not redirect
Returns valid JSON rather than an HTML login or error page
Is accessible from a public network without authentication or VPN access
Is accessible regardless of client IP address, region, or User-Agent

Verify the Associated Domains capability for your app target in Xcode:

Open the app target’s signing and capabilities settings and find Associated Domains. If the capability is not present, add it to the target.
Confirm that its domain list contains the exact relying party host in this format:
webcredentials:<relying-party-domain>
Do not include https://, a path, query parameters, or a trailing slash.
Confirm that the same host is used for the passkey relying party domain and the apple-app-site-association URL.
Confirm that webcredentials.apps contains the app’s exact <APP_ID_PREFIX>.<BUNDLE_ID> value.

Allow time for updates

Association files may be cached by your hosting provider, CDN, and the platform verification services. Updating the file on the origin server does not guarantee that Android or Apple devices receive the new version immediately. Inspect the response headers for each association file:

curl -sS -D - -o /dev/null \
  https://<relying-party-domain>/.well-known/<association-file>

Review Cache-Control, Age, Expires, ETag, and Last-Modified. Avoid long cache lifetimes, such as one week, if you expect to update the association files. A long max-age can keep an earlier version valid after the origin file has changed.

Google Digital Asset Links determines statement validity from the underlying data TTL, subject to implementation limits. The Digital Asset Links API returns maxAge, which indicates how much longer its result should be considered valid.
Apple’s CDN normally requests the apple-app-site-association file within 24 hours. Devices check for updates approximately once per week after installation. Apple does not provide manual cache invalidation. See Supporting associated domains.

After an update, first confirm that the public endpoint returns the new file and review its current cache headers. For complete platform setup and troubleshooting, see the Android SDK passkey guide or iOS SDK passkey guide.

OwnID Authentication

SDK Integration

Connectors

Social Providers

Mobile SDKs

Branding & Customization

Platform Overview

Changelog

Configure your platform

Configure the OwnID Console

Verify the association

Allow time for updates

​Configure your platform

​Configure the OwnID Console

​Verify the association

​Allow time for updates

Configure your platform

Configure the OwnID Console

Verify the association

Allow time for updates