Authenticating using a service account from a different GCP project causes createCustomToken to sign the wrong project.

[MattGson]

[REQUIRED] Step 2: Describe your environment

• Operating System version: GKE node:10-alpine image
• Firebase SDK version: 8.2.0
• Firebase Product: Firestore
• Node.js version: 10
• NPM version: 6.9.0

[REQUIRED] Step 3: Describe the problem

I have a Google Cloud Platform project that needs to sign custom tokens from GKE compute instances via the node-admin SDK for multiple firebase projects (I need multiple Firestores).

One Firebase project is owned by the GCP project, the other is not (Limit of 1:1 set by Google). I have given the GCP project access to both Firebase projects by adding the compute engine default service account to the IAM section for the external Firebase project. I have given it the Firebase Editor and Service Account Token Creator roles.

I initialise the connection for either Firestore using:

app = admin.initializeApp({
        databaseURL: `https://${config.databaseURL}`,
        projectId: config.projectId,
    });

As you can see, I don't pass any account credentials as I use the compute engine default service account. I switch Firebase instances by passing the databaseURL and projectId.

When I sign a token using app.auth().createCustomToken this works fine for both firebase instances.

The issue is when the client tries to authenticate to the Firestore using the custom token. It works for the Firestore that is part of the same project as the service account. For the other Firestore it fails with mismatch error 400.

The interesting thing is that the token signed for the external firebase project (that doesn't work) does work if I then point the frontend to the other firebase project.

This implies that either initializeApp is ignoring the databaseURL and projectId or app.auth().createCustomToken is.

Explained simply:

Using compute default service account from Project A always signs token for Project A even if initializeApp() is configured with Project B.

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[hiranya911]

Custom tokens are signed using the "credentials". Database URL and project ID have nothing to do with it (they are not even referenced by the createCustomToken() API). In your case the SDK is using application default credentials of project A, so the tokens you get are only valid for project A. This is working as intended.

You generally need to do a lot of additional configuration to make your scenario work.

Option 1: Upload service accounts JSON files for all your projects along with your code. Initialize multiple Firebase App instances -- one for each JSON file, and then use them to create tokens for different projects.

Option 2: Initialize multiple Firebase App instances, each with a different serviceAccountId option. These service account IDs should come your target projects. You should also make sure they have the "Service Account Token Creator" IAM role on project A. Then you can use the different App instances to create tokens scoped to each project.

[MattGson]

The application default credentials on GKE should be using the default compute service account according to this. This service account has been given permissions to sign tokens for both Firebase projects so I would expect this to work.

re Option 1: I was trying to avoid using service account JSON files as all my other access to google services is done using ADC which saves a lot of configuration hassle.

re Option2: At the momentI am trying to use the same service account to access two Firebase projects. Are you suggesting that I work the other way and add a service account from Project B to Project A?

[MattGson]

Just tested option 2 and it seems to work as expected. Thanks for the help.

[hiranya911]

This service account has been given permissions to sign tokens for both Firebase projects so I would expect this to work.

A service account can only sign tokens for one and only one project. Any token signed by service account Foo is only valid within the parent project of Foo.

re Option2: At the momentI am trying to use the same service account to access two Firebase projects. Are you suggesting that I work the other way and add a service account from Project B to Project A?

You need to specify a serviceAccountId that belong to your project B. Then you have to ensure that the default compute service account of project A has the "Service Account Token Creator" role on that serviceAccountId. I would expect something like the following to work:

$ gcloud projects add-iam-policy-binding Project-B \
     --member serviceAccount:Project-A@Default-GKE-Service-Account \
     --role roles/iam.serviceAccountTokenCreator

[alapeta]

Hi, I have similar setup and I am trying to follow option2 but still without success.

I am initializing my projects in dev by setting GOOGLE_APPLICATION_CREDENTIALS ENV variable which points to service account key from my Project A. This key is from firebase-adminsdk-***@projectA.iam.gserviceaccount.com.

To admin.initializeApp I only pass projectId and serviceAccountId of my project B - again this serviceAccountId is firbase-adminsdk-... . I am not passing credential so it is taken form ENV.

Is still receive token mismatch error (I believe that I set all permissions in the right way).

Is this possible that this is not working because of dev environment and not google managed production ?

[hiranya911]

Is this possible that this is not working because of dev environment and not google managed production ?

Possibly. When running locally the SDK uses the local private key to sign tokens, so all your tokens are actually signed by the Project A service account.

[alapeta]

ok, thanks
I have just made a try with production environment on Run Cloud and it works.

But how to test it during development locally. Any ideas?

[alapeta]

Currently the only idea I have is to choose option1 in dev and option2 in production...

[hiranya911]

I haven't tested this, but you can try using refresh token based application default credentials when testing locally. Install the gcloud CLI and authenticate with it, and then initialize the Admin SDK without setting the GOOGLE_APPLICATION_CREDENTIALS environment variable. The SDK should use refresh token credentials, and since there are no service accounts in the picture, it should contact IAM to remotely sign the token as it would in the prod environment.

Note that there are other known issues with Auth APIs when using local refresh token credentials. So if your application makes other API calls like admin.auth().getUser(), this might not work.

Otherwise option 1 listed above is the only immediate solution I can think of. In the future we can look into making a change in the SDK so that token signing works the same way both in prod and local environments.

[ericbuehl]

@hiranya911

A service account can only sign tokens for one and only one project. Any token signed by service account Foo is only valid within the parent project of Foo.

Is this documented anywhere? It isn't clear to me how/why this limitation exists