-
Notifications
You must be signed in to change notification settings - Fork 7.3k
Trusted Device two factor authentication #39732
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
6f28a7a
to
7770009
Compare
b9b544e
to
8b1b755
Compare
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.webauthn.account.WebAuthnSigningInTest#categoriesTestKeycloak CI - WebAuthn IT (firefox)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
@@ -128,6 +128,8 @@ signedInDevices=Signed in devices | |||
delete=Delete | |||
missingPasswordMessage='{{0}}'\: Please specify password. | |||
otp-help-text=Enter a verification code from authenticator application. | |||
trusted-device-display-name=Trusted device | |||
trusted-device-help-text=Trusted devices don't require second factor authentication for a longer period of time |
There was a problem hiding this comment.
Maybe make the trusted device period length available to this message as a parameter? (If it isn't already? I'm not so familiar with Keycloak's code)
E.g. so you could display:
Trusted devices will only require second-factor authentication every 7 days
How would this interact with step up authentication? |
Currently this is implemented as a new Authenticator. This may be not the best way to do it, because the order of the authenticators presented to client during the login process is controlled by the order of the saved credential types. If we keep it as a separate authenticator, then some custom condition (like in Wouter's solution) would be needed. Another option is that the trusted device validation logic could be part of the OTP and WebAuthn authenticator instead of doing it in a separate authenticator. This is the second entry on the "to-be-decided" list in the PR's description. With the current approach you can use the new authenticator as a regular one (example: OTP Form, Password Form). |
Signed-off-by: Norbert Kelemen <nkelemen18@nkelemen.hu>
Signed-off-by: Norbert Kelemen <nkelemen18@nkelemen.hu>
Signed-off-by: Norbert Kelemen <nkelemen18@nkelemen.hu>
Signed-off-by: Norbert Kelemen <nkelemen18@nkelemen.hu>
4e5cfdc
to
0509deb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unreported flaky test detected, please review
Unreported flaky test detectedIf the flaky tests below are affected by the changes, please review and update the changes accordingly. Otherwise, a maintainer should report the flaky tests prior to merging the PR. org.keycloak.testsuite.webauthn.account.WebAuthnSigningInTest#categoriesTestKeycloak CI - WebAuthn IT (firefox)
|
Take into consideration I am no UX expert, but:
I think from end-user perspective there's no benefit from implementing it as part of OTP/WebAuthn flows, as it introduces weird flow, where your device might be trusted for one method and not for the other, which might provide to weird behavior i.e.:
It'd also introduce 2 entries per device per user if they have both 2FA mechanisms implemented, which seems counter intuitive. On the other hand I suppose it could be overcome, by, i.e. providing flows with conditional (like
And this from design perspective is directly connected to the previous one. IMO if we treat the Trusted Device as separate authenticator, then the UI should mirror that, and it should serve user with a separate prompt. This way we automatically hint on how the Trusted Device mechanism will behave. |
Thank you for your feedback, @ModerNews. I absolutely agree with you. I think that the current implementation is not fully self-evident. If you trust a device, then it will be trusted regardless of the used 2FA authenticator. This means that the same credential will be created even if you checked the trust device checkbox on WebAuthn form and even if you check it on OTP form. If we go with the separate form, then I don't know what would be the best way to implement it. Probably a "required user action". The problem is, that the authenticator should be executed before the OTP/WebAuthn authenticator, and the "Trust device form" only after a successful 2FA validation. I would be interested in what do the core developers think about this topic. @ahus1 what do you think, who could help us design this feature from the Keycloak team? |
Trusted device authentication instead of OTP or WebAuthn.
Note: this is a draft PR.
This PoC is based on:
At least the following things are missing:
Pictures of this PoC
Realm Authentication settings of the new Policy
OTP form on an untrusted device
WebAuthn form on an untrusted device
Stored credential(s) in account console
Stored credential(s) in admin console