How to work with REST API for registering/signing-in users using phone/OTP from another web page?

Phone/OTP login is very popular. Yet when we asked the Keycloak team to provide it out of the box, they refused, claiming that it is not secure because of some attacks like operator swapping.

However, we still need this, because some customers want it. This is the scenario:

  1. We create a phone/OTP form outside Keycloak (since we are not Java developers and we have failed for a couple of reasons to extend it)
  2. The user comes in. Enters his phone number. Either he exists, or he is a new user. We create an OTP and send it to the user. Yet what should we do in this part with Keycloak?
  3. The user receives the OTP and enters it. We now want to sign in the user and get the OIDC JWT. How should we use REST API for this purpose?

I know that we can use REST API if we have username/password as below:

curl -X POST '' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'client_id=your_client_id' \
--data-urlencode 'client_secret=your_client_secret' \
--data-urlencode 'grant_type=password' \
--data-urlencode 'username=your_username' \
--data-urlencode 'password=your_password'

But in this case, we do not have the password. In other words, we do the authentication part, and we want to ask Keycloak to give us a token for this username without a password.


There are some possibilities to implement a secure login for human end users directly in Keycloak.
First, always use a web based OIDC or SAML redirect from your app using system standard browser, then authenticate at Keycloak by
(1) Username + (strong!) password + MFA, or
(2) Username + Webauthn (FIDO2, Passkeys, …), or
(3) use a web based OIDC or SAML redirect to a third party IdP which itself is using (1), (2) or (3)

Keylcoak has a user registration option, user self service account console, both are customizable (ok, modifying the user account console is painful), you can even implement your own user account console, there’s an OAuth-secured end user API for that. So there’s everything you need, it’s recommended to use that instead of implementing your own login stuff.

Almost every online banking system kicked SMS-based TANs due to security reasons already years ago.
And sorry, “because some customers want it” is not really a valid argument to do security nonsense.


@mbonn, please look at Ory. And also Here

There is GitHub - p2-inc/keycloak-magic-link: Magic Link Authentication for Keycloak for an email based login flow.

1 Like

Keycloak is, like most other IdPs also, an opinionated implementation of an OIDC provider.
Just because one provider does offer something, that doesn’t mean that
a) Keycloak must/should do also the same and
b) the offered feature is legit/secure/proper

If Keycloak doesn’t offer some desired features ootb, most of the time, there’s a reason for it. But everyone is free to extend Keycloak with the provided SPIs. They are here to get used.

And, just like @mbonn wrote, “because some customers want it” is not a legit requirement for security. Most of the customers don’t know about security and it’s in our all responsibility to teach them the proper things, and not just implement what they want because they’re throwing money at you.


I agree with dasniko and mbonn.
Nevertheless, OTP login is still used everywhere. Luckily, nowadays we can offer more secure passwordless alternatives. However, for some business units and use cases, relying on this authentication mechanism is common, and it’s also common to conduct risk analysis to implement MFA in certain scenarios to mitigate the risks stated earlier.
But, again, agreeing with dasniko in relation to SPIs, it’s frequent that you end up customizing Keycloak. Therefore, find some time to learn Java + IAM :grinning:

@dasniko I respect you so much because what I learned about Keycloak was mostly based on watching your YouTube videos and posts here.

However, I disagree in this special case. Security is context-based. It’s even context-based in the real physical world. The security level required for holding the Olympics is different than the security level required for holding a homemade birthday party. In the second case, there is still the probability of an armed attack, yet nobody hires a snipper to shield its homemade birthday party against armed attacks.

It’s a huge mistake to think that all companies should spend the same for security and have the same security requirements.

The security requirements for a bank can not be compared with the security requirements for a simple online shop with a limited user base. Banks can afford hundreds of millions of dollars to be spent on security. That online shop, can not afford more than a thousand dollars. Comparing them and prescribing one single solution for both of them is clearly a strategic mistake.

Phone/OTP is a viable solution for the security requirements of that small online shop.

Yet you are right. Keycloak does not have any obligation to implement features as the community needs them. That’s fair.

@embesozzi, that’s the point. As I mentioned before, Keycloak is very expensive. You’re right. I can spend time and learn Java + IAM, or even hire somebody to do that. Yet that means “money”. In business money talks as we all know it. Some companies (like mine) do not have enough budget for that purpose. I can’t hire a Java developer. I simply can’t afford that. I have tried to outsource Phone/OTP and failed a couple of times for multiple reasons, I even tried to create the plugin myself, but I failed at even building the simple example that comes with the Keycloak source.

Anyway, now I’m on my way to create a simple Phone/OTP login in React and .NET and I’ll use Keycloak’s Admin API for that purpose. Thank you.

That’s your opinion. As I already wrote, Keycloak is also opinionated. I’m on the Keycloak-side. Period.

That’s definitely the wrong way. The ADMIN API is for ADMIN purposes, not for authenticating users. Using it for authentication might yield in unknown attack vectors. It’s not made for authentication.
The proper way is to implement a Authentication SPI. Yes, there’s knowledge required. But simply using an API where you think you don’t need knowledge… famous last words… :bomb: