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.
Related
I'm trying to use Firebase as an authorization method for a paid Shopify website theme. The idea is the store owner purchases and downloads the theme files, and after purchasing also creates a firebase account with an email and password. Then an API key for the theme will be emailed to them. Once they have the API key they will input their account email and API key into the settings within the theme files. To authenticate the user the theme files will have some javascript that checks if the username and password inputted correspond to a existing user in the firebase database. If the email and API key inputted does not match to any user in the database then the user will be redirected to an error message HTML file, or get an error message popup that they cannot close saying to input the correct key.
Another possibility is to use the firebase firestore unique user ID instead of generating user API keys. Maybe this way there would be no need for using the firestore database.
Either way, this logic seems ok if it was a single user. But since it is a website theme file it is possible that every users website will get thousands of customer visits per day. Thus every customer that visits the clients site will trigger an authentication check with firebase with the clients email and API. So every user account on Firebase could potentially have thousands or maybe even hundred of thousands of logins and database queries everyday (depending on how popular their website is). So this is the part Im worried about.
Anyone have similar experience using Firebase for website theme authentication? Perhaps I am going about it all wrong here. Or maybe Firebase is just the wrong tool for this job.
Appreciate any input!
What is the difference between using Google OAuth and signing in users at the frontend of the application, and signing in users at the backend side of the application?
Example: Signing in users and getting the ID and a auth object in React or letting Node/Express handle everything, the prosess, redirecting and store it in a database.
Is there any advantages for one or the other methods, which are most common and are there any "rules"?
What is the difference between using Google OAuth and signing in users
at the frontend of the application, and signing in users at the
backend side of the application?
So to clarify to everyone reading this, signing in users at the backend side of the application is another way of saying OAuth for servers and signing in users at the frontend of the application is OAuth for JavaScript browser applications such as React.
Signing in users via OAuth for servers and browsers results in a 'token' that a server/browser can use to make requests on behalf of the user. We are asking the user to provide us access to their information via an outside service provider such as an email address, identification of some sort and it will be inside that token as well as some possible permissions that allow us to take actions on behalf of that user.
Is there any advantages for one or the other methods, which are most
common and are there any "rules"?
Server-side OAuth is usually used when we have an app that needs to access user data when they are not logged in. So if you are attempting to build an application that needs to access the users email every ten minutes and possibly delete emails on the users' behalf, you would want to be able to access their email account every 10 minutes regardless of whether they are logged into our application. So for this use case we want to make use of Oauth for server.
Otherwise, if we are not trying to do anything on behalf of the user except sign them into our app, then we can just go with OAuth for browser.
Those two things are very different. Without knowing the specifics of what you're trying to accomplish, you should know as a general rule that front-end-only authentication and authorization leaves you extremely vulnerable.
If someone knows JavaScript well, or is using editing plugins, or any of a million different things, they can bypass much front-end authorization. Or they could just watch to see what calls your app makes to the back end, then simulate those calls from something like Postman, bypassing your web front end entirely.
If you're not securing your backend, you're not secure. Typically systems do both.
It is just a different ways of registering users to our website.
Signing in users at the frontend using OAuth can be very handy as it enables our users to not go through our boring forms in our website. Using OAuth is just one click away from registering users in our website. Beneficial to both the clients and developer.We are provided with the general information about clients by the provider(google,facebook) just clicking on one button.
Signing in users at the backend side is the traditional way of registering our clients. Here we force our client to fill the forms in our website(which may be painfull if it is a long form) and all the filled data is stored in our database.
So they are both different ways to register clients to our websites. Both are used very often. It depends on usecase and needs. Oauth can be used if you want to attract more clients by registering them just by one click.
We have a web app that caters to a small set of users that are guaranteed to have an account on Office 365.
To save them from remembering one more password, and to use Microsoft's infrastructure for OAuth, we decided to allow them to login using their Outlook credentials.
It is a react app, we are using the msal library and we have successfully been able to receive the accessToken from Microsoft. (Thus, authenticating the user's identity.)
What I am not confused about now is what I should do with that token:
I need to have my own User database. What information should I store in it? Should I store the access_token as well?
How do I verify the user's identity on my backend server?
Basically, what is the ideal way of managing this kind of a scenario? Wherein a third party authenticator is used (and solely) used to confirm the identity of the user and get the name, profile image and other things only.
Any references to existing workflows or an explanation of the steps involved will be highly appreciated.
I'm using Parse.com, and like it a lot.
I'd like users of my app to automatically be assigned an account (which I create behind the scenes using the Parse API) and then log them into their account.
I could easily do this if I assigned them a hard coded, standard password for their account, e.g superPass123.
Is this the only way I can do this? Or is there some other way to allow me to login automatically as a user without knowing a users password, if my user has "super" rights?
If you secure it enough, you can essentially do this by using Cloud Code. I'll skip over the validation/authorization part, and focus on how.
A cloud function, which, running with the Master Key, can query for a user. The cloud function returns the users session token to the client (user.getSessionToken()), which uses the "become" functionality to log in as that user.
Relevant posts:
Announcing the "become" feature: http://blog.parse.com/2013/12/03/bring-your-own-login/
Tutorial that covers an implementation of cloud code providing a session token: https://parse.com/tutorials/adding-third-party-authentication-to-your-web-app
I have developed a multi-page Javascript web application. My clients have asked me to provide a login page. They do not need anything fancy and requested a single username and password that they can share with those who need access to certain featured within the application. They want anybody to be able to see the application, but only authenticated users can use certain tools within the application.
I currently use an ASP.net proxy page (.ashx file) for handling requests to and from a 3rd party server storing the data consumed in my application.
I've never created a login system and have no idea where to begin. I don't think I need a database for login information because there will only be one username and password.
How could I go about securely storing the username and password to authenticate with the user-submitted login information and enabling parts of the application based on whether a user is authenticated or not?
The good news are that you don't need to build the login system, Microsoft did it for you. This is called the Membership System. All you need to do is expose this API to your end users.
And it's a bad idea to have a single credential for everybody. It is better to assign unique credentials to each user.