in the identity space – co-creator of IdentityServer & IdentityModel OSS Project – certified OpenID Connect & OAuth 2.0 Engine for ASP.NET Core • Co-Founder of Duende Software – the new home of IdentityServer – https://duendesoftware.com email dominick@duendesoftware.com blog https://blog.duendesoftware.com twitter @leastprivilege slides https://speakerdeck.com/duendesoftware
applications started as "classic web apps" – "spiced up" with JavaScript over time • Cookies have been used in the first place for authentication sessions – "just worked" for doing Ajax calls as well • Cross Site Request Forgery (CSRF) was discovered
OAuth 2 the IETF tried to solve the cookie problem – encourage the use of token-based API calls in the browser – explicitly send tokens as opposed to automatic cookie transmission – OAuth 2 implicit flow to overcome same-origin restrictions • Lots of security compromises – token transport over URLs – token storage in the browser • Threat: Cross Site Scripting
have "secure" storage – by design storage is accessible via JavaScript • Code injection attacks allow exfiltration of storage content – injection attacks top threat on OWASP top ten – https://www.securityweek.com/google-releases-poc-exploit-browser-based-spectre-attack • That's why Implict Flow does not allow refresh tokens
need to be managed – in absence of refresh tokens, the "silent renew" technique has been commonly used – utilizes iFrame with session cookie to request new tokens – additional benefit of being session bound • Frontend applications needs session change notifications – JavaScript checkSession iFrame technique – relies on a session cookie in iFrame
all before mentioned techniques – OpenID Foundation also provides a certification program • We maintained a certified library over the last 7 years – oidc-client.js • Lots of pain-points – pretty complicated JavaScript necessary – ever changing JavaScript landscape – browser changes and incompatibilies
they deal with 3rd party cookies – especially in iFrames • Safari – https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/ • Chrome – https://www.theverge.com/2021/6/24/22547339/google-chrome- cookiepocalypse-delayed-2023 • Firefox, Brave…
renew – session notifications • both JS and front-channel • End result: do your own token management with refresh tokens – refresh tokens end up in the browser – requires complicated token rotation techniques (that do not really work) • Session change notifications do not work anymore – back-channel notifications rarely implemented
Best Current Practices – https://tools.ietf.org/wg/oauth/draft-ietf-oauth-browser-based-apps/ • Proposal for alternative application patterns – https://datatracker.ietf.org/doc/draft-bertocci-oauth2-tmi-bff/
stores & manages tokens • proxies cross-domain calls • Browser • stores no tokens • uses cookies JavaScript Applications with a Backend JavaScript Applications without a Backend • Browser • initiates flow • store & manages tokens • makes all API calls • use no cookies
vs "Full BFF" For the sake of clarity, in this document we will use Full BFF to refer to the approach where both token acquisition and API invocation are handled by the backend, and TMI-BFF for approaches where the frontend retain the responsibility to implement some functionality. Although the Full BFF approach offers better security, by virtue of keep all tokens out of the user agent, it is not always viable.
commercial BFF framework for ASP.NET Core • works with JavaScript and Blazor WASM applications – source code is on GitHub • https://github.com/DuendeSoftware/BFF • Fair Trade Software – free for companies and individuals with <1M USD gross revenue – commercial license for others
ASP.NET Core StaticFiles middleware • User authentication and token requests – ASP.NET Core OpenID Connect authentication handler • Secure frontend to backend communication – ASP.NET Core cookie authentication handler • SameSite cookies – additional antiforgery protection
the only technique that works reliably – BFF host should implement a logout notification endpoint – https://openid.net/specs/openid-connect-backchannel-1_0.html • ASP.NET also allows storing sessions server-side – cookie then only contains the session ID – allows server-side session termination
a static custom HTTP header will trigger CORS pre-flight request • same-origin sandbox – can be enforced via middleware POST /data Cookie: xxx X-CSRF: 1 <body>
– browsers allow for some unique attack vectors – guidance has often changed over the last years • Browser vendors optimize their security to same site scenarios – SameSite cookies – block third party cookies • Backend for Frontend takes advantage of browser sandbox and simplifies frontend code – same site and origin