Browser access and automation use different flows
An administrator's successful browser session does not prove that a service account can call an IAP-protected web resource. Automation needs a supported credential flow and IAP access for its own identity. A browser cookie copied into a job is not a maintainable service authentication design.
IAP documents service-account JWT and OIDC options with different audience contracts. The JWT flow scopes the audience to the protected resource URL as documented. The OIDC flow uses the relevant OAuth client configuration and audience. Current guidance also distinguishes the default Google-managed OAuth client from programmatic flows that require client configuration, while providing a service-account JWT route. Do not interchange these audience values with Cloud Run's direct invoker audience rules.
Prepare the exact protected URL, IAP resource, runtime service account, OAuth-client ownership where applicable, and permitted token-signing method. Obtain read access to IAP settings and IAM policy. Prefer supported remote signing or identity libraries over distributing a long-lived private key to the job.
Establish one deliberate authentication path
- Identify whether the request actually passes through IAP and which resource policy governs it. Confirm the application's OAuth-client setup, including whether it uses a Google-managed client. Record the intended JWT or OIDC method before generating credentials.
- Review IAP access for the automation identity at the appropriate protected-resource scope. The documented IAP-secured web access role grants the relevant access permission; a broad project administration role is not a substitute for understanding the target policy.
- For the JWT flow, follow the documented issuer, subject, audience, and lifetime requirements. Scope signing permission to the intended service account. For the OIDC flow, verify the supported OAuth-client and programmatic-access configuration and obtain a token for that audience through a maintained library.
- Make a harmless request from the real automation runtime. Inspect the response and logs to distinguish IAP rejection from an authenticated request rejected by the application. Keep bearer credentials out of command output, redirects captured in shared logs, and incident tickets.
Illustrative scenario
A fictional monitoring job successfully authenticates directly to a Cloud Run service but fails when aimed at an IAP-protected web URL. It reuses a token with the Cloud Run service URL as audience. The team identifies the IAP token contract, chooses the supported service-account flow for its client configuration, and grants narrowly scoped IAP access. The protected backend can then perform its own application authorization.
| Observation | Boundary to inspect | Correction |
|---|---|---|
| Browser works, job is redirected or denied | Automation token flow | Use supported programmatic credentials |
| Token is signed but rejected | Token type and audience | Match JWT or OIDC requirements |
| Identity authenticates but lacks access | Protected-resource IAP IAM | Grant the intended web-resource access |
| IAP passes request, app returns forbidden | Application authorization | Review the app's own permission model |
Verify identity and scope
Run the approved automation identity against a safe endpoint and confirm the expected application result. Test a separate unauthorized identity in staging. Verify the token refresh or regeneration path over the job's real operating duration. Check redirects deliberately so a login page is not mistakenly counted as a healthy application response. A successful HTTP response must match the expected business or monitoring content.
Operating procedure
Record token method, audience, IAP resource, signing identity, and access-policy owner. Review these after domain, OAuth-client, backend, or service-account changes. Monitor IAP authentication failures separately from backend failures. Reassess token handling after library upgrades and keep signing rights constrained to the service identities that actually need automated access.
Explore Clouvenix cloud security for implementation and operational handover.