This document describes how to authenticate to an IAP-secured resource from a user account or a service account.
Programmatic access is the scenario where you call IAP protected applications from non-browser clients. This includes command line tools, service-to-service calls, and mobile applications. Depending on your use case, you might want to authenticate to IAP using user credentials or service credentials.
A user account belongs to an individual user. You authenticate a user account when your application requires access to IAP-secured resources on a user's behalf. For more information, see User accounts.
Caution: Only Google Identities are supported for user account programmatic access in IAP. Identity Platform and Workforce Identity Federation identities are not supported for programmatic access.A service account represents an application instead of an individual user. You authenticate a service account when you want to allow an application to access your IAP-secured resources. For more information, see Service accounts.
IAP supports the following type of credentials for programmatic access:
Pass these credentials to IAP in the Authorization
or Proxy-Authorization
HTTP header.
Before you begin, you'll need an IAP-secured application to which you want to programmatically connect using a developer account, service account, or mobile app credentials.
Warning: If you've configured your application to use the Google-managed OAuth 2.0 client, programmatic access is blocked by default. You need to allowlist an OAuth 2.0 client that the callers will use to generate credentials. Authenticate a user accountYou can enable user access to your app from a desktop or mobile app to allow a program to interact with an IAP-secured resource.
Authenticate from a mobile apprequestIdToken
client ID to the client ID for the resource you're connecting to.Authorization: Bearer
header to make the authenticated request to the IAP-secured resource.This section describes how to authenticate a user account from a desktop command line.
Each developer who wants to access an IAP-secured app will need to sign in first. You can package the process into a script, such as by using gcloud CLI. The following example uses curl to sign in and generate a token that can be used to access the application:
Start a local server that can echo the incoming requests.
# Example using Netcat (http://netcat.sourceforge.net/)
nc -k -l 4444
Go to the following URI, where DESKTOP_CLIENT_ID
is the Desktop app client ID:
https://accounts.google.com/o/oauth2/v2/auth?client_id=DESKTOP_CLIENT_ID&response_type=code&scope=openid%20email&access_type=offline&redirect_uri=http://localhost:4444&cred_ref=true
In the local server output, look for the request parameters:
GET /?code=CODE&scope=email%20openid%20https://www.googleapis.com/auth/userinfo.email&hd=google.com&prompt=consent HTTP/1.1
Copy the CODE value to replace AUTH_CODE
in the following command, along with the Desktop app client ID and secret:
curl --verbose \
--data client_id=DESKTOP_CLIENT_ID \
--data client_secret=DESKTOP_CLIENT_SECRET \
--data code=CODE \
--data redirect_uri=http://localhost:4444 \
--data grant_type=authorization_code \
https://oauth2.googleapis.com/token
This command returns a JSON object with an id_token
field that you can use to access the application.
To access the app, use the id_token
:
curl --verbose --header 'Authorization: Bearer ID_TOKEN' URL
Refresh token
You can use the refresh token generated during the sign-in flow to get new ID tokens. This is useful when the original ID token expires. Each ID token is valid for about one hour, during which time you can make multiple requests to a specific app.
The following example uses curl to use the refresh token to get a new ID token. In this example, REFRESH_TOKEN
is the token from the sign-in flow. DESKTOP_CLIENT_ID
and DESKTOP_CLIENT_SECRET
are the same as used in the sign-in flow:
curl --verbose \
--data client_id=DESKTOP_CLIENT_ID \
--data client_secret=DESKTOP_CLIENT_SECRET \
--data refresh_token=REFRESH_TOKEN \
--data grant_type=refresh_token \
https://oauth2.googleapis.com/token
This command returns a JSON object with a new id_token
field that you can use to access the app.
You can use a service account JWT or an OpenID Connect (OIDC) token to authenticate a service account with an IAP-secured resource. The following table outlines some of the differences between the different authentication tokens and their features.
Authentication features Service account JWT OpenID Connect token Context-aware access support OAuth 2.0 Client ID requirement Token scope URL of IAP-secured resource OAuth 2.0 client ID Note: Service accounts don't support device policy attributes with context-aware access. Authenticate with a service account JWTIAP supports service account JWT authentication for Google identities, Identity Platform, and Workforce Identity Federation configured applications.
Authenticate a service account using a JWT comprises the following main steps:
Grant the calling service account the Service Account Token Creator role (roles/iam.serviceAccountTokenCreator
).
The role gives principals permission to create short-lived credentials, like JWTs.
Create a JWT for the IAP-secured resource.
Sign the JWT using the service account private key.
The created JWT should have a payload similar to the following example:
{
"iss": SERVICE_ACCOUNT_EMAIL_ADDRESS,
"sub": SERVICE_ACCOUNT_EMAIL_ADDRESS,
"aud": TARGET_URL,
"iat": IAT,
"exp": EXP,
}
For the iss
and sub
fields, specify the service account's email address. This is found in the client_email
field of the service account JSON file, or passed in. Typical format: service-account@PROJECT_ID.iam.gserviceaccount.com
For the aud
field, specify the URL of the IAP-secured resource.
For the iat
field, specify the current Unix epoch time, and for the exp
field, specify a time within 3600 seconds later. This defines when the JWT expires.
https://example.com
. A JWT with the audience of https://example.com/path1
is invalid for accessing https://example.com/path2
, or any subdomains like https://sub.example.com
. Sign the JWT
You can use one of the following methods to sign the JWT:
Use the IAM Service Account Credentials API to sign a service account JWT. The method fetches the private key associated with your service account and uses it to sign the JWT payload. This allows the signing of a JWT without direct access to a private key.
To authenticate to IAP, set up application default credentials. For more information, see Set up authentication for a local development environment.
gcloudcat > claim.json << EOM
{
"iss": "SERVICE_ACCOUNT_EMAIL_ADDRESS",
"sub": "SERVICE_ACCOUNT_EMAIL_ADDRESS",
"aud": "TARGET_URL",
"iat": $(date +%s),
"exp": $((`date +%s` + 3600))
}
EOM
claim.json
:gcloud iam service-accounts sign-jwt --iam-account="SERVICE_ACCOUNT_EMAIL_ADDRESS" claim.json output.jwt
After a successful request, output.jwt
contains a signed JWT that you can use to access your IAP-secured resource.
import datetime
import json
import google.auth
from google.cloud import iam_credentials_v1
def generate_jwt_payload(service_account_email: str, resource_url: str) -> str:
"""Generates JWT payload for service account.
Creates a properly formatted JWT payload with standard claims (iss, sub, aud,
iat, exp) needed for IAP authentication.
Args:
service_account_email (str): Specifies service account JWT is created for.
resource_url (str): Specifies scope of the JWT, the URL that the JWT will
be allowed to access.
Returns:
str: JSON string containing the JWT payload with properly formatted claims.
"""
# Create current time and expiration time (1 hour later) in UTC
iat = datetime.datetime.now(tz=datetime.timezone.utc)
exp = iat + datetime.timedelta(seconds=3600)
# Convert datetime objects to numeric timestamps (seconds since epoch)
# as required by JWT standard (RFC 7519)
payload = {
"iss": service_account_email,
"sub": service_account_email,
"aud": resource_url,
"iat": int(iat.timestamp()),
"exp": int(exp.timestamp()),
}
return json.dumps(payload)
def sign_jwt(target_sa: str, resource_url: str) -> str:
"""Signs JWT payload using ADC and IAM credentials API.
Uses Google Cloud's IAM Credentials API to sign a JWT. This requires the
caller to have iap.webServiceVersions.accessViaIap permission on the target
service account.
Args:
target_sa (str): Service Account JWT is being created for.
iap.webServiceVersions.accessViaIap permission is required.
resource_url (str): Audience of the JWT, and scope of the JWT token.
This is the url of the IAP protected application.
Returns:
str: A signed JWT that can be used to access IAP protected apps.
Use in Authorization header as: 'Bearer <signed_jwt>'
"""
# Get default credentials from environment or application credentials
source_credentials, project_id = google.auth.default()
# Initialize IAM credentials client with source credentials
iam_client = iam_credentials_v1.IAMCredentialsClient(credentials=source_credentials)
# Generate the service account resource name
# If project_id is None, use '-' as placeholder as per API requirements
project = project_id if project_id else "-"
name = iam_client.service_account_path(project, target_sa)
# Create and sign the JWT payload
payload = generate_jwt_payload(target_sa, resource_url)
# Sign the JWT using the IAM credentials API
response = iam_client.sign_jwt(name=name, payload=payload)
return response.signed_jwt
curl
Run the following command to prepare a request with the JWT payload:
cat << EOF > request.json
{
"payload": JWT_PAYLOAD
}
EOF
Sign the JWT using the IAM
Service Account Credentials API:
curl -X POST \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
-H "Content-Type: application/json; charset=utf-8" \
-d @request.json \
"https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/SERVICE_ACCOUNT_EMAIL_ADDRESS:signJwt"
After a successful request, a signed JWT is returned in the response.
Use the JWT to access your IAP-secured resource.
JWTs are signed using the private key of the service account.
If you have a service account key file, the JWT can be signed locally.
The script sends a JWT header along with the payload. For the kid
field in the header, use the service account's private key ID, which is in the private_key_id
field of the service account credential JSON file. The key is also used to sign the JWT.
In all cases, to access the app, use the signed-jwt
:
curl --verbose --header 'Authorization: Bearer SIGNED_JWT' URL
Authenticate with an OIDC token
When making requests to the IAP-secured resource, you must include the token in the Authorization
header: Authorization: 'Bearer OIDC_TOKEN'
email
claim for IAP to accept it.
The following code samples demonstrate how to obtain an OIDC token.
Obtain an OIDC token for the default service accountTo get an OIDC token for the default service account for Compute Engine, App Engine, or Cloud Run, reference the following code sample to generate a token to access an IAP-secured resource:
C#To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
GoTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
JavaTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
Node.jsTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
PHPTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
PythonTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
RubyTo authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.
Obtaining an OIDC token from a local service account key fileTo generate an OIDC token using a service account key file, you will use the key file to create and sign a JWT assertion, then exchange that assertion for an ID token. The following Bash script demonstrates this process:
Bash#!/usr/bin/env bash
#
# Example script that generates an OIDC token using a service account key file
# and uses it to access an IAP-secured resource
set -euo pipefail
get_token() {
# Get the bearer token in exchange for the service account credentials
local service_account_key_file_path="${1}"
local iap_client_id="${2}"
# Define the scope and token endpoint
local iam_scope="https://www.googleapis.com/auth/iam"
local oauth_token_uri="https://www.googleapis.com/oauth2/v4/token"
# Extract data from service account key file
local private_key_id="$(cat "${service_account_key_file_path}" | jq -r '.private_key_id')"
local client_email="$(cat "${service_account_key_file_path}" | jq -r '.client_email')"
local private_key="$(cat "${service_account_key_file_path}" | jq -r '.private_key')"
# Set token timestamps (current time and expiration 10 minutes later)
local issued_at="$(date +%s)"
local expires_at="$((issued_at + 600))"
# Create JWT header and payload
local header="{'alg':'RS256','typ':'JWT','kid':'${private_key_id}'}"
local header_base64="$(echo "${header}" | base64 | tr -d '\n')"
local payload="{'iss':'${client_email}','aud':'${oauth_token_uri}','exp':${expires_at},'iat':${issued_at},'sub':'${client_email}','target_audience':'${iap_client_id}'}"
local payload_base64="$(echo "${payload}" | base64 | tr -d '\n')"
# Create JWT signature using the private key
local signature_base64="$(printf %s "${header_base64}.${payload_base64}" | openssl dgst -binary -sha256 -sign <(printf '%s\n' "${private_key}") | base64 | tr -d '\n')"
local assertion="${header_base64}.${payload_base64}.${signature_base64}"
# Exchange the signed JWT assertion for an ID token
local token_payload="$(curl -s \
--data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
--data-urlencode "assertion=${assertion}" \
https://www.googleapis.com/oauth2/v4/token)"
# Extract just the ID token from the response
local bearer_id_token="$(echo "${token_payload}" | jq -r '.id_token')"
echo "${bearer_id_token}"
}
main() {
# Check if required arguments are provided
if [[ $# -lt 3 ]]; then
echo "Usage: $0 <service_account_key_file.json> <iap_client_id> <url>"
exit 1
fi
# Assign parameters to variables
SERVICE_ACCOUNT_KEY="$1"
IAP_CLIENT_ID="$2"
URL="$3"
# Generate the ID token
echo "Generating token..."
ID_TOKEN=$(get_token "${SERVICE_ACCOUNT_KEY}" "${IAP_CLIENT_ID}")
# Access the IAP-secured resource with the token
echo "Accessing: ${URL}"
curl --header "Authorization: Bearer ${ID_TOKEN}" "${URL}"
}
# Run the main function with all provided arguments
main "$@"
This script performs the following steps:
To use this script:
get_iap_token.sh
chmod +x get_iap_token.sh
./get_iap_token.sh service-account-key.json \
OAUTH_CLIENT_ID \
URL
Where:
service-account-key.json
is your downloaded service account key fileIn all other cases, use the IAM credentials API to generate an OIDC token by impersonating a target service account right before accessing an IAP-secured resource. This process involves the following steps:
Provide the calling service account (the service account associated with the code that is obtaining the ID token) with the Service Account OpenID Connect Identity Token Creator role (roles/iam.serviceAccountOpenIdTokenCreator
).
This gives the calling service account the ability to impersonate the target service account.
Use the credentials provided by the calling service account to call the generateIdToken method on the target service account.
Set the audience
field to your client ID.
For step-by-step instructions, see Create an ID token.
If your application uses the Authorization
request header, you can include the ID token in a Proxy-Authorization: Bearer
header instead. If a valid ID token is found in a Proxy-Authorization
header, IAP authorizes the request with it. After authorizing the request, IAP passes the Authorization
header to your application without processing the content.
If no valid ID token is found in the Proxy-Authorization
header, IAP continues to process the Authorization
header and strips the Proxy-Authorization
header before passing the request to your application.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4