I need to be able to have a Cognito User Pool user, with the ability to link several different social providers to that user so they can either login using a email/password (basic cognito auth) or via their social account ('email' being the common data field/username).
The flow I currently have:
1) User clicks sign with Facebook, my app handles the oAuth handshake and eventually get the accessToken and email address
2) At this point I couldn't find a way to detect if the user was already registered in the User Pool, so I attempt a Login call with a random password and infer from the error response if the user doesn't exist at all.
3) If the user isn't registered, I redirect the user to registration page so they can provide a Password. Once confirmed, I call SignUp to create a regular cognito user (unverified).
From this point I am stuck.. How do I then associate the Facebook account to this newly created cognito user?
Note: As I'm using custom UI flow for this so using the HoC from aws-amplify-react-native library isn't possible.
After trying every possible method mentioned in Amplify documentation, it seems social signin with federatedSignin cannot be used with userpool.
Related
i have used aws congnito for user authentication for my app. so here user direcly signup with the application and if the same user(same email) login with third party means using google or facebook in my case, it shows "#error_description=PreSignUp+failed+with+error+A+user+with+the+same+email+address+exists.+&state=dSUG682CKNVOB7mAF0safs7Mgn99xnuJ&error=invalid_request"
so how to handle this problem i want to get user to be authenticated if the user with same email
All my existing users have been authenticated using Phone Authentication method. But now we want to implement the Email and Password authentication method. For the present users, is it possible to link their accounts to the email and password authentication method using UID from the Phone method?
I am looking at the below:
firebase.auth().createUserWithEmailAndPassword(values.email, values.password).push(UID).
Again the UID is retrieved from the Phone Provider Method. With this, we expect that Firebase will create the user with the same UID as that of the Phone Provider not a new UID. Is this possible?
I am implementing this using Javascript.
What you're looking for is known as account linking in Firebase Authentication. The flow is:
The user signs in (in your case with phone auth).
You create credentials for an additional provider (email+password in your case).
You then link the new credentials to the existing account.
After this, the user will retain their UID from phone auth, but they can now sign in with both providers. You can repeat the process for other providers too if you want.
On my website, I have two portals for login. Portal A is login for learners. Portal B is login for teachers.
Both learners' and teachers' accounts are located in the same Firebase project, in another words, both types of accounts are located in the same authentication space. Both portals use the same simple login code:
firebase.auth().signInWithEmailAndPassword(user_email, user_password).catch(function(error) {})
Currently, the learners can login at both portals, and same for the teachers. What I am trying to do is to prevent the teachers to login at the learners' portal and vice versa. I am not sure how to implement this. I have made a setCustomUserClaim to give an identity to the two types of accounts on the authentication token. But I can only grab the auth token once the user is logged in, not before I think. Also, I have a Firestore collection that stores all the info of the users including their identity. But each user's document is named with their corresponding UID. The latter can be grabbed once they login in as well. Any idea on how to implement this?
Firebase Authentication has no built-in way to distinguish between these two types of users. It simply authenticates the credentials that a user enters, and ensure that they're correct. If certain users can only access a certain application or certain data, this is information that will have to come from you.
The above is important to realize, so I'll repeat it: Firebase Authentication allows all users to authenticate as long as they provide the right credentials. It has no way to block access to authentication based on application-specific information, such as your user-type. This type of authorization logic is part of your application, both in code and (if you use a Firebase Database) of your server-side security rules.
A common way to implement your scenario is to add the information about the types of users to a database (such as Firebase's Realtime Database, or Cloud Firestore). In this data you could for example store the email addresses of all teachers.
Now with this information, your code can then determine whether the person who signed in to the site is a teacher or not. If they're a teacher signing in to the student web site, you can redirect them, and vice versa.
AWS SDK (JavaScript)
I ported all of my users from a MSSQL DB to a AWS Cognito UserPool.
Now I need to have each one of my Cognito users in my Identity pool.
This needs to happen so I can move my user data into Cognito Sync's datasets.
Problem :
I cannot move each cognito user in my userpool to my identity pool.
I have searched the docs and I cannot seem to findout how to go about this.
I cannot log each user in because each user will need to reset their own password. (this is due to the way things are when porting users from a .csv file)
SOLVED
I loop through users in a batch.
Each user is converted to a Cognito User in a User Pool
Once the Cognito User is successfully added, I then log that user in manually,
Then I have to set the users password with a temp password
Next I get the successful method called
Inside the success method, I now have the user in the Identity pool because I logged the user in manually
Now I get the users Identity ID
Now I can set DataSets
NEXT IMPORTANT I have to set the user back to "RESET REQUIRED"
Then the loop continues and I process the next user in the batch
NOTE Make sure you do not have anything checked in you MFA portion in the Userpool or emails will be sent. Also emails are still sent in special circumstances. To get around this, I performed this task
Change the users email to fake#fake.com
All emails are sent to fake#fake.com
when you are done with the user and all is well, change the users email back to the correct email.
First, Identity Pool does not have users - just identities. Each identity corresponds to a User (A Userpool user or a Google/FB user) in case of authenticated identities and has an IdentityId (for all identities - authenticated & unauthenticated). This is generated when a GetId API call is made with an IdToken from the appropriate IdP (Userpool in your case).
Also, I don't see why you need to generate identities for all the users in your userpool. These identities are supposed to be generated on-the-fly. Design & deploy your app and when a user uses your app for the first time, your app will make a GetId call, thus generating an IdentityId.
I want users to be able to register on my mobile (web based) app and login using their Facebook account. Is this possible using the JavaScript API?
The user can login using Facebook, and the userID and auth code of that user can be sent to my server to create the account, but I see a security flaw because then anyone could then log in as anyone by sending a userID and their own auth code. So can user accounts not be done with the JavaScript API and only with a server side API?
All Facebook requests are also signed with a secret key that belongs to the app you've registered to handle Facebook sign-ups on your website, so you can use that to verify it comes from Facebook and not someone else.
This is also outlined in the registration documentation
Strictly speaking, it is not possible for the Facebook SDKs to explicitly create a new user. However, when you implement a 'Login with Facebook' button (see here for JS and here for PHP), Facebook's OAuth dialog appears, which will prompt the user to log in (if they are not already) or to sign up with Facebook, thereby creating a new account, albeit not under your control.