Skip to content
Back to skills

Oauth

ASecurity

Implement OAuth 2.0 and OpenID Connect flows securely.

  • 17 stars
  • 0 votes
  • 0 copies
  • 7 views
  • Added September 6, 2026
securityrustgogitapibackendsecurity

Works with

  • cli
  • api

Security analysis

A100/100

Pro scans all 2 files and shows the line behind each finding

Scanned September 6, 2026

npx -y skills add clawic/skills --skill oauth --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Oauth?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Oauth
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/clawic-oauth/badge)](https://www.skillsdirectory.com/skills/clawic-oauth)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: OAuth
slug: oauth
version: 1.0.0
description: Implement OAuth 2.0 and OpenID Connect flows securely.
homepage: https://clawic.com/skills/oauth
metadata:
  clawdbot:
    emoji: 🔑
    os:
    - linux
    - darwin
    - win32
    displayName: OAuth
---

## Flow Selection

- Authorization Code + PKCE: use for all clients—web apps, mobile, SPAs
- Client Credentials: service-to-service only—no user context
- Implicit flow: deprecated—don't use; was for SPAs before PKCE existed
- Device Code: for devices without browsers (TVs, CLIs)—user authorizes on separate device

## PKCE (Proof Key for Code Exchange)

- Required for public clients (SPAs, mobile), recommended for all
- Generate `code_verifier`: 43-128 char random string, stored client-side
- Send `code_challenge`: SHA256 hash of verifier, sent with auth request
- Token exchange includes `code_verifier`—server verifies against stored challenge
- Prevents authorization code interception—attacker can't use stolen code without verifier

## State Parameter

- Always include `state` in authorization request—prevents CSRF attacks
- Generate random, unguessable value; store in session before redirect
- Verify returned `state` matches stored value before processing callback
- Can also encode return URL or other context (encrypted or signed)

## Redirect URI Security

- Register exact redirect URIs—no wildcards, no open redirects
- Validate redirect_uri on both authorize and token endpoints
- Use HTTPS always—except localhost for development
- Path matching is exact—`/callback` ≠ `/callback/`

## Tokens

- Access token: short-lived (minutes to hour), used for API access
- Refresh token: longer-lived, used only at token endpoint for new access tokens
- ID token (OIDC): JWT with user identity claims—don't use for API authorization
- Don't send refresh tokens to resource servers—only to authorization server

## Scopes

- Request minimum scopes needed—users trust granular requests more
- Scope format varies: `openid profile email` (OIDC), `repo:read` (GitHub-style)
- Server may grant fewer scopes than requested—check token response
- `openid` scope required for OIDC—triggers ID token issuance

## OpenID Connect

- OIDC = OAuth 2.0 + identity layer—adds ID token and UserInfo endpoint
- ID token is JWT with `sub`, `iss`, `aud`, `exp` + profile claims
- Verify ID token signature before trusting claims
- `nonce` parameter prevents replay attacks—include in auth request, verify in ID token

## Security Checklist

- HTTPS everywhere—tokens in URLs must be protected in transit
- Validate `iss` and `aud` in tokens—prevents token confusion across services
- Bind authorization code to client—code usable only by requesting client
- Short authorization code lifetime (10 min max)—single use
- Implement token revocation for logout/security events

## Common Mistakes

- Using access token as identity proof—use ID token for authentication
- Storing tokens in localStorage—vulnerable to XSS; prefer httpOnly cookies or memory
- Not validating redirect_uri—allows open redirect attacks
- Accepting tokens from URL fragment in backend—fragment never reaches server
- Long-lived access tokens—use short access + refresh pattern

## Token Endpoints

- `/authorize`: user-facing, returns code via redirect
- `/token`: backend-to-backend, exchanges code for tokens; requires client auth for confidential clients
- `/userinfo` (OIDC): returns user profile claims; requires access token
- `/revoke`: invalidates tokens; accepts access or refresh token

## Client Types

- Confidential: can store secrets (backend apps)—uses client_secret
- Public: cannot store secrets (SPAs, mobile)—uses PKCE only
- Never embed client_secret in mobile apps or SPAs—it will be extracted

Files in this skill

  • SKILL.md3.7 KB
  • _meta.json162 B

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

View all in security →

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.