A security engineer is configuring automated, server-to-server data ingestion from an external enterprise SaaS application (Salesforce) into Google Cloud services. The integration must synchronize enterprise records continuously in the background without interactive user authentication. The organization's security policy defines the following requirements: Cryptographic authentication: Avoid using shared symmetric client secrets that could be leaked or intercepted. Non-interactive authorization: Enable unattended background execution using an explicit, designated execution identity. Access governance: Prevent user self-authorization and enforce strict pre-authorization so that only admin-approved accounts can initiate token exchange. Least privilege and persistence: Restrict scopes strictly to data access APIs and maintain valid offline access until explicitly revoked. Which OAuth 2.0 configuration should the engineer implement to meet these requirements?

Configure the OAuth 2.0 JWT Bearer flow using an asymmetric 2048-bit RSA key pair, upload the public certificate to the external client app, set permitted users to "Admin approved users are pre-authorized", and grant API and offline access scopes.: ### What the OAuth 2.0 JWT Bearer Flow Is The **OAuth 2.0 JWT Bearer Token Flow** (defined in RFC 7523) provides an automated, server-to-server authentication mechanism where a client application signs a JSON Web Token (JWT) using an **asymmetric private key**. The target authorization server verifies the signature against a pre-registered **public X.509 certificate**, eliminating the need for shared static secrets or interactive user logins. ### How It Meets the Requirements - **Cryptographic authentication without symmetric secrets**: By generating an **RSA 2048-bit private key** (`server.key`) to sign authorization assertions and uploading the corresponding public certificate (`server.crt`) to the external application, the integration eliminates static shared secrets (`client_secret`), protecting against credential leaks and interception. - **Non-interactive authorization**: The JWT Bearer flow allows Google Cloud background connectors to programmatically sign assertions and exchange them directly for access tokens on behalf of a designated enterprise account without manual browser redirection. - **Access governance**: Setting **Permitted users** to **Admin approved users are pre-authorized** ensures that individual end users cannot self-authorize the application. Only identities explicitly mapped to the app via profiles or permission sets can execute the flow. - **Least privilege and persistence**: Selecting targeted scopes (`Manage user data via APIs` and `refresh_token, offline_access`) ensures appropriate data extraction capabilities while the refresh token policy maintains continuous synchronization until administrative revocation. ### Key Advantages - **Phishing-resistant, asymmetric cryptography**: Eliminates shared secrets across system boundaries; the private key never leaves the Google Cloud environment. - **Centralized enterprise policy enforcement**: Enforces administrator-level governance by restricting token issuance strictly to designated permission sets. - **Zero interactive overhead**: Ideal for background daemon tasks, extract-transform-load (ETL) pipelines, and continuous AI indexing connectors. - **Fine-grained revocation**: Access can be revoked instantly by revoking the certificate, modifying the user's permission set, or disabling the connected app policy. ### Why This Is Optimal Compared to symmetric client credential flows or user-interactive authorization code flows, the JWT Bearer flow provides the strongest security posture for unattended server-to-server integrations by combining **public key infrastructure (PKI)** with **explicit administrative pre-authorization**.

Oauth2 Jwt Bearer Flow Enterprise Integration | Professional Cloud Security Engineer

Oauth2 Jwt Bearer Flow Enterprise Integration

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

A security engineer is configuring automated, server-to-server data ingestion from an external enterprise SaaS application (Salesforce) into Google Cloud services. The integration must synchronize enterprise records continuously in the background without interactive user authentication.

The organization's security policy defines the following requirements:

Cryptographic authentication: Avoid using shared symmetric client secrets that could be leaked or intercepted.
Non-interactive authorization: Enable unattended background execution using an explicit, designated execution identity.
Access governance: Prevent user self-authorization and enforce strict pre-authorization so that only admin-approved accounts can initiate token exchange.
Least privilege and persistence: Restrict scopes strictly to data access APIs and maintain valid offline access until explicitly revoked.

Which OAuth 2.0 configuration should the engineer implement to meet these requirements?

Configure the OAuth 2.0 Client Credentials flow using a generated consumer key and consumer secret, set permitted users to "All users may self-authorize", and configure full IP relaxation.

Configure the OAuth 2.0 JWT Bearer flow using an asymmetric 2048-bit RSA key pair, upload the public certificate to the external client app, set permitted users to "Admin approved users are pre-authorized", and grant API and offline access scopes.

Configure the OAuth 2.0 Authorization Code flow with Proof Key for Code Exchange (PKCE), specify a web callback URL, and require end-user consent for every token generation request.

Configure the OAuth 2.0 Implicit Grant flow, store the returned access tokens in Cloud Storage, and assign broad administrative scopes across all resource endpoints.

Professional Cloud Security Engineer

Oauth2 Jwt Bearer Flow Enterprise Integration

Related questions