I am looking to build a custom login application using a custom frontend (e.g., an Angular app) while utilizing Keycloak as the Identity Provider (IDP). Here’s what I aim to achieve:
Develop a custom login application (e.g., an Angular app) and deploy it separately from Keycloak.
Create a new Keycloak IDP and configure it to redirect to the custom frontend application as the default IDP redirect.
Set up a new client in Keycloak using the “Standard Flow” to support the authorization code flow.
Allow users to enter their credentials (username/password) on the custom form and handle the login process.
Follow the standard Keycloak login flow and use the provided APIs:
Invoke the /login-actions/authenticate endpoint with the session_code, tab_id, and execution query parameters. (I’m unsure how to retrieve these parameters since Keycloak automatically generates them in the returned HTML for the default Keycloak login form.)
Handle the redirection process in line with Keycloak’s default behavior.
Finally, redirect to the predefined redirect URI and obtain the authorization code.
The main goal is to replicate the default Keycloak login flow on my custom login page application and manage the authentication flow through this custom frontend. I want to avoid using Keycloak themes, as they are deployed with Keycloak, and I prefer to have my client application deployed separately.
My question is: Is it possible to achieve this setup with Keycloak, or would it require a custom implementation within Keycloak to support this flow?
I would appreciate any advice or guidance from the community on how to proceed.
I read this here and on the CNCF Slack, and it’s not clear to me why you would want to replicate the functionality of Keycloak’s login theme in your own application. There are lots of tools to customize the look and feel (e.g. Keycloakify) without having to build the entire thing yourself.
Furthermore, I’ve seen people try to do this by using the APIs (oidc and login-actions/*), and open up gigantic security holes in the process. One of the reasons to use Keycloak’s login theme (and the related customization tools) is to benefit from the enormous pool of direct and indirect security testers. If you build it yourself, you’re the only one that must validate and support it.
I would appreciate any advice or guidance from the community on how to proceed.
Use Keycloak’s login screens. Customize look and feel with a tool like Keycloakify. DON’T REINVENT THE WHEEL.
If you are struggling with some of the core concepts of OIDC and Keycloak, that’s normal, and we can point you to resources and documentation that can help. But, if you really want to implement a “custom login application”, you’re on your own.
I don’t want to reinvent the wheel; I just want to separate the login process from Keycloak while still using Keycloak through its APIs. I plan to implement many custom features during and after the login process, such as:
Logging in with a username and PIN
Internal calls to services for SCA (Strong Customer Authentication) eligibility checks and performing SCA operations (2FA)
OTP via SMS (using an internal service for generating codes, configuring SMS providers, etc.)
And more.
All of these functionalities could be implemented using custom SPIs (custom authenticators, custom OTP, etc.). However, this would require a significant amount of custom code, tightly coupled with Keycloak’s implementations. My main concern is that Keycloak might stop supporting custom SPIs in the future, or there could be major breaking changes to the Authenticator interface or other components.
We are currently using version 22.0.5. Does the community have any plans for significant deprecations or major breaking changes around SPIs, authentication, 2FA, or similar features?
To avoid these potential issues, I am exploring how to achieve the same objectives with a custom login page.
You can do all of those things with custom authenticators. Given that all of the authenticators in Keycloak are built using the same SPIs, there is almost no chance they will make breaking changes.
However, this would require a significant amount of custom code
Implementing the few things you have mentioned as SPIs is trivial compared to the amount of code you would build to correctly implement pages for all of the authentication flows. You’re not just talking about a “login page”, but pages for all possible flows and error conditions.
But probably the most important thing to take into account is that nobody will help and support you if you choose to build a custom UI. In contrast, there are lots of people who are capable and motivated to help you with SPI implementations.
The idea behind OAut/OIDC is to let the user only enter its confidential and secret data (credetials) om the secure server (Keycloak). Therefore, the SPIs and Theme templates are made to adjust Keycloak to your custom requirements. The SPIs won‘t just dissappear, just because you are afraid of.
Habing a separate application for this means building a man-in-the-middle and at least one (likely more) more entity gets on touch with the users credentials, which schould be avoided by all means.
I’m working on a similar case where there is a need for a API based approach for Authorization Code with PKCE which is best suited for Native Mobile Apps, But WRT the user experience I feel that the redirection on mobile app with Mobile native browser will not get the best user experience. But i see the other tools like Forgerock and PingIdentity has API based authentication approach is there compromise in the security here ? Can you kindly help me to understand if such similar API based authentication is possible from keycloak end ? Additionally i am lookin for a option only for Native Mobile Apps. I agree with your point on man in the middle or applications in the middle between the user and Identity server.
I don’t think in terms of tools, I think in terms of specifications.
Just because someone else is doing anything, it doesn’t mean that it’s a proper solution.
I don’t know the features of the other tools, I can’t tell anything about it.
