De la bonne utilisation de OAuth2

Bienvenue au
Identity Tech Talk France
ForgeRock

De la bonne utilisation de
OAuth2
Identity Tech Talk France
21 Mars 2019
Léonard Moustacchis
Prepared by Neil Madden

What is OAuth?
• 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)
wants to use
Resource Server (RS)
to access
Authorization Server (AS)
Request
access (scope)
Authorize access
Access token
Access token

OAuth 2 flows
• 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

Basic security measures (not covered)
• Always use HTTPS everywhere
• Basic web security best practice
• Secure, HttpOnly, SameSite cookies
• Content-Security-Policy
• Keep client credentials secret
• Don’t check into Git!
• A client_secret is not a password – should be of high entropy
• Use a unique random “state” parameter on all auth requests
• Use limited scope access tokens

Resource Server

Where to put 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

Authorization: Bearer
POST /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

How to validate 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

The fallacy of 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

Token introspection (RFC 7662)
Resource Server (RS)
Client
Access Token
Introspect
access_token=...
Valid?,
Scope=...

Q: Are we done now?

Mobile clients - 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

What’s wrong with 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=...

Recommendations
• Use system browser to
initiate flows
• Use claimed HTTPS
redirects
• iOS: Universal Links
• Android: App Links
• Use the authorization code
flow...
• ... with PKCE (RFC 7636)

PKCE: Proof Key for Code Exchange
Resource Owner (RO)
Client Resource Server (RS)
Generate random verifier, v
Request authorization
code_challenge=SHA-256(v)
Authorize as normal
Authorization code
Request access token
code=<code>&
code_verifier=<v>
Check SHA-256(v) = challenge
Access token

Web Clients

Server-side clients
• 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)

Client-side web apps/SPAs
• 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
/spa#access_token=LGqTQrz71J8...
Web Page
Legitimate
Script
Malicious
Script
/spa#access_token=Kt8Fc98cDE...

New advice for 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

Can’t move off 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)

Token binding and SPAs
• Within a web-page TLS is a shared resource
• No “same-origin” protections
• All scripts (sandboxed or not) use the same TLS connection
when talking to the same origin
• TLS-level protections are not a silver bullet
• Token binding
• mTLS constrained access tokens
• Always prefer “Authorization: Bearer”
• Triggers SOP/CORS

Key take-aways

Take-aways
• Prefer 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

THANK YOU!

De la bonne utilisation de OAuth2

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to De la bonne utilisation de OAuth2

Similar to De la bonne utilisation de OAuth2 (20)

More from Leonard Moustacchis

More from Leonard Moustacchis (20)

Recently uploaded

Recently uploaded (20)

De la bonne utilisation de OAuth2