I'm considering to use Firebase to perform identity verification. I am new to JWT, so my apologies if this is an obvious question, but I don't understand how the verification is actually done. It seems that FirebaseAuth.getInstance().verifyIdToken(idToken) works asynchronously, as the result is obtained via a listener. I understand that some certificates are used as described here, and that those certificates are rotated regularly. Does it mean that networking is required between my back-end server and Firebase server's each time I will call verifyIdToken()? Isn't it a problem ?
In order to verify Firebase ID tokens, the Firebase Auth public certs need to be retrieved (network request) and these are rotated on a regular basis. These are needed to ensure the Id token has not been tampered with. The JWT is first parsed, the algorithm to encrypt the token is checked to see if it matches the expected one, the signature is then verified using the public key obtained, finally the JWT claims are validated ensuring the token has not expired.
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
I am trying to implement an authentication/authorization system using firebase and I am struggling with the last part of the authorization flow, which is, enabling my server to verify the validity of a token.
There are two ways to perform this:
Validate the token using the Admin SDK of firebase, where essentially a server communicates with Firebase and validates a token (safe option)
Validate the token using a third-party JWT library.
My question has to do with option (2), which according to documentation is perfectly feasible. The question is, how is this safe? Everything included in the token-validation process is public according to this:
Finally, ensure that the ID token was signed by the private key corresponding to the token's kid claim. Grab the public key from https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com and use a JWT library to verify the signature. Use
If the token is public, and the key for validating it is public, who guarantees that the token is genuine?
Probably there is something related to JWTs that I am missing?
PS. I have already implemented option (1) with remote validation, but this will significantly affect the application performance.
You can verify validity of a token with the public key, but you can only create tokens with the private key.
As their names imply:
Your private key should only be used in trusted environments, such as your development machine, a server you control, or Cloud Functions. So those are the only places where you can generate auth tokens.
The public key however can be shared with others, which means that they can use it to ensure that the token is valid.
I am using firebase mobile otp authentication. After successful authentication my android app receives a token which I have to verify on my django server. But while I was reading the docs of verifying this token, it comes out that if someone knows my firebase project-id, they can generate valid tokens anytime they want.
To get contec, look at the last method to verify firebase token at link
Isn't this quite risky, as once your firebase project id is known to someone, they can create fake tokens??
Also does custom authentication token help overcome this problem?
Thanks. Let me know if I have incorrectly understood the firebase token validation and it is not possible to create fake tokens once we know the firebase project-id.
ID tokens are signed by a private key owned by Firebase Auth. They cannot be forged. Note that the doc you've referenced also states:
Finally, ensure that the ID token was signed by the private key corresponding to the token's kid claim. Grab the public key from https://www.googleapis.com/robot/v1/metadata/x509/securetoken#system.gserviceaccount.com and use a JWT library to verify the signature.
A forged ID token will not pass the signature check.
Okay so in my iOS app I log the user into firebase, then get the jwt token. So now I have my server with an api which accepts an idtoken in the header of the GET.
What do I do here? Certainly I wouldn't be validating the JWT againt firebase on every single API call right? I mean its fast, but that adds latency with a second external check, no? How does one simply just decode that guy in C#? I have an Auth0 layer already and that decodes the JWT with my server-stored secret, but that same code doesn't work for the Firebase token.
Could it just be decoded then extract the user details from that, maybe just check expiry and if expiry > X months it's still okay?
In order to verify Firebase ID tokens and JWTs in general, you only make a network call on your server to get the public certs which are usually not updated for several hours. You could cache that and try to verify with an ID token and if it fails, only then, load the new public certs.
And yes, you must verify the ID token on each call especially since Firebase ID tokens expire after typically an hour and need to be refreshed continuously.
I'm implementing my own OAuth authentication system (with refresh_token support) for an app and I have some questions about how to do it:
Client identification: The client is registered in the auth server and gets a client_id and a client_secret. How do I generate it? is there some kind of relation between both values?.
User authentication: The client sends the users_credentials (username+password for example) + client_id and gets a refresh_token and (temp?)access_token. That access_token is the one I should use in further request or I should use a accesss_token`=F(refresh_token,access_token,client_secret). In the second case what does the F function consist on?
Access token refresh: The client send client_id, refresh_token and gets a access_token (and a optional new refresh_token). Does the access_token need the same conversion (whatever it be), as in the point 2?
If I'm wrong, when and how is the client_secret used?
Complete answers and concrete examples will be "bountied".
The authorisation/authentication server generates these values when you create an account with them (for instance when you create a developer account with Facebook or Google). If you are doing these parts yourself, they should be cryptographically secure pseudo-random numbers or letters. Remember that the client ID is usually publically visible, so choose a reasonably large set of alpha-numerics (I use 30 characters). The secret is private and can be harder to guess so I chose 30 digits with letters, numbers and symbols. These are not related to each other, it is just that one is public and the other isn't.
The usual way this works is that there is a browser redirect to the auth server passing the client id in the URL (and redirect uri) and specifically NOT the user id and password. The whole point of OAuth2 is that the client system never sees the user name and password, only the auth server. After this redirect, the auth server verifies the client id, checks the username/password (for instance) and then returns to the redirect uri with a temporary code. This temporary code is passed back to the Auth server in order to obtain an access token. Since this call is made as a POST from the server, it also passes the client secret to verify that it really is the correct client system and not someone who stole the client id from somewhere else. At this point, the auth server will return an access token (and optional refresh token - you do not need to use them, I don't).
If the client system wants to log the user in without them having to type in their username and password all the time, it can use a refresh token, if available, to call back onto the Auth server and if the Auth server is happy that the refresh token is still valid and any other business rules are correct, it can give you back another access token directly without the user being involved.
I recommend reading the OAuth2 spec here: OAuth2 Spec RFC6749. It can take a while but if you delete the bits you don't need and reduce the amount of data, there are plenty of useful examples in it.
FIRSTLY, The client identifier can be any string that you want, but it should be unique for each client. It can even be the client's choice if you wish.
The client secret should be a cryptographically strong random string. Here is how you could generate one in C#:
RandomNumberGenerator cryptoRandomDataGenerator = new RNGCryptoServiceProvider();
byte[] buffer = new byte[length];
cryptoRandomDataGenerator.GetBytes(buffer);
string uniq = Convert.ToBase64String(buffer);
return uniq;
SECONDLY, The whole point of OAuth is to allow external apps to do things on your behalf without asking for your credentials. So, you need to implement an authentication server that does the logging in part for you. The user opens the app and gets an option to Log in using your website. You tend out access tokens and refresh tokens once the user has keyed in his credentials. The app can then simply use the tokens to perform actions on the user's behalf. I wrote an answer to How would an efficient OAuth2.0 server / provider work? that explains how access tokens can be constructed.
Remember, the need for refresh tokens and the lifetime of access tokens purely depends on how you intend to use them and what does your security framework look like.
LASTLY, The refresh token can also be an HMAC encoded string/a JSON object as I had explained in the answer to the linked question. You can have random refresh tokens and a large backend storage to keep it to verify the tokens in the incoming requests, or have HMAC encoded strings for added security/less storage requirements/latency to decrypt/encrypt tokens.
Also, do make sure that you go through all the flows and possibly the RFC too as mentioned by Lukos.