None
SSO Login

Introduction:

SSO (Single Sign-On) is a convenient way to authenticate users, and many apps rely on it for security. But even well-known systems like Microsoft's Azure AD can have vulnerabilities if not integrated properly. Recently, I found a serious flaw in how a web app handled its Microsoft SSO integration — and it taught me a lot about securing authentication flows.

Here's the bug I found, how it worked, and the important lessons you can learn from it.

The Setup: Using Microsoft SSO

In the web app I was testing, Microsoft SSO was used to authenticate users. Here's how it was supposed to work:

  1. The user clicks the SSO Login button.
  2. They enter their email and password on the Microsoft login page.
  3. After logging in, Microsoft sends an authorization code to the app.
  4. The app exchanges the code for an ID token, which it uses to authenticate the user.

Sounds simple enough but there was a problem.

The Bug: Impersonating Users by Manipulating Data

After I entered my login details, I intercepted the authentication request using Burp Suite (a security tool). The request contained a JSON object with user information, including email, tenantId, and objectId. Here's where things went wrong.

I noticed that by simply removing the objectId field and replacing the email with another user's email, I could forward the request and get logged in as that user — even though I never entered their password.

This was a serious impersonation vulnerability. The app was trusting data from the client (the email and objectId in the JSON), without properly verifying it, which allowed me to fake my identity.

Why This Happened: The Root Cause

The issue was that the app trusted client-supplied data (email, objectId) without validating it. Instead of checking the ID token issued by Microsoft to verify the user's identity, the app relied on data that could easily be tampered with.

Lessons Learned: Best Practices for SSO Security

This bug reinforced some critical lessons about handling SSO securely:

  1. Never Trust Client-Side Identity Data: Always use server-validated tokens to establish identity. Client-side data like email or objectId can be manipulated easily, as I showed.
  2. Validate Tokens: Any token (like the ID token you get from the SSO provider) should always be verified server-side before trusting the identity claims within it. This ensures the token hasn't been tampered with.
  3. Use Secure Libraries: Always rely on well-established libraries or SDKs for handling SSO authentication. They take care of validating tokens and handling edge cases.
  4. Test for Edge Cases: Regularly test your authentication system to make sure there are no holes in the security like the one I found by manipulating the request

Key Takeaways:

  • Validate ID tokens to ensure the data hasn't been tampered with.
  • Never trust client data (like email or objectId) for authentication.
  • Test thoroughly for security flaws in your authentication process.