2 @duendeidentity Me • 15+ years consulting and project work 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 [email protected] blog https://blog.duendesoftware.com twitter @leastprivilege slides https://speakerdeck.com/duendesoftware
3 @duendeidentity Agenda • Some history – the cookie era – the token era – problems • Getting the best of both worlds – Backend for Frontend Pattern – TMI BFF vs "full BFF"
6 @duendeidentity History 1 – The Cookie Era • Most 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
9 @duendeidentity History 2 – The Token Era • With 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
13 @duendeidentity Challenge: Token Storage • The browser does not 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
14 @duendeidentity Challenge: Token and Session Management • Access 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
15 @duendeidentity JavaScript Client Libraries • Good client libraries implement 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
16 @duendeidentity Browser Changes (1) • Browsers more restrictive how 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…
17 @duendeidentity Browser Changes (2) • Affected features – silent 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
18 @duendeidentity Browser Changes (3) • Browser vendors emphasize the "same site" sandbox and architecture – SameSite cookies – CORS for additional sandboxing September 2021
19 @duendeidentity New IETF Recommendations • OAuth for Browser-based Applications 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/
20 @duendeidentity • Application Server • iniates protocol flow • 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
21 @duendeidentity Backend for Frontend Pattern (BFF) • TMI BFF 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.
24 @duendeidentity Building a BFF with ASP.NET Core Session Management OpenID Connect/OAuth Client Library Token Management UI Assets BFF Host Local / Remote API Endpoints
25 @duendeidentity Duende.BFF • Full disclosure – we built a 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
28 @duendeidentity Triggering login/logout • Frontend can trigger login and logout operations by invoking application- local endpoints GET /bff/login GET /bff/logout
30 @duendeidentity Session Management / Query • Frontend can retrieve session information • Or check current session state GET /bff/user GET /bff/user?slide=false
31 @duendeidentity Session Change Notifications • Backchannel logout notifications is 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
32 @duendeidentity Calling local APIs • Antiforgery protection – requiring 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
34 @duendeidentity Summary • Securing browser-based applications is not trivial – 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
duendesoftware
ohnoeight
johanjanssens
ericgpks
koic
eatplaynap
mthiroshi00excite
yuya4
ivargrimstad
masayaaoyama
manfredsteyer
shintanimoto
michaelherold
jensimmons
chrislema
trishagee
philhawksworth
keithpitt
colly
samlambert
nonsquared
eitanlees
tammielis
rasmusluckow