missing `kid` in `createCustomToken` token header

[Bamieh]

[REQUIRED] Step 2: Describe your environment

• Library version: "firebase-admin": "5.4.3"
• Firebase Product: auth (auth, database, storage, etc)

[REQUIRED] Step 3: Describe the problem

The createCustomToken function does not add kid to the header of the jwt token. This makes me unable to use the token in many applications (i have to sign in with the username and password using firebase rather than firebase-admin)a

[google-oss-bot]

Hmmm this issue does not seem to follow the issue template. Make sure you provide all the required information.

[Bamieh]

@firebase-oss-bot hmmmmm 🤔

[bojeil-google]

How do you use a custom token to "sign in with the username and password using firebase rather than firebase-admin"?

[hiranya911]

@Bamieh The only meaningful thing you can do with a custom token is to pass it to one of the signInWithCustomToken() methods provided by the client SDKs. This will send the token to a Firebase auth backend server, which does not care if the kid header exists. For this reason it is not required.

How are you using custom tokens? What service/application is complaining about the kid header not being present?

[Bamieh]

Our backend uses firebase-php which calls the method \JWT::decode to verify firebase user tokens, this method (provided by firebase) checks for the KID.

My intent was to create a user via admin auth, then create a token for that uid, and send it to the backend to access the services.

I started using the admin auth in the first place because the web auth forces a limit of a 100 user creations per IP per day and i sometimes exceed this quota (I'm heavily automating e2e testing for our platform).

Currently i solved this issue by creating the user via admin auth, then sign in via the firebase web package as a web user to get the backend verifiable token. I didnt see anyway to adjust the token headers.

[hiranya911]

It sounds like you're doing the right thing now: using the custom token in a client SDK to sign in, and obtain an ID token. The ID token can be verified in the server side.

Verifying custom tokens in user code is not a supported use case, as they are meant to be verified by the Firebase auth backend servers only.

[Bamieh]

@hiranya911 I understand. Can you clarify what exactly you mean by "Firebase auth backend servers only"? Our backend uses firebase auth, doesnt that make it qualified consuming custom tokens?

[bojeil-google]

The custom Auth token is only meant to be consumed by the Firebase Auth backend server. The public certificate for a project is not exposed as a result.
So the flow works as follows:

1. Mint custom token with your private key
2. send custom token to Firebase Auth backend via signInWithCustomToken API.
3. Auth backend verifies it with your allocated cert.
4. A Firebase Auth refresh token and ID token are sent back to the client.
5. You can verify the ID token using the public cert which is shared by all projects. Admin SDK provides an API for that.

What should be of interest to you is the final ID token which was obtained from the original custom token.

[peicodes]

Verifying custom tokens in user code is not a supported use case, as they are meant to be verified by the Firebase auth backend servers only.

According to your docs, verifying with a third party library is a supported use case. The kid is still missing from the headers though.

https://firebase.google.com/docs/auth/admin/verify-id-tokens#verify_id_tokens_using_a_third-party_jwt_library

[hiranya911]

The doc link you're referring to is about verifying "ID tokens", and not "custom tokens". That's a different use case. ID tokens indeed contain a kid header. Custom tokens do not.

[peicodes]

@hiranya911 Thank you for your quick response. I've been stuck on this issue for a while, do you mind giving me some suggestions?

We are trying to use the same custom token to authenticate with firebase + our backend. The token is generated using Functions, which uses the App Engine Default Service Account. The token creation itself works fine, and we are able to validate the token in our backend using the corresponding public key found at https://www.googleapis.com/robot/v1/metadata/x509/<PROJECT_ID>@appspot.gserviceaccount.com.

The issue is, the private key used to sign the token is managed by Firebase, and seems to be automatically rotated every few days. The solution I am trying to implement is to have our backend fetch and cache the correct public key based on the kid claim.

We are also considering having Functions sign the token with another private/public key or service account that we specify - is that a viable solution?

Here is a short snippet of how we are generating the token Functions-side:

  const firebaseToken = await admin.auth().createCustomToken(user.id, claims);
  return { token: firebaseToken };

[hiranya911]

Like @bojeil-google has mentioned in a previous comment, those public keys are not exposed by Firebase. So there's really no way to verify a custom token in your own code. You can find some alternative solutions at https://stackoverflow.com/questions/61767695/how-to-verify-a-custom-token

[peicodes]

We are able to retrieve the public keys for signed custom tokens here: https://www.googleapis.com/robot/v1/metadata/x509/<PROJECT_ID>@appspot.gserviceaccount.com. We just have no idea which one is being used by Firebase to sign it. Through trial and error, we are able to eventually find the one that can verify the custom tokens on our server side. If only we had the kid in the custom token, we would be able to verify it in our own code, by picking the right public key.

Do you know of any way for a Function to know the key ID being used when calling createCustomToken? Like an environment variable? If I include the kid as a custom claim, then I am able to retrieve it on the other side.

For example, using the link I provided, I am able to see all the public keys for my app engine default service account, including the internal ones used to sign custom tokens on functions (attached as a file): public_keys.txt

If this doesn't work, we can follow the suggested solution in your link. The issue is that it requires additional requests before we can have an ID token to auth with our backend, and we are trying to minimize that.