Initial commit - 611 cybersecurity skills across all subdomains

2026-07-17 21:19:40 +03:00 · 2026-02-25 10:47:44 +01:00
commit 22a7ab1462
1765 changed files with 280648 additions and 0 deletions
@@ -0,0 +1,52 @@
+# Standards and References - OAuth 2.0 Authorization Flow
+
+## Core OAuth Standards
+- **RFC 6749**: The OAuth 2.0 Authorization Framework
+  - https://datatracker.ietf.org/doc/html/rfc6749
+- **RFC 6750**: The OAuth 2.0 Authorization Framework: Bearer Token Usage
+  - https://datatracker.ietf.org/doc/html/rfc6750
+- **RFC 7636**: Proof Key for Code Exchange (PKCE)
+  - https://datatracker.ietf.org/doc/html/rfc7636
+- **RFC 9700**: OAuth 2.0 Security Best Current Practice
+  - https://datatracker.ietf.org/doc/html/rfc9700
+- **OAuth 2.1 Draft**: Consolidation of OAuth 2.0 with PKCE mandatory
+  - https://oauth.net/2.1/
+
+## Token Standards
+- **RFC 7519**: JSON Web Token (JWT)
+  - https://datatracker.ietf.org/doc/html/rfc7519
+- **RFC 7515**: JSON Web Signature (JWS)
+  - https://datatracker.ietf.org/doc/html/rfc7515
+- **RFC 9449**: OAuth 2.0 Demonstrating Proof of Possession (DPoP)
+  - https://datatracker.ietf.org/doc/html/rfc9449
+- **RFC 7009**: OAuth 2.0 Token Revocation
+  - https://datatracker.ietf.org/doc/html/rfc7009
+
+## OpenID Connect
+- **OpenID Connect Core 1.0**: Authentication layer on OAuth 2.0
+  - https://openid.net/specs/openid-connect-core-1_0.html
+- **OpenID Connect Discovery**: Provider metadata discovery
+  - https://openid.net/specs/openid-connect-discovery-1_0.html
+
+## Additional Grant Types
+- **RFC 8628**: OAuth 2.0 Device Authorization Grant
+  - https://datatracker.ietf.org/doc/html/rfc8628
+
+## NIST Standards
+- **NIST SP 800-63B**: Digital Identity Guidelines - Authentication
+- **NIST SP 800-53 Rev 5**:
+  - AC-3: Access Enforcement
+  - IA-5: Authenticator Management
+  - SC-13: Cryptographic Protection
+  - SC-23: Session Authenticity
+  - AU-3: Content of Audit Records
+
+## Implementation Guides
+- **Auth0 PKCE Guide**: https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce
+- **Microsoft OIDC Flow**: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth2-auth-code-flow
+- **Okta OAuth Express**: https://developer.okta.com/blog/2025/07/28/express-oauth-pkce
+- **PKCE Explained**: https://oauth.net/2/pkce/
+
+## Security References
+- **OWASP OAuth 2.0 Security**: Common vulnerabilities and mitigations
+- **OAuth Security Workshop**: Annual research on OAuth attack vectors
@@ -0,0 +1,123 @@
+# OAuth 2.0 Authorization Flow Workflows
+
+## Workflow 1: Authorization Code Flow with PKCE
+
+```
+Client                     Auth Server              Resource Server
+  |                            |                         |
+  |-- Generate code_verifier --|                         |
+  |-- Compute code_challenge --|                         |
+  |                            |                         |
+  |--- AuthZ Request --------->|                         |
+  |  (code_challenge, state)   |                         |
+  |                            |-- User Authenticates -->|
+  |                            |<- User Consents --------|
+  |<-- AuthZ Code + state -----|                         |
+  |                            |                         |
+  |--- Token Request --------->|                         |
+  |  (code + code_verifier)    |                         |
+  |<-- Access + Refresh Token--|                         |
+  |                            |                         |
+  |--- API Request (Bearer) ---|------------------------>|
+  |<-- API Response ---------- |<------------------------|
+```
+
+### Step-by-Step:
+1. Client generates `code_verifier`: random 43-128 char string (A-Z, a-z, 0-9, -._~)
+2. Client computes `code_challenge = BASE64URL(SHA256(code_verifier))`
+3. Client redirects to: `GET /authorize?response_type=code&client_id=xxx&redirect_uri=xxx&scope=xxx&state=RANDOM&code_challenge=xxx&code_challenge_method=S256`
+4. User authenticates and consents at authorization server
+5. Server redirects to: `redirect_uri?code=AUTH_CODE&state=RANDOM`
+6. Client validates state matches original
+7. Client exchanges code: `POST /token` with `grant_type=authorization_code&code=AUTH_CODE&code_verifier=xxx&redirect_uri=xxx`
+8. Server validates SHA256(code_verifier) matches stored code_challenge
+9. Server returns access_token, refresh_token, id_token (if OIDC)
+
+## Workflow 2: Client Credentials Flow (Machine-to-Machine)
+
+```
+Service A                  Auth Server              Service B (API)
+  |                            |                         |
+  |--- Token Request --------->|                         |
+  |  (client_id, secret, scope)|                         |
+  |<-- Access Token -----------|                         |
+  |                            |                         |
+  |--- API Request (Bearer) ---|------------------------>|
+  |<-- API Response ---------- |<------------------------|
+```
+
+### Step-by-Step:
+1. Service registers with auth server (client_id + client_secret)
+2. Service requests token: `POST /token` with `grant_type=client_credentials&scope=api:read`
+3. Auth server validates client credentials
+4. Auth server returns access_token (no refresh token, no user context)
+5. Service calls API with `Authorization: Bearer ACCESS_TOKEN`
+
+## Workflow 3: Token Refresh with Rotation
+
+```
+Client                     Auth Server
+  |                            |
+  |--- Refresh Request ------->|
+  |  (refresh_token_v1)        |
+  |<-- New Access Token -------|
+  |<-- New Refresh Token (v2) -|
+  |  (v1 invalidated)          |
+  |                            |
+  |--- Refresh Request ------->|
+  |  (refresh_token_v2)        |
+  |<-- New Access Token -------|
+  |<-- New Refresh Token (v3) -|
+  |                            |
+  |--- THEFT: Reuse v1 ------->|
+  |  (DETECTED: v1 reused)     |
+  |<-- REVOKE ALL TOKENS ------|
+```
+
+### Rotation Detection:
+- Each refresh token is single-use
+- On reuse of an old refresh token, server detects theft
+- All tokens in the grant chain are revoked
+- User must re-authenticate
+
+## Workflow 4: Device Authorization Grant
+
+```
+Device                     Auth Server              User (Browser)
+  |                            |                         |
+  |--- Device AuthZ Request -->|                         |
+  |<-- device_code,            |                         |
+  |    user_code,              |                         |
+  |    verification_uri -------|                         |
+  |                            |                         |
+  |-- Display user_code ------>|                         |
+  |   to user on screen        |                         |
+  |                            |<-- User visits URI -----|
+  |                            |<-- Enters user_code ----|
+  |                            |<-- Authenticates -------|
+  |                            |<-- Consents ------------|
+  |                            |                         |
+  |--- Poll Token Endpoint --->|                         |
+  |  (device_code)             |                         |
+  |<-- Access Token -----------|                         |
+```
+
+## Workflow 5: Token Revocation
+
+### Steps:
+1. Client sends revocation request: `POST /revoke` with `token=xxx&token_type_hint=refresh_token`
+2. Auth server invalidates the token
+3. If refresh token revoked, all associated access tokens also invalidated
+4. Server returns 200 OK regardless of whether token was valid (prevents token fishing)
+
+## Workflow 6: Security Incident - Token Compromise Response
+
+### Steps:
+1. Detect suspicious token usage (unusual IP, impossible travel)
+2. Immediately revoke the compromised token via revocation endpoint
+3. If refresh token compromised, revoke entire token family
+4. Force re-authentication for affected user
+5. Audit all API calls made with compromised token
+6. Check for scope escalation attempts
+7. Review authorization logs for the compromised session
+8. Notify affected user and security team