on Application Security Architectures – Working with Software Development Teams (ISVs and in-house) • Co-Creator of IdentityServer & IdentityModel OSS Project – Certified OpenID Connect & OAuth 2.0 Implementation for .NET – https://identityserver.io • Co-Creator of PolicyServer – Modern Authorization Solution – https://policyserver.io email dominick.baier@leastprivilege.com blog https://leastprivilege.com twitter @leastprivilege slides https://speakerdeck.com/leastprivilege
building clients • Look at recommended approaches for several client types – server to server – web applications – native/mobile applications – SPAs • Give you references to further reading material
via Authorization header – form body or query string as alternative Authorization: Bearer <token> GET /service/resource https://tools.ietf.org/html/rfc6750
authenticate user – start/join session – make API calls on behalf of the user • Typical client challenges – how to securely retrieve access token – access token storage & lifetime management – session management
substitution attack – client can be tricked into using its client secret with a leaked/stolen code • Different mitigation approaches – OpenID Connect: Hybrid Flow – OAuth2: Proof Key for Code Exchange (PKCE)
client libraries – id_token validation – cryptographic linking of artifacts • Identity token via front channel – might leak identity information – at least sub
tokens have finite lifetimes – requesting a new token requires browser round trip to authorization server – should be as short lived as possible • Refresh tokens allow renewal semantics – no user interaction required – typically combined with a revocation feature
Supports both Hybrid Flow and PKCE – PKCE recommended • Token storage using session mechanism – can revoke refresh tokens at logout time (if not needed anymore) • Automatic token management by plugging in IdentityModel.AspNetCore – https://github.com/IdentityModel/IdentityModel.AspNetCore
only looked at server-based clients – typically unique client IDs – can store a secret securely • Public clients cannot store a client secret securely – e.g. SPAs, mobile apps – 1:many mapping of client id to instance • Dynamic client registration can turn public into confidential client – additional bootstrapping infrastructure necessary
stored using secure data storage provided by OS – e.g. KeyChain on iOS, DPAPI on Windows… – some support additional security mechanisms (e.g. biometrics) • Refresh can be automated by client libraries – e.g. using HTTP message handler & HttpClient • Tokens can be revoked when not needed anymore – logout – uninstall
most problematic client type from a security point of view – but also most popular client type • Unique attacks due to "shared execution environment" nature of browser – Cross-Site Request Forgery (CSRF) – Cross-Site Scripting (XSS) • Ongoing work in IETF to produce useful guidance – https://tools.ietf.org/html/draft-parecki-oauth-browser-based-apps
SPAs • Implicit credential that browser sends automatically – Cookies – Integrated Windows authentication (Kerberos) – X509 client certificates • Explicit credential that must be sent from application code – Tokens
Browser only sends cookie from page in same origin • Decent browser support (as of mid-2019) https://caniuse.com/#search=samesite HTTP/1.1 200 OK Set-Cookie: key=value; HttpOnly; SameSite=strict
Same-site cookies is still new – Some people still on older browsers • API must have server-side code to issue cookie to browser – Easy for legacy/mixed, more work for modern/SPA • Application must be same origin as API – Will your app always be the same domain as the API(s)? • Browser-based app is only app that can call the API – Will you ever want other apps to use the API?
a different form of credential – Commonly use JSON web token (JWT) – Sent via authorization header to authenticate HTTP request – Provides solution to CSRF that combines anti-forgery and authentication • Tokens help solve the architectural issues – More than just browser-based apps can use tokens – No cookie management needed in API – Can call APIs cross-domain
Regardless of the flow, tokens will be stored in the browser – e.g. session storage – prone to XSS-based attacks • potential exfiltration of tokens • even worse with refresh tokens – Content Security Policy (CSP) highly recommend – but not always easy • Not recommended to use refresh tokens in SPAs – rather use "token renew" technique – renewal bound to session
cookies + anti forgery protection APIs access token client https://leastprivilege.com/2019/01/18/an-alternative-way-to-secure-spas-with-asp-net-core-openid-connect-oauth-2-0-and-proxykit/
Dominick Baier
leastprivilege
reverentgeek
rmw
skipperchong
carmenhchung
keathley
productmarketing
clairelew
thoeni
jcasabona
