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 [email protected] 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
– which protocol flow to use? – is a user involved? • Manage token – where to store them? – how to renew the token? – is long-lived access required? • Use token
– authenticate user • UI workflows – start/join (single sign-on) session • listening to session change notifications • potentially coordinating token storage with session lifetime – make API calls on behalf of the user – silently renew tokens • To accommodate all of these requirements, Authorization Code Flow was created
only designed for confidential clients • Code 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)
• Built-in features make writing clients easy – OpenID Connect authentication handler supports Hybrid Flow • extensibility points to customize behavior – token storage mechanism that is automatically tied to session • uses cookies for storage by default • can be replaced with distributed cache • can be used for automatic token lifetime management • Can revoke refresh tokens at logout time (if not needed anymore) https://leastprivilege.com/2019/01/14/automatic-oauth-2-0-token-management-in-asp-net-core/
client libraries – id_token validation – cryptographic linking of artifacts • Identity token via front channel – might leak identity information – at least sub
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
PKCE (RFC 7636) introduces a per-request client secret – allows binding front–channel to back-channel client – prohibits token substitution – also works without a client secret • Similar goals as nonce and c_hash approach – independent of OpenID Connect – verification happens on the token server
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
client and APIs are in same application or origin – cookies are used to secure AJAX calls • Problems and limitations – Cross-Site Request forgery • mitigation techniques well understood, but require extra work – cross-domain API access – non-browser API clients
flow is out-dated – relies solely on # vs ? handling in browser for leakage protection – tokens end up in URL history in browser – traditionally no protection against token substitution attacks • OpenID Connect added at_hash claim • needs client side crypto similar to Hybrid Flow • IETF wants to deprecate Implicit Flow – CORS widely deployed now – use Code Flow + PKCE instead
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 recommended – but not always easy* – HTTP token binding might help in the future** • Token renewal should be tied to session lifetime – "Silent renew" technique – bind refresh tokens to session * https://www.youtube.com/watch?v=uf12a-0AluI ** https://groups.google.com/a/chromium.org/forum/#!topic/net-dev/8QD01FloF1o
SameSite Cookies • Can prevent all cross-origin usages of cookies • On by default for ASP.NET Core authentication cookies – LAX only https://caniuse.com/#search=samesite
+ same site cookies 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/