Broken access control and identification & authentication failures consistently rank among the OWASP Top 10. Yet, many teams still disable authentication entirely when running integration tests against their APIs—undermining the very security controls they intend to validate.

I had session in Experts Live Denmark 2026 and in one session of a MVP colleague Stephan van Rooij (Microsoft MVP, Software Architect at Smartersoft / Roostersync B.V.) demonstrates a powerful but careful approach: testing API authentication and RBAC without disabling security, using a controlled man‑in‑the‑middle (MITM) identity proxy.

This post summarizes the core ideas, techniques, risks, and mitigations discussed in the session.

The Core Problem: Testing APIs Without Breaking Security

Modern APIs are typically protected by JWT access tokens issued by Azure Entra ID (or another OpenID Connect provider). During integration testing, teams often face a dilemma:

  • ✅ Realistic tests require authentication
  • ❌ Real tokens are hard to generate in automated tests
  • ❌ Disabling authentication invalidates RBAC and security tests

As Stephan highlights, disabling authentication means you’re no longer testing your API realistically—especially when authorization logic is critical.

The Key Idea: An Identity Proxy That Issues “Forged but Valid” Tokens

The solution demonstrated is an identity proxy that sits between the API and the real identity provider.

How it Works (Conceptually)

  1. The API is configured to load its OpenID configuration from a proxy instead of directly from Entra ID.
  2. The proxy:
    • Fetches the real configuration from Entra ID
    • Keeps the original issuer, audience, and metadata
    • Rewrites the keyset URI to point back to itself
  3. The proxy:
    • Loads the real Entra signing keys
    • Injects an additional signing certificate
  4. The API:
    • Still validates tokens successfully
    • Cannot distinguish forged test tokens from real ones

From the API’s perspective, the tokens look exactly as if they came from Entra ID—and they validate correctly.

This allows test code to generate tokens with custom claims, subjects, and roles, without ever disabling authentication.

Why This Is Powerful for Integration Testing

Using this approach, you can:

  • Run full integration tests against your real API pipeline
  • Validate role‑based access control (RBAC)
  • Test edge cases like:
    • Access to resources owned by other users
    • Missing roles
    • Non‑existent resources
  • Debug your API normally (breakpoints, request inspection, etc.)

The session demonstrates this using:

  • ASP.NET test hosting
  • WebApplicationFactory
  • A Docker‑based identity proxy container
  • Test containers that start quickly and are disposed after tests

Authentication remains enabled throughout.

Example: Testing Without Disabling Authentication

Stephan demonstrates a test flow where:

  • A forged token is generated with specific claims
  • The token is attached as an Authorization header
  • The API endpoint is called normally
  • Assertions validate:
    • HTTP status codes
    • Returned data
    • Authorization behavior

This allows testing scenarios such as:

  • “User can only see their own data”
  • “Accessing another user’s resource returns NotFound”
  • “Unauthorized access behaves consistently”

All without turning authentication off.

Security Reality Check: Yes, This Is a MITM Attack

This approach intentionally performs a man‑in‑the‑middle attack on token validation.

Stephan is explicit about this:

  • ✅ This is for testing purposes
  • ❌ If left unprotected in production, it introduces serious risk
  • ❌ It can be abused maliciously if misconfigured

Which leads to the most important part of the talk…

Protecting Your API Against Forged Tokens

The session outlines three concrete mitigations you should apply in production.

1. Require HTTPS Metadata

Ensure your API only loads OpenID metadata over HTTPS.

If RequireHttpsMetadata is disabled, an attacker could serve fake metadata from a local or insecure endpoint.

✅ Enabling this blocks non‑HTTPS identity endpoints.

2. Validate the Authority Explicitly

On startup, verify that the authority URL:

  • Starts with login.microsoftonline.com
  • Matches what you expect exactly

If the authority is modified, fail fast on startup.

✅ This prevents silent authority tampering.

3. Certificate Pinning (Advanced)

For maximum protection, the session recommends certificate pinning:

  • Validate that the TLS certificate chain ends in a known Microsoft root certificate
  • Example cited: DigiCert Global Root G2

This completely blocks:

  • DNS poisoning
  • HTTPS interception
  • Rogue identity endpoints

⚠️ Note: Certificate pinning can conflict with enterprise HTTPS inspection, which is why Microsoft does not enable it by default.

Side Lessons from Real‑World Security Incidents

The session also highlights two real‑world security patterns worth remembering:

Timing Attacks on Authentication

An API returned identical responses for:

  • Non‑existent users
  • Existing users with wrong passwords

But response times differed by ~100ms—enough to detect valid accounts.

✅ Fix: Use constant‑time comparisons when validating credentials.

Status Codes Can Leak Information

If unauthenticated users receive 404 Not Found for endpoints that do exist, attackers can infer your API structure.

✅ Some industries require:

  • 401 Unauthorized for unauthenticated requests
  • 404 only after authentication succeeds

CI/CD: Enforcing Security with Tests

The session also demonstrates running these integration tests in GitHub Actions:

  • Tests run automatically on every build
  • Releases are blocked if tests fail
  • Missing authorization on endpoints is detected early

This ensures security regressions never reach production.

Key Takeaways

  • Never disable authentication for integration testing
  • You can test authentication and RBAC safely
  • A controlled identity proxy enables realistic testing
  • Production APIs must defend against the same technique
  • Small configuration choices can have major security impact

As Stephan puts it:

“With this, you can safely release on Friday afternoon—because it’s all tested.”