App Identity API for legacy bundled services

Region ID

The REGION_ID is an abbreviated code that Google assigns based on the region you select when you create your app. The code does not correspond to a country or province, even though some region IDs may appear similar to commonly used country and province codes. For apps created after February 2020, REGION_ID.r is included in App Engine URLs. For existing apps created before this date, the region ID is optional in the URL.

Learn more about region IDs.

OK

Go Java PHP Python

The App Identity API lets an application discover its application ID (also called the project ID). Using the ID, an App Engine application can assert its identity to other App Engine Apps, Google APIs, and third-party applications and services. The application ID can also be used to generate a URL or email address, or to make a run-time decision.

This API is supported for first-generation runtimes and can be used when upgrading to corresponding second-generation runtimes. If you are updating to the App Engine runtime, refer to the Upgrade to second-generation runtimes page to learn about your migration options for legacy bundled services.

Getting the project ID

The project ID can be found using the

Getting the application hostname

By default, App Engine apps are served from URLs in the form https://PROJECT_ID.REGION_ID.r.appspot.com, where the project ID is part of the hostname. If an app is served from a custom domain, it may be necessary to retrieve the entire hostname component. You can do this using the

Asserting identity to other App Engine apps

If you want to determine the identity of the App Engine app that is making a request to your App Engine app, you can use the request header X-Appengine-Inbound-Appid. This header is added to the request by the URLFetch service and is not user modifiable, so it safely indicates the requesting application's project ID, if present.

Requirements:

• Only calls made to your app's appspot.com domain will contain the X-Appengine-Inbound-Appid header. Calls to custom domains do not contain the header.

In your application handler, you can check the incoming ID by reading the X-Appengine-Inbound-Appid header and comparing it to a list of IDs allowed to make requests.

Asserting identity to Google APIs

Google APIs use the OAuth 2.0 protocol for authentication and authorization. The App Identity API can create OAuth tokens that can be used to assert that the source of a request is the application itself. The returns an access token for a scope, or list of scopes. This token can then be set in the HTTP headers of a call to identify the calling application.

Note: The Google API Client Libraries can also manage much of this for you automatically.

Note that the application's identity is represented by the service account name, which is typically [e-mail]. You can get the exact value by using the . For services which offer ACLs, you can grant the application access by granting this account access.

Asserting identity to third-party services

The token generated by only works against Google services. However you can use the underlying signing technology to assert the identity of your application to other services. The will sign bytes using a private key unique to your application, and the will return certificates which can be used to validate the signature.

Note: The certificates may be rotated from time to time, and the method may return multiple certificates. Only certificates that are currently valid are returned; if you store signed messages you will need additional key management in order to verify signatures later.

Getting the default Cloud Storage Bucket name

Each application can have one default Cloud Storage bucket, which includes 5GB of free storage and a free quota for I/O operations.

To get the name of the default bucket, you can use the App Identity API. Call .