******** Passkeys ******** .. contents:: On this page :local: :depth: 1 Overview ======== A **passkey** is a phishing-resistant credential that lets a person sign in to a website or application without typing a password or a one-time code. Instead, the user proves who they are by unlocking their device in the way they normally do, using a fingerprint, a face scan, a screen-lock PIN or a hardware security key. Passkeys are built on the **FIDO2** standards, which combine the **WebAuthn** specification from the World Wide Web Consortium (W3C) with the **CTAP2** protocol from the FIDO Alliance. In AuthControl Sentry, passkeys are an authentication method alongside the mobile app, PINpad, hardware tokens and others. From version 4.3, users can register passkeys in the User Portal and use them to sign in through Sentry SSO. Because the passkey is verified when the user signs in to Sentry, it works with every application that uses Sentry SSO, whether the application connects using **SAML 2.0** or **OpenID Connect (OIDC)**. The application receives either a signed SAML assertion or a signed OIDC ID token, and does not need to know anything about passkeys. Background ========== Passwords have long been the weakest link in authentication. Users reuse them, choose guessable ones and can be tricked into typing them into fake websites. One-time codes improve matters but can still be intercepted or relayed by an attacker operating a convincing fake login page. The FIDO Alliance, formed in 2012, set out to replace shared secrets with public-key cryptography. Its first specification, U2F, used dedicated hardware security keys as a second factor. This evolved into FIDO2 (2018), which allows the same approach to be used by the built-in authenticators in phones and computers, and which can replace the password altogether rather than just supplement it. The term *passkey* was adopted by Apple, Google, Microsoft and the FIDO Alliance in 2022 to describe FIDO credentials that can be used across a user's devices and presented in a consistent way. Today passkeys are supported by all major operating systems, browsers and password managers. How passkeys work ================= Passkeys use **public-key cryptography**. When a user creates (*registers*) a passkey for a service, their device generates a unique pair of mathematically linked keys: * A **public key**, which is sent to the service and stored against the user's account. * A **private key**, which stays on the user's device or in their passkey provider and is never sent to the service. When the user signs in, the service sends a random *challenge*. The user unlocks the passkey, the device signs the challenge with the private key, and the service verifies the signature using the stored public key. Because the public key can only verify signatures and cannot create them, a copy of it is of no use to an attacker. A breach of the service therefore does not expose credentials that can be replayed elsewhere. The private key is never shared with the service, and it can only be used after the user has been verified locally, for example with a fingerprint or device PIN. The biometric or PIN is checked by the device itself and is never sent to Sentry. Each passkey is tied to the hostname of your Sentry SSO login page when it's created. At sign-in, the browser checks the address of the page asking for the passkey and will only use it on that exact domain. That means a fake login page on a lookalike address can't trigger or capture the passkey, even if the user is fooled into visiting it, which makes passkeys resistant to phishing in a way passwords and one-time codes aren't. It also means Sentry SSO needs to run on a proper hostname with a valid certificate, and if that hostname changes later, users will need to enrol their passkeys again. Architecture ------------ The diagram below shows the main components and how they communicate. .. image:: images/Passkeys/passkey-architecture.svg :alt: Passkey architecture: authenticators on Android, iOS, macOS, Windows and security keys communicate with a browser (Chrome, Edge, Firefox or Safari) using CTAP2 or the platform API. The browser uses WebAuthn over HTTPS to Sentry SSO, which verifies the signature with the Sentry Core and issues a SAML assertion or OIDC token to the application. :width: 100% .. note:: Product names and logos in the diagram are trademarks of their respective owners and are used only to identify compatible platforms. Using device biometrics ======================= Most devices protect their passkey store with a local *user verification* step, and this is what makes a passkey a multi-factor credential in a single gesture: the device holds the key (something you have) and the user unlocks it with a biometric or PIN (something you are, or know). When Sentry SSO asks for a passkey, the browser passes the request to the passkey store on the user's device, which then asks the user to verify themselves using whatever the device supports, for example: * **Fingerprint readers**, such as Touch ID on a Mac or iPhone, a fingerprint sensor on an Android phone, or a reader on a laptop or security key. * **Face recognition**, such as Face ID, or Windows Hello Face, which uses an infrared (IR) webcam so that it is not fooled by a photograph. * **A screen-lock PIN, pattern or password**, used as a fallback or where no biometric hardware is fitted. The biometric data is matched locally by the device, using its secure hardware (for example a secure enclave or TPM), and unlocks the private key only for that sign-in. The fingerprint or face template is never sent to Sentry or the browser. Sentry only receives a signed response and an indication that user verification took place. This means no biometric database needs to be held or protected by your organisation, and users can re-enrol or change their biometrics on their device without any change in Sentry. .. note:: The biometric only unlocks the passkey on that device. It is not a shared credential, and enrolling a fingerprint or face on one device does not enable it on any other. Types of passkey ================ Passkeys differ in where the private key is held. **Synced passkeys** The private key is stored by a passkey provider, such as a platform account (Apple iCloud Keychain, Google Password Manager, Microsoft account) or a third-party password manager, and is synchronised between the user's devices. These are convenient, because a new phone or laptop can use existing passkeys, and recovery is straightforward. Their security depends on the security of the provider account. **Device-bound passkeys** The private key never leaves a single piece of hardware, typically a **FIDO2 security key** such as a YubiKey. These offer the strongest assurance, because the credential cannot be copied, but if the key is lost the passkey is lost with it, so users should register more than one. Passkeys can also be used from one device to sign in on another. For example, a user can approve a sign-in on a computer by scanning a QR code with their phone. The two devices must be physically near each other, which preserves the phishing resistance of the passkey. Security properties =================== .. list-table:: :header-rows: 1 :widths: 28 24 24 24 * - Property - Password - One-time code - Passkey * - Can be guessed or cracked - Yes - No - No * - Can be reused across sites - Yes - No - No * - Secret is held by the service - Yes - Often - No (public key only) * - Can be phished or relayed - Yes - Yes - No * - Requires user to type something - Yes - Yes - No Passkeys are not a complete answer to every risk. A synced passkey is only as secure as the account that syncs it, and a stolen device that is unlocked, or whose screen-lock is known to the thief, may allow the passkey to be used. Organisations that need stricter assurance can limit registration to hardware keys, as described below. Passkeys in AuthControl Sentry ============================== Availability ------------ Passkey support is available from AuthControl Sentry **4.3**. See the :doc:`release notes ` for the full list of changes in that version. Passkeys can be used to authenticate to applications integrated with Sentry SSO over either SAML or OIDC, for example when Sentry is used as an external authentication method for Microsoft Entra ID. Two authentication methods -------------------------- Sentry SSO offers two passkey authentication methods: **FIDO2 Passkeys** Accepts any FIDO2 passkey, including synced passkeys and hardware security keys. **Hardware Passkeys** Accepts hardware-bound credentials only. Use this to enforce hardware-only authentication for applications that require it. You do not need to enable both. Because *FIDO2 Passkeys* already includes hardware keys, enable *Hardware Passkeys* only if you want to enforce hardware-only. Enabling passkeys ----------------- Passkeys are configured in the Core web administration: 1. In **Policy -> Passkeys**, set *Enable Passkey authentication* to **Yes**. 2. Set the **Relying Party Identifier** to the qualified hostname of Sentry (for example ``sentry.company.com``) and give the relying party a name. 3. Set the **Public URL** to the full address, including ``https://``, that users will use. It must be reachable by anyone who will register a passkey. 4. In **Repository -> Groups**, enable passkeys on at least one group, then run a User Sync so that group members receive the right. 5. Enable passkeys in the User Portal (Authentication and Display Settings) and in SSO (Authentication Methods). See :ref:`the 4.3 technical notes ` and :ref:`Policy -> Passkeys ` for the full set of options. Registering and managing passkeys --------------------------------- Users add passkeys in the User Portal, either themselves if self-provisioning is enabled, or by following a provision link sent by the helpdesk. Administrators can also provision, rename, revoke, reinstate, purge and test a user's passkeys from :ref:`User Administration `. Attestation ----------- During registration, a passkey can optionally present **attestation**, a signed statement from the authenticator's manufacturer describing the make and model of the device. Sentry can require attestation, and can be given allow and deny lists of devices and a set of trust roots. Be aware that most software passkey providers do not support attestation, so requiring it effectively restricts users to hardware security keys. Leave it disabled unless you are familiar with how attestation works. Recovery -------- Because there is no password to reset, plan for the loss of a device. Encourage users to register more than one passkey, such as a synced passkey and a spare hardware key, and use the helpdesk provision process to enrol a replacement. Glossary ======== **Authenticator** The device or software that creates and holds passkeys, such as a phone, a computer or a security key. **Attestation** A statement by an authenticator's manufacturer that vouches for the type of device being registered. **CTAP2** Client to Authenticator Protocol, which lets a browser or operating system communicate with an external authenticator. **FIDO2** The set of standards, comprising WebAuthn and CTAP2, on which passkeys are based. **OIDC (OpenID Connect)** An identity layer on top of OAuth 2.0 in which Sentry, as the identity provider, returns a signed ID token to the application. Supported by Sentry SSO from version 4.3. **Relying party (RP)** The service that a passkey is used to sign in to. In this context, Sentry. Not to be confused with a SAML service provider or OIDC client, which is the application that Sentry then signs the user in to. **SAML** Security Assertion Markup Language, the XML-based standard by which Sentry, as the identity provider, passes a signed assertion to a service provider. **RP ID** The domain name a passkey is bound to. Browsers will only offer a passkey to a site matching its RP ID. **WebAuthn** The W3C web standard that lets websites create and use public-key credentials through the browser. Further reading =============== * `FIDO Alliance: Passkeys `_ * `W3C Web Authentication specification `_