This article mentions:
If your app includes a custom backend server, ID tokens can and should
be used to communicate securely with it. Instead of sending requests
with a user’s raw uid which can be easily spoofed by a malicious
client, send the user's ID token which can be verified via a Firebase
Admin SDK (or even a third-party JWT library if Firebase does not have
an Admin SDK in your language of choice). To facilitate this, the
modern client SDKs provide convenient methods for retrieving ID tokens
for the currently logged-in user. The Admin SDK ensures the ID token
is valid and returns the decoded token, which includes the uid of the
user it belongs to as well as any custom claims added to it.
From learning on Youtube, the raw uid always seems to be used.
Eg:
try {
final foo = FirebaseFirestore.instance
.collection("users")
.doc(FirebaseAuth.instance.currentUser!.uid)
.collection("...");
}
How do I convert this to use the getIdToken() or getIdTokenResult() instead of uid?
The UID of a user is a unique, constant identifier for that user. So if the same user logs in multiple times, they'll get the same UID.
It makes no sense to use the ID token as the identifier for the user in the database, as an ID token will change every hour.
You should continue to use the UID to identify the user, and only use the ID token when you need to verify the user's identity.
Related
Users who have certain user IDs can perform add and delete operations.
How can I log in and disable idToken to log out after adding or deleting, log out? Tokens have a 1-hour duration. People who are learning idToken can make additions and deletions. That's why it should be disabled.
I get idToken by requesting https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=[API_KEY].
With the Firebase Realtime Rest Api xxx.com/abc.json?auth= endpoint, you can have the authority to add and delete.
The REST API itself is stateless, so the only available information that someone is logged in is in your application that calls the REST API.
When you sign out in one of the Firebase SDKs they simply remove the ID token from the local state. I recommend you do the same: remove the ID token from memory effectively signs the user out.
Firebase only passes the ID token over encrypted connections, so is not susceptible to man-in-the-middle attacks (like the one you describe) unless your network is already compromised.
There is no way to revoke the ID token itself once it's minted, but if you want to revoke access for a specific ID token or user, have a look at https://firebase.google.com/docs/auth/admin/manage-sessions
background of this question
I'm using firebase auth for user authentication on my app.
I realized that firebase doesn't have a log of user information changes, so I can't answer user questions about it.
So, I'm planning to move the feature of changing user account info (like email, display name, and password) from using the client-side firebase auth library to using server-side firebase auth SDK for the purpose of taking logs of these changes to use for user support. Also, I'd like to make logout a user who changes account info.
I've looked for the appropriate API on the document firebase.google.com/go/v4/auth and found UpdateUser function. The struct UserToUpdate which is a parameter of UpdateUser can set a new email address, new password and new display name, but I can't find to set the parameter to make a user logout.
my question
Is there a way to log out a specific user by firebase auth go SDK?
Firebase Authentication's client-side sign-in is based on ID tokens, which are valid until their built-in expiration (by default: an hour after they are minted). Since no server keeps a list of all the ID tokens it has minted, there is no way to mark a token as invalid on such a list either.
The common approach to revoke access for a user is to:
Revoke the refresh token, so that they can no longer mint new ID tokens with it.
Add the ID token(s) of the user to a self-managed list of revoked ID tokens.
Detect the presence of an ID token in this list from your server-side code and security rules.
Optionally detect the refresh token revocation on the client
Instead of logging the user out, you can also force-refresh their ID token/profile on the client to get the latest information from the server.
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 users will use FirebaseAuth to get their id token, then send this to the server, where it’s authenticated with verifyIdToken. Currently, I’m using the uid property of the result as a key in my db. To make things more efficient, I would like to hash the id token, and use that as a key in my db instead. For this to work, getIdToken must always return the same thing for any given user. Can I rely on this to be true?
To clarify, the user will still be authenticated with verifyIdToken at first. But once they’re in the db, I will just use a query on the db to authenticate them instead.
ID tokens expire after one hour (for security reasons) and are refreshed automatically by the Firebase client SDK. If you want to pass an ID token to your backend, you should only pass a fresh token, otherwise it will not validate on your backend when you go to verify it. I suggest reading that linked documentation to get more details, including how to use a listener to get the token immediately when it's refreshed.
Is firebase token is use to sent to specific device?
How do I store firebase token in MySQL?
From google website, It does not mention about the length of the token.
It seems to be very long.
An Instance ID Token identifies a specific app on a specific device. From the Firebase documentation:
Registration token - An ID generated by the FCM SDK for each client app instance.
The Instance ID Token indeed only expires in very few conditions. Also from the documentation:
The registration token may change when:
The app deletes Instance ID
The app is restored on a new device
The user uninstalls/reinstall the app
The user clears app data.
The token is a relatively long string. Since you're unlikely to frequently search for it, I'd store in in a text field in your database.