Identity and callbacks
After sign-in returns, identify the original login
A browser can hold several sign-in windows and change sessions while a callback is in flight. Account retains the original intent, browser binding and one-use proof; the business application then establishes its own session.
Sign-in starts with one bounded original intent
The business backend begins login with the issuer, client, exact redirect, state, nonce and PKCE proof retained together. A browser selector locates that original record; possession does not establish account identity or CSRF authority. Account owns authentication, while the application retains its login transaction and resulting session.
Callback handling checks that binding before interpreting a code, confirmed rejection or uncertain outcome. A success page or URL marker cannot issue a session. The design separates callback admission, token verification and application-session commitment so that navigation carries no extra authority.
Two windows share a browser, not one login result
Suppose one browser opens login for application A and then application B. They may share a browser-binding cookie, but retain separate intents, clients, redirects and state. A’s callback completes only A. Refreshing a consumed, expired or mismatched selector cannot fall through to B’s context.
Two successful logins can each create an Account session. The cookie retained by the browser follows actual response ordering; that does not revoke the other session. Logout also needs its original session binding so a delayed action cannot end a newer login. Yaoledge compares the expected session identity at its product boundary.
| Object | Role | Does not grant |
|---|---|---|
| Login selector | Locate one original intent | Account identity or a fresh login opportunity |
| Browser binding | Bind the initiating browser | Authentication by itself |
| Authenticated session | Use an account within its own lifetime and restrictions | Consume proof for another intent |
Claim the original flow before one external exchange
An external-provider callback first checks its fixed route, parameters, original state, initiating browser or credential-addition session, and expiry. Duplicate parameters, mixed code and error values, a wrong provider or mismatched browser binding reject before contacting the provider.
For a code-bearing flow, Account claims the active record in a short transaction. Only a definitively committed claimant may exchange the code and read identity; an uncertain claim sends nothing. Final storage rechecks the original intent, restrictions, expiry and identity ownership, reusing verified evidence across storage retries without another exchange.
Admit the original binding
Decode callback parameters once and match the original browser or addition session.
Claim the active flow
Dispatch the provider exchange only after the claim is definitively committed.
Commit the identity result
Recheck the original context and commit using the same verified evidence.
Identity and access credentials have different recipients
The application uses the SDK to validate the complete login response: signature, issuer, client audience, original nonce, validity interval and account identity. Only then is VerifiedLogin available for creating an application session. A login_result navigation marker supplies feedback, not a replacement for a current-session query.
The identity system also issues credentials for separate purposes. OIDC ID Tokens, UserInfo access tokens and Transact machine grants have different audiences and permissions. A shared issuer does not make them interchangeable; registration and the actual receiver constrain their use.
| Credential | Selected purpose | Receiver checks |
|---|---|---|
| OIDC ID Token | Establish identity for the original client | Issuer, audience, nonce and lifetime |
| UserInfo access token | Read UserInfo for the original account | Resource, account, client and lifetime |
| Transact machine grant | Use registered transaction API scopes | Resource audience, client and exact scopes |
Make a fresh start explicit after an uncertain result
If a provider exchange was sent and its reply is lost, revisiting the callback cannot repeat it. An uncertain final session write should remain unknown and lead to an explicit new login from the original application. The new intent has its own proof; the old flow does not transfer to it.
Credential addition has a different continuation: inspect bindings for the known original account under current authority. Readback must remain subject-bound rather than treating a replacement browser session’s account as the original result. Adding a credential creates neither a new account nor a replacement login session.
Interpret a result after establishing its binding
Establish the source, account and original intent before selecting the next action.
An old callback grants no automatic retry
A consumed or uncertain provider exchange is not resent on refresh.
Verify the binding, not only the sign-in button
The design calls for distinguishable clients, accounts and callback ordering with independent expectations. These expose cross-window confusion, duplicate provider exchanges and delayed logout. The following are verification objectives, not claims of completed deployment experiments.
| Scenario | What to observe | Boundary retained |
|---|---|---|
| Two interleaved logins | Each client, redirect and state | No adoption of another intent |
| Two callbacks race for one state | Actual provider dispatch count | Only the definite claimant sends |
| Lose the reply after dispatch | No new exchange from the old callback | Uncertainty stays distinct |
| Replace the session before logout | Expected identity and current cookie | Do not revoke the replacement |