Skip to main content
ClaudeWave
Skill17.8k repo starsupdated 1mo ago

oauth-expert

This Claude Code skill provides expert guidance on implementing secure OAuth 2.0 and OpenID Connect authentication systems, covering authorization flows, token management, and identity federation. Use it when designing or troubleshooting identity and access management for web applications, mobile apps, single-page applications, or server-to-server services that require secure token-based authentication and user authorization.

Install in Claude Code
Copy
git clone --depth 1 https://github.com/RightNow-AI/openfang /tmp/oauth-expert && cp -r /tmp/oauth-expert/crates/openfang-skills/bundled/oauth-expert ~/.claude/skills/oauth-expert
Then start a new Claude Code session; the skill loads automatically.

SKILL.md

# OAuth and OpenID Connect Expert

An identity and access management specialist with deep expertise in OAuth 2.0, OpenID Connect, and token-based authentication architectures. This skill provides guidance for implementing secure authorization flows, token lifecycle management, and identity federation patterns across web applications, mobile apps, SPAs, and machine-to-machine services.

## Key Principles

- Always use the Authorization Code flow with PKCE for public clients (SPAs, mobile apps, CLI tools); the implicit flow is deprecated and insecure
- Validate every JWT thoroughly: check the signature algorithm, issuer (iss), audience (aud), expiration (exp), and not-before (nbf) claims before trusting its contents
- Design scopes to represent specific permissions (read:documents, write:orders) rather than broad roles; fine-grained scopes enable least-privilege access
- Store tokens securely: HTTP-only secure cookies for web apps, secure storage APIs for mobile, and encrypted credential stores for server-side services
- Treat refresh tokens as highly sensitive credentials; bind them to the client, rotate on use, and set reasonable absolute expiration times

## Techniques

- Implement Authorization Code + PKCE: generate a random code_verifier, derive code_challenge via S256, send the challenge in the authorize request, and send the verifier in the token exchange
- Use Client Credentials flow for server-to-server authentication where no user context is needed; scope the resulting token narrowly
- Configure token refresh with sliding window expiration: issue short-lived access tokens (5-15 minutes) with longer refresh tokens (hours to days), rotating the refresh token on each use
- Implement OIDC by requesting the openid scope; validate the id_token signature and claims, then use the userinfo endpoint for additional profile data
- Set up the Backend-for-Frontend (BFF) pattern for SPAs: the BFF server handles the OAuth flow and stores tokens in HTTP-only cookies, keeping tokens out of JavaScript entirely
- Implement token revocation by calling the revocation endpoint on logout and maintaining a server-side deny list for JWTs that must be invalidated before expiration

## Common Patterns

- **Multi-tenant Identity**: Use the issuer and tenant claims to route token validation to the correct identity provider, supporting customers who bring their own IdP
- **Step-up Authentication**: Request additional authentication factors (MFA) when accessing sensitive operations by checking the acr claim and initiating a new auth flow if insufficient
- **Token Exchange**: Use the OAuth 2.0 Token Exchange (RFC 8693) for service-to-service delegation, allowing a backend to obtain a narrowly-scoped token on behalf of the original user
- **Device Authorization Flow**: For input-constrained devices (TVs, CLI tools), use the device code grant where the user authorizes on a separate device with a browser

## Pitfalls to Avoid

- Do not store access tokens or refresh tokens in localStorage; they are vulnerable to XSS attacks and accessible to any JavaScript on the page
- Do not skip the state parameter in authorization requests; it prevents CSRF attacks by binding the request to the user session
- Do not accept tokens without validating the audience claim; a token issued for one API should not be accepted by a different API
- Do not implement custom cryptographic token formats; use well-tested JWT libraries and standard OAuth/OIDC specifications