OAuth Roles: Client Resource Owner AS
Four roles, one trust story — map them on 127.0.0.1:8814.
Visual · oauth_roles
Resource owner, client, authorization server, resource server. 127.0.0.1:8814.
OAuth is delegation with named roles — not a license to build fake login pages.
OAuth 2.0 separates the resource owner (user), client (app), authorization server (issues tokens), and resource server (API). Confusion among roles is how phishing kits pretend to be the AS. Cyberlium teaches names and trust boundaries on YOUR lab — never impostor consent screens aimed at humans. Dest 127.0.0.1:8814. Next: OAuth Flows Named.
1. Name the four roles without mixing them
Resource owner grants. Client requests. Authorization server authenticates the owner and issues tokens. Resource server accepts access tokens and serves data.
Your teaching API on 8814 may play resource server; a tiny lab AS may issue tokens. Both stay on 127.0.0.1.
Command guide
Try these commands — Name the four roles without mixing them
═══ TOOLS & WEBSITES ═══ Browse / read these (authorized learning only — stay in YOUR lab / program scope)
OAuth 2.0 roles — https://oauth.net/2/ (resource owner, client, auth server) Auth0 flows — https://auth0.com/docs/get-started/authentication-and-authorization-flow
═══ INSTALL ═══
Linux (Debian/Ubuntu):
Command — copy this
sudo apt install curl
macOS: Built-in
Windows: Built-in (PowerShell: Invoke-WebRequest)
═══ LINUX / macOS ═══
SAFE demo: query params visible to server (httpbin is intentional practice)
Command — copy this
curl -sS "https://httpbin.org/get?client_id=lab-client&response_type=code&scope=openid" | jq '.args'
curl -sS -o /dev/null -w "httpbin GET %{http_code}
" "https://httpbin.org/get?state=lab-csrf-token"Primary tools to practice this lesson: curl. Reference sites: OAuth 2.0 roles (https://oauth.net/2/); Auth0 flows (https://auth0.com/docs/get-started/authentication-and-authorization-flow). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Delegation is not password sharing
OAuth exists so the client does not store the owner’s password for the AS. If a “kit” asks users to type passwords into the client directly while painting the AS logo, that is phishing theater — refuse it.
Write a one-line refusal: no fake Google/GitHub login pages in this course.
3. Ethics wall
Do not register OAuth apps against providers to harvest classmates. Do not run reverse proxies that steal auth codes on café Wi-Fi.
Ship a roles diagram in text. Quiz will ask who issues tokens.
4. What you ship: a four-role map and a phishing-kit refusal
Roles named. AS vs RS clear. Refusal of fake login kits. Dest 127.0.0.1:8814. DEMO GATE.
5. What you record before the next lesson
Date. Roles note. NEVER phishing OAuth. File t13-m05-l01-oauth-roles.txt chmod 600.
6. Wrong vs right: stranger APIs vs literacy on systems you own
Worked failure — same API word, opposite target. Right never needs a live shop or classmate token.
- Wrong: Deploy a cloned Google login. Steal auth codes on LAN. hydra the AS.
- Right: Roles map + refusal. Next: OAuth Flows Named.
Mission: name OAuth roles without impostors
1) / STOP if router. 2) Write four roles and who issues tokens. 3) Write phishing-kit refusal. Never fake consent pages.
Stuck? Ask Cyberlium AI Mentor
Ask Mentor for a roles diagram check — not for phishing page HTML.
APPLY: Who issues access tokens in OAuth?
APPLY: True or False: A fake Google login page is acceptable “OAuth practice.”
APPLY: Module 5 teaching port?
OAuth Flows Named
Part of API Security with AI — OAuth and OIDC Literacy.
OIDC ID Token Literacy
Part of API Security with AI — OAuth and OIDC Literacy.
OAuth Lab — Roles and Token Shape
Part of API Security with AI — OAuth and OIDC Literacy.