Notifications
Clear all
Topic starter
06/07/2026 9:39 am
TL;DR: Client-side OAuth security still depends on brittle trust boundaries that teams often underestimate, according to Curity. Its client security archive brings together guidance on OAuth for browser, mobile, and SPA environments, including unsolicited SAML responses, XSS prevention, token handler design, same-site cookies, and the nonce authenticator pattern.
NHIMG editorial — based on content published by Curity: Client Security guidance on OAuth hardening for browser and mobile apps
Questions worth separating out
Q: How should security teams secure OAuth client flows in browser-based apps?
A: Security teams should minimise the amount of sensitive identity state the browser holds, bind every response to an initiated transaction, and treat XSS as an identity risk.
Q: Why do unsolicited SAML responses create risk for OAuth applications?
A: They create risk because the application may accept an identity assertion without the request context that proves it was expected.
Q: What do teams get wrong about token handler design for SPAs?
A: Teams often treat the token handler as a convenience layer rather than the security boundary.
Practitioner guidance
- Bind every OAuth response to a known transaction Reject unsolicited or out-of-context SAML responses unless they match a previously initiated flow, the expected audience, and the correct session state.
- Move sensitive token handling out of the browser Use a backend token handler where the architecture allows it, especially for SPAs and browser-based apps that otherwise expose tokens to script and storage abuse.
- Treat XSS prevention as identity control Prioritise script injection testing, content security controls, and safe handling of session state because browser compromise can directly undermine OAuth trust.
What's in the full article
Curity's full article covers the operational detail this post intentionally leaves for the source:
- Implementation guidance for handling unsolicited SAML responses in OAuth application flows
- Practical PKCE considerations for reducing interception and replay risk in browser-based clients
- Design specifics for the token handler pattern across SPAs and API-driven backends
- Cookie and nonce behavior details that support safer browser session handling
👉 Read Curity's client security guidance on OAuth, SAML responses, and browser trust →
OAuth client security and token handling: what teams miss?
Explore further
06/07/2026 9:54 am
OAuth client security is really a trust-boundary problem, not a protocol problem. The article’s mix of SAML, PKCE, cookies, and browser security shows that compromise often happens at the seams between identity layers rather than in the core authorization grant itself. That means practitioners need to evaluate where trust is established, where it is carried forward, and where it can be broken by a client-side attacker. The practical conclusion is that OAuth program design must treat every browser boundary as potentially hostile.
A few things that frame the scale:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: How do same-site cookies help OAuth security, and where do they fall short?
A: Same-site cookies reduce some cross-site session abuse by limiting when browsers send authentication state. They do not solve XSS, unsafe redirects, or weak application logic that trusts client state too broadly. Teams should use cookie scope as one control in a broader session integrity design, not as a standalone fix.
👉 Read our full editorial: OAuth client security still depends on browser and token trust
