YanoSec
Progress0 of 152 lessons complete

Course / 09 Web security / Lesson 26 of 28

OAuth

Estimated time: 18 min reading · 12 min activity

A notes-printing app should be able to read approved notes without receiving the user's password. OAuth 2.0 is a framework for delegated authorization: a resource owner permits a client limited access to a resource. A scope describes a permission such as notes.read, rather than a general sign-in identity.

The four roles are the resource owner, who controls the resource; the client, which wants access; the authorization server, which issues access tokens after authorization; and the resource server, which serves the protected data. Here Ada, notes-printer, club-auth and the notes app fill those roles. An access token represents limited access that the resource server still needs to validate.

Before you begin

Estimated time
18 min reading, 12 min activity. Setup and optional practice may take longer.
Where you work
Read the original fictional source, object tables, token claims and policy models in any current desktop or mobile browser. No loader, template engine, provider registration, service or network request is required.
Without a lab
Follow the printed data through each stated rule on paper. Record the decision, its supporting fact and a limit, then compare with the guided rubric. Model reasoning does not establish a live tool result. Reading works without JavaScript. Checking requires JavaScript and a secure context; saving also requires usable storage.

After this lesson you can:

  • Name the resource owner, the client, the authorization server, and the resource server.
  • Follow notes.read from Ada's approval to the notes app.

01Example

Use a fresh fictional calendar app to learn the four roles. Then place the existing notes actors in the guided diagram.

Resource owner: Bea
Client: calendar-view
Authorization server: schedule-auth
Resource server: calendar service
Approved scope: calendar.read
The client receives limited access rather than Bea's password.
Fictional flow; no registration or token issuance.

02A token is not a password

In the authorization-code flow, the client sends the browser to the authorization server, receives a short-lived code through a registered redirect and redeems it for a token. A redirect URI is the registered address for that response. state links the response to the browser interaction that started it. PKCE, Proof Key for Code Exchange, binds code redemption to a secret verifier created by that client for this flow.

Use exact registered redirects, appropriate response binding and PKCE according to current OAuth security guidance. RFC 9700 requires PKCE for public clients and prohibits the resource-owner password grant. The loopback callback in this card is a fictional local/native-client teaching case, not a production redirect recommendation. No provider was registered. OAuth access alone is not a login protocol; OpenID Connect adds identity information for that purpose.

Place the four OAuth roles on a fictional local flow, and keep a scoped token distinct from a login.Model. A teaching model drawn by hand. It shows the idea, not real tool output.

Read the full explanation below.

Playback is optional. Step through at your own pace.

Bea, resource ownerPassword handoff is not part of this model.
calendar-view, clientcalendar-view receives limited access rather than Bea’s password.
schedule-auth, authorization serverFictional trusted role; no actual issuance.
Calendar service, resource serverCalendar service is the resource server; no real service was contacted.
  1. Bea, resource owner → schedule-auth, authorization serverApprove calendar.readFictional scope approval; no registration occurs.
  2. schedule-auth, authorization server → calendar-view, clientLimited accessClient receives limited access rather than Bea's password; no token issued here.
  3. calendar-view, client → Calendar service, resource serverWould use calendar.readThe resource service applies its own access checks.
Approved scope calendar.read
permitted-model
Resource access check
pending

Bea approves the limited calendar.read scope.

Follow the explanation

  1. Bea approves the limited calendar.read scope.
  2. The client receives limited access and would use it at the calendar service.
Read every state and value

1. Bea approves the limited calendar.read scope.

Messages shown
Approve calendar.read
Current message
Approve calendar.read
Policy decisions
Status: permitted-model · Status: pending
Participant roles
Actor: Bea, resource owner; Text: Password handoff is not part of this model. · Actor: calendar-view, client; Text: calendar-view receives limited access rather than Bea’s password. · Actor: schedule-auth, authorization server; Text: Fictional trusted role; no actual issuance. · Actor: Calendar service, resource server; Text: Calendar service is the resource server; no real service was contacted.

2. The client receives limited access and would use it at the calendar service.

Messages shown
Approve calendar.read · Limited access · Would use calendar.read
Current message
Would use calendar.read
Policy decisions
Status: permitted-model · Status: not-established
Participant roles
Actor: Bea, resource owner; Text: Resource owner approving calendar.read. · Actor: calendar-view, client; Text: Limited scope is calendar.read. · Actor: schedule-auth, authorization server; Text: schedule-auth is the fictional authorization server. · Actor: Calendar service, resource server; Text: A real resource-policy outcome is not supplied.
OAuth delegates scoped access; this fictional flow issues no token and does not establish a login.

03Place the roles

Read the evidence before comparing with the activity rubric. Do not register a provider.

Three software roles in an OAuth flow
Three software roles in an OAuth flowModel. A teaching model drawn by hand. It shows the idea, not real tool output.The Client box is the application asking to use an API. The Authorization box is the server that issues access tokens. Notes is the resource server providing the protected API and checking access to its resources. The resource owner whose permission is involved is a separate role, explained in the lesson; this three-box schematic does not show every step or prove that a flow is secure.

Download the actor diagram

Fictional local/native-client flow. No provider was registered. No token was issued.

Resource owner: Ada
Client: notes-printer, running on the same machine
Authorization server: club-auth
Resource server: the notes app
Scope: notes.read
Registered redirect: http://127.0.0.1:8000/callback
A different path is not the registered redirect.

The owner approves notes.read at club-auth.
The client receives a code, then a token, from club-auth.
The notes app sees the token, not Ada's password.
state is a one-time value bound to the browser that started this flow.
PKCE binds code redemption to a secret verifier created by this client for this flow.
RFC 9700 says public clients must use PKCE, and says the resource-owner password grant must not be used. This card uses neither that grant nor the implicit grant.

Download the fictional flow

  1. Write the four role names beside Ada, notes-printer, club-auth, and the notes app.
  2. Write what the notes app sees, and what it does not see.
  3. Check: the notes app sees the token and does not see Ada's password. The scope is notes.read. The redirect is the loopback callback.
  4. Stop. Do not create a real client registration.

04Optional challenge

Say what state is for and what PKCE is for on this card. The rubric is: state binds the browser that started the flow, and PKCE checks a verifier when the code is redeemed. About ten minutes.

05Fresh cases for the checks

Use these fictional cases for the checks below. They have different inputs from the worked examples. Read them here or make notes; no installation or external service is needed.

Delegation case A: new fictional flowOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Resource owner Ivo approves library.read.
Client shelf-view asks for that limited access.
Authorization server reading-auth returns a short-lived code and later an access token to shelf-view.
Resource server library-api receives the access token for protected reads, never Ivo’s password.
No provider registration, code or token issuance occurred.

Delegation case B: independent redirect/scope policyOwned fixture. An original file made for this course. Follow the activity's instructions in your own lab.

Registered redirect: http://127.0.0.1:8000/return
Approved permission: library.read only.
P: same registered redirect and library.read.
Q: redirect http://127.0.0.1:8000/other and library.read.
R: registered redirect but library.write requested as though already approved.
This is a fictional local/native-client card, not a production redirect recommendation.

06Explain your evidence

Optional written self-check: explain one decision using the supplied case. No tool run is required.

Check your explanation: map all four actors; trace code/token recipients and approved scope; keep the password outside the delegated API flow; compare exact registered redirects and permissions; distinguish access delegation from identity sign-in.

07Common mistakes

If you send Ada's password to the notes app, you skipped the card. The app sees the token.

If you use a different callback path, it is not the registered redirect.

If you treat the flow as a finished login protocol, OpenID Connect is the layer the introduction of RFC 9700 names for federated login.

References