OIDC Session Metadata and Zero Trust: An Architecture Decision Record

In regulated financial environments — PCI-DSS, SOC 2 Type II, Brazil's BACEN 4.658 — federated authentication with external providers like Google has always been a double-edged sword. You gain UX and reduce credential management surface, but you lose visibility into the user's session lifecycle on the IdP side. A valid JWT issued at 09:00 is still accepted at 17:00 even if the user changed their password at 14:00, Google detected suspicious account access at 15:00, or the device was flagged as compromised at 16:00.

The traditional mitigation model was simple and blunt: short-lived tokens (15-30 minutes) with aggressive refresh. This works, but at a cost: re-authentication latency, friction in long-running flows (reports, exports, user-initiated batch operations), and pressure on Cognito rate limits — which enforces 120 token requests per second per user pool by default, a limit medium-scale systems hit easily at peak hours.

OIDC session metadata shifts the defense vector. Instead of shortening token lifetime, you enrich the authorization decision with real-time IdP signals. The token can be longer-lived, but each sensitive request passes through an evaluation that considers the current state of the session at Google — not just the state at issuance time. This is, conceptually, what NIST SP 800-207 calls 'continuous verification' within a Zero Trust model.

Before reaching the options, it is necessary to name the forces that make this decision non-trivial:

Latency vs. Signal Freshness. Querying Google session metadata on every request adds an external network call to the critical path. In financial APIs with a p99 SLO < 300ms, this is unacceptable without caching. But caching introduces a staleness window — exactly the problem we are trying to solve.

IdP Availability vs. Service Continuity. If Google's metadata endpoint is unavailable, what do we do? Fail-open (accept the request) or fail-closed (deny)? In financial systems, fail-closed is the correct regulatory default, but this means a Google degradation can take down your service.

Policy Granularity vs. Operational Complexity. The more granular the adaptive access policy — 'this endpoint requires risk score < 20 AND recent device verification' — the harder it is to debug, audit, and explain to compliance teams.

Claims Coverage vs. Vendor Dependency. The metadata Google exposes is proprietary. If tomorrow you need to support Microsoft Entra or Okta as an alternative IdP, your policy logic needs to abstract over different claims schemas. This is a lock-in risk that few architecture teams model explicitly.

These four tensions define the design space. The options below are different responses to the same set of forces.

After modeling the four options against the identified forces, the decision I would make is a variant of Option C with a surgical synchronous element: asynchronous session metadata evaluation for most requests, with mandatory synchronous step-up for high-financial-impact operations.

The logic is as follows: not all requests have the same risk profile. A balance inquiry or statement read has tolerance for a 5-minute staleness window on the risk signal. A transfer above R$ 10,000, a personal data change, or a credit approval does not. Forcing the same evaluation model on both is over-engineering in the first case and under-engineering in the second.

The concrete implementation uses three AWS components in coordination:

1. DynamoDB as session state cache: partition key userId#sessionId, TTL of 5 minutes, with attributes riskScore, verificationState, lastMetadataRefresh, and stepUpRequired. Provisioned capacity with auto-scaling: 100 RCU/WCU base, scaling to 2,000 at peak. KMS CMK encryption, end-to-end.

1. Lambda Authorizer with synchronous DynamoDB read: the authorizer reads the cached session state (p99 latency < 5ms with optional DAX) and makes the authorization decision locally. There is no Google call on the critical path. If stepUpRequired = true, it returns 401 with WWW-Authenticate: step-up and the client initiates the re-authentication flow.

1. EventBridge Scheduler + async refresh Lambda: every 4 minutes, a job queries Google's metadata endpoint for active sessions and updates DynamoDB. If the risk signal changes, the stepUpRequired attribute is set atomically with a DynamoDB condition (ConditionExpression: attribute_not_exists(stepUpRequired) OR stepUpRequired = :false), avoiding race conditions.

IAM and Least Privilege in the Lambda Authorizer. The authorizer needs only dynamodb:GetItem on the session table, with condition aws:ResourceTag/Classification = SessionCache. No write permissions. The refresh Lambda role has dynamodb:UpdateItem with dynamodb:LeadingKeys condition restricted to the userId# prefix — preventing a code bug from writing to arbitrary partitions. Both roles use kms:Decrypt with condition kms:EncryptionContext:TableName = session-state.

Circuit Breaker in the Refresh Lambda. The call to Google's metadata endpoint must have a 2-second timeout and at most 2 retries with exponential backoff. If the error rate exceeds 50% in a 60-second window, the circuit breaker opens and the refresh Lambda stops trying — but does not automatically set stepUpRequired = true. The correct policy here is to preserve the last known state and emit a CloudWatch alarm (MetricName: GoogleMetadataUnavailable, threshold > 3 minutes). The fail-open vs. fail-closed decision during Google unavailability must be explicit in the policy and documented in the ADR — not implicit in the code.

Risk Signal Observability. Google's metadata includes fields like credential_age, account_risk_level, and device_verified. These values should be emitted as custom metric dimensions in CloudWatch — not just logged. This allows creating alarms like 'percentage of active sessions with account_risk_level = HIGH > 5%', which is a signal of an ongoing credential stuffing attack. The SLO I would define: riskSignalAge (time since last successful refresh) < 6 minutes for 99% of active sessions.

Cognito User Pools and the Opaque Token Problem. Cognito does not automatically forward custom claims from Google to the access token. You need a Pre Token Generation Lambda trigger that reads the session state from DynamoDB and injects the relevant claims. Note: this trigger adds latency to the token refresh flow — keep it below 100ms or Cognito will timeout the call.

An identity architecture decision does not end at the technical implementation. In regulated financial systems, the traceability of each authorization decision is as important as the decision itself. Each Lambda Authorizer invocation should emit a structured event to CloudWatch Logs with: userId, sessionId, decision (allow/deny/step-up), riskScore at decision time, signalAge in seconds, and the API Gateway requestId. This log is the audit evidence to demonstrate to the regulator that the system was operating with continuous verification.

In the AWS Well-Architected context, this architecture directly touches the Security pillar — specifically the principles of 'apply security at all layers' and 'enable traceability'. The use of KMS CMK with annual rotation, granular IAM conditions, and CloudTrail enabled for all DynamoDB and KMS operations closes the audit loop.

The path to mature Zero Trust from here has two natural steps. The first is adding device context signals — not just what Google knows about the account, but what you know about the device: fingerprint, geolocation, behavioral pattern. This can be implemented via Amazon Fraud Detector or a custom SageMaker model fed by the audit logs. The second is moving the authorization policy to an external engine — Open Policy Agent (OPA) running on EKS, or AWS Verified Permissions with Cedar — decoupling policy logic from the authorizer code and allowing the compliance team to edit policies without code deployments.

This evolution should be on the roadmap, but not in the MVP. The classic trap is trying to build the complete Zero Trust system in the first iteration and delivering nothing.