AI
Replayed Tokens Breach Microservice Boundaries
In a financial application, a gateway validated tokens and routed requests to account, transaction, and internal services. The attacker removed the authorization header, got a 401 error, then used Burp Suite to enumerate endpoints. A header change from Express.js to Django 4.2.17 revealed an internal admin service. The attacker replayed the same token from the public service to access the Django user list. Two problems: the token lacked granular scope, and the gateway did not enforce scope downstream. The 2025 Salesforce breach used a similar wide-scope integration token to access 7,000+ customer environments.
Bearer Tokens Enable MFA-Free Hijacking
The STORM-2372 attack against Microsoft used phishing to capture a token after the victim entered credentials and MFA. Once the attacker held the bearer token, MFA became irrelevant. The demo showed a polling server grabbing the token from local storage after a user clicked a payload. The attacker replaced the token in their browser and accessed the user profile without any login. Bearer tokens are not bound to a device or session. Mitigation: DPoP tokens, which include a public key fingerprint. The client proves possession with a private key, so a stolen token alone is insufficient.
Federated Identity Confusion Exploits Weak Issuer Checks
Many applications offer multiple identity providers (Google, Azure, internal IDP). An attacker created an account on a low-trust internal IDP using the admin email admin@company.com. That IDP allowed self-registration, no email verification, and no MFA. The application validated only the issuer and subject, not the trust level or account type. The low-trust token was accepted for admin access. Secure code limits admin roles to high-trust IDPs and enforces MFA. Composite identity (issuer + subject) treats the same email from different providers as separate identities, preventing the takeover.
Q&A
How do you distribute DPoP tokens to public untrusted clients? Clients generate a key pair locally (browser or mobile) and pass only the public key when requesting a token. The server binds the public key into the token. ▶ 29:19
Where is the weakest link in JWT flows: the token, validation logic, or trust between servers? The validation logic is the weakest link, especially when multiple systems must each validate the same token correctly. ▶ 30:54
If identity, authorization, and trust all collapse into a single signed JWT, are we securing systems or protecting a valuable string? We are protecting a very valuable string. The JWT must follow all standard security parameters and correct attributes to remain secure. ▶ 31:50
Notable Quotes
any person who has the token can use it just like a currency Bhaumik Shah · ▶ 13:08
so with the bearer token the attacker has the token passes the API server and access is granted Bhaumik Shah · ▶ 17:10
It does not check who issued it whether it was issued by the Google or Microsoft or octa or odd zero right it doesn’t check that Bhaumik Shah · ▶ 19:53
MFA is not going to protect here Bhaumik Shah · ▶ 16:50
Key Takeaways
- Enforce token scope at each microservice, not just at the gateway.
- Use DPoP tokens to bind authentication to a device, preventing replay.
- Treat federated identity providers as separate trust zones with bound privileges.
About the Speaker(s)
Bhaumik Shah is a cybersecurity leader and founder of Securify, where he helps organizations secure their cloud, applications, and infrastructure through penetration testing, red team operations, and compliance programs like SOC 2 and ISO 27001. With over a decade of experience uncovering vulnerabilities in identity systems, he also shares security insights on his YouTube channel cyberc TV.