✳ Field lesson IF1 / 10 min

Who holds the ticket, and what does it open?

Map the four OAuth roles, tell an access ticket from a sign-in, and treat scope and audience as privilege limits.

identityoauthfederationauthorization

What you’ll be able to do

  • Name the resource owner, client, authorization server, and resource server for one Harbor Mail grant.
  • Sort an access token from a case that still needs an authentication assertion.
  • State which grants modern practice keeps, and which OAuth 2.1 and RFC 9700 set aside.
  • Use scope and audience as limits on what the ticket may do and where it may be accepted.

The button worked. What did Harbor Mail learn?

Harbor Mail shows “Sign in with Riverstone.” Sam clicks it, the page returns to the inbox, and the session looks fine. Maya’s first questions are small. Did Harbor Mail learn Sam’s Riverstone password? What can the API token in that session actually reach?

F4 already split authentication from authorization. This lesson practices that split on a delegated ticket. The glossary entries for OAuth, federation, and single sign-on stay the short definitions. Read them if a word is new. Do not treat a green button as a finished trust review.

Four roles, one ticket

OAuth 2.1 is an Internet-Draft, draft-ietf-oauth-v2-1-16, published 3 September 2026 and set to expire 7 March 2027. It is Standards Track work in progress. It is not an RFC. The draft consolidates OAuth 2.0 with current best practice. Section 1.1 names the same four roles as RFC 6749.

The resource owner is the party who can grant access, often Sam for one mailbox. The client is the application asking to act, here Harbor Mail. The authorization server is Riverstone IdP when it issues the ticket. The resource server is the API that accepts the ticket and serves mail. Harbor Mail can hold a ticket without ever seeing Sam’s password.

  • Resource owner: who may grant access to the protected thing.
  • Client: the app that asks for and then presents the ticket.
  • Authorization server: the issuer that mints the access token.
  • Resource server: the API that accepts the token and returns the resource.

An access token is not a sign-in

The OAuth 2.1 draft’s introduction treats the access token as delegated access attributes. It is authorization to do something limited. It is not proof that a particular human is present. OpenID Connect is the identity layer people add when they need that proof. A Harbor Mail screen that says “signed in” can still be only an access ticket.

Grant names, at literacy level: the authorization code grant is the one to prefer for a person using a browser. A refresh token asks for a new access token later. Client credentials let a service call an API as itself, with no person in the chair. The Implicit grant and the Resource Owner Password Credentials grant are removed in the OAuth 2.1 draft. RFC 9700, OAuth 2.0 Security Best Current Practice, BCP 240, January 2025, says those grants must not be used. This lesson does not walk the wire protocol.

Scope and audience keep the ticket small

RFC 9700 section 2.3 treats scope and audience as ways to restrict privilege. Scope names the kind of access requested, such as read one mailbox. Audience names who may accept the token. A token minted for Harbor Mail’s mail API must fail at a different API, even if the signature checks out.

A consent screen that says “read contacts” is a request Sam saw. It is not the same fact as the token the authorization server issued, and it is not the same fact as what the resource server enforces. Brief #4’s SaaS consent exercise on Harborline judges the credential that was issued. This path asks who issued it, who presents it, and which API may honor it.

Exit ticket: what the authorization server, the client, and the resource server prove.
RoleWhat it can proveWhat it does not prove
Authorization serverIt issued this access token to this client, for these scopes and this audience, until expiry.Which human is at the keyboard, or that Harbor Mail may do every mail action.
Client (Harbor Mail)It holds a ticket it can present to the resource server.Sam’s password, or that the ticket is a login proof.
Resource serverIt accepted or rejected the ticket for one action on one API.That a successful call identified a person, or authorized a second API.

CHECK YOUR JUDGMENT

Three Harbor Mail events follow “Sign in with Riverstone.” Sort them.

NEXT FIELD LESSON

ID Token and SAML assertion are claims, not blank admin passes

↗

Find your next idea.

Tip: press / to open search. Escape closes this window.