Resecurity published a useful case study on a yard-management system where the upstream identity provider looked strong, but the application’s own session layer broke the trust model. The platform used Azure Entra ID SSO and MFA, yet Resecurity says testers could forge application sessions because a signed cookie used a predictable signing secret and a public user identifier as the value being trusted.

That is the lesson for defenders: SSO is not the finish line. If the application creates its own session cookie after login, that cookie becomes a separate authentication boundary. A weak implementation there can bypass the protections everyone assumes the identity provider is enforcing.

What Resecurity reported

According to Resecurity, the tested application issued a signed session cookie after Entra ID authentication. The cookie did not reference a random, server-side session identifier. Instead, it protected a user database ID that could be found in API responses. The signing key was also predictable and hard-coded, reportedly matching the cookie name itself.

Those two choices combined into an authentication bypass. Once a valid user ID and the signing pattern were known, the application accepted forged session cookies as if they represented real authenticated users. Resecurity says the issue allowed impersonation of multiple employee accounts, including elevated accounts, without the victim’s password, MFA challenge, or Entra ID token.

The scary part is how normal the rest of the stack looked. The application had SSO, signed identity-provider tokens, schema validation, and parameterized database access. Those controls matter, but they did not save the environment once the application’s post-login session mechanism became the weakest link.

Why this matters for SMBs and government contractors

Many small and mid-sized organizations now rely on SSO as the visible proof that an application is secure. That confidence can be dangerous when custom applications, vendor portals, logistics platforms, line-of-business systems, or “temporary” admin apps implement their own cookie/session logic behind the SSO handoff.

For government contractors, the risk is bigger than account takeover inside one portal. A session-layer bypass can expose employee records, operational workflows, contract data, CUI-adjacent documents, supplier information, and administrative functions that were assumed to be protected by MFA. If the affected application supports logistics, facilities, inventory, or partner access, an identity flaw can quickly become an operational security problem.

Defensive takeaways

  • Review the session layer, not just the SSO checkbox. Confirm what your application trusts after the identity provider returns a token. A secure login flow can still hand off to an insecure cookie.
  • Use random server-side session identifiers. Session cookies should reference unpredictable values tied to server-side state, not public database IDs, email addresses, usernames, or role values.
  • Keep signing secrets long, random, and centrally managed. Cookie and token signing keys should come from a secrets manager or protected environment configuration, not source code, examples, defaults, or names derived from the cookie itself.
  • Rotate secrets after discovery. If a signing secret was predictable, hard-coded, logged, or shared across environments, assume sessions may be forgeable. Rotate the key and invalidate existing sessions.
  • Do not expose unnecessary internal identifiers. Public user IDs are not always sensitive by themselves, but they become dangerous when reused as session payloads, authorization decisions, or object-access anchors.
  • Test role and session boundaries during vendor reviews. Ask vendors how sessions are generated, stored, signed, invalidated, and bound to identity-provider claims. “We use SSO” is not a complete answer.
  • Log impossible session behavior. Alert on session use from new geography, sudden role changes, cookie-only authentication without normal token exchange patterns, and administrative activity shortly after session anomalies.

Bulwark Black assessment

This is a clean example of a modern identity failure: the strong control was upstream, while the weakness lived in the application glue code. Defenders should treat post-SSO session handling as part of the authentication system, not as an implementation detail left to developers without review.

The practical move is to add session architecture to security assessments. For every business-critical application, know whether sessions are server-side or stateless, what value is signed, where the signing secret lives, how keys rotate, how sessions are invalidated, and whether authorization is rechecked server-side on every sensitive action. If those answers are vague, the SSO integration may be giving the organization more confidence than protection.

Original source: Resecurity — Session Cookie Authentication Bypass: Predictable Signing Secret Enableds Account Impersonations.