A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://cloud.google.com/iap/docs/authentication-howto below:

Programmatic authentication | Identity-Aware Proxy

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.

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

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 account

You 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 app
  1. Create or use an existing OAuth 2.0 client ID for your mobile app. To use an existing OAuth 2.0 client ID, follow the steps in How to share OAuth Clients. Add the OAuth client ID to the allowlist for programmatic access for the application.
  2. Get an ID token for the IAP-secured client ID.
  3. Include the ID token in an Authorization: Bearer header to make the authenticated request to the IAP-secured resource.
Authenticate from a desktop app

This section describes how to authenticate a user account from a desktop command line.

  1. To allow developers to access your application from the command line, create a desktop OAuth 2.0 client ID or share an existing desktop OAuth client ID.
  2. Add the OAuth ID to the allowlist for programmatic access for the application.
Sign in to the application

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:

  1. Sign in to your account that has access to the Google Cloud resource.
  2. Start a local server that can echo the incoming requests.

      # Example using Netcat (http://netcat.sourceforge.net/)
      nc -k -l 4444
    
  3. 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
    
  4. 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
    
  5. 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.

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.

Note: The refresh token workflow is not supported for access level policies. You must regenerate a new ID token using the full authentication flow. Authenticate a service account

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 JWT

IAP 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:

  1. 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.

  2. Create a JWT for the IAP-secured resource.

  3. Sign the JWT using the service account private key.

Create the JWT

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,
}
Note: Service account JWTs are limited to the specified audience. You must set the audience to the exact URL and path of the IAP-secured resource, for example, 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:

Sign the JWT using IAM Service Account Credentials API

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.

gcloud
  1. Run the following command to prepare a request with the JWT payload
cat > claim.json << EOM
{
  "iss": "SERVICE_ACCOUNT_EMAIL_ADDRESS",
  "sub": "SERVICE_ACCOUNT_EMAIL_ADDRESS",
  "aud": "TARGET_URL",
  "iat": $(date +%s),
  "exp": $((`date +%s` + 3600))
}
EOM
  1. Use the following Google Cloud CLI command to sign the payload in 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.

Python
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
  1. Run the following command to prepare a request with the JWT payload:

    cat << EOF > request.json
    {
      "payload": JWT_PAYLOAD
    }
    EOF
    
  2. 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.

  3. Use the JWT to access your IAP-secured resource.

Note: Using IAM credentials API to sign the JWT uses a network call. Sign the JWT from a local credential key file

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.

Access the application

In all cases, to access the app, use the signed-jwt:

curl --verbose --header 'Authorization: Bearer SIGNED_JWT' URL
Authenticate with an OIDC token
  1. Create or use an existing OAuth 2.0 client ID. To use an existing OAuth 2.0 client ID, follow the steps in How to share OAuth Clients.
  2. Add the OAuth ID to the allowlist for programmatic access for the application.
  3. Ensure the default service account is added to the access list for the IAP-secured project.

When making requests to the IAP-secured resource, you must include the token in the Authorization header: Authorization: 'Bearer OIDC_TOKEN'

Note: The generated ID token must have an 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 account

To 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.

Go

To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.

Java

To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.

Node.js

To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.

PHP

To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.

Python

To authenticate to IAP, set up Application Default Credentials. For more information, see Set up authentication for a local development environment.

Ruby

To 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 file

To 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:

  1. Extracts the service account key information from your JSON key file
  2. Creates a JWT with the necessary fields, including the IAP client ID as the target audience
  3. Signs the JWT using the service account's private key
  4. Exchanges this JWT for an OIDC token through Google's OAuth service
  5. Uses the resulting token to make an authenticated request to your IAP-secured resource

To use this script:

  1. Save it to a file, for example: get_iap_token.sh
  2. Make it executable: chmod +x get_iap_token.sh
  3. Run it with three parameters:
  ./get_iap_token.sh service-account-key.json \
    OAUTH_CLIENT_ID \
    URL

Where:

Obtain an OIDC token in all other cases

In 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:

  1. 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.

  2. 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.

What's next

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