I couldn't find information on this. I have an iOS app, written in swift. Firebase is my storage and database place. For now, I authenticate my users with email and password (no social media auth). My question is - is it possible after they've created their account to create many sub accounts? And if so, how do I track those (meaning, which is the primary account and how to switch between them - something like twitter and the way it allows to use multiple accounts and switch between them)?
My goal is to allow each user to have/create multiple accounts, make 1 account primary and the rest would be secondary accounts. Not sure if Firebase allows any of this though. I know this is broad description, but I want to make sure that this is indeed possible before I try to do anything like that. Any ideas?
Related
Is there a way to get all signed up users using FirebaseAuth. I know I can create users node and save users when they sign up, but I'm looking for a way to get users using something like Auth.getAllUsers since all I'm looking for is uid and displayName. I'm using swift, so admin sdk seems not supporting it.
There is no client-side API to get a list of all users, which is why many developers write details about the users into a database (such as the Firebase Realtime Database, or Cloud Firestore).
There is a server-side Admin SDK that allows listing all users. See https://firebase.google.com/docs/auth/admin/manage-users#list_all_users
You can create a cloud function that returns the results of the Admin SDK list all users function. Make sure that you remove any private data fields from the reply, though. The hashed password, salt, and providers are included in the data.
My goal is to prevent users of multiple login in. I do not want this to be client-side, with like the onDisconnect and onConnect values, but with a server check. I came across this answer:
How to prevent simultaneous logins of the same user with Firebase?
Which tells me to create a custom auth system. When I am following the docs (https://firebase.google.com/docs/auth/ios/custom-auth) I need to "Copy this file to your authentication server" (3c). How would I do this? I am just using Firebase and my little iOS app. I would like to manage everything on these 2 things, no server in between, is this possible? Or can this file only be uploaded through another server?
If above things are not possible, how can I server check if the user really signed in? I am using Cloud Functions, but I did not came across a trigger for a user signing in. Please no answers with onDisconnect/onConnect, I want it server side. A user may NOT login if he is already logged in. Thanks :)
Implementing custom authentication requires that you have a secure place to mint the custom token that identifies each of your users. You cannot do this securely with only client-side code, because that would mean everyone could claim to be whoever they want.
While you can use Cloud Functions for Firebase to implement a secure back-end without spinning up your own server, I highly recommend against doing that just for the purpose of preventing a user to sign in from multiple locations.
It's important when talking about security to split these two steps:
Authentication - a user proving to be who they are
Authorization - the authenticated user being able to use your app
There very seldom is a reason to keep a user from proving who they are. Your concern seems to fall onto keeping them from using the app from multiple locations. To do that, it's probably easier to track for each user where they are using the app from already using Firebase Database's presence system.
Also see:
How to handle multiple connections of the same user on Firebase?
Android - How to detect same user from multiple devices?
How to prevent same user logging in from different devices ? My app is paid , so I dont want credentials to be shared
I am currently uniquely identifying a user by storing the FacebookID of that user. I recently read around and I saw that this is incorrect usage and that Facebook ID's can change for some reason, all in all that I shouldn't use them. Is this true? If so, is a AWS Cognito ID that is derived when a new facebook user signs in and authenticates themselves a viable way to uniquely identify a user? If not, How would I uniquely link a facebook account, with apparently no variable that is stable enough to store, with a unique identifier to store in my database?
Check the following statement (from the official documentation: https://developers.facebook.com/docs/apps/upgrading):
No matter what version they originally used to sign up for your app, the ID will remain the same for people who have already logged into your app. This change is backwards-compatible for anyone who has logged into your app at any point in the past.
So, you can use the Facebook ID to uniquely identify your users.
However, depending on your use case and the way you plan to manage security, you should consider a few more things. The purpose of AWS Cognito ID is not to be communicated between users, it is kept between your app and Cognito. So if you want users to communicate using their accounts (sending text messages for example), the Facebook ID is more suited for that. Nevertheless, I am experiencing this problem when trying to achieve fine-grained access control using DynamoDB.
As Hatim said, the Cognito identity id is not meant to be shared between users.
That being said, once an identity id has a login associated to it, it could only change on merging with another authenticated id. Unless you're doing that, which it doesn't sound like you are, it would be a stable way to identify your users. You could use the identity id as the identifier in your database, as long as it isn't exposed.
If you're using DynamoDB, as this blog post explains, doing it this way allows you to configure your IAM roles to make access to this data more secure.
I am creating an app with multiple login options.
There will be a possibility to login via Facebook, Google+, and a manual login.
Its all good for now. But lets talk about the case where a user decided to logout from one account, and login using the other account. For instance, logging in via Facebook, logging out, then logging in via Google+.
This scenario causes the database to create multiple users in the database for only one user.
The only way I can think of solving this, is to find a link between all the different logins.
Options:
Email - The user can use different emails for the different apps, or might not have his email public through one of the social apis.
Phone Identifier - The user might let someone else use the app on his phone, or the user might have multiple devices.
Name - There will be many people with identical names.
Due to the above not being viable options, I wanted to see how other people have approached this concern.
I am not looking to use any 3rd party frameworks.
Thanks!
According to this question: Architecture for merging multiple accounts and registering a user account
Various answers have said that using email is a good way of establishing correspondence between different accounts and then doing automatic merging for multiple account sign in.
However, twitter is a major provider that does not provide email through their oauth API.
How can we reliably and automatically establish a correspondence between a twitter account and for example Google, Facebook, Github... etc accounts? So that we can auto-merge those accounts.
I'm writing a library to help in this, so it's not really useful to say do it manually, since I would like to provide options.
There is no secure-way to automatically do it, I implemented an application with local account/Twitter.Facebook/Google and I didn't have other choice.
I suggest you to allow your users to register with one method (local account, Twitter, Facebook, Google...) and create a page in "My account" that allow them to associate other accounts.
In Twitter a user can be identified by either a name or a key, you have no way to know them unless you explicitly ask them to the user.
Moreover now in Twitter 1.1 you have to redirect your user to Twitter to approve your application and then you get the OAuth token and security key. As you can see there must be an interaction with Twitter, at least if you need to perform some restricted queries on his behalf (e.g. create a Tweet).