Custom Login Page with social login (not the one from Keycloak)


I am trying to create to have my own custom page for the login into Keycloak, with user & pass, but also with social login (Facebook & Google).

Is there a way to have my completely self made login page, which means a page that is not hosted on the keycloak instance ? Not only with email & pass, but also with the social buttons ?

Note: I do know how to customize the default login page, and this is not what I need.

My problem: I am currently developing a mobile App (with Flutter), and it is advised to use the AppAuth library. But with that, when the user wants to login, she is redirected with a browser (out of the app) to the default login page.
This is a really bad user experience, and I would like to have my own Login Screen in the App.

Thanks !


I have a similar issue. In general I want to use Keycloak as an API for authN (authentication) and write/control my own UI login flow.

1 Like

maybe this will help you:

It is always recommended to use the system default browser to do the SSO login. Everthing other tends to be security nonsense, regardless of user experience.

1 Like

I have often seen such articles and they always go like

You should never open an embedded web view with the OAuth prompt

Okay no embedded Webview. But what about native UI elements ?
All my apps (Evernote, Strava, Soundcloud,…) allow social logins with native elements, without opening any browser. Those that means they are security nonsense ?

Most likely these other apps don’t use OIDC.
Keycloak is an OIDC implementation. If you wanna use Keycloak, you are using OIDC. Thus, you should stick to the principles and spec.
Everything else is security nonsense. Period.

1 Like

Check if this git repo is helpful or not login-sample/Login.tsx at master · cindy-choi/login-sample · GitHub

I am also studying keycloak social login provider will get back to you in few days if I am able to solve that issue :slight_smile:

That’s a good point. We’re using Keycloak for AuthN (OIDC) and we’re using using OPA for AuthZ. However, I don’t see why that should prevent following the spec via an API vs handing full delegation of the UI over to Keycloak.

So does that mean if you have your own UI login/register page then handling it via admin APIs is same as using default keyloak login/register theme? Both will work equally same right? But by handling via APIs will there be any issue or something which needs to be taken care of while implementing?

What you can do:

Configure keycloak as usual, make sure you can login users via user/password and google button. Make sure your application can do a normal (browser mediated) login with keycloak, both with user/password and with google button.

Now you are ready to implement your own authentication form. You will be using the direct grant OIDC flow.

In your own implementation, when user chooses user/password form, use that information to do a direct grant request do keycloak (basically a post request with the user and password as parameters) (you’ll probably want to do that over HTTPS). As this is not the normal behavior of an OIDC client, I don’t believe flutter library can do that, so you’ll have to find a way to give it the token received with the direct grant.

If the user chooses google’s button, you make a normal redirect to keycloak, but this time you pass the query parameter kc_idp_hint like in: ```

Because you provided kc_idp_hint keycloak will (hopefully) not show the user authentication form and redirect the user directly to google. This kc_idp_hint can be used with other identity providers too, not just google. For some providers, that will be the alias.

Alternatively, if your users will never use keycloaks’ user/password form (the one hosted by keycloak itself), you can disable this form altogether and instruct keycloak to always go google first. This is done by marking “Identity Provider Redirector” and “REQUIRED” in the browser flow (or in another flow, which you can instruct keycloak to use with your client in the “authentication flow overrides” part of your client definition) and setting “Default Identity Provider” to google (or other provider alias).

Hope this helps.

1 Like

Direct Grant can help you too.

Just do a request and if successful user credentials are valid.

I wonder what is so difficult to understand about that… Last try.

For authenticating end users, implement a browser redirect using the system default browser (or the SFSafariViewController on mobile devices), catch the redirect and work with the OIDC tokens (or SAML assertion, if you prefer that). There are many libraries doing that flow. Do nothing else. Never force your end users to enter their credentials to an app where they have no knowledge about the origin. Where they cannot see what the app is doing with their password. Where users cannot verify where the password is sent to and if this transfer is sufficiently encrypted. Of course, you (as you are its developer) trust your own app (and your backend or whatever…). Your co-implementers trust your app. Maybe even your boss trusts your app. But any other world-wide user can’t trust your app and should never trust your app.

In contrast, with the system browser, users can check the URL, they can check the quality of the TLS stuff. They can be sure that the crendentials are sent directly and only to the party which is able to verify them. They can be sure that there is no untrusted third party in the middle to grab the credentials. MFA auth flows can be done. “Hey, it’s really my well-known https-using home identity provider where I have to enter my password! And, very good, I use the browser I am always using when entering the password. And look, my home provider is asking me for my 2nd factor, as it always does for third party logins.” Or: “Oh, I do not need to enter my credentials because there’s an already established session with my home provider, I am just logged in…” That’s single sign on. Sorry, anything else is nonsense.

It’s important to train users to make these thoughts. And to make them aware of not entering their credentials to every nice blinking password field that comes along…

(The direct grant may be suitable for special logins/accounts, e.g. administrative tasks within a script where you have no browser. However, for such things we have the OIDC client credential grant, which is also higher recommended than direct password grant.)


Additionally, to second what @mbonn said, this is what the
OAuth 2.0 Security Best Current Practice, Section 2.4 says:

The resource owner password credentials grant MUST NOT be used. This 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 two-factor authentication, authentication with cryptographic credentials (cf. WebCrypto [webcrypto], WebAuthn [webauthn]), and authentication processes that require multiple steps can be hard or impossible.

And, as this is not enough, the OAuth 2.1 spec (yet draft version) thinks about removing ROPC.

1 Like

I appreciate your effort in educating the OP, but the OP is not obligated by law to follow a protocol if he doesn’t want to.

I’m pretty sure he got it the first time, that what he’s trying to do is not in the best practices, but why not let him decide if he wants to follow the best practices or not?

Sometimes you have restrictions that doesn’t make sense, but you have to follow them anyway.

What he wants is possible with keycloak. You can help him or just leave him alone.

1 Like

@mbonn @dasniko Thank for your reply, I really do understand the concept, that make sense.

BUT. When I open for example my Strava app, I see a Login with Facebook & Google buttons.
If I click on Google, the google popup from my Android comes and ask me to choose my account. I click and I am logged in. No password asked, no browser windows opened. Single sign on.
If I click on Facebook, a browser open (I don’t have Facebook app on my phone). As it is the system browser, and I am already logged into Facebook, I can just click again and I am logged in. No password asked.

Looks like all your security concern are covered.
Why can’t we do that with keycloak ? It feels like I am missing something…

Not everything what’s technically possible, should be done.
I don’t know how Strava does it’s auth process, I guess they have their own system. And this probably doesn’t have to follow the principles. :man_shrugging:

Yes. You are missing the fact that you are using keycloak as a middle man. Keycloak is an OIDC and SAML identity provider. Although highly customizable, it is actually implemented to follow those protocols and use cases.

You can connect your application directly to google and have that experience (iPhone has the best experience for google login, IMHO). The app itself (with the help of a backend API) deals with the user linking (google id with strava id).

What you are trying to achieve is not a pure OIDC authentication flow, so keycloak kind of gets in your way here. You can customize it (via a server plugin), but I believe its harder develop and maintain.

But if you are going to depart from a pure OIDC or SAML authentication flow, and customize things, I believe it’s simpler to make use of possibility already present in keycloak, the direct grant, because it’s just a POST request to a server (probably it’s the way Strava does it, with their own authentication solution, possibly not Keycloak-based).

If you want to completely mimic that experience, you’ll have a better user experience, but with a more complex solution.

My suggestion would be to deal with email/pass login using a direct grant and let the browser deal with google and Facebook login (mediated by keycloak).

Okay so I guess that the correct answer to the original question is that Keycloak is not made for such a use case.
Thank you


I suppose you can implement that with keycloak, but certainly it’s a mix between a custom authentication (POST with password and username) and identity provider linking.

Definitively possible with keycloak, with multiple possibilities with varied degrees of complexity.

I’d look closer to Direct Grant Flow and Client Initiated Account Linking.