OAuth Roles
Resource owner, client, authorization server, resource server — literacy only, no phishing kits.
Visual · t17_oauth_roles
OAuth delegates access — know the roles before reading a flow diagram. Original Cyberlium.
OAuth is delegation plumbing — not a license to clone login pages on the public internet.
OAuth 2.0 roles: resource owner (user), client (app requesting access), authorization server (issues tokens), resource server (API holding data). Common flows (authorization code with PKCE for public clients) exchange codes for tokens under HTTPS. Learn redirect URI validation, scope minimization, and state parameter literacy on paper and $REPO lab integrations you register yourself. NEVER build fake OAuth consent pages, phishing kits, or token stealers targeting real providers or classmates — that is fraud, not secure coding homework.
1. Four roles
Resource owner approves scope. Client receives limited token. Authorization server mints tokens. Resource server validates them.
Map each role to a concrete example in your lab (GitHub OAuth app on localhost).
Command guide
Try these commands — Four roles
═══ LINUX / BASH (Network & Reconnaissance Audit) ═══
Scan target host for open ports and service version signatures
Command — copy this
nmap -sS -sV -p 80,443,8080 -Pn ${LAB_HOST:-127.0.0.1}DNS and WHOIS reconnaissance on authorized domain
Command — copy this
dig +short A target.local dig +short MX target.local whois target.local 2>/dev/null | grep -iE "(Registrar|Creation Date|Name Server)" | head -6
Inspect HTTP headers for technology stack fingerprinting
Command — copy this
curl -s -I "http://${LAB_HOST:-127.0.0.1}:8080" | grep -iE "(Server|X-Powered-By|Set-Cookie|Content-Security-Policy)"Primary tools to practice this lesson: python3, curl. Reference sites: OAuth 2.0 (https://oauth.net/2/); OWASP OAuth (https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html). Run every command in the box — install first, then the usage lines — only on YOUR lab / program scope.
2. Defender literacy
Redirect URI allowlists prevent code interception. State parameter binds request to session.
PKCE required for public/mobile clients — literacy for why code alone is insufficient.
3. Hard refusal
No phishing kits mimicking Google/Microsoft login for 'OAuth lab.'
No capturing authorization codes from users who did not consent in YOUR registered lab app.
4. What you ship: OAuth role map
Four roles defined + redirect URI + state notes + NEVER phishing kit sentence.
5. What you record before the next lesson
OAuth roles paragraph.
6. Wrong vs right: stranger apps vs YOUR repo
Worked failure — same MSF word, opposite target. Right never needs a café Wi-Fi or classmate laptop.
- Wrong: Deploy lookalike login page to harvest real provider tokens.
- Right: Name OAuth roles. Next: sessions lab.
Mission: OAuth literacy map
1) Define four OAuth roles in one line each. 2) Write why redirect URI must be allowlisted. 3) Write NEVER OAuth phishing kits.
Stuck? Ask Cyberlium AI Mentor
Ask Mentor: “Auth code + PKCE steps?”
APPLY: Authorization server:
APPLY: True or False: Fake OAuth login pages are course lab.
APPLY: state parameter helps: