OAuth 2: What could possibly go wrong?

OAuth 2: What could possibly go wrong? Neil Madden Security
Director, ForgeRock

Are you using OAuth today?

• Original problem: enable 3rd party apps/sites to access my data without giving them my password

• Original problem: enable 3rd party apps/sites to access my data without giving them my password • OAuth: Protocol for delegated authorisation • OAuth 1 – 2007 (RFC 5849 in 2010) • OAuth 2 – 2012 (RFC 6749)

• Original problem: enable 3rd party apps/sites to access my data without giving them my password • OAuth: Protocol for delegated authorisation • OAuth 1 – 2007 (RFC 5849 in 2010) • OAuth 2 – 2012 (RFC 6749) • Now: • Lots of extensions • Used outside of Web – mobile, IoT, microservices • Uses beyond delegated authZ – OpenID Connect, UMA

Copyright © 2018 ForgeRock. All rights reserved The Dance Client
Resource Owner (RO) Resource Server (RS)

Resource Owner (RO) wants to use Resource Server (RS)

Resource Owner (RO) wants to use Resource Server (RS) to access

Resource Owner (RO) Resource Server (RS) Authorization Server (AS)

Resource Owner (RO) Resource Server (RS) Authorization Server (AS) Request  access (scope)

Resource Owner (RO) Resource Server (RS) Authorization Server (AS) Request  access (scope) Authorize access

Resource Owner (RO) Resource Server (RS) Authorization Server (AS) Access token

• Implicit flow – access token returned directly from authorization request (redirect) • In fragment ...#access_token=LGqTQrz71J8... • Purely redirect-based

• Implicit flow – access token returned directly from authorization request (redirect) • In fragment ...#access_token=LGqTQrz71J8... • Purely redirect-based • Authorization code flow – a one-time code is returned • Client makes direct call to AS to swap code for access token • AS can directly authenticate the client

• Implicit flow – access token returned directly from authorization request (redirect) • In fragment ...#access_token=LGqTQrz71J8... • Purely redirect-based • Authorization code flow – a one-time code is returned • Client makes direct call to AS to swap code for access token • AS can directly authenticate the client • Refresh token flow • Previously authorized client • Get new access token without bothering user, extend access

Copyright © 2018 ForgeRock. All rights reserved Where to put
the access token

the access token • 4 main choices (for HTTP): • In URL parameter: ?access_token=LGqTQrz71J8... • In Cookie: Cookie: accesstoken=LGqTQrz71J8... • In POST body (form/x-www-form-urlencoded) • In a header

the access token • 4 main choices (for HTTP): • In URL parameter: ?access_token=LGqTQrz71J8... • In Cookie: Cookie: accesstoken=LGqTQrz71J8... • In POST body (form/x-www-form-urlencoded) • In a header • URL parameter – bad! • Leaks in access logs of servers, proxies, and Referer header

the access token • 4 main choices (for HTTP): • In URL parameter: ?access_token=LGqTQrz71J8... • In Cookie: Cookie: accesstoken=LGqTQrz71J8... • In POST body (form/x-www-form-urlencoded) • In a header • URL parameter – bad! • Leaks in access logs of servers, proxies, and Referer header • Cookie – beware CSRF, cookie hijacking, cookie blocking

the access token • 4 main choices (for HTTP): • In URL parameter: ?access_token=LGqTQrz71J8... • In Cookie: Cookie: accesstoken=LGqTQrz71J8... • In POST body (form/x-www-form-urlencoded) • In a header • URL parameter – bad! • Leaks in access logs of servers, proxies, and Referer header • Cookie – beware CSRF, cookie hijacking, cookie blocking • POST body – better, but mixes authorization with application data

Copyright © 2018 ForgeRock. All rights reserved Authorization: Bearer POST
/api/foo HTTP/1.1 Authorization: Bearer LGqTQrz71J8... ... HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer scope=”foo bar”

/api/foo HTTP/1.1 Authorization: Bearer LGqTQrz71J8... ... HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer scope=”foo bar” • Standard approach (RFC 6750)

/api/foo HTTP/1.1 Authorization: Bearer LGqTQrz71J8... ... HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer scope=”foo bar” • Standard approach (RFC 6750) • Middle-boxes, caches all know about Authorization headers

/api/foo HTTP/1.1 Authorization: Bearer LGqTQrz71J8... ... HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer scope=”foo bar” • Standard approach (RFC 6750) • Middle-boxes, caches all know about Authorization headers • Triggers same-origin policy/CORS protections in browsers

Copyright © 2018 ForgeRock. All rights reserved How to validate
an access token?

an access token? • Scope: up to the RS – what makes sense to the user?

an access token? • Scope: up to the RS – what makes sense to the user? • Validation unspecified: up to the AS and RS to agree • But see Token Introspection (RFC 7662)

an access token? • Scope: up to the RS – what makes sense to the user? • Validation unspecified: up to the AS and RS to agree • But see Token Introspection (RFC 7662) • Popular choice: • access token is a signed JWT • can be verified by RS alone

an access token? • Scope: up to the RS – what makes sense to the user? • Validation unspecified: up to the AS and RS to agree • But see Token Introspection (RFC 7662) • Popular choice: • access token is a signed JWT • can be verified by RS alone • But... what about revocation?

an access token? • Scope: up to the RS – what makes sense to the user? • Validation unspecified: up to the AS and RS to agree • But see Token Introspection (RFC 7662) • Popular choice: • access token is a signed JWT • can be verified by RS alone • But... what about revocation? • Answer: • Short-lived access tokens • Client must refresh frequently

Copyright © 2018 ForgeRock. All rights reserved The fallacy of
the short attack window

the short attack window • How short should access token lifetime be? • Minutes? • Hours?

the short attack window • How short should access token lifetime be? • Minutes? • Hours? • Facebook “View As” OAuth attack in September • 50 million accounts affected • 90 million access tokens revoked afterwards • Highly automated

the short attack window • How short should access token lifetime be? • Minutes? • Hours? • Facebook “View As” OAuth attack in September • 50 million accounts affected • 90 million access tokens revoked afterwards • Highly automated • How long was each compromised token used for? • Seconds? Milliseconds?

the short attack window • How short should access token lifetime be? • Minutes? • Hours? • Facebook “View As” OAuth attack in September • 50 million accounts affected • 90 million access tokens revoked afterwards • Highly automated • How long was each compromised token used for? • Seconds? Milliseconds? • Short life-times should not be primary protection measure

Copyright © 2018 ForgeRock. All rights reserved Q: Are we
done now?

Copyright © 2018 ForgeRock. All rights reserved What did we
forget?

forget? • Does the Resource Owner themselves have permission?

forget? • Does the Resource Owner themselves have permission? • Remember: OAuth is delegated authorization

forget? • Does the Resource Owner themselves have permission? • Remember: OAuth is delegated authorization • Assumes RS already has an authorization policy for users

forget? • Does the Resource Owner themselves have permission? • Remember: OAuth is delegated authorization • Assumes RS already has an authorization policy for users • AS doesn’t know anything about the RS during “authorization” call

forget? • Does the Resource Owner themselves have permission? • Remember: OAuth is delegated authorization • Assumes RS already has an authorization policy for users • AS doesn’t know anything about the RS during “authorization” call • Related: does the RO still have permission? • Access tokens with refresh can live a long time • Classic TOCTOU bug

forget? • Does the Resource Owner themselves have permission? • Remember: OAuth is delegated authorization • Assumes RS already has an authorization policy for users • AS doesn’t know anything about the RS during “authorization” call • Related: does the RO still have permission? • Access tokens with refresh can live a long time • Classic TOCTOU bug • OAuth not a replacement for authorization (but see UMA)

Mobile Clients

Copyright © 2018 ForgeRock. All rights reserved Mobile clients -
old approach

old approach • Register with AS as public client

old approach • Register with AS as public client • Use a custom URL scheme for redirect: • com.example.app:/callback • OS will handover to your app when redirect occurs

old approach • Register with AS as public client • Use a custom URL scheme for redirect: • com.example.app:/callback • OS will handover to your app when redirect occurs • Use implicit flow

old approach • Register with AS as public client • Use a custom URL scheme for redirect: • com.example.app:/callback • OS will handover to your app when redirect occurs • Use implicit flow • Spawn in-app embedded web view

Copyright © 2018 ForgeRock. All rights reserved What’s wrong with
this approach? Genuine App Authorization Server my-app:/cb?access_token=...

this approach? • Custom URL schemes are not enforced unique Genuine App Authorization Server my-app:/cb?access_token=...

this approach? • Custom URL schemes are not enforced unique • Malicious app can register same scheme Genuine App Malicious App Authorization Server my-app:/cb?access_token=...

this approach? • Custom URL schemes are not enforced unique • Malicious app can register same scheme • Either app could get handed the access token Genuine App Malicious App Authorization Server my-app:/cb?access_token=...

this approach? • Custom URL schemes are not enforced unique • Malicious app can register same scheme • Either app could get handed the access token • In-app web view: encourages poor practices Genuine App Malicious App Authorization Server my-app:/cb?access_token=...

Copyright © 2018 ForgeRock. All rights reserved Recommendations Image: https://www.flickr.com/photos/79908182@N00/4154193182
(user: smoorenburg, CC-BY-2.0)

Copyright © 2018 ForgeRock. All rights reserved Recommendations • Use
system browser to initiate flows Image: https://www.flickr.com/photos/79908182@N00/4154193182 (user: smoorenburg, CC-BY-2.0)

system browser to initiate flows • Use claimed HTTPS redirects • iOS: Universal Links • Android: App Links Image: https://www.flickr.com/photos/79908182@N00/4154193182 (user: smoorenburg, CC-BY-2.0)

system browser to initiate flows • Use claimed HTTPS redirects • iOS: Universal Links • Android: App Links • Use the authorization code flow... Image: https://www.flickr.com/photos/79908182@N00/4154193182 (user: smoorenburg, CC-BY-2.0)

system browser to initiate flows • Use claimed HTTPS redirects • iOS: Universal Links • Android: App Links • Use the authorization code flow... • ... with PKCE (RFC 7636) Image: https://www.flickr.com/photos/79908182@N00/4154193182 (user: smoorenburg, CC-BY-2.0)

Copyright © 2018 ForgeRock. All rights reserved PKCE: Proof Key
for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS)

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Generate random verifier, v

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Request authorization  code_challenge=SHA-256(v)

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Authorize as normal

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Authorization code

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Request access token  code=<code>&  code_verifier=<v>

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Request access token  code=<code>&  code_verifier=<v> Check SHA-256(v) = challenge

for Code Exchange Resource Owner (RO) Client Resource Server (RS) Authorization Server (AS) Access token

Use authorization code flow • Confidential client, so require authentication to AS

Use authorization code flow • Confidential client, so require authentication to AS • What can go wrong?

Use authorization code flow • Confidential client, so require authentication to AS • What can go wrong? • Credential theft • Client secret recoverable from AS • Consider private_key_jwt or mTLS authentication

Use authorization code flow • Confidential client, so require authentication to AS • What can go wrong? • Credential theft • Client secret recoverable from AS • Consider private_key_jwt or mTLS authentication • Code injection attack (replay) • Use PKCE on server-side too! • (But quite difficult attack model if using state properly)

• Old advice: use implicit flow /spa#access_token=LGqTQrz71J8... Web Page Legitimate  Script

• Old advice: use implicit flow • What can go wrong? /spa#access_token=LGqTQrz71J8... Web Page Legitimate  Script

• Old advice: use implicit flow • What can go wrong? • Token sniffing from URL /spa#access_token=LGqTQrz71J8... Web Page Legitimate  Script Malicious  Script

• Old advice: use implicit flow • What can go wrong? • Token sniffing from URL • Referer leaks (document.referrer in iframe) • But fragment not usually included /spa#access_token=LGqTQrz71J8... Web Page Legitimate  Script Malicious  Script

• Old advice: use implicit flow • What can go wrong? • Token sniffing from URL • Referer leaks (document.referrer in iframe) • But fragment not usually included • Token injection Web Page Legitimate  Script Malicious  Script /spa#access_token=Kt8Fc98cDE...

• Old advice: use implicit flow • What can go wrong? • Token sniffing from URL • Referer leaks (document.referrer in iframe) • But fragment not usually included • Token injection • Redirects include fragment Web Page Legitimate  Script Malicious  Script /spa#access_token=Kt8Fc98cDE...

SPAs • One big change since OAuth 2.0 published (2012):

SPAs • One big change since OAuth 2.0 published (2012): • CORS! • Published in 2014

SPAs • One big change since OAuth 2.0 published (2012): • CORS! • Published in 2014 • Previously not possible for SPA to make cross-origin call to AS

SPAs • One big change since OAuth 2.0 published (2012): • CORS! • Published in 2014 • Previously not possible for SPA to make cross-origin call to AS • CORS changes that – allows SPA to use authorization code flow

SPAs • One big change since OAuth 2.0 published (2012): • CORS! • Published in 2014 • Previously not possible for SPA to make cross-origin call to AS • CORS changes that – allows SPA to use authorization code flow • New advice: auth code + PKCE • Public client, just like for mobile

implicit? • Don’t Panic!

implicit? • Don’t Panic! • The sky isn’t falling • Web security best practice goes a long way

implicit? • Don’t Panic! • The sky isn’t falling • Web security best practice goes a long way • Mitigations:

implicit? • Don’t Panic! • The sky isn’t falling • Web security best practice goes a long way • Mitigations: • Use OpenID Connect flows • ID Token includes “at_hash”, “nonce” – prevents injection • Consider even if you don’t care about authentication

implicit? • Don’t Panic! • The sky isn’t falling • Web security best practice goes a long way • Mitigations: • Use OpenID Connect flows • ID Token includes “at_hash”, “nonce” – prevents injection • Consider even if you don’t care about authentication • JARM – JWT-secure Authorization Response Mode

implicit? • Don’t Panic! • The sky isn’t falling • Web security best practice goes a long way • Mitigations: • Use OpenID Connect flows • ID Token includes “at_hash”, “nonce” – prevents injection • Consider even if you don’t care about authentication • JARM – JWT-secure Authorization Response Mode • Sender-constrained access tokens (PoP)

the authorization code flow in all cases • Even for SPAs • Implicit likely to be deprecated • Use PKCE • Even for confidential clients

the authorization code flow in all cases • Even for SPAs • Implicit likely to be deprecated • Use PKCE • Even for confidential clients • Prefer Authorization: Bearer

the authorization code flow in all cases • Even for SPAs • Implicit likely to be deprecated • Use PKCE • Even for confidential clients • Prefer Authorization: Bearer • Security drafts in progress: • draft-ietf-oauth-security-topics • draft-parecki-oauth-browser-based-apps

OAuth 2: What could possibly go wrong?

OAuth 2: What could possibly go wrong?

Other Decks in Programming

Featured

Transcript