Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
Authentication (authn) verifies who a user is. Authorization (authz) determines they can do. Getting these right is non-negotiable -- a flaw in either can expose user data, enable privilege escalation, or bring regulatory consequences. This skill covers the major authentication flows, token formats, authorization models, multi-tenancy patterns, and security headers needed to build secure backend systems.
what
OAuth 2.0 Flows
Authorization Code + PKCE (Recommended for Most Apps)
The most secure flow for user-facing applications (SPAs, mobile apps, server-rendered apps). PKCE (Proof Key for Code Exchange) prevents authorization code interception attacks.
Client generates a random code_verifier and derives code_challenge = SHA256(code_verifier).
Client redirects user to authorization server with code_challenge.
User authenticates and consents. Authorization server redirects back with an authorization code.
Client exchanges the code + code_verifier for tokens. Server verifies SHA256(code_verifier) == code_challenge.
Client uses the access token to call APIs.
Client Credentials (Machine-to-Machine)
For service-to-service communication where no user is involved.
Service A ──POST /token──> Authorization Server
client_id +
client_secret
grant_type=client_credentials
Service A <──access_token── Authorization Server
Service A ──Bearer token──> Service B
Use when: Backend services authenticate to each other. No user context needed.
Device Code (TV / IoT / CLI)
For devices with limited input capability.
1. Device requests a device code and user code from auth server
2. Device displays: "Go to https://auth.example.com/device and enter code: ABCD-1234"
3. User visits URL on their phone/laptop, enters code, authenticates
4. Device polls auth server until user completes authentication
5. Auth server returns access token to device
OpenID Connect (OIDC)
OIDC is an identity layer built on top of OAuth 2.0. It adds:
Component
Purpose
ID Token
A JWT containing user identity claims (sub, email, name) -- proves who the user is
UserInfo Endpoint
GET /userinfo returns additional user profile claims
Discovery
GET /.well-known/openid-configuration returns all endpoint URLs, supported scopes, signing algorithms
Standard Scopes
openid (required), profile, email, address, phone
Key distinction: OAuth 2.0 alone is for authorization (access to resources). OIDC adds authentication (identity of the user).
Refresh token rotation issues a new refresh token with every access token refresh. If a refresh token is used twice, the server assumes the original was stolen and revokes the entire token family.
1. Client sends refresh_token_v1 → Server returns access_token + refresh_token_v2
2. Client sends refresh_token_v2 → Server returns access_token + refresh_token_v3
3. Attacker sends refresh_token_v1 → Server detects reuse → revokes ALL tokens for user
Session-Based Authentication
Server-Side Sessions
1. User submits credentials
2. Server validates, creates session record (in DB or Redis)
3. Server sends session ID in a cookie
4. Client sends cookie with every request
5. Server looks up session by ID, retrieves user context
Cookie Security
Attribute
Purpose
Recommendation
HttpOnly
Prevents JavaScript access (XSS mitigation)
Always set
Secure
Cookie sent only over HTTPS
Always set in production
SameSite=Lax
Mitigates CSRF for top-level navigations
Default for most apps
SameSite=Strict
Cookie never sent cross-site
For sensitive operations
Path=/
Scope the cookie to a path
Set appropriately
Max-Age / Expires
Session duration
Match your session TTL
CSRF Protection
SameSite cookies (Lax or Strict) -- primary defense in modern browsers.
Synchronizer Token Pattern -- server generates a random token, embeds in forms, validates on POST.
Double Submit Cookie -- CSRF token in both a cookie and a request header; server verifies they match.
API Key Authentication
Appropriate for:
Server-to-server communication where OAuth is overkill.
Public APIs with usage-based billing (keys identify the caller for rate limiting and billing).
Development/testing environments.
Not appropriate for: User-facing authentication (API keys cannot represent user identity or consent).
Best practices:
Treat API keys as secrets. Hash them in storage (like passwords).
Support key rotation: allow multiple active keys per client.
Include the key in a header (X-API-Key or Authorization: Bearer), never in the URL.
Scope keys to specific permissions and rate limits.
RBAC (Role-Based Access Control)
Users are assigned roles; roles are granted permissions. Users inherit the permissions of their assigned roles.
PERMIT action=read ON resource=document
WHERE subject.clearance_level >= resource.classification
AND subject.department == resource.department
AND environment.time BETWEEN 08:00 AND 18:00
Best for: Complex authorization requirements where RBAC role explosion becomes unmanageable (e.g., healthcare, government, multi-tenant SaaS with granular permissions).
Multi-Tenancy Patterns
Pattern
Isolation Level
Complexity
Cost
Shared database, shared schema
Row-level (tenant_id column)
Low
Lowest
Shared database, schema-per-tenant
Schema-level
Medium
Medium
Database-per-tenant
Full database isolation
High
Highest
Row-Level Security (Shared Schema)
-- PostgreSQL Row-Level SecurityALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.current_tenant')::uuid);
-- Set tenant context per requestSET app.current_tenant ='org_acme';
SELECT*FROM orders; -- only returns org_acme's orders
Decision heuristic:
Shared schema + RLS for most SaaS applications (simplest, cost-effective, sufficient isolation).
Schema-per-tenant when tenants need custom schema extensions or stronger isolation without separate databases.
Database-per-tenant when regulatory, compliance, or contractual requirements mandate full data isolation (e.g., healthcare, finance, government).
Identity Providers
Provider
Type
Best For
Auth0
Managed (Okta)
SaaS apps, rapid development, extensive social login support
Microsoft Entra ID (Azure AD)
Managed (Microsoft)
Enterprise apps, Microsoft ecosystem, B2B federation
Amazon Cognito
Managed (AWS)
AWS-native apps, user pools + federated identity
Keycloak
Open-source (self-hosted)
Full control, on-premises, custom requirements
Firebase Auth
Managed (Google)
Mobile-first apps, Google ecosystem, quick prototyping
Recommendation: Use a managed identity provider unless you have strong requirements for self-hosting. Building authentication from scratch is a security liability.
Security Headers
Header
Purpose
Recommended Value
CORS (Access-Control-Allow-Origin)
Controls which origins can call your API
Explicit allowlist (never * with credentials)
Content-Security-Policy (CSP)
Controls what content the browser can load/execute
default-src 'self'; script-src 'self' (customize per app)
Strict-Transport-Security (HSTS)
Forces HTTPS for all future requests
max-age=31536000; includeSubDomains; preload
Referrer-Policy
Controls how much referrer info is sent
strict-origin-when-cross-origin
X-Content-Type-Options
Prevents MIME type sniffing
nosniff
X-Frame-Options
Prevents clickjacking via iframes
DENY or SAMEORIGIN
Permissions-Policy
Controls browser features (camera, mic, geolocation)
Never use Access-Control-Allow-Origin: * when Access-Control-Allow-Credentials: true.
Maintain an explicit allowlist of trusted origins.
Set Access-Control-Max-Age to reduce preflight request overhead.
Best Practices
Use a managed identity provider (Auth0, Entra ID, Cognito, Keycloak) instead of building authentication from scratch. Authentication is a security-critical function where the cost of getting it wrong is severe.
Always use PKCE with the Authorization Code flow -- even for server-side apps. It adds security with no meaningful cost.
Keep access token lifetimes short (5-15 minutes). Use refresh tokens for longer sessions.
Check permissions, not roles, in your authorization code. This makes RBAC more granular and decouples business logic from role definitions.
Implement row-level security or tenant-scoped queries as a defense-in-depth measure -- never rely solely on application-level tenant filtering.
Set all security headers from day one. Adding HSTS, CSP, and CORS retroactively often breaks existing functionality.
Store secrets (API keys, client secrets, signing keys) in a secrets manager (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault), never in code or environment variables in plain text.
Rotate signing keys and refresh tokens regularly. Implement token family revocation for refresh token reuse detection.
