This document summarizes OAuth 2.0 threat landscapes and best practices for mitigation. It discusses threats such as CSRF, session injection, token leakage, IDP mix-up, and token reuse/misuse. Recommended mitigations include using the state parameter, PKCE, short-lived tokens, TLS, white-listing callback URLs, scoped tokens, audience restriction, OpenID Connect, and throttling. The document provides technical details on various OAuth 2.0 flows and threats as well as references to relevant IETF draft specifications.

1. OAuth 2.0 Threat Landscapes
Prabath Siriwardena (@prabath)
Cloud Identity Summit, 2017.

2. ABOUT ME
2
▪ The Senior Director of Security Architecture, WSO2
▪ Authored the book Advanced API Security - and three more

3. OAUTH 2.0 RECAP

4. OAUTH 2.0
4

5. AUTHORIZATION CODE
5

6. IMPLICIT
6

7. CLIENT CREDENTIALS
7

8. RESOURCE OWNER PASSWORD
8

9. THREATS / MITIGATIONS / BEST PRACTICES

10. ▪ CSRF (Cross Site Request Forgery)
○ The attacker tries to log into the target website (OAuth 2.0 client) with his
account at the corresponding identity provider.
○ The attacker blocks the redirection to the target web site, and captures the
authorization code. The target web site never sees the code.
○ The attacker constructs the callback URL for the target site - and lets the victim,
clicks on it.
○ The victim logs into the target web site, with the account attached to the
attacker - and adds credit card information.
○ The attacker too logs into the target website with his/her valid credentials and
uses victim’s credit card to buy goods.
10
SESSION INJECTION
THREATS

11. ▪ Short-lived authorization code
▪ Use the state parameter as defined in the OAuth 2.0 specification.
○ Generate a random number and pass it to the authorization server along with
the grant request.
○ Before redirecting to the authorization server, add the generated value of the
state to the current user session.
○ Authorization server has to return back the same state value with the
authorization code to the return_uri.
○ The client has to validate the state value returned from the authorization server
with the value stored in the user’s current session - if mismatches - reject
moving forward.
11
MITIGATIONS / BEST PRACTICES
SESSION INJECTION

12. ▪ Use Proof Key for Code Exchange (PKCE)
○ https://tools.ietf.org/html/rfc7636
12
MITIGATIONS / BEST PRACTICES
SESSION INJECTION

13. ▪ The OAuth 2.0 client app generates a random number
(code_verifier) and finds the SHA256 hash of it - which
is called the code_challenge
▪ Send the code_challenge along with the hashing
method in the authorization grant request to the
authorization server.
▪ Authorization server records the code_challenge and
replies back with the code.
▪ The client sends the code_verifier along with the
authorization code to the token endpoint.
13
PROOF KEY FOR CODE EXCHANGE

14. TOKEN LEAKAGE
▪ Attacker may attempt to eavesdrop authorization code/access token/
refresh token in transit from the authorization server to the client.
○ Malware installed in the browser (public clients)
○ Browser history (public clients / URI fragments)
○ Intercept the TLS communication between the client (confidential) and the
authorization server (exploiting vulnerabilities at the TLS layer)
▪ Heartbleed
▪ Logjam
▪ Authorization Code Flow Open Redirector
14
THREATS

15. ▪ A malicious app can register itself as a handler for the same custom
scheme as of a legitimate OAuth 2.0 native app, can get hold of the
authorization code.
▪ Attacker may attempt a brute force attack to crack the authorization
code/access token.
▪ Attacker may attempt to steal the authorization code/access token/
refresh token stored in the authorization server.
▪ IdP Mix-Up / Malicious Endpoint
15
THREATS
TOKEN LEAKAGE

16. ▪ The OAuth 2.0 app provides multiple IdP options to login.
▪ The victim picks foo.idp from the browser - the attacker intercepts
the request and change the selection to evil.idp.
▪ The client thinks it’s evil.idp and redirects the user to evil.idp.
▪ The attacker intercepts the redirection and modify the redirection
to go to the foo.idp.
▪ The client gets either the code or the token (based on the grant
type) and now will talk to the evil.idp to validate.
▪ The evil.idp gets hold of user’s access token or the authorization
code from the foo.idp.
16
IDP MIXUP

17. ▪ Always on TLS (use TLS 1.2 or later)
▪ Address all the TLS level vulnerabilities both at the client, authorization
server and the resource server.
▪ The token value should be >=128 bits long and constructed from a
cryptographically strong random or pseudo-random number sequence.
▪ Never store tokens in clear text - but the salted hash.
▪ Short-lived tokens.
○ LinkedIn has an expiration of 30 seconds for its authorization codes.
17
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE

18. ▪ The token expiration time would depend on the following parameters.
○ Risk associated with token leakage
○ Duration of the underlying access grant
○ Time required for an attacker to guess or produce a valid token
▪ One-time authorization code
▪ One-time access token (implicit grant type)
▪ Use PKCE (proof key for code exchange) to avoid authorization code
interception attack.
○ Have S256 as the code challenge method
▪ Enforce standard SQL injection countermeasures
18
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE

19. ▪ Avoid using the same client_id/client_secret for each instance of a
mobile app - rather use the Dynamic Client Registration API to
generate a key pair per instance.
○ Most of the time the leakage of authorization code becomes a threat when the
attacker is in hold of the client id and client secret.
▪ Restrict grant types by client.
○ Most of the authorization servers do support all core grant types. If unrestricted,
leakage of client id/client secret gives the attacker the opportunity obtain an
access token via client credentials grant type.
19
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE

20. ▪ Enable client authentication via a much secured manner.
○ JWT client assertions
○ TLS mutual authentication
○ Have a key of size 2048 bits or larger if RSA algorithms are used for the client
authentication
○ Have a key of size 160 bits or larger if elliptic curve algorithms are used for the
client authentication
▪ White-list callback URLs (redirect_uri)
○ The absolute URL or a regEx pattern
20
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE

21. ▪ IdP-Mixup
○ Use different callback URLs by IdP
○ https://tools.ietf.org/html/draft-ietf-oauth-mix-up-mitigation-01
ols.ietf.org/html/draft-ietf-oauth-mix-up-mitigaon-01
▪ Token Binding
○ https://tools.ietf.org/html/draft-ietf-tokbind-protocol
○ https://tools.ietf.org/html/draft-ietf-tokbind-negotiation
○ https://tools.ietf.org/html/draft-ietf-tokbind-https
○ https://tools.ietf.org/html/draft-ietf-oauth-token-binding
21
MITIGATIONS / BEST PRACTICES
TOKEN LEAKAGE

22. TOKEN REUSE/MISUSE
▪ A malicious resource (an API / Microservice) could reuse an access
token used to access itself by a legitimate client to access another
resource, impersonating the original client.
▪ An evil web site gets an access token from a legitimate user, can
reuse it at another web site (which trusts the same authorization
server) with the implicit grant type
○ https://target-app/callback?access_token=<access_token>
▪ A legitimate user misuses an access token (issued under implicit grant
type/SPA) to access a set of backend APIs in a way, exhausting
server resources.
22
THREATS

23. ▪ Use scoped access tokens. Qualify the scope name, with a namespace
unique to the resource (resource server).
▪ The client obtains the access token for a given audience - by passing
the audience information (representing the resource server) to the
token endpoint - as per https://tools.ietf.org/id/draft-tschofenig-oauth-
audience-00.html.
▪ Use OAuth for authorization not for authentication.
○ Use OpenID Connect for authentication
23
MITIGATIONS / BEST PRACTICES
TOKEN REUSE/MISUSE

24. ▪ To avoid exhausting resources at the server side, enforce throttle limits
by user by application. In case an attacker wants to misuse a token -
the worst he/she can do is to eat his/her own quota.
24
MITIGATIONS / BEST PRACTICES
TOKEN REUSE/MISUSE

25. OPEN TECHNOLOGY FOR YOUR AGILE DIGITAL BUSINESS
THANK YOU