Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.
Related
Is there any way to get to know the a user is already logged in any other devices ?.
In Firebase Auth service.
Anyone please let me know is there any predefined provision in Firebase Auth.
UserMetaData has the last sign in time. You can also set auth state persistence to be either local, session, or none.
You could use these to approximate whether a given user could be authenticated elsewhere, but it doesn't seem like there's data on whether a user is definitely currently authenticated somewhere. For that you'd need to store login/logout data separately, such as in a a Firestore document for each user.
Note that the auth service doesn't typically know (or care) whether the user is actively using the app... it just issues each user an authentication token, which is used over some period of time to prove that they are who they say the are. The token can be invalidated/refreshed from time to time for security reasons (according to the persistence setting), but it's not an indication of whether they're "active". You don't mention your use case, but if you're trying to figure out whether users are on or offline (say for a chat application), you should look at Firebase's offline capabilities.
I am building an app, where I need to use my own backend besides Firebase. I need to authenticate a logged-in user in my backend too. So I found this tutorial which does this. I send an idToken and verify this header in admin sdk in my node, based on the docs. I thought I could cache this token with redis or just a js map after the first verification for 10 minutes or as much as a user session would take, to speed things up, instead of verifying each request in a 10 min sess. I could probably cache the token in the phone too for some time?
My question is, what security consequences would this bring? Thank you.
To clarify I am not using custom tokens, I will be using the built in Firebase Authentication.
The convention is to send the ID token to your backend with every request. It's not expensive to verify the token with the Admin SDK as shown in that documentation. It doesn't cost any money.
Typically what you're supposed to do is use a listener to detect when the ID token changes (it will be refreshed automatically every hour), and keep using that token until the SDK delivers a new one to your callback. In web clients, you're supposed to use onIdTokenChanged to register a callback to get changes to this token over time. There is no need to persist or cache this token - simply use whatever the callback most recently provided.
Some of the Firebase backend services keep a small cache of recent ID tokens, and their decoded results. So if they receive the exact same token, they'll use the already decoded result. This is a riskless operation, as the decoding operation is idempotent: the same input will always deliver the same output.
I've incorporated Firebase Cloud Messaging into my app. After messing around, I kind of understood the premise of how it operates. So, as a result, I structured my code so that when users sign up the FCM token is stored. After creating two accounts, I realise both FCM tokens for the user were the same.
Looked online and sorted this issue, and now I can refresh the token on launch, and still append the new FCM token when users initially sign up.
So now, I ask the question - Users are created with a fcmToken field (which I can refer to in my code), however, due to the fact a new token is generated on launch each time does this render the token(s) stored for each user useless? Or can I still push to the specific user using the fcmToken?
I've looked online, but can't seem to find an answer.
FCM tokens don't uniquely identify an individual end user. They identify a specific installation of an app on a specific device. When sending with that token, it doesn't matter who is signed in to the app (or if anyone is signed in at all) - the app will still receive it and need to figure out what to do with it. It's up to you to decide what to do with that message, given the sign-in state of the user. If you expect that your app could have multiple users sharing a single app on a single device, then you will probably want to send something in the payload to determine who that message was intended for, if necessary.
#doug great answer, but there's a common implementation problem when people share a device, so please add a warning, something like: often only the last logged in user should receive push notifications, otherwise he could see messages from the person who was logged in before. your backend should not only store all the devices a user is logged in, but also for each device who the last active user is and check this upon sending a push. the question whether you receive push or not when logged out is a common topic, too.
I am using firebase auth in a flutter app I am developing.
I am using the firebase_auth dart library.
Once the user is logged in, every request to my custom server backend contains the idToken, which I obtain by calling FirebaseUser.getIdToken(). What I recently just noticed is that the idToken is 900 characters long!! That seems excessively long. By just sending the firebase idToken on every request, I have increased my network data usage by 25x.
Is this normal? I have never used JWT before, so I don't know what to expect.
This is normal, and also not that big in modern terms.
There is no maximum size of a JWT. It's going to be dependent on what Firebase Auth puts in it, which comes from the authentication provided they used to sign in. The size will definitely vary from user to user, especially based on what you might put in custom claims.
Bit of context, I am trying to use Firebase for both authentication and data storage. Since my application deals with potentially sensitive data, the confidentiality features offered by Firebase (all Firebase communication is done via HTTPS according to their blog) seems like a great way to keep my data secured. In fact, the only problem I have with Firebase is that authentication last far longer than it should. As far as I can tell, it lasts through device resets, application rebuilds and loss of connection. Even worse, I have no idea how long it persists for. I've tried searching online but I can't find the information anywhere. As far as I can tell, it lasts around a day, but that's just a guess. I am using email and password as credentials for my sign in.
My question has two parts, does anyone know the default duration of Firebase authentication and does anyone know how to shorten it? Otherwise are there any other services that are similar to Firebase where you can set the authentication duration?
If I could shorten the duration to 4 hours Firebase would literally be perfect, other wise I might have to implement my own authentication, since authentication that last's for as long as Firebase is far too insecure.
Firebase Authentication (for 3.x or higher SDKs) uses two types of tokens:
A token that identifies the user. This token is created when the users signs in with the app and does not expire. To get rid of this token, sign out the user.
A token that allows the user to access the Firebase back-end. This token is based on the previous token, is valid for an hour, and is automatically created and refreshed by the Firebase SDKs.