loading
Preparing LoginRadius developer resources
Mission: Help enterprises accelerate digital transformation with our fully-managed Customer IAM technology.
Skip to main content

Passkeys

Passkeys replace passwords with public-key cryptography. Instead of a shared secret, your device holds a private key that never leaves it — the server only ever sees the public key. This makes passkeys resistant to phishing and credential theft by design, since there is no password to steal or replay.

Users authenticate through whatever their device already supports: biometrics (Face ID, Touch ID, fingerprint readers), a PIN, or Windows Hello. For shared or cross-device scenarios, external security keys (e.g., USB-based FIDO2 keys) work too.

For a deeper look at how WebAuthn and passkeys work, see the FIDO Alliance passkey documentation — the consortium behind the passkey web standard.

This document covers passkey key features, common use cases, Admin Console configuration, and API implementation.

Key Features

  • No passwords — authentication is based on a key pair, so there are no weak or reused passwords to worry about.
  • Phishing resistant — the private key is bound to a specific origin, so it cannot be used on a fake site.
  • Simple for users — login happens through biometrics or a device PIN, with no passwords to remember or type.
  • Works across devices and platforms — supports built-in device authenticators (Face ID, Windows Hello, PINs) as well as portable external security keys for cross-device use.

Business Use Cases

  • Employee login: Reduce password reset requests and IT overhead by giving employees a faster, more secure way to sign in.
  • Customer account security: Protect users from phishing and credential stuffing without adding friction to the login experience.
  • User registration: New users can sign up without creating a password, which lowers drop-off at onboarding.
  • Regulatory compliance: Passkeys support strong authentication requirements in regulated industries (finance, healthcare) and align with standards like GDPR and SOC 2.
  • Multi-device access: Users can authenticate on new devices using a synced passkey or an external security key, without going through password resets or extra MFA prompts.

Configuration

The Configuration section guides you through setting up Passkeys in the Admin Console and explains their usage via APIs.

If you encounter a 'Feature not available' message, it means that the particular feature is not enabled in your account. Please contact the LoginRadius support team for assistance in enabling this feature.

Admin Console Configuration

  • Navigate to Authentication > Authentication Configuration > Passkeys section of the LoginRadius admin console.

  • Enable the Passkey Authentication toggle.

  • Configure the following settings as per the business requirements:

    • Passkey Selection: Choose between Autofill, Button, or Both.

      • Autofill allows users to select the passkey from the autofill form.
      • The button displays a "Sign In with Passkey" button on the login page.
      • Both enable the Autofill and Button options.

    • Progressive Enrollment: This feature allows you to prompt users to establish a passkey during email/password login if needed. Users can skip this step, and it will reappear after a specified delay, which you can set in the 'Progressive Enrollment Delay' option.

      • Progressive Enrollment Delay (Days): Specify the number of days after which the progressive enrollment option will reappear for users who skip it.

    • Local Enrollment: Enable this to require users to generate a local passkey when logging in on a new device using a cross-device passkey. Users can skip this step if needed.

    • Relying Party Display Name: The brand name shown to users during passkey prompts (e.g., "Acme Corp"). Enter your site or app name here.

    • Relying Party ID: The domain that owns the passkey credential. Enter the bare domain without scheme or port. A credential registered against this RP ID can be used on that domain and any of its subdomains. localhost is valid for local development.

      • Examples: example.com, localhost

    • Relying Party Origins: The exact origins allowed to use passkeys. Add each origin as a separate entry. Accepted formats:

      • Web: https://example.com, https://app.example.com:3000
      • Android native app: android:apk-key-hash:<sha1-hash>
      • iOS native app: ios:bundle-id:<bundle-identifier>
      • Localhost testing: http://localhost:<port>

    • Attestation: Choose how much information about the authenticator device is shared during registration:

      • None: No or limited device information.
      • Indirect: Basic device information with privacy considerations.
      • Direct: Comprehensive device details, which may restrict certain devices due to privacy concerns.

  • Click the Update button to apply the configurations.

Domain scoping and subdomains

Passkeys are bound to the Relying Party ID. A credential registered against example.com can be used on example.com and any subdomain (e.g., login.example.com, app.example.com), but it cannot be used on a different domain like other.com.

For native mobile apps, add the app's origin (android:apk-key-hash:... or ios:bundle-id:...) to Relying Party Origins, and set the Relying Party ID to the associated web domain that the app is linked to.

API Implementation

LoginRadius provides APIs covering the full passkey lifecycle: registering a passkey, logging in, adding a passkey to an existing account, deleting a passkey, recovering access via forgot and reset passkey flows, and MFA with passkeys. The sections below walk through the core registration and login flows in detail, with request/response examples and client-side code.

Before You Start: Encoding Helpers

WebAuthn APIs return and expect binary data in ArrayBuffer format, but APIs require base64url-encoded strings.

Define these helper functions once and use them for both registration and login:


function base64UrlEncode(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");
}

function base64UrlDecode(base64url) {
  const base64 = base64url.replace(/-/g, "+").replace(/_/g, "/")
    .padEnd(base64url.length + (4 - base64url.length % 4) % 4, "=");
  return Uint8Array.from(atob(base64), c => c.charCodeAt(0));
}

Passkeys Registration

Call the Registration Begin By Passkey API to start the flow. The server generates a one-time challenge and returns the options the browser needs to create a passkey.

Sample Response

{
  "RegisterBeginCredential": {
    "publicKey": {
      "rp": {
        "name": "LoginRadius App",
        "id": "example.com"
      },
      "user": {
        "name": "f04d624989314945a950c6a8f71959d0",
        "displayName": "f04d624989314945a950c6a8f71959d0",
        "id": "ZjA0ZDYyNDk4OTMxNDk0NWE5NTBjNmE4ZjcxOTU5ZDA"
      },
      "challenge": "1x9aUZmA5hCXdvt8szxILDmnWUWWkXgkAE61tC_7yJc",
      "pubKeyCredParams": [...], // supported key algorithms
      "timeout": 60000,
      "authenticatorSelection": {
        "requireResidentKey": false,
        "userVerification": "preferred"
      }
    }
  }
}
Loading...

Passkey Login

The login flow uses a passkey the user already registered. The browser authenticates the user locally (biometrics, PIN, or security key) and returns a signed assertion that LoginRadius verifies server-side.

Call the Login Begin By Passkey API to start the flow. The server generates a challenge and returns the list of credentials registered for that user.

Request Parameters

  • apikey: Your LoginRadius API key
  • identifier: The user’s email address

Sample Response

{
  "LoginBeginCredential": {
    "publicKey": {
      "challenge": "<base64url-challenge>",
      "timeout": 60000,
      "rpId": "example.com",
      "allowCredentials": [
        { "type": "public-key", "id": "<base64url-id>" }
      ],
      "userVerification": "preferred"
    }
  }
}
Loading...

Passkeys as Primary Authentication

When a passkey is the primary authentication method, users sign in directly through their device — no password, no additional step. If MFA is also enabled for your app, they will not be prompted for a separate TOTP code or any other factor. LoginRadius treats a successfully verified passkey as both a first and second factor: the device holds the private key (something you have), and the biometric or PIN used to unlock it (something you are or know) satisfies user verification — all in a single step.

Passkey as MFA

Passkeys can also be used purely as a second factor, with a traditional method (e.g., email/password) as the primary login. After the user completes the primary authentication, LoginRadius triggers the WebAuthn ceremony to verify their identity — the user taps their device or uses a biometric, and the signed assertion is checked server-side. If verification passes, the MFA step is satisfied and the session is established.

To enable this, go to Security > Multi-Factor Authentication in the Admin Console, enable MFA, and then enable Passkey as an MFA method. You will also need to complete the passkey configuration before passkeys can be used as a second factor.

Loading...

Additional APIs are available to help you meet your use cases. The documentation provides an overview and guidance on how to use them.

Related Resources

Passwordless AuthenticationMulti-Factor Authentication