I am using Google Firebase Authentication to handle user management for my web application.
Specifically, I am using managed session cookies. The problem I am running into is figuring out how to associate each session with a corresponding user.
For example, I would have two separate tables:
User - Stores personal information such as name, email, password, etc
Account - Stores account related information such as posts, friends, etc
I was thinking of using Redis as a key-value store for this situation and the flow would work something along the lines of this:
User enters credentials
Credentials gets verified by Google's backend
User receives ID token
User sends ID token to my backend along with user id
Google's backend creates a session cookie
Backend would store the session along with the user id into Redis
Whenever user hits a protected endpoint that requires user id, a call to Redis would be made
I thought this might work because, within my Flask API, if I print out the type of the session cookie, the value is of type string.
I was wondering if this is an overkill, or if there is a better alternative to achieve what I want.
After much research and discussions with peers who work in the software industry, I have decided to use the strategy outlined in the question.
Feel free to comment if you have anything else to add.
Cheers.
Related
I'm quite new to firebase and I am looking for best practices using it, maybe I will be able to get some advices here.
What I want to do:
User login using firebase.
Problem:
I save user info in firebase but use SQL server as database where I need that user information as userId
Question: How should I approach that?
Register user on firebase and when I get response with userId and token, save it to my sql database too?
what's my current approach:
At this stage we're thinking of creating new users via admin panel (and then these users can sign in)
Would it be good approach to add user to sql database, send email to finish registration (create pasword) and then add this user to firebase, and with response send request to my backend where I update user that he's verified, add userId and token?
It's very common to store additional information about Firebase Authentication users in your own database. Whether it's good in your use-case is subjective, but it's definitely common.
Assuming that you have a server interacting with SQL server on the user's behalf, be sure to pass the ID token from the client to the server, decode it there, and then use the UID (and other claims) from that token in your database interactions. Don't allow the user to just pass their UID, as that'd be a security risk.
For more on this scenario, see the Firebase documentation on verifying a user through their ID token.
Your approach with an admin panel is a common first approach, but not something I'd recommend. Since you'll need to allow the user's to sign in with email/password, there is nothing keeping them from calling the createUserWithEmailAndPassword API themselves on your project. So I'd recommend leaving the creation completely to the clients, and save yourself from having to consider that an abuse scenario.
If you want to control what users an access the data, store a list of email addresses (since you seem to associate that with uniquely identifying a user already) in the database, and check the email address in the ID token is in the list (and is marked as verified in the token).
My application have to fetch data from external services with the usage of manually provided at profile/management by user api key & api secret.
I'd like to prevent a huge amount of retriving those necessary keys queries to database and persist it somewhere else (assuming that those keys won't be updated too frequently).
From my point of view it could be implemented with next options:
Use MemoryCache provider with SlidingExpiration;
Create a custom Claim and append it into existing Identity claims collection;
Please correct me if I'm wrong, but if I've realized it right - claim's information is a part of data, which is used for serialization/deserialization at frontend<->backend interaction (I'm not quite confident about it, but suppose that it's used within cookies & tokens).
Actually these keys are also required for a several background processes (message queue consumers or scheduled jobs for example).
Would you mind letting me know a proper way for persiting such protected and frequently used fields in an optimized way?
Thank you in advance.
When you login using one of SignInManager's sign-in methods, it sets a cookie on the browser with an access token in it. This cookie contains claims data. So in subsequent authorized requests, you can query the User.Claims field to access the required fields without making a trip to your datastore.
Now whether you choose to use claims or not totally depends on how often you need the API Key / Secret. Your claims are part of the access token. If sending the API key / Secret on every request is justified, claims is the ideal choice.
UPDATE:
Rather than decrypting the tokens at the frontend, it's better to send them to the frontend client along with the access token.
Incase you're not aware of IdentityServer4 or OpenIddict do check them out. It's probably got all that you need.
I am currently building one web application, and I consider to use Firebase auth and its database. My concern is that if user id is on browser, does it make any security issue?
For example, say that my user id is 12345, and I would like to show some information about user 12345 on a certain page. In order to move to the certain page that I can see user's information, I click some element (like a button), and go to the page. (Ex: https://localhost:9876 => https://localhost:9876/12345) In this case, the user id is visible, but I am not sure if this is reliable approach.
Thanks.
EDIT: I just noticed that security rules should be used thanks to Eric's comment. However, I am not 100% sure if the rule can be used for auth object too. For example, auth object is used to get user id, but using user id, is it possible for someone to obtain the user's email address which is stored in auth object? For instance, in the above example, someone might obtain user 12345's email address using user id, 12345.
The correct way to secure user related resources is via a Firebase ID token. Database/Storage rules already rely on this mechanism. You cannot just rely on the correct user ID being provided. That provides no security. Instead, before return restricted resources, you should check verify the ID token and trust only its content which includes the UID. FYI: the Firebase Admin SDKs already provide an API to verify an ID token.
Typically the way to pass the ID token (if you are not using real-time database), is as follows:
Single page app: you can call getIdToken() and then pass the latest ID token in the URL query parameter, post body or the header as you send an XHR request to your server.
Traditional website: you have to set a session cookie. The easiest way is to set the ID token as session cookie and keep updating it on expiration. On your backend, you will verify this before returning the user specific resource.
If a user logs into my Firebase store with Google authentication, the client gets access to all sorts of useful user-specific information, like the user's name and email. I might want to put this information in the store, and the client can certainly send it along in a write request. But as far as I know, there's no way to validate (on the server side) that this information is correct. There is nothing stopping someone from using a second client to send fictitious metadata.
(For instance, take a look at the skeletal auth variable which is accessible from security rules. It doesn't contain the information I need for validation.)
How do people deal with this kind of situation?
Only limited information about the user is available in the auth variable in security rules.
To access more information, you'll have to store that information in the database when the user is created or signs in. Most developers add a /users node to their database for this reason.
You can then look the extra information up in your security rules with something like root.child('users').child(auth.uid)...
The process is covered in the Firebase documentation section on Storing User Data.
I am building a multi tenant MVC4 web application. I distinguish the tenant based on the url alias (customername.webapp.net). I have a database that stores the customer id which I can lookup using the customername.
Obviously I need this customer identification during the entire session that a user from that customer is using my webapp.
Is it acceptable to store this unique identifier in the session? Or are there better design choices for this kind of "session data"?
I'd rather store this information inside the UserData portion of the forms authentication cookie (if you are using Forms Authenticatoin) or simply add it as a claim if you are using claims based authentication. When the user logs-in you would extract the tenant name from the current request, query your database in order to obtain the tenant id and then persist this id. If you store the id in the UserData portion of the Forms Authentication cookie you could write a custom [Authorize] attribute which will read the FormsAuthenticationTicket, decrypt it, get the tenant id from the UserData portion and then build a custom principal. This way you will have it available everywhere in your application. If you use claims based authentication, you would simply add it as a new claim.
I wouldn't use Session at all inside my application.
Please don't be misguided by the answer. It is dangerous to use cookie.
Session in this case would be the valid option, not cookies. If you store your tenantId inside your cookie, and your application establishes database connection based on your cookie, then after you login as a user, you can tamper and change the cookie and now your application will make connection to another database thereby compromising security. Even if your cookie is encrypted, it's not 100% reliable.
Session in this case would be the reliable server information that keeps track of which tenant database should be connected to. Although session can be a performance drop compared to cookie, in this case you have no other good options. You are designing a multitenancy application and that's just something you have to sacrifice.
Yes, you may still able to use cookie if you REALLY want to. You just have to keep checking if the user is connected to the right database somehow, which to me is more of a performance drop than using session.
Don't hate session just because alot of people abuse it or hate it. You just have to use it in the right manner.
Bottom line is, if you are using any info for security purposes, don't use cookie.