I am starting to learn about JWT and I was wondering if some one got a hold of both my id token and refresh token, could that someone access firestore or other firebase resources pretending to be me indefinitely(until the refresh token is revoked)?
If so, how does firebase prevent this from happening?
I can't help feeling that the if someone could get my id token, it's not that hard to access the refresh token as well.
All communication with Firebase APIs are over HTTPS, which means that no one can listen in on that communication. It is secure. If someone got both a fresh ID token and a refresh token, then could impersonate you when making calls to Firebase APIs.
However, no one can get your ID token or refresh token unless you make a security mistake. For example, leaving your computer unlocked while you're signed in would be a bad idea. Or, having a password that's easy to guess. Use all the standard security precautions, and you won't have a problem.
Related
I am considering to use firebase authentication for a new service.
As I understand it, when the user is authenticated, firebase generates an id token that can be verified on the server with one of the certificates published on https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com.
If the verification is successful, I can trust the uid
But, I need to be able to prove how I obtained that session (and why it was trusted) at a later time, and I don't know how to do it
I could save the generated id token and the certificate that it was used, then show that the signature is valid (even if the token is expired). But the firebase certificates are self signed, so there is no way that I can prove that I didn't fake the whole process
This could be solved if there was a history or log of the expired certificates, but I could not find it
Is there a log of the certificates that I didn't see? Is it possible to do this in some other way?
Any help would be greatly appreciated
In my application I have used aws cognito with next auth for user auth.
In the jwt callback that I have from api next-auth I receive an access token, which is then saved and sent to the client side. There, I save it in local storage and, among other things, I send it to my api which checks if it is correct.
The problem is that after an hour the access token expires and does not get a new one (always next-auth gives me old value). Has anyone had a similar flow and knows how to manage a session refresh? I will add that I am not automatically logged out because next-auth is managing it underneath, but it does not return the value of the new access token to me.
Do you have any ways how to manage this?
I can suggest a workaround that would take the least effort to solve this quickly. Amazon Cognito contains 3 kinds of tokens, the ID Token, Access Token and Refresh Token.
From the Amazon Cognito console, you can increase the validity of the token you're dealing with from there. A good idea is to refer to this answer.
Albeit you might need a couple of methods to assert security and robustness.
I can not find how should handle the auth part correctly. Basically, my backend returns me a token, and with this token, I call auth().signInWithCustomToken(token). All works fine my users have access to chat and other things. Also, on signout I call auth.signout(). But the problem is if the user does not use the app for some time and when coming to the app with refresh token if it is valid we generate new accessToken. But how to handle firebase part in this flow because user can not access chat, etc because it seems firebase token is not valid anymore. Any idea how to handle refresh token or flow in this case?
Once you've signed out with signout(), refreshing a token won't help at all. The user is fully and completely signed out. If you want to sign back in, you will need another new token to sign in with signInWithCustomToken(). Once the user is signed in, the Firebase SDK will automatically refresh a token to keep that sign-in alive for a long as needed. There is nothing you need to do for that.
I was recently having an argument with another programmer mate of mine regarding storing Firebase Auth UID (just the uid nothing else) in a cookie with sameSite: 'strict' enabled.
What's the argument about
Currently, I am working in a Nuxt JS project where I am saving the user's uid on onAuthStateChange() event in a cookie with sameSite: 'strict' enabled so that I can grab it in my serverMiddleware code and do stuff with it.
I have checked this firebase doc about managing cookie and it shows how to store the JWT idToken in a cookie and then in the server decode it.
In fact, that is who I initially coded my work. But due to some requirements, it was super helpful if I store the uid instead. So, I did that. Then I started reading about how can I hack my own data to see if anyone can harm my data from the uid in the cookie.
Then I stumbled upon to this firebase doc: Use the Cloud Firestore REST API which shows how to get the firestore data using REST API and I figured out that you need to provide Google OAuth 2.0 token in the header of the API call in order for it to work, otherwise even if you put the correct URL with all the collection name and everything (which is hard for an outsider to know, but lets assume he knows), you will get nothing but this:
{
"error": {
"code": 403,
"message": "Missing or insufficient permissions.",
"status": "PERMISSION_DENIED"
}
}
I have also tried to run code in browser console in order to hack the data out of my project. But That didn't work as well.
Now in order to get the Google OAuth 2.0 token, the person must need login access to my account which is not that easy as I have a unique long password along with 2 Step Authentication with phone OTP & push notification. Besides if anyone has login access to my Google account, he can easily go to console.firebase.com and see the data, so at that point, nothing will matter.
But I did say that if anyone is using firebase Realtime database then I will not recommend storing the uid in a cookie as the realtime database provides easy REST API without any authentication layer to fetch data. At that time I would recommend using JWT idToken instead.
So, what's the final question?
The final question is this:
If someone is using firebase auth & firebase cloud firestore (not realtime database) using firebase SDK in his project, is it secure to store just the uid in cookie instead of storing JWT idToken if it will reduce the code complexity and code execution time over using idToken?
I would love to know your thoughts on these as there are many super experienced devs beside two programmers arguing.
My friend keeps telling me that storing uid in the cookie is not sure, but when I asked him why exactly, he had no concrete answer. As what is secure and what is not a universal thing and changes as you change your tools. But in this exact context what do you guys think? I know that normally in most cases it is not a secure thing, but I am asking about this specific context only.
It is in fact fairly common to expose the UID of a user to other user to identify that user. See Firebase - Is auth.uid a shared secret?
There is nothing insecure about storing the UID in a cookie, nor in reading that cookie in your middleware. But if your middleware then assumes that the UID is the authenticated user, you have a security risk.
What is keeping any other user from putting your or my UID into that cookie, and thus getting access to your or my data?
Also note that UIDs don't change over time, so if ever one (even inadvertently) leaks, you could impersonate that user forever.
ID tokens on the other hand have a limited lifespan (currently about an hour), which limits the risk if they accidentally get exposed.
I'm using OAuth 2.0 to log in users in my website. Just like any kind of website, e.g. Google, Asana, etc. .
What I would like to know is if there is a way to revoke ONLY the access token and not the refresh token when the user logs out.
This is what I do:
when a user logs in, I create a session and obtain the access token (and the refresh token if the user logs in for the first time). When the user logs out, I just invalidate the session but the access token is still valid.
Sure, the access token will invalidate after a while or when the user logs in the web app again but what I want to know is if the access token can be invalidated during the log out process.
There's no generic answer to this question as the implementation of token revocation behavior wrt. related tokens is Authorization Server specific. Google will invalidate the refresh token together with the access token that is being revoked, other implementations may choose not to do so. Yet other implementations may not even offer a way to revoke access tokens at all.
For Google you can revoke the access token upon logout as described in https://developers.google.com/accounts/docs/OAuth2WebServer#tokenrevoke but it will also revoke the associated refresh token. You must then go through the authorization code flow again to get a new refresh token, which you could try with prompt=none to avoid the user being prompted.