Sync multiple email accounts at the same time - ios

We have an app that allows us to signup using one email id and can add/ link another email id. When we enter the home page after signup, it should show the teams/challenges created using the first email id on the top and the teams created using the second email id on the bottom. We are thinking of using firebase for backend. Is it possible to have two email ids active at the same time?

No. You must go outside BaaS, particularly Firebase, as you have mentioned. You can consider making your own backend server for that feature.
What Firebase can provide you is the ability to have a single email address connected to different sign-in methods.
ref: https://support.google.com/firebase/answer/9134820?hl=en&ref_topic=6386702

If you're using Firebase Authentication to sign in users, then no, it's not possible to have two accounts signed in to a single device at a time. If you sign in a second account, then the first one will be automatically signed out.
If you want to "link" two accounts in such a way that they can query each others' data, you're going to have to establish that relationship in your database or custom claims, and use that in security rules to allow shared access to data.

Related

FusionAuth - Invite based user on-boarding with social logins

We create users with their email address. We send email to each user with a link to change password api with changePasswordId. When user clicks the link, he will be redirected to change password screen where he can set the password and access the application. This works.
But, now we want to allow users to register with their social Idps upon receiving invitation/verification email. Can't see any fusionauth documentation on this part.
Questions are as follows
How to let user select their social Idp while verifying their email?
Can a user have multiple logins with different Idps for one application in FusionAuth?
Is there any linking api which links all external user accounts with their fusionauth user account?
The flow we are expecting is :
Invite User -> User clicks link -> User will be presented with set
password and social logins-> User chooses google -> Google
authenticates user and returns token back to fusion auth -> fusion
auth links user's google account with already created (invited) user
account. -> Next time user logs in with google account -> Fusion auth
identifies the user and allows him to access the application.
Updated :
Let me try to explain our situation and need, with less focus on the password setup task:
We need to set up new users that are associated with google based education accounts on custom school domains. Teachers and students that might have addresses like first.last#middle.school.com We need to take the class roster from Google Classroom, initialize accounts for each student in our backend via our API which also creates FusionAuth user and app registrations for each.
Schools don't often want kids setting passwords on vendor sites. When we send the account confirmation / verification email to the new cohort of students they would ideally be directed to the approved and configured method for that domain (perhaps Google, Microsoft, other SAML or password). If we can't get selective about the confirmation method shown after the student provides her invited email address then we could present multiple confirmation options on the same screen and let the teacher direct the students to the correct choice.
But in summary we need to avoid requiring password setup and support confirmation with the invited social account when required by the school.
If I understand your use case correctly, what you want is to add the "Login with Google buttons" to the Setup Password workflow. This is different than the Email Verification workflow, so if you are looking for a way to log users in with their social profiles during Email Verification, that's something completely different. In fact, I don't think that is a use case because after the user verifies their email, they need to log in again and they can do that using their social profile.
Unfortunately, FusionAuth doesn't fully support the ability to allow someone to use the Setup Password workflow using a social login. It might be possible though using the Email Templates and Theme editor in FusionAuth. I haven't tested this, but you could try it and see if it works.
What you would do is to pass in a URL parameter to show the social login buttons during the Setup Password workflow. This would be something you could do in the email template for Setup Password like this:
Click this link to setup your password:
<a href="https://example.com/password/change/${changePasswordId}?showSocial=true">
Setup Password
</a>
Then, using the Theme editor in FusionAuth, you would add some code in to show the buttons like this (the ?? part is to handle when the parameter is missing):
[#if showSocial?? && showSocial]
show social buttons here
[/#if]
You could give that a try and see if it works for your use case. If it doesn't work, you can always open a feature request for this on our GitHub issue tracker and we can see if it receives enough upvotes to get on the roadmap. You can also engage FusionAuth professional services to build this feature for you as well.
For your other questions, you can have as many logins with external IdPs as you want for a single user. The user is unique by their email address.
I'm not sure what you mean by "linking api", but if a user logs in with an external IdP, their tokens from those external providers are stored on the user object. You can look up those values and then call third-party APIs with their access_tokens.
UPDATE 8/27/2019
Ah yes. The social login buttons do require all of the OAuth parameters, so this solution won't work because those parameters aren't part of the Setup Password workflow.
I guess I'm confused on how this actually works and whether or not this is a workflow FusionAuth should be handling. Social logins aren't generally used for account verification. They are normally used for account creation. For example, you could just send the student to FusionAuth before their account is created, they login with their Google classroom account, and then they have a FusionAuth account. Is there any reason the student can just login in after their account is created? Is that not essentially the same thing?
Could you do something where students that have accounts in Google Classroom are created in FusionAuth with a randomly generated 32 character password (for security) since they will be logging in with Google regardless. You can then just send them an email with a standard login link.
For students that login in with a username and password to FusionAuth directly, send them a Setup Password email. This will let them pick their own password.
In terms of account Linking, FusionAuth links accounts automatically based on email address (the unique login identifier actually). Therefore, you don't need to call any extra API to associate the social login with a user.
I might still not be clearly understanding the use case, so feel free to contact us directly using the form on our website. We might need to setup a web conference to discuss your needs in detail.

How do I restrict user sign ups to only certain domains in Firebase?

I have an iOS app that I'd like to restrict access to, making it only available to users from a specific email domain.
The app requires the users to log in using their Google Account.
I've found various answers online that suggested adding
".read": "auth.token.email.endsWith('gmail.com')"
But that doesn't seem to return an error in the sign in page, but only when the user in question tries to access the database. Any suggestions?
You will have to enforce that. You have multiple tools to do so:
After signInWithCredential resolves, you can check the domain and that it is a google.com provider. If you are allowing email/password users, you need to verify those too. If the user doesn't meet your criteria, use the delete API on the user and issue an error to the user that they need to sign in with a certain account.
Enforce the check in your rules, as you can't always trust the client. Ensure that if a user signs up, and isn't deleted, he/she can't access the data.
Use Firebase functions which has a trigger for user creation. On user creation, check your criteria is met, if not, use the firebase-admin module to delete that user.
If you are using the Google sign-in library for iOS to get the Google credential, you can check the Google user email and Google ID token before you signInWithCredential in Firebase and block the sign in attempt.
Write your own clean up script: If you are hosting your own server and do not want to use Firebase Functions, you can run a daily script that downloads all your users using the Firebase CLI SDK and then deletes all users using firebase-admin SDK that do no match your criteria.
Since the required email domain is #gmail.com, you could just disable the email and password and enable the Google sign in method in your Firebase console. So, the only way a user can sign in on your app is with a Google account.
https://firebase.google.com/docs/auth/ios/google-signin
Include the email and password sign up option and just check for domains within your app. This will be a simple string comparison test on the email address.
Or just spin up a server to which you'll be sending the emails to for verification. This way you wouldn't have to push out new updates every time you add an extra domain. You can try and see if cloud functions would be helpful instead of spinning up a new server.

Identity 2.0 Linking Multiple Login Providers

I have finally managed to implement Facebook as an external login provider on my MVC website which seems to be working fine, but I am wondering what is the correct / secure way to allow multiple external login provides to be linked to a single account.
Lets say I login with my facebook ID, no existing account is found with the same email address and my website persists a new account with their email address and their facebook token etc associated.
Next day I login with my Google account, If i check my database for an account which already has a matching email address what should I do?
1) Link this Google account with the existing account automatically and
log them in?
2) Ask the user if they wish to link their google account to the
already existing account we found?
3) Something else?
Thank You.
It is really up to you. But the default provided in the VS2013 template assumes a one to many relationship between your internal user and any external logins. If you retrieve a user with UserManager, you will see a IList for each external provider the user has logged in with.
As they log in with the new provider, you would normally not automatically know the user is associated with another provider's login. When you login it looks up a user via external ProviderKey, so initally would not find any relation to an internal user. At that point you could search users by name, email (with customized user store) and so on to link as needed.
Assuming primary emails registered on facebook and google for example, are verified by them (which they usually are) I don't see any issues on linking them together.
I think the main problem is linking internal account with email that was not verified to be from specific user. If i create an account with email of other user and that email is not verified, when the other user creates an account it associates the data of the first user together and that way both users are using the same account.
Can anyone identify and explain potential flaws for my first claim please?

iOS + Rails: Login with Facebook best practice

I'm building an iOS app with a Rails backend. The user can log into the iOS app with Facebook.
What is the best way to associate this with a User record on the backend?
My thinking is to get the Facebook UID, check if a record exists with that ID in the Users table and if not create an account by storing the UID and Facebook email. Is this the correct way this should be done?
I haven't written a system like this before so I want to make sure I'm not going about it completely the wrong way.
Thanks
it looks like you might want to check out parse.com as a backend service
But either way what you suggested is pretty much how they are implementing it and they were acquired by Facebook so I believe they do it right:
add a column called 'fuid' to store the Facebook ID and check if such an entry exists before adding a new user entry to the User table
I think this railscast will be a good way to start from. For the database of app you can create an authentication table where you can store the type of authentication(in case you change your mind and want to sign up users from twitter or somewhere else), uid and the access token. You will also need a users table where you can store all the information related to a user. Not to forget a user will have many authentications or one authentication depending on your need.
As for the flow of app you can go two ways:
a. You get the users approval from the facebook, store access token, uid and get users email, first name or whatever information you need and then store it all in the back end and then sign up him/her.
b. Get the approval from user, store uid and access token and then render a form which will be filled with the user's information like first name,last name etc. User will create a password for your app and then you can sign up him/her.

How to implement 'User' functionality in an app?

This is probably a repeat. However, the other answers haven't helped me out. So, here goes.
I'm working on an application and we with need to add 'users' to it. We'll be giving the option for people to sign in with Facebook, Twitter and LinkedIn. I've worked with these APIs before, however never combined them globally.
How can I maintain and manage these users that will use different services to log in. I'm confused as to how they would be stored in a database, would I need to have a different table for each different social service or is there a way to implement a table that will house all users in one place.
From what I understand, you're asking how to manage, store, verify users that will be logging in your application through different social services.
This is how we've implemented it through the various projects we've worked with. From the list of services you've provided we've worked only with twitter and facebook, so I can only speak about that.
Setup:
We have a web service that our iOS app communicates with such as when the iOS app needs to make a request call for user login the server would take the user details trying to login and gives back a response where the app would then do whats necessary.
We have a database stored on the server with a users table which is used to verify a user.
That being said, you need to understand whats common between most social services, or to at least know what the property is that is used by these social services to uniquely identify its users. In this case they all use email to identify users.
You'll find that when interfacing your app with these different APIs, they like to use a login session key used for unique logged in sessions.
So on your database you would store whatever details you want to save of the user, but know that you need to store atleast the username, password (encrypted), email (for identification, unique column), and login_session_key.
Just double check that linkedIn does have something like a session key that it creates when a user logs in with that method. Facebook and twitter do. Send at least the 4 main data properties needed (username, password, email, session) to the server You then follow this sort of approach:
New user
If the user that is new tries to login, the server first checks the email provided even exists in the database, if it does not then you sent a response back alerting the user that the user does not exist; your app would then take them to the register screen for example.
If the user is in the registry page, save all the details you want to store of theirs including username, password and email.
Members
If the user logs in the email will exist on the server side, its an existing user so just update the session key that was sent from the app on log in if the password matches, (in some apps these session keys are used through the life cycle of the application being used, with each request sending the same session key and if at any point the session key does not match during app interaction, it can be concluded that the user has logged elsewhere on another device perhaps.
if the password does not matches return the appropriate message.
That's about it really. We're able to store all facebook and twitter users in one table.

Resources