WEB / WEB-15.03

The modern login journey

Follow browser redirects, the RP session and downstream API permission through Atlas’s server-side login profile and its decision owners.

CORE · RED · BLUE · ARTIFACT · PRACTICE

Read every scenario without motion

Own note

Start after tokens
The scene starts with the token response held by the RP; browser redirects and code exchange are explained in the ledger.
Browser
No local session
Atlas · RP server
ID+AT aliases held; gate pending
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP ID validation
The RP evaluates the selected issuer, audience, time, key and nonce gates; there is no browser session alias yet.
Browser
No local session
Atlas · RP server
ID accepted; iss/sub bound; no session
OpenID Provider
OP prior authentication valid
Notes API
No API request
Create local session
The RP creates a session with a new identifier and local lifetime; it changes neither OP state nor API policy.
Browser
No local session
Atlas · RP server
New local session ready; expires=2000
OpenID Provider
OP prior authentication valid
Notes API
No API request
Browser received response
The RP session response arrived at the browser. The browser received the selected session alias and prepared its next application request to open the notes using that alias; no API request or API data exists yet.
Browser
Session alias received; note request ready; no API data
Atlas · RP server
New local session ready; expires=2000
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP received request
The browser’s normal note request arrived at the RP; session alias receipt is not a successful lookup result.
Browser
Session alias held; no API data
Atlas · RP server
App request received; session pending
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP session gate
Local lookup passed time and invalidation checks; the RP prepared the selected API credential and action.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
No API request
API receipt
The normal API request arrived from the RP; token context and object permission are evaluated by separate local gates.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
Access alias received; gates pending
API policy outcome
The selected token gate is valid; object policy allows the own note. This scene contains no response body or DOM update.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
Token accepted; object allow; no body

Object denied

Start after tokens
The scene starts with the token response held by the RP; browser redirects and code exchange are explained in the ledger.
Browser
No local session
Atlas · RP server
ID+AT aliases held; gate pending
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP ID validation
The RP evaluates the selected issuer, audience, time, key and nonce gates; there is no browser session alias yet.
Browser
No local session
Atlas · RP server
ID accepted; iss/sub bound; no session
OpenID Provider
OP prior authentication valid
Notes API
No API request
Create local session
The RP creates a session with a new identifier and local lifetime; it changes neither OP state nor API policy.
Browser
No local session
Atlas · RP server
New local session ready; expires=2000
OpenID Provider
OP prior authentication valid
Notes API
No API request
Browser received response
The RP session response arrived at the browser. The browser received the selected session alias and prepared its next application request to open the notes using that alias; no API request or API data exists yet.
Browser
Session alias received; note request ready; no API data
Atlas · RP server
New local session ready; expires=2000
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP received request
The browser’s normal note request arrived at the RP; session alias receipt is not a successful lookup result.
Browser
Session alias held; no API data
Atlas · RP server
App request received; session pending
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP session gate
Local lookup passed time and invalidation checks; the RP prepared the selected API credential and action.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
No API request
API receipt
The normal API request arrived from the RP; token context and object permission are evaluated by separate local gates.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
Access alias received; gates pending
API policy outcome
The selected token gate is valid; object policy denies the foreign tenant. This scene contains no response body or DOM update.
Browser
Session alias held; no API data
Atlas · RP server
Session valid; notes:read request ready
OpenID Provider
OP prior authentication valid
Notes API
Token accepted; object deny; no body

RP session expired

Local clock boundary
The browser prepared a note request with its retained session alias. The RP record is at expiresAt=2000 and now=2000 while the OP authentication state remains valid. Holding an alias does not tell the browser the current RP acceptance decision.
Browser
Prior session alias; note request ready
Atlas · RP server
Local session expires=2000; now=2000
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP received request
The browser’s normal request arrived at the RP with its alias; receiving the alias does not remove the timeout.
Browser
Prior session alias held
Atlas · RP server
Request received; local session pending
OpenID Provider
OP prior authentication valid
Notes API
No API request
RP expiry denial
The RP local session gate denied access because now equals expiresAt; access token and object gates are not called.
Browser
Prior session alias held
Atlas · RP server
Local session denied; no API request
OpenID Provider
OP prior authentication valid
Notes API
No API request
Local error receipt
The RP local-session-denied outcome arrived at the browser; this is the RP local-session decision. No request was sent to the API and no new authentication transaction was started at the OP in this scene.
Browser
local-session-denied received; API not called
Atlas · RP server
Local session denied; no API request
OpenID Provider
OP prior authentication valid
Notes API
No API request

ACTORS · STATE · DATA FLOW

One screen, several trust decisions

When Mina opens Atlas, the browser may have no local session cookie alias. Atlas RP server starts an authentication transaction, preparing the selected issuer, its redirect URI, S256 PKCE and browser-bound state/nonce context. The browser visits the OP authorization endpoint. The OP makes authentication and grant decisions and the browser follows the code callback. TLS connections along the way establish transport trust in web origins, not local user binding or Notes API permission. URLs and redirects are not assumed to share a socket or origin.

A callback reaching the RP is a receipt. The RP validates correlation and selected issuer context before exchanging the code server-side. The ID token conveys authentication to the RP; the access token conveys API access context to the RS. Once ID token gates pass, the RP maps issuer/subject to a local account through policy and creates a new local session. This profile returns only a session cookie alias to the browser, keeping ID/access/refresh tokens out of frontend display data. This is a selected server-side architecture, not a mandatory topology for all web clients.

From session to resource decision

When Mina opens her notes, the browser makes an ordinary application request to Atlas. Receiving the cookie alias does not guarantee a successful local session lookup: the server separately checks existence, invalidation and timeouts. A valid session establishes user context; the RP uses the appropriate access token for downstream Notes API. The API checks token validation, audience, expiry and notes:read scope before deciding Mina/tenant/object/read policy. A valid ID token and local session do not replace that final policy.

The artifact describes the complete journey through a decision-owner table; the scene begins at a selected point where the token response is already held by the RP. It shows ID validation, local session creation, browser response, normal request, RP lookup, API arrival and the API gate. The OP receives no new message here; its prior authentication state remains explanatory context. The final allow or deny is a policy decision, not a claim that a response body rendered in a browser or actual note bytes were read. No API request is created in the expired-session branch.

Read every scenario without motion

Foreign resource

The application request is prepared
The browser prepares an ordinary application request with alias session-new-A. Prior login acceptance is not a grant for every selected API resource.
Browser
Session alias; request ready
Server-side RP
RP has not received request
Notes API
API has not received request
The request reached the RP
The RP received the session alias in an ordinary application request. It evaluates the local-session lookup rather than relying on authenticated-looking browser UI.
Browser
Awaiting response
Server-side RP
Input received for session lookup
Notes API
API has not received request
The RP session gate prepares the API request
This row has true idGate and sessionGate; the RP prepares the API request with its server-side access context. An ID token, code or local-session cookie is not substituted as the API access credential.
Browser
Awaiting response
Server-side RP
Session accepted; API request ready
Notes API
API has not received request
The API request arrived
The API received the ordinary request; apiReceives=true. Receipt does not yet mean that token gates or object authorization passed.
Browser
Awaiting response
Server-side RP
Awaiting API outcome
Notes API
Request received; policy pending
The object-gate outcome was prepared
tokenGate=true coexists with objectGate=false; the selected result is object-denied. The API prepares that outcome for the RP without inventing a resource body or numeric HTTP status.
Browser
Awaiting response
Server-side RP
Awaiting API outcome
Notes API
object-denied outcome ready
The API decision reached the RP
The RP received object-denied. The browser has not yet received that response or updated the DOM; successful login does not automatically turn this resource denial into allow.
Browser
Response still pending
Server-side RP
Known: object-denied
Notes API
object-denied outcome ready

Session expiry

A request with the retained alias is ready
The browser still carries session-new-A. This branch selects now=2000 and expiresAt=2000; even with OP session=true, RP local-session policy is separate.
Browser
Alias present; request ready
Server-side RP
RP has not received request
Notes API
API has not received request
The request reached the RP
The RP received the alias in an ordinary request. Neither the browser cookie nor OP login state replaces the local lifetime check.
Browser
Awaiting response
Server-side RP
Session lookup input received
Notes API
API has not received request
Local-expiry equality was rejected
The condition now < expiresAt fails at equality; sessionGate=false. This is not an access-token expiry result and does not imply invalidation of the OP session.
Browser
Awaiting response
Server-side RP
Local session denied at equality
Notes API
API has not received request
API dispatch was withheld
apiReceives=false remains; tokenGate and objectGate stay not evaluated. Without dispatch, no claim is made that the API rejected a token or denied an object.
Browser
Awaiting response
Server-side RP
No API dispatch
Notes API
Token/object not evaluated
The local-denial outcome was prepared
The RP prepares local-session-denied for the browser. Starting another authentication transaction is a separate flow; OP session=true does not create local context.
Browser
Awaiting response
Server-side RP
local-session-denied ready
Notes API
Token/object not evaluated
The RP local decision reached the browser
The browser received local-session-denied. Retaining the alias does not make the session valid again; API gates were never evaluated in this branch.
Browser
Known: local-session-denied
Server-side RP
local-session-denied ready
Notes API
API not contacted

ASSUMPTION · BOUNDARY · CONTROL

Do not overinterpret login success

The normal and foreign-resource branches pass the same ID token, session and access token gates. Only object policy changes: Mina is not bound to a note in the selected other tenant. This isolates the condition of an authorization error. If a system treats accepted identity as permission for every resource, impact depends on the data or actions exposed to that session owner. Opening a client-side page, returning a callback or receiving an API request is not sufficient evidence by itself.

The session-expired branch selects now=2000 and expiresAt=2000. The browser still carries its alias and the OP session is valid, but Atlas rejects its local session and does not call the API. This is not an access token expiry test; it is a boundary belonging to the RP session clock. An active OP does not automatically renew the RP cookie. Starting another authentication transaction is a separate normal flow; merely knowing the OP has a login does not create a session. Combining timeout, credential renewal and reauthentication under one error sends troubleshooting to the wrong actor.

The credential storage boundary

Where a credential is stored is part of the flow. Keeping ID tokens out of this server-side browser profile does not end all browser risks: the session cookie still accompanies application requests, and state-changing operations need their own request protection. HttpOnly restricts script access to the cookie; it does not guarantee authorization for every operation using it. Read each trust boundary together with credential type and recipient to understand what it protects.

Read every scenario without motion

Gate owners

The login-journey evidence map was selected
Journey stages separate transport, transaction, ID validation, local-session and API-policy owners. Review does not collapse them into one login-success row.
Journey observation
Journey stages 1–12
Credential/gate review
Owner map not read
Product evidence scope
Product outcome not examined
Callback and token endpoint were separated
Stage 4 is the code callback, stage 5 is RP correlation and stage 6 is the OP token-endpoint outcome. A browser callback does not complete ID validation or API access.
Journey observation
Callback/token exchange map
Credential/gate review
Code recipient: OP token endpoint
Product evidence scope
API outcome not examined
ID and local-session gates were separated
Stage 7 is the RP ID issuer/audience/time/key/signature/nonce gate; stage 8 is iss/sub binding and a new session. The ID token belongs only at the RP authentication validator.
Journey observation
ID/session map
Credential/gate review
ID recipient: RP; session: RP lookup
Product evidence scope
API outcome not examined
API-token and object gates were separated
Stage 11 is API access context and stage 12 is tenant/object/action policy. An access credential is not interchangeable with a code or session cookie; each gate produces its own evidence.
Journey observation
API gate map
Credential/gate review
Token gate ≠ object gate
Product evidence scope
Policy result separate
Delivery and DOM stayed outside scope
sceneOmissions includes the API response body and DOM rendering. Reading the full gate map does not establish actual data reads, cookie acceptance or the user’s appearance.
Journey observation
Declared full gate map
Credential/gate review
Owner boundaries explicit
Product evidence scope
UNKNOWN: body/DOM delivery
The journey conclusion closed according to evidence
The map explains which owner must produce each decision. It does not establish runtime validation of the entire login journey without actual validator, session-store and API observations.
Journey observation
Known: decision ownership map
Credential/gate review
Runtime observations separately required
Product evidence scope
UNKNOWN: actual end-to-end outcome

API receipt

The foreign-resource decision was selected
The foreign-resource row carries true idGate, sessionGate, opSession and tokenGate. Review reads apiReceives separately from the final object decision.
Journey observation
Foreign-resource row
Credential/gate review
API evidence not examined
Product evidence scope
Resource outcome not examined
The API-receipt field was read
apiReceives=true is only declared state that the API received this ordinary request. Receipt, token verification and data delivery are not the same outcome.
Journey observation
apiReceives=true
Credential/gate review
Receipt known in row
Product evidence scope
Delivery unknown
Token-acceptance scope was preserved
tokenGate=true describes valid token context for this row. It is not substituted for object relationship or tenant policy.
Journey observation
apiReceives=true
Credential/gate review
tokenGate=true
Product evidence scope
Object outcome under review
The final-policy outcome was compared
objectGate=false and expected=object-denied are recorded. API receipt can remain true while the resource action is negative; the difference is not relabelled as login failure.
Journey observation
Known: receipt
Credential/gate review
Known: valid token context
Product evidence scope
Known: object-denied
Missing body observation was preserved
The artifact shows a selected policy result, not an API response body. Actual body delivery or a client DOM outcome is not added to this row without separate evidence.
Journey observation
Known: receipt
Credential/gate review
Known: object denial
Product evidence scope
UNKNOWN: actual body/DOM
Gate correlation was bounded
This row explains how login success and object denial can coexist. Correlation does not require logging token/code/session secrets, and no actual protocol-run claim is made.
Journey observation
Declared gate correlation
Credential/gate review
Known: object-denied
Product evidence scope
Observed product outcome separate

IMPLEMENTATION · SECURITY CONTROL · VERIFICATION

Give each gate an owner and evidence

Atlas tracks transport peers, transaction correlation, OP identity, local sessions and API resource policy separately. Selecting a new session identifier after successful login, rather than promoting an old pre-authentication context, is a session lifecycle decision. The profile selects Secure, HttpOnly and host-bound cookie scope; SameSite is evaluated together with callback type. GET redirects and POST responses are not assumed to have identical cookie behavior. The fixture creates no cookie bytes and does not measure browser enforcement.

Local regression compares three branches. In normal flow the ID gate passes first, the session is created next, and the API receives a request only after an ordinary request and successful session lookup. In foreign-resource the token gate is true but object gate false, so access is denied; in expired-session the OP state remains true but no message reaches the API. Time fixtures also evaluate the 1999/2000 boundary and an invalidated session. These are reproducible state checks of the decision table, not screenshots masquerading as a real login.

Each gate produces its own evidence

Operational evidence comes from different owners: an RP validation library supplies a signature result, the session store a timeout result and the API policy engine an object decision. Safe correlation IDs can link events without logging tokens, codes, cookies or private keys. Provider interoperability, key rollover, consent/freshness policy, refresh behavior and browser navigation need separate isolated integration tests. The full journey table helps plan those tests; completing the model does not establish success in those external systems.

NOW APPLY IT TO THE CASE

Under which conditions does RP-session acceptance reach an API action?

The browser carries a local-session alias; the RP and API apply their own gates. OP state or successful login is not equated with a resource action or browser knowledge.

Which issuer/recipient relationship supplies identity in the case? Separate login or delegation success from evidence for current tenant/object permission.

Open the related case file ↗

READ THE EXAMPLE TOGETHER

Atlas login gate ledger

Select a field and examine what it supports and where the evidence ends.

Read the raw artifact and field explanations

{
  "profile": {
    "architecture": "confidential server-side RP",
    "flow": "OIDC authorization_code + S256",
    "browserCredential": "local session alias only",
    "tokenResponseHeldAtSceneStart": true,
    "actualProtocolRun": false,
    "actualCookieIssued": false,
    "actualApiDataRead": false
  },
  "journey": [
    {
      "stage": 1,
      "actor": "RP",
      "evidence": "new browser-bound transaction; selected issuer, redirect, state, nonce, PKCE context"
    },
    {
      "stage": 2,
      "actor": "Browser",
      "evidence": "normal navigation to OP; no RP authentication acceptance yet"
    },
    {
      "stage": 3,
      "actor": "OP",
      "evidence": "owner authentication and grant decision"
    },
    {
      "stage": 4,
      "actor": "Browser",
      "evidence": "code callback; no access token at API"
    },
    {
      "stage": 5,
      "actor": "RP",
      "evidence": "callback correlation and selected issuer context accepted"
    },
    {
      "stage": 6,
      "actor": "OP token endpoint",
      "evidence": "client/code/redirect/PKCE gate; token response"
    },
    {
      "stage": 7,
      "actor": "RP",
      "evidence": "ID issuer/audience/time/key provenance/signature/nonce gate"
    },
    {
      "stage": 8,
      "actor": "RP",
      "evidence": "local iss/sub binding and new session"
    },
    {
      "stage": 9,
      "actor": "Browser",
      "evidence": "session alias in normal application request"
    },
    {
      "stage": 10,
      "actor": "RP",
      "evidence": "session lookup/expiry/invalidation gate; select API credential"
    },
    {
      "stage": 11,
      "actor": "API",
      "evidence": "access token context and audience/time/scope gate"
    },
    {
      "stage": 12,
      "actor": "API",
      "evidence": "tenant/object/action authorization; selected policy result only"
    }
  ],
  "session": {
    "alias": "session-new-A",
    "issuer": "https://id.example.org",
    "subject": "subject-Mina",
    "expiresAt": 2000,
    "invalidated": false,
    "identifierRenewedAfterAuthentication": true,
    "cookiePolicy": {
      "Secure": true,
      "HttpOnly": true,
      "hostBound": true,
      "SameSite": "Lax selected GET callback profile",
      "csrfForStateChangeSeparate": true
    }
  },
  "sessionCases": [
    {
      "name": "normal",
      "now": 1050,
      "exists": true,
      "invalidated": false,
      "expected": true
    },
    {
      "name": "last-valid",
      "now": 1999,
      "exists": true,
      "invalidated": false,
      "expected": true
    },
    {
      "name": "expiry-equality",
      "now": 2000,
      "exists": true,
      "invalidated": false,
      "expected": false
    },
    {
      "name": "invalidated",
      "now": 1050,
      "exists": true,
      "invalidated": true,
      "expected": false
    }
  ],
  "cases": [
    {
      "case": "normal",
      "idGate": true,
      "sessionGate": true,
      "opSession": true,
      "tokenGate": true,
      "objectGate": true,
      "apiReceives": true,
      "expected": "allow"
    },
    {
      "case": "foreign-resource",
      "idGate": true,
      "sessionGate": true,
      "opSession": true,
      "tokenGate": true,
      "objectGate": false,
      "apiReceives": true,
      "expected": "object-denied"
    },
    {
      "case": "session-expired",
      "idGate": "prior login accepted",
      "sessionGate": false,
      "opSession": true,
      "tokenGate": "not evaluated",
      "objectGate": "not evaluated",
      "apiReceives": false,
      "expected": "local-session-denied"
    }
  ],
  "credentialRecipients": {
    "code": "OP token endpoint",
    "idToken": "RP authentication validator",
    "accessToken": "API resource validator",
    "refreshToken": "OP token endpoint, if issued",
    "sessionCookie": "RP local session lookup"
  },
  "sceneOmissions": [
    "browser-to-OP and callback navigation",
    "token exchange",
    "DNS/TLS/HTTP encoders",
    "actual token validation",
    "refresh and logout",
    "API response body and DOM rendering"
  ]
}

journey: Each full-journey gate has its own owner and evidence.
session: Local timeout and cookie policy; not equal to token exp.
sessionCases: Zero-leeway local session boundary and invalidation.
cases: OP state alone creates neither an RP session nor API permission.
credentialRecipients: Separates credential type from its intended validation owner.

The full journey is an explanatory ledger; the scene processes only the segment after token response. No real login, token/JWS, cookie, session store, browser or API runs.

Two reality checks

A completed callback means API access succeeded.

Callback receipt, token/ID validation, session lookup and API policy are separate gates.

Atlas sessions cannot expire while the OP is signed in.

OP and RP manage their own session lifetimes; neither renews the other automatically.

YOUR TURN

Work through this story.

Predict the outcome, find the evidence boundary, and explain it in your own words.

The OP session is true but the RP local session expired. Is the selected API request sent?

No; local-session-denied and apiReceives=false.
Yes; the OP session overrides every RP deadline.

Read the explained answer

No; local-session-denied and apiReceives=false. — Prior accepted login does not replace current-session validity; token/object gates are not evaluated in this branch.

Is the foreign-resource branch a login failure or an object-permission failure?

Selected lesson artifact fields; teaching example

cases[1]: {"case":"foreign-resource","idGate":true,"sessionGate":true,"opSession":true,"tokenGate":true,"objectGate":false,"apiReceives":true,"expected":"object-denied"}

Every deny means password/OP login failed.
Object-permission failure; earlier gates are true.

Read the explained answer

Object-permission failure; earlier gates are true. — The API accepts token context but does not grant the specific foreign resource.

Why are iss/sub binding, a renewed session identifier and state-changing CSRF policy three separate decisions in modern login?

Read the explained answer

The RP correctly binds issuer+subject to a local account and establishes a new local-session generation after successful authentication. Cookie flags are carrier policy; a state-changing request needs a separate intent/CSRF gate. The scene omits token-exchange/body/DOM stages; a selected policy result is not proof of actual API delivery.

□ I did not equate iss/sub with a display name.

□ I did not count session creation as an action-intent grant.

Open the application console · request / response / browser

Also open request, URL, cookie and DOM examples

Sources and scope

OpenID Connect Core 1.0 — Final incorporating errata set 2§1 Introduction and terminology; §2 ID Token · §3.1.2.1 Authentication Request: openid, prompt, nonce, max_age · §3.1.2.6 Authentication Error Response · §3.1.3.2 Token Request Validation; §3.1.3.5 Token Response Validation · §3.1.3.7 ID Token Validation; §3.1.3.8 Access Token Validation · §5.7 Claim Stability and Uniqueness
RFC 9700 — Best Current Practice for OAuth 2.0 Security§2.1 Protecting Redirect-Based Flows; §2.1.1 Authorization Code Grant · §2.1.2 Implicit Grant; §2.2.1 Access Tokens; §2.2.2 Refresh Tokens · §2.3 Access Token Privilege Restriction; §2.4 Resource Owner Password Credentials Grant; §2.5 Client Authentication
RFC 6749 — The OAuth 2.0 Authorization Framework§1.1 Roles; §1.2 Protocol Flow; §1.3.1 Authorization Code · §1.4 Access Token; §1.5 Refresh Token · §3.2.1 Client Authentication; §3.3 Access Token Scope · §4.1.1–4.1.4 Authorization Code Grant · §5.1 Successful Response; §6 Refreshing an Access Token; §7 Accessing Protected Resources
OWASP Session Management Cheat SheetSameSite Attribute; Domain and Path Attributes · Session Expiration / Idle Timeout; Absolute Timeout · Renew the Session ID After Any Privilege Level Change
OWASP Authorization Cheat SheetRecommendations / Enforce Least Privileges · Recommendations / Deny by Default; Validate the Permissions on Every Request
RFC 6750 — The OAuth 2.0 Authorization Framework: Bearer Token Usage§1.2 Terminology: Bearer Token · §2.1 Authorization Request Header Field · §2.3 URI Query Parameter security qualifications

YOUR NOTES / THIS BROWSER

The modern login journey

1. Core · Mechanism

Own note

Object denied

RP session expired

One screen, several trust decisions

From session to resource decision

2. Red · Trust & Impact

Foreign resource

Session expiry

Do not overinterpret login success

The credential storage boundary

3. Blue · Secure development & defense

Gate owners

API receipt

Give each gate an owner and evidence

Each gate produces its own evidence

Under which conditions does RP-session acceptance reach an API action?

Two reality checks

The OP session is true but the RP local session expired. Is the selected API request sent?

Is the foreign-resource branch a login failure or an object-permission failure?

Why are iss/sub binding, a renewed session identifier and state-changing CSRF policy three separate decisions in modern login?

Sources and scope