I'm in need of an authentication & authorization service that can manage our app's pool of users. I stumbled upon Keycloak and have been checking it for the past few days, but I'm wondering why Keycloak doesn't provide an API for a client to sign-in/sign-up on behalf of a user.

Is this because Keycloak is exclusively made for Single Sign-On? Or is there a more fundamental reason to it?

I was reading this blogpost about ROPC - https://www.identityserver.com/articles/fact-sheet-the-dangers-of-using-the-password-grant-type-with-mobile-applications - and I was struck by how harsh it was. While I can understand the caution for third-party apps using the authorization service, the author seems to stress that not even first-party client app should be able to authenticate on behalf of the user.

In practice, it seems that some people are trying to get around this by using the admin API. This repo, for instance, logs in to Keycloak as an admin and then creates users out of it. Login is then managed using the highly-discouraged Resource Owner Password Grant. The sign-ups, in particular, isn't this abusing the admin API? It's practically giving admin credentials to a client that in the initial design was so untrustworthy that passwords shouldn't even be inputted there. That's madness!

In contrast, for example, I found that it seems Amazon Cognito allows this lightly - https://docs.amplify.aws/lib/auth/emailpassword/q/platform/js#sign-up. It even provided support for SDK integration that was displayed under the service's main page to show "how easy it is to integrate into your app". Are they simply violating OAUTH guidelines? Or is this actually acceptable practice - to let user input their credentials into your app? Should I even use an IAM for customer-facing applications like an e-commerce?

Thanks a lot.

  • I find the arguments you've linked to against allowing this pretty convincing and I think they already answer your question. If you think that they don't then please explain what you see different - instead of basically asking an already answered question again without even addressing the arguments from the answer. Or what makes your use case so special that these arguments don't apply? Sep 14, 2020 at 3:09
  • I guess I'm thinking from a business perspective - virtually all apps out there has sign-in/sign-up directly from the app. Imagine downloading Grubhub and having to redirect to the authorization service! That'll make the UX part of the sign-up/sign-in very limited. If this is the case, then aren't they all "impersonating" the user? But why does this matter when the user's only interface to your system is your first-party app?
    – aIKid
    Sep 14, 2020 at 3:25
  • At the end of the day, I can see how it's very useful to manage the administrator'dashboard access. I'm just curious if Keycloak is even the right tool to manage "public" users for a customer-facing app. If not, are there other open-source authorization services out there that is more suitable?
    – aIKid
    Sep 14, 2020 at 3:28
  • "... virtually all apps out there has sign-in/sign-up directly from the app ... That'll make the UX part of the sign-up/sign-in very limited." - This is basically the whole point the article you've linked to was written: "Having trouble convincing your colleagues that using the password grant type is a terrible idea? Is the allure of owning the login UI too strong for your design team?". You just reiterate this without actually addressing the arguments in the article which explain why this approach is a bad idea from start. Sep 14, 2020 at 3:29
  • I can see that they are valid arguments - I'm just not convinced by the author's authority. He gives an example of using "Facebook" and "Google" login, but 'Facebook" and "Google" itself don't use a separate web view - disjointed from the rest of their system to authorize, right? Or am I not understanding how they work?
    – aIKid
    Sep 14, 2020 at 3:37

1 Answer 1


Keycloak does allow the user to sign-in by providing credentials through your app. However, since this is considered less secure, it is not enabled by default; you must opt-in to this behavior.

I think that AWS Cognito enables this by default to make it easier to integrate. Whether or not this is a good trade-off is debatable.

See the discussion here: https://stackoverflow.com/questions/39356300/avoid-keycloak-default-login-page-and-use-project-login-page

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .