[keycloak-user] Automatic one-time login

Dmitry Telegin demetrio at carretti.pro
Tue Jun 18 09:13:46 EDT 2019


Hi Manuel,

You might even avoid implementing one-time code logic (incl. REST endpoint, custom credential etc.) by using the approach demonstrated in the quickstart [1].

Had you been using Keycloak's registration flow, this quickstart could have been applicable entirely (modulo authentication vs. registration flow), but still you can borrow the main idea from it: using app-specific signed token (instead of one-time code) to assert that registration succeeded.

Keycloak already supports one-time action tokens (see org.keycloak.authentication.actiontoken.ActionTokenHandler::canUseTokenRepeatedly). To ensure that your app-specific token is one-time too, you could associate it with the "parent" action token using the latter's "nonce" claim. One thing you need to know about one-time action tokens in Keycloak - this is done via org.keycloak.models.ActionTokenStoreProvider, and the default implementation (o.k.models.sessions.infinispan.InfinispanActionTokenStoreProvider) is non-persistent, so if by some reason the whole cluster gets restarted before action token expires, it could be potentially reused.

Otherwise, both options that you described should be viable. Please find the answers below.

On Tue, 2019-06-18 at 08:03 +0000, Manuel Bleichenbacher wrote:
> Hi everybody,
> 
> Our new application will have a length user registration procedure that we would like to keep separate from Keycloak (it will mainly require application data, reuse part of the application's UI etc.). At the end of the registration procedure, we would still like to automatically login the user so he/she doesn't need to reenter the username and password. What are our options to achieve it?
> 
> The backend will certainly use a privileged Keycloak user (e.g. to create the new user via the REST Admin API). And the result of the login should be that the user's access token (JWT) is available in the user's session in the backend. So far we have come up with the following options:
> 
> Option A: REST endpoint / custom authenticator
> 
> - Add a custom REST endpoint so the backend can create a one-time code and save it as a credential on the new user
> - Add a custom authenticator to the browser flow that checks for the one-time code
> - The user would then be directed to the regular authentication flow. If the one-time code is present and correct, the username/password step and possibly all other authentication steps will be skipped and the authentication immediately succeeds.
> 
> Option B: REST endpoint / action token
> 
> - Add a custom REST endpoint so the backend can create a one-time code and save it as a credential on the new user
> - Implement an additional action token handler that checks the one-time token to authenticate the user
> - The user would then be directed to the action token URL. If the one-time code is correct, the user is authenticated.
> 
> What is your recommendation:
> - Are these feasible options?
> - Are we missing a good option?
> 
> For option A: How can we pass the one-time code to the authentication flow? Can we use a URL parameter, HTTP header attribute?

This is possible, but not much reliable because of HTTP redirects. After a redirect, the initial parameters will be lost (as well as headers), and you'll need to parse the parameter out of Referer header. Check out this thread [2] for details.

However, there exists a hack so that you can use "scope" parameter to pass data reliably, see this thread for details [3].

> For option B: Can the action token flow initiate the OAUTH2 flow and return an authorization code? Can this flow be easily integrated with the Spring Boot  adapter?

Yes, see this [4]. AFAIK for the adapter it should look like an ordinary flow, it won't even know it had been initiated via action token handler.

[1] https://github.com/keycloak/keycloak-quickstarts/tree/latest/action-token-authenticator
[2] https://lists.jboss.org/pipermail/keycloak-user/2018-November/016230.html
[3] https://lists.jboss.org/pipermail/keycloak-user/2019-May/018393.html
[4] https://github.com/keycloak/keycloak-quickstarts/blob/latest/action-token-authenticator/src/main/java/org/keycloak/quickstart/actiontoken/token/ExternalApplicationNotificationActionTokenHandler.java#L89

Good luck,
Dmitry Telegin

Carretti Consulting OÜ | Keycloak Consulting and Training
Sepapaja 6, Tallinn 15551, Estonia | info at carretti.pro

> 
> Any input is appreciated.
> 
> Thanks
> Manuel
> 
> --
> manuel bleichenbacher | senior consultant
> m +41 79 617 90 01 | manuel.bleichenbacher at acrea.com
>  
> acrea ag | konradstrasse 32 | 8005 zürich
> www.acrea.com | blog.acrea.com
>  
> www.nezasa.com - incubated by Acrea
> 
> 
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user



More information about the keycloak-user mailing list