Using special URLs and headers

This page describes how to use Cloud Identity-Aware Proxy (Cloud IAP) special URLs and headers to enhance your application UI or provide troubleshooting options.

Special URLs

Passing user identity

The following URL returns a JSON dictionary with the user's identity:

YOUR_APP_URL/_gcp_iap/identity

This URL is available from any signed-in Google account, even if the account doesn't have access to the app. You can navigate to the URL directly or you can reference it to make requests to the URL. Following is an example value returned by the URL:

{"email":"accounts.google.com:USER_EMAIL","sub":"accounts.google.com:118133858486581853996"}

You might find this value useful to personalize your app, such as by displaying the user's name, to pass identity to another page, or capture usage data in logs.

Clearing user login

The following URL clears the Cloud IAP login cookie:

YOUR_APP_URL/_gcp_iap/clear_login_cookie

By default, this URL is linked from the 403 page to help users who might be signed in to the wrong place. You can also provide the URL to a user who gets stuck, or use it to enable profile switching in your application.

Refreshing user sessions

Cloud IAP sessions are valid for one hour. When a session expires, by default AJAX requests return an HTTP 401: Unauthorized response code. This is because of HTTPS Cross-Origin Resource Sharing (CORS) restrictions in the Google OAuth server.

You can use the URLs below to avoid Cloud IAP session timeouts in your AJAX applications:

URL Function
/_gcp_iap/do_session_refresh Force re-authentication and redirect to /_gcp_iap/session_refresher.
/_gcp_iap/session_refresher Serves a page that refreshes to /_gcp_iap/do_session_refresh after 45 minutes.

For more information about how to implement these special URLs for your AJAX applications, see Managing Cloud IAP sessions.

Testing JWT verification

Cloud IAP helps you test your JWT verification logic by passing invalid JWTs to testing webpages.

For example, Cloud IAP passes a JWT with an invalid signiture for any request to a webpage that ends with /_gcp_iap/secure_token_test/SIGNATURE. Your verification logic should catch the invalid signiture.

Create a webpage for each of the following scenarios you want to test for under DOMAIN/FILE_PATH/_gcp_iap/secure_token_test/TEST_TYPE.

URL Test case
/_gcp_iap/secure_token_test/NOT_SET A valid JWT.
/_gcp_iap/secure_token_test/FUTURE_ISSUE Issue date is set in the future.
/_gcp_iap/secure_token_test/PAST_EXPIRATION Expiration date is set in the past.
/_gcp_iap/secure_token_test/ISSUER Incorrect issuer.
/_gcp_iap/secure_token_test/AUDIENCE Incorrect audience.
/_gcp_iap/secure_token_test/SIGNATURE Signed using an incorrect signer.

Special headers

Detecting responses from Cloud IAP

When Cloud IAP generates an HTTP response, such as when it denies access (403) or requests authentication (302 or 401), it adds the X-Goog-IAP-Generated-Response HTTP response header. By detecting the presence of this header, you can perform actions like:

  • Distinguish between error messages generated by Cloud IAP and error messages generated by your application.

  • Detect when Cloud IAP credentials need to be added to a request.

Was this page helpful? Let us know how we did:

Send feedback about...

Identity-Aware Proxy Documentation