Custom web server for UI pages

Hi there,

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.

Cheers,

1 Like

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

read How to create a custom login page using javascript adapter

I read it, really informative,

Worth saying that I am not asking for a JavaScript driven workflow.

@stianst How to create a custom login page using javascript adapter mentioned the theme, but once again, we would like to leverage keycloak as an API only.

I still can’t understand why this is not possible or the potential issues.

Will your application use OpenID Connect?

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?

See: OAuth 2.0 Authorization Code Grant

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 https://developer.okta.com/docs/reference/api/users/#create-user-with-password 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.

The question I asked was:

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.

1 Like

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”.

Here is an example from other tookit: https://github.com/ory/hydra-login-consent-node

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.

3 Likes

@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

Examples:

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.

I read this documentation https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.0/html/server_administration_guide/identity_broker

Yes, we would like to use Keycloak for configuring all these Oauth2/SAML integrations but yeah, we would like to control the experiences

Examples:

Thank you for your support.

Hi @yordis ,

If you are looking for the login/authentication experience control in a relying party, please note that this kind of login process has security implications. You can find more details here - https://www.scottbrady91.com/OAuth/Why-the-Resource-Owner-Password-Credentials-Grant-Type-is-not-Authentication-nor-Suitable-for-Modern-Applications

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

Regards,

Vinod

1 Like

What do you mean exactly by a relying party?

Relying Party, client, web application, web property = Generally a web application that wants to authenticate and eventually authorize access to data.

https://wiki.mozilla.org/Security/Guidelines/OpenID_connect

Right, I don’t see ourselves using this unless I am misunderstanding something.

Take https://zoom.us/signin as the perfect example of what we would like to do.

@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 ).

At what point you let the user sign up with username/password if you own the Identity Provider and you dont want to use OAuth2 to sign up?

I am confused where you are trying to get to, Keycloak allow you to use username/password today as far as I can tell … same thing.