This page provides background information on API keys and authentication: how each of these are used, the differences between them, and the scenarios where you should consider using API keys.
API keys are for projects, authentication is for users
Google Cloud Endpoints handles both API keys and authentication schemes (such as Firebase or Auth0). The main distinction between these two is:
API keys identify the calling project — the app or site — making the call to an API
Auth tokens identify a user — the person — that is using the app or site
API keys provide project authorization
To decide which scheme is most appropriate, it is important to understand what API keys and authentication can provide.
API keys provide
Project Identification — Identify the app or the project that's making a call to this API
Project Authorization — Check whether the calling app has been granted access to call the API and has enabled the API in their project
API keys are not as secure as auth tokens (see Security of API Keys), but they identify the app or project that's calling an API. They are generated on the project making the call, and their use can be restricted to a specific environment such as an IP address range, or a specific Android or iOS app.By identifying the calling project, API keys enable usage information to be associated with that project, and they allow the Extensible Service Proxy (ESP) to reject calls from projects that haven't been granted access or enabled the API.
Authentication of users
By contrast, authentication schemes typically serve two purposes
User Authentication — Securely verify that the calling user is who they claim to be
User Authorization — Check whether the user should have access to make this request
Authentication schemes provide a secure way of identifying the calling user. Cloud Endpoints also checks the auth token to verify that it has permission to call an API. Based on that authentication, the API server will decide on authorizing a request.
If you need the ability to identify the user making the call, see Authenticating Users.
While API keys identify the calling project, they do not identify the calling user. For instance, if you have created an app that is calling an API, an API key would identify the app that is making the call, but not the identity of the person who is using the app.
If you need a more secure way to limit which projects or services can call your API, see Authentication Between Services.
Security of API keys
API keys are generally not considered secure; they are typically accessible to clients, making it easy for someone to steal an API key. Once the key is stolen, it has no expiration, so it may be used indefinitely, unless the project owner revokes or regenerates the key. While the restrictions you can set on an API Key mitigate this, there are better approaches for authorization.
For examples, see Authenticating Users.
When to use API keys
An API may restrict some or all of its methods to require API keys. It makes sense to do this if:
You do want to block anonymous traffic. API keys identify an app's traffic for the API producer, in case the app developer needs to work with the API producer to debug an issue or show their app's usage.
You want to be able to control the number of calls made to your API.
You want to identify usage patterns in your API's traffic. You can see app usage in APIs & services.
You want to be able to filter logs by API key.
API keys cannot be used for:
Identifying individual users — API keys don't identify users, they identify projects.
Identifying the creators of a project.
Note also that Service Infrastructure does not provide a method to directly look up projects from API Keys.