< draft-ietf-oauth-v2-threatmodel-01.txt   draft-ietf-oauth-v2-threatmodel-02.txt >
Web Authorization Protocol (oauth) T. Lodderstedt, Ed. Web Authorization Protocol (oauth) T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational M. McGloin Intended status: Informational M. McGloin
Expires: April 28, 2012 IBM Expires: August 22, 2012 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
October 26, 2011 February 19, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-01 draft-ietf-oauth-v2-threatmodel-02
Abstract Abstract
This document gives security considerations based on a comprehensive This document gives security considerations based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 28, 2012. This Internet-Draft will expire on August 22, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 7 2.3. Architectural assumptions . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 12
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12
3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12 3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12
4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14 4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . 16
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18
4.1.4. Threat: End-user credentials phished using 4.1.4. Threat: End-user credentials phished using
compromised or embedded browser . . . . . . . . . . . 18 compromised or embedded browser . . . . . . . . . . . 18
4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19
4.2.1. Threat: Password phishing by counterfeit 4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 19 authorization server . . . . . . . . . . . . . . . . . 20
4.2.2. Threat: User unintentionally grants too much 4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 20 access scope . . . . . . . . . . . . . . . . . . . . . 20
4.2.3. Threat: Malicious client obtains existing 4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 20 authorization by fraud . . . . . . . . . . . . . . . . 21
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . 21 server database . . . . . . . . . . . . . . . . . . . 22
4.3.3. Threat: Obtain client credentials over non secure 4.3.3. Threat: Obtain client credentials over non secure
transport . . . . . . . . . . . . . . . . . . . . . . 22 transport . . . . . . . . . . . . . . . . . . . . . . 22
4.3.4. Threat: Obtain client secret from authorization 4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 22 server database . . . . . . . . . . . . . . . . . . . 23
4.3.5. Threat: Obtain client secret by online guessing . . . 22 4.3.5. Threat: Obtain client secret by online guessing . . . 23
4.3.6. Threat: DoS on dynamic client secret creation . . . . 23 4.3.6. Threat: DoS on dynamic client secret creation . . . . 23
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 23 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 . . . . . . . . . . . . . . . . . . . . . . 23 codes . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1.2. Threat: Obtain authorization codes from 4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 24 authorization server database . . . . . . . . . . 25
4.4.1.3. Threat: Online guessing of authorization codes . . 25 4.4.1.3. Threat: Online guessing of authorization codes . . 25
4.4.1.4. Threat: Malicious client obtains authorization . . 25 4.4.1.4. Threat: Malicious client obtains authorization . . 26
4.4.1.5. Threat: Authorization code phishing . . . . . . . 26 4.4.1.5. Threat: Authorization code phishing . . . . . . . 27
4.4.1.6. Threat: User session impersonation . . . . . . . . 27 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 . . . . . . . . . . . . . . . . 28 counterfeit client . . . . . . . . . . . . . . . . 28
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 29 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30
4.4.1.9. Threat: Clickjacking attack against 4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 30 authorization . . . . . . . . . . . . . . . . . . 31
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 32 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 . . . . . . . . . . . . . . . . . . . . . . 32 codes . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 34 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35
4.4.2.1. Threat: Access token leak in 4.4.2.1. Threat: Access token leak in
transport/end-points . . . . . . . . . . . . . . . 34 transport/end-points . . . . . . . . . . . . . . . 35
4.4.2.2. Threat: Access token leak in browser history . . . 34 4.4.2.2. Threat: Access token leak in browser history . . . 35
4.4.2.3. Threat: Malicious client obtains authorization . . 35 4.4.2.3. Threat: Malicious client obtains authorization . . 35
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 35 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 35 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36
4.4.3. Resource Owner Password Credentials . . . . . . . . . 36 4.4.3. Resource Owner Password Credentials . . . . . . . . . 37
4.4.3.1. Threat: Accidental exposure of passwords at 4.4.3.1. Threat: Accidental exposure of passwords at
client site . . . . . . . . . . . . . . . . . . . 37 client site . . . . . . . . . . . . . . . . . . . 38
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 37 authorization . . . . . . . . . . . . . . . . . . 38
4.4.3.3. Threat: Client obtains refresh token through 4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 38 automatic authorization . . . . . . . . . . . . . 38
4.4.3.4. Threat: Obtain user passwords on transport . . . . 38 4.4.3.4. Threat: Obtain user passwords on transport . . . . 39
4.4.3.5. Threat: Obtain user passwords from 4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 38 authorization server database . . . . . . . . . . 39
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 39 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 39 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 39 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40
4.5.1. Threat: Eavesdropping refresh tokens from 4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 39 authorization server . . . . . . . . . . . . . . . . . 40
4.5.2. Threat: Obtaining refresh token from authorization 4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 40 server database . . . . . . . . . . . . . . . . . . . 41
4.5.3. Threat: Obtain refresh token by online guessing . . . 40 4.5.3. Threat: Obtain refresh token by online guessing . . . 41
4.5.4. Threat: Obtain refresh token phishing by 4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 40 counterfeit authorization server . . . . . . . . . . . 41
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 41 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42
4.6.1. Threat: Eavesdropping access tokens on transport . . . 41 4.6.1. Threat: Eavesdropping access tokens on transport . . . 42
4.6.2. Threat: Replay authorized resource server requests . . 41 4.6.2. Threat: Replay authorized resource server requests . . 42
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42
4.6.4. Threat: Access token phishing by counterfeit 4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 42 resource server . . . . . . . . . . . . . . . . . . . 43
4.6.5. Threat: Abuse of token by legitimate resource 4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 43 server or client . . . . . . . . . . . . . . . . . . . 44
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 43 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 43 referrers . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 44 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 44 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45
5.1.2. Server authentication . . . . . . . . . . . . . . . . 45 5.1.2. Server authentication . . . . . . . . . . . . . . . . 46
5.1.3. Always keep the resource owner informed . . . . . . . 45 5.1.3. Always keep the resource owner informed . . . . . . . 46
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46
5.1.4.1. Credential Storage Protection . . . . . . . . . . 46 5.1.4.1. Credential Storage Protection . . . . . . . . . . 47
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 47 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 48 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 48 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49
5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49
5.1.5.4. Limit number of usages/ One time usage . . . . . . 49 5.1.5.4. Limit number of usages/ One time usage . . . . . . 50
5.1.5.5. Bind tokens to a particular resource server 5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 49 (Audience) . . . . . . . . . . . . . . . . . . . . 50
5.1.5.6. Use endpoint address as token audience . . . . . . 50 5.1.5.6. Use endpoint address as token audience . . . . . . 51
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 50 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 51
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 50 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51
5.1.5.10. Encryption of token content . . . . . . . . . . . 51 5.1.5.10. Encryption of token content . . . . . . . . . . . 51
5.1.5.11. Random token value with high entropy . . . . . . . 51 5.1.5.11. Random token value with high entropy . . . . . . . 51
5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 51 5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 52
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 51 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 52
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 51 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 51 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52
5.2.1.1. Automatic revocation of derived tokens if 5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 51 abuse is detected . . . . . . . . . . . . . . . . 52
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52
5.2.2.2. Binding of refresh token to client_id . . . . . . 52 5.2.2.2. Binding of refresh token to client_id . . . . . . 53
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 52 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 53
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 52 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53
5.2.2.5. Device identification . . . . . . . . . . . . . . 53 5.2.2.5. Device identification . . . . . . . . . . . . . . 54
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 53 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 54
5.2.3. Public client authentication and authorization . . . . 53 5.2.3. Client authentication and authorization . . . . . . . 54
5.2.3.1. Don't issue secrets to public clients or 5.2.3.1. Don't issue secrets to public clients or
clients with inappropriate security policy . . . . 54 clients with inappropriate security policy . . . . 55
5.2.3.2. Public clients without secret require user 5.2.3.2. Public clients without secret require user
consent . . . . . . . . . . . . . . . . . . . . . 54 consent . . . . . . . . . . . . . . . . . . . . . 55
5.2.3.3. Client_id only in combination with redirect_uri . 55 5.2.3.3. Client_id only in combination with redirect_uri . 55
5.2.3.4. Deployment-specific client secrets . . . . . . . . 55 5.2.3.4. Deployment-specific client secrets . . . . . . . . 56
5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 5.2.3.5. Validation of pre-registered redirect_uri . . . . 56
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 56 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57
5.2.3.7. Use strong client authentication (e.g. 5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 57 client_assertion / client_token) . . . . . . . . . 57
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 57 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58
5.2.4.1. Automatic processing of repeated 5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 57 authorizations requires client validation . . . . 58
5.2.4.2. Informed decisions based on transparency . . . . . 57 5.2.4.2. Informed decisions based on transparency . . . . . 58
5.2.4.3. Validation of client properties by end-user . . . 57 5.2.4.3. Validation of client properties by end-user . . . 58
5.2.4.4. Binding of authorization code to client_id . . . . 58 5.2.4.4. Binding of authorization code to client_id . . . . 59
5.2.4.5. Binding of authorization code to redirect_uri . . 58 5.2.4.5. Binding of authorization code to redirect_uri . . 59
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 58 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59
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 . . . . . . . . . . . . 58 bundled with software packages . . . . . . . . . . . . 59
5.3.2. Standard web server protection measures (for 5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 59 config files and databases) . . . . . . . . . . . . . 60
5.3.3. Store secrets in a secure storage . . . . . . . . . . 59 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 59 access . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.5. Platform security measures . . . . . . . . . . . . . . 59 5.3.5. Platform security measures . . . . . . . . . . . . . . 60
5.3.6. Link state parameter to user agent session . . . . . . 59 5.3.6. Link state parameter to user agent session . . . . . . 60
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 60 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 60 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 60 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 61 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62
8.1. Normative References . . . . . . . . . . . . . . . . . . . 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 62
8.2. Informative References . . . . . . . . . . . . . . . . . . 62 8.2. Informative References . . . . . . . . . . . . . . . . . . 63
Appendix A. Document History . . . . . . . . . . . . . . . . . . 62 Appendix A. Document History . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65
1. Introduction 1. Introduction
This document gives security considerations based on a comprehensive This document gives security considerations 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 26 skipping to change at page 6, line 26
o Gives a comprehensive threat model for OAuth and describes the o Gives a comprehensive threat model for OAuth and describes the
respective counter measures to thwart those threats. respective counter measures to thwart those threats.
Threats include any intentional attacks on OAuth tokens and resources Threats include any intentional attacks on OAuth tokens and resources
protected by OAuth tokens as well as security risks introduced if the protected by OAuth tokens as well as security risks introduced if the
proper security measures are not put in place. Threats are proper security measures are not put in place. Threats are
structured along the lines of the protocol structure to aid structured along the lines of the protocol structure to aid
development teams implement each part of the protocol securely. For development teams implement each part of the protocol securely. For
example all threats for granting access or all threats for a example all threats for granting access or all threats for a
particular client profile or all threats for protecting the resource particular grant type or all threats for protecting the resource
server. server.
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:
skipping to change at page 7, line 16 skipping to change at page 7, line 16
o Token formats o Token formats
o Except for "Resource Owner Password Credentials" (see o Except for "Resource Owner Password Credentials" (see
[I-D.ietf-oauth-v2], section 4.3), the mechanism used by [I-D.ietf-oauth-v2], section 4.3), the mechanism used by
authorization servers to authenticate the user authorization servers to authenticate the user
o Mechanism by which a user obtained an assertion and any resulting o Mechanism by which a user obtained an assertion and any resulting
attacks mounted as a result of the assertion being false. attacks mounted as a result of the assertion being false.
o Clients are not bound to a specific deployment: An example could o Clients not bound to a specific deployment: An example could be a
by a mail client with support for contact list access via the mail client with support for contact list access via the portable
portable contacts API (see [portable-contacts]). Such clients contacts API (see [portable-contacts]). Such clients cannot be
cannot be registered upfront with a particular deployment and must registered upfront with a particular deployment and should
dynamically discover the URLs relevant for the OAuth protocol. dynamically discover the URLs relevant for the OAuth protocol.
2.2. Attack Assumptions 2.2. Attack Assumptions
The following assumptions relate to an attacker and resources The following assumptions relate to an attacker and resources
available to an attacker: available to an attacker:
o It is assumed the attacker has full access to the network between o It is assumed the attacker has full access to the network between
the client and authorization servers and the client and the the client and authorization servers and the client and the
resource server, respectively. The attacker may eaves drop on any resource server, respectively. The attacker may eavesdrop on any
communications between those parties. He is not assumed to have communications between those parties. He is not assumed to have
access to communication between authorization and resource server. access to communication between authorization and resource server.
o It is assumed an attacker has unlimited resources to mount an o It is assumed an attacker has unlimited resources to mount an
attack. attack.
o It is assumed that 2 of the 3 parties involved in the OAuth o It is assumed that 2 of the 3 parties involved in the OAuth
protocol may collude to mount an attack against the 3rd party. protocol may collude to mount an attack against the 3rd party.
For example, the client and authorization server may be under For example, the client and authorization server may be under
control of an attacker and collude to trick a user to gain access control of an attacker and collude to trick a user to gain access
to resources. to resources.
2.3. Architectural assumptions 2.3. Architectural assumptions
This section documents the assumptions about the features, This section documents the assumptions about the features,
limitations and design options of the different entities of a OAuth limitations, and design options of the different entities of a OAuth
deployment along with the security-sensitive data-elements managed by deployment along with the security-sensitive data-elements managed by
those entity. These assumptions are the foundation of the treat those entity. These assumptions are the foundation of the threat
analysis. analysis.
The OAuth protocol leaves deployments with a certain degree of The OAuth protocol leaves deployments with a certain degree of
freedom how to implement and apply the standard. The core freedom how to implement and apply the standard. The core
specification defines the core concepts of an authorization server specification defines the core concepts of an authorization server
and a resource server. Both servers can be implemented in the same and a resource server. Both servers can be implemented in the same
server entity, or they may also be different entities. The later is server entity, or they may also be different entities. The later is
typically the case for multi-service providers with a single typically the case for multi-service providers with a single
authentication and authorization system, and are more typical in authentication and authorization system, and are more typical in
middleware architectures. middleware architectures.
2.3.1. Authorization Servers 2.3.1. Authorization Servers
The following data elements MAY be stored or accessible on the The following data elements are stored or accessible on the
authorization server: authorization server:
o user names and passwords o user names and passwords
o client ids and secrets o client ids and secrets
o client-specific refresh tokens o client-specific refresh tokens
o client-specific access tokens (in case of handle-based design) o client-specific access tokens (in case of handle-based design)
o HTTPS certificate/key o HTTPS certificate/key
o per authorization process (in case of handle-based design): o per-authorization process (in case of handle-based design):
redirect_uri, client_id, authorization code redirect_uri, client_id, authorization code
2.3.2. Resource Server 2.3.2. Resource Server
The following data elements MAY be stored or accessible on the The following data elements are stored or accessible on the resource
resource server: server:
o user data (out of scope) o user data (out of scope)
o HTTPS certificate/key o HTTPS certificate/key
o authz server credentials (handle-based design), or o authorization server credentials (handle-based design), or
o authz server shared secret/public key (assertion-based design) o authorization server shared secret/public key (assertion-based
design)
o access tokens (per request) o access tokens (per request)
It is assumed that a resource server has no knowledge of refresh It is assumed that a resource server has no knowledge of refresh
tokens, user passwords, or client secrets. tokens, user passwords, or client secrets.
2.3.3. Client 2.3.3. Client
A full definition of different client types and profiles is given in A full definition of different client types and profiles is given in
[I-D.ietf-oauth-v2], Section 2.1. [I-D.ietf-oauth-v2], Section 2.1.
skipping to change at page 9, line 13 skipping to change at page 9, line 15
The following data elements are stored or accessible on the client: The following data elements are stored or accessible on the client:
o client id (and client secret or corresponding client credential) o client id (and client secret or corresponding client credential)
o one or more refresh tokens (persistent) and access tokens o one or more refresh tokens (persistent) and access tokens
(transient) per end-user or other security-context or delegation (transient) per end-user or other security-context or delegation
context context
o trusted CA certificates (HTTPS) o trusted CA certificates (HTTPS)
o per authorization process: redirect_uri, authorization code o per-authorization process: redirect_uri, authorization code
3. Security Features 3. Security Features
These are some of the security features which have been built into These are some of the security features which have been built into
the OAuth 2.0 protocol to mitigate attacks and security issues. the OAuth 2.0 protocol to mitigate attacks and security issues.
3.1. Tokens 3.1. Tokens
OAuth makes extensive use of all kinds of tokens (access tokens, OAuth makes extensive use many kinds of tokens (access tokens,
refresh tokens, authorization codes). The information content of a refresh tokens, authorization codes). The information content of a
token can be represented in two ways as follows: token can be represented in two ways as follows:
Handle (or artifact) a reference to some internal data structure Handle (or artifact) a reference to some internal data structure
within the authorization server, the internal data structure within the authorization server; the internal data structure
contains the attributes of the token, such as user id, scope, etc. contains the attributes of the token, such as user id, scope, etc.
Handles enable simple revocation and do not require cryptographic Handles enable simple revocation and do not require cryptographic
mechanisms to protected token content from being modified. On the mechanisms to protect token content from being modified. On the
other hand, handles require communication between issuing and other hand, handles require communication between issuing and
consuming entity (e.g. authorization and resource server) in order consuming entity (e.g. authorization and resource server) in order
to validate the token and obtain token-bound data. This to validate the token and obtain token-bound data. This
communication might have an negative impact on performance and communication might have an negative impact on performance and
scalability if both entities reside on different system. Handles scalability if both entities reside on different systems. Handles
are therefore typically used if the issuing and consuming entity are therefore typically used if the issuing and consuming entity
are the same. A 'handle' token is often referred to as an are the same. A 'handle' token is often referred to as an
'opaque' token because the resource server does not need to be 'opaque' token because the resource server does not need to be
able to interpret the token directly, it simply uses the token. able to interpret the token directly, it simply uses the token.
Assertions (aka self-contained token) a parseable token. An Assertions (aka self-contained token) a parseable token. An
assertion typically has a duration, an audience, and is digitally assertion typically has a duration, an audience, and is digitally
signed containing information about the user and the client. signed containing information about the user and the client.
Examples of assertion formats are SAML assertions and Kerberos Examples of assertion formats are SAML assertions and Kerberos
tickets. Assertions can typically directly be validated and used tickets. Assertions can typically directly be validated and used
skipping to change at page 11, line 22 skipping to change at page 11, line 27
A refresh token represents a long-lasting authorization of a certain A refresh token represents a long-lasting authorization of a certain
client to access resources on behalf of a resource owner. Such client to access resources on behalf of a resource owner. Such
tokens are exchanged between client and authorization server, only. tokens are exchanged between client and authorization server, only.
Clients use this kind of token to obtain ("refresh") new access Clients use this kind of token to obtain ("refresh") new access
tokens used for resource server invocations. tokens used for resource server invocations.
A refresh token, coupled with a short access token lifetime, can be A refresh token, coupled with a short access token lifetime, can be
used to grant longer access to resources without involving end user used to grant longer access to resources without involving end user
authorization. This offers an advantage where resource servers and authorization. This offers an advantage where resource servers and
authorization servers are not the same entity, e.g. in a distributed authorization servers are not the same entity, e.g. in a distributed
environment, as the refresh token must always be exchanged at the environment, as the refresh token is always exchanged at the
authorization server. The authorization server can revoke the authorization server. The authorization server can revoke the
refresh token at any time causing the granted access to be revoked refresh token at any time causing the granted access to be revoked
once the current access token expires. Because of this, a short once the current access token expires. Because of this, a short
access token lifetime is important if timely revocation is a high access token lifetime is important if timely revocation is a high
priority. priority.
The refresh token is also a secret bound to the client identifier and The refresh token is also a secret bound to the client identifier and
_instance_ which originally requested the authorization and client instance which originally requested the authorization and
representing the original resource owner grant. This is ensured by representing the original resource owner grant. This is ensured by
the authorization process as follows: the authorization process as follows:
1. The resource owner and user-agent safely deliver the 1. The resource owner and user-agent safely deliver the
authorization code to the client instance in first place. authorization code to the client instance in first place.
2. The client uses it immediately in secure transport-level 2. The client uses it immediately in secure transport-level
communications to the authorization server and then securely communications to the authorization server and then securely
stores the long-lived refresh token. stores the long-lived refresh token.
3. The client always uses the refresh token in secure transport- 3. The client always uses the refresh token in secure transport-
level communications to the authorization server to get an access level communications to the authorization server to get an access
token (and optionally rollover the refresh token). token (and optionally rollover the refresh token).
So as long as the confidentiality of the particular token can be So as long as the confidentiality of the particular token can be
ensured by the client, a refresh tokens can also be used as an ensured by the client, a refresh tokens can also be used as an
alternative mean to authenticate the client instance itself. alternative mean to authenticate the client instance itself.
3.4. Authorization Code 3.4. Authorization Code
An Authorization Code represents the intermediary result of a An Authorization Code represents the intermediate result of a
successful end-user authorization process and is used by the client successful end-user authorization process and is used by the client
to obtain access and refresh token. Authorization codes are sent to to obtain access and refresh token. Authorization codes are sent to
the client's redirection URI instead of tokens for two purposes. the client's redirection URI instead of tokens for two purposes.
1. Instead of (longer-lasting) tokens, the short-living 1. Instead of (longer-lasting) tokens, the short-lived authorization
authorization code is exposed to potential attackers via URI code is exposed to potential attackers via URI query parameters
query parameters (HTTP referrer), browser cacher or log file (HTTP referrer), browser cache, or log file entries.
entries.
2. It is much simpler to authenticate clients during the direct 2. It is much simpler to authenticate clients during the direct
request between client and authorization server than in the request between client and authorization server than in the
context of the indirect authorization request. The later would context of the indirect authorization request. The later would
require digital signatures. require digital signatures.
3.5. Redirection URI 3.5. Redirection URI
A redirection URI helps to detect malicious client and prevents A redirection URI helps to detect malicious clients and prevents
phishing attacks from clients attempting to trick the user into phishing attacks from clients attempting to trick the user into
believing the phisher is the client. The value of the actual believing the phisher is the client. The value of the actual
redirection URI used in the authorization request has to be presented redirection URI used in the authorization request has to be presented
and is verified when an authorization code is exchanged for tokens. and is verified when an authorization code is exchanged for tokens.
This helps to prevent attacks, where the authorization code is This helps to prevent attacks, where the authorization code is
revealed through redirectors and counterfeit web application clients. revealed through redirectors and counterfeit web application clients.
The authorization server requires public clients and confidential The authorization server should require public clients and
clients using implicit grant type to pre-register their redirect URIs confidential clients using implicit grant type to pre-register their
and validate agains the registered redirection URI in the redirect URIs and validate against the registered redirection URI in
authorization request. the authorization request.
3.6. State parameter 3.6. State parameter
The state parameter is used to link requests and callbacks to prevent The state parameter is used to link requests and callbacks to prevent
CSRF attacks where an attacker authorizes access to his own resources CSRF attacks where an attacker authorizes access to his own resources
and then tricks a users into following a redirect with the attacker's and then tricks a users into following a redirect with the attacker's
token. It should bind to the authenticated state in a user agent and token. This parameter should bind to the authenticated state in a
the user agent must be capable of keeping it in a location accessible user agent and, as per the core OAuth spec, the user agent must be
only by the client and user agent, i.e. protected by same-origin capable of keeping it in a location accessible only by the client and
policy user agent, i.e. protected by same-origin policy
3.7. Client Identity 3.7. Client Identity
Authentication protocols have typically not taken into account the Authentication protocols have typically not taken into account the
identity of the software component acting on behalf of the end-user. identity of the software component acting on behalf of the end-user.
OAuth does this in order to increase the security level in delegated OAuth does this in order to increase the security level in delegated
authorization scenarios and because the client will be able to act authorization scenarios and because the client will be able to act
without the user being present. without the user being present.
OAuth uses the _client_id_ (client identity) to collate associated OAuth uses the client identifier to collate associated request to the
request to the same originator, such as same originator, such as
o a particular end-user authorization process and the corresponding o a particular end-user authorization process and the corresponding
request on the tokens endpoint to exchange the authorization code request on the token's endpoint to exchange the authorization code
for tokens or for tokens or
o the initial authorization and issuance of a tokens by an end-user o the initial authorization and issuance of a token by an end-user
to a particular client and sub-sequent requests by this client to to a particular client, and subsequent requests by this client to
obtain tokens w/o user consent (automatic processing of repeated obtain tokens without user consent (automatic processing of
authorization) repeated authorization)
The client identity may also be used by the authorization server to The client identity may also be used by the authorization server to
display relevant registration information to a user when requesting display relevant registration information to a user when requesting
consent for scope requested by a particular client. The client consent for scope requested by a particular client. The client
identity may be used to limit the number of request for a particular identity may be used to limit the number of request for a particular
client or to charge the client per request. Client Identity may client or to charge the client per request. Client Identity may
furthermore be useful to differentiate access by different clients, furthermore be useful to differentiate access by different clients,
e.g. in server log files. e.g. in server log files.
OAuth defines two client types, confidential and public, based on OAuth defines two client types, confidential and public, based on
their ability to authenticate securely with the authorization server their ability to authenticate with the authorization server (i.e.
(i.e. ability to maintain the confidentiality of their client ability to maintain the confidentiality of their client credentials).
credentials). Confidential clients are capable of maintaining the Confidential clients are capable of maintaining the confidentiality
confidentiality of client credentials (i.e. a client secret of client credentials (i.e. a client secret associated with the
associated with the client identifier) or capable of secure client client identifier) or capable of secure client authentication using
authentication using other means, such as a client assertion (e.g. other means, such as a client assertion (e.g. SAML) or key
SAML) or key cryptography. The latter is considered more secure. cryptography. The latter is considered more secure.
The authorization server should determine whether the client is The authorization server should determine whether the client is
capable of keeping its secret confidential or using secure capable of keeping its secret confidential or using secure
authentication. Alternatively, the _end-user_ can verify the authentication. Alternatively, the end-user can verify the identity
identity of the client, e.g. by only installing trusted of the client, e.g. by only installing trusted applications.The
applications.The _redirection URI_ can be used to prevent delivering redicrection URI can be used to prevent delivering credentials to a
credentials to a counterfeit client after obtaining end-user counterfeit client after obtaining end-user authorization in some
authorization, but can't be used to verify the client identity. cases, but can't be used to verify the client identity.
Clients can be categorized as follows based on the client type, Clients can be categorized as follows based on the client type,
profile (e.g. native vs web application) and deployment model: profile (e.g. native vs web application) and deployment model:
Deployment-independent client_id with pre-registered redirect_uri and Deployment-independent client_id with pre-registered redirect_uri and
without client_secret Such an identity is used by multiple without client_secret Such an identity is used by multiple
installations of the same software package. The identity of such installations of the same software package. The identity of such
a client can only be validated with the help of the end-user. a client can only be validated with the help of the end-user.
This is a viable option for native applications in order to This is a viable option for native applications in order to
identify the client for the purpose of displaying meta information identify the client for the purpose of displaying meta information
skipping to change at page 14, line 16 skipping to change at page 14, line 16
Deployment-independent client_id with pre-registered redirect_uri and Deployment-independent client_id with pre-registered redirect_uri and
with client_secret This is an option for native applications only, with client_secret This is an option for native applications only,
since web application would require different redirect URIs. This since web application would require different redirect URIs. This
category is not advisable because the client secret cannot be category is not advisable because the client secret cannot be
protected appropriately (see Section 4.1.1). Due to its security protected appropriately (see Section 4.1.1). Due to its security
weaknesses, such client identities have the same trust level as weaknesses, such client identities have the same trust level as
deployment-independent clients without secret. Revocation will deployment-independent clients without secret. Revocation will
affect ALL deployments. affect ALL deployments.
Deployment-specific client_id with pre-registered redirect_uri and Deployment-specific client_id with pre-registered redirect_uri and
with client_secret The client registration process insures the with client_secret The client registration process ensures the
validation of the client's properties, such as redirection URI, validation of the client's properties, such as redirection URI,
website address, web site name, contacts. Such a client identity website address, web site name, contacts. Such a client identity
can be utilized for all relevant use cases cited above. This can be utilized for all relevant use cases cited above. This
level can be achieved for web applications in combination with a level can be achieved for web applications in combination with a
manual or user-bound registration process. Achieving this level manual or user-bound registration process. Achieving this level
for native applications is much more difficult. Either the for native applications is much more difficult. Either the
installation of the application is conducted by an administrator, installation of the application is conducted by an administrator,
who validates the clients authenticity, or the process from who validates the client's authenticity, or the process from
validating the application to the installation of the application validating the application to the installation of the application
on the device and the creation of the client credentials is on the device and the creation of the client credentials is
controlled end-to-end by a single entity (e.g. application market controlled end-to-end by a single entity (e.g. application market
provider). Revocation will affect a single deployment only. provider). Revocation will affect a single deployment only.
Deployment-specific client_id with client_secret without validated Deployment-specific client_id with client_secret without validated
properties Such a client can be recognized by the authorization properties Such a client can be recognized by the authorization
server in transactions with subsequent requests (e.g. server in transactions with subsequent requests (e.g.
authorization and token issuance, refresh token issuance and authorization and token issuance, refresh token issuance and
access token refreshment). The authorization server cannot assure access token refreshment). The authorization server cannot assure
any property of the client to end-users. Automatic processing of any property of the client to end-users. Automatic processing of
re-authorizations could be allowed as well. Such client re-authorizations could be allowed as well. Such client
credentials can be generated automatically without any validation credentials can be generated automatically without any validation
of client properties, which makes it another option especially for of client properties, which makes it another option especially for
native applications. Revocation will affect a single deployment native applications. Revocation will affect a single deployment
only. only.
4. Security Threat Model 4. Security Threat Model
This sections gives a comprehensive threat model of OAuth 2.0. This section gives a comprehensive threat model of OAuth 2.0.
Threats are grouped first by attacks directed against an OAuth Threats are grouped first by attacks directed against an OAuth
component, which are client, authorization server, and resource component, which are client, authorization server, and resource
server. Subsequently, they are grouped by flow, e.g. obtain token or server. Subsequently, they are grouped by flow, e.g. obtain token or
access protected resources. Every countermeasure description refers access protected resources. Every countermeasure description refers
to a detailed description in Section 5. to a detailed description in Section 5.
4.1. Clients 4.1. Clients
This section describes possible threats directed to OAuth clients. This section describes possible threats directed to OAuth clients.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
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.
*Attack: Obtain Secret From Source Code or Binary.* This applies for Attack: Obtain Secret From Source Code or Binary:
all client profiles. For open source projects, secrets can be
extracted directly from source code in their public repositories.
Secrets can be extracted from application binaries just as easily
when published source is not available to the attacker. Even if an
application takes significant measures to obfuscate secrets in their
application distribution one should consider that the secret can
still be reverse-engineered by anyone with access to a complete
functioning application bundle or binary.
_Countermeasures:_ This applies for all client types. For open source projects, secrets
can be extracted directly from source code in their public
repositories. Secrets can be extracted from application binaries
just as easily when published source is not available to the
attacker. Even if an application takes significant measures to
obfuscate secrets in their application distribution one should
consider that the secret can still be reverse-engineered by anyone
with access to a complete functioning application bundle or binary.
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 Public clients require user consent - 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 Client secret revocation - Section 5.2.3.6
Attack: Obtain a Deployment-Specific Secret:
__ An attacker may try to obtain the secret from a client installation,
either from a web site (web server) or a particular devices (native
*Attack: Obtain a Deployment-Specific Secret.* An attacker may try to application).
obtain the secret from a client installation, either from a web site
(web server) or a particular devices (native 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 Client secret revocation - 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. Some different client types and further specialized countermeasures.
generally applicable countermeasure to mitigate such attacks shall be Before detailing those threats, here are some generally applicable
given in advance: countermeasures:
o The authorization server must 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 Limited scope tokens - Section 5.1.5.1
o Refresh token revocation - Section 5.2.2.4 o Refresh token revocation - Section 5.2.2.4
o Client secret revocation - Section 5.2.3.6 o Client secret revocation - 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 attack may An attacker may obtain the refresh tokens issued to a web application
obtain the refresh tokens issued to a web server client. Impact: by way of overcoming the web server's security controls. Impact:
Exposure of all refresh tokens on that side. 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
that side 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.* On native On native clients, leakage of a refresh token typically affects a
clients, leakage of a refresh token typically affects a single user, single user, only.
only.
_Read from local filesystem:_ The attacker could try get file system Read from local file system: The attacker could try get file system
access on the device and read the refresh tokens. The attacker could access on the device and read the refresh tokens. The attacker could
utilize a malicious application for that purpose. utilize a malicious application for that purpose.
_Countermeasures:_ Countermeasures:
o Store secrets in a secure storage - Section 5.3.3 o Store secrets in a secure storage - Section 5.3.3
o Utilize device lock to prevent unauthorized device access - o Utilize device lock to prevent unauthorized device access -
Section 5.3.4 Section 5.3.4
__ Attack: Steal device:
_Steal device_: The host device (e.g. mobile phone) may be stolen. The host device (e.g. mobile phone) may be stolen. In that case, the
In that case, the attacker gets access to all applications under the attacker gets access to all applications under the identity of the
identity of the legitimate user. legitimate user.
_Countermeasures:_ Countermeasures:
o Utilize device lock to prevent unauthorized device access - o Utilize device lock to prevent unauthorized device access -
Section 5.3.4 Section 5.3.4
o Where a user knows the device has been stolen, they can revoke the o Where a user knows the device has been stolen, they can revoke the
affected tokens - Section 5.2.2.4 affected tokens - Section 5.2.2.4
__ Attack: Clone Device:
_Clone device: _All device data and applications are copied to All device data and applications are copied to another device.
another device. Applications are used as-is on the target device. Applications are used as-is on the target device.
_Countermeasures:_ Countermeasures:
o Utilize device lock to prevent unauthorized device access -
Section 5.3.4
o Combine refresh token request with device identification - o Combine refresh token request with device identification -
Section 5.2.2.5 Section 5.2.2.5
o Refresh Token Rotation - Section 5.2.2.3 o Refresh Token Rotation - Section 5.2.2.3
o Where a user knows the device has been cloned, they can use this o Where a user knows the device has been cloned, they can use this
countermeasure - Refresh Token Revocation - Section 5.2.2.4 countermeasure - Refresh Token Revocation - Section 5.2.2.4
__
4.1.3. Threat: Obtain Access Tokens 4.1.3. Threat: Obtain Access Tokens
Depending on the client type, there are different ways access tokens Depending on the client type, there are different ways access tokens
may be revealed to an attacker. Access tokens could be stolen from may be revealed to an attacker. Access tokens could be stolen from
the device if the application stores them in a storage, which is the device if the application stores them in a storage, which is
accessible to other applications. accessible to other applications.
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.
skipping to change at page 18, line 50 skipping to change at page 19, line 10
to additional information it should not have access to (e.g. uid/ to additional information it should not have access to (e.g. uid/
password). password).
Impact: If the client application or the communication is Impact: If the client application or the communication is
compromised, the user would not be aware and all information in the compromised, the user would not be aware and all information in the
authorization exchange could be captured such as username and authorization exchange could be captured such as username and
password. password.
Countermeasures: Countermeasures:
o Client developers and end-user can be educated to trust an o The OAuth flow is designed so that client applications never need
external System-Browser only. to know user passwords. Client applications should avoid directly
asking users for the their credentials. In addition, end users
could be educated about phishing attacks and best practices, such
as only accessing trusted clients, as OAuth does not provide any
protection against malicious applications and the end user is
solely responsible for the trustworthiness of any native
application installed.
o Client applications could be validated prior publication in a o Client applications could be validated prior to publication in an
application market. application market for users to access. That validation is out of
scope for OAuth but could include validating that the client
application handles user authentication in an appropriate way.
o Client developers should not collect authentication information o Client developers should not write client applications that
directly from users and should instead use redirects to and back collect authentication information directly from users and should
from a trusted external system-browser. instead delegate this task to a trusted system component, e.g. the
system-browser.
4.1.5. Threat: Open Redirectors on client 4.1.5. Threat: Open Redirectors on client
An open redirector is an endpoint using a parameter to automatically An open redirector is an endpoint using a parameter to automatically
redirect a user-agent to the location specified by the parameter redirect a user-agent to the location specified by the parameter
value without any validation. If the authorization server allows the value without any validation. If the authorization server allows the
client to register only part of the redirection URI, an attacker can client to register only part of the redirection URI, an attacker can
use an open redirector operated by the client to construct a use an open redirector operated by the client to construct a
redirection URI that will pass the authorization server validation redirection URI that will pass the authorization server validation
but will send the authorization code or access token to an endpoint but will send the authorization code or access token to an endpoint
skipping to change at page 21, line 21 skipping to change at page 21, line 45
the parameter value without any validation. the parameter value without any validation.
Impact: An attacker could utilize a user's trust in your Impact: An attacker could utilize a user's trust in your
authorization server to launch a phishing attack. authorization server to launch a phishing attack.
Countermeasure Countermeasure
o require clients to register full redirection URI Section 5.2.3.5 o require clients to register full redirection URI Section 5.2.3.5
o don't redirect to redirection URI, if client identity or o don't redirect to redirection URI, if client identity or
redirection URI could not be verified Section 5.2.3.5 redirection URI can't be verified Section 5.2.3.5
4.3. Token endpoint 4.3. Token endpoint
4.3.1. Threat: Eavesdropping access tokens 4.3.1. Threat: Eavesdropping access tokens
Attackers may attempts to eavesdrop access token on transit from the Attackers may attempts to eavesdrop access token on transit from the
authorization server to the client. authorization server to the client.
Impact: The attacker is able to access all resources with the Impact: The attacker is able to access all resources with the
permissions covered by the scope of the particular access token. permissions covered by the scope of the particular access token.
Countermeasures: Countermeasures:
o Authorization servers MUST ensure that these transmissions are o As per the core OAuth spec, the authorization servers must ensure
protected using transport-layer mechanisms such as TLS or SSL (see that these transmissions are protected using transport-layer
Section 5.1.1). mechanisms such as TLS or SSL (see Section 5.1.1).
o If end-to-end confidentiality cannot be guaranteed, reducing scope o If end-to-end confidentiality cannot be guaranteed, reducing scope
(see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks. tokens can be used to reduce the damage in case of leaks.
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
skipping to change at page 22, line 21 skipping to change at page 22, line 48
4.3.3. Threat: Obtain client credentials over non secure transport 4.3.3. Threat: Obtain client credentials over non secure transport
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. Impact: authentication process or during OAuth token requests. Impact:
Revelation of a client credential enabling the possibility for Revelation of a client credential enabling the possibility for
phishing or imitation of a client service. phishing or imitation of a client service.
Countermeasures: Countermeasures:
o Implement transport security through Confidentiality of Requests o Implement transport security through - 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 (Examples: Digest plaintext credentials over the wire (Examples: Digest
authentication) authentication)
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
skipping to change at page 23, line 35 skipping to change at page 24, line 15
4.4.1. Authorization Code 4.4.1. Authorization Code
4.4.1.1. Threat: Eavesdropping or leaking authorization codes 4.4.1.1. Threat: Eavesdropping or leaking authorization codes
An attacker could try to eavesdrop transmission of the authorization An attacker could try to eavesdrop transmission of the authorization
code between authorization server and client. Furthermore, code between authorization server and client. Furthermore,
authorization codes are passed via the browser which may authorization codes are passed via the browser which may
unintentionally leak those codes to untrusted web sites and attackers unintentionally leak those codes to untrusted web sites and attackers
by different ways: by different ways:
o Referrer headers: browsers frequently pass a "referer" header when o Referrer headers: browsers frequently pass a "referrer" header
a web page embeds content, or when a user travels from one web when a web page embeds content, or when a user travels from one
page to another web page. These referrer headers may be sent even web page to another web page. These referrer headers may be sent
when the origin site does not trust the destination site. The even when the origin site does not trust the destination site.
referee header is commonly logged for traffic analysis purposes. The referrer header is commonly logged for traffic analysis
purposes.
o Request logs: web server request logs commonly include query o Request logs: web server request logs commonly include query
parameters on requests. parameters on requests.
o Open redirectors: web sites sometimes need to send users to o Open redirectors: web sites sometimes need to send users to
another destination via a redirector. Open redirectors pose a another destination via a redirector. Open redirectors pose a
particular risk to web-based delegation protocols because the particular risk to web-based delegation protocols because the
redirector can leak verification codes to untrusted destination redirector can leak verification codes to untrusted destination
sites. sites.
skipping to change at page 24, line 15 skipping to change at page 24, line 45
Note: A description of a similar attacks on the SAML protocol can be Note: A description of a similar attacks on the SAML protocol can be
found at http://www.oasis-open.org/committees/download.php/3405/ found at http://www.oasis-open.org/committees/download.php/3405/
oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http:// oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http://
www.thomasgross.net/publications/papers/ www.thomasgross.net/publications/papers/
GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http:// GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http://
www.oasis-open.org/committees/download.php/11191/ www.oasis-open.org/committees/download.php/11191/
sstc-gross-sec-analysis-response-01.pdf. sstc-gross-sec-analysis-response-01.pdf.
Countermeasures: Countermeasures:
o Authorization server as well as the client MUST ensure that these o As per the core OAuth spec, the authorization server as well as
transmissions are protected using transport-layer mechanisms such the client must ensure that these transmissions are protected
as TLS or SSL (see Section 5.1.1). using transport-layer mechanisms such as TLS or SSL (see
Section 5.1.1).
o The authorization server shall 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 Limited duration of 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 a o If an Authorization Server observes multiple attempts to redeem a
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
(Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks. tokens can be used to reduce the damage in case of leaks.
skipping to change at page 25, line 5 skipping to change at page 25, line 35
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 Credential storage protection can be employed - Section 5.1.4.1 o Best practices for credential storage protection should be
employed - Section 5.1.4.1
o System security measures - Section 5.1.4.1.1 o 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.
Impact: disclosure of single access token, probably also associated Impact: disclosure of single access token, probably also associated
refresh token. refresh token.
Countermeasures: Countermeasures:
o For handle-based designs: Section 5.1.5.11 o Handle-based tokens must use high entropy: Section 5.1.5.11
o For assertion-based designs: 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 Short expiration time - Section 5.1.5.3
4.4.1.4. Threat: Malicious client obtains authorization 4.4.1.4. Threat: Malicious client obtains authorization
skipping to change at page 26, line 7 skipping to change at page 26, line 38
responsibility of the platform running on the particular device responsibility of the platform running on the particular device
probably in cooperation with other components of the respective probably in cooperation with other components of the respective
ecosystem (e.g. an application management infrastructure). The sole ecosystem (e.g. an application management infrastructure). The sole
responsibility of the authorization server is to control access to responsibility of the authorization server is to control access to
the end-user's resources living in resource servers and to prevent the end-user's resources living in resource servers and to prevent
unauthorized access to them. Based on this assumption, the following unauthorized access to them. Based on this assumption, the following
countermeasures are available to cope with the threat. countermeasures are available to cope with the threat.
Countermeasures: Countermeasures:
o The authorization server should authentication the client, if o The authorization server should authenticate the client, if
possible (see Section 5.2.3.4). Note: the authentication takes possible (see Section 5.2.3.4). Note: the authentication takes
place after the end-user has authorized the access. place after the end-user has authorized the access.
o The authorization server should validate the client's redirection o The authorization server should validate the client's redirection
URI against the pre-registered redirection URI, if one exists (see URI against the pre-registered redirection URI, if one exists (see
Section 5.2.3.5). Note: The validation of the redirection URI is Section 5.2.3.5). Note: An invalid redirect URI indicates an
the only technical mean to recognize a malicious client id in invalid client whereas a valid redirect URI not neccesserily
advance of the authorization process. Further note this does not indicates a valid client. The level of confidence depends on the
work for native applications because in contrast to web client type. For web applications, the confidence is high since
applications this URI is not bound to a single communication the redirect URI refers to the globally unique network endpoint of
endpoint. The valid client's redirection URI (typically with this application whose address is also validated using HTTPS
custom scheme) can be used by a malicious client on any device. server authentication by the user agent. In contrast for native
clients, the redirect URI typically refers to device local
resources, e.g. a custom scheme. So a malicious client on a
particular device can use the valid redirect URI the legitimate
client uses on all other devices.
o After authenticating the end-user, the authorization server should o After authenticating the end-user, the authorization server should
ask him/her for consent. In this context, the user shall be ask him/her for consent. In this context, the user should be
explained the purpose, scope, and duration of the authorization. explained the purpose, scope, and duration of the authorization.
Moreover, the authorization server must view to the end-user the Moreover, the authorization server should show the user any
meta data it associates with the particular client. It is up to identity information it has for that client. It is up to the user
the user to validate the binding of this data to the particular to validate the binding of this data to the particular application
application (e.g. Name) and to approve the authorization request. (e.g. Name) and to approve the authorization request. (see
(see Section 5.2.4.3). Section 5.2.4.3).
o The authorization server must not perform automatic re- o The authorization server should not perform automatic re-
authorizations for clients it is unable to reliably authenticate authorizations for clients it is unable to reliably authenticate
or validate (see Section 5.2.4.1). or validate (see Section 5.2.4.1).
o If the authorization server automatically authenticates the end- o If the authorization server automatically authenticates the end-
user, it may nevertheless require some user input in order to user, it may nevertheless require some user input in order to
prevent screen scraping. Examples are CAPTCHAs or user-specific prevent screen scraping. Examples are CAPTCHAs or user-specific
secret like PIN codes. secrets like PIN codes.
o The authorization server may also limit the scope of tokens it o The authorization server may also limit the scope of tokens it
issues to clients it cannot reliably authenticate (see issues to clients it cannot reliably authenticate (see
Section 5.1.5.1). Section 5.1.5.1).
4.4.1.5. Threat: Authorization code phishing 4.4.1.5. Threat: Authorization code phishing
A hostile party could impersonate the client site and get access to A hostile party could impersonate the client site and get access to
the authorization code. This could be achieved using DNS or ARP the authorization code. This could be achieved using DNS or ARP
spoofing. This applies to clients, which are web applications, thus spoofing. This applies to clients, which are web applications, thus
skipping to change at page 27, line 11 skipping to change at page 27, line 46
Impact: This affects web applications and may lead to a disclosure of Impact: This affects web applications and may lead to a disclosure of
authorization codes and, potentially, the corresponding access and authorization codes and, potentially, the corresponding access and
refresh tokens. refresh tokens.
Countermeasures: Countermeasures:
It is strongly recommended that one of the following countermeasures It is strongly recommended that one of the following countermeasures
is utilized in order to prevent this attack: is utilized in order to prevent this attack:
o The redirection URI of the client SHOULD point to a HTTPS o The redirection URI of the client should point to a HTTPS
protected endpoint and the browser shall be utilized to protected endpoint and the browser should be utilized to
authenticate this redirection URI using server authentication (see authenticate this redirection URI using server authentication (see
Section 5.1.2). Section 5.1.2).
o The authorization server SHOULD require the client to be o The authorization server should require the client to be
authenticated, i.e. confidential client, so the binding of the authenticated, i.e. confidential client, so the binding of the
authorization code to a certain client can be validated in a authorization code to a certain client can be validated in a
reliable way (see Section 5.2.4.4). reliable way (see Section 5.2.4.4).
4.4.1.6. Threat: User session impersonation 4.4.1.6. Threat: User session impersonation
A hostile party could impersonate the client site and impersonate the A hostile party could impersonate the client site and impersonate the
user's session on this client. This could be achieved using DNS or user's session on this client. This could be achieved using DNS or
ARP spoofing. This applies to clients, which are web applications, ARP spoofing. This applies to clients, which are web applications,
thus the redirect URI is not local to the host where the user's thus the redirect URI is not local to the host where the user's
skipping to change at page 27, line 48 skipping to change at page 28, line 37
Login" button), the attacker can use the intercepted authorization Login" button), the attacker can use the intercepted authorization
code to log in to the client as the user. code to log in to the client as the user.
Note: Authenticating the client during authorization code exchange Note: Authenticating the client during authorization code exchange
will not help to detect such an attack as it is the legitimate client will not help to detect such an attack as it is the legitimate client
that obtains the tokens. that obtains the tokens.
Countermeasures: Countermeasures:
o In order to prevent an attacker from impersonating the end-users o In order to prevent an attacker from impersonating the end-users
session, the redirection URI of the client MUST point to a HTTPS session, the redirection URI of the client should point to a HTTPS
protected endpoint and the browser shall be utilized to protected endpoint and the browser should be utilized to
authenticate this redirection URI using server authentication (see authenticate this redirection URI using server authentication (see
Section 5.1.2) Section 5.1.2)
4.4.1.7. Threat: Authorization code leakage through counterfeit client 4.4.1.7. Threat: Authorization code leakage through counterfeit client
The attack leverages the authorization code grant type in an attempt The attack leverages the authorization code grant type in an attempt
to get another user (victim) to log-in, authorize access to his/her to get another user (victim) to log-in, authorize access to his/her
resources, and subsequently obtain the authorization code and inject resources, and subsequently obtain the authorization code and inject
it into a client application using the attacker's account. The goal it into a client application using the attacker's account. The goal
is to associate an access authorization for resources of the victim is to associate an access authorization for resources of the victim
skipping to change at page 29, line 17 skipping to change at page 30, line 7
attacker's user account on this site. attacker's user account on this site.
8. The attacker may now access the victims resources using the 8. The attacker may now access the victims resources using the
client site. client site.
Impact: The attackers gains access to the victim's resources as Impact: The attackers gains access to the victim's resources as
associated with his account on the client site. associated with his account on the client site.
Countermeasures: Countermeasures:
o The attacker must use another redirection URI for its o The attacker will need to use another redirection URI for its
authorization process than the target web site because it needs to authorization process than the target web site because it needs to
intercept the flow. So if the authorization server associates the intercept the flow. So if the authorization server associates the
authorization code with the redirection URI of a particular end- authorization code with the redirection URI of a particular end-
user authorization and validates this redirection URI with the user authorization and validates this redirection URI with the
redirection URI passed to the tokens endpoint, such an attack is redirection URI passed to the token's endpoint, such an attack is
detected (see Section 5.2.4.5). detected (see Section 5.2.4.5).
o The authorization server may also enforce the usage and validation o The authorization server may also enforce the usage and validation
of pre-registered redirect URIs (see Section 5.2.3.5). This will of pre-registered redirect URIs (see Section 5.2.3.5). This will
allow for an early recognition of session fixation attempts. allow for an early recognition of session fixation attempts.
o For native applications, one could also consider to use o For native applications, one could also consider to use
deployment-specific client ids and secrets (see Section 5.2.3.4, deployment-specific client ids and secrets (see Section 5.2.3.4,
along with the binding of authorization code to client_id (see along with the binding of authorization code to client_id (see
Section 5.2.4.4), to detect such an attack because the attacker Section 5.2.4.4), to detect such an attack because the attacker
does not have access the deployment-specific secret. Thus he will does not have access the deployment-specific secret. Thus he will
not be able to exchange the authorization code. not be able to exchange the authorization code.
o The client may consider to use other flows, which are not o The client may consider using other flows, which are not
vulnerable to this kind of attacks such as "Implicit Grant" or vulnerable to this kind of attacks such as "Implicit Grant" or
"Resource Owner Password Credentials" (see Section 4.4.2 or "Resource Owner Password Credentials" (see Section 4.4.2 or
Section 4.4.3). Section 4.4.3).
4.4.1.8. Threat: CSRF attack against redirect-uri 4.4.1.8. Threat: CSRF attack against redirect-uri
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has requests are transmitted from a user that the website trusts or has
authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
on OAuth approvals can allow an attacker to obtain authorization to on OAuth approvals can allow an attacker to obtain authorization to
skipping to change at page 30, line 42 skipping to change at page 31, line 32
are carefully constructed to be placed directly under important are carefully constructed to be placed directly under important
buttons on the target site. When a user clicks a visible button, buttons on the target site. When a user clicks a visible button,
they are actually clicking a button (such as an "Authorize" button) they are actually clicking a button (such as an "Authorize" button)
on the hidden page. on the hidden page.
Impact: An attacker can steal a user's authentication credentials and Impact: An attacker can steal a user's authentication credentials and
access their resources access their resources
Countermeasure Countermeasure
o Native applications SHOULD use external browsers instead of o Native applications should use external browsers instead of
embedding browsers in an iFrame when requesting end-user embedding browsers in a web view when requesting end-user
authorization authorization
o For newer browsers, avoidance of iFrames can be enforced server o For newer browsers, avoidance of iFrames can be enforced server
side by using the X-FRAME-OPTION header - Section 5.2.2.6 side by using the X-FRAME-OPTION header - Section 5.2.2.6
o For older browsers, javascript framebusting techniques can be used o For older browsers, javascript framebusting techniques can be used
but may not be effective in all browsers. but may not be effective in all browsers.
4.4.1.10. Threat: Resource Owner Impersonation 4.4.1.10. Threat: Resource Owner Impersonation
skipping to change at page 31, line 19 skipping to change at page 32, line 8
response to the access request, either granting or denying access to response to the access request, either granting or denying access to
the protected resources. A malicious client can exploit knowledge of the protected resources. A malicious client can exploit knowledge of
the structure of this flow in order to gain authorization without the the structure of this flow in order to gain authorization without the
resource owner's consent, by transmitting the necessary requests resource owner's consent, by transmitting the necessary requests
programmatically, and simulating the flow against the authorization programmatically, and simulating the flow against the authorization
server. That way, the client may gain access to the victims server. That way, the client may gain access to the victims
resources without her approval. An authorization server will be resources without her approval. An authorization server will be
vulnerable to this threat, if it uses non-interactive authentication vulnerable to this threat, if it uses non-interactive authentication
mechanisms or split the authorization flow across multiple pages. mechanisms or split the authorization flow across multiple pages.
The malicious client might embbed a hidden HTML user agent, interpret The malicious client might embed a hidden HTML user agent, interpret
the HTML forms sent by the authorization server, and automatically the HTML forms sent by the authorization server, and automatically
answer with the corresponding form post requests. As a pre- answer with the corresponding form post requests. As a pre-
requisiete, the attacker must be able to execute the authorization requisite, the attacker must be able to execute the authorization
process in the context of an already authenticated session of the process in the context of an already authenticated session of the
resource owner with the authorization server. There are different resource owner with the authorization server. There are different
ways to achieve this: ways to achieve this:
o The malicious client could abuse an existing session in an o The malicious client could abuse an existing session in an
external browser or cross-browser cookies on the particular external browser or cross-browser cookies on the particular
device. device.
o It could also request authorization for a particular scope and o It could also request authorization for a particular scope and
silently abuse the resulting session in his browser instance to silently abuse the resulting session in his browser instance to
"silently" request another scope. "silently" request another scope.
o Alternatively, the attacker might exploit an authorization o Alternatively, the attacker might exploit an authorization
server's aibility to authenticate the resource owner automatically server's ability to authenticate the resource owner automatically
and without user interactions, e.g. based on certificates. and without user interactions, e.g. based on certificates.
In all cases, such an attack is limited to clients running on the In all cases, such an attack is limited to clients running on the
victim's device, within the user agent or as native app. victim's device, within the user agent or as native app.
Please note: Such attacks cannot be prevented using CSRF Please note: Such attacks cannot be prevented using CSRF
countermeasures, since the attacker just "executes" the URLs as countermeasures, since the attacker just "executes" the URLs as
prepared by the authorization server including any nonce e.t.c. prepared by the authorization server including any nonce etc.
Countermeasures: Countermeasures:
Authorization servers should decide, based on an analysis of the risk Authorization servers should decide, based on an analysis of the risk
associated with this threat, whether to assume, detect, or to prevent associated with this threat, whether to assume, detect, or to prevent
this threat. this threat.
In order to prevent such an attack, the authorization server may In order to prevent such an attack, the authorization server may
force an user interaction based on non-predictable input values as force an user interaction based on non-predictable input values as
part of the user consent approval. The authorization server could part of the user consent approval. The authorization server could
skipping to change at page 32, line 50 skipping to change at page 33, line 41
authorization server. This can result in a DoS attack on the authorization server. This can result in a DoS attack on the
authorization server. authorization server.
This attack can still be effective even when CSRF defense/the 'state' This attack can still be effective even when CSRF defense/the 'state'
parameter are deployed on the client side. With such a defense, the parameter are deployed on the client side. With such a defense, the
attacker might need to incur an additional HTTP request to obtain a attacker might need to incur an additional HTTP request to obtain a
valid CSRF code/ state parameter. This apparently cuts down the valid CSRF code/ state parameter. This apparently cuts down the
effectiveness of the attack by a factor of 2. However, if the HTTPS/ effectiveness of the attack by a factor of 2. However, if the HTTPS/
HTTP cost ratio is higher than 2 (the cost factor is estimated to be HTTP cost ratio is higher than 2 (the cost factor is estimated to be
around 3.5x at around 3.5x at
http://www.semicomplete.com/blog/geekery/ssl-latency.html), the <http://www.semicomplete.com/blog/geekery/ssl-latency.html>) the
attacker still achieves a magnification of resource utilization at attacker still achieves a magnification of resource utilization at
the expense of the authorization server. the expense of the authorization server.
Impact: There are a few effects that the attacker can accomplish with Impact: There are a few effects that the attacker can accomplish with
this OAuth flow that they cannot easily achieve otherwise. this OAuth flow that they cannot easily achieve otherwise.
1. Connection laundering: With the clients as the relay between the 1. Connection laundering: With the clients as the relay between the
attacker and the authorization server, the authorization server attacker and the authorization server, the authorization server
learns little or no information about the identity of the learns little or no information about the identity of the
attacker. Defenses such rate limiting on the offending attacker attacker. Defenses such rate limiting on the offending attacker
skipping to change at page 33, line 35 skipping to change at page 34, line 25
similar, say, by including an iframe pointing to the HTTPS URL of similar, say, by including an iframe pointing to the HTTPS URL of
the authorization server in an HTTP web page and lure web users the authorization server in an HTTP web page and lure web users
to visit that page, timing attacks using such a scheme may be to visit that page, timing attacks using such a scheme may be
more difficult as it seems nontrivial to synchronize a large more difficult as it seems nontrivial to synchronize a large
number of users to simultaneously visit a particular site under number of users to simultaneously visit a particular site under
the attacker's control. the attacker's control.
Countermeasures Countermeasures
o Though not a complete countermeasure by themselves, CSRF defense o Though not a complete countermeasure by themselves, CSRF defense
and the 'state' parameter created with secure random codes SHOULD and the 'state' parameter created with secure random codes should
be deployed on the client side. The client SHOULD forward the be deployed on the client side. The client should forward the
authorization code to the authorization server only after both the authorization code to the authorization server only after both the
CSRF token and the 'state' parameter are validated. CSRF token and the 'state' parameter are validated.
o If the client authenticates the user, either through a single sign o If the client authenticates the user, either through a single sign
on protocol ( such as OpenID / Facebook Connect ) or through local on protocol ( such as OpenID / Facebook Connect ) or through local
authentication, the client SHOULD suspend the access by a user authentication, the client should suspend the access by a user
account if the number of invalid authorization codes submitted by account if the number of invalid authorization codes submitted by
this user exceeds a certain threshold. this user exceeds a certain threshold.
o The authorization server SHOULD send an error response to the o The authorization server should send an error response to the
client reporting an invalid authorization code and rate limit or client reporting an invalid authorization code and rate limit or
disallow connections from clients whose number of invalid requests disallow connections from clients whose number of invalid requests
exceeds a threshold. exceeds a threshold.
o The authorization server MAY in addition sign the authorization o The authorization server may in addition sign the authorization
code using the public key from its SSL certificate, and require code using the public key from its SSL certificate, and require
the client to validate the signature. To enhance interoperability the client to validate the signature. To enhance interoperability
between multiple clients and authorization servers, a standard between multiple clients and authorization servers, a standard
procedure to create and validate the signature (including what procedure to create and validate the signature (including what
attributes to sign) MAY be developed and agreed between the attributes to sign) may be developed and agreed between the
clients and the servers. clients and the servers.
4.4.2. Implicit Grant 4.4.2. Implicit Grant
In the implicit grant type flow, the access token is directly In the implicit grant type flow, the access token is directly
returned to the client as a fragment part of the redirection URI. It returned to the client as a fragment part of the redirection URI. It
is assumed that the token is not sent to the redirection URI target is assumed that the token is not sent to the redirection URI target
since HTTP user agents do not send fragments server requests. Thus as HTTP user agents do not send the fragment part of URIs to HTTP
an attacker cannot eavesdrop the access token on this communication servers. Thus an attacker cannot eavesdrop the access token on this
path and It cannot leak through HTTP referee headers. communication path and It cannot leak through HTTP referee headers.
4.4.2.1. Threat: Access token leak in transport/end-points 4.4.2.1. Threat: Access token leak in transport/end-points
This token might be eavesdropped by an attacker. The token is sent This token might be eavesdropped by an attacker. The token is sent
from server to client via a URI fragment of the redirection URI. If from server to client via a URI fragment of the redirection URI. If
the communication is not secured or the end-point is not secured, the the communication is not secured or the end-point is not secured, the
token could be leaked by parsing the returned URI. token could be leaked by parsing the returned URI.
Impact: the attacker would be able to assume the same rights granted Impact: the attacker would be able to assume the same rights granted
by the token. by the token.
Countermeasures: Countermeasures:
o The authorization server must ensure confidentiality of the o The authorization server should ensure confidentiality of the
response from the authorization server to the client (see response from the authorization server to the client (see
Section 5.1.1). 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 browsers 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 Shorten token duration (see Section 5.1.5.3) and reduced scope of
the token may reduce the impact of that attack (see the token may reduce the impact of that attack (see
Section 5.1.5.1). Section 5.1.5.1).
o Make these requests non-cachable o Make these requests non-cachable
skipping to change at page 35, line 25 skipping to change at page 36, line 17
A hostile party could act as the client web server and replace or A hostile party could act as the client web server and replace or
modify the actual implementation of the client (script). This could modify the actual implementation of the client (script). This could
be achieved using DNS or ARP spoofing. This applies to clients be achieved using DNS or ARP spoofing. This applies to clients
implemented within the Web Browser in a scripting language. implemented within the Web Browser in a scripting language.
Impact: The attacker could obtain user credential information and Impact: The attacker could obtain user credential information and
assume the full identity of the user. assume the full identity of the user.
Countermeasures: Countermeasures:
o The authorization server must authenticate the server from which o The authorization server should authenticate the server from which
scripts are obtained (see Section 5.1.2). scripts are obtained (see Section 5.1.2).
o The client must ensure that scripts obtained have not been altered o The client should ensure that scripts obtained have not been
in transport (see Section 5.1.1). altered in transport (see Section 5.1.1).
o Introduce one time per-use secrets (e.g. client_secret) values o Introduce one time per-use secrets (e.g. client_secret) values
that can only be used by scripts in a small time window once that can only be used by scripts in a small time window once
loaded from a server. The intention would be to reduce the loaded from a server. The intention would be to reduce the
effectiveness of copying client-side scripts for re-use in an effectiveness of copying client-side scripts for re-use in an
attackers modified code. [[pending discussion]] attackers modified code.
4.4.2.5. Threat: CSRF attack against redirect-uri 4.4.2.5. Threat: CSRF attack against redirect-uri
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has requests are transmitted from a user that the website trusts or has
authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
on OAuth approvals can allow an attacker to obtain authorization to on OAuth approvals can allow an attacker to obtain authorization to
OAuth protected resources without the consent of the User. OAuth protected resources without the consent of the User.
This attack works against the redirection URI used in the implicit This attack works against the redirection URI used in the implicit
skipping to change at page 36, line 50 skipping to change at page 37, line 41
Impact: The resource server can only differentiate scope based on the Impact: The resource server can only differentiate scope based on the
access token being associated with a particular client. The client access token being associated with a particular client. The client
could also acquire long-living tokens and pass them up to a attacker could also acquire long-living tokens and pass them up to a attacker
web service for further abuse. The client, eavesdroppers, or end- web service for further abuse. The client, eavesdroppers, or end-
points could eavesdrop user id and password. points could eavesdrop user id and password.
Countermeasures: Countermeasures:
o Except for migration reasons, minimize use of this grant type o Except for migration reasons, minimize use of this grant type
o The authorization server must 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 Authorization server MUST ensure that these transmissions are o As per the core Oauth spec, the authorization server must ensure
protected using transport-layer mechanisms such as TLS or SSL (see that these transmissions are protected using transport-layer
Section 5.1.1). mechanisms such as TLS or SSL (see Section 5.1.1).
4.4.3.1. Threat: Accidental exposure of passwords at client site 4.4.3.1. Threat: Accidental exposure of passwords at client site
If the client does not provide enough protection, an attacker or If the client does not provide enough protection, an attacker or
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
skipping to change at page 37, line 44 skipping to change at page 38, line 40
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
resource owner interaction resource owner interaction
o The authorization server may generally restrict the scope of o The authorization server may generally restrict the scope of
access tokens (Section 5.1.5.1) issued by this flow. If the access tokens (Section 5.1.5.1) issued by this flow. If the
particular client is trustworthy and can be authenticated in a particular client is trustworthy and can be authenticated in a
reliable way, the authorization server could relax that reliable way, the authorization server could relax that
restriction. Resource owners may prescribe (e.g. in their restriction. Resource owners may prescribe (e.g. in their
preferences) what the maximum permission for client using this preferences) what the maximum scope is for clients using this
flow shall be. flow.
o The authorization server could notify the resource owner by an o The authorization server could notify the resource owner by an
appropriate media, e.g. e-Mail, of the grant issued (see appropriate media, e.g. e-Mail, of the grant issued (see
Section 5.1.3). Section 5.1.3).
4.4.3.3. Threat: Client obtains refresh token through automatic 4.4.3.3. Threat: Client obtains refresh token through automatic
authorization 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
skipping to change at page 39, line 49 skipping to change at page 40, line 45
4.5. Refreshing an Access Token 4.5. Refreshing an Access Token
4.5.1. Threat: Eavesdropping refresh tokens from authorization server 4.5.1. Threat: Eavesdropping refresh tokens from authorization server
An attacker may eavesdrop refresh tokens when they are transmitted An attacker may eavesdrop refresh tokens when they are transmitted
from the authorization server to the client. from the authorization server to the client.
Countermeasures: Countermeasures:
o Authorization servers MUST ensure that these transmissions are o As per the core OAuth spec, the Authorization servers must ensure
protected using transport-layer mechanisms such as TLS or SSL (see that these transmissions are protected using transport-layer
Section 5.1.1). mechanisms such as TLS or SSL (see Section 5.1.1).
o If end-to-end confidentiality cannot be guaranteed, reducing scope o If end-to-end confidentiality cannot be guaranteed, reducing scope
(see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for
issued access tokens can be used to reduce the damage in case of issued access tokens can be used to reduce the damage in case of
leaks. leaks.
4.5.2. Threat: Obtaining refresh token from authorization server 4.5.2. Threat: Obtaining refresh token from authorization server
database database
This threat is applicable if the authorization server stores refresh This threat is applicable if the authorization server stores refresh
skipping to change at page 41, line 17 skipping to change at page 42, line 13
Countermeasures: Countermeasures:
o Server authentication (as described in Section 5.1.2) o 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 MUST by 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).
Countermeasures: Countermeasures:
o Access tokens sent as bearer tokens, SHOULD NOT be sent in the o Access tokens sent as bearer tokens, should not be sent in the
clear over an insecure channel. Instead transport protection clear over an insecure channel. As per the core OAuth spec,
means shall be utilized to prevent eavesdropping by an attacker transmission of access tokens must be protected using transport-
(see Section 5.1.1). layer mechanisms such as TLS or SSL (see Section 5.1.1).
o A short lifetime reduces impact in case tokens are compromised o A short lifetime reduces impact in case tokens are compromised
(see Section 5.1.5.3). (see Section 5.1.5.3).
o The access token can be bound to a client's identity and require o The access token can be bound to a client's identity and require
the client to authenticate with the resource server (see the client to prove legitimate ownership of the token to the
Section 5.4.2). Client authentication MUST be performed without resource server (see Section 5.4.2).
exposing the required secret to the transport channel.
4.6.2. Threat: Replay authorized resource server requests 4.6.2. Threat: Replay authorized resource server requests
An attacker could attempt to replay valid requests in order to obtain An attacker could attempt to replay valid requests in order to obtain
or to modify/destroy user data. or to modify/destroy user data.
Countermeasures: Countermeasures:
o The resource server should utilize transport security measure in o The resource server should utilize transport security measure in
order to prevent such attacks (see Section 5.1.1). This would order to prevent such attacks (see Section 5.1.1). This would
prevent the attacker from capturing valid requests. prevent the attacker from capturing valid requests.
o Alternatively, the resource server could employ signed requests o Alternatively, the resource server could employ signed requests
(see Section 5.4.3) along with nounces and timestamps in order to (see Section 5.4.3) along with nounces and timestamps in order to
uniquely identify requests. The resource server MUST detect and uniquely identify requests. The resource server should detect and
refuse every replayed request. refuse every replayed request.
4.6.3. Threat: Guessing access tokens 4.6.3. Threat: Guessing access tokens
Where the token is a handle, the attacker may use attempt to guess Where the token is a handle, the attacker may use attempt to guess
the access token values based on knowledge they have from other the access token values based on knowledge they have from other
access tokens. access tokens.
Impact: Access to a single user's data. Impact: Access to a single user's data.
Countermeasures: Countermeasures:
o Handle Tokens should have a reasonable entropy (see o Handle Tokens should have a reasonable entropy (see
Section 5.1.5.11) in order to make guessing a valid token value Section 5.1.5.11) in order to make guessing a valid token value
difficult. difficult.
o Assertion (or self-contained token ) tokens contents SHALL be o Assertion (or self-contained token ) tokens contents should be
protected by a digital signature (see Section 5.1.5.9). protected by a digital signature (see Section 5.1.5.9).
o Security can be further strengthened by using a short access token o Security can be further strengthened by using a short access token
duration (see Section 5.1.5.2 and Section 5.1.5.3). duration (see Section 5.1.5.2 and Section 5.1.5.3).
4.6.4. Threat: Access token phishing by counterfeit resource server 4.6.4. Threat: Access token phishing by counterfeit resource server
An attacker may pretend to be a particular resource server and to An attacker may pretend to be a particular resource server and to
accept tokens from a particular authorization server. If the client accept tokens from a particular authorization server. If the client
sends a valid access tokens to this counterfeit resource server, the sends a valid access tokens to this counterfeit resource server, the
server in turn may use that token to access other services on behalf server in turn may use that token to access other services on behalf
of the resource owner. of the resource owner.
Countermeasures: Countermeasures:
o Clients SHOULD not make authenticated requests with an access o Clients should not make authenticated requests with an access
token to unfamiliar resource servers, regardless of the presence token to unfamiliar resource servers, regardless of the presence
of a secure channel. If the resource server address is well-known of a secure channel. If the resource server address is well-known
to the client, it may authenticate the resource servers (see to the client, it may authenticate the resource servers (see
Section 5.1.2). Section 5.1.2).
o Associate the endpoint address of the resource server the client o Associate the endpoint address of the resource server the client
talked to with the access token (e.g. in an audience field) and talked to with the access token (e.g. in an audience field) and
validate association at legitimate resource server. The endpoint validate association at legitimate resource server. The endpoint
address validation policy may be strict (exact match) or more address validation policy may be strict (exact match) or more
relaxed (e.g. same host). This would require to tell the relaxed (e.g. same host). This would require to tell the
skipping to change at page 43, line 37 skipping to change at page 44, line 32
WWW-Authenticate headers to distinguish authenticated content so that WWW-Authenticate headers to distinguish authenticated content so that
it can be protected. Proxies and caches, in particular, may fail to it can be protected. Proxies and caches, in particular, may fail to
adequately protect requests not using these headers. For example, adequately protect requests not using these headers. For example,
private authenticated content may be stored in (and thus retrievable private authenticated content may be stored in (and thus retrievable
from) publicly-accessible caches. from) publicly-accessible caches.
Countermeasures: Countermeasures:
o Resource servers not using the HTTP Authorization scheme (OAuth o Resource servers not using the HTTP Authorization scheme (OAuth
HTTP Authorization Scheme - see Section 5.4.1) should take care to HTTP Authorization Scheme - see Section 5.4.1) should take care to
use other mechanisms, such as the Cache-Control header, to ensure use other mechanisms, such as the Cache-Control header, to
that authenticated content is protected. minimize the risk that authenticated content is not protected.
o Reducing scope (see Section 5.1.5.1) and expiry time o Reducing scope (see Section 5.1.5.1) and expiry time
(Section 5.1.5.3) for access tokens can be used to reduce the (Section 5.1.5.3) for access tokens can be used to reduce the
damage in case of leaks. damage in case of leaks.
4.6.7. Threat: Token leakage via logfiles and HTTP referrers 4.6.7. Threat: Token leakage via logfiles and HTTP referrers
If access tokens are sent via URI query parameters, such tokens may If access tokens are sent via URI query parameters, such tokens may
leak to log files and HTTP referrers. leak to log files and HTTP referrers.
skipping to change at page 45, line 19 skipping to change at page 46, line 12
o Replay of user passwords and client secrets o Replay of user passwords and client secrets
5.1.2. Server authentication 5.1.2. 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 DNS name of the server to the public key presented by the server the DNS name of the server to the public key presented by the server
during connection establishment. during connection establishment.
The client MUST 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
certification authorities the client trusts for that purpose. certification authorities the client trusts for that purpose.
Clients should carefully select those trusted CAs and protect the Clients should carefully select those trusted CAs and protect the
storage for trusted CA certificates from modifications. storage for trusted CA certificates from modifications.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o Spoofing o Spoofing
o Proxying o Proxying
o Phishing by counterfeit servers o Phishing by counterfeit servers
5.1.3. Always keep the resource owner informed 5.1.3. Always keep the resource owner informed
Transparency to the resource owner is a key element of the OAuth Transparency to the resource owner is a key element of the OAuth
protocol. The user shall always be in control of the authorization protocol. The user should always be in control of the authorization
processes and get the necessary information to meet informed processes and get the necessary information to meet informed
decisions. Moreover, user involvement is a further security decisions. Moreover, user involvement is a further security
countermeasure. The user can probably recognize certain kinds of countermeasure. The user can probably recognize certain kinds of
attacks better than the authorization server. Information can be attacks better than the authorization server. Information can be
presented/exchanged during the authorization process, after the presented/exchanged during the authorization process, after the
authorization process, and every time the user wishes to get informed authorization process, and every time the user wishes to get informed
by using techniques such as: by using techniques such as:
o User consent forms o User consent forms
skipping to change at page 46, line 47 skipping to change at page 47, line 39
o When using dynamic SQL, parameterize queries using bind arguments. o When using dynamic SQL, parameterize queries using bind arguments.
Bind arguments eliminate possibility of SQL injections. Bind arguments eliminate possibility of SQL injections.
o Filter and sanitize the input. For example, if an identifier has o Filter and sanitize the input. For example, if an identifier has
a known format, ensure that the supplied value matches the a known format, ensure that the supplied value matches the
identifier syntax rules. identifier syntax rules.
5.1.4.1.3. No cleartext storage of credentials 5.1.4.1.3. No cleartext storage of credentials
The authorization server may consider to not store credential in The authorization server should not store credential in clear text.
clear text. Typical approaches are to store hashes instead. If the Typical approaches are to store hashes instead. If the credential
credential lacks a reasonable entropy level (because it is a user lacks a reasonable entropy level (because it is a user password) an
password) an additional salt will harden the storage to prevent additional salt will harden the storage to prevent offline dictionary
offline dictionary attacks. Note: Some authentication protocols attacks. Note: Some authentication protocols require the
require the authorization server to have access to the secret in the authorization server to have access to the secret in the clear.
clear. Those protocols cannot be implemented if the server only has Those protocols cannot be implemented if the server only has access
access to hashes. to hashes.
5.1.4.1.4. Encryption of credentials 5.1.4.1.4. Encryption of credentials
For client applications, insecurely persisted client credentials are For client applications, insecurely persisted client credentials are
easy targets for attackers to obtain. Store client credentials using easy targets for attackers to obtain. Store client credentials using
an encrypted persistence mechanism such as a keystore or database. an encrypted persistence mechanism such as a keystore or database.
Note that compiling client credentials directly into client code Note that compiling client credentials directly into client code
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. Nevertheless, it MUST of the obligation to manage credentials.
ensure the integrity of the respective public keys.
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. 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. password policy in order to increase the user passwords' entropy.
This will hinder online password attacks. This will hinder online password attacks.
5.1.4.2.2. High entropy of secrets 5.1.4.2.2. High entropy of secrets
When creating token handles or other secrets not intended for usage When creating token handles or other secrets not intended for usage
by human users, the authorization server MUST include a reasonable by human users, the authorization server should include a reasonable
level of entropy in order to mitigate the risk of guessing attacks. level of entropy in order to mitigate the risk of guessing attacks.
The token value MUST be constructed from a cryptographically strong The token value should be constructed from a cryptographically strong
random or pseudo-random number sequence [RFC1750] generated by the random or pseudo-random number sequence [RFC1750] generated by the
Authorization Server. The probability of any two Authorization Code Authorization Server. The probability of any two Authorization Code
values being identical MUST be less than or equal to 2^(-128) and values being identical should be less than or equal to 2^(-128) and
SHOULD be less than or equal to 2^(-160). should be less than or equal to 2^(-160).
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. Tar pit
skipping to change at page 49, line 39 skipping to change at page 50, line 28
The authorization server may restrict the number of requests or The authorization server may restrict the number of requests or
operations which can be performed with a certain token. This operations which can be performed with a certain token. This
mechanism can be used to mitigate the following threats: mechanism can be used to mitigate the following threats:
o replay of tokens o replay of tokens
o reduce likelihood of successful online guessing o reduce likelihood of successful online guessing
For example, if an Authorization Server observes more than one For example, if an Authorization Server observes more than one
attempt to redeem a authorization code, the Authorization Server MAY attempt to redeem a authorization code, the Authorization Server may
want to revoke all access tokens granted based on the authorization want to revoke all access tokens granted based on the authorization
code as well as reject the current request. code as well as reject the current request.
As with the authorization code, access tokens MAY also have a limited As with the authorization code, access tokens may also have a limited
number of operations. This forces client applications to either re- number of operations. This forces client applications to either re-
authenticate and use a refresh token to obtain a fresh access token, authenticate and use a refresh token to obtain a fresh access token,
or it forces the client to re-authorize the access token by involving or it forces the client to re-authorize the access token by involving
the user. the user.
5.1.5.5. Bind tokens to a particular resource server (Audience) 5.1.5.5. Bind tokens to a particular resource server (Audience)
Authorization servers in multi-service environments may consider to Authorization servers in multi-service environments may consider
issue tokens with different content to different resource servers and issuing tokens with different content to different resource servers
to explicitly indicate in the token the target server a token is and to explicitly indicate in the token the target server a token is
intended to be sent to (see Audience in SAML Assertions). This intended to be sent to (see Audience in SAML Assertions). This
countermeasure can be used in the following situations: countermeasure can be used in the following situations:
o It reduce the impact of a successful replay attempt, since the o It reduces the impact of a successful replay attempt, since the
token is applicable to a single resource server, only. token is applicable to a single resource server, only.
o It prevents abuse of a token by a rough resource server or client, o It prevents abuse of a token by a rough resource server or client,
since the token can only be used on that server. It is rejected since the token can only be used on that server. It is rejected
by other servers. by other servers.
o It reduce the impact of a leakage of a valid token to a o It reduces the impact of a leakage of a valid token to a
counterfeit resource server. counterfeit resource server.
5.1.5.6. Use endpoint address as token audience 5.1.5.6. Use endpoint address as token audience
This may be used to indicate to a resource server, which endpoint This may be used to indicate to a resource server, which endpoint
address has been used to obtain the token. This measure will allow address has been used to obtain the token. This measure will allow
to detect requests from a counterfeit resource server, since such to detect requests from a counterfeit resource server, since such
token will contain the endpoint address of that server. token will contain the endpoint address of that server.
5.1.5.7. Audience and Token scopes 5.1.5.7. Audience and Token scopes
Deployments may consider to use only tokens with explicitly defined Deployments may consider only using tokens with explicitly defined
scope, where every scope is associated with a particular resource scope, where every scope is associated with a particular resource
server. This approach can be used to mitigate attacks, where a server. This approach can be used to mitigate attacks, where a
resource server or client uses a token for a different then the resource server or client uses a token for a different then the
intended purpose. intended purpose.
5.1.5.8. Bind token to client id 5.1.5.8. Bind token to client id
An authorization server may bind a token to a certain client An authorization server may bind a token to a certain client
identity. This identity match must be validated for every request identity. This identity should be validated for every request with
with that token. This means can be used, to that token. This means can be used, to
o detect token leakage and o detect token leakage and
o prevent token abuse. o prevent token abuse.
Note: Validating the client identity may require the target server to Note: Validating the client identity may require the target server to
authenticate the client's identity. This authentication can be based authenticate the client's identity. This authentication can be based
on secrets managed independent of the token (e.g. pre-registered on secrets managed independent of the token (e.g. pre-registered
client id/secret on authorization server) or sent with the token client id/secret on authorization server) or sent with the token
itself (e.g. as part of the encrypted token content). itself (e.g. as part of the encrypted token content).
5.1.5.9. Signed tokens 5.1.5.9. Signed tokens
Self-contained tokens SHOULD be signed in order to detect any attempt Self-contained tokens should be signed in order to detect any attempt
to modify or produce faked tokens. to modify or produce faked tokens.
5.1.5.10. Encryption of token content 5.1.5.10. Encryption of token content
Self-contained may be encrypted for privacy reasons or to protect Self-contained may be encrypted for privacy reasons or to protect
system internal data. system internal data.
5.1.5.11. Random token value with high entropy 5.1.5.11. Random token value with high entropy
When creating token handles, the authorization server MUST include a When creating token handles, the authorization server should include
reasonable level of entropy in order to mitigate the risk of guessing a reasonable level of entropy in order to mitigate the risk of
attacks. The token value MUST be constructed from a guessing attacks. The token value should be constructed from a
cryptographically strong random or pseudo-random number sequence cryptographically strong random or pseudo-random number sequence
[RFC1750] generated by the Authorization Server. The probability of [RFC1750] generated by the Authorization Server. The probability of
any two token values being identical MUST be less than or equal to any two token values being identical should be less than or equal to
2^(-128) and SHOULD be less than or equal to 2^(-160). 2^(-128) and should be less than or equal to 2^(-160).
5.1.5.12. Assertion formats 5.1.5.12. Assertion formats
For service providers intending to implement an assertion-based token For service providers intending to implement an assertion-based token
design it is highly recommended to adopt a standard assertion format design it is highly recommended to adopt a standard assertion format
(such as SAML or JWT) that implements [draft-ietf-oauth-assertions]. (such as SAML or JWT) that implements [draft-ietf-oauth-assertions].
5.1.6. Access tokens 5.1.6. Access tokens
The following measures should be used to protect access tokens
o keep them in transient memory (accessible by the client o keep them in transient memory (accessible by the client
application only) application only)
o protect from exposure to 3rd parties (malicious application) o protect from exposure to 3rd parties (malicious application)
o limit number of access tokens granted to a user o limit number of access tokens granted to a user
5.2. Authorization Server 5.2. Authorization Server
This section describes considerations related to the OAuth This section describes considerations related to the OAuth
skipping to change at page 52, line 17 skipping to change at page 53, line 7
5.2.2.1. Restricted issuance of refresh tokens 5.2.2.1. Restricted issuance of refresh tokens
The authorization server may decide based on an appropriate policy The authorization server may decide based on an appropriate policy
not to issue refresh tokens. Since refresh tokens are long term not to issue refresh tokens. Since refresh tokens are long term
credentials, they may be subject theft. For example, if the credentials, they may be subject theft. For example, if the
authorization server does not trust a client to securely store such authorization server does not trust a client to securely store such
tokens, it may refuse to issue such a client a refresh token. tokens, it may refuse to issue such a client a refresh token.
5.2.2.2. Binding of refresh token to client_id 5.2.2.2. Binding of refresh token to client_id
The authorization server MUST bind every refresh token to the id of The authorization server should bind every refresh token to the id of
the client such a token was originally issued to and validate this the client such a token was originally issued to and validate this
binding for every request to refresh that token. This measure is a binding for every request to refresh that token. If possible (e.g.
countermeasure against refresh token theft or leakage. confidential clients), the authorization server should authenticate
the respective client.
Note: This binding MUST be protected from unauthorized modifications. This is a countermeasure against refresh token theft or leakage.
Note: This binding should be protected from unauthorized
modifications.
5.2.2.3. Refresh Token Rotation 5.2.2.3. Refresh Token Rotation
Refresh token rotation is intended to automatically detect and Refresh token rotation is intended to automatically detect and
prevent attempts to use the same refresh token in parallel from prevent attempts to use the same refresh token in parallel from
different apps/devices. This happens if a token gets stolen from the different apps/devices. This happens if a token gets stolen from the
client and is subsequently used by the attacker and the legitimate client and is subsequently used by the attacker and the legitimate
client. The basic idea is to change the refresh token value with client. The basic idea is to change the refresh token value with
every refresh request in order to detect attempts to obtain access every refresh request in order to detect attempts to obtain access
tokens using old refresh tokens. Since the authorization server tokens using old refresh tokens. Since the authorization server
skipping to change at page 53, line 14 skipping to change at page 54, line 8
o device theft, o device theft,
o impersonation of resource owner, or o impersonation of resource owner, or
o suspected compromised client applications. o suspected compromised client applications.
5.2.2.5. Device identification 5.2.2.5. Device identification
The authorization server may require to bind authentication The authorization server may require to bind authentication
credentials to a device identifier or token assigned to that device. credentials to a device identifier. The IMEI is one example of such
As the IMEI can be spoofed, that is not suitable, For mobile phones, an identifier, there are also operating system specific identifiers.
a registration process can be used to assign a unique token to the The authorization server could include such an identifier when
device using an SMS message. That token or identifier can then be authenticating user credentials in order to detect token theft from a
validated with when authenticating user credentials. particular device.
This is a countermeasure against the following threats:
o token theft from a particular device
5.2.2.6. X-FRAME-OPTION header 5.2.2.6. X-FRAME-OPTION header
For newer browsers, avoidance of iFrames can be enforced server side For newer browsers, avoidance of iFrames can be enforced server side
by using the X-FRAME-OPTION header. This header can have two values, by using the X-FRAME-OPTION header. This header can have two values,
deny and same origin, which will block any framing or framing by deny and same origin, which will block any framing or framing by
sites with a different origin, respectively. sites with a different origin, respectively.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o Clickjacking attacks o Clickjacking attacks
5.2.3. Public client authentication and authorization 5.2.3. Client authentication and authorization
As described in Section 3 (Security Features), clients are As described in Section 3 (Security Features), clients are
identified, authenticated and authorized for several purposes, such identified, authenticated and authorized for several purposes, such
as a as a
o Collate sub-sequent requests to the same client, o Collate sub-sequent requests to the same client,
o Indicate the trustworthiness of a particular client to the end- o Indicate the trustworthiness of a particular client to the end-
user, user,
skipping to change at page 54, line 41 skipping to change at page 55, line 32
out of work. Moreover, since the authorization server cannot really out of work. Moreover, since the authorization server cannot really
trust on the client's identity, it would be dangerous to indicate to trust on the client's identity, it would be dangerous to indicate to
end-users the trustworthiness of the client. end-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. Public clients without secret require user consent
Authorization servers should not allow automatic authorization for Authorization servers should not allow automatic authorization for
public clients. The authorization may issue a client id, but SHOULD public clients. The authorization may issue a client id, but should
require that all authorizations are approved by the end-user. This require that all authorizations are approved by the end-user. This
is a countermeasure for clients without secret against the following is a countermeasure for clients without secret against the following
threats: 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
The authorization may issue a client_id and bind the client_id to a The authorization may issue a client_id and bind the client_id to a
certain pre-configured redirect_uri. Any authorization request with certain pre-configured redirect_uri. Any authorization request with
another redirection URI is refused automatically. Alternatively, the another redirection URI is refused automatically. Alternatively, the
authorization server MUST not accept any dynamic redirection URI for authorization server should not accept any dynamic redirection URI
such a client_id and instead always redirect to the well-known pre- for such a client_id and instead always redirect to the well-known
configured redirection URI. This is a countermeasure for clients pre-configured redirection URI. This is a countermeasure for clients
without secrets against the following threats: without secrets against the following threats:
o Cross-site scripting attacks o Cross-site scripting attacks
o Impersonation of public client applications o Impersonation of public client applications
5.2.3.4. Deployment-specific client secrets 5.2.3.4. Deployment-specific client secrets
A authorization server may issue separate client identifiers and A authorization server may issue separate client identifiers and
corresponding secrets to the different deployments of a client. The corresponding secrets to the different deployments of a client. The
skipping to change at page 56, line 8 skipping to change at page 56, line 43
The first approach would allow to achieve a level where the client is The first approach would allow to achieve a level where the client is
authenticated and identified, whereas the second option only allows authenticated and identified, whereas the second option only allows
to authenticate the client but not to validate properties of the to authenticate the client but not to validate properties of the
client. But this would at least help to prevent several replay client. But this would at least help to prevent several replay
attacks. Moreover, deployment-specific client_id and secret allow to attacks. Moreover, deployment-specific client_id and secret allow to
selectively revoke all refresh tokens of a specific deployment at selectively revoke all refresh tokens of a specific deployment at
once. once.
5.2.3.5. Validation of pre-registered redirect_uri 5.2.3.5. Validation of pre-registered redirect_uri
An authorization server SHOULD require all clients to register their An authorization server should require all clients to register their
redirect_uri and the redirect_uri should be the full URI as defined redirect_uri and the redirect_uri should be the full URI as defined
in [I-D.ietf-oauth-v2]. The way this registration is performed is in [I-D.ietf-oauth-v2]. The way this registration is performed is
out of scope of this document. Every actual redirection URI sent out of scope of this document. As per the core spec, every actual
with the respective client_id to the end-user authorization endpoint redirection URI sent with the respective client_id to the end-user
must match the registered redirection URI. Where it does not match, authorization endpoint must match the registered redirection URI.
the authorization server must assume the inbound GET request has been Where it does not match, the authorization server should assume the
sent by an attacker and refuse it. Note: the authorization server inbound GET request has been sent by an attacker and refuse it.
MUST NOT redirect the user agent back to the redirection URI of such Note: the authorization server should not redirect the user agent
an authorization request. back to the redirection URI of such an authorization request.
o Authorization code leakage through counterfeit web site: allows to o Authorization code leakage through counterfeit web site: allows to
detect attack attempts already after first redirect to end-user detect attack attempts already after first redirect to end-user
authorization endpoint (Section 4.4.1.7). authorization endpoint (Section 4.4.1.7).
o For clients with validated properties, this measure also helps to o For clients with validated properties, this measure also helps to
detect malicious applications early in the end-user authorization detect malicious applications early in the end-user authorization
process. This reduces the need for a interactive validation by process. This reduces the need for a interactive validation by
the user (Section 4.4.1.4, Section 4.4.2.3). the user (Section 4.4.1.4, Section 4.4.2.3).
o Open Redirector attack via client redirection endpoint. ( o Open Redirector attack via client redirection endpoint. (
Section 4.1.5. ) Section 4.1.5. )
o Open Redirector phishing attack via authorization server o Open Redirector phishing attack via authorization server
redirection endpoint ( Section 4.2.4 ) redirection endpoint ( Section 4.2.4 )
The underlying assumption of this measure is that an attacker must The underlying assumption of this measure is that an attacker will
use another redirection URI in order to get access to the need to use another redirection URI in order to get access to the
authorization code. Deployments might consider the possibility of an authorization code. Deployments might consider the possibility of an
attacker using spoofing attacks to a victims device to circumvent attacker using spoofing attacks to a victims device to circumvent
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, it specified yet). With the lack of dynamic client registration, it
only works for clients bound to certain deployments at development/ only works for clients bound to certain deployments at development/
configuration time. As soon as dynamic resource server discovery configuration time. As soon as dynamic resource server discovery
gets involved, that's no longer feasible. gets involved, that's no longer feasible.
skipping to change at page 57, line 32 skipping to change at page 58, line 16
process. process.
5.2.4. End-user authorization 5.2.4. End-user authorization
This secion involves considerations for authorization flows involving This secion involves considerations for authorization flows involving
the end-user. the end-user.
5.2.4.1. Automatic processing of repeated authorizations requires 5.2.4.1. Automatic processing of repeated authorizations requires
client validation client validation
Authorization servers SHOULD NOT automatically process repeat Authorization servers should NOT automatically process repeat
authorizations where the client is not authenticated through a client authorizations where the client is not authenticated through a client
secret or some other authentication mechanism such as signing with secret or some other authentication mechanism such as signing with
security certificates (5.7.2.7. Use strong client authentication security certificates (5.7.2.7. Use strong client authentication
(e.g. client_assertion / client_token)) or validation of a pre- (e.g. client_assertion / client_token)) or validation of a pre-
registered redirect URI (5.7.2.5. Validation of pre-registered registered redirect URI (5.7.2.5. Validation of pre-registered
redirection URI ). redirection URI ).
5.2.4.2. Informed decisions based on transparency 5.2.4.2. Informed decisions based on transparency
The authorization server SHOULD clearly explain to the end-user what The authorization server should clearly explain to the end-user what
happens in the authorization process and what the consequences are. happens in the authorization process and what the consequences are.
For example, the user shall understand what access he is about to For example, the user should understand what access he is about to
grant to which client for what duration. It shall also be obvious to grant to which client for what duration. It should also be obvious
the user, whether the server is able to reliably certify certain to the user, whether the server is able to reliably certify certain
client properties (web site address, security policy). client properties (web site address, security policy).
5.2.4.3. Validation of client properties by end-user 5.2.4.3. Validation of client properties by end-user
In the authorization process, the user is typically asked to approve In the authorization process, the user is typically asked to approve
a client's request for authorization. This is an important security a client's request for authorization. This is an important security
mechanism by itself because the end-user can be involved in the mechanism by itself because the end-user can be involved in the
validation of client properties, such as whether the client name validation of client properties, such as whether the client name
known to the authorization server fits the name of the web site or known to the authorization server fits the name of the web site or
the application the end-user is using. This measure is especially the application the end-user is using. This measure is especially
helpful in all situation where the authorization server is unable to helpful in all situation where the authorization server is unable to
authenticate the client. It is a countermeasure against: authenticate the client. It is a countermeasure against:
o Malicious application o Malicious application
o A client application masquerading as another client o A client application masquerading as another client
5.2.4.4. Binding of authorization code to client_id 5.2.4.4. Binding of authorization code to client_id
The authorization server MUST bind every authorization code to the id The authorization server should bind every authorization code to the
of the respective client which initiated the end-user authorization id of the respective client which initiated the end-user
process. This measure is a countermeasure against: authorization process. This measure is a countermeasure against:
o replay of authorization codes with different client credentials o replay of authorization codes with different client credentials
since an attacker cannot use another client_id to exchange an since an attacker cannot use another client_id to exchange an
authorization code into a token authorization code into a token
o Online guessing of authorization codes o Online guessing of authorization codes
Note: This binding MUST be protected from unauthorized modifications. Note: This binding should be protected from unauthorized
modifications.
5.2.4.5. Binding of authorization code to redirect_uri 5.2.4.5. Binding of authorization code to redirect_uri
The authorization server MUST bind every authorization code to the The authorization server should bind every authorization code to the
actual redirection URI used as redirect target of the client in the actual redirection URI used as redirect target of the client in the
end-user authorization process. This binding MUST be validated when end-user authorization process. This binding should be validated
the client attempts to exchange the respective authorization code for when the client attempts to exchange the respective authorization
an access token. This measure is a countermeasure against code for an access token. This measure is a countermeasure against
authorization code leakage through counterfeit web sites since an authorization code leakage through counterfeit web sites since an
attacker cannot use another redirection URI to exchange an attacker cannot use another redirection URI to exchange an
authorization code into a token. authorization code into a token.
5.3. Client App Security 5.3. Client App Security
This section deals with considerations for client applications. This section deals with considerations for client applications.
5.3.1. Don't store credentials in code or resources bundled with 5.3.1. Don't store credentials in code or resources bundled with
software packages software packages
skipping to change at page 59, line 14 skipping to change at page 60, line 8
of the application or a associated resource bundle, cannot be of the application or a associated resource bundle, cannot be
entirely protected from reverse engineering. Secondly, such secrets entirely protected from reverse engineering. Secondly, such secrets
cannot be revoked since this would immediately put all installations cannot be revoked since this would immediately put all installations
out of work. Moreover, since the authorization server cannot really out of work. Moreover, since the authorization server cannot really
trust on the client's identity, it would be dangerous to indicate to trust on the client's identity, it would be dangerous to indicate to
end-users the trustworthiness of the client. end-users the trustworthiness of the client.
5.3.2. Standard web server protection measures (for config files and 5.3.2. Standard web server protection measures (for config files and
databases) databases)
Use standard web server protection measures - Section 5.3.2
5.3.3. Store secrets in a secure storage 5.3.3. Store secrets in a secure storage
The are different way to store secrets of all kinds (tokens, client The are different way to store secrets of all kinds (tokens, client
secrets) securely on a device or server. secrets) securely on a device or server.
Most multi-user operation systems segregate the personal storage of Most multi-user operation systems segregate the personal storage of
the different system users. Moreover, most modern smartphone the different system users. Moreover, most modern smartphone
operating systems even support to store app-specific data in separate operating systems even support to store app-specific data in separate
areas of the file systems and protect it from access by other areas of the file systems and protect it from access by other
applications. Additionally, applications can implements confidential applications. Additionally, applications can implements confidential
data itself using a user-supplied secret, such as PIN or password. data itself using a user-supplied secret, such as PIN or password.
Another option is to swap refresh token storage to a trusted backend Another option is to swap refresh token storage to a trusted backend
server. This mean in turn requires a resilient authentication server. This mean in turn requires a resilient authentication
mechanisms between client and backend server. Note: Applications mechanisms between client and backend server. Note: Applications
must ensure that confidential data are kept confidential even after should ensure that confidential data is kept confidential even after
reading from secure storage, which typically means to keep this data reading from secure storage, which typically means to keep this data
in the local memory of the application. in the local memory of the application.
5.3.4. Utilize device lock to prevent unauthorized device access 5.3.4. Utilize device lock to prevent unauthorized device access
On a typical modern phone, there are many "device lock" options which
can be utilized to provide additional protection where a device is
stolen or misplaced. These include PINs, passwords and other
biomtric featres such as "face recognition". These are not equal in
their level of security they provide.
5.3.5. Platform security measures 5.3.5. Platform security measures
o Validation process o Validation process
o software package signatures o software package signatures
o Remote removal o Remote removal
5.3.6. Link state parameter to user agent session 5.3.6. Link state parameter to user agent session
The state parameter is used to link client requests and prevent CSRF The state parameter is used to link client requests and prevent CSRF
attacks, for example against the redirection URI. An attacker could attacks, for example against the redirection URI. An attacker could
inject their own authorization code or access token, which can result inject their own authorization code or access token, which can result
in the client using an access token associated with the attacker's in the client using an access token associated with the attacker's
protected resources rather than the victim's (e.g. save the victim's protected resources rather than the victim's (e.g. save the victim's
bank account information to a protected resource controlled by the bank account information to a protected resource controlled by the
attacker). attacker).
The client SHOULD utilize the "state" request parameter to send the The client should utilize the "state" request parameter to send the
authorization server a value that binds the request to the user- authorization server a value that binds the request to the user-
agent's authenticated state (e.g. a hash of the session cookie used agent's authenticated state (e.g. a hash of the session cookie used
to authenticate the user-agent) when making an authorization request. to authenticate the user-agent) when making an authorization request.
Once authorization has been obtained from the end-user, the Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state" client with the required binding value contained in the "state"
parameter. parameter.
The binding value enables the client to verify the validity of the The binding value enables the client to verify the validity of the
request by matching the binding value to the user- agent's request by matching the binding value to the user- agent's
skipping to change at page 61, line 16 skipping to change at page 62, line 20
able to validate whether the authorization server issued the token able to validate whether the authorization server issued the token
to that client to that client
This mechanisms is a countermeasure against abuse of tokens by This mechanisms is a countermeasure against abuse of tokens by
counterfeit resource servers. counterfeit resource servers.
5.4.3. Signed requests 5.4.3. Signed requests
A resource server may decide to accept signed requests only, either A resource server may decide to accept signed requests only, either
to replace transport level security measures or to complement such to replace transport level security measures or to complement such
measures. Every signed request must be uniquely identifiable and measures. Every signed request should be uniquely identifiable and
must not be processed twice by the resource server. This should not be processed twice by the resource server. This
countermeasure helps to mitigate: countermeasure helps to mitigate:
o modifications of the message and o modifications of the message and
o replay attempts o replay attempts
6. IANA Considerations 6. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an Note to RFC Editor: this section may be removed on publication as an
RFC. RFC.
7. Acknowledgements 7. Acknowledgements
We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam, We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam,
Shane B Weeden, Skylar Woodward, Niv Steingarten and James H. Manger Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James
for their comments and contributions. H. Manger for their comments and contributions.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0
2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work Authorization Protocol", draft-ietf-oauth-v2-23 (work in
in progress), September 2011. progress), January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 8.2. Informative References
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Authorization Protocol: Bearer Tokens", Authorization Protocol: Bearer Tokens",
draft-ietf-oauth-v2-bearer-11 (work in progress), draft-ietf-oauth-v2-bearer-17 (work in progress),
October 2011. February 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication: MAC Access Authentication", Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
draft-ietf-oauth-v2-http-mac-00 (work in progress), progress), February 2012.
May 2011.
[I-D.lodderstedt-oauth-revocation] [I-D.lodderstedt-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-lodderstedt-oauth-revocation-03 (work Revocation", draft-lodderstedt-oauth-revocation-03 (work
in progress), September 2011. in progress), September 2011.
[portable-contacts] [portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008. Smarr, J., "Portable Contacts 1.0 Draft C", August 2008.
Appendix A. Document History Appendix A. Document History
skipping to change at page 64, line 5 skipping to change at page 64, line 48
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
o Incoporated Tim Bray's review comments (e.g. removed all normative
language)
Authors' Addresses Authors' Addresses
Torsten Lodderstedt (editor) Torsten Lodderstedt (editor)
Deutsche Telekom AG Deutsche Telekom AG
Email: torsten@lodderstedt.net Email: torsten@lodderstedt.net
Mark McGloin Mark McGloin
IBM IBM
 End of changes. 196 change blocks. 
380 lines changed or deleted 410 lines changed or added

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