TL;DR: If a user is created by a web server process external to Keycloak, is there a way to “force” Keycloak to consider that browser logged in as the newly created user, e.g. by somehow getting a code or token from Keycloak via an API and redirecting the browser to Keycloak using that code?
Background & Details: We’re planning a step-by-step transition of our application to use Keycloak and OAuth2 for log in. For the first step, we’d like to do as few changes to our application as possible. E.g. we won’t store users in Keycloak but will be using the User Storage SPI to integrate with the existing user database already in the application.
The existing account registration and creation workflow has been carefully designed by designers and marketing over many iterations since it is very sensitive to the business. Changing that flow is almost a deal-breaker for OAuth2 adoption, so we’d like to keep the existing registration user experience as-is.
What happens today is that when the user has entered his username and password (twice for verification), the user experience is that he is redirected to the main page logged in as his newly created user. Behind the scenes, when the POST request comes in with the username and passwords, a user account is created, the user’s cookie-based session is marked as logged in as the newly created user, and the user is redirected to the front page, already logged in.
Is there some way to replicate that user experience using OAuth2 and Keycloak, if the registration process remains on our web server and doesn’t use the Keycloak registration flow? We’d like to avoid the user having to see a login page and input the username and password he just entered on the previous registration page, but instead give the experience of being logged in automatically after registration is complete. Is that possible?
Hi @pmorch ! Did you find a solution to this matter?
I’m in the same situation than you for the same reasons as well. In addition, my use case is bit more complex, because we want to verify newly registered user’s email.
I found a decent workaround, but it implies to use Oauth2 Direct Access Grants during registration process, which is prohibited and will be removed in Oauth2.1.
Here is a short description of our workflow (both client app and Keycloak are trusted):
- User can register on client App, that handles the whole process, with various steps if required by the business
- At the end of the registration process on client side, user’s data are sent to KC via API REST (password is sent in a distinct request to improve security)
- Then, since client app has already collected user’s credentials, we use those to automatically login user in the background through OIDC and Direct Access Grants
- Client app get the user’s access token and can handle email verification on its own if business requires it too (note that email is verified on KC side, otherwise authentication is locked since user account is in “Account is not fully set up” state)
Here is a simple diagram of this flow:
To achieve this I have to overcome a few issues:
- use of Direct Access Grants during registration (that I’d rather avoid for security and other reasons)
- create a new custom field in LDAP backend, named emailVerifiedByClient to be able to let the client app handles this process its own way, since if email is not verified in Keycloak, authentication is locked
- Single Sign On won’t work after registration flow, since user is authenticated on client app, and not on KC (so he hasn’t a cookie). User will have to login on KC form, and provide his credentials again, in order to access another client app.
How come, when you test this scenario within Keycloak UI (and its account client), it’s working perfectly, even though Direct Access Grant is not activated, and email has not yet been verified? I wonder how it’s done to be able to implement something similar and probably more secured than the flow I’ve imagined.
Can someone explain us how it’s done on Keycloak UI?
What I’ve understand so far, is that, user gets automatically authenticated at the end of registration process in the background (but how?), even before email verification email is sent. Since “Account is not fully set up”, how is this possible?
Last but not least, modifying Keycloak source code should be avoided in the solution, since we don’t have Java developers in our staff.
No sorry, we didn’t find a great solution.
Our not-so-great solution involved creating our own Authentication SPI in keycloak for this exact purpose. I’ve since left the company where we created it, so I can’t go into further details.
Thank you for your feedback Peter
Implementing an Auth Service Provider Interface is indeed another decent solution, but since it requires to extend KC source code, it’s not a viable option in our case, at least for now.
We’re going to implement the solution I’ve described in this thread, and we will see if we can find something better in the future.
Wish you well in your new company