Learning outcomes
- Trace the session from federated authentication through renewal and termination.
- Set idle, absolute, and reauthentication limits from the protected action and risk.
- Test fixation, theft, replay, stale identity, and logout behavior.
- Separate provider, Pomerium, and application session responsibilities.
Protocol roles
Separate the identity-provider session, federation transaction, Pomerium session, and upstream application session. Each has its own cookie or token, lifetime, keys, revocation mechanism, and owner. Logout from one does not automatically terminate all others.
The user agent carries session bindings. The server validates them and retrieves or verifies server-side state. An application can create its own session after it trusts an upstream identity signal.
Message flow
- The unauthenticated request starts a federated sign-in with state and request-correlation protection.
- The identity provider authenticates the user and returns a protected result for the intended client.
- The relying party validates the response and creates a new session identifier.
- The browser sends the protected session cookie on later requests.
- The relying party checks session validity, timeout, revocation, and current authorization context.
- Renewal or reauthentication replaces or strengthens session state as required.
- Logout, account change, risk event, or expiry terminates the relevant sessions.
Rotate the session identifier after authentication and privilege change. Protect cookies with Secure, HttpOnly, and appropriate SameSite behavior. Bind server-side state to the expected account and client context without relying on unstable fingerprinting as the sole control.
Validation and failure cases
Test session fixation by supplying an identifier before sign-in and confirming that it changes. Test theft by replaying a copied session under controlled conditions. Test idle and absolute expiry. Test concurrent sessions. Test account disable, password or authenticator change, group removal, policy change, provider logout, Pomerium logout, and application logout separately.
Check cross-site request protection for state-changing operations. Do not put reusable session secrets in URLs, logs, analytics, or client-readable storage when a protected cookie can serve the flow.
Design tradeoffs and residual risk
Long sessions reduce user friction but extend theft and revocation exposure. Short sessions and frequent reauthentication increase dependency load and user fatigue. Central logout improves control but can be incomplete across applications and protocols. Refresh mechanisms improve continuity while creating another credential lifecycle.
Pomerium boundary
Pomerium creates and validates its own access session after identity-provider authentication. It can end that session, but the identity-provider session and any upstream application session are separate. The application must decide how it accepts Pomerium identity and how it creates, limits, and revokes local session state.
Exercise
Draw the provider, Pomerium, and application sessions for one route. Record each cookie or token owner, purpose, storage, lifetime, renewal, rotation, and revocation event. Then disable the user and measure each session's last successful action.
Repeat after provider logout and after Pomerium logout. Explain why the observed results differ.
Evaluation checklist
- Are provider, federation, Pomerium, and application sessions distinct in the model?
- Does the identifier rotate after authentication and privilege change?
- Are idle, absolute, renewal, and reauthentication limits explicit?
- Are fixation, theft, cross-site request, and replay cases tested?
- Does logout terminate the sessions that the user and operator expect?
- Is revocation latency measured through the final application action?
Next learning unit
Revocation Latency
Measure how long a disabled identity, authenticator, session, claim, or permission can continue to authorize action.
