More and more companies are coming to the conclusion that the threat of token exfiltration is too big of an unknown and that no high value access tokens should be stored in JavaScript-accessible locations.
It’s not only your own code that must be XSS-proof. It’s also all the frameworks, libraries, and NPM packages you are pulling in (as well as their dependencies). And even worse, you have to worry about other people’s code running on your domain.
Storing tokens on the server-side and using encrypted/signed HTTP-only cookies for session management makes that threat model considerably easier. This is not to say that this makes the application “auto-magically” secure against content injection, but forcing the attacker through a well-defined interface to the back end gives you way more leverage than being able to make arbitrary API calls with a stolen token.
Browsers are already (and will be even more in the future) restricting the usage of cookies across site boundaries to protect users from privacy invasion techniques. The problem is that legitimate OAuth and OpenID Connect protocol interactions are from a browser’s point of view, indistinguishable from common tracking mechanisms.
This affects front-channel logout notifications (used in pretty much every authentication protocol—like SAML, WS-Fed and OpenID Connect), the OpenID Connect JavaScript session management, and the “silent renew” technique that was recommended to give your application session-bound token refreshing.
To overcome these limitations, we need the help of an application back end to bridge the gap to the authentication system, do more robust server-side token management with refresh tokens, and provide support for more future-proof mechanisms like back-channel logout notifications.
Writing a robust protocol library for JavaScript is not a trivial task. There is a substantial amount of ongoing maintenance necessary due to subtle behavior changes between browsers and their versions.
On the server-side, though (and especially with ASP.NET Core), we have a fully featured and stable OpenID Connect client library that supports all the necessary protocol mechanisms and provides an excellent extensibility model for advanced features like Mutual TLS, Proof-of-Possession, JWT secured authorization requests, and JWT-based client authentication.
Putting your requirements in the center is our motivation.
All of our source code is on GitHub. Check out our documentation, quickstart, and samples.