In Cognito, is there any way where I can allow a user (Account status: External provider) to create a password for their account and do login using username and password.
I am using a Hosted UI.
Consider a case where a user logged in using the Google sign-in method and the user pool has a user entry. I have given the user a preferred username and email options to sign in. but since it does not have a password yet, the user should be able to reset their password using forgot password method.
But I get the error "User password cannot be reset in the current state."
Can you please suggest if there is any method or workaround for this.
Thanks.
You cannot create a password for an EXTERNAL_PROVIDER user.
The password is handled directly by your provider and Cognito Hosted UI only retrieve the user fields you previously mapped in the configuration.
If you try to change the password of your user connected by Google, you will get the following error :
User is not authorized to change password.
Because the password can only be changed with the provider.
Related
The requirement is that an admin should be able to login as any user anytime with just username. So I need a way to authenticate a user with just a username and no password. Is there a way for that in aws cognito? Thanks in advance !!
As far as I know you've got this and this so you can not sign in as a different user using just the username.
I am using Microsoft Azure authentication for user Login ,
After login of user there is change password section in my application where user provide his current password and new password so my query is
Is there is any Api(Graph) to GET Current Password for that user OR Any API(Graph) through which we authenticate current Password which provided by user
Is there any other scenario which help me to authenticate current password which was given by user while changing password
Or any other way to get current password for that user
thanks
There is no way to get the current password for users.
It would be a massive security vulnerability and imply they store them insecurely.
There is a way to authenticate a user like that, but it won't work if the user has e.g. MFA.
I would suggest a different approach.
Check how old the authentication is (id token has the time it was issued).
If it is older than, say, 15 minutes, require the user to authenticate with AAD (prompt=login).
You can also require MFA for the login if you know all your users use it.
Then they should be able to give a new password, which you can then set with Graph API.
So instead of making a call to check the current password, require a fresh ID token and rely on AAD to check the user credentials.
Also, the users should be able to change it themselves already as written in docs: https://learn.microsoft.com/en-us/azure/active-directory/user-help/active-directory-passwords-update-your-own-password
From our native code, when attempting to change a user's password in a password reset flow, the password's complexity is not applied when we use an Admin account to change that password.
We are using the procedure as explained here: https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/users-operations#ResetUserPassword
In other words, when we attempt to change a password of a user using the user's identity token, the conditions for a password are applied.
But if we attempt to change that password by an Admin instead of the user's JWT, in a password reset situation, the minimum password requirements are not applied.
I suspect that maybe this has something to do with User Flows, but I am not certain.
Any ideas ?
Using admin to reset the user password with the AAD graph API, when the new password not complied with the complexity policy, it prompts an error.
Using admin to reset the user password with the Microsoft graph API, when the new password not complied with the complexity policy, it also prompts an error.
For a specific user in Azure AD, say (xyz#mail.com), when I use a specific old password such as pass#321, it redirects me to the Update your password screen stating - "You need to update your password because this is the first time you are signing in, or because your password has expired."
While if I use the current correct password, it signs in successfully. Or if I use some other old password or some wrong password, it correctly shows the message "Your account or password is incorrect. If you don't remember your password, reset it now."
Is there a way to flush out old password history from Azure AD or to debug the old password properties?
I can't delete the user and create again as there is lot of dependency in my team on that user id(xyz#mail.com)
Here's my question. To access our app, the users must be invited.
This means, we use an admin web app to create the user account in Firebase and we send him an invite to download the app and use it.
Now the next phase, how can we send to the newly created user his credentials?
Our first idea was to use a temporary password. We could send the password by email to the user and ask him to redefine his password at his first logging.
His this a good idea? I guess it's not
Is there a better way?
Thanks for the help.
T
There is no way to prevent users from authenticating with Firebase Authentication. So instead of depending on pre-creating of the accounts, you should ensure that only authorized users have access to the data.
For example, when using the Firebase Database, you could keep a list of authorized users in the database:
/authorizedEmails
t4ncr3d3#hisdomain,com: true
puf#hisdomain,com: true
And then you'd check the auth.email variable against this list in the database's security rules.
Instead of pre-creating the account, you could then simply email the user an invite to the app. E.g. an email with a link like http://myapp.mydomain.com/signup.html?email=t4ncr3d3#hisdomain.com
Then when they click the link, pre-populate the sign-up form with the email address you sent the message to and call createUserWithEmailAndPassword().
You could use the new (as of Nov 2016) firebase-admin library (java or node) to programmatically create users from your server side - see this link for details.
After that, you could send the email and password to the user via email, and allow only email based password logins. Unfortunately, you can't force uninvited people to stop authenticating with your app, as they could manually invoke the APIs used to create a new account on their own, as you see on the same page. However, you are under no obligation to provide a login mechanism via your UI. They would have to use their browser to type and invoke the JS needed to create the account.
If you are OK with people forcibly creating accounts, but you would like to lock down their access, you could do something similar to what Frank mentions in another answer by using admin control of the database to restrict access to those users you have created and invited with a special flag in the database (that only you can modify using the admin SDK) that acts as a gateway into your app. If you perform the security properly, that should prevent those whom you didn't invite from using the app, even if they can effectively authenticate with it.