OAuth

Read E8 · cal.read

1. Context. Exporter C7 holds active bearer access token AT9. Mina delegated cal.read for calendar C17 through CalendarAuth. The client asks CalendarAPI for the existing event E8 without receiving Mina’s password. A completed code-with-PKCE flow, approved cal.read/C17 grant, and receipt are assumed. Mina owns C17; C7 is the client, CalendarAuth the authorization server, CalendarAPI the resource server. AT9 safely labels an opaque, API-restricted token. Issuance, consent, refresh, and revocation are outside this view; C7 gets no owner password.
2. Request. The client sends its API request with AT9 in the Authorization header over HTTPS. CalendarAPI shows receipt after arrival. No response or new permission has reached the client yet. GET /cal/C17/events/E8 has no body. POST /cal/C17/events carries {"event":"E9"}, its complete synthetic JSON body. Both send the same opaque bearer token in Authorization over assumed working HTTPS with valid syntax. No raw credential is shown or logged. A requested scope adds no grant.
3. Check. CalendarAPI finds AT9 active and intended for this API, then checks cal.read and the C17 resource grant. Both permit reading E8. A 200 representation is prepared; the client has not received it yet. Fresh authenticated TLS introspection at CalendarAuth supplies active status, issuer, API audience, expiry, scope, and an agreed C17-grant extension. Token checks pass in both tests; no JWT signature is implied. The API checks the calendar grant and maps read/create to cal.read/cal.write; only read is granted. Bearer possession cannot prove C7 is the caller; sender constraints need additional enforced proof.
4. Response. The 200 response travels back to the client with a synthetic E8 copy. After arrival, the client shows E8 received. The original stays in CalendarAPI; delegated reading has not become calendar-writing authority. The complete 200 OK application/json body is {"event":"E8"}. The original remains. One delegated read establishes neither client sign-in nor other actions. An ID token serves a different purpose; the linked field lesson teaches the full OAuth exchange.

Create E9 · cal.write

1. Context. Exporter C7 holds the same active bearer access token AT9. Mina delegated cal.read for calendar C17 through CalendarAuth. The client now asks to create E9, which requires cal.write. A completed code-with-PKCE flow, approved cal.read/C17 grant, and receipt are assumed. Mina owns C17; C7 is the client, CalendarAuth the authorization server, CalendarAPI the resource server. AT9 safely labels an opaque, API-restricted token. Issuance, consent, refresh, and revocation are outside this view; C7 gets no owner password.
2. Request. The client sends its API request with AT9 in the Authorization header over HTTPS. CalendarAPI shows receipt after arrival. No response or new permission has reached the client yet. GET /cal/C17/events/E8 has no body. POST /cal/C17/events carries {"event":"E9"}, its complete synthetic JSON body. Both send the same opaque bearer token in Authorization over assumed working HTTPS with valid syntax. No raw credential is shown or logged. A requested scope adds no grant.
3. Check. CalendarAPI finds AT9 active and intended for this API. It still refuses the create operation: the granted cal.read scope does not include cal.write. E9 is not created; AT9 remains valid. Fresh authenticated TLS introspection at CalendarAuth supplies active status, issuer, API audience, expiry, scope, and an agreed C17-grant extension. Token checks pass in both tests; no JWT signature is implied. The API checks the calendar grant and maps read/create to cal.read/cal.write; only read is granted. Bearer possession cannot prove C7 is the caller; sender constraints need additional enforced proof.
4. Response. The refusal response travels back to the client. After arrival, it shows 403 Forbidden with insufficient_scope. No E9 was created. The original E8 and AT9’s read grant remain unchanged. The bodyless 403 Forbidden includes WWW-Authenticate: Bearer error="insufficient_scope". No E9 is created; E8, AT9, cal.read, and working transport remain intact. The delivered refusal concerns this operation, not an invalid token or failed owner sign-in.

This shows API use after token issuance, not a complete OAuth exchange. AT9 is a reference, not a usable token. An access token is not a human sign-in statement or proof of the client presenting a bearer credential.

Flow references: RFC 6749 - OAuth roles and resource access · RFC 6750 - bearer tokens and insufficient scope · RFC 7662 - opaque-token introspection · RFC 9700 - token audience and sender constraints