Part 3: Authentication Protocols and Flows

The Day I Implemented the Wrong Flow

Early in my career, I built a React SPA that needed to call our backend API. I read "OAuth 2.0" and implemented the implicit flow—because that's what the first tutorial I found suggested. Everything worked... until our security audit flagged it as a critical vulnerability. Tokens were being exposed in browser history and URL fragments.

I had to refactor to authorization code flow with PKCE. It took days to understand why one flow was secure and the other wasn't. Let me save you that pain.

OAuth 2.0 and OpenID Connect: The Foundation

MS Entra implements two critical standards:

OAuth 2.0

Purpose: Authorization (what can you access?) Result: Access tokens for calling APIs

OpenID Connect (OIDC)

Purpose: Authentication (who are you?) Result: ID tokens with user identity information

The relationship:

OpenID Connect
      │
      └──── Built on top of OAuth 2.0
            │
            └──── Adds identity layer

What You Get From Each

OAuth 2.0 gives you:

{
  access_token: "eyJ0eXAiOiJKV1QiLCJhbGc...",  // For API calls
  token_type: "Bearer",
  expires_in: 3600,
  scope: "api://payment-api/Payments.Read"
}

OIDC adds:

{
  access_token: "eyJ0eXAiOiJKV1QiLCJhbGc...",
  id_token: "eyJ0eXAiOiJKV1QiLCJhbGc...",     // Identity information
  token_type: "Bearer",
  expires_in: 3600,
  scope: "openid profile email"
}

MS Entra Authentication Endpoints

MS Entra supports two endpoint versions:

v1.0 Endpoint (Legacy)

https://login.microsoftonline.com/{tenant}/oauth2/authorize
https://login.microsoftonline.com/{tenant}/oauth2/token

v2.0 Endpoint (Current)

https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token

Use v2.0 for new applications. It supports:

• Personal Microsoft accounts

• Better token structure

• Incremental consent

• PKCE support

Well-Known Configuration

MS Entra publishes its configuration at:

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

Real example:

// Fetch MS Entra configuration
const response = await fetch(
  "https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration"
);

const config = await response.json();

console.log(config);
// {
//   "authorization_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/authorize",
//   "token_endpoint": "https://login.microsoftonline.com/common/oauth2/v2.0/token", 
//   "jwks_uri": "https://login.microsoftonline.com/common/discovery/v2.0/keys",
//   "issuer": "https://login.microsoftonline.com/{tenantid}/v2.0",
//   "response_types_supported": ["code", "id_token", "code id_token", ...],
//   "scopes_supported": ["openid", "profile", "email", "offline_access"],
//   ...
// }

OAuth 2.0 Flows in MS Entra

MS Entra supports multiple OAuth flows. Choosing the right one is critical.

Flow Selection Matrix

type ApplicationType = "SPA" | "Web" | "Mobile" | "Backend" | "Daemon";

function selectFlow(appType: ApplicationType, hasUser: boolean): string {
  if (!hasUser) {
    return "Client Credentials Flow";  // Daemon/service
  }
  
  switch (appType) {
    case "SPA":
      return "Authorization Code Flow with PKCE";  // React, Vue, Angular
    case "Web":
      return "Authorization Code Flow";             // Server-rendered
    case "Mobile":
      return "Authorization Code Flow with PKCE";  // iOS, Android
    case "Backend":
      return "On-Behalf-Of Flow";                  // API calling API
    default:
      throw new Error("Unknown app type");
  }
}

Let me explain each flow with real implementations.

1. Authorization Code Flow with PKCE

Best for: Single-page applications (SPAs), mobile apps, desktop apps

Why: Most secure for public clients that can't keep secrets

The Problem It Solves

Public clients (SPAs, mobile apps) can't securely store client secrets. Any secret in JavaScript or a mobile app can be extracted. PKCE (Proof Key for Code Exchange) solves this.

How PKCE Works

// Step 1: Generate code verifier (random string)
function generateCodeVerifier(): string {
  const array = new Uint8Array(32);
  crypto.getRandomValues(array);
  return base64URLEncode(array);
}

// Step 2: Generate code challenge (hash of verifier)
async function generateCodeChallenge(verifier: string): Promise<string> {
  const encoder = new TextEncoder();
  const data = encoder.encode(verifier);
  const digest = await crypto.subtle.digest("SHA-256", data);
  return base64URLEncode(new Uint8Array(digest));
}

// Step 3: Start auth flow
const codeVerifier = generateCodeVerifier();
const codeChallenge = await generateCodeChallenge(codeVerifier);

// Store verifier for later
sessionStorage.setItem("pkce_verifier", codeVerifier);

// Redirect to authorization endpoint
const authUrl = new URL("https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize");
authUrl.searchParams.set("client_id", clientId);
authUrl.searchParams.set("response_type", "code");
authUrl.searchParams.set("redirect_uri", redirectUri);
authUrl.searchParams.set("scope", "openid profile api://payment-api/Payments.Read");
authUrl.searchParams.set("code_challenge", codeChallenge);
authUrl.searchParams.set("code_challenge_method", "S256");

window.location.href = authUrl.toString();

Complete React SPA Example

// src/auth/MsalConfig.ts
import { PublicClientApplication, Configuration } from "@azure/msal-browser";

const msalConfig: Configuration = {
  auth: {
    clientId: process.env.REACT_APP_CLIENT_ID!,
    authority: `https://login.microsoftonline.com/${process.env.REACT_APP_TENANT_ID}`,
    redirectUri: window.location.origin,
  },
  cache: {
    cacheLocation: "localStorage",  // or "sessionStorage"
    storeAuthStateInCookie: false,
  },
};

export const msalInstance = new PublicClientApplication(msalConfig);

// Initialize MSAL
await msalInstance.initialize();

// src/components/Login.tsx
import { msalInstance } from "../auth/MsalConfig";

export function Login() {
  const handleLogin = async () => {
    try {
      const loginRequest = {
        scopes: [
          "openid",
          "profile", 
          "email",
          "api://payment-api/Payments.Read",
          "api://payment-api/Payments.Write"
        ],
        prompt: "select_account"  // Force account selection
      };
      
      // Initiates auth code flow with PKCE automatically
      const response = await msalInstance.loginPopup(loginRequest);
      
      console.log("Signed in:", response.account);
      console.log("Access token:", response.accessToken);
      
      // Store account info
      const account = response.account;
      
    } catch (error) {
      console.error("Login failed:", error);
    }
  };
  
  return <button onClick={handleLogin}>Sign In</button>;
}

// src/api/PaymentClient.ts
async function callPaymentAPI() {
  // Get token silently (uses cached token or refresh token)
  const accounts = msalInstance.getAllAccounts();
  
  if (accounts.length === 0) {
    throw new Error("No signed-in account");
  }
  
  const request = {
    scopes: ["api://payment-api/Payments.Read"],
    account: accounts[0]
  };
  
  let tokenResponse;
  
  try {
    // Try to acquire token silently
    tokenResponse = await msalInstance.acquireTokenSilent(request);
  } catch (error) {
    // Silent acquisition failed, use popup
    tokenResponse = await msalInstance.acquireTokenPopup(request);
  }
  
  // Call API with token
  const response = await fetch("https://api.mycompany.com/payments", {
    headers: {
      "Authorization": `Bearer ${tokenResponse.accessToken}`,
      "Content-Type": "application/json"
    }
  });
  
  return response.json();
}

The Flow Diagram

User's Browser              MS Entra                Your SPA
     │                         │                       │
     │  1. Click "Sign In"     │                       │
     ├────────────────────────>│                       │
     │                         │                       │
     │  2. Generate PKCE       │                       │
     │     code_verifier       │                       │
     │     code_challenge      │                       │
     │                         │                       │
     │  3. Redirect to /authorize with code_challenge │
     ├────────────────────────>│                       │
     │                         │                       │
     │  4. Show login page     │                       │
     │<────────────────────────┤                       │
     │                         │                       │
     │  5. Enter credentials   │                       │
     ├────────────────────────>│                       │
     │                         │                       │
     │  6. Redirect to SPA with authorization code     │
     │<────────────────────────┤                       │
     │                         │                       │
     │  7. Extract code        │                       │
     │  8. POST to /token with code + code_verifier    │
     ├────────────────────────>│                       │
     │                         │                       │
     │  9. Validate PKCE       │                       │
     │  10. Return tokens      │                       │
     │<────────────────────────┤                       │
     │                         │                       │
     │  11. Store tokens       │                       │
     │  12. Call API           │                       │
     ├─────────────────────────┼──────────────────────>│
     │                         │                       │

2. Authorization Code Flow (Without PKCE)

Best for: Traditional web applications with server-side code

Why: Server can securely store client secret

Node.js Express Example

// server.ts
import express from "express";
import session from "express-session";
import { ConfidentialClientApplication } from "@azure/msal-node";

const app = express();

// Configure session
app.use(session({
  secret: process.env.SESSION_SECRET!,
  resave: false,
  saveUninitialized: false,
  cookie: { secure: true, httpOnly: true }
}));

// MSAL configuration
const msalConfig = {
  auth: {
    clientId: process.env.AZURE_CLIENT_ID!,
    authority: `https://login.microsoftonline.com/${process.env.AZURE_TENANT_ID}`,
    clientSecret: process.env.AZURE_CLIENT_SECRET!  // Server can keep secrets
  },
  system: {
    loggerOptions: {
      loggerCallback: (level, message) => console.log(message),
      piiLoggingEnabled: false,
      logLevel: 3
    }
  }
};

const msalClient = new ConfidentialClientApplication(msalConfig);

// Login route
app.get("/auth/login", async (req, res) => {
  const authCodeUrlParameters = {
    scopes: ["user.read", "api://payment-api/Payments.Read"],
    redirectUri: "https://myapp.com/auth/callback"
  };
  
  try {
    const authUrl = await msalClient.getAuthCodeUrl(authCodeUrlParameters);
    res.redirect(authUrl);
  } catch (error) {
    res.status(500).send("Error initiating authentication");
  }
});

// Callback route
app.get("/auth/callback", async (req, res) => {
  const tokenRequest = {
    code: req.query.code as string,
    scopes: ["user.read", "api://payment-api/Payments.Read"],
    redirectUri: "https://myapp.com/auth/callback"
  };
  
  try {
    const tokenResponse = await msalClient.acquireTokenByCode(tokenRequest);
    
    // Store tokens in session
    req.session.accessToken = tokenResponse.accessToken;
    req.session.account = tokenResponse.account;
    
    res.redirect("/dashboard");
  } catch (error) {
    res.status(500).send("Error acquiring token");
  }
});

// Protected API endpoint
app.get("/api/payments", async (req, res) => {
  if (!req.session.accessToken) {
    return res.status(401).send("Not authenticated");
  }
  
  // Call backend API with token
  const response = await fetch("https://api.mycompany.com/payments", {
    headers: {
      "Authorization": `Bearer ${req.session.accessToken}`
    }
  });
  
  const data = await response.json();
  res.json(data);
});

app.listen(3000,() => console.log("Server running on port 3000"));

3. Client Credentials Flow

Best for: Daemon apps, background services, service-to-service communication

Why: No user involved, app authenticates as itself

When to Use

• Scheduled jobs processing data

• Backend service calling another backend service

• CI/CD pipelines accessing resources

• Monitoring/alerting systems

Implementation Example

// scripts/sync-users.ts
// Daily job that syncs users from MS Entra to local database
import { ClientClientApplication } from "@azure/msal-node";
import { Client } from "@microsoft/microsoft-graph-client";

class UserSyncService {
  private msalClient: ConfidentialClientApplication;
  
  constructor() {
    this.msalClient = new ConfidentialClientApplication({
      auth: {
        clientId: process.env.AZURE_CLIENT_ID!,
        authority: `https://login.microsoftonline.com/${process.env.AZURE_TENANT_ID}`,
        clientSecret: process.env.AZURE_CLIENT_SECRET!
      }
    });
  }
  
  async getGraphClient(): Promise<Client> {
    // Acquire token using client credentials
    const tokenResponse = await this.msalClient.acquireTokenByClientCredential({
      scopes: ["https://graph.microsoft.com/.default"]  // .default = all app permissions
    });
    
    if (!tokenResponse?.accessToken) {
      throw new Error("Failed to acquire token");
    }
    
    // Create Graph client
    return Client.init({
      authProvider: (done) => {
        done(null, tokenResponse.accessToken);
      }
    });
  }
  
  async syncUsers() {
    const client = await this.getGraphClient();
    
    // Get all users (requires User.Read.All app permission)
    let users = [];
    let nextLink = "/users?$top=100";
    
    while (nextLink) {
      const response = await client.api(nextLink).get();
      users.push(...response.value);
      nextLink = response["@odata.nextLink"];
    }
    
    console.log(`Found ${users.length} users`);
    
    // Sync to local database
    for (const user of users) {
      await this.upsertUser({
        id: user.id,
        email: user.userPrincipalName,
        displayName: user.displayName,
        department: user.department
      });
    }
  }
  
  private async upsertUser(user: any) {
    // Database logic here
  }
}

// Run sync
const service = new UserSyncService();
await service.syncUsers();

Service-to-Service Communication

// payment-api calling user-service
import { ClientSecretCredential } from "@azure/identity";

class UserServiceClient {
  private credential: ClientSecretCredential;
  private baseUrl: string;
  
  constructor() {
    this.credential = new ClientSecretCredential(
      process.env.AZURE_TENANT_ID!,
      process.env.AZURE_CLIENT_ID!,      // payment-api's client ID
      process.env.AZURE_CLIENT_SECRET!
    );
    this.baseUrl = "https://user-service.mycompany.com";
  }
  
  async getUser(userId: string) {
    // Get token for user-service
    const tokenResponse = await this.credential.getToken(
      "api://user-service/.default"  // user-service's app ID URI
    );
    
    const response = await fetch(`${this.baseUrl}/users/${userId}`, {
      headers: {
        "Authorization": `Bearer ${tokenResponse.token}`,
        "Content-Type": "application/json"
      }
    });
    
    if (!response.ok) {
      throw new Error(`User service error: ${response.status}`);
    }
    
    return response.json();
  }
}

// Usage in payment API
app.post("/api/payments", async (req, res) => {
  const { userId, amount } = req.body;
  
  // Get user details from user-service using client credentials
  const userClient = new UserServiceClient();
  const user = await userClient.getUser(userId);
  
  // Process payment...
  
  res.json({ success: true });
});

4. On-Behalf-Of (OBO) Flow

Best for: Middle-tier APIs that need to call downstream APIs on behalf of the user

Why: Maintains user context through the call chain

The Scenario

User → Frontend SPA → API Gateway → Payment Service → User Service
                          ↓              ↓              ↓
                   User token    User token      User token
                                (via OBO)       (via OBO)

User's identity and permissions flow through the entire chain.

Implementation

// api-gateway/src/services/PaymentServiceClient.ts
import { OnBehalfOfCredential } from "@azure/identity";

class PaymentServiceClient {
  constructor(private userAccessToken: string) {}
  
  async createPayment(amount: number) {
    // Exchange user's token for payment-service token
    const oboCredential = new OnBehalfOfCredential({
      tenantId: process.env.AZURE_TENANT_ID!,
      clientId: process.env.AZURE_CLIENT_ID!,      // api-gateway's client ID
      clientSecret: process.env.AZURE_CLIENT_SECRET!,
      userAssertionToken: this.userAccessToken     // User's original token
    });
    
    // Get token for payment-service
    const tokenResponse = await oboCredential.getToken(
      "api://payment-service/.default"
    );
    
    // Call payment-service with OBO token
    const response = await fetch("https://payment-service.mycompany.com/payments", {
      method: "POST",
      headers: {
        "Authorization": `Bearer ${tokenResponse.token}`,
        "Content-Type": "application/json"
      },
      body: JSON.stringify({ amount })
    });
    
    return response.json();
  }
}

// api-gateway/src/routes/payments.ts
app.post("/api/payments", async (req, res) => {
  // Extract user's token from request
  const userToken = req.headers.authorization?.replace("Bearer ", "");
  
  if (!userToken) {
    return res.status(401).json({ error: "No token provided" });
  }
  
  // Call payment service using OBO flow
  const client = new PaymentServiceClient(userToken);
  const result = await client.createPayment(req.body.amount);
  
  res.json(result);
});

OBO Token Claims

// Original user token (from SPA)
{
  "aud": "api-gateway-client-id",
  "iss": "https://login.microsoftonline.com/{tenant}/v2.0",
  "sub": "user-id",
  "name": "John Doe",
  "scp": "Payments.Read Payments.Write"  // User consented to these
}

// OBO token (for payment-service)
{
  "aud": "payment-service-client-id",
  "iss": "https://login.microsoftonline.com/{tenant}/v2.0",
  "sub": "user-id",                       // Same user!
  "name": "John Doe",
  "scp": "Payments.Process",
  "azp": "api-gateway-client-id",         // App that requested OBO
  "azpacr": "1"                            // Authentication context
}

The user's identity flows through. Payment service sees who the end user is, not just the API gateway.

5. Resource Owner Password Credentials (ROPC)

⚠️ AVOID THIS FLOW

Why it exists: Legacy support for apps that can't use redirect-based flows

Why to avoid:

• ❌ App handles user's password (security risk)

• ❌ No MFA support

• ❌ No Conditional Access support

• ❌ Goes against modern security best practices

Only use if: You absolutely cannot use any other flow (very rare)

// ❌ ROPC Flow (avoid!)
const tokenResponse = await msalClient.acquireTokenByUsernamePassword({
  scopes: ["user.read"],
  username: "[email protected]",
  password: "user-password"  // 🚨 App handles password!
});

Instead, use device code flow for CLI tools or other alternatives.

6. Device Code Flow

Best for: Devices without browsers (IoT, CLI tools, smart TVs)

Why: User authenticates on a separate device

How It Works

Device (no browser)        MS Entra            User's Phone/Computer
       │                      │                        │
       │  1. Request code     │                        │
       ├─────────────────────>│                        │
       │                      │                        │
       │  2. Return code      │                        │
       │     & URL            │                        │
       │<─────────────────────┤                        │
       │                      │                        │
       │  3. Display:         │                        │
       │     "Go to           │                        │
       │      microsoft.com/  │                        │
       │      devicelogin"    │                        │
       │     "Enter: ABCD1234"│                        │
       │                      │                        │
       │                      │   4. User opens URL    │
       │                      │<───────────────────────┤
       │                      │                        │
       │                      │   5. Enters code       │
       │                      │        ABCD1234        │
       │                      │<───────────────────────┤
       │                      │                        │
       │  6. Poll for token   │   7. User signs in     │
       ├─────────────────────>│<───────────────────────┤
       │                      │                        │
       │  8. Return token     │   9. Consent given     │
       │<─────────────────────┤                        │
       │                      │                        │

CLI Tool Example

// cli-tool.ts
import { DeviceCodeCredential } from "@azure/identity";
import { Client } from "@microsoft/microsoft-graph-client";
import { TokenCredentialAuthenticationProvider } from "@microsoft/microsoft-graph-client/authProviders/azureTokenCredentials";

async function main() {
  const credential = new DeviceCodeCredential({
    tenantId: process.env.AZURE_TENANT_ID!,
    clientId: process.env.AZURE_CLIENT_ID!,
    userPromptCallback: (info) => {
      // Display instructions to user
      console.log(info.message);
      // Output: "To sign in, use a web browser to open the page
      //          https://microsoft.com/devicelogin and enter the code ABCD1234"
    }
  });
  
  // Get token (waits for user to complete auth on another device)
  const token = await credential.getToken("https://graph.microsoft.com/.default");
  
  // Create Graph client
  const authProvider = new TokenCredentialAuthenticationProvider(credential, {
    scopes: ["https://graph.microsoft.com/.default"]
  });
  
  const client = Client.initWithMiddleware({ authProvider });
  
  // Use the API
  const me = await client.api("/me").get();
  console.log(`Hello, ${me.displayName}!`);
}

main();

SAML Integration

While OAuth 2.0 is the modern standard, many enterprises still use SAML for SSO.

SAML vs OAuth 2.0

// SAML 2.0
interface SAMLFlow {
  protocol: "SAML 2.0";
  tokenFormat: "XML";
  useCase: "Enterprise SSO";
  typical: "Login to Salesforce with corporate account";
}

// OAuth 2.0 + OIDC
interface OAuth Flow {
  protocol: "OAuth 2.0 + OIDC";
  tokenFormat: "JSON (JWT)";
  useCase: "API authorization + SSO";
  typical: "React SPA calling REST API";
}

When MS Entra Uses SAML

Scenario 1: Enterprise App SSO

Employee → MS Entra → SAML assertion → Salesforce

Scenario 2: Your App as Service Provider

Employee → MS Entra (IdP) → SAML assertion → Your App (SP)

SAML Configuration in MS Entra

Enterprise Application → Single sign-on → SAML

Basic SAML Configuration:
  - Identifier (Entity ID): https://myapp.com
  - Reply URL (ACS): https://myapp.com/saml/acs
  
Attributes & Claims:
  - Unique User Identifier: user.userprincipalname
  - Email: user.mail
  - First Name: user.givenname
  - Last Name: user.surname
  
SAML Certificates:
  - Download Federation Metadata XML
  - Or download Certificate (Base64)

Implementing SAML in Node.js

// Using passport-saml
import passport from "passport";
import { Strategy as SamlStrategy } from "passport-saml";
import express from "express";

const app = express();

// SAML strategy configuration
passport.use(new SamlStrategy(
  {
    entryPoint: "https://login.microsoftonline.com/{tenant}/saml2",
    issuer: "https://myapp.com",
    callbackUrl: "https://myapp.com/saml/acs",
    cert: process.env.SAML_CERT!,  // From MS Entra
    identifierFormat: null
  },
  (profile, done) => {
    // profile contains user attributes from SAML assertion
    const user = {
      id: profile.nameID,
      email: profile.email,
      name: profile.displayName
    };
    return done(null, user);
  }
));

// Initiate SAML login
app.get("/login", passport.authenticate("saml"));

// SAML assertion consumer service (ACS)
app.post("/saml/acs",
  passport.authenticate("saml", { failureRedirect: "/login" }),
  (req, res) => {
    // User authenticated successfully
    res.redirect("/dashboard");
  }
);

// Logout
app.get("/logout", (req, res) => {
  req.logout(() => {
    res.redirect("/");
  });
});

Flow Comparison Summary

interface FlowComparison {
  flow: string;
  appType: string;
  hasUser: boolean;
  security: "High" | "Medium" | "Low";
  complexity: "Low" | "Medium" | "High";
  use: string;
}

const flows: FlowComparison[] = [
  {
    flow: "Authorization Code + PKCE",
    appType: "SPA, Mobile",
    hasUser: true,
    security: "High",
    complexity: "Medium",
    use: "React/Vue/Angular apps"
  },
  {
    flow: "Authorization Code",
    appType: "Web (server-side)",
    hasUser: true,
    security: "High",
    complexity: "Medium",
    use: "Node.js/Express servers"
  },
  {
    flow: "Client Credentials",
    appType: "Backend service",
    hasUser: false,
    security: "High",
    complexity: "Low",
    use: "Service-to-service, daemons"
  },
  {
    flow: "On-Behalf-Of",
    appType: "API",
    hasUser: true,
    security: "High",
    complexity: "High",
    use: "API chains maintaining user context"
  },
  {
    flow: "Device Code",
    appType: "IoT, CLI",
    hasUser: true,
    security: "High",
    complexity: "Medium",
    use: "Devices without browsers"
  },
  {
    flow: "Implicit",
    appType: "SPA (legacy)",
    hasUser: true,
    security: "Low",
    complexity: "Low",
    use: "❌ Deprecated, don't use"
  },
  {
    flow: "ROPC",
    appType: "Any (legacy)",
    hasUser: true,
    security: "Low",
    complexity: "Low",
    use: "❌ Avoid if possible"
  }
];

Common Pitfalls

Pitfall 1: Using Implicit Flow

// ❌ Implicit flow (deprecated)
const authUrl = `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
  response_type=id_token+token  // Tokens in URL!
  &client_id=...
  &redirect_uri=...`;
  
// Tokens end up in:
// - Browser history
// - Server logs
// - Referrer headers

// ✅ Use authorization code + PKCE instead
const authUrl = `https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
  response_type=code  // Just the code
  &client_id=...
  &code_challenge=...
  &code_challenge_method=S256`;

Pitfall 2: Wrong Scopes

// ❌ OAuth scopes for OIDC
scopes: ["User.Read"]  // This is a Graph API scope

// ✅ OIDC scopes
scopes: ["openid", "profile", "email"]

// ✅ Or both
scopes: ["openid", "profile", "api://my-api/My.Scope"]

Pitfall 3: Not Validating Tokens

// ❌ Just decode and trust
const decoded = jwt.decode(token);
const userId = decoded.sub;  // Unvalidated!

// ✅ Always validate signature, issuer, audience
const validated = jwt.verify(token, publicKey, {
  issuer: `https://login.microsoftonline.com/${tenantId}/v2.0`,
  audience: clientId
});

Key Takeaways

1. Use Authorization Code + PKCE for SPAs: Most secure for public clients

2. Client Credentials for Services: No user involved

3. On-Behalf-Of for API Chains: Maintain user context

4. Avoid Implicit Flow: Deprecated and insecure

5. SAML for Enterprise SSO: Still common in enterprises

6. Always Validate Tokens: Never trust without verification

What's Next

In Part 4: Tokens and Token Management, we'll dive deep into:

• JWT structure and claims

• Access tokens vs ID tokens vs refresh tokens

• Token validation best practices

• JWKS and key rotation

• Token lifetime management

• Caching strategies

We'll dissect tokens to understand exactly what's inside and how to work with them securely.

---

Previous: Part 2: Applications and Service Principals Next: Part 4: Tokens and Token Management Back to Series Overview