I want to enable login in my application using following call flow:
Step 1: User visits the Application website and enters the Mobile Number or Username.
Step 2: Application requests Keycloak to generate the OTP for the user associated with the username. The OTP returned by Keycloak is sent to User via Email or SMS.
Step 3: User enters the OTP and the application sends the OTP to Keycloak to validate against that user.
Step 4: Keycloak validates the OTP and responds back with Access Token.
In the above call flow, I need 2 APIs from Keycloak.
API to generate the OTP for given username
API to validate the OTP provided by the User and respond back with Access Token
Please let me know if this login call flow is possible or not using the latest Keycloak version.
Related
We have our own CRM portals and we want to offer OpenID based User authentication and authorization.
To achieve this we have decided to use Keycloak.
The flow we formalized is below and we are stuck due to may be not knowing much of the configurations inside Keycloak or may be its not possible.
User visits our existing CRM login page where he/she provides the username and password.
On click of Login the keycloak custom Identity provider should authenticate the user
Keycloak should receive the authentication success response and generate the JWT token
User is redirected back to CRM dashboard with the help of redirect_url configured in custom IDP.
What we have done till now,
Created a custom IDP inside Keycloak.
Configured all endpoints in this custom IDP
No custom authentication flow yet, all defaults i.e. First login flow is set to 'first broker login'
Challenges we are facing currently,
User on our CRM login page (Not the keycloak login form) and click on login button
The Keycloak login form is shown to user. We dont want any keycloak login pages. but instead the custom IDP endpoints should be executed and a JWT is returned back to redirected CRM application.
Is this possible to achieve the flow I mentioned above?
You need to adapt the browser Authentication Flow
Authentication -> Flows -> Browser
There you find the Identity Provider Redirector. Click Configure and specify a Default Identity Provider (you need the alias of your IDP there)
Normally all available IdentityProviders are listed beside the login form. But if a DefaultIdentityProvider is configured, KC immediately redirects to the external IDP.
I used keycloak as an authorization server in my projects and also used the user's mobile number as a username with keycloak, now I want to provide a possibility to users to be able to change their username (mobile number), as:
the user enters a new mobile number
keycloak sends OTP code to the user
user enters the received OTP code
keycloak validates that code
finally username (mobile number) will be changed
how can I do that?
I am using a keycloak auth Spi with sms auth which works finde for browser flow.
My requirement is to use it with direct access grant. Therefor I have to create a formless challenge which conntext the auth session between two requests.
I am struggling with passing the parameters in the response. I've analyzed the request when entering the sms otp in the login form. I know the request object in detail but I cannot figure out where to get the required parameters from the sessin object within the authenticate methid.
Params are:
a cookie
code
client_id
execution
session_code
tab_id
My question:
Is it even possible to use this flow without a form?
Where do I get the parameters from?
If Keycloak's self-registration form is used, once submitted, it will send an email verification link to that newly registered user.
Once the user clicks the link, his email will be verified, and it will redirect him to the redirectUri from his client and provide the authorization code, which is perfect.
The problem arises when I don't want to use Keycloak's registration form, instead I have a custom registration mobile form, which sends the user data. Those data is then sent to the Keycloak by Admin REST create user API.
Once the user is created, by triggering /send-verify-email or /execute-actions-email APIs none of them are returning authorization code in the end. Yes, they do redirect to the redirectUri which you specified, but I need authorization code as well, in order to be logged in automatically upon clicking on the link.
Desired result:
User should be able to register and then he should be able to login thrugh a mobile app (event if the email address isn't verified), the app shows a warning that email isn't verified and some app functionality a disabled
What i have:
native mobile app that has user signup and signin functionality
api server consumed by the app
keycloack instance
signup functionality is done by api server, it is a keycloak confidencial client that can create users
signin is done by the mobile app directly with a post call to keycloak /token endpoind that returns access token
all good, now i have a token that can be consumed by my api server and i know that it is a registered user with unconfirmed email address
The problem is that user don't receive any Welcome/Confirm email, but: if user goes to keycloak LogIn webpage and try to login with newly created user then he receives an email from Keycloak, but for LogIn through api there are no emails. Is there any way so solve this? Am i doing something wrong?
The only way to request user to verify emails is by requesting "Verify Email" action, but if i do this then user can't login with unverified email anymore
Login is done with POST to /auth/realms/realm/protocol/openid-connect/token and with {grant_type: 'password', password: 'string', username: 'string'} body
Calling PUT /{realm}/users/{id}/send-verify-email seems to behaves the same like requesting Verify Email to /execute-actions-email
I know I'm a few years late for this answer, but for anyone who comes here in the future, the devs answered in this thread here
This is a limitation with the execute actions endpoint and it uses a
generic email. It's not a bug, rather a limitation
And that's it. They have a specific endpoint just to send an email of verification but it's only a wrapper to the endpoint execute-actions-email