Review the whole journey from who signed in to what this request may do now. Inventory every sign-in and recovery route; trace how each creates a session; inspect the session's lifetime, renewal and termination; then follow a sensitive request through current membership and resource checks. A successful login is evidence of authentication, not permission to read a particular customer's object. The answer changes when your application supports several identity providers, machine credentials or users in more than one account: each entry path needs the same access decision, but may carry different assurance evidence. OWASP separates authentication, session management and authorization on every request for good reason. A review that checks only the login screen leaves the most consequential boundaries untouched.
This guide produces a small evidence ledger rather than a claim that an application is “secure.” You can do much of it from source, configuration and deployment records. Confirming runtime behavior needs an authorized test environment with synthetic users and accounts. Record which kind of evidence you actually have.
Set the scope around actions, not pages
Start with one deployed application and an immutable revision or release identifier. Name the browser client, API, identity provider, session store, refresh mechanism and any gateway that can reject a request. Add native password login, SSO, passkeys, recovery, invitations, service tokens, mobile clients, websocket connections and background actions when they exist. A route visible only to an internal client still deserves review if it can deliver customer data.
Choose three representative actions before reading implementation details: an ordinary account read, a cross-account or cross-object read, and a sensitive change such as adding an administrator or replacing an authenticator. For each, write the intended rule in plain language. “Only an active member of account A with the billing capability can download an invoice belonging to A” is testable. “Authenticated users can download invoices” is not.
The OWASP Multi Tenant Security Cheat Sheet treats tenant isolation and per-resource access as separate concerns. Make that distinction in your scope: authentication, current account membership, action capability and ownership of the requested object are four different questions.
Illustrative case: one person, two accounts, three sessions
Illustrative case, not a customer system or observed exploit: Maya belongs to both Alder Analytics and Birch Retail in a B2B SaaS product. She is a billing administrator in Alder and a read-only analyst in Birch. She signs in with SSO on a laptop; her browser holds an application session. A mobile client uses a separately issued token. A CI job has a machine credential for Alder's exports. The browser has an account switcher that changes a displayed name and sends accountId with API requests.
The review question is whether changing that selector, refreshing an old session, or calling the API directly can borrow Alder's billing privilege while asking for a Birch invoice. The existence of a signed session does not answer it. Nor does the account switcher: the server must bind the actor to the selected account and check the invoice owner and action for this request. OWASP's authorization guidance calls for permission checks on every request, including requests generated outside the normal UI.
Use a compact trace. These entries are review hypotheses until the named evidence is collected:
| Boundary | Question for Alder invoice download | Evidence to collect | What would fail it |
|---|---|---|---|
| Entry | Is this Maya's authenticated browser session? | Validated issuer, subject, audience, session ID and original authentication time | A client-supplied email or account name stands in for verified identity |
| Assurance | Did the sign-in meet the action's authentication policy? | Provider result or server-recorded challenge, method and time | A browser flag or refreshed token is treated as a new MFA challenge |
| Membership | Is Maya an active Alder member now? | Current membership and revocation state | An old token's account claim revives removed access |
| Action | May that membership download Alder invoices? | Current role or capability decision | Birch analyst rights are mixed with Alder administrator rights |
| Resource | Does invoice INV-42 belong to Alder? |
Server-side owner lookup and checked response path | A caller-controlled ID or cache key determines ownership |
| Release | Is the same decision applied before PDF bytes leave? | API and object-delivery path review | The API checks access but a presigned download bypasses it |
The trace does not assert that INV-42 exists or that a cross-account request succeeded. It tells the team where a counterexample would matter.
Follow one identity through a day, not just a login
The following timeline is synthetic; it is a review exercise, not observed application behavior. Maya authenticates through SSO at 09:00, receives browser session S-1 and later refreshes an access token. Alder requires recent qualifying authentication for adding an administrator, while an ordinary invoice read uses its separate current authorization policy.
| Time | Event | What changed | What did not change |
|---|---|---|---|
| 09:00 | SSO authentication completes | Identity and recorded authentication evidence established | No blanket right to every account |
| 09:01 | App creates S-1 | Application session starts | IdP session is a separate lifecycle |
| 10:00 | Access token refreshed | New token issue/expiry times | Original authentication time is still 09:00 unless a new authentication occurred |
| 10:02 | Maya requests administrator invitation | Sensitive-action decision needed | Token freshness alone does not satisfy recent-authentication policy |
| 10:04 | Qualifying step-up succeeds | New assurance event bound to Maya's session | Birch role remains read-only |
| 10:10 | Alder removes Maya | Alder membership becomes inactive | Birch membership and IdP login may still exist |
| 10:12 | IdP silently authenticates Maya again | A valid identity response may be returned | Removed Alder membership must not be recreated automatically |
OIDC Core distinguishes token issuance from original authentication time, including after refresh. The application must also qualify what the provider's assurance claims mean; an auth_time alone does not prove a particular factor was used.
The timeline exposes three independent failures a login-screen audit would miss: refresh could incorrectly reset assurance age; account switching could reuse Alder's role in Birch; and fresh SSO could revive a removed membership. Each needs a different source check.
Inspect the session record that connects the steps
A useful illustrative server record separates identity, session and assurance:
session S-1
subject: provider-qualified Maya identity
created_at: 09:01
latest_qualifying_authentication: 10:04
assurance_event: event-42, verified under policy P-7
status: active
selected account: request selector, not a stored global role
membership: loaded for the selected account and action
These are example fields, not a prescribed schema. The important property is that refresh does not manufacture event-42 and that a browser cannot set its timestamp. A real implementation needs validated issuer/client binding, session integrity and expiry, appropriate cookie or token handling, and CSRF protection for cookie-authenticated changes.
For S-1, inspect four concrete session controls alongside the assurance record: a new session identifier after authentication or privilege elevation; server-enforced idle and absolute timeouts; a Secure, HttpOnly cookie with an appropriate SameSite policy when cookies carry the session; and server-side invalidation at logout. HttpOnly restricts script access to the cookie, but does not stop a compromised page from making authenticated requests. Refresh must follow the intended session lifetime rather than indefinitely extending an absolute limit. These controls address session theft and fixation, separate from the account checks (OWASP session guidance).
At 10:12, the correct Alder result is “identity recognized, no active membership,” with no protected account data. Birch can remain usable under its own current role. If account-specific IdPs or assurance policies differ, the target account may require its own qualified sign-in. The application must not union grants from all of Maya's memberships.
Keep machine identity outside this human timeline
The CI export credential mentioned earlier has its own issuer, action scope, owner and revocation path. Maya completing MFA does not upgrade that credential, and deleting S-1 does not necessarily revoke it. Inventory it alongside the human journey, then review it under the machine-credential method.
For the human flow, a compact conclusion should identify which transitions were established in source and which remain unobserved. For example: “Refresh preserves original authentication evidence; sensitive actions require a qualifying event; Alder removal denies new Alder requests; mobile session revocation not yet checked.” Those are separate claims requiring their own artifacts, not one global authentication pass.
NIST's session guidance explains why IdP and relying-party sessions have independent lifecycles. The review's practical job is to locate the exact application checks that keep valid identity from becoming stale authority.
When evidence is missing
You may be unable to inspect the customer's IdP configuration, a managed gateway, mobile storage or a downstream file service. Write “not verified” with the missing artifact and owner. Do not turn a signed assertion into proof of MFA strength without checking the issuer policy and challenge semantics. Do not call a logout reliable because the button disappears. If the route map is incomplete, bound the assessment to the routes actually reviewed and schedule the missing ones. If a potentially severe access path is plausible, arrange containment through the incident owner while the technical status remains investigative.
Turn the journey into a reviewable evidence packet
For Maya's browser flow, collect the callback validation, session creation, refresh handling, account selection, invoice authorization, and final delivery implementation. Give each artifact the revision or deployed configuration identity it actually has. The identity provider and application may change independently, so a single application commit cannot identify every relevant policy.
Then connect the packet to the timeline. The refresh handler should explain why the 10:00 token does not manufacture a new assurance event. The account lookup should explain why Birch's reader grant cannot borrow Alder's owner capability. The membership decision should explain why the 10:12 sign-in recognizes Maya without reactivating Alder. If an artifact cannot answer its assigned question, record the precise gap instead of marking the whole row checked because a related file was read.
Separate normal paths from fallback paths. A timeout in membership lookup, a failed session-store read, and a rejected provider response need their own bounded outcomes. The service should not obtain a usable account role from an old client field merely because the authoritative dependency is unavailable. At the same time, an availability failure should be reported as such; it is not evidence that the object policy was exercised successfully.
Review the ordinary logout promise with the same care
Ask what the application's logout control claims to end. It may terminate the current browser session, all application sessions for that identity, or a wider set of identity-provider sessions through an integration. Those are different promises. The review should identify the intended scope before comparing browser and mobile behavior.
For the synthetic day, ending S-1 can correctly leave Maya's separate mobile session active if that is the declared action. An account-removal decision still needs to prevent that mobile session from delivering Alder data. Conversely, a global session reset may intentionally interrupt Birch too. The UI and support procedure should make the distinction clear enough that an operator does not choose a narrower action while expecting a wider one.
The completed review therefore produces several bounded conclusions: identity validation, session lifetime, assurance freshness, account membership, resource access, and delivery. A failure in one does not erase all evidence about the others, but it can change the practical risk of a sensitive operation. That is why the journey is a better review unit than the sign-in page alone.
Your next useful action is to fill the six-row trace for one sensitive operation and ask the identity and service owners to resolve its two weakest entries. Then use the MFA route review to test step-up coverage, or the account-switching guide to examine cross-account behavior in detail.