Skip to content
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

[Feature]: support of OTP as failback authenticator #358

Open
1 task done
ArminRadmueller opened this issue May 6, 2024 · 2 comments
Open
1 task done

[Feature]: support of OTP as failback authenticator #358

ArminRadmueller opened this issue May 6, 2024 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@ArminRadmueller
Copy link

Is there an existing feature request for this?

  • I have searched the existing issues

Is your feature related to a problem? Please describe.

I would like to use the home-idp-discovery with our Keycloak and after watching the video I had set it up as described and encountered the same problem as described in #285. In the documentation it's described correctly with username/password form.
I wanted to set up the home-idp-discovery with an OTP failback instead of the password-form, in other words passwordless.

Describe the solution you'd like

Would it be possible to adapt the implementation in #251 so that password form or alternatively OTP form only works again?

I would like to describe my idea better:
User inserts his e-mail address and is redirected to a linked identity provider. If it is only a local or LDAP account, the alternative authenticator (failback) will be used, which would be the OTP in my scenario.

Describe alternatives you've considered

No response

Anything else?

No response

@ArminRadmueller ArminRadmueller added the enhancement New feature or request label May 6, 2024
@sventorben sventorben self-assigned this May 6, 2024
@sventorben
Copy link
Owner

Hello @ArminRadmueller,

Would it be possible to adapt the implementation in #251 so that password form or alternatively OTP form only works again?

To make this work, I would need to set the user in the Keycloak context. But that would instantly lead to the security issue described in #251 again. So, I do not think I will be able to support this right now.

If you need passwordless authentication, why not use the WebAuthnPasswordlessAuthenticator that should not need the user to be set in the context?

@ArminRadmueller
Copy link
Author

I will test it in the next few days, but it will be too big a step for our use case

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants