In federated identity management, the relying party application is transferring the user registration and authentication capabilities to the identity provider, this will help to reduce the attack surface. The user registration and authentication will be handled by the identity provider. Similar to the Gmail use case, when someone wants to log in to Gmail, they will be redirected to accounts.google.com for their identity management.
The main benefit of using Keycloak or different federated identity provider via OIDC is to reduce the complexity of user registration and authentication in the relying party applications. I would highly recommend watching the following videos.
I understand. That will happen since we are using accounts.x.com as Google for that, what I asked for is to have control over the webserver to serve the registration and login page and use keycloak server (for those two pages) as an API.
Well, this is literally what I dont need at the moment since we want more control over it, we are totally fine with the complexity.
I watched those videos before posting it, amazing for understanding Keycloak capabilities, but doesn’t answer what I am looking for, thank you regardless, those are nice videos.
I am not sure if I made it clear that having full control over the account profile, login and registration (probably consent screen as well) experiences is what we are asking for.
I do not understand why you keep suggesting to “just use keycloak” for those cases when that is literally the problem for us right now.
Statements around “it is more secure” is a fallacy, any software is insecure when you dont take the required measurement.
Is Okta less secure than Keycloak because allow us to use the following capability: Users | Okta Developer
Again, we own the Identity Provider server (keycloak) so what’s the problem.
I may be missing something because I don’t understand where are you coming from.
Resource owner password credentials grant type insecurely exposes the credentials of the resource owner to the client. Even if the client is benign, this results in an increased attack surface (credentials can leak in more places than just the AS) and users are trained to enter their credentials in places other than the AS.
Furthermore, adapting the resource owner password credentials grant to strong authentication, (e.g: WebAuthn, otp, etc. ), and authentication processes that require multiple steps can be hard or impossible.
Resource owner password credentials grant trains people to get phished.
I am not using the Resource owner password, especially after being discouraged. As of today, we would like to use a magic link, oauth2, and SAML so no username/password for us so far.
Anyway, thank you very much for the help, apologies if the conversation is frustrating for you.
We will deal with Keycloak way to do things and adjust our strategy around it. Thank you very much.
@yordis , no worries. The point I am trying to make is that it’s more secure if the Identity Provider will handle the user authentication and registration process. It’s not about Keycloak’s way, it’s how the OIDC, SAML, etc are recommended to use. I hope the following links will help.
I am happy to help you if you are interested in a secure solution.
It’s more than just hosting the UI, it’s about who’s handling the authentication process. I would recommend reading the OpenID Connect specification as it may help to get a better idea on the related information we discussed.
@vinod, I think what @yordis is trying to get to here is the following: Keycloak serves some HTML, JS, and CSS for a few pages (e.g., login, password reset, etc.) and communicates with the API to securely handle authentication via OIDC, SAML, etc. Instead of relying on Keycloak’s hosted HTML, JS, and CSS pages, is there a way for one to host their own servers and implement the same functionality that Keycloak implements in those pages? In this case, one could host those pages at accounts.example.com and one would have to implement all the complexity to properly handle security at accounts.example.com. With this, then one would be able to use accounts.example.com to authorize access to app.example.com, api.example.com, etc. The main difference is that since the accounts.example.com pages are being served by a custom server, as opposed to Keycloak, one can rely on modern front-end frameworks like Next.js, as opposed to having to use Keycloak themes.
I think this is a very valid question as I found myself asking the same question. And not just for Keycloak, I wanted something similar for Auth0 but it doesn’t seem they provide it.
So, @vinod, do you know if it’s possible to custom implement an accounts.example.com similar to Google’s accounts.google.com backed by Keycloak APIs?
Perhaps this means that one would use Keycloak as the identity provider and would have to implement their own OIDC provider if I’m understanding the nomenclature correctly?
The answer is yes you can! The admin-console is a client just like all other applications. So setup a new client and when our user has the rights he can call the admin rest api of keycloak, even if it’s not on the same host.
We are currently starting to build a new admin console based on react and patternfly and it we will use the same technique to build it, we might even keep it as a feature. See the admin console repo
It’s correct though that you can’t build new themes outside of keycloak as themes have a hierarchical nature and use some bootstrapping by the server.
Thank you very much for the help on this topic, and yes, that is exactly what I am talking about.
I was actually starting to work on something similar (a distributed UI in a sense https://youtu.be/_S1Bl6Pt_uw) and interested in creating the Keycloak subsystem on it (just that I am using Material UI but probably we will end up using the same libraries)
Is there any conversation happen somewhere that I could participate in or anticipate some work? I am interested in the topic.
I am a bit confused by your response, admin-console redirects to Keycloak when it is not authenticated. So I am not sure how admin-console could be an example of what we are looking for, there is no authenticated user when you are trying to log in.
Are you suggesting to create a server-to-server client and do a pass-thou or something like that?
Also, if you know of any example of those Keycloak theme pages built with React or any other modern framework would be amazing, I googled it but I didn’t have any success.
Why would the admin console not be a example of what you are looking for? Yes it redirects to keycloak when you are not authenticated and then it redirects back to your application when you are authenticated. Then when the user has the rights to invoke the admin rest endpoints it all works. Have a look at the admin-console repo and you’ll see what I mean.
Right there is the new account console that supports theme-ing and is hosted by keycloak itself. You wanted to see an example of that right?
Now the new admin console is going to be a separate completely standalone application and will use keycloak authentication just like other applications that use keycloak for authorization / authentication, by using the keycloak Javascript adapter, it doesn’t need a proxy server. If you have full control or not depends on the role the logged in user has. The client does know who the user is otherwise keycloak would be quite useless. When you call backend rest endpoint and you don’t have enough rights you get a 401 response.
Right, but there is no logged in user when you are trying to login/sign up/reset password and so on. That is what I am trying to say.
It depends, with a proxy server as Ory does, you use Keycloak as just another API server, and saving configuration and so on that you would normally query using a Keycloak server itself.
