OAuth 2.0 & OpenID Connect (OIDC)

📋 Overview

OAuth 2.0 is the industry-standard framework for Delegated Authorization, allowing a third-party application to obtain limited access to a user's resources without knowing their password. OpenID Connect (OIDC) is a thin layer on top of OAuth 2.0 that adds Authentication, providing a standardized way to verify the identity of the user via an "ID Token." Together, they form the backbone of modern SSO (Single Sign-On) and API security.

---

🏗️ Core Principles & Characteristics

• The Four Roles:
  1. Resource Owner: The User.
  2. Client: The App requesting access.
  3. Authorization Server: The "Truth" (Okta, Auth0, Google).
  4. Resource Server: The API holding the data.
• Tokens:
  • Access Token: A credential (usually a JWT) used to access the API. "What can I do?"
  • ID Token: A JWT containing user profile info. "Who am I?"
  • Refresh Token: Used to obtain new access tokens without the user re-authenticating.
• Grant Types (Flows):
  • Authorization Code + PKCE: The gold standard for Web and Mobile apps.
  • Client Credentials: For machine-to-machine (M2M) communication.

---

⚖️ Trade-offs: Pros & Cons

• Pros:
  • Security: Users never share passwords with third-party apps.
  • Revocability: Access can be revoked at any time by the user or the admin.
  • Standardization: Works across all platforms and languages.
• Cons:
  • Complexity: Implementing the "Handshake" correctly is difficult and prone to security holes (e.g., Redirect URI leaks).
  • Centralized Failure: If your Identity Provider (IdP) goes down, no one can log in to any of your services.

---

🌍 Real-World Implementation

• "Login with Google/GitHub": Classic OIDC implementation where the external provider identifies the user and gives the app an ID token.
• Microservices Security: A "BFF" (Backend for Frontend) obtains an access token and passes it to various downstream microservices, which validate the token locally using the IdP's public keys.
• Mobile Apps: Use the PKCE extension to securely handle the authorization code without needing a "Client Secret" (which can't be safely stored on a phone).

---

💡 Interview "Gotchas" & Tips

• OAuth2 is NOT Authentication: This is the most common mistake. Always clarify that OAuth2 is for Authorization (Permissions). OIDC is for Authentication (Identity).
• Why PKCE? Explain that PKCE prevents "Authorization Code Injection" attacks on public clients (like browsers or mobile apps) where an attacker might intercept the code from the redirect URL.
• Local vs. Remote Validation: Explain how microservices use JWKS to validate tokens offline (fast) vs. using the Introspection endpoint (slow but allows instant revocation).

---

📐 Suggested Architecture Primitives

• Authorization Server (IdP): The central authority.
• JWT (JSON Web Token): The standard format for tokens.
• Scopes: Defining the "Permissions" (e.g., read:orders, email).
• JWKS Endpoint: Where the server publishes its public keys for token validation.
• BFF Pattern: Using a backend proxy to manage tokens for a frontend SPA to increase security.