Replies: 7 comments 4 replies
-
|
cc @xianli123 |
Beta Was this translation helpful? Give feedback.
-
|
Thanks! @jonkoops @jeetparte. I looked through this discussion. I need to check the UI to see more details. As for the requirement, we want the user to choose to use Passkey or Password to register/sign in. Is that right? |
Beta Was this translation helpful? Give feedback.
-
|
Jeet,
Could you open this as an enhancement request?
https://github.com/keycloak/keycloak/issues/new?assignees=&labels=kind%2Fenhancement%2Cstatus%2Ftriage&projects=&template=enhancement.yml
…On Wed, Mar 13, 2024 at 8:50 AM Jeet Parte ***@***.***> wrote:
Hi everyone,
I recently configured passkeys on a Keycloak 24.0.1 instance via the
password-less login flow (i.e. showing a username form, followed by
password or passkey forms). I am happy that it works with such minimal
configuration. Thanks to the Keycloak contributors for implementing it!
I would also like to share my feedback on some areas that could use
improvements to ensure an optimal user experience that encourages users to
opt-in to using passkeys. Sharing these below —
Registering passkeys
The current recommendation in the docs
<https://www.keycloak.org/docs/latest/server_admin/#setup-2> is to set a
required action on the user (or on all new users
by enabling it as a *Default Action* on the realm). I found that this is
not optimal as the user cannot bypass the page in case
- their device doesn't support passkey registration,
- or they encounter an error during passkey registration,
- or they simply don't want to opt-in to passkeys.
As recommended by the guidelines (see bootstrapping
<https://passkeys.dev/docs/use-cases/bootstrapping/#opting-the-user-into-passkeys>
and 4th point under FIDO UX principles
<https://fidoalliance.org/ux-guidelines-for-passkey-creation-and-sign-ins/#ux-principles>),
it would be better to make 'Passkey Registration' optional — leaving the
choice to the user, for example with a 'Not Now' button.
The registration page can also be skipped altogether if we detect the
user's device and OS combination does not support passkeys, i.e. a check on
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable().
Screenshot.2024-03-13.at.3.09.39.PM.png (view on web)
<https://github.com/keycloak/keycloak/assets/17269750/45d2cc5e-f4ed-46d1-b06a-f06156b52215>
Another option for passkey registration is to direct the user to the
account console page which offers the 'Set up Passkey' option. This means
the client application needs to offer a 'Create Passkey' option in its UI
to the authenticated user to direct them to the account console. This
option works perfectly as the registration page in this case does offer a
'Cancel' option (and any additional UI customisation, such as adding
additional messaging about passkeys, I assume can be done at the theme
level).
Screenshot.2024-03-13.at.3.17.03.PM.png (view on web)
<https://github.com/keycloak/keycloak/assets/17269750/e46ecf3f-772d-4a56-a050-6e73b2dbd9a6> Screenshot.2024-03-13.at.4.51.24.PM.png
(view on web)
<https://github.com/keycloak/keycloak/assets/17269750/1ccf956d-0b46-4548-8b46-aff91d8aeb5f> Supporting
passkeys for New User registration
Currently, the New User registration page makes the password compulsory
and a passkey can only be registered as an add-on via a required action. It
would be nice to offer newly created users an option between setting up a
password or a passkey.
The Inventage passkey tutorial
<https://keycloak.ch/keycloak-tutorials/tutorial-passkey/> features such
an option.
Screenshot.2024-03-13.at.4.44.08.PM.png (view on web)
<https://github.com/keycloak/keycloak/assets/17269750/eb8a1f0a-a5f4-43ee-8eaa-d01603ae2d16> Friction
using passkeys in the login flow
As mentioned above, I setup the password-less flow shown in the docs as
below —
0.configured-authentication-flow.png (view on web)
<https://github.com/keycloak/keycloak/assets/17269750/9a282f82-dfef-4f96-a4b0-5b6027497c7d>
I soon discovered that after the username is filled in, the password form
is always presented first (due to the way credential ordering works). A
user wanting to sign in with a passkey must follow a series of steps (see
screenshots below):
- Choose the 'Try Another Way' option on the password page.
- Choose 'Passkey' in the list of displayed authentication options
that show.
- Click an additional button on the passkey page to begin the WebAuthn
flow.
Screenshots
Screenshot.2024-03-08.at.5.45.42.PM.png (view on web)
<https://github.com/keycloak/keycloak/assets/17269750/f0d7ca9b-fec9-46a6-9b2f-05113ee68d6e> Screenshot.2024-03-08.at.5.45.57.PM.png
(view on web)
<https://github.com/keycloak/keycloak/assets/17269750/72362d4c-3234-4542-add9-53a5e8124353> Screenshot.2024-03-08.at.5.46.07.PM.png
(view on web)
<https://github.com/keycloak/keycloak/assets/17269750/f647473b-bff0-46a0-a5f7-b94e88e179bb> Screenshot.2024-03-08.at.5.49.51.PM.png
(view on web)
<https://github.com/keycloak/keycloak/assets/17269750/87a0da83-9777-4eba-a8d7-1e5ec44b9534> Screenshot.2024-03-08.at.5.50.29.PM.png
(view on web)
<https://github.com/keycloak/keycloak/assets/17269750/8b87b262-fdb6-4282-9c7b-983fc793f591>
So my choice would be to:
1. To prefer passkeys over passwords for users that have them setup.*
2. Alternatively, show the list of sign-in options first and let the
user pick which they want to use (password or passkey).
3. Not having to press an additional button on the passkey page for
invoking the passkey flow.
*in discussion #24883
<#24883>, this comment
<#24883 (comment)>
mentions a REST API endpoint
<https://www.keycloak.org/docs-api/23.0.0/rest-api/index.html#_post_adminrealmsrealmusersidcredentialscredentialidmovetofirst>
that can move a credential at a higher priority so it shows first. Perhaps
we can do the equivalent upon registering a password-less credential?
I am aware that work on conditional UI
<https://passkeys.dev/docs/reference/terms/#autofill-ui> is underway in
#24264 <#24264> and will
significantly improve the login situation but the above still applies if a
user proceeds with the normal flow.
Passkeys support is looking great and IMO only has a few gaps to fill.
Hope the team finds my feedback useful!
Cheers,
Jeet
—
Reply to this email directly, view it on GitHub
<#27859>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD32QRL3X2C4JOHGB7TU63YYBDP5AVCNFSM6AAAAABEUDDPHCVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZWGM3DONBXGE>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
I'm working on it in https://github.com/cad0p/keycloak-custom-passkeys |
Beta Was this translation helpful? Give feedback.
-
|
For logging in with passkeys, the best user experience is achieved with conditional UI, as demonstrated here. |
Beta Was this translation helpful? Give feedback.
-
|
We especially miss the |
Beta Was this translation helpful? Give feedback.
-
|
Anything new on this (specifically the passkey as default option for users, who have it configured and a one-click direct passkey login)? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone,
I recently configured passkeys on a Keycloak 24.0.1 instance via the password-less login flow (i.e. showing a username form, followed by password or passkey forms). I am happy that it works with such minimal configuration. Thanks to the Keycloak contributors for implementing it!
I would also like to share my feedback on some areas that could use improvements to ensure an optimal user experience that encourages users to opt-in to using passkeys. Sharing these below —
Registering passkeys
The current recommendation in the docs is to set a required action on the user (or on all new users
by enabling it as a Default Action on the realm). I found that this is not optimal as the user cannot bypass the page in case
As recommended by the guidelines (see bootstrapping and 4th point under FIDO UX principles), it would be better to make 'Passkey Registration' optional — leaving the choice to the user, for example with a 'Not Now' button.
The registration page can also be skipped altogether if we detect the user's device and OS combination does not support passkeys, i.e. a check on
PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable().Another option for passkey registration is to direct the user to the account console page which offers the 'Set up Passkey' option. This means the client application needs to offer a 'Create Passkey' option in its UI to the authenticated user to direct them to the account console. This option works perfectly as the registration page in this case does offer a 'Cancel' option (and any additional UI customisation, such as adding additional messaging about passkeys, I assume can be done at the theme level).
Supporting passkeys for New User registration
Currently, the New User registration page makes the password compulsory and a passkey can only be registered as an add-on via a required action. It would be nice to offer newly created users an option between setting up a password or a passkey.
The Inventage passkey tutorial features such an option.
Friction using passkeys in the login flow
As mentioned above, I setup the password-less flow shown in the docs as below —
I soon discovered that after the username is filled in, the password form is always presented first (due to the way credential ordering works). A user wanting to sign in with a passkey must follow a series of steps (see screenshots below):
Screenshots
So my choice would be to:
*in discussion #24883, this comment mentions a REST API endpoint that can move a credential at a higher priority so it shows first. Perhaps we can do the equivalent upon registering a password-less credential?
I am aware that work on conditional UI is underway in #24264 and will significantly improve the login situation but the above still applies if a user proceeds with the normal flow.
Passkey labelling
On creating a passkey, a modal dialog to label the passkey is displayed with 2 options: 'Cancel' and 'OK'. The 'Cancel' button behaviour is unexpected. Please see my earlier comment #27147 (comment).
Passkeys support is looking great and IMO only has a few gaps to fill. Hope the team finds my feedback useful!
Cheers,
Jeet
Beta Was this translation helpful? Give feedback.
All reactions