8000 Trusted Device two factor authentication by nkelemen18 · Pull Request #39732 · keycloak/keycloak · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

nkelemen18
Copy link
Contributor
@nkelemen18 nkelemen18 commented May 14, 2025

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:

  • test cases
  • decision about the authenticator implementation: separate authenticator or part of the OTP/WebAuthn authneticators
  • decision about how to ask user whether it wants to trust the device: checkbox on OTP/WebAuthn forms or a separate page

Pictures of this PoC

Realm Authentication settings of the new Policy

policy-settings

OTP form on an untrusted device

otp-form

WebAuthn form on an untrusted device

webauthn-form

Stored credential(s) in account console

account-console-credentials

Stored credential(s) in admin console

admin-console-credentials

@keycloak-github-bot
Copy link
8000

Unreported flaky test detected

If 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#categoriesTest

Keycloak CI - WebAuthn IT (firefox)

java.lang.AssertionError: 

Expected: is <2>
     but: was <0>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
...

Report flaky test

Copy link
@keycloak-github-bot keycloak-github-bot bot left a 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

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

@liamjones
Copy link

How would this interact with step up authentication?

@nkelemen18
Copy link
Contributor Author
nkelemen18 commented May 15, 2025

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).

Actual state (Trusted Device in Conditional OTP flow) :
kép

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>
@nkelemen18 nkelemen18 force-pushed the feat-trusted-devices branch from 4e5cfdc to 0509deb Compare May 15, 2025 10:47
Copy link
@keycloak-github-bot keycloak-github-bot bot left a 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

@keycloak-github-bot
Copy link

Unreported flaky test detected

If 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#categoriesTest

Keycloak CI - WebAuthn IT (firefox)

java.lang.AssertionError: 

Expected: is <2>
     but: was <0>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
...

Report flaky test

@ModerNews
Copy link
ModerNews commented May 15, 2025

Take into consideration I am no UX expert, but:

deciosion about the authenticator implementation: separate authenticator or part of the OTP/WebAuthn authneticators

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.:

  • User has defined both OTP and WebAuthn in their account
  • OTP is the default MFA for the flow
  • User prefers WebAuthn, therefore has their device configured as trusted in WebAuthn flow
  • User now has to manualy change to WebAuthn only for the Trusted Device Mechanism to kick in

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 keycloak-spi-trusted-device does).

decision about how to ask user whether it wants to trust the device: checkbox on OTP/WebAuthn forms or a separate page

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.
Meanwhile the checkbox, as in your screenshots is in UI tied to the particular authenticator should be added if we treat Trusted Device as part of the OTP/WebAuthn.

This way we automatically hint on how the Trusted Device mechanism will behave.

@nkelemen18
Copy link
Contributor Author
  • User prefers WebAuthn, therefore has their device configured as trusted in WebAuthn flow
  • User now has to manualy change to WebAuthn only for the Trusted Device Mechanism to kick in

It'd also introduce 2 entries per device per user if they have both 2FA mechanisms implemented, which seems counter intuitive.

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0