draft-ietf-oauth-v2-threatmodel-07.txt   draft-ietf-oauth-v2-threatmodel-08.txt 
OAuth Working Group T. Lodderstedt, Ed. OAuth Working Group T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational M. McGloin Intended status: Informational M. McGloin
Expires: February 15, 2013 IBM Expires: April 9, 2013 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
August 14, 2012 October 6, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-07 draft-ietf-oauth-v2-threatmodel-08
Abstract Abstract
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth 2.0 specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2013. This Internet-Draft will expire on April 9, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 8 2.3. Architectural assumptions . . . . . . . . . . . . . . . . 8
2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8
2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8
2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Limited Access Token Lifetime . . . . . . . . . . . . 11 3.1.2. Limited Access Token Lifetime . . . . . . . . . . . . 11
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12
3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12 3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 13
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 13 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 13
3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13 3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 17
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 19
4.1.4. Threat: End-user credentials phished using 4.1.4. Threat: End-user credentials phished using
compromised or embedded browser . . . . . . . . . . . 19 compromised or embedded browser . . . . . . . . . . . 19
4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 20 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 20
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 20 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 20
4.2.1. Threat: Password phishing by counterfeit 4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 20 authorization server . . . . . . . . . . . . . . . . . 20
4.2.2. Threat: User unintentionally grants too much 4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 21 access scope . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Threat: Malicious client obtains existing 4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 21 authorization by fraud . . . . . . . . . . . . . . . . 21
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22
4.3.2. Threat: Obtain access tokens from authorization 4.3.2. Threat: Obtain access tokens from authorization
server database . . . . . . . . . . . . . . . . . . . 22 server database . . . . . . . . . . . . . . . . . . . 23
4.3.3. Threat: Disclosure of client credentials during 4.3.3. Threat: Disclosure of client credentials during
transmission . . . . . . . . . . . . . . . . . . . . . 23 transmission . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. Threat: Obtain client secret from authorization 4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 23 server database . . . . . . . . . . . . . . . . . . . 23
4.3.5. Threat: Obtain client secret by online guessing . . . 23 4.3.5. Threat: Obtain client secret by online guessing . . . 24
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24
4.4.1.1. Threat: Eavesdropping or leaking authorization 4.4.1.1. Threat: Eavesdropping or leaking authorization
codes . . . . . . . . . . . . . . . . . . . . . . 24 codes . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1.2. Threat: Obtain authorization codes from 4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 25 authorization server database . . . . . . . . . . 25
4.4.1.3. Threat: Online guessing of authorization codes . . 26 4.4.1.3. Threat: Online guessing of authorization codes . . 26
4.4.1.4. Threat: Malicious client obtains authorization . . 26 4.4.1.4. Threat: Malicious client obtains authorization . . 26
4.4.1.5. Threat: Authorization code phishing . . . . . . . 27 4.4.1.5. Threat: Authorization code phishing . . . . . . . 28
4.4.1.6. Threat: User session impersonation . . . . . . . . 28 4.4.1.6. Threat: User session impersonation . . . . . . . . 28
4.4.1.7. Threat: Authorization code leakage through 4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 29 counterfeit client . . . . . . . . . . . . . . . . 29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31
4.4.1.9. Threat: Clickjacking attack against 4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 31 authorization . . . . . . . . . . . . . . . . . . 31
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33
4.4.1.12. Threat: DoS using manufactured authorization 4.4.1.12. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 33 codes . . . . . . . . . . . . . . . . . . . . . . 34
4.4.1.13. Threat: Code substitution (OAuth Login) . . . . . 35 4.4.1.13. Threat: Code substitution (OAuth Login) . . . . . 35
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 36 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 36
4.4.2.1. Threat: Access token leak in 4.4.2.1. Threat: Access token leak in
transport/end-points . . . . . . . . . . . . . . . 36 transport/end-points . . . . . . . . . . . . . . . 36
4.4.2.2. Threat: Access token leak in browser history . . . 36 4.4.2.2. Threat: Access token leak in browser history . . . 37
4.4.2.3. Threat: Malicious client obtains authorization . . 36 4.4.2.3. Threat: Malicious client obtains authorization . . 37
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 37 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 38
4.4.2.6. Threat: Token substitution (OAuth Login) . . . . . 38 4.4.2.6. Threat: Token substitution (OAuth Login) . . . . . 38
4.4.3. Resource Owner Password Credentials . . . . . . . . . 39 4.4.3. Resource Owner Password Credentials . . . . . . . . . 39
4.4.3.1. Threat: Accidental exposure of passwords at 4.4.3.1. Threat: Accidental exposure of passwords at
client site . . . . . . . . . . . . . . . . . . . 40 client site . . . . . . . . . . . . . . . . . . . 40
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 40 authorization . . . . . . . . . . . . . . . . . . 40
4.4.3.3. Threat: Client obtains refresh token through 4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 41 automatic authorization . . . . . . . . . . . . . 41
4.4.3.4. Threat: Obtain user passwords on transport . . . . 41 4.4.3.4. Threat: Obtain user passwords on transport . . . . 42
4.4.3.5. Threat: Obtain user passwords from 4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 41 authorization server database . . . . . . . . . . 42
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 42 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 43
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 42 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 43
4.5.1. Threat: Eavesdropping refresh tokens from 4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 42 authorization server . . . . . . . . . . . . . . . . . 43
4.5.2. Threat: Obtaining refresh token from authorization 4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 43 server database . . . . . . . . . . . . . . . . . . . 43
4.5.3. Threat: Obtain refresh token by online guessing . . . 43 4.5.3. Threat: Obtain refresh token by online guessing . . . 44
4.5.4. Threat: Obtain refresh token phishing by 4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 43 counterfeit authorization server . . . . . . . . . . . 44
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44
4.6.1. Threat: Eavesdropping access tokens on transport . . . 44 4.6.1. Threat: Eavesdropping access tokens on transport . . . 44
4.6.2. Threat: Replay authorized resource server requests . . 44 4.6.2. Threat: Replay authorized resource server requests . . 45
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45
4.6.4. Threat: Access token phishing by counterfeit 4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 45 resource server . . . . . . . . . . . . . . . . . . . 46
4.6.5. Threat: Abuse of token by legitimate resource 4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 46 server or client . . . . . . . . . . . . . . . . . . . 46
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 46 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 47
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 46 referrers . . . . . . . . . . . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 47 5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 47 5.1.1. Ensure confidentiality of requests . . . . . . . . . . 48
5.1.2. Server authentication . . . . . . . . . . . . . . . . 48 5.1.2. Utiliize server authentication . . . . . . . . . . . . 48
5.1.3. Always keep the resource owner informed . . . . . . . 48 5.1.3. Always keep the resource owner informed . . . . . . . 49
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49
5.1.4.1. Credential Storage Protection . . . . . . . . . . 49 5.1.4.1. Enforce credential storage protection best
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 50 practices . . . . . . . . . . . . . . . . . . . . 50
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 51 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 51
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 51 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 52
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 52
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52
5.1.5.3. Short expiration time . . . . . . . . . . . . . . 52 5.1.5.3. Use short expiration time . . . . . . . . . . . . 53
5.1.5.4. Limit number of usages/ One time usage . . . . . . 53 5.1.5.4. Limit number of usages/ One time usage . . . . . . 53
5.1.5.5. Bind tokens to a particular resource server 5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 53 (Audience) . . . . . . . . . . . . . . . . . . . . 54
5.1.5.6. Use endpoint address as token audience . . . . . . 53 5.1.5.6. Use endpoint address as token audience . . . . . . 54
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 54 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 55
5.1.5.10. Encryption of token content . . . . . . . . . . . 54 5.1.5.10. Encryption of token content . . . . . . . . . . . 55
5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 54 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 55
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55
5.2.1.1. Automatic revocation of derived tokens if 5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 55 abuse is detected . . . . . . . . . . . . . . . . 55
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 55 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 56
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 55 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 56
5.2.2.2. Binding of refresh token to client_id . . . . . . 55 5.2.2.2. Binding of refresh token to client_id . . . . . . 56
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 56 5.2.2.4. Revoke refresh tokens . . . . . . . . . . . . . . 57
5.2.2.5. Device identification . . . . . . . . . . . . . . 56 5.2.2.5. Device identification . . . . . . . . . . . . . . 57
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57
5.2.3. Client authentication and authorization . . . . . . . 57 5.2.3. Client authentication and authorization . . . . . . . 57
5.2.3.1. Don't issue secrets to client with 5.2.3.1. Don't issue secrets to client with
inappropriate security policy . . . . . . . . . . 57 inappropriate security policy . . . . . . . . . . 58
5.2.3.2. Public clients without secret require user
consent . . . . . . . . . . . . . . . . . . . . . 58 5.2.3.2. Require user consent for public clients
5.2.3.3. Client_id only in combination with redirect_uri . 58 without secret . . . . . . . . . . . . . . . . . . 59
5.2.3.4. Installation-specific client secrets . . . . . . . 58 5.2.3.3. Client_id only in combination with redirect_uri . 59
5.2.3.5. Validation of pre-registered redirect_uri . . . . 59 5.2.3.4. Installation-specific client secrets . . . . . . . 59
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 60 5.2.3.5. Validation of pre-registered redirect_uri . . . . 60
5.2.3.6. Revoke client secrets . . . . . . . . . . . . . . 61
5.2.3.7. Use strong client authentication (e.g. 5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 60 client_assertion / client_token) . . . . . . . . . 61
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 60 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 61
5.2.4.1. Automatic processing of repeated 5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 61 authorizations requires client validation . . . . 61
5.2.4.2. Informed decisions based on transparency . . . . . 61 5.2.4.2. Informed decisions based on transparency . . . . . 62
5.2.4.3. Validation of client properties by end-user . . . 61 5.2.4.3. Validation of client properties by end-user . . . 62
5.2.4.4. Binding of authorization code to client_id . . . . 61 5.2.4.4. Binding of authorization code to client_id . . . . 62
5.2.4.5. Binding of authorization code to redirect_uri . . 62 5.2.4.5. Binding of authorization code to redirect_uri . . 62
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 62 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 63
5.3.1. Don't store credentials in code or resources 5.3.1. Don't store credentials in code or resources
bundled with software packages . . . . . . . . . . . . 62 bundled with software packages . . . . . . . . . . . . 63
5.3.2. Standard web server protection measures (for 5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 62 config files and databases) . . . . . . . . . . . . . 63
5.3.3. Store secrets in a secure storage . . . . . . . . . . 62 5.3.3. Store secrets in a secure storage . . . . . . . . . . 63
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 63 access . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3.5. Link state parameter to user agent session . . . . . . 63 5.3.5. Link state parameter to user agent session . . . . . . 64
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 63 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 64
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 63 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 64
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 64 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 65
5.5. A Word on User Interaction and User-Installed Apps . . . . 65 5.5. A Word on User Interaction and User-Installed Apps . . . . 65
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
8.1. Informative References . . . . . . . . . . . . . . . . . . 66 8.1. Informative References . . . . . . . . . . . . . . . . . . 67
8.2. Informative References . . . . . . . . . . . . . . . . . . 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 67
Appendix A. Document History . . . . . . . . . . . . . . . . . . 68 Appendix A. Document History . . . . . . . . . . . . . . . . . . 69
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
1. Introduction 1. Introduction
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
contains the following content: contains the following content:
o Documents any assumptions and scope considered when creating the o Documents any assumptions and scope considered when creating the
threat model. threat model.
skipping to change at page 6, line 37 skipping to change at page 6, line 37
particular grant type or all threats for protecting the resource particular grant type or all threats for protecting the resource
server. server.
Note: This document cannot assess the probability nor the risk Note: This document cannot assess the probability nor the risk
associated with a particular threat because those aspects strongly associated with a particular threat because those aspects strongly
depend on the particular application and deployment OAuth is used to depend on the particular application and deployment OAuth is used to
protect. Similar, impacts are given on a rather abstract level. But protect. Similar, impacts are given on a rather abstract level. But
the information given here may serve as a foundation for deployment- the information given here may serve as a foundation for deployment-
specific threat models. Implementors may refine and detail the specific threat models. Implementors may refine and detail the
abstract threat model in order to account for the specific properties abstract threat model in order to account for the specific properties
of their deployment and to come up with a risk analysis. of their deployment and to come up with a risk analysis. As this
document is based on the base OAuth 2.0 specification, itdoes not
consider proposed extensions, such as client registration or
discovery, many of which are still under discussion.
2. Overview 2. Overview
2.1. Scope 2.1. Scope
The security considerations document only considers clients bound to The security considerations document only considers clients bound to
a particular deployment as supported by [I-D.ietf-oauth-v2]. Such a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
deployments have the following characteristics: deployments have the following characteristics:
o Resource server URLs are static and well-known at development o Resource server URLs are static and well-known at development
skipping to change at page 15, line 39 skipping to change at page 16, line 8
This section describes possible threats directed to OAuth clients. This section describes possible threats directed to OAuth clients.
4.1.1. Threat: Obtain Client Secrets 4.1.1. Threat: Obtain Client Secrets
The attacker could try to get access to the secret of a particular The attacker could try to get access to the secret of a particular
client in order to: client in order to:
o replay its refresh tokens and authorization codes, or o replay its refresh tokens and authorization codes, or
o obtain tokens on behalf of the attacked client with the privileges o obtain tokens on behalf of the attacked client with the privileges
of that client. of that client_id acting as an instance of the client.
The resulting impact would be: The resulting impact would be:
o Client authentication of access to authorization server can be o Client authentication of access to authorization server can be
bypassed bypassed
o Stolen refresh tokens or authorization codes can be replayed o Stolen refresh tokens or authorization codes can be replayed
Depending on the client category, the following attacks could be Depending on the client category, the following attacks could be
utilized to obtain the client secret. utilized to obtain the client secret.
skipping to change at page 16, line 21 skipping to change at page 16, line 36
attacker. Even if an application takes significant measures to attacker. Even if an application takes significant measures to
obfuscate secrets in their application distribution one should obfuscate secrets in their application distribution one should
consider that the secret can still be reverse-engineered by anyone consider that the secret can still be reverse-engineered by anyone
with access to a complete functioning application bundle or binary. with access to a complete functioning application bundle or binary.
Countermeasures: Countermeasures:
o Don't issue secrets to public clients or clients with o Don't issue secrets to public clients or clients with
inappropriate security policy - Section 5.2.3.1 inappropriate security policy - Section 5.2.3.1
o Public clients require user consent - Section 5.2.3.2 o Require user consent for public clients- Section 5.2.3.2
o Use deployment-specific client secrets - Section 5.2.3.4 o Use deployment-specific client secrets - Section 5.2.3.4
o Client secret revocation - Section 5.2.3.6 o Revoke client secrets - Section 5.2.3.6
Attack: Obtain a Deployment-Specific Secret: Attack: Obtain a Deployment-Specific Secret:
An attacker may try to obtain the secret from a client installation, An attacker may try to obtain the secret from a client installation,
either from a web site (web server) or a particular devices (native either from a web site (web server) or a particular devices (native
application). application).
Countermeasures: Countermeasures:
o Web server: apply standard web server protection measures (for o Web server: apply standard web server protection measures (for
config files and databases) - Section 5.3.2 config files and databases) - Section 5.3.2
o Native applications: Store secrets in a secure local storage - o Native applications: Store secrets in a secure local storage -
Section 5.3.3 Section 5.3.3
o Client secret revocation - Section 5.2.3.6 o Revoke client secrets - Section 5.2.3.6
4.1.2. Threat: Obtain Refresh Tokens 4.1.2. Threat: Obtain Refresh Tokens
Depending on the client type, there are different ways refresh tokens Depending on the client type, there are different ways refresh tokens
may be revealed to an attacker. The following sub-sections give a may be revealed to an attacker. The following sub-sections give a
more detailed description of the different attacks with respect to more detailed description of the different attacks with respect to
different client types and further specialized countermeasures. different client types and further specialized countermeasures.
Before detailing those threats, here are some generally applicable Before detailing those threats, here are some generally applicable
countermeasures: countermeasures:
o The authorization server should validate the client id associated o The authorization server should validate the client id associated
with the particular refresh token with every refresh request- with the particular refresh token with every refresh request-
Section 5.2.2.2 Section 5.2.2.2
o Limited scope tokens - Section 5.1.5.1 o Limit token scope - Section 5.1.5.1
o Refresh token revocation - Section 5.2.2.4 o Revoke refresh tokens - Section 5.2.2.4
o Client secret revocation - Section 5.2.3.6 o Revoke client secrets - Section 5.2.3.6
o Refresh tokens can automatically be replaced in order to detect o Refresh tokens can automatically be replaced in order to detect
unauthorized token usage by another party (Refresh Token Rotation) unauthorized token usage by another party (Refresh Token Rotation)
- Section 5.2.2.3 - Section 5.2.2.3
Attack: Obtain Refresh Token from Web application: Attack: Obtain Refresh Token from Web application:
An attacker may obtain the refresh tokens issued to a web application An attacker may obtain the refresh tokens issued to a web application
by way of overcoming the web server's security controls. Impact: by way of overcoming the web server's security controls. Impact:
Since a web application manages the user accounts of a certain site, Since a web application manages the user accounts of a certain site,
such an attack would result in an exposure of all refresh tokens on such an attack would result in an exposure of all refresh tokens on
that side to the attacker. that site to the attacker.
Countermeasures: Countermeasures:
o Standard web server protection measures - Section 5.3.2 o Standard web server protection measures - Section 5.3.2
o Use strong client authentication (e.g. client_assertion / o Use strong client authentication (e.g. client_assertion /
client_token), so the attacker cannot obtain the client secret client_token), so the attacker cannot obtain the client secret
required to exchange the tokens - Section 5.2.3.7 required to exchange the tokens - Section 5.2.3.7
Attack: Obtain Refresh Token from Native clients: Attack: Obtain Refresh Token from Native clients:
skipping to change at page 19, line 8 skipping to change at page 19, line 23
Impact: Where the token is a bearer token and no additional mechanism Impact: Where the token is a bearer token and no additional mechanism
is used to identify the client, the attacker can access all resources is used to identify the client, the attacker can access all resources
associated with the token and its scope. associated with the token and its scope.
Countermeasures: Countermeasures:
o Keep access tokens in transient memory and limit grants: o Keep access tokens in transient memory and limit grants:
Section 5.1.6 Section 5.1.6
o Limited scope tokens - Section 5.1.5.1 o Limit token scope - Section 5.1.5.1
o Keep access tokens in private memory or apply same protection o Keep access tokens in private memory or apply same protection
means as for refresh tokens - Section 5.2.2 means as for refresh tokens - Section 5.2.2
o Keep access token lifetime short - Section 5.1.5.3 o Keep access token lifetime short - Section 5.1.5.3
4.1.4. Threat: End-user credentials phished using compromised or 4.1.4. Threat: End-user credentials phished using compromised or
embedded browser embedded browser
A malicious application could attempt to phish end-user passwords by A malicious application could attempt to phish end-user passwords by
skipping to change at page 20, line 41 skipping to change at page 21, line 11
ARP spoofing. Wide deployment of OAuth and similar protocols may ARP spoofing. Wide deployment of OAuth and similar protocols may
cause users to become inured to the practice of being redirected to cause users to become inured to the practice of being redirected to
websites where they are asked to enter their passwords. If users are websites where they are asked to enter their passwords. If users are
not careful to verify the authenticity of these websites before not careful to verify the authenticity of these websites before
entering their credentials, it will be possible for attackers to entering their credentials, it will be possible for attackers to
exploit this practice to steal Users' passwords. exploit this practice to steal Users' passwords.
Countermeasures: Countermeasures:
o Authorization servers should consider such attacks when developing o Authorization servers should consider such attacks when developing
services based on OAuth, and should require transport-layer services based on OAuth, and should require the use of transport-
security for any requests where the authenticity of the layer security for any requests where the authenticity of the
authorization server or of request responses is an issue (see authorization server or of request responses is an issue (see
Section 5.1.2). Section 5.1.2).
o Authorization servers should attempt to educate Users about the o Authorization servers should attempt to educate Users about the
risks phishing attacks pose, and should provide mechanisms that risks phishing attacks pose, and should provide mechanisms that
make it easy for users to confirm the authenticity of their sites. make it easy for users to confirm the authenticity of their sites.
4.2.2. Threat: User unintentionally grants too much access scope 4.2.2. Threat: User unintentionally grants too much access scope
When obtaining end user authorization, the end-user may not When obtaining end user authorization, the end-user may not
skipping to change at page 21, line 43 skipping to change at page 22, line 11
client. Instead of prompting the user for approval, the client. Instead of prompting the user for approval, the
authorization server automatically redirects the user back to the authorization server automatically redirects the user back to the
client. client.
A malicious client may exploit that feature and try to obtain such an A malicious client may exploit that feature and try to obtain such an
authorization code instead of the legitimate client. authorization code instead of the legitimate client.
Countermeasures: Countermeasures:
o Authorization servers should not automatically process repeat o Authorization servers should not automatically process repeat
authorizations to public clients or unless the client is validated authorizations to public clients unless the client is validated
using a pre-registered redirect URI (Section 5.2.3.5 ) using a pre-registered redirect URI (Section 5.2.3.5 )
o Authorization servers can mitigate the risks associated with o Authorization servers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens automatic processing by limiting the scope of Access Tokens
obtained through automated approvals - Section 5.1.5.1 obtained through automated approvals - Section 5.1.5.1
4.2.4. Threat: Open redirector 4.2.4. Threat: Open redirector
An attacker could use the end-user authorization endpoint and the An attacker could use the end-user authorization endpoint and the
redirection URI parameter to abuse the authorization server as an redirection URI parameter to abuse the authorization server as an
skipping to change at page 23, line 5 skipping to change at page 23, line 19
4.3.2. Threat: Obtain access tokens from authorization server database 4.3.2. Threat: Obtain access tokens from authorization server database
This threat is applicable if the authorization server stores access This threat is applicable if the authorization server stores access
tokens as handles in a database. An attacker may obtain access tokens as handles in a database. An attacker may obtain access
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. Impact: disclosure the database or launching a SQL injection attack. Impact: disclosure
of all access tokens of all access tokens
Countermeasures: Countermeasures:
o System security measures - Section 5.1.4.1.1 o Enforce system security measures - Section 5.1.4.1.1
o Store access token hashes only - Section 5.1.4.1.3 o Store access token hashes only - Section 5.1.4.1.3
o Standard SQL injection Countermeasures - Section 5.1.4.1.2 o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
4.3.3. Threat: Disclosure of client credentials during transmission 4.3.3. Threat: Disclosure of client credentials during transmission
An attacker could attempt to eavesdrop the transmission of client An attacker could attempt to eavesdrop the transmission of client
credentials between client and server during the client credentials between client and server during the client
authentication process or during OAuth token requests. authentication process or during OAuth token requests.
Impact: Revelation of a client credential enabling phishing or Impact: Revelation of a client credential enabling phishing or
impersonation of a client service. impersonation of a client service.
skipping to change at page 23, line 39 skipping to change at page 24, line 5
4.3.4. Threat: Obtain client secret from authorization server database 4.3.4. Threat: Obtain client secret from authorization server database
An attacker may obtain valid client_id/secret combinations from the An attacker may obtain valid client_id/secret combinations from the
authorization server's database by gaining access to the database or authorization server's database by gaining access to the database or
launching a SQL injection attack. Impact: disclosure of all launching a SQL injection attack. Impact: disclosure of all
client_id/secret combinations. This allows the attacker to act on client_id/secret combinations. This allows the attacker to act on
behalf of legitimate clients. behalf of legitimate clients.
Countermeasures: Countermeasures:
o System security measures - Section 5.1.4.1.1 o Enforce system security measures - Section 5.1.4.1.1
o Standard SQL injection Countermeasures - Section 5.1.4.1.2 o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
o Ensure proper handling of credentials as per Credential Storage o Ensure proper handling of credentials as per Enforce credential
Protection. storage protection best practices.
4.3.5. Threat: Obtain client secret by online guessing 4.3.5. Threat: Obtain client secret by online guessing
An attacker may try to guess valid client_id/secret pairs. Impact: An attacker may try to guess valid client_id/secret pairs. Impact:
disclosure of single client_id/secret pair. disclosure of single client_id/secret pair.
Countermeasures: Countermeasures:
o High entropy of secrets - Section 5.1.4.2.2 o Use high entropy for secrets - Section 5.1.4.2.2
o Lock accounts - Section 5.1.4.2.3 o Lock accounts - Section 5.1.4.2.3
o Use Strong Client Authentication - Section 5.2.3.7 o Use Strong Client Authentication - Section 5.2.3.7
4.4. Obtaining Authorization 4.4. Obtaining Authorization
This section covers threats which are specific to certain flows This section covers threats which are specific to certain flows
utilized to obtain access tokens. Each flow is characterized by utilized to obtain access tokens. Each flow is characterized by
response types and/or grant types on the end-user authorization and response types and/or grant types on the end-user authorization and
skipping to change at page 25, line 14 skipping to change at page 25, line 28
o As per the core OAuth spec, the authorization server as well as o As per the core OAuth spec, the authorization server as well as
the client must ensure that these transmissions are protected the client must ensure that these transmissions are protected
using transport-layer mechanisms such as TLS (see Section 5.1.1). using transport-layer mechanisms such as TLS (see Section 5.1.1).
o The authorization server will require the client to authenticate o The authorization server will require the client to authenticate
wherever possible, so the binding of the authorization code to a wherever possible, so the binding of the authorization code to a
certain client can be validated in a reliable way (see certain client can be validated in a reliable way (see
Section 5.2.4.4). Section 5.2.4.4).
o Limited duration of authorization codes - Section 5.1.5.3 o Use short expiry time for authorization codes - Section 5.1.5.3
o The authorization server should enforce a one time usage o The authorization server should enforce a one time usage
restriction (see Section 5.1.5.4). restriction (see Section 5.1.5.4).
o If an Authorization Server observes multiple attempts to redeem an o If an Authorization Server observes multiple attempts to redeem an
authorization code, the Authorization Server may want to revoke authorization code, the Authorization Server may want to revoke
all tokens granted based on the authorization code (see all tokens granted based on the authorization code (see
Section 5.2.1.1). Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope o In the absence of these countermeasures, reducing scope
skipping to change at page 25, line 38 skipping to change at page 26, line 4
o The client server may reload the target page of the redirection o The client server may reload the target page of the redirection
URI in order to automatically cleanup the browser cache. URI in order to automatically cleanup the browser cache.
4.4.1.2. Threat: Obtain authorization codes from authorization server 4.4.1.2. Threat: Obtain authorization codes from authorization server
database database
This threat is applicable if the authorization server stores This threat is applicable if the authorization server stores
authorization codes as handles in a database. An attacker may obtain authorization codes as handles in a database. An attacker may obtain
authorization codes from the authorization server's database by authorization codes from the authorization server's database by
gaining access to the database or launching a SQL injection attack. gaining access to the database or launching a SQL injection attack.
Impact: disclosure of all authorization codes, most likely along with Impact: disclosure of all authorization codes, most likely along with
the respective redirect_uri and client_id values. the respective redirect_uri and client_id values.
Countermeasures: Countermeasures:
o Best practices for credential storage protection should be o Best practices for credential storage protection should be
employed - Section 5.1.4.1 employed - Section 5.1.4.1
o System security measures - Section 5.1.4.1.1 o Enforce system security measures - Section 5.1.4.1.1
o Store access token hashes only - Section 5.1.4.1.3 o Store access token hashes only - Section 5.1.4.1.3
o Standard SQL injection countermeasures - Section 5.1.4.1.2 o Standard SQL injection countermeasures - Section 5.1.4.1.2
4.4.1.3. Threat: Online guessing of authorization codes 4.4.1.3. Threat: Online guessing of authorization codes
An attacker may try to guess valid authorization code values and send An attacker may try to guess valid authorization code values and send
it using the grant type "code" in order to obtain a valid access it using the grant type "code" in order to obtain a valid access
token. token.
skipping to change at page 26, line 26 skipping to change at page 26, line 40
o Handle-based tokens must use high entropy: Section 5.1.4.2.2 o Handle-based tokens must use high entropy: Section 5.1.4.2.2
o Assertion-based tokens should be signed: Section 5.1.5.9 o Assertion-based tokens should be signed: Section 5.1.5.9
o Authenticate the client, adds another value the attacker has to o Authenticate the client, adds another value the attacker has to
guess - Section 5.2.3.4 guess - Section 5.2.3.4
o Binding of authorization code to redirection URI, adds another o Binding of authorization code to redirection URI, adds another
value the attacker has to guess - Section 5.2.4.5 value the attacker has to guess - Section 5.2.4.5
o Short expiration time - Section 5.1.5.3 o Use short expiry time for tokens - Section 5.1.5.3
4.4.1.4. Threat: Malicious client obtains authorization 4.4.1.4. Threat: Malicious client obtains authorization
A malicious client could pretend to be a valid client and obtain an A malicious client could pretend to be a valid client and obtain an
access authorization that way. The malicious client could even access authorization that way. The malicious client could even
utilize screen scraping techniques in order to simulate the user utilize screen scraping techniques in order to simulate the user
consent in the authorization flow. consent in the authorization flow.
Assumption: It is not the task of the authorization server to protect Assumption: It is not the task of the authorization server to protect
the end-user's device from malicious software. This is the the end-user's device from malicious software. This is the
skipping to change at page 36, line 42 skipping to change at page 37, line 12
TLS) of the response from the authorization server to the client TLS) of the response from the authorization server to the client
(see Section 5.1.1). (see Section 5.1.1).
4.4.2.2. Threat: Access token leak in browser history 4.4.2.2. Threat: Access token leak in browser history
An attacker could obtain the token from the browser's history. Note An attacker could obtain the token from the browser's history. Note
this means the attacker needs access to the particular device. this means the attacker needs access to the particular device.
Countermeasures: Countermeasures:
o Shorten token duration (see Section 5.1.5.3) and reduced scope of o Use short expiry time for tokens (see Section 5.1.5.3) and reduced
the token may reduce the impact of that attack (see scope of the token may reduce the impact of that attack (see
Section 5.1.5.1). Section 5.1.5.1).
o Make responses non-cachable o Make responses non-cachable
4.4.2.3. Threat: Malicious client obtains authorization 4.4.2.3. Threat: Malicious client obtains authorization
A malicious client could attempt to obtain a token by fraud. A malicious client could attempt to obtain a token by fraud.
The same countermeasures as for Section 4.4.1.4 are applicable, The same countermeasures as for Section 4.4.1.4 are applicable,
except client authentication. except client authentication.
skipping to change at page 40, line 22 skipping to change at page 40, line 44
disgruntled employee could retrieve the passwords for a user. disgruntled employee could retrieve the passwords for a user.
Countermeasures: Countermeasures:
o Use other flows, which do not rely on the client's cooperation for o Use other flows, which do not rely on the client's cooperation for
secure resource owner credential handling secure resource owner credential handling
o Use digest authentication instead of plaintext credential o Use digest authentication instead of plaintext credential
processing processing
o Obfuscation of passwords in logs o Obfuscate passwords in logs
4.4.3.2. Threat: Client obtains scopes without end-user authorization 4.4.3.2. Threat: Client obtains scopes without end-user authorization
All interaction with the resource owner is performed by the client. All interaction with the resource owner is performed by the client.
Thus it might, intentionally or unintentionally, happen that the Thus it might, intentionally or unintentionally, happen that the
client obtains a token with scope unknown for or unintended by the client obtains a token with scope unknown for or unintended by the
resource owner. For example, the resource owner might think the resource owner. For example, the resource owner might think the
client needs and acquires read-only access to its media storage only client needs and acquires read-only access to its media storage only
but the client tries to acquire an access token with full access but the client tries to acquire an access token with full access
permissions. permissions.
skipping to change at page 41, line 39 skipping to change at page 42, line 14
4.4.3.4. Threat: Obtain user passwords on transport 4.4.3.4. Threat: Obtain user passwords on transport
An attacker could attempt to eavesdrop the transmission of end-user An attacker could attempt to eavesdrop the transmission of end-user
credentials with the grant type "password" between client and server. credentials with the grant type "password" between client and server.
Impact: disclosure of a single end-users password. Impact: disclosure of a single end-users password.
Countermeasures: Countermeasures:
o Confidentiality of Requests - Section 5.1.1 o Ensure confidentiality of requests - Section 5.1.1
o alternative authentication means, which do not require to send o alternative authentication means, which do not require to send
plaintext credentials over the wire (e.g. Hash-based Message plaintext credentials over the wire (e.g. Hash-based Message
Authentication Code) Authentication Code)
4.4.3.5. Threat: Obtain user passwords from authorization server 4.4.3.5. Threat: Obtain user passwords from authorization server
database database
An attacker may obtain valid username/password combinations from the An attacker may obtain valid username/password combinations from the
authorization server's database by gaining access to the database or authorization server's database by gaining access to the database or
launching a SQL injection attack. launching a SQL injection attack.
Impact: disclosure of all username/password combinations. The impact Impact: disclosure of all username/password combinations. The impact
may exceed the domain of the authorization server since many users may exceed the domain of the authorization server since many users
tend to use the same credentials on different services. tend to use the same credentials on different services.
Countermeasures: Countermeasures:
o Credential storage protection can be employed - Section 5.1.4.1 o Enforce credential storage protection best practices -
Section 5.1.4.1
4.4.3.6. Threat: Online guessing 4.4.3.6. Threat: Online guessing
An attacker may try to guess valid username/password combinations An attacker may try to guess valid username/password combinations
using the grant type "password". using the grant type "password".
Impact: Revelation of a single username/password combination. Impact: Revelation of a single username/password combination.
Countermeasures: Countermeasures:
o Password policy - Section 5.1.4.2.1 o Utilize secure password policy - Section 5.1.4.2.1
o Lock accounts - Section 5.1.4.2.3 o Lock accounts - Section 5.1.4.2.3
o Tar pit - Section 5.1.4.2.4 o Use tar pit - Section 5.1.4.2.4
o CAPTCHA - Section 5.1.4.2.5
o Use CAPTCHAs - Section 5.1.4.2.5
o Consider not to use grant type "password" o Consider not to use grant type "password"
o Client authentication (see Section 5.2.3) will provide another o Client authentication (see Section 5.2.3) will provide another
authentication factor and thus hinder the attack. authentication factor and thus hinder the attack.
4.4.4. Client Credentials 4.4.4. Client Credentials
Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an
identifier (not secret) combined with an additional means (such as a identifier (not secret) combined with an additional means (such as a
matching client secret) of authenticating a client. The threats to matching client secret) of authenticating a client. The threats to
skipping to change at page 43, line 22 skipping to change at page 43, line 46
This threat is applicable if the authorization server stores refresh This threat is applicable if the authorization server stores refresh
tokens as handles in a database. An attacker may obtain refresh tokens as handles in a database. An attacker may obtain refresh
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. the database or launching a SQL injection attack.
Impact: disclosure of all refresh tokens Impact: disclosure of all refresh tokens
Countermeasures: Countermeasures:
o Credential storage protection - Section 5.1.4.1 o Enforce credential storage protection best practices -
Section 5.1.4.1
o Bind token to client id, if the attacker cannot obtain the o Bind token to client id, if the attacker cannot obtain the
required id and secret - Section 5.1.5.8 required id and secret - Section 5.1.5.8
4.5.3. Threat: Obtain refresh token by online guessing 4.5.3. Threat: Obtain refresh token by online guessing
An attacker may try to guess valid refresh token values and send it An attacker may try to guess valid refresh token values and send it
using the grant type "refresh_token" in order to obtain a valid using the grant type "refresh_token" in order to obtain a valid
access token. access token.
skipping to change at page 44, line 9 skipping to change at page 44, line 36
authorization server authorization server
An attacker could try to obtain valid refresh tokens by proxying An attacker could try to obtain valid refresh tokens by proxying
requests to the authorization server. Given the assumption that the requests to the authorization server. Given the assumption that the
authorization server URL is well-known at development time or can at authorization server URL is well-known at development time or can at
least be obtained from a well-known resource server, the attacker least be obtained from a well-known resource server, the attacker
must utilize some kind of spoofing in order to succeed. must utilize some kind of spoofing in order to succeed.
Countermeasures: Countermeasures:
o Server authentication (as described in Section 5.1.2) o Utilize server authentication (as described in Section 5.1.2)
4.6. Accessing Protected Resources 4.6. Accessing Protected Resources
4.6.1. Threat: Eavesdropping access tokens on transport 4.6.1. Threat: Eavesdropping access tokens on transport
An attacker could try to obtain a valid access token on transport An attacker could try to obtain a valid access token on transport
between client and resource server. As access tokens are shared between client and resource server. As access tokens are shared
secrets between authorization and resource server, they should be secrets between authorization and resource server, they should be
treated with the same care as other credentials (e.g. end-user treated with the same care as other credentials (e.g. end-user
passwords). passwords).
skipping to change at page 47, line 31 skipping to change at page 48, line 16
This section describes the countermeasures as recommended to mitigate This section describes the countermeasures as recommended to mitigate
the threats as described in Section 4. the threats as described in Section 4.
5.1. General 5.1. General
The general section covers considerations that apply generally across The general section covers considerations that apply generally across
all OAuth components (client, resource server, token server, and all OAuth components (client, resource server, token server, and
user-agents). user-agents).
5.1.1. Confidentiality of Requests 5.1.1. Ensure confidentiality of requests
This is applicable to all requests sent from client to authorization This is applicable to all requests sent from client to authorization
server or resource server. While OAuth provides a mechanism for server or resource server. While OAuth provides a mechanism for
verifying the integrity of requests, it provides no guarantee of verifying the integrity of requests, it provides no guarantee of
request confidentiality. Unless further precautions are taken, request confidentiality. Unless further precautions are taken,
eavesdroppers will have full access to request content and may be eavesdroppers will have full access to request content and may be
able to mount interception or replay attacks through using content of able to mount interception or replay attacks through using content of
request, e.g. secrets or tokens. request, e.g. secrets or tokens.
Attacks can be mitigated by using transport-layer mechanisms such as Attacks can be mitigated by using transport-layer mechanisms such as
skipping to change at page 48, line 15 skipping to change at page 48, line 48
o Replay of access tokens obtained on tokens endpoint or resource o Replay of access tokens obtained on tokens endpoint or resource
server's endpoint server's endpoint
o Replay of refresh tokens obtained on tokens endpoint o Replay of refresh tokens obtained on tokens endpoint
o Replay of authorization codes obtained on tokens endpoint o Replay of authorization codes obtained on tokens endpoint
(redirect?) (redirect?)
o Replay of user passwords and client secrets o Replay of user passwords and client secrets
5.1.2. Server authentication 5.1.2. Utiliize server authentication
HTTPS server authentication or similar means can be used to HTTPS server authentication or similar means can be used to
authenticate the identity of a server. The goal is to reliably bind authenticate the identity of a server. The goal is to reliably bind
the fully qualified domain name of the server to the public key the fully qualified domain name of the server to the public key
presented by the server during connection establishment (see presented by the server during connection establishment (see
[RFC2818]). [RFC2818]).
The client should validate the binding of the server to its domain The client should validate the binding of the server to its domain
name. If the server fails to prove that binding, it is considered a name. If the server fails to prove that binding, it is considered a
man-in-the-middle attack. The security measure depends on the man-in-the-middle attack. The security measure depends on the
skipping to change at page 49, line 20 skipping to change at page 50, line 5
o User self-care applications or portals o User self-care applications or portals
5.1.4. Credentials 5.1.4. Credentials
This sections describes countermeasures used to protect all kinds of This sections describes countermeasures used to protect all kinds of
credentials from unauthorized access and abuse. Credentials are long credentials from unauthorized access and abuse. Credentials are long
term secrets, such as client secrets and user passwords as well as term secrets, such as client secrets and user passwords as well as
all kinds of tokens (refresh and access token) or authorization all kinds of tokens (refresh and access token) or authorization
codes. codes.
5.1.4.1. Credential Storage Protection 5.1.4.1. Enforce credential storage protection best practices
Administrators should undertake industry best practices to protect Administrators should undertake industry best practices to protect
the storage of credentials (see for example [owasp]). Such practices the storage of credentials (see for example [owasp]). Such practices
may include but are not limited to the following sub-sections. may include but are not limited to the following sub-sections.
5.1.4.1.1. Standard System Security Means 5.1.4.1.1. Enforce Standard System Security Means
A server system may be locked down so that no attacker may get access A server system may be locked down so that no attacker may get access
to sensible configuration files and databases. to sensible configuration files and databases.
5.1.4.1.2. Standard SQL Injection Countermeasures 5.1.4.1.2. Enforce standard SQL Injection Countermeasures
If a client identifier or other authentication component is queried If a client identifier or other authentication component is queried
or compared against a SQL Database it may become possible for an or compared against a SQL Database it may become possible for an
injection attack to occur if parameters received are not validated injection attack to occur if parameters received are not validated
before submission to the database. before submission to the database.
o Ensure that server code is using the minimum database privileges o Ensure that server code is using the minimum database privileges
possible to reduce the "surface" of possible attacks. possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use o Avoid dynamic SQL using concatenated input. If possible, use
skipping to change at page 50, line 34 skipping to change at page 51, line 16
makes client applications vulnerable to scanning as well as difficult makes client applications vulnerable to scanning as well as difficult
to administer should client credentials change over time. to administer should client credentials change over time.
5.1.4.1.5. Use of asymmetric cryptography 5.1.4.1.5. Use of asymmetric cryptography
Usage of asymmetric cryptography will free the authorization server Usage of asymmetric cryptography will free the authorization server
of the obligation to manage credentials. of the obligation to manage credentials.
5.1.4.2. Online attacks on secrets 5.1.4.2. Online attacks on secrets
5.1.4.2.1. Password policy 5.1.4.2.1. Utilize secure password policy
The authorization server may decide to enforce a complex user The authorization server may decide to enforce a complex user
password policy in order to increase the user passwords' entropy to password policy in order to increase the user passwords' entropy to
hinder online password attacks. Note that too much complexity can hinder online password attacks. Note that too much complexity can
increase the liklihood that users re-use passwords or write them down increase the liklihood that users re-use passwords or write them down
or otherwise store them insecurely. or otherwise store them insecurely.
5.1.4.2.2. High entropy of secrets 5.1.4.2.2. Use high entropy for secrets
When creating secrets not intended for usage by human users (e.g. When creating secrets not intended for usage by human users (e.g.
client secrets or token handles), the authorization server should client secrets or token handles), the authorization server should
include a reasonable level of entropy in order to mitigate the risk include a reasonable level of entropy in order to mitigate the risk
of guessing attacks. The token value should be >=128 bits long and of guessing attacks. The token value should be >=128 bits long and
constructed from a cryptographically strong random or pseudo-random constructed from a cryptographically strong random or pseudo-random
number sequence (see [RFC4086] for best current practice) generated number sequence (see [RFC4086] for best current practice) generated
by the Authorization Server. by the Authorization Server.
5.1.4.2.3. Lock accounts 5.1.4.2.3. Lock accounts
Online attacks on passwords can be mitigated by locking the Online attacks on passwords can be mitigated by locking the
respective accounts after a certain number of failed attempts. respective accounts after a certain number of failed attempts.
Note: This measure can be abused to lock down legitimate service Note: This measure can be abused to lock down legitimate service
users. users.
5.1.4.2.4. Tar pit 5.1.4.2.4. Use tar pit
The authorization server may react on failed attempts to authenticate The authorization server may react on failed attempts to authenticate
by username/password by temporarily locking the respective account by username/password by temporarily locking the respective account
and delaying the response for a certain duration. This duration may and delaying the response for a certain duration. This duration may
increase with the number of failed attempts. The objective is to increase with the number of failed attempts. The objective is to
slow the attackers attempts on a certain username down. slow the attackers attempts on a certain username down.
Note: this may require a more complex and stateful design of the Note: this may require a more complex and stateful design of the
authorization server. authorization server.
5.1.4.2.5. Usage of CAPTCHAs 5.1.4.2.5. Usa CAPTCHAs
The idea is to prevent programs from automatically checking huge The idea is to prevent programs from automatically checking huge
number of passwords by requiring human interaction. number of passwords by requiring human interaction.
Note: this has a negative impact on user experience. Note: this has a negative impact on user experience.
5.1.5. Tokens (access, refresh, code) 5.1.5. Tokens (access, refresh, code)
5.1.5.1. Limit token scope 5.1.5.1. Limit token scope
skipping to change at page 52, line 33 skipping to change at page 53, line 14
o risk associated to a token leakage o risk associated to a token leakage
o duration of the underlying access grant, o duration of the underlying access grant,
o duration until the modification of an access grant should take o duration until the modification of an access grant should take
effect, and effect, and
o time required for an attacker to guess or produce valid token. o time required for an attacker to guess or produce valid token.
5.1.5.3. Short expiration time 5.1.5.3. Use short expiration time
A short expiration time for tokens is a protection means against the A short expiration time for tokens is a protection means against the
following threats: following threats:
o replay o replay
o reduce impact of token leak o reduce impact of token leak
o reduce likelihood of successful online guessing o reduce likelihood of successful online guessing
skipping to change at page 56, line 27 skipping to change at page 57, line 5
revoked. revoked.
The OAuth specification supports this measure in that the tokens The OAuth specification supports this measure in that the tokens
response allows the authorization server to return a new refresh response allows the authorization server to return a new refresh
token even for requests with grant type "refresh_token". token even for requests with grant type "refresh_token".
Note: this measure may cause problems in clustered environments since Note: this measure may cause problems in clustered environments since
usage of the currently valid refresh token must be ensured. In such usage of the currently valid refresh token must be ensured. In such
an environment, other measures might be more appropriate. an environment, other measures might be more appropriate.
5.2.2.4. Refresh Token Revocation 5.2.2.4. Revoke refresh tokens
The authorization server may allow clients or end-users to explicitly The authorization server may allow clients or end-users to explicitly
request the invalidation of refresh tokens. A mechanism to revoke request the invalidation of refresh tokens. A mechanism to revoke
tokens is specified in [I-D.ietf-oauth-revocation]. tokens is specified in [I-D.ietf-oauth-revocation].
This is a countermeasure against: This is a countermeasure against:
o device theft, o device theft,
o impersonation of resource owner, or o impersonation of resource owner, or
skipping to change at page 58, line 21 skipping to change at page 59, line 5
code of the application or a associated resource bundle, is not code of the application or a associated resource bundle, is not
protected from reverse engineering. Secondly, such secrets cannot be protected from reverse engineering. Secondly, such secrets cannot be
revoked since this would immediately put all installations out of revoked since this would immediately put all installations out of
work. Moreover, since the authorization server cannot really trust work. Moreover, since the authorization server cannot really trust
the client's identifier, it would be dangerous to indicate to end- the client's identifier, it would be dangerous to indicate to end-
users the trustworthiness of the client. users the trustworthiness of the client.
There are other ways to achieve a reasonable security level, as There are other ways to achieve a reasonable security level, as
described in the following sections. described in the following sections.
5.2.3.2. Public clients without secret require user consent 5.2.3.2. Require user consent for public clients without secret
Authorization servers should not allow automatic authorization for Authorization servers should not allow automatic authorization for
public clients. The authorization may issue an individual client id, public clients. The authorization may issue an individual client id,
but should require that all authorizations are approved by the end- but should require that all authorizations are approved by the end-
user. This is a countermeasure for clients without secret against user. This is a countermeasure for clients without secret against
the following threats: the following threats:
o Impersonation of public client applications o Impersonation of public client applications
5.2.3.3. Client_id only in combination with redirect_uri 5.2.3.3. Client_id only in combination with redirect_uri
skipping to change at page 60, line 25 skipping to change at page 61, line 11
this security measure. this security measure.
Note: Pre-registering clients might not scale in some deployments Note: Pre-registering clients might not scale in some deployments
(manual process) or require dynamic client registration (not (manual process) or require dynamic client registration (not
specified yet). With the lack of dynamic client registration, pre- specified yet). With the lack of dynamic client registration, pre-
registered "redirect_uri" only works for clients bound to certain registered "redirect_uri" only works for clients bound to certain
deployments at development/configuration time. As soon as dynamic deployments at development/configuration time. As soon as dynamic
resource server discovery is required, the pre-registered resource server discovery is required, the pre-registered
redirect_uri may be no longer feasible. redirect_uri may be no longer feasible.
5.2.3.6. Client secret revocation 5.2.3.6. Revoke client secrets
An authorization server may revoke a client's secret in order to An authorization server may revoke a client's secret in order to
prevent abuse of a revealed secret. prevent abuse of a revealed secret.
Note: This measure will immediately invalidate any authorization code Note: This measure will immediately invalidate any authorization code
or refresh token issued to the respective client. This might be or refresh token issued to the respective client. This might be
unintentionally impact client identifiers and secrets used across unintentionally impact client identifiers and secrets used across
multiple deployments of a particular native or web application. multiple deployments of a particular native or web application.
This a countermeasure against: This a countermeasure against:
skipping to change at page 66, line 43 skipping to change at page 67, line 36
8.2. Informative References 8.2. Informative References
[I-D.gondrom-x-frame-options] [I-D.gondrom-x-frame-options]
Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
draft-gondrom-x-frame-options-00 (work in progress), draft-gondrom-x-frame-options-00 (work in progress),
March 2012. March 2012.
[I-D.ietf-oauth-assertions] [I-D.ietf-oauth-assertions]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0", "Assertion Framework for OAuth 2.0",
draft-ietf-oauth-assertions-04 (work in progress), draft-ietf-oauth-assertions-06 (work in progress),
July 2012. September 2012.
[I-D.ietf-oauth-json-web-token] [I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-03 (work in (JWT)", draft-ietf-oauth-json-web-token-03 (work in
progress), July 2012. progress), July 2012.
[I-D.ietf-oauth-revocation] [I-D.ietf-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-00 (work in Revocation", draft-ietf-oauth-revocation-01 (work in
progress), May 2012. progress), October 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[IMEI] 3GPP, "International Mobile station Equipment Identities [IMEI] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 3.3.0, July 2002. (IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
skipping to change at page 70, line 4 skipping to change at page 70, line 42
o Synchronisation with the core's security consideration section o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15) (UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation o Added Resource Owner Impersonation
o Improved section 5 o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02 draft-ietf-oauth-v2-threatmodel-02
o Incoporated Tim Bray's review comments (e.g. removed all normative o Incoporated Tim Bray's review comments (e.g. removed all normative
language) language)
draft-ietf-oauth-v2-threatmodel-03 draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback o incorporated shepherd review feedback
draft-ietf-oauth-v2-threatmodel-06
o incorporated AD review feedback o incorporated AD review feedback
draft-ietf-oauth-v2-threatmodel-07 draft-ietf-oauth-v2-threatmodel-07
o added new section on token substituation o added new section on token substituation
o made references to core and bearer normative o made references to core and bearer normative
Authors' Addresses Authors' Addresses
 End of changes. 88 change blocks. 
129 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/