Authentication and access-control testing for an identity platform

The client is a Swiss identity platform used to sign citizens and staff into public-sector services through a single login. When one identity layer guards access to many services, a flaw in it undermines every service behind it.

The platform stitched together several authentication flows, and each had been built at a different time, by different hands, without a unified security review.

Authentication logic was spread across login, single sign-on, and token issuance, and the interactions between those flows had never been tested as a whole. The seams between flows are exactly where abuse cases hide.

Weaknesses in areas such as session handling, token validation, and access control are precisely the ones attackers probe first, yet the client had no independent assurance over them. The most sensitive layer had the least scrutiny.

Because this layer fronted public services, the client needed confidence that identity could not be bypassed or escalated. The bar was to withstand real abuse, not just pass a happy-path check.

Working within a signed scope, we tested the authentication and access-control flows against realistic abuse cases: token tampering, session fixation, privilege escalation, and broken access control. Testing the flows as attackers would is what reveals the real weaknesses.

We examined the OAuth2 and OIDC implementations closely, validating how tokens were issued, scoped, and verified across the flows. Token handling is where identity platforms most often fail quietly.

Each finding came with reproduction steps and specific hardening guidance for the identity layer, and we retested after remediation to confirm the paths were closed. The identity layer went into rollout with its weaknesses proven shut.