I am developping a vue application protected by keycloak using keycloak-js.
I have a requirement that each user have an account page in my app to change their password.
.
However it seems that keycloak has no endpoint to check old password.
How can i achieve this ?
I am wondering if this is the appropriate way to do with keycloak or not ...
I already tried the update password action that send an email with magic link to the user so they can change their password. However it is not compliant with owasp recommendation that advise to force user to type their old password each time.
An alternative approach is for you to create a Keycloak client with Direct Access Grants enabled (i.e., Resource Owner Password Credentials Grant in OAuth2 terminology).
Then you can use the token endpoint and exchange the username and password for an access token. If the password is correct you get a token, otherwise it fails. Consequently, you can use this to infer if the user has inserted the old password.
In this GitHub repo you can see an example of how the call to the aforementioned endpoint would look like.
Related
I am creating a API using nestJS. As I am currently working on a "Proof of concept", where I am authenticating the user by verifying their "credentials" (username and password), then the user (developer) get a JWT token back, which the user sends as Bearer token.
Moving forward, I have some concerns using username and password to issue an access token. As I understand the option would be to use an ID provider og some sort. The best would be to use something like Azure Open Id Connect provider (but that means that the users needs to have a Microsoft email account of some sort?). I could even write my own?
So my question is: What would be the recommended solution in order to authenticate the user so I can issue a bearer token?
You need to set up middleware "https://docs.nestjs.com/middleware" go through this link.
I am currently in the process of wrapping my head around OAuth2 and OIDC. I know what all the grant types are (namely the grant types "Authorization Code", "Client Credentials", "Device Token" and "Refresh Token"). However, these four grant types do not include an option to pass a username and password. I get that there is a password flow, but this grant type is forbidden according to the Security Best Practices.
I also get the problems with the password flow, but I do not know how to replace it - after all, the user needs to enter their credentials at some point.
Is there anything I am missing? I would have thought that there is a single, trusted client that uses the password flow and that all other clients are redirected to, when a user wants to sign in.
I think I understand this issue a little better now although I may be projecting my own requirements on to your question a little bit here.
The Password Grant flow previously allowed a single client to authenticate multiple end users with the API. Let's say you run a shop and your delivery company have an API. Your shop sets up a client and each of your staff members can log in to their own account via the client.
In this case to log in they need to provide the client ID and secret as well as their username and password which Password Grant allows.
However in order to pass the user credentials to the API, the client needs to handle them in plain-text.
That's where the Authorisation Code flow takes over. Essentially it defers the login process to the API and the user enters their credentials there.
But what if your client is the API user? The shop users log in to the shop application and the shop application authenticates with the delivery API as the shop not the end user.
The Client Credentials Grant is the appropriate choice here. The documentation talks about using the Client Credentials Grant "outside of the context of a user" but this doesn't mean that the client itself can't be associated with user within the API identified and verified by the client ID and secret.
In this case the client has all the credentials is needs to handle logging in to the API without requiring intervention from the user.
In any situation where the API handles the authentication of an end user, it is fair to expect the user to be actively involved in the process and therefore to be able to interact with the login screen provided by the API via the Authentication Code flow.
I am currently using Auth0 to allow users to log in to an application. I am building it using the embedded approach. I see in the Auth0 documentation that they support passwordless login for SMS and email but I am not sure if that is the correct approach to use for a one time code when a user forgets their password?
Has anyone developed a forgot password and reset through embedded with Auth0? What approach did you use? Is passwordless strictly for logging in?
Important - this is not the universal login approach.
Thanks.
There are multiple ways in Auth0 that user can be authenticated. Those are categorized under the Connections in Auth0. Passwordless is one way of doing so. In this approach there is no password involved in. Which means, there can’t be a use-case, where the user forget his password for your application. (What can happen is that user forget his password for his email account or user would no longer have access to mobile phone, where he receive the SMS from Auth0 for authentication.) So passwordless is not for reset user password. It is just for Authenticate the user.
If you provide an option to login with Username and Password you can use Database connection type in Auth0. In this approach, there is a use-case where, user forget his password for your app.
In that case your application should provide the forget password option. In Universal Login, it has built in support for this. However, as you don’t use Universal Login, you may have to implement that by yourself.There are couple of methods which are explained in Auth0 Documentation. One options would be to use change_password endpoint in Authentication APIs. This will send an reset password email to user. Then user can use the link given in that email to reset his password. There is another option, where you can generate a password reset ticket in Auth0 using the password reset ticket endpoint. Hope you can use one of them for your requirement.
I've stood up an instance of identityserver4, an API project, and a UI.
The workflow is as follows:
User visits the UI.
User provides user name and password to UI.
UI sends credentials to back of web app, which uses a password grant to authenticate the user with IdentityServer4.
IdentityServer4 returns a token.
Token is used to identify who the user is to the UI and that the user has access to certain sections of the site.
When the user needs to do something within the site, the token is passed to the API via bearer auth.
The password grant isn't negotiable, as this is a first party app and it makes no sense to redirect the user away from the main site.
What's the proper set of middleware to use for this? Should I just use a CookieAuthenticationMiddleware and attach the token as a claim? I'll need to access the claims from HttpContext.User claims. Do I need to use IdentityMiddleware?
You can request identity scopes using the password grant type and use the userinfo endpoint to resolve them to claims - like in this sample:
https://github.com/IdentityServer/IdentityServer4.Samples/tree/dev/Clients/src/ConsoleResourceOwnerFlowUserInfo
And yes - you can use the cookie middleware to persist those claims and the access token for later usage.
I have a web application built using React that has an existing User/Session system. Right now, username and password are passed to server to authenticate and create session.
Enter Facebook Login (web). I want to allow for both username/password and also Facebook Login. So, now Facebook Dialog box appears and users can connect. I now receive the Facebook User Id and access token (short-life) on the client side (not the server side). How, now do I authenticate this user on my existing system and create a session?
If I use just the user id, this reveals a security issue (anyone can authenticate with a known user id and get a hijacked session). The short-lived access token is just that, short-lived. So that can't be used as an effective "password". So, what is the best way to securely authenticate someone on my existing login system if they've authenticated themselves via Facebook.
Thanks so much.
Found another user with the same issue here. It was resolved by the following:
The Facebook login request returns user id + short lived access token (client side).
Use the server side Facebook SDK to check the validity of the access token (will return user_id and app_id fields if valid).
You can trust the user_id field returned from the Facebook API to check against your existing user database.