Series intro — cctbp.com | Tom Stacy, CISSP®
Every red team engagement I’ve run that touched an identity provider has had the same arc.
The pre-engagement call: “We use OAuth 2.0 with PKCE, MFA on all accounts, and our IdP is hardened.” The client is confident. Their team spent real time on this. Then you get into the environment and you find the authorization server accepting response_type=token on a flow that was supposed to be code-only. Or a SAML assertion that replays cleanly because the SP isn’t validating NotOnOrAfter. Or a refresh token that survives a password reset.
None of that is exotic. All of it has been previously documented. The CVEs exist. The academic papers exist. The conference talks exist.
The gap isn’t knowledge. The gap is proof.
When a red teamer says “your OAuth implementation is vulnerable to authorization code interception,” the client’s security team hears a theoretical concern. When you hand them a screen recording of you exchanging an intercepted code for a valid access token against their staging environment — against their authorization server, their client IDs, their redirect URIs — that’s a different conversation.
The problem is that getting to that proof has always required either a complicated bespoke lab setup or going straight at a production environment with all the risk that implies. Neither option is good.
What This Series Is
This is a practitioner series about authentication and identity attack chains. OAuth 2.0. OIDC. SAML. MFA bypass. Session abuse. Cross-tenant edge cases.
Every technique gets the same treatment:
- What the attack actually is, in precise technical terms
- What conditions make it possible
- A reproducible demonstration against a purpose-built lab environment
- What it looks like in logs from the defender’s side
- What actually fixes it — not just “use PKCE” but why, and what “enforced server-side” means in practice
The lab environment is FlawedToken for OAuth/OIDC work and FlawedAssertion for SAML. Both are open source, Docker-based, and built to have the misconfigurations active by default with toggles to switch to correct behavior so you can see exactly what changes.
One command to run them. No cloud accounts required. No authorized-target paperwork for a lab you control.
Why Now
The tooling for this work has always lagged the knowledge. Static analysis tools flag some OAuth misconfigs. Burp extensions cover some token manipulation cases. But there’s never been a coherent, maintained lab environment purpose-built for auth-flow attack chains with the kind of documentation that makes the techniques transferable.
ShroudCloud™ is the longer answer to this problem — engagement infrastructure for authorized adversarial operations against auth flows at scale. The waitlist is open. But the lab tools and this series exist independently of that and always will. The techniques should be accessible to anyone doing this work.
What’s First
The first technique post covers authorization code interception. It’s the right place to start because it’s the foundational OAuth attack and because understanding it precisely — the flow, the seam, the conditions — is prerequisite knowledge for everything that comes after.
The post is already written. It goes up Friday.
Join the ShroudCloud™ waitlist at shroudcloud.com
Tom Stacy, CISSP®, is an authentication and identity security specialist. He writes at cctbp.com and is building ShroudCloud™, an engagement infrastructure for auth and session security.