OAUTH AUTHORIZATION-CODE WALKTHROUGH — ORIGINAL FICTIONAL EXERCISE
Checked 2026-10-28.
https://showmeyoursaas.com/articles/oauth/
Reserved .test domains and symbolic placeholders are not working endpoints or tokens.
No request, user authorization, token exchange, or API action occurs in this exercise.

ACTORS
Resource owner: fictional person permitting access to their export metadata.
Client: QueueNote at https://client.example.test
Authorization service: https://auth.example.test
Protected resource API: https://api.example.test
Requested scope: exports:read (invented; real scopes are provider-defined).
Client identifier: fictional-client (not a secret or a registered application).

CONNECTION TRANSACTION
Create a fresh PKCE verifier and S256 challenge with a maintained integration.
Associate the transaction with the correct local session and intended workspace.
Record the actual registered redirect URI and requested permission.
The local lab demonstrates the calculation only; it creates no session or grant.

ILLUSTRATIVE AUTHORIZATION FIELDS
response_type: code
client_id: fictional-client
redirect_uri: https://client.example.test/oauth/callback
scope: exports:read
code_challenge: PUBLIC_CHALLENGE_FROM_THIS_TRANSACTION
code_challenge_method: S256
state: OPAQUE_TRANSACTION_VALUE_BOUND_TO_SESSION
These are symbolic fields, not a copy-paste authorization URL.

APPROVAL PATH
The browser interacts with the authorization service.
After a valid approval, the browser returns to the registered callback with a code and relevant transaction response.
The client must validate association with the correct connection attempt and user context.
The client exchanges the code at the token endpoint with the required verifier, redirect information and applicable client authentication.
A valid code exchange can produce tokens under the provider's actual contract.
The code is not the access token.

DENIAL / FAILURE PATHS
Denial: preserve disconnected state and explain the next permitted step.
Expired or replayed code: follow the provider's documented error path.
Mismatched transaction: do not attach the remote connection to a guessed session or workspace.
Invalid verifier: the PKCE proof must not be accepted.
Reduced scope: inspect the actual grant; do not assume requested scope was granted.
Revocation: stop relying on stale local connected status.
No complete callback validator or authorization server is implemented here.

TOKEN AND IDENTITY REVIEW
Who owns token storage and refresh?
Which architecture protects secrets and tokens appropriately?
What must never appear in a public bundle, broad log or support document?
Which API audience and account does the token serve?
How is the permitted local workspace relationship established?
Is OpenID Connect used for sign-in, and which maintained integration validates that protocol?
An OAuth access token is not an interchangeable ID token.
Disconnecting locally and revoking remotely are distinct operations.

BLANK IMPLEMENTATION REVIEW
Actual provider and current documentation:
Client type:
Registered redirect:
Requested and granted scopes:
Maintained SDK/integration:
Transaction/session binding:
PKCE support and S256:
Client authentication, when applicable:
Token storage / refresh / revocation:
Error and reduced-scope behavior:
Queued work after disconnect:
Authorized test plan:
Verified results:
Unresolved questions:

PRIMARY REFERENCES
https://www.rfc-editor.org/rfc/rfc6749.html
https://www.rfc-editor.org/rfc/rfc7636.html
https://www.rfc-editor.org/rfc/rfc9700.html
https://openid.net/specs/openid-connect-core-1_0.html