I am fairly new to Keycloack so I don’t what I don’t know, so I am doing some research and I would like to gather some information about the following question.
Are there any resources that you recommend about creating a custom web server for serving theme pages?
Rather than serving those pages from the Keycloak server, it would be amazing to give control over these pages to Front End folks so they could leverage their technologies and tools and leverage Keycloak for APIs only.
We are currently working with NextJS and ReactJS stack for the web servers.
You can use Docker to develop the theme. Look at the example in https://github.com/zonaut/keycloak-extensions
A theme needs to be deployed into Keycloak, you can’t run it outside Keycloak.
Thank you very much for the link, I will check it out, really helpful.
My intention is to bypass that theme and keycloak completely, only leverage the APIs to gather the required information in order to recreate those pages.
I don’t know what the full scope of your project is but you will still need to use the Keycloak theme pages for login/register/… pages. At most you can create external pages for some account settings but that’s it.
Are there any details about potential issues of creating external pages for login (probably magic link, some oauth2, and SAML)?
Help me to understand what would be the problem of using my own server for those pages and communicate with keycloak using the admin sdk or something like that I am guessing
Do you understand that it is a browser-based protocol that makes heavy use of browser redirects?
Are you aware of a AuthN / AuthZ vendor (e.g. Okta. Auth0, …) that supports OpenID Connect and that allows you to provide you own sign up / sign in pages?
Yes, they do allow me to communicate using their SDKs for some of these workflows, I have used Okta before where I control some of these pages and use APIs such as Users | Okta Developer to “mimic” some of the workflows.
Maybe it wouldn’t make sense much to do it for OpenID Connect for sure due to the complexity of redirects as you mentioned.
Sure, where are you trying to get at?
I understand some of these workflows are heavily involved with browser redirections, but a simple username and password form are not, nor a reset password, or registrations … or many other pages, like account details and what have you.
Most people keep saying, I must use the theme but I can’t find any articulated reasons for it.
That being said, I may be wrong, more often than not I am, and I am not able to understand where are you coming from.
Are you aware of a AuthN / AuthZ vendor (e.g. Okta. Auth0, …) that supports OpenID Connect and that allows you to provide your own sign up / sign in pages?
And the answer is that the Authorization Code Flow is a browser-based protocol that makes heavy use of browser redirects and therefore you cannot provide your own sign up / sign in pages.
WIth OpenID Connect, the username and password form is presented by the keycloak web app running on a WildFly web server instance. Once keycloak validates the login, keycloak redirects the browser back to whatever application keycloak is “guarding”.
Comparing to Hydra makes little sense as it just delegates the full authentication flow. It’s basically just a thin OIDC wrapper, nothing more. If you want to use Keycloak this way you already can through identity brokering, which means Keycloak won’t render any login pages, and your application is required to do so. This would mean instead of implementing a custom federation API like what Hydra has defined you would do it using a standard and well known API like OpenID Connect or SAML.
@stianst thank you very much for your help on the topic, I hope I can consume some of your knowledge on the topic if you don’t mind. I think it will be more helpful for you to explain our situation.
At the moment we have some webservers running for these auth stuff, the devs control the experience using FE tools like next with reactjs and the design system components.
We are trying to let the FE dev to handle the experience of those pages
I am not sure about “comparing” but using Hydra as an example of what I am talking about since Hydra allows you to have more granular control (included user consent) since as I mentioned before, we would like to take advantage of our design system and react + next stack.
You may choose the “Resource Owner Password Credentials Grant” but I won’t personally recommend it. The Resource Owner Password Credentials grant is omitted from Oauth 2.1
@yordis in Zoom’s example, zoom.us/signin is a relying party/client and it’s handling the credentials (user name , password) of a user (Resource Owner) directly.
If you are interested in a secure implementation please check how Googles’ relying party/client (e.g: gmail, youtube) is integrated with their Identity Provider ( accounts.google.com ).