How does Firebase select CLIENT_ID and API_KEY for GoogleService-Info.plist

[Rui Silvestre]

Hi,

I'm trying to understand how the CLIENT_ID and API_KEY values are selected from the available ones listed on the Credentials page in GCP, when we download the GoogleService-Info file.

For reference, when we create a new app in the Firebase Console:

- it creates a new OAuth 2.0 Client ID to GCP — "auto created by Google Service"

- it creates a new unrestricted API key — "auto created by Firebase"

When we download the config file, a CLIENT_ID and API_KEY are selected, what is the logic behind that?

From my tests, CLIENT_ID is retrieved from the most recent one that matches the app bundle ID and appstore ID.

I tried to prove this by creating a new Oauth2.0 Client ID with the same bundle ID and appstore ID for the app I then downloaded the config file for, and the newly created Client ID appeared as the value for the config API_KEY, even though there was another identical Client ID in GCP, but just older in date.

For the API_KEY I'm completely at lost, but at config file creation time a decision has to be made on what value to select for API_KEY. 

I tried creating a new API key in GCP that is restricted on bundle ID for the app I want to download the config for, but that config always comes back with an already existing API Key — where is that link defined?

I know if I delete, from the GCP Console, the API Key that currently appears on the config file, the new one I created will be picked up, so there is some logic to pick the best match (worst case it creates a new one and picks that). 

There seems to be no way to override how the GoogleService file chooses the keys it uses, other than downloading it and then replacing inside the file whatever client id and api key we need. But that kind of defeats the purpose of having the ease of use of just downloading the file.

I couldn't find any docs on this, and nothing on the GCP or Firebase Console that allows defining it.

Any ideas?

Thanks

Rui

[Nick]

Hi Rui,

CLIENT_ID is based on the app's platform and package name / bundle ID, and is meant to be treated as an opaque token (it should not be parsed).

For API_KEY, once an API key has been associated with a Firebase app, that association will not change unless the API key is deleted or has constraints added to it (eg. package name / bundle ID) that make the key no longer "match" the app. If it no longer matches, Firebase will attempt to find a different API key in the project that matches, and associate it with that one. If no existing API key matches the app, Firebase will provision a new API key for the app.

Best,

-Nick

[Rui Silvestre]

Hi Nick,

thanks for replying and confirming some of my research.

I ended up regenerating all client ids and api keys in GCP, naming them in a way so that their purpose is clear (opposite to Firebase default naming), and replacing the new values under my project config files.

The fact that there is no way to change that association explicitly is unfortunate and makes downloading the Firebase config file a potentially dangerous thing that will break your app. This is particularly worse if you use other Google APIs and want to segregate access to them via Api Keys. Point in case, since the client id / api key association is arbitrary when they are not yet linked, when I got the config it picked up another key I had for the same app bundle but restricted to the Vision API, which wouldn't allow Firebase to initalize properly.

To be honest, I don't even know what systems under the Firebase SDK actually use that API_KEY, it seems analytics / remote config calls do, but it's all very opaque and undocumented.

Every API_KEY should be independent by service/api that needs to be called, but that seems to be the case only sometimes. I guess it depends on what API means in each context and how the backends are structured.

I have a quick followup question regarding this API_KEY.

Why are the automatically provisioned api keys created from Firebase not app restricted, even when that value is known from the app configuration on Firebase? Is that by design / 'needed' for API_KEY to work correctly? Isn't this restriction best practice?

Cheers

[Nick]

Hi Rui,

> I ended up regenerating all client ids and api keys in GCP, naming them in a way so that their purpose is clear (opposite to Firebase default naming), and replacing the new values under my project config files.

Out of curiosity, what did you end up naming your new API keys?

> The fact that there is no way to change that association explicitly is unfortunate and makes downloading the Firebase config file a potentially dangerous thing that will break your app.

API keys will continue working for your app as long as there aren't constraints added to them that would prevent them from matching your app. The "association" just defines which of the matching API keys on your project will consistently show up in your app's downloaded Firebase config. As such, downloading the config should never be a dangerous operation (please let me know if I've misunderstood your concern).

> This is particularly worse if you use other Google APIs and want to segregate access to them via Api Keys.

You can add restrictions to API keys based on the package name / bundle ID / web URL of the app, which should support this use case. Unless you're saying you'd like to use two different Cloud/Firebase API keys in the same app on the same platform, since I don't think that's a recommended practice.

> Point in case, since the client id / api key association is arbitrary when they are not yet linked, when I got the config it picked up another key I had for the same app bundle but restricted to the Vision API, which wouldn't allow Firebase to initalize properly.

That's a good point - It would be better if, when associating an app with a new API key, Firebase avoided picking keys that have API restrictions already set on them.

> I have a quick followup question regarding this API_KEY.

> Why are the automatically provisioned api keys created from Firebase not app restricted, even when that value is known from the app configuration on Firebase? Is that by design / 'needed' for API_KEY to work correctly? Isn't this restriction best practice?

Restricting APIs keys to a package name / bundle ID / web URL is a best practice. I think that, in the early days of Firebase, there was a technical constraint preventing the keys from being provisioned with restrictions like that. Now that it's something that's possible, Firebase just hasn't implemented it as the default yet.