Protecting Microsoft 365 SSO Sessions with Device Binding

Your app uses Microsoft Entra ID (Azure AD) for SSO. Users sign in with their corporate Microsoft account. But after SSO completes, the session cookie is a bearer token anyone can steal. Here's how to fix that.

The Problem with Microsoft SSO Sessions

Microsoft Entra ID handles authentication. After the OAuth flow completes, your app receives tokens (access token, ID token, refresh token) and creates a session. This session is typically stored as an HTTP cookie.

The issue: Microsoft secures the login. You secure the session.If an attacker steals the session cookie (via AiTM, XSS, or malware), they bypass all of Microsoft's security — MFA, Conditional Access, device compliance — because those checks only run during authentication, not on every request.

How TokenForge Fits In

TokenForge adds a device-binding layer after Microsoft SSO completes. The flow becomes:

1. User clicks "Sign in with Microsoft" → Microsoft Entra ID handles auth + MFA
2. Your app receives tokens, creates a session cookie
3. TokenForge binds the session to the device — generates ECDSA key pair, registers public key with the server
4. Every subsequent request is signed with the device key
5. Server verifies signature + calculates trust score on every request

Integration: Next.js + MSAL + TokenForge

If you're using @azure/msal-react or next-authwith the Azure AD provider, here's how to add TokenForge:

Step 1: Add the script tag

One line in your HTML. Auto-binds the device after Microsoft SSO completes:

<script
  src="https://tokenforge-api.opensyber.cloud/sdk.js"
  data-api-key="tf_your_api_key"
></script>

Step 2: Add server middleware

npm install @opensyber/tokenforge

// Express
import { tokenForgeMiddleware } from '@opensyber/tokenforge/express';
app.use(tokenForgeMiddleware({ apiKey: process.env.TOKENFORGE_API_KEY! }));

// Next.js
import { withTokenForge } from '@opensyber/tokenforge/nextjs';
export const GET = withTokenForge(handler, { apiKey: process.env.TOKENFORGE_API_KEY! });

Advanced: MSAL integration (optional)

For deeper control with @azure/msal-react, use the npm package:

npm install @opensyber/tokenforge

// app/providers.tsx
import { createTokenForge } from '@opensyber/tokenforge/client';
import { useEffect } from 'react';
import { useSession } from 'next-auth/react'; // or useMsal()

const tf = createTokenForge({ apiBase: '/api' });

export function TokenForgeInit() {
  const { data: session } = useSession();
  useEffect(() => {
    if (session?.user) tf.init();
  }, [session]);
  return null;
}

Integration: Power Automate + Logic Apps

For Microsoft 365 flows (Power Automate, Logic Apps) that call your API, the service-to-service pattern is different. These calls use app-only tokens, not user sessions. TokenForge protects user-facing sessions, not service-to-service calls.

The recommended approach:

• User-facing web app → TokenForge device binding (full protection)
• Power Automate → your API → validate the app-only token + IP allowlist (no device binding needed)
• Teams tab / Outlook add-in → TokenForge works inside the embedded browser (WebView supports Web Crypto API)

What You Get

• AiTM attacks that steal Microsoft SSO cookies are blocked — signature mismatch
• XSS token theft is neutralized — private keys are non-extractable
• Trust score dashboard shows anomalies (IP change, geo mismatch, fingerprint drift)
• Step-up auth triggers re-verification for sensitive operations
• Audit logs for compliance (SOC2, ISO 27001 session security controls)

Microsoft Conditional Access + TokenForge

Microsoft Conditional Access evaluates device compliance, location, and risk at login time. TokenForge evaluates trust on every request. They complement each other: