Question: What are passkeys?
Answer: A passkey is a password replacement, that provides faster, easier, and more secure sign-in experience to websites and applications. Based on FIDO standards, passkeys give businesses a phishing-resistant alternative to passwords with a great user experience.
Question: So, what is so special about passkeys?
Answer: There is no shared secret sent to the server with passkeys, preventing potential exploitation by attackers.
Passkeys are significantly more secure for consumers because they rely on public-key cryptography rather than passwords. As a result, passkeys are a more phishing-resistant alternative. A crucial aspect of the phishing-resistance is that a passkey is bound to a particular RP domain name. As a result, unlike for passwords, passkeys cannot inadvertently be submitted to the wrong website (ex. to a spoofed website) during the authentication step.
In addition, businesses that use passkeys for authentication do not have to store a customer’s password credentials (often a target for bad actors). Instead, they store a public key with minimal value to a bad actor. By eliminating a common target for bad actors, passkeys also lower the risk of a data breach.
Question: How can I enable passkeys?
Answer: Passkeys are available as a Database connection in the Manage Dashboard of the Customer Identity Cloud. Customers can enable passkey by navigating to: Authentication -> Database -> Connection -> Authentication Methods -> Passkey
as shown in the below screenshot.
Question: Where can I find more information about this feature?
Answer: You can refer to our online documentation to learn more about the feature and explore details regarding related changes.
Question: What changes are included in Management API?
Answer: The Management API allows customers to list and revoke passkeys.
The following API2 endpoints now support operations on passkeys:
GET /api/v2/users/:user_id/authentication_methods- This endpoint prefixes a user’s passkeys sorted by creation date
GET /api/v2/users/:user_id/authentication_methods/:authenticator_id- This endpoint will retrieve a passkey by id
DELETE /api/v2/users/:user_id/authentication_methods/:authenticator_id- This endpoint will revoke a passkey by id
Some modifications were made to the following connections endpoints:
-
PATCH /api/v2/connections/{id} now accepts two new attributes, authentication_methods and passkey_options payload within the options attribute. Details about the schema can be found in Auth0 docs here.
-
POST /api/v2/connections/{id} now accepts two new attributes, authentication_methods and passkey_options payload within the options attribute. Details about the schema can be found in Auth0 docs here.
Question: Is there any specific AMR claim for passkey?
Answer: When issuing idtokens for a given user transaction, the token payload might include the amr claim that indicates which authentication method was used to authenticate the user.
When the existing password-based authentication completes today, the idtoken does not even include this amr claim, but when an end-user completes a passkey-based authentication, we will emit an amr claim, set to phr (acronym of phishing-resistant). This allows customer applications to understand that a passkey was used to authenticate this session.
Question: Can we integrate this on native app?
Answer: In the upcoming iterations, we’re aiming to integrate with native SDK. However, currently, customers can implement New Universal Login to provide passkeys on native apps through browser-based logins, as explained here Native Login. We’ve successfully tested this approach on iOS and Android, using passkeys for signups and logins through browser-based logins within native apps.
Because passkeys involve integration with device unlock methods, it’s important to note that simulators like XCode might not consistently produce the desired outcomes. To ensure accurate results, we recommend integrating and testing the native app browser-based login behavior directly on the actual device.