This chapter covers App Engine security fundamentals with a deep focus on Identity-Aware Proxy (IAP), a critical component for controlling access to your App Engine applications. Understanding IAP is essential for the ACE exam, as it appears in roughly 10-15% of security-related questions, often in scenarios requiring user authentication without modifying application code. You will learn how IAP works, how to configure it, and how it differs from other access control methods like Firebase Authentication or network-level firewalls.
Jump to a section
Imagine a large corporate building with a VIP floor that hosts sensitive meetings. The building has a main entrance with a security guard who checks IDs. However, the VIP floor requires an additional, more stringent check: a biometric scanner and a verified appointment list. This second layer is Identity-Aware Proxy (IAP). The building itself is App Engine, and the VIP floor is your application. Without IAP, anyone who passes the main entrance (the network firewall) can roam the building and potentially access the VIP floor. With IAP, even if someone sneaks past the main guard, they face the biometric scanner at the VIP floor door. The scanner checks not just any ID, but a verified identity (Google account or external identity) and a specific permission (membership in a Cloud IAP-secured Web App User group). If the person's identity isn't on the approved list, the door remains locked. Moreover, the scanner logs every attempt and can be configured to require additional checks like a PIN (2FA) for highly sensitive areas. IAP works similarly: it intercepts every request to your App Engine app before the request reaches the application code. It verifies the user's identity via Google or OIDC, checks IAM permissions, and only then forwards the request with the user's identity embedded in headers. The original request is never trusted; IAP establishes a new, verified connection to the backend.
What is App Engine Security and Why Does It Matter?
App Engine is a fully managed serverless platform that abstracts away infrastructure. However, this abstraction does not eliminate security responsibilities. The shared responsibility model means Google Cloud secures the underlying infrastructure, but you must secure your application and data. App Engine security encompasses several layers:
Network-level security: VPC firewall rules, Serverless VPC Access, and Cloud Armor.
Identity and access management: IAM roles and service accounts.
Application-level security: authentication and authorization, often handled by IAP or Firebase Authentication.
The ACE exam focuses on IAP as the primary mechanism for authenticating and authorizing users accessing App Engine apps. IAP sits in front of your application and enforces access control based on identity and context, without requiring you to modify your app code. This is a key differentiator from traditional VPNs or firewalls.
How IAP Works Internally
IAP uses a reverse proxy architecture. When a user requests a resource from an App Engine app protected by IAP, the request first reaches Google's global frontend (GFE). The GFE checks if the resource is behind IAP. If yes, it initiates an OAuth 2.0 flow using Google's identity platform. The user is redirected to Google's authentication endpoint (or a third-party OIDC provider if configured). After successful authentication, IAP verifies that the user has the roles/iap.httpsResourceAccessor role on the resource. If authorized, the GFE forwards the request to the App Engine app, but with the original request's source IP replaced by Google's internal IP addresses (typically in the range 130.211.0.0/22, 35.191.0.0/16, and 108.177.0.0/17). Additionally, IAP injects signed JWT headers (X-Goog-Iap-Jwt-Assertion) that contain the user's identity. The backend app can verify this JWT to trust the identity.
Key Components, Values, Defaults, and Timers
IAP Brand: A single OAuth 2.0 consent screen per project. Default: no brand exists until created. Must be configured before enabling IAP.
OAuth Client: Created automatically when you set up IAP. Used for the OAuth flow.
IAP Roles: roles/iap.httpsResourceAccessor grants access to the resource. roles/iap.admin allows managing IAP settings.
Backend Service: The App Engine service (default or specific version) you protect. IAP is enabled per service, not per version.
Access Context: Optional context-aware access policies using Access Context Manager (ACM) to enforce conditions like device policy, IP range, or time.
Session Duration: Default session length is 1 hour (configurable via IAP settings). After expiry, the user must re-authenticate.
JWT Verification: The X-Goog-Iap-Jwt-Assertion header contains a JWT signed by Google. The backend can verify it using the JWKS endpoint: https://www.gstatic.com/iap/verify/public_key. The JWT includes sub (user ID), email, aud (audience = IAP client ID), and exp (expiration).
Configuration and Verification Commands
To enable IAP on an App Engine service: 1. Create an OAuth consent screen brand:
gcloud alpha iap oauth-brand create --application_title="MyApp" --support_email="admin@example.com"Enable IAP on the App Engine service:
gcloud iap web enable --resource-type=app-engine --service=SERVICE_IDAdd users to the IAP-secured accessor role:
gcloud iap web add-iam-policy-binding --resource-type=app-engine --service=SERVICE_ID --role=roles/iap.httpsResourceAccessor --member=user:user@example.comTo verify IAP is working, access the app URL. You should be redirected to a login page. After authentication, you can see the IAP headers by checking the request logs in Cloud Logging:
gcloud logging read "resource.type=gae_app AND logName=projects/PROJECT_ID/logs/requests" --limit 10Look for the x-iap-* headers.
How IAP Interacts with Related Technologies
Firebase Authentication: If you use Firebase Auth, you can still use IAP for an additional layer. However, IAP itself uses Google Identity Platform; Firebase Auth is separate. You can combine them: IAP authenticates, then your app uses Firebase for additional roles.
Cloud Armor: Works at the network layer (L7) and can filter requests based on IP, geo, or OWASP rules. IAP works at the identity layer. They complement each other: Cloud Armor blocks malicious traffic before it reaches IAP, reducing authentication load.
VPC Firewall Rules: For App Engine Standard, VPC firewall rules are not directly applicable (App Engine is serverless). For App Engine Flexible, you can use VPC firewall rules if the instance is in a VPC. IAP is independent of VPC.
Service Accounts: IAP can be used to authenticate service-to-service calls. By default, IAP is designed for end-user authentication. For service accounts, you can use IAP with OIDC tokens or use Cloud Endpoints.
IAP for External Identities
IAP supports external identities (non-Google accounts) via OpenID Connect (OIDC) or SAML. You can configure a third-party identity provider (IdP) such as Okta or Azure AD. The flow: user authenticates with the IdP, IdP returns an ID token, IAP validates the token and checks IAM permissions. This is configured in the IAP settings by specifying the OIDC provider's issuer URI and audience.
IAP and App Engine Versions
IAP is applied at the service level, not version level. If you have multiple versions of an App Engine service, all versions behind that service are protected. To selectively protect versions, you must use separate services (e.g., default and staging) and enable IAP only on the desired service. Alternatively, use URL dispatch rules with different services.
Context-Aware Access
IAP can enforce context-aware access policies using Access Context Manager. For example, you can require that users access from a corporate IP range or from a device that is company-managed. This is configured by creating an access level in Access Context Manager and attaching it to the IAP resource. The policy is evaluated after authentication but before authorization. If the context does not match, access is denied even if the user has the IAP role.
Performance and Scaling
IAP introduces minimal latency (typically <50ms) because it runs on Google's global infrastructure. It scales transparently with App Engine. There is no additional cost for IAP itself, but you pay for the OAuth infrastructure and Cloud Logging if used for audit. IAP does not affect App Engine's scaling behavior; the app still scales based on request load.
Common Pitfalls
IAP Brand Not Created: If you forget to create the OAuth brand, IAP enablement fails with an error.
Wrong Resource Type: When enabling IAP via gcloud, you must specify --resource-type=app-engine. Using --resource-type=iap_web is incorrect for App Engine.
Session Timeout: If users complain about frequent re-authentication, check the session duration setting (default 1 hour). You can increase it up to 24 hours.
JWT Verification Failure: The backend must verify the JWT using the correct audience (the IAP client ID). If the audience mismatches, verification fails. The client ID can be found in the IAP settings or via gcloud iap web get-iam-policy.
App Engine Standard vs Flexible: IAP works identically on both, but for Flexible, you must ensure the VM can reach the IAP proxy (no firewall blocking outbound 443 to Google's IPs).
Exam Tips
Remember that IAP works at the application layer (L7), not network layer (L3/L4).
Know that IAP does not require any code changes in the app; it's a proxy.
The default session length is 1 hour.
IAP uses OAuth 2.0 and OpenID Connect.
For service-to-service calls, use service accounts with IAP or Cloud Endpoints.
IAP can be used with any Google Cloud service that supports it (App Engine, GKE, Compute Engine via HTTPS load balancers, etc.).
User Requests App Engine URL
The user enters the App Engine application URL in a browser. The DNS resolves to Google's global frontend (GFE). The GFE inspects the request and determines that the target App Engine service has IAP enabled. Instead of forwarding the request directly to the application, the GFE initiates an OAuth 2.0 authentication flow. The user's browser is redirected to the Google Accounts authentication endpoint (or a third-party IdP if configured). The request at this point contains no user identity; it's just an HTTP GET. The GFE returns a 302 redirect with a `Location` header pointing to the OAuth authorization URL.
User Authenticates with Identity Provider
The user's browser follows the redirect to the identity provider (e.g., Google sign-in). The user enters credentials (username/password, or uses SSO). If 2FA is required by the IdP, the user completes that step. Upon successful authentication, the IdP generates an ID token (JWT) containing claims like `sub`, `email`, `hd` (hosted domain), and `exp`. The IdP sends a callback to the GFE with this token. The GFE validates the token's signature and expiry. The user is now authenticated but not yet authorized.
IAP Checks IAM Permissions
After authentication, the GFE (acting as IAP proxy) checks if the authenticated user has the IAM role `roles/iap.httpsResourceAccessor` on the specific App Engine service. This is done by calling the Cloud IAM API internally. The IAM policy is evaluated against the resource (the App Engine service). If the user has the role (directly or via group membership), authorization succeeds. If not, the user receives a 403 Forbidden page. The IAM check is cached for a short period (seconds) to optimize performance.
IAP Forwards Request to App Engine
If authorized, the GFE creates a new HTTP request to the App Engine service. The original request's source IP is replaced with one of Google's internal IPs (e.g., `130.211.0.0/22`). The GFE adds several headers: `X-Goog-Authenticated-User-Email` (obfuscated), `X-Goog-Authenticated-User-Id` (obfuscated), and `X-Goog-Iap-Jwt-Assertion` (a signed JWT containing the user's identity and audience). The App Engine service receives this request and processes it. The application can optionally verify the JWT to trust the identity. The response flows back through the GFE to the user.
Application Verifies JWT (Optional)
The App Engine application can verify the `X-Goog-Iap-Jwt-Assertion` header to ensure the request came through IAP and to extract the user's identity. Verification involves fetching the public key from `https://www.gstatic.com/iap/verify/public_key`, checking the JWT signature, validating the `aud` claim matches the IAP client ID, and checking the `exp` claim. If verification fails, the application should reject the request. This step is optional because IAP already guarantees the user is authenticated and authorized; however, it adds defense-in-depth. Many exam questions test that the JWT is signed by Google and can be verified using Google's public key.
Enterprise Scenario 1: Internal Employee Portal
A large enterprise runs an internal HR portal on App Engine Standard. The portal contains sensitive employee data like salaries and performance reviews. The security team mandates that only authenticated employees can access the portal, and access must be logged for audit. They enable IAP on the default App Engine service. They create an OAuth brand with the company's support email. They add a Google Group (e.g., all-employees@company.com) to the IAP-secured accessor role. Employees accessing the portal are redirected to the company's Google Workspace login. IAP authenticates them via Google Workspace (since the company uses G Suite) and checks membership in the group. The session duration is set to 8 hours to reduce re-authentication during the workday. The app uses the X-Goog-Iap-Jwt-Assertion header to log the user's email for audit. Misconfiguration: If the IAP brand is not created, the first employee gets an error. Also, if the group membership is slow to propagate, some employees may get 403 errors temporarily. Scaling: The portal handles 10,000 requests per second; IAP adds negligible latency. The team uses Cloud Armor to block requests from non-corporate IP ranges before they hit IAP, reducing authentication load.
Enterprise Scenario 2: Multi-Tenant SaaS Application
A SaaS company offers a multi-tenant application on App Engine Flexible. Each tenant has a custom subdomain (e.g., tenant1.app.com). They want to use IAP for tenant authentication but need to route users to the correct tenant's data. They cannot use IAP alone because IAP authenticates the user but does not know which tenant the user belongs to. They combine IAP with a custom authentication layer: IAP authenticates the user and passes the identity via headers. The application then maps the user to a tenant using a database lookup. For external identity providers (e.g., Okta), they configure IAP with OIDC. Each tenant uses their own Okta org, so they need separate IAP settings per subdomain. They achieve this by creating separate App Engine services for each tenant (or using URL dispatch) and enabling IAP on each service with a different OIDC configuration. Performance: 100 tenants, each with 500 users. IAP handles the load without issues. Misconfiguration: If the OIDC audience is wrong, IAP rejects valid users. The team learned to test with a single user before rolling out to all tenants.
Enterprise Scenario 3: Hybrid Cloud with On-Premise Authentication
A company uses an on-premise Active Directory (AD) for employee identities. They want to use IAP for an App Engine app but need to authenticate against AD. They set up an OIDC bridge using Azure AD or a custom STS that federates with AD. They configure IAP with the OIDC provider's issuer URL and audience. Employees authenticate via AD through the OIDC flow. IAP validates the token from the OIDC provider. The app does not need to know about AD. This setup avoids duplicating identities in Google Cloud. Common pitfall: The OIDC provider must return a token with the aud claim matching the IAP client ID. If the token's aud is wrong, IAP rejects it. Also, the OIDC provider must be reachable from Google's infrastructure; firewall rules must allow outbound from Google to the provider.
The ACE exam tests IAP under Objective 5.2 (Security Compliance) and also appears in scenarios about App Engine security. Expect 2-4 questions directly on IAP. The exam focuses on:
IAP vs. other authentication methods: The most common wrong answer is confusing IAP with Firebase Authentication. Firebase Auth is an SDK that you integrate into your app code; IAP is a proxy that works without code changes. Another wrong answer is assuming IAP provides network-level security (it doesn't; it's application-layer).
IAP and App Engine versions: Candidates often think IAP can be enabled per version. It cannot; it's per service. To protect only a specific version, you must put that version in a separate service.
Session duration: The default is 1 hour. A common trap question asks: "A user complains they are frequently logged out. What should you do?" Answer: Increase the session duration in IAP settings (up to 24 hours).
JWT verification: The exam tests that the JWT is signed by Google and the public key is at https://www.gstatic.com/iap/verify/public_key. Also, the aud claim must match the IAP client ID.
IAM roles: The role for access is roles/iap.httpsResourceAccessor. The role for administration is roles/iap.admin. Do not confuse with roles/appengine.appViewer.
External identities: IAP supports OIDC and SAML. The exam may ask how to integrate with an external IdP. The correct answer is to configure the OIDC provider in IAP settings.
Context-aware access: The exam may describe a scenario where you need to restrict access to corporate devices. The solution is to use Access Context Manager with IAP.
Troubleshooting: If users get a 403 error, the most likely cause is missing IAM role roles/iap.httpsResourceAccessor. If they get a login loop, check the OAuth client configuration or session expiry.
To eliminate wrong answers, remember the mechanism: IAP intercepts requests before they reach App Engine. It does not modify the app code. It uses OAuth 2.0. It adds headers. It cannot block requests based on IP (use Cloud Armor for that).
IAP is a reverse proxy that authenticates and authorizes users before requests reach App Engine, without code changes.
The IAM role for accessing an IAP-protected resource is `roles/iap.httpsResourceAccessor`.
Default IAP session duration is 1 hour; configurable up to 24 hours.
IAP adds headers `X-Goog-Authenticated-User-Email`, `X-Goog-Authenticated-User-Id`, and `X-Goog-Iap-Jwt-Assertion` to forwarded requests.
The JWT in `X-Goog-Iap-Jwt-Assertion` is signed by Google and can be verified using the public key at `https://www.gstatic.com/iap/verify/public_key`.
IAP is enabled per App Engine service, not per version.
For external identity providers, configure OIDC or SAML in IAP settings.
Context-aware access can be enforced using Access Context Manager with IAP.
IAP does not replace network security; use Cloud Armor for IP/geo filtering.
IAP supports App Engine Standard and Flexible equally.
These come up on the exam all the time. Here's how to tell them apart.
IAP (Identity-Aware Proxy)
No code changes required; works as a reverse proxy.
Uses OAuth 2.0 / OIDC at the proxy level.
Enforced at the Google Cloud infrastructure level.
Supports context-aware access (device, IP, time).
Best for serverless apps like App Engine without modifying app.
Firebase Authentication
Requires integrating Firebase SDK into application code.
Provides client-side authentication and user management.
Runs within the application; no proxy.
Does not natively support context-aware access; must implement manually.
Best for apps that need custom authentication UI or user management.
Mistake
IAP requires modifying application code to handle authentication.
Correct
IAP works as a reverse proxy without any code changes. The application receives authenticated requests with identity headers. Optionally, you can verify the JWT in code, but it is not required.
Mistake
IAP can be enabled per version of an App Engine service.
Correct
IAP is enabled at the service level, not per version. All versions of a service are protected. To protect only a specific version, you must deploy it as a separate service.
Mistake
IAP provides network-level security like a firewall.
Correct
IAP is an application-layer (L7) identity proxy. It does not filter based on IP addresses or ports. For network-level security, use Cloud Armor or VPC firewall rules (for App Engine Flexible with VPC).
Mistake
IAP only works with Google accounts.
Correct
IAP supports external identities via OIDC and SAML. You can configure any OpenID Connect provider, such as Okta, Azure AD, or custom OAuth2 servers.
Mistake
The default session length for IAP is 24 hours.
Correct
The default session length is 1 hour. It can be configured up to 24 hours in IAP settings.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
First, create an OAuth brand using `gcloud alpha iap oauth-brand create`. Then enable IAP on the App Engine service with `gcloud iap web enable --resource-type=app-engine --service=SERVICE_ID`. Finally, grant access to users by adding them to the `roles/iap.httpsResourceAccessor` role using `gcloud iap web add-iam-policy-binding`. Users will then be prompted to log in when accessing the app.
Yes, IAP works with custom domains. The OAuth redirect URIs must include the custom domain. When you enable IAP, the OAuth client is automatically configured with the App Engine URL. If you use a custom domain, you may need to add the custom domain as an authorized redirect URI in the OAuth client settings in the Google Cloud Console under APIs & Services > Credentials.
You can verify the JWT by fetching the public key from `https://www.gstatic.com/iap/verify/public_key`. Use a JWT library to decode and verify the signature. Ensure the `aud` claim matches your IAP client ID (found in IAP settings). Check the `exp` claim for expiration. Many languages have libraries for JWT verification. Google provides sample code for Python, Java, and Go.
IAP is an identity-aware proxy that authenticates users and checks IAM permissions at the application layer. Cloud Armor is a web application firewall (WAF) that filters traffic based on IP, geo, or OWASP rules at the network layer. They complement each other: Cloud Armor blocks malicious traffic before it reaches IAP, reducing the number of authentication requests. You can use both together for defense-in-depth.
IAP is primarily designed for end-user authentication. For service-to-service calls, you should use service accounts with OAuth 2.0 access tokens or Cloud Endpoints. However, you can configure IAP to accept OIDC tokens from service accounts by setting the external identity provider to a custom OIDC issuer that issues tokens for service accounts. This is less common; the recommended approach is to use Cloud Endpoints or direct service account authentication.
A 403 error after authentication means the user is authenticated but not authorized. The most common cause is that the user does not have the `roles/iap.httpsResourceAccessor` role on the App Engine service. Check the IAM policy for the service using `gcloud iap web get-iam-policy --resource-type=app-engine --service=SERVICE_ID`. Add the user or group to the role. Also, verify that the user is not blocked by a context-aware access policy.
In the IAP settings, under 'Identity Provider', select 'Third-party identity provider' and choose OIDC. Enter the issuer URL from Okta (e.g., `https://dev-123456.okta.com/oauth2/default`), the client ID, and the client secret. Ensure the Okta application is configured to return an ID token with the correct audience (the IAP client ID). Users will be redirected to Okta for authentication. After successful login, IAP checks IAM permissions as usual.
You've just covered App Engine Security and IAP — now see how well it sticks with free ACE practice questions. Full explanations included, no account needed.
Done with this chapter?