An AWS Application Load Balancer listener rule uses the authenticate-oidc action to log users in before traffic reaches your service. What does the ALB do with an unauthenticated request, what does your application receive once the user is signed in, and what must the application still verify itself?
answer
- the load balancer runs the login, not the app
- a redirect dance, then a session cookie
- claims arrive as request headers
- one of them is a signed JWT
- headers are only as safe as the network path
basics
~20 sThe ALB runs the OIDC redirect flow itself, sets a session cookie, and then forwards the request with x-amzn-oidc-identity, x-amzn-oidc-accesstoken and a signed x-amzn-oidc-data JWT. The application must verify that JWT's signature and make sure targets cannot be reached without going through the ALB.
solid answer
~50 sOn an unauthenticated request the ALB redirects the browser to the identity provider's authorization endpoint, receives the code back, exchanges it at the token endpoint, calls the user-info endpoint, and stores the session in its own cookie - `AWSELBAuthSessionCookie` by default, split into numbered parts when it is large. Only then does it forward the original request, adding three headers: `x-amzn-oidc-identity` with the subject, `x-amzn-oidc-accesstoken` with the provider's access token, and `x-amzn-oidc-data` - a JWT signed by AWS carrying the user's claims. The rule's `OnUnauthenticatedRequest` setting decides the behaviour for callers that cannot follow a redirect: `authenticate` is the default, `deny` returns 401, `allow` passes the request through unauthenticated. Two things stay your responsibility. Verify the `x-amzn-oidc-data` signature against the regional public key rather than trusting the header blindly, and lock the target security group so nothing but the load balancer can reach it - otherwise anyone who can route to a target simply sets those headers themselves.
go deeper
Know that an ALB listener rule can force a login through an identity provider before requests reach your service, and that the service then receives the user's identity in request headers.
Walk the flow: redirect to the authorization endpoint, code exchange, user-info call, session cookie, then forward with the three x-amzn-oidc headers - and note that it requires an HTTPS listener.
Show the security reasoning: verify the signed JWT, lock targets to the load balancer's security group so the headers cannot be forged, and choose the right OnUnauthenticatedRequest behaviour for API versus browser paths.
Decide whether identity belongs at the edge at all - what you gain by deleting auth code from many internal services, what you lose in portability and logout control, and where the boundary with in-application authorization sits.
## What the action actually does `authenticate-oidc` is a listener rule action on an Application Load Balancer that moves the entire OpenID Connect authorization-code flow into the load balancer. You configure it with the provider's issuer, authorization endpoint, token endpoint and user-info endpoint, plus a client id and client secret and the scopes you want. `authenticate-cognito` is the same mechanism with an Amazon Cognito user pool supplying those endpoints for you. The flow, for a request with no valid session: 1. The ALB responds with a redirect to the identity provider's authorization endpoint. 2. The user authenticates at the provider and is redirected back to the load balancer's callback path. 3. The ALB exchanges the authorization code at the token endpoint and calls the user-info endpoint - server to server, from the load balancer, so it needs network reachability to those endpoints. 4. The ALB sets a session cookie on the browser and finally forwards the *original* request to the target group. The cookie is named `AWSELBAuthSessionCookie` unless you override it, and when the encoded session exceeds what fits in one cookie the ALB splits it into numbered shards. Session lifetime is configurable and defaults to several days, which matters: the ALB's session, not the identity provider's, decides how long a user stays signed in through the load balancer. In the rule's action list, an authenticate action must come **before** the forward action - authentication is a gate the request passes through on its way to the target. ## What the target receives Once a session exists, the ALB adds three request headers before forwarding: - `x-amzn-oidc-identity` - the subject claim identifying the user. - `x-amzn-oidc-accesstoken` - the access token the provider issued, for calling downstream APIs on the user's behalf. - `x-amzn-oidc-data` - a JWT, signed by AWS with an elliptic-curve key, whose payload carries the user claims. Its header names the key id and the endpoint from which the corresponding public key can be fetched for that Region. The application therefore gets identity without implementing OIDC at all: no redirect handling, no token exchange, no library. That is the whole appeal, and it is genuinely useful for internal tools, dashboards and anything you would otherwise leave behind a VPN. ## What remains your job **Verify the signature.** `x-amzn-oidc-data` is a claim, and a claim is only trustworthy if you check who made it. Fetch the public key by the key id in the JWT header, verify the signature, and check the expiry before you believe the claims. Code that reads the header and decodes the payload without verification is trusting whatever the last hop said. **Close the bypass.** These are ordinary HTTP headers. If anything other than the ALB can open a connection to a target - another workload in the VPC, a misconfigured public IP, a developer port-forward - it can set `x-amzn-oidc-identity` to any value it likes and walk straight in as an administrator. The target's security group must permit inbound traffic only from the load balancer's security group, and the application should strip or ignore these headers on any path that can be reached another way. Signature verification and network isolation together are what make edge authentication safe; either alone is not enough. **Decide what non-browser callers do.** The flow is redirect-based, so an API client, a health probe or a monitoring agent cannot complete it. `OnUnauthenticatedRequest` gives you three behaviours - `authenticate` (send the redirect, the default), `deny` (return 401, correct for API paths), `allow` (forward without a session, appropriate only where the application does its own check). In practice a service with both a UI and an API needs two rules: one authenticating the browser paths, one denying or passing through the API paths, which then validate a bearer token themselves. **Remember what edge auth is not.** The ALB authenticates - it establishes who the user is. It does not authorize: deciding whether that user may perform this action stays inside the application. And logout is a genuine wrinkle, since ending the application's own session does not clear the ALB's session cookie; you must expire that cookie and, usually, redirect to the provider's logout endpoint too. ## Practical requirements The action requires an HTTPS listener - tokens and session cookies must not traverse plaintext, and the ALB enforces this. The load balancer needs egress reachability to the identity provider's endpoints. And every authenticated request costs a little more processing at the edge, which is a fair trade for deleting an authentication implementation from a dozen internal services.
- Why is the target's security group as important as verifying the signed token?Because the identity arrives as plain request headers. If anything besides the load balancer can reach the target, it can forge `x-amzn-oidc-identity` and impersonate any user. Restricting the target's inbound rules to the ALB's security group is what makes the header trustworthy in the first place; signature verification is the second lock.
- Your service has a browser UI and a machine-to-machine API on the same host. How do you configure the rules?Two listener rules. The UI paths get the `authenticate-oidc` action so browsers are redirected to sign in. The API paths get a separate rule that either denies unauthenticated requests or forwards them untouched, with the service validating its own bearer tokens - because an API client cannot follow the OIDC redirect flow.
- A user logs out of the application but is still signed in on the next request. What was missed?The ALB's own session cookie was never cleared. Application logout ends the app's session, not the load balancer's, so the ALB keeps forwarding an authenticated request. Logout must expire the ALB session cookie in the response and typically also redirect to the identity provider's end-session endpoint.
saying these in an interview costs you the question
- The x-amzn-oidc-data header can be trusted without verifying its signature.
- ALB authentication also handles authorization for the application.
- API clients can complete the OIDC flow the same way browsers do.
- Application logout also ends the ALB's session.
- The action works on an HTTP listener as long as the IdP uses TLS.