draft-ietf-oauth-v2-threatmodel-00.txt   draft-ietf-oauth-v2-threatmodel-01.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: Standards Track M. McGloin Intended status: Informational M. McGloin
Expires: January 2, 2012 IBM Expires: April 28, 2012 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
July 01, 2011 October 26, 2011
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-00 draft-ietf-oauth-v2-threatmodel-01
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 January 2, 2012. This Internet-Draft will expire on April 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 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
2.3.3.1. Web Application . . . . . . . . . . . . . . . . . 9 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3.2. Native Applications . . . . . . . . . . . . . . . 9 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3.3. User-agent-based Applications . . . . . . . . . . 10 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3.4. Autonomous . . . . . . . . . . . . . . . . . . . . 11 3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12
3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 13 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12
3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 13 3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12
3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 14 4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14
3.5. Redirect-URI . . . . . . . . . . . . . . . . . . . . . . . 14 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 14 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15
3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 14 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16
4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 16 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 17
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 18
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 20
4.1.4. Threat: End-user credentials phished using 4.1.4. Threat: End-user credentials phished using
compromised or embedded browser . . . . . . . . . . . 20 compromised or embedded browser . . . . . . . . . . . 18
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 21 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19
4.2.1. Threat: Password phishing by counterfeit 4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 21 authorization server . . . . . . . . . . . . . . . . . 19
4.2.2. Threat: User unintentionally grants too much 4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 21 access scope . . . . . . . . . . . . . . . . . . . . . 20
4.2.3. Threat: Malicious client obtains existing 4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 22 authorization by fraud . . . . . . . . . . . . . . . . 20
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 23 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 23 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 21
4.3.2. Threat: Obtain access tokens from authorization 4.3.2. Threat: Obtain access tokens from authorization
server database . . . . . . . . . . . . . . . . . . . 23 server database . . . . . . . . . . . . . . . . . . . 21
4.3.3. Threat: Obtain client credentials over non secure 4.3.3. Threat: Obtain client credentials over non secure
transport . . . . . . . . . . . . . . . . . . . . . . 23 transport . . . . . . . . . . . . . . . . . . . . . . 22
4.3.4. Threat: Obtain client secret from authorization 4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 24 server database . . . . . . . . . . . . . . . . . . . 22
4.3.5. Threat: Obtain client secret by online guessing . . . 24 4.3.5. Threat: Obtain client secret by online guessing . . . 22
4.3.6. Threat: DoS on dynamic client secret creation . . . . 24 4.3.6. Threat: DoS on dynamic client secret creation . . . . 23
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 25 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 25 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 23
4.4.1.1. Threat: Eavesdropping or leaking authorization 4.4.1.1. Threat: Eavesdropping or leaking authorization
codes . . . . . . . . . . . . . . . . . . . . . . 25 codes . . . . . . . . . . . . . . . . . . . . . . 23
4.4.1.2. Threat: Obtain authorization codes from 4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 26 authorization server database . . . . . . . . . . 24
4.4.1.3. Threat: Online guessing of authorization codes . . 27 4.4.1.3. Threat: Online guessing of authorization codes . . 25
4.4.1.4. Threat: Malicious client obtains authorization . . 27 4.4.1.4. Threat: Malicious client obtains authorization . . 25
4.4.1.5. Threat: Authorization code phishing . . . . . . . 28 4.4.1.5. Threat: Authorization code phishing . . . . . . . 26
4.4.1.6. Threat: User session impersonation . . . . . . . . 29 4.4.1.6. Threat: User session impersonation . . . . . . . . 27
4.4.1.7. Threat: Authorization code leakage through 4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 29 counterfeit client . . . . . . . . . . . . . . . . 28
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 29
4.4.1.9. Threat: Clickjacking attack against 4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 32 authorization . . . . . . . . . . . . . . . . . . 30
4.4.1.10. Threat: DoS, Exhaustion of resources attacks . . . 32 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31
4.4.1.11. Threat: DoS using manufactured authorization 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 32
codes . . . . . . . . . . . . . . . . . . . . . . 33 4.4.1.12. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 32
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 34 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 34
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 . . . . . . . . . . . . . . . 34
4.4.2.2. Threat: Access token leak in browser history . . . 35 4.4.2.2. Threat: Access token leak in browser history . . . 34
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 . . . . . . . . . 35
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 35
4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 4.4.3. Resource Owner Password Credentials . . . . . . . . . 36
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 . . . . . . . . . . . . . . . . . . . 37
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 38 authorization . . . . . . . . . . . . . . . . . . 37
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 . . . . 39 4.4.3.4. Threat: Obtain user passwords on transport . . . . 38
4.4.3.5. Threat: Obtain user passwords from 4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 39 authorization server database . . . . . . . . . . 38
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 39 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 39
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 39
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 39
4.5.1. Threat: Eavesdropping refresh tokens from 4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 40 authorization server . . . . . . . . . . . . . . . . . 39
4.5.2. Threat: Obtaining refresh token from authorization 4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 40 server database . . . . . . . . . . . . . . . . . . . 40
4.5.3. Threat: Obtain refresh token by online guessing . . . 41 4.5.3. Threat: Obtain refresh token by online guessing . . . 40
4.5.4. Threat: Obtain refresh token phishing by 4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 41 counterfeit authorization server . . . . . . . . . . . 40
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 41 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 41
4.6.1. Threat: Eavesdropping access tokens on transport . . . 41 4.6.1. Threat: Eavesdropping access tokens on transport . . . 41
4.6.2. Threat: Replay authorized resource server requests . . 42 4.6.2. Threat: Replay authorized resource server requests . . 41
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 . . . . . . . . . . . . . . . . . . . 43 resource server . . . . . . . . . . . . . . . . . . . 42
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 . . . . . . . . . . . . . . . . . . . 43
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 43
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 44 referrers . . . . . . . . . . . . . . . . . . . . . . 43
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . 44
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 44
5.1.2. Server authentication . . . . . . . . . . . . . . . . 45 5.1.2. Server authentication . . . . . . . . . . . . . . . . 45
5.1.3. Always keep the resource owner informed . . . . . . . 46 5.1.3. Always keep the resource owner informed . . . . . . . 45
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 . . . . . . . . . . 46
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 47 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 47
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 48 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 48
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 48 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 48
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 . . . . . . 50 5.1.5.4. Limit number of usages/ One time usage . . . . . . 49
5.1.5.5. Bind tokens to a particular resource server 5.1.5.5. Bind tokens to a particular resource server
(Audience) . . . . . . . . . . . . . . . . . . . . 50 (Audience) . . . . . . . . . . . . . . . . . . . . 49
5.1.5.6. Use endpoint address as token audience . . . . . . 50 5.1.5.6. Use endpoint address as token audience . . . . . . 50
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 50 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 50
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 50
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 . . . . . . . . . . . . . . . . 51
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 51 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 51
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 51
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 51
5.2.1.1. Automatic revocation of derived tokens if 5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 52 abuse is detected . . . . . . . . . . . . . . . . 51
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 . . . . . . 52
5.2.2.3. Refresh Token Replacement . . . . . . . . . . . . 52 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 52
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 52
5.2.2.5. Combine refresh token requests with 5.2.2.5. Device identification . . . . . . . . . . . . . . 53
user-provided secret . . . . . . . . . . . . . . . 53 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 53
5.2.2.6. Device identification . . . . . . . . . . . . . . 53 5.2.3. Public client authentication and authorization . . . . 53
5.2.2.7. X-FRAME-OPTION header . . . . . . . . . . . . . . 53 5.2.3.1. Don't issue secrets to public clients or
5.2.3. Client authentication and authorization . . . . . . . 54 clients with inappropriate security policy . . . . 54
5.2.3.1. Don't issue secrets to clients with 5.2.3.2. Public clients without secret require user
inappropriate security policy . . . . . . . . . . 54 consent . . . . . . . . . . . . . . . . . . . . . 54
5.2.3.2. Clients without secret require user 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 . . . . . . . . 55
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 . . . . . . . . . . . . . 57 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 56
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 . . . . . . . . . . . . . . . . 57
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 . . . . 57
5.2.4.2. Informed decisions based on transparency . . . . . 58 5.2.4.2. Informed decisions based on transparency . . . . . 57
5.2.4.3. Validation of client properties by end-user . . . 58 5.2.4.3. Validation of client properties by end-user . . . 57
5.2.4.4. Binding of authorization code to client_id . . . . 58 5.2.4.4. Binding of authorization code to client_id . . . . 58
5.2.4.5. Binding of authorization code to redirect_uri . . 58 5.2.4.5. Binding of authorization code to redirect_uri . . 58
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 58
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 . . . . . . . . . . . . 59 bundled with software packages . . . . . . . . . . . . 58
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) . . . . . . . . . . . . . 59
5.3.3. Store secrets in a secure storage . . . . . . . . . . 59 5.3.3. Store secrets in a secure storage . . . . . . . . . . 59
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 59 access . . . . . . . . . . . . . . . . . . . . . . . . 59
5.3.5. Platform security measures . . . . . . . . . . . . . . 59 5.3.5. Platform security measures . . . . . . . . . . . . . . 59
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 59 5.3.6. Link state parameter to user agent session . . . . . . 59
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 59 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 60
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 60
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 60 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 60
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 60 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 61
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61
8.1. Normative References . . . . . . . . . . . . . . . . . . . 61 8.1. Normative References . . . . . . . . . . . . . . . . . . . 61
8.2. Informative References . . . . . . . . . . . . . . . . . . 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 62
Appendix A. Document History . . . . . . . . . . . . . . . . . . 61 Appendix A. Document History . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
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 7, line 20 skipping to change at page 7, line 20
[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 are not bound to a specific deployment: An example could
by a mail client with support for contact list access via the by a mail client with support for contact list access via the
portable contacts API (see [portable-contacts]). Such clients portable contacts API (see [portable-contacts]). Such clients
cannot be registered upfront with a particular deployment and must cannot be registered upfront with a particular deployment and must
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 eaves drop on any
communications between those parties. He is not assumed to have communications between those parties. He is not assumed to have
skipping to change at page 8, line 48 skipping to change at page 8, line 48
o authz server shared secret/public key (assertion-based design) o authz 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
[I-D.ietf-oauth-v2], Section 2.1.
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 certs (HTTPS) o trusted CA certificates (HTTPS)
o per authorization process: redirect_uri, authorization code o per authorization process: redirect_uri, authorization code
2.3.3.1. Web Application
A web application is a client running on a web server, typically with
its own user management. End-users access the client via an HTML
user interface rendered in a user- agent on the end-user's device.
The client credentials as well as any token issued to the client are
stored on the web server and are not exposed to or accessible by the
end-user. Tokens are bound to a single user identity at the site.
The potential number of tokens affected by a security breach depends
on number of site users.
Such clients are implemented using the authorization code grant type
(see Section 4.4.1).
2.3.3.2. Native Applications
A native application is a client which is installed and executes on
the end-user's device, such as a notebook, PC, Tablet, Smartphone, or
Gaming Console. The OAuth protocol data and credentials are
accessible to the end-user. It is assumed that such an application
can protect dynamically issued credentials, such as refresh tokens,
from eavesdropping by other applications residing on the same device.
Massively distributed applications such as these cannot reliably keep
secrets confidential, which are issued per software package. This is
because such secrets would need to be transferred to the user device
as part of the installation process. An attacker could reverse
engineer any secret from the binary or accompanying resources.
Native Applications are able to protect per installation/instance
secrets (e.g. refresh tokens) to some extent.
Device platforms typically allow users to lock the device with a PIN
code and to segregate different apps or users (multi-user operation
systems).
Some devices can be identified/authenticated (to varying degrees of
assurance):
o Handsets and smart phones by its International Mobile Equipment
Identity (IMEI)
o Set top boxes, gaming consoles, others by using certificates and
TPM module - Note: This does not help to identify client apps but
may be used to bound tokens to devices and to detect token theft
Mobile devices, such as handsets or smart phones have the following
special characteristics:
o Limited input capabilities, therefore such clients typically
obtain a refresh token in order to provide automatic login for
sub-sequent application sessions
o As mobile and small devices, they can get cloned, stolen or lost
easier than other devices.
o Security breach will affect single user (or a few users) only.
For the purposes of this document, the scenario of attackers who
control a smartphone device entirely is out of scope.
There are several implementation options for native applications:
o The authorization code grant type in combination with an embedded
or external browser (Section 4.4.1)
o The implict grant type in combination with an embedded or external
browser (Section 4.4.2)
o The resource owner password credentials grant type can be used as
well (Section 4.4.3)
Different threats exists for those implementation options, which are
discussed in the respective sections of the threat model.
2.3.3.3. User-agent-based Applications
A user-agent-based application is a client in which the client code
is downloaded from a web server and executes within a user-agent on
the end-user's device. The OAuth protocol data and credentials are
accessible to the end-user. Since such applications directly reside
within the user-agent, they can make seamless use of the user-agent
capabilities in the end-user authorization process.
Such client are implemented using the implicit grant grant type
(Section 4.4.2).
2.3.3.4. Autonomous
Autonomous clients access resource services using rights grants by
client credentials only. Thus the autonomous client becomes the
"user". Authenticating autonomous clients is conceptually similar to
end-user authentication since the issued tokens refer to the client's
identity. Autonomous clients shall always be required to use a
secret or some other form of authentication (e.g. client assertion in
the form of a SAML assertion or STS token) acceptable to the
authorization/token services. The client must ensure the
confidentiality of client_secret or other credential.
Such client are implemented using the client credentials grant type.
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 of all 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:
skipping to change at page 12, line 19 skipping to change at page 10, line 16
as follows: as follows:
bearer token A 'bearer token' is a token that can be used by any bearer token A 'bearer token' is a token that can be used by any
client who has received the token (e.g. client who has received the token (e.g.
[I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to
use the token it is important that communication between end- use the token it is important that communication between end-
points be secured to ensure that only authorized end-points may points be secured to ensure that only authorized end-points may
capture the token. The bearer token is convenient to client capture the token. The bearer token is convenient to client
applications as it does not require them to do anything to use applications as it does not require them to do anything to use
them (such as a proof of identity). Bearer tokens have similar them (such as a proof of identity). Bearer tokens have similar
characteristics to web SSO cookies used in browsers. characteristics to web single-sign-on (SSO) cookies used in
browsers.
proof token A 'proof token' is a token that can only be used by a proof token A 'proof token' is a token that can only be used by a
specific client. Each use of the token, requires the client to specific client. Each use of the token, requires the client to
perform some action that proves that it is the authorized user of perform some action that proves that it is the authorized user of
the token. Examples of this are MAC tokens, which require the the token. Examples of this are MAC tokens, which require the
client to digitally sign the resource request with a secret client to digitally sign the resource request with a secret
corresponding to the particular token send with the request corresponding to the particular token send with the request
(e.g.[I-D.ietf-oauth-v2-http-mac]). (e.g.[I-D.ietf-oauth-v2-http-mac]).
3.1.1. Scope 3.1.1. Scope
skipping to change at page 14, line 10 skipping to change at page 12, line 10
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 intermediary 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 redirect_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-living
authorization code is exposed to potential attackers via URI authorization code is exposed to potential attackers via URI
query parameters (HTTP referrer), browser cacher or log file query parameters (HTTP referrer), browser cacher 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. Redirect-URI 3.5. Redirection URI
A Redirect-uri helps to identify clients and prevents phishing A redirection URI helps to detect malicious client and prevents
attacks from other 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
redirect_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 app clients. revealed through redirectors and counterfeit web application clients.
Moreover, the authorization server may require clients to pre- The authorization server requires public clients and confidential
register their redirect URIs and validate the redirect_uri in the clients using implicit grant type to pre-register their redirect URIs
authorization request in order to detect malicious clients. and validate agains the registered redirection URI in 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. token. It should bind to the authenticated state in a user agent and
the user agent must be capable of keeping it in a location accessible
only by the client and 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's presence. Depending on the client type, the without the user being present.
client identity can and should be authenticated (see below).
OAuth uses the _client_id_ (client identity) to collate associated OAuth uses the _client_id_ (client identity) to collate associated
request to the same originator, such as request to the 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 tokens 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 tokens by an end-user
to a particular client and sub-sequent requests by this client to to a particular client and sub-sequent requests by this client to
obtain tokens w/o user consent (automatic processing of repeated obtain tokens w/o user consent (automatic processing of repeated
authorization) 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
skipping to change at page 15, line 21 skipping to change at page 13, line 25
authorization) 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.
The _client_secret_ is used to verify the client identifier. The OAuth defines two client types, confidential and public, based on
authorization server should only rely on this form of client their ability to authenticate securely with the authorization server
authentication where these secrets can be deployed to the clients in (i.e. ability to maintain the confidentiality of their client
a secure manner and the client is capable of keeping its secret credentials). Confidential clients are capable of maintaining the
confidential. Alternatively, the client identity can also be confidentiality of client credentials (i.e. a client secret
verified using the _redirect_uri_ or by the _end-user_. associated with the client identifier) or capable of secure client
authentication using other means, such as a client assertion (e.g.
Clients (and the trustworthiness of its identity) can be classifed by SAML) or key cryptography. The latter is considered more secure.
using the following parameters:
o Deployment-specific or -independent client_id (Note: for native
apps, every installation of a particular app on a certain device
is considered a deployment.)
o Validated properties, such as app name or redirect_uri
o Client_secret available The authorization server should determine whether the client is
capable of keeping its secret confidential or using secure
authentication. Alternatively, the _end-user_ can verify the
identity of the client, e.g. by only installing trusted
applications.The _redirection URI_ can be used to prevent delivering
credentials to a counterfeit client after obtaining end-user
authorization, but can't be used to verify the client identity.
Typical client categories are: Clients can be categorized as follows based on the client type,
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 apps in order to identify the This is a viable option for native applications in order to
client for the purpose of displaying meta information about the identify the client for the purpose of displaying meta information
client to the user and to differentiate clients in log files. about the client to the user and to differentiate clients in log
Revocation of such an identity will affect ALL deployments of the files. Revocation of such an identity will affect ALL deployments
respective software. of the respective software.
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 trustlevel 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 insures the
validation of the client's properties, such as redirect_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 app is conducted by an administrator, who installation of the application is conducted by an administrator,
validates the clients authenticity, or the process from validating who validates the clients authenticity, or the process from
the app to the installation of the app on the device and the validating the application to the installation of the application
creation of the client credentials is controlled end-to-end by a on the device and the creation of the client credentials is
single entity (e.g. app market provider). Revocation will affect controlled end-to-end by a single entity (e.g. application market
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 apps. Revocation will affect a single deployment only. native applications. Revocation will affect a single deployment
only.
Use of the client secret is considered a relatively weak form of
credential for the client. Use of stronger mechanisms such as a
client assertion (e.g. SAML), key cryptography, are preferred.
4. Security Threat Model 4. Security Threat Model
This sections gives a comprehensive threat model of OAuth 2.0. This sections gives a comprehensive threat model of OAuth 2.0.
Threats are grouped first by attackes 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.
4.1.1. Threat: Obtain Client Secrets 4.1.1. Threat: Obtain Client Secrets
skipping to change at page 17, line 26 skipping to change at page 15, line 26
o obtain tokens on behalf of the attacked client with the privileges o obtain tokens on behalf of the attacked client with the privileges
of that client. of that client.
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, there are the following approaches Depending on the client category, the following attacks could be
an attacker could utilize 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.* This applies for
all client profiles. For open source projects, secrets can be all client profiles. For open source projects, secrets can be
extracted directly from source code in their public repositories. extracted directly from source code in their public repositories.
Secrets can be extracted from application binaries just as easily Secrets can be extracted from application binaries just as easily
when published source is not available to the attacker. Even if an when published source is not available to the attacker. Even if an
application takes significant measures to obfuscate secrets in their application takes significant measures to obfuscate secrets in their
application distribution one should consider that the secret can application distribution one should consider that the secret can
still be reverse-engineered by anyone with access to a complete still be reverse-engineered by anyone with access to a complete
functioning application bundle or binary. functioning application bundle or binary.
_Countermeasures:_ _Countermeasures:_
o Don't issue secrets to clients with inappropriate security policy o Don't issue secrets to public clients or clients with
- Section 5.2.3.1 inappropriate security policy - Section 5.2.3.1
o Clients without secrect 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 *Attack: Obtain a Deployment-Specific Secret.* An attacker may try to
obtain the secret from a client installation, either from a web site obtain the secret from a client installation, either from a web site
(web server) or a particular devices (native app). (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 apps: 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. Some
skipping to change at page 18, line 37 skipping to change at page 16, line 37
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 unauthorized token usage by another party (Refresh Token Rotation)
Replacement) - Section 5.2.2.3 - Section 5.2.2.3
** **
*Attack: Obtain Refresh Token from Web application.* An attack may *Attack: Obtain Refresh Token from Web application.* An attack may
obtain the refresh tokens issued to a web server client. Impact: obtain the refresh tokens issued to a web server client. Impact:
Exposure of all refresh tokens on that side. Exposure of all refresh tokens on that side.
_Countermeasures:_ _Countermeasures:_
o Standard web server protection measures - Section 5.3.2 o Standard web server protection measures - Section 5.3.2
skipping to change at page 19, line 14 skipping to change at page 17, line 14
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.* On native *Attack: Obtain Refresh Token from Native clients.* On native
clients, leakage of a refresh token typically affects a single user, clients, leakage of a refresh token typically affects a single user,
only. only.
_Read from local filesystem:_ The attacker could try get file system _Read from local filesystem:_ 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 app 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
__ __
_Steal device_: The host device (e.g. mobile phone) may be stolen. _Steal device_: The host device (e.g. mobile phone) may be stolen.
In that case, the attacker gets access to all apps under the identity In that case, the attacker gets access to all applications under the
of the legitimate user. identity of the 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 Combine refresh token requests with user-provided secret -
Section 5.2.2.5
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
__ __
_Clone device: _All device data and applications are copied to _Clone device: _All device data and applications are copied to
another device. Applications are used as-is on the target device. another device. Applications are used as-is on the target device.
_Countermeasures:_ _Countermeasures:_
o Combine refresh token request with device identification - o Combine refresh token request with device identification -
Section 5.2.2.6
o Combine refresh token requests with user-provided secret -
Section 5.2.2.5 Section 5.2.2.5
o Refresh Token Replacement - 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
__ __
_Obtain refresh tokens from backup:_ A refresh token could be
obtained from the backup of a client application, or device.
_Countermeasures:_
o tbd
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 app stores them in a storage, which is accessible the device if the application stores them in a storage, which is
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.
Countermeasures: Countermeasures:
o Keep access tokens in transient memory and limit grants: o Keep access tokens in transient memory and limit grants:
Section 5.1.6 Section 5.1.6
o Limited scope tokens - Section 5.1.5.1 o Limited scope tokens - Section 5.1.5.1
o Keep access tokens in private memory or apply same protection o Keep access tokens in private memory or apply same protection
means as for refresh tokens - Section 5.2.2 means as for refresh tokens - Section 5.2.2
o Keep access token lifetime short - Section 5.1.5.3 o Keep access token lifetime short - Section 5.1.5.3
4.1.4. Threat: End-user credentials phished using compromised or 4.1.4. Threat: End-user credentials phished using compromised or
embedded browser embedded browser
A malicious app could attempt to phish end-user passwords by misusing A malicious application could attempt to phish end-user passwords by
an embedded browser in the end-user authorization process, or by misusing an embedded browser in the end-user authorization process,
presenting its own user-interface instead of allowing trusted system or by presenting its own user-interface instead of allowing trusted
browser to render the authorization UI. By doing so, the usual system browser to render the authorization user interface. By doing
visual trust mechanisms may be bypassed (e.g. TLS confirmation, web so, the usual visual trust mechanisms may be bypassed (e.g. TLS
site mechanisms). By using an embedded or internal client app UI, confirmation, web site mechanisms). By using an embedded or internal
the client app has access to additional information it should not client application user interface, the client application has access
have access to (e.g. uid/password). to additional information it should not have access to (e.g. uid/
password).
Impact: If the client app or the communication is compromised, the Impact: If the client application or the communication is
user would not be aware and all information in the authorization compromised, the user would not be aware and all information in the
exchange could be captured such as username and password. authorization exchange could be captured such as username and
password.
Countermeasures: Countermeasures:
o Client developers and end-user can be educated to trust an o Client developers and end-user can be educated to trust an
external System-Browser only. external System-Browser only.
o Client apps could be validated prior publication in a app market. o Client applications could be validated prior publication in a
application market.
o Client developers should not collect authentication information o Client developers should not collect authentication information
directly from users and should instead use redirects to and back directly from users and should instead use redirects to and back
from a trusted external system-browser. from a trusted external system-browser.
4.1.5. Threat: Open Redirectors on client
An open redirector is an endpoint using a parameter to automatically
redirect a user-agent to the location specified by the parameter
value without any validation. If the authorization server allows the
client to register only part of the redirection URI, an attacker can
use an open redirector operated by the client to construct a
redirection URI that will pass the authorization server validation
but will send the authorization code or access token to an endpoint
under the control of the attacker.
Impact: An attacker could gain access to authorization codes or
access tokens
Countermeasure
o require clients to register full redirection URI Section 5.2.3.5
4.2. Authorization Endpoint 4.2. Authorization Endpoint
4.2.1. Threat: Password phishing by counterfeit authorization server 4.2.1. Threat: Password phishing by counterfeit authorization server
OAuth makes no attempt to verify the authenticity of the OAuth makes no attempt to verify the authenticity of the
Authorization Server. A hostile party could take advantage of this Authorization Server. A hostile party could take advantage of this
by intercepting the Client's requests and returning misleading or by intercepting the Client's requests and returning misleading or
otherwise incorrect responses. This could be achieved using DNS or otherwise incorrect responses. This could be achieved using DNS or
ARP spoofing. Wide deployment of OAuth and similar protocols may ARP spoofing. Wide deployment of OAuth and similar protocols may
cause Users to become inured to the practice of being redirected to cause Users to become inured to the practice of being redirected to
skipping to change at page 22, line 10 skipping to change at page 20, line 21
When obtaining end user authorization, the end-user may not When obtaining end user authorization, the end-user may not
understand the scope of the access being granted and to whom or they understand the scope of the access being granted and to whom or they
may end up providing a client with access to resources which should may end up providing a client with access to resources which should
not be permitted. not be permitted.
Countermeasures: Countermeasures:
o Explain the scope (resources and the permissions) the user is o Explain the scope (resources and the permissions) the user is
about to grant in a understandable way - Section 5.2.4.2 about to grant in a understandable way - Section 5.2.4.2
o Narrow scope based on client-specific policy - When obtaining end o Narrow scope based on client - When obtaining end user
user authorization and where the client requests scope, the authorization and where the client requests scope, the
authorization server may want to consider whether to honour that authorization server may want to consider whether to honour that
scope based on who the client is. That decision is between the scope based on who the client is. That decision is between the
client and authorization server and is outside the scope of this client and authorization server and is outside the scope of this
spec. The authorization server may also want to consider what spec. The authorization server may also want to consider what
scope to grant based on the profile used, e.g. providing lower scope to grant based on the client type, e.g. providing lower
scope where no client secret is provided from a native scope to public clients. - Section 5.1.5.1
application. - Section 5.1.5.1
4.2.3. Threat: Malicious client obtains existing authorization by fraud 4.2.3. Threat: Malicious client obtains existing authorization by fraud
Authorization servers may wish to automatically process authorization Authorization servers may wish to automatically process authorization
requests from clients which have been previously authorized by the requests from clients which have been previously authorized by the
user. When the user is redirected to the authorization server's end- user. When the user is redirected to the authorization server's end-
user authorization endpoint to grant access, the authorization server user authorization endpoint to grant access, the authorization server
detects that the user has already granted access to that particular detects that the user has already granted access to that particular
client. Instead of prompting the user for approval, the client. Instead of prompting the user for approval, the
authorization server automatically redirects the user back to the authorization server automatically redirects the user back to the
client. client.
A malicious client may exploit that feature and try to obtain such an A malicious client may exploit that feature and try to obtain such an
authorization code instead of the legimate client. authorization code instead of the legitimate client.
Countermeasures: Countermeasures:
o Authorization servers should not automatically process repeat o Authorization servers should not automatically process repeat
authorizations where the client is not authenticated through a authorizations to public clients or unless the client is validated
client secret or some other authentication mechanism such as using a pre-registered redirect URI (Section 5.2.3.5 )
signing with security certs (see Section 5.2.3.7) or validation of
a pre-registered redirect uri (Section 5.2.3.5 )
o Authorization servers can mitigate the risks associated with o Authorization servers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens automatic processing by limiting the scope of Access Tokens
obtained through automated approvals - Section 5.1.5.1 obtained through automated approvals - Section 5.1.5.1
4.2.4. Threat: Open redirector 4.2.4. Threat: Open redirector
An attacker could use the end-user authorization endpoint and the An attacker could use the end-user authorization endpoint and the
redirect_uri parameter to abuse the authorization server as redirection URI parameter to abuse the authorization server as an
redirector. open redirector. An open redirector is an endpoint using a parameter
to automatically redirect a user-agent to the location specified by
the parameter value without any validation.
Impact: An attacker could utilize a user's trust in your
authorization server to launch a phishing attack.
Impact?
Countermeasure Countermeasure
o don't redirect to redirect_uri, if client identity or redirect_uri o require clients to register full redirection URI Section 5.2.3.5
could not be verified
o don't redirect to redirection URI, if client identity or
redirection URI could not 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 eaversdrop 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 Authorization servers MUST ensure that these transmissions are
protected using transport-layer mechanisms such as TLS or SSL (see protected using transport-layer mechanisms such as TLS or SSL (see
Section 5.1.1). Section 5.1.1).
skipping to change at page 23, line 43 skipping to change at page 22, line 9
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. Impact: disclosure the database or launching a SQL injection attack. Impact: disclosure
of all access tokens of all access tokens
Countermeasures: Countermeasures:
o System security measures - Section 5.1.4.1.1 o 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 inj. Countermeasures - Section 5.1.4.1.2 o Standard SQL injection Countermeasures - Section 5.1.4.1.2
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 immitation 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 Confidentiality of Requests
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
client_id/secret combinations. This allows the attacker to act on client_id/secret combinations. This allows the attacker to act on
behalf of legitimate clients. behalf of legitimate clients.
Countermeasures: Countermeasures:
o Ensure proper handling of credentials as per Credential storage o Ensure proper handling of credentials as per Credential Storage
protection. Protection.
4.3.5. Threat: Obtain client secret by online guessing 4.3.5. Threat: Obtain client secret by online guessing
An attacker may try to guess valid client_id/secret pairs. Impact: An attacker may try to guess valid client_id/secret pairs. Impact:
disclosure of single client_id/secret pair. disclosure of single client_id/secret pair.
Countermeasures: Countermeasures:
o High entropy of secrets - Section 5.1.4.2.2 o High entropy of secrets - Section 5.1.4.2.2
o Lock accounts - Section 5.1.4.2.3 o Lock accounts - Section 5.1.4.2.3
o Use Strong Client Authentication - Section 5.2.3.7
4.3.6. Threat: DoS on dynamic client secret creation 4.3.6. Threat: DoS on dynamic client secret creation
If an authorization servers includes a nontrivial amount of entropy If an authorization servers includes a nontrivial amount of entropy
in client secrets and if the authorization server automatically in client secrets and if the authorization server automatically
grants them, an attacker could exhaust the pool by repeatedly grants them, an attacker could exhaust the pool by repeatedly
applying for them. applying for them.
Countermeasures: Countermeasures:
o The authorization server should consider some verification step o The authorization server should consider some verification step
skipping to change at page 25, line 22 skipping to change at page 23, line 35
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 Referer headers: browsers frequently pass a "referer" header when o Referrer headers: browsers frequently pass a "referer" header when
a web page embeds content, or when a user travels from one web a web page embeds content, or when a user travels from one web
page to another web page. These referer headers may be sent even page to another web page. These referrer headers may be sent even
when the origin site does not trust the destination site. The when the origin site does not trust the destination site. The
referer header is commonly logged for traffic analysis purposes. referee 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 26, line 28 skipping to change at page 24, line 38
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.
o The client server may reload the target page of the redirect_uri o The client server may reload the target page of the redirection
in order to automatically cleanup the browser cache. URI in order to automatically cleanup the browser cache.
4.4.1.2. Threat: Obtain authorization codes from authorization server 4.4.1.2. Threat: Obtain authorization codes from authorization server
database database
This threat is applicable if the authorization server stores This threat is applicable if the authorization server stores
authorization codes as handles in a database. An attacker may obtain authorization codes as handles in a database. An attacker may obtain
authorization codes from the authorization server's database by authorization codes from the authorization server's database by
gaining access to the database or launching a SQL injection attack. gaining access to the database or launching a SQL injection attack.
Impact: disclosure of all authorization codes, most likely along with Impact: disclosure of all authorization codes, most likely along with
the respective redirect_uri and client_id values. the respective redirect_uri and client_id values.
Countermeasures: Countermeasures:
o Credential storage protection can be employed - Section 5.1.4.1 o Credential storage protection can 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 inj. 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. Impact: disclosure of single access token (+probably refresh token.
token)
Impact: disclosure of single access token, probably also associated
refresh token.
Countermeasures: Countermeasures:
o For handle-based designs: Section 5.1.5.11 o For handle-based designs: Section 5.1.5.11
o For assertion-based designs: Section 5.1.5.9 o For assertion-based designs: 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 redirect_uri, adds another value o Binding of authorization code to redirection URI, adds another
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
A malicious client could counterfeit a valid client and obtain an A malicious client could counterfeit a valid client and obtain an
access authorization that way. The malicious client could even access authorization that way. The malicious client could even
utilize screen scraping techniques in order to simulate the user utilize screen scraping techniques in order to simulate the user
consent in the authorization flow. consent in the authorization flow.
skipping to change at page 27, line 49 skipping to change at page 26, line 11
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 authentication 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 redirect_uri o The authorization server should validate the client's redirection
against the pre-registered redirect_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 redirect_uri is the Section 5.2.3.5). Note: The validation of the redirection URI is
only technical mean to recognize a malicious client id in advance the only technical mean to recognize a malicious client id in
of the authorization process. Further note this does not work for advance of the authorization process. Further note this does not
native applications because in contrast to web applications this work for native applications because in contrast to web
URI is not bound to a single communication endpoint. The valid applications this URI is not bound to a single communication
client's redirect_uri (typically with custom scheme) can be used endpoint. The valid client's redirection URI (typically with
by a malicious on any device. custom scheme) can be used by a malicious client on any device.
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 shall 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 must view to the end-user the
meta data it associates with the particular client. It is up to meta data it associates with the particular client. It is up to
the user to validate the binding of this data to the particular the user to validate the binding of this data to the particular
application (e.g. Name) and to approve the authorization request. application (e.g. Name) and to approve the authorization request.
(see Section 5.2.4.3). (see Section 5.2.4.3).
skipping to change at page 28, line 46 skipping to change at page 27, line 8
spoofing. This applies to clients, which are web applications, thus spoofing. This applies to clients, which are web applications, thus
the redirect URI is not local to the host where the user's browser is the redirect URI is not local to the host where the user's browser is
running. running.
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:
o The authorization server MUST require the client to authenticate It is strongly recommended that one of the following countermeasures
with a secret, so the binding of the authorization code to a is utilized in order to prevent this attack:
certain client can be validated in a reliable way (see
Section 5.2.4.4).
o The redirect_uri of the client SHOULD point to a HTTPS protected o The redirection URI of the client SHOULD point to a HTTPS
endpoint and the browser shall be utilized to authenticate this protected endpoint and the browser shall be utilized to
redirect_uri using server authentication (see Section 5.1.2). authenticate this redirection URI using server authentication (see
Section 5.1.2).
o The authorization server SHOULD require the client to be
authenticated, i.e. confidential client, so the binding of the
authorization code to a certain client can be validated in a
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
browser is running. browser is running.
Impact: An attacker who intercepts the authorization code as it is Impact: An attacker who intercepts the authorization code as it is
skipping to change at page 29, line 36 skipping to change at page 27, line 48
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 redirect_uri of the client MUST point to a HTTPS session, the redirection URI of the client MUST point to a HTTPS
protected endpoint and the browser shall be utilized to protected endpoint and the browser shall be utilized to
authenticate this redirect_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 sub-sequently 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
with the user account of the attacker on a client site. with the user account of the attacker on a client site.
The attacker abuses an existing client application and combines it The attacker abuses an existing client application and combines it
with his own counterfeit client web site. The attack depends on the with his own counterfeit client web site. The attack depends on the
victim expecting the client application to request access to a victim expecting the client application to request access to a
certain resource server. The victim, seeing only a normal request certain resource server. The victim, seeing only a normal request
from an expected application, approves the request. The attacker from an expected application, approves the request. The attacker
then uses the victim's authorization to gain access to the then uses the victim's authorization to gain access to the
information unknowingly authorized by the victim. information unknowingly authorized by the victim.
The attacker conducts the following flow: The attacker conducts the following flow:
1. The attacker accesses the client web site (or application) and 1. The attacker accesses the client web site (or application) and
initates data access to a particular resource server. The client initiates data access to a particular resource server. The
web site in turn initiates an authorization request to the client web site in turn initiates an authorization request to the
resource server's authorization server. Instead of proceeding resource server's authorization server. Instead of proceeding
with the authorization process, the attacker modifies the with the authorization process, the attacker modifies the
authorization server end-user authorization URL as constructed by authorization server end-user authorization URL as constructed by
the client to include a redirect_uri parameter refering to a web the client to include a redirection URI parameter referring to a
site under his control (attacker's web site). web site under his control (attacker's web site).
2. The attacker tricks another user (the victim) to open that 2. The attacker tricks another user (the victim) to open that
modified end-user authorization URI and to authorize access (e.g. modified end-user authorization URI and to authorize access (e.g.
an email link, or blog link). The way the attacker achieve that an email link, or blog link). The way the attacker achieve that
goal is out of scope. goal is out of scope.
3. Having clicked the link, the victim is requested to authenticate 3. Having clicked the link, the victim is requested to authenticate
and authorize the client site to have access. and authorize the client site to have access.
4. After completion of the authorization process, the authorization 4. After completion of the authorization process, the authorization
server redirects the user agent to the attacker's web site server redirects the user agent to the attacker's web site
instead of the original client web site. instead of the original client web site.
5. The attacker obtains the authorization code from his web site by 5. The attacker obtains the authorization code from his web site by
means out of scope of this document. means out of scope of this document.
6. He then constructs a redirect_uri to the target web site (or app) 6. He then constructs a redirection URI to the target web site (or
based on the original authorization request's redirect_uri and application) based on the original authorization request's
the newly obtained authorization code and directs his user agent redirection URI and the newly obtained authorization code and
to this URL. The authorization code is injected into the directs his user agent to this URL. The authorization code is
original client site (or application). injected into the original client site (or application).
7. The client site uses the authorization code to fetch a token from 7. The client site uses the authorization code to fetch a token from
the authorization server and associates this token with the the authorization server and associates this token with the
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 attackes 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 redirect_uri for its authorization o The attacker must use another redirection URI for its
process than the target web site because it needs to intercept the authorization process than the target web site because it needs to
flow. So if the authorization server associates the authorization intercept the flow. So if the authorization server associates the
code with the redirect_uri of a particular end-user authorization authorization code with the redirection URI of a particular end-
and validates this redirect_uri with the redirect_uri passed to user authorization and validates this redirection URI with the
the tokens endpount, such an attack is detected (see redirection URI passed to the tokens endpoint, such an attack is
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 sesssion fixation attempts. allow for an early recognition of session fixation attempts.
o For native apps, one could also consider to use deployment- o For native applications, one could also consider to use
specific client ids and secrets (see Section 5.2.3.4, along with deployment-specific client ids and secrets (see Section 5.2.3.4,
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 to use 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
OAuth protected resources without the consent of the User. OAuth protected resources without the consent of the User.
This attack works against the redirect-uri used in the authorization This attack works against the redirection URI used in the
code flow. An attacker could authorize an authorization code to authorization code flow. An attacker could authorize an
their own protected resources on an authorization server. He then authorization code to their own protected resources on an
aborts the redirect flow back to the client on his device and tricks authorization server. He then aborts the redirect flow back to the
the victim into executing the redirect back to the client. The client on his device and tricks the victim into executing the
client receives the redirect, fetches the token(s) from the redirect back to the client. The client receives the redirect,
authorization server and asscociates the victim's client session with fetches the token(s) from the authorization server and associates the
the resources accessible using the token. victim's client session with the resources accessible using the
token.
Impact: The user accesses resources on behalf of the attacker. The Impact: The user accesses resources on behalf of the attacker. The
effective impact depends on the type of resource accessed. For effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's example, the user may upload private items to an attacker's
resources. Or when using OAuth in 3rd party login scenarios, the resources. Or when using OAuth in 3rd party login scenarios, the
user may associate his client account with the attacker's idenity at user may associate his client account with the attacker's identity at
the external identity provider. This way the attacker could easily the external identity provider. This way the attacker could easily
accces the victim's data at the client by logging in from another access the victim's data at the client by logging in from another
device with his credentials at the external identity provider. device with his credentials at the external identity provider.
Countermeasures: Countermeasures:
o The state parameter should be used to link the authorization o The state parameter should be used to link the authorization
request with the redirect-uri used deliver the access token. This request with the redirection URI used to deliver the access token.
will ensure the client is not tricked into completing any redirect Section 5.3.6
callback unless it is linked to an authorization request the
client initiated. The state parameter should be unguessable and
the client should be capable of keeping the state parameter
secret.
o Client developers and end-user can be educated not follow o Client developers and end-user can be educated not follow
untrusted urls. untrusted URLs.
4.4.1.9. Threat: Clickjacking attack against authorization 4.4.1.9. Threat: Clickjacking attack against authorization
With Clickjacking, a malicious site loads the target site in a With Clickjacking, a malicious site loads the target site in a
transparent iframe overlaid on top of a set of dummy buttons which transparent iframe overlaid on top of a set of dummy buttons which
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 an iFrame 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.7 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: DoS, Exhaustion of resources attacks 4.4.1.10. Threat: Resource Owner Impersonation
When a client requests access to protected resources, the
authorization flow normally involves the resource owner's explicit
response to the access request, either granting or denying access to
the protected resources. A malicious client can exploit knowledge of
the structure of this flow in order to gain authorization without the
resource owner's consent, by transmitting the necessary requests
programmatically, and simulating the flow against the authorization
server. That way, the client may gain access to the victims
resources without her approval. An authorization server will be
vulnerable to this threat, if it uses non-interactive authentication
mechanisms or split the authorization flow across multiple pages.
The malicious client might embbed a hidden HTML user agent, interpret
the HTML forms sent by the authorization server, and automatically
answer with the corresponding form post requests. As a pre-
requisiete, the attacker must be able to execute the authorization
process in the context of an already authenticated session of the
resource owner with the authorization server. There are different
ways to achieve this:
o The malicious client could abuse an existing session in an
external browser or cross-browser cookies on the particular
device.
o It could also request authorization for a particular scope and
silently abuse the resulting session in his browser instance to
"silently" request another scope.
o Alternatively, the attacker might exploit an authorization
server's aibility to authenticate the resource owner automatically
and without user interactions, e.g. based on certificates.
In all cases, such an attack is limited to clients running on the
victim's device, within the user agent or as native app.
Please note: Such attacks cannot be prevented using CSRF
countermeasures, since the attacker just "executes" the URLs as
prepared by the authorization server including any nonce e.t.c.
Countermeasures:
Authorization servers should decide, based on an analysis of the risk
associated with this threat, whether to assume, detect, or to prevent
this threat.
In order to prevent such an attack, the authorization server may
force an user interaction based on non-predictable input values as
part of the user consent approval. The authorization server could
o combine password authentication and user consent in a single form,
o make use of CAPTCHAs, or
o or use one-time secrets send out of bound to the resource owner
(e.g. via text or instance message).
Alternatively in order to allow the resource owner to detect abuse,
the authorization server could notify the resource owner of any
approval by appropriate means, e.g. text or instant message or
e-Mail.
4.4.1.11. Threat: DoS, Exhaustion of resources attacks
If an authorization server includes a nontrivial amount of entropy in If an authorization server includes a nontrivial amount of entropy in
authorization codes or access tokens (limiting the number of possible authorization codes or access tokens (limiting the number of possible
codes/tokens) and automatically grants either without user codes/tokens) and automatically grants either without user
intervention and has no limit on code or access tokens per user, an intervention and has no limit on code or access tokens per user, an
attacker could exhaust the pool by repeatedly directing user(s) attacker could exhaust the pool by repeatedly directing user(s)
browser to request code or access tokens. This is because more browser to request code or access tokens. This is because more
entropy means a larger number of tokens can be issued. entropy means a larger number of tokens can be issued.
Countermeasures: Countermeasures:
o The authorization server should consider limiting the number of o The authorization server should consider limiting the number of
access tokens granted per user. The authorization server should access tokens granted per user. The authorization server should
include a nontrivial amount of entropy in authorization codes. include a nontrivial amount of entropy in authorization codes.
4.4.1.11. Threat: DoS using manufactured authorization codes 4.4.1.12. Threat: DoS using manufactured authorization codes
An attacker who owns a botnet can locate the redirect URIs of clients An attacker who owns a botnet can locate the redirect URIs of clients
that listen on HTTP, access them with random authorization codes, and that listen on HTTP, access them with random authorization codes, and
cause a large number of HTTPS connections to be concentrated onto the cause a large number of HTTPS connections to be concentrated onto the
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
skipping to change at page 33, line 41 skipping to change at page 33, line 17
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
machines are less effective due to the difficulty to identify the machines are less effective due to the difficulty to identify the
attacking machines. Although an attacker could also launder its attacking machines. Although an attacker could also launder its
connections through an anonymizing systems such as Tor, the connections through an anonymizing systems such as Tor, the
effectiveness of that approach depends on the capacity of the effectiveness of that approach depends on the capacity of the
anonyming system. On the other hand, a potentially large number annoying system. On the other hand, a potentially large number
of OAuth clients could be utilized for this attack. of OAuth clients could be utilized for this attack.
2. Asymmetric resource utilization: The attacker incurs the cost of 2. Asymmetric resource utilization: The attacker incurs the cost of
an HTTP connection and causes an HTTPS connection to be made on an HTTP connection and causes an HTTPS connection to be made on
the authorization server; and the attacker can co-ordinate the the authorization server; and the attacker can co-ordinate the
timing of such HTTPS connections across multiple clients timing of such HTTPS connections across multiple clients
relatively easily. Although the attacker could achieve something relatively easily. Although the attacker could achieve something
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
skipping to change at page 34, line 36 skipping to change at page 34, line 15
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
he implict grant flow, the access token is directly returned to the In the implicit grant type flow, the access token is directly
client as fragment part of the redirect_uri. It is assumed that the returned to the client as a fragment part of the redirection URI. It
token is not send to the redirect_uri target since HTTP user agents is assumed that the token is not sent to the redirection URI target
do not send fragments server requests. Thus an attacker cannot since HTTP user agents do not send fragments server requests. Thus
eavesdrop the access token on this communication path and It cannot an attacker cannot eavesdrop the access token on this communication
leak through HTTP referer headers. 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 redirect_uri. If the from server to client via a URI fragment of the redirection URI. If
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 confidentialty of the o The authorization server must ensure confidentiality of the
response from the authorizaton 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 browsers 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
o Native apps can directly embedd a browser widget and therewith o Native applications can directly embed a browser widget and
gain full control of the cache. So the app can cleanup browser therewith gain full control of the cache. So the application can
history after authorization process. cleanup browser history after authorization process.
4.4.2.3. Threat: Malicious client obtains authorization 4.4.2.3. Threat: Malicious client obtains authorization
An malicious client could attempt to obtain a token by fraud. An malicious client could attempt to obtain a token by fraud.
The same countermeasures as for Section 4.4.1.4 are applicable, The same countermeasures as for Section 4.4.1.4 are applicable,
except client authentication. except client authentication.
4.4.2.4. Threat: Manipulation of scripts 4.4.2.4. Threat: Manipulation of scripts
skipping to change at page 36, line 19 skipping to change at page 35, line 45
attackers modified code. [[pending discussion]] attackers modified code. [[pending discussion]]
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 redirect-uri used in the implicit grant This attack works against the redirection URI used in the implicit
flow. An attacker could acquire an access token to their own grant flow. An attacker could acquire an access token to their own
protected resources. He could then construct a redirect-uri and protected resources. He could then construct a redirection URI and
embed their access token in that uri. If he can trick the user into embed their access token in that URI. If he can trick the user into
following the redirect-uri and the client does not have protection following the redirection URI and the client does not have protection
against this attack, the user may have the attacker's access token against this attack, the user may have the attacker's access token
authorized within their client. authorized within their client.
Impact: The user accesses resources on behalf of the attacker. The Impact: The user accesses resources on behalf of the attacker. The
effective impact depends on the type of resource accessed. For effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's example, the user may upload private items to an attacker's
resources. Or when using OAuth in 3rd party login scenarios, the resources. Or when using OAuth in 3rd party login scenarios, the
user may associate his client account with the attacker's idenity at user may associate his client account with the attacker's identity at
the external identity provider. This way the attacker could easily the external identity provider. This way the attacker could easily
accces the victim's data at the client by logging in from another access the victim's data at the client by logging in from another
device with his credentials at the external identity provider. device with his credentials at the external identity provider.
Countermeasures: Countermeasures:
o The state parameter should be used to link the authorization o The state parameter should be used to link the authorization
request with the redirect-uri used deliver the access token. This request with the redirection URI used deliver the access token.
will ensure the client is not tricked into completing any redirect This will ensure the client is not tricked into completing any
callback unless it is linked to an authorization request the redirect callback unless it is linked to an authorization request
client initiated. The state parameter should be unguessable and the client initiated. The state parameter should be unguessable
the client should be capable of keeping the state parameter and the client should be capable of keeping the state parameter
secret. secret.
o Client developers and end-user can be educated not follow o Client developers and end-user can be educated not follow
untrusted urls. untrusted URLs.
4.4.3. Resource Owner Password Credentials 4.4.3. Resource Owner Password Credentials
The "Resource Owner Password Credentials" grant type (see The "Resource Owner Password Credentials" grant type (see
[I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration
reasons, allows a client to request an access token using an end- reasons, allows a client to request an access token using an end-
users user-id and password along with its own credential. This grant users user-id and password along with its own credential. This grant
type has higher risk because it maintains the uid/password anti- type has higher risk because it maintains the uid/password anti-
pattern. Additionally, because the user does not have control over pattern. Additionally, because the user does not have control over
the authorization process, clients using this grant type are not the authorization process, clients using this grant type are not
skipping to change at page 40, line 17 skipping to change at page 39, line 37
o Abandon on grant type "password" o Abandon on grant type "password"
o Client authentication (see Section 5.2.3) will provide another o Client authentication (see Section 5.2.3) will provide another
authentication factor and thus hinder the attack. authentication factor and thus hinder the attack.
4.4.4. Client Credentials 4.4.4. Client Credentials
Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an
identifier (not secret) combined with an additional means (such as a identifier (not secret) combined with an additional means (such as a
matching client secret) of authenticating a client. matching client secret) of authenticating a client. The threats to
this grant type are similar to Section 4.4.3.
[[Threats seem to be covered elsewhere such as Section 4.4.1.1]]
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
dAn 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 Authorization servers MUST ensure that these transmissions are
protected using transport-layer mechanisms such as TLS or SSL (see protected using transport-layer mechanisms such as TLS or SSL (see
Section 5.1.1). 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
skipping to change at page 41, line 37 skipping to change at page 41, line 5
o Authenticate the client, adds another element the attacker has to o Authenticate the client, adds another element the attacker has to
guess (see Section 5.2.3.4) guess (see Section 5.2.3.4)
4.5.4. Threat: Obtain refresh token phishing by counterfeit 4.5.4. Threat: Obtain refresh token phishing by counterfeit
authorization server authorization server
An attacker could try to obtain valid refresh tokens by proxying An attacker could try to obtain valid refresh tokens by proxying
requests to the authorization server. Given the assumption that the requests to the authorization server. Given the assumption that the
authorization server URL is well-known at development time or can at authorization server URL is well-known at development time or can at
least be obtained from a well-known resource server, the attacker least be obtained from a well-known resource server, the attacker
must utilize some kind of spoofing in order to suceed. must utilize some kind of spoofing in order to succeed.
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
skipping to change at page 43, line 45 skipping to change at page 43, line 13
prevents the attack because the counterfeit server is assumed to prevents the attack because the counterfeit server is assumed to
miss the capabilities to correctly authenticate on behalf of the miss the capabilities to correctly authenticate on behalf of the
legitimate client to the resource server (Section 5.4.2). legitimate client to the resource server (Section 5.4.2).
o Restrict the token scope (see Section 5.1.5.1) and or limit the o Restrict the token scope (see Section 5.1.5.1) and or limit the
token to a certain resource server (Section 5.1.5.5). token to a certain resource server (Section 5.1.5.5).
4.6.5. Threat: Abuse of token by legitimate resource server or client 4.6.5. Threat: Abuse of token by legitimate resource server or client
A legitimate resource server could attempt to use an access token to A legitimate resource server could attempt to use an access token to
access another resource servers. Similarily, a client could try to access another resource servers. Similarly, a client could try to
use a token obtained for one server on another resource server. use a token obtained for one server on another resource server.
Countermeasures: Countermeasures:
o Tokens should be restricted to particular resource servers (see o Tokens should be restricted to particular resource servers (see
Section 5.1.5.5). Section 5.1.5.5).
4.6.6. Threat: Leak of confidential data in HTTP-Proxies 4.6.6. Threat: Leak of confidential data in HTTP-Proxies
The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is
optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J., optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J.,
Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and
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 ensure
that authenticated content is protected. that authenticated content is 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.
skipping to change at page 45, line 12 skipping to change at page 44, line 30
Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing
one time token usage (see Section 5.1.5.4). one time token usage (see Section 5.1.5.4).
5. Security Considerations 5. Security Considerations
This section describes the countermeasures as recommended to mitigate This section describes the countermeasures as recommended to mitigate
the threats as described in Section 4. the threats as described in Section 4.
5.1. General 5.1. General
The general section covers consideratios that apply generally across
all OAuth components (client, resource server, token server, and
user-agents).
5.1.1. Confidentiality of Requests 5.1.1. Confidentiality of Requests
This is applicable to all requests sent from client to authorization This is applicable to all requests sent from client to authorization
server or resource server. While OAuth provides a mechanism for server or resource server. While OAuth provides a mechanism for
verifying the integrity of requests, it provides no guarantee of verifying the integrity of requests, it provides no guarantee of
request confidentiality. Unless further precautions are taken, request confidentiality. Unless further precautions are taken,
eavesdroppers will have full access to request content and may be eavesdroppers will have full access to request content and may be
able to mount attacks through using content of request, e.g. secrets able to mount interception or replay attacks through using content of
or tokens, or mount replay attacks. request, e.g. secrets or tokens.
Attacks can be mitigated by using transport-layer mechanisms such as Attacks can be mitigated by using transport-layer mechanisms such as
TLS or SSL. VPN may considered as well. TLS or SSL. VPN may considered as well.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o Replay of access tokens obtained on tokens endpoint or resource o Replay of access tokens obtained on tokens endpoint or resource
server's endpoint server's endpoint
o Replay of refresh tokens obtained on tokens endpoint o Replay of refresh tokens obtained on tokens endpoint
skipping to change at page 45, line 45 skipping to change at page 45, line 20
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 MUST validate the binding of the server to its domain
name. If the server fails to prove that binding, it is condered a name. If the server fails to prove that binding, it is considered a
men-in-the-middle. The security measure depends on the certification man-in-the-middle attack. The security measure depends on the
authorities the client trusts for that purpose. Clients should certification authorities the client trusts for that purpose.
carefully select those trusted CAs and protect the storage for Clients should carefully select those trusted CAs and protect the
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 conterfeit 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 shall 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
o Notification messages (e-Mail, SMS, ...) o Notification messages (e-Mail, SMS, ...)
o Activity/Event logs o Activity/Event logs
o User self-care applications or portals
o User self-care apps or portals
5.1.4. Credentials 5.1.4. Credentials
This sections describes countermeasures used to protect all kind of This sections describes countermeasures used to protect all kinds of
credentials from unauthorized access and abuse. Credentials are long credentials from unauthorized access and abuse. Credentials are long
term secrets, such as client secrets and user passwords as well as term secrets, such as client secrets and user passwords as well as
all kinds of tokens (refresh and access token) or authorization all kinds of tokens (refresh and access token) or authorization
codes. codes.
5.1.4.1. Credential storage protection 5.1.4.1. Credential Storage Protection
5.1.4.1.1. Standard system security means Administrators should undertake industry best practices to protect
the storage of credentials. Such practices may include but are not
limited to the following sub-sections.
5.1.4.1.1. Standard System Security Means
A server system may be locked down so that no attacker may get access A server system may be locked down so that no attacker may get access
to sensible configuration files and databases. to sensible configuration files and databases.
5.1.4.1.2. Standard SQL inj. Countermeasures 5.1.4.1.2. Standard SQL Injection Countermeasures
If a client identifier or other authentication component is queried If a client identifier or other authentication component is queried
or compared against a SQL Database it may become possible for an or compared against a SQL Database it may become possible for an
injection attack to occur if parameters received are not validated injection attack to occur if parameters received are not validated
before submission to the database. before submission to the database.
o Ensure that server code is using the minimum database privileges o Ensure that server code is using the minimum database privileges
possible to reduce the "surface" of possible attacks. possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use o Avoid dynamic SQL using concatenated input. If possible, use
skipping to change at page 47, line 31 skipping to change at page 47, line 10
clear text. Typical approaches are to store hashes instead. If the clear text. Typical approaches are to store hashes instead. If the
credential lacks a reasonable entropy level (because it is a user credential lacks a reasonable entropy level (because it is a user
password) an additional salt will harden the storage to prevent password) an additional salt will harden the storage to prevent
offline dictionary attacks. Note: Some authentication protocols offline dictionary attacks. Note: Some authentication protocols
require the authorization server to have access to the secret in the require the authorization server to have access to the secret in the
clear. Those protocols cannot be implemented if the server only has clear. Those protocols cannot be implemented if the server only has
access to hashes. access to hashes.
5.1.4.1.4. Encryption of credentials 5.1.4.1.4. Encryption of credentials
For client applicatinos, 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. Nevertheless, it MUST
skipping to change at page 48, line 31 skipping to change at page 48, line 11
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
The authorization server may react on failed attempts to authenticate The authorization server may react on failed attempts to authenticate
by username/password by temporarily locking the respective account by username/password by temporarily locking the respective account
and delaying the response for a certain duration. This duration may and delaying the response for a certain duration. This duration may
increase with the number of failed attempts. The objective is to increase with the number of failed attempts. The objective is to
slow the attackes attempts on a certain username down. slow the attackers attempts on a certain username down.
Note: this may require a more complex and stateful design of the Note: this may require a more complex and stateful design of the
authorization server. authorization server.
5.1.4.2.5. Usage of CAPTCHAs 5.1.4.2.5. Usage of CAPTCHAs
The idea is to prevent programms from automatically checkinga huge The idea is to prevent programs from automatically checking huge
number of passwords by requiring human interaction. number of passwords by requiring human interaction.
Note: this has a negative impact on user experience. Note: this has a negative impact on user experience.
5.1.5. Tokens (access, refresh, code) 5.1.5. Tokens (access, refresh, code)
5.1.5.1. Limit token scope 5.1.5.1. Limit token scope
The authorization server may decide to reduce or limit the scope The authorization server may decide to reduce or limit the scope
associated with a token. Basis of this decision is out of scope, associated with a token. Basis of this decision is out of scope,
examples are: examples are:
o a client-specific policy, e.g. issue only less powerful tokens to o a client-specific policy, e.g. issue only less powerful tokens to
unauthenticated clients, public clients,
o a service-specific policy, e.g. it a very sensible service, o a service-specific policy, e.g. it a very sensible service,
o a resource-owner specific setting, or o a resource-owner specific setting, or
o combinations of such policies and preferences. o combinations of such policies and preferences.
The authorization server may allow different scopes dependent on the The authorization server may allow different scopes dependent on the
grant type. For example, end-user authorization via direct grant type. For example, end-user authorization via direct
interaction with the end-user (authorization code) might be interaction with the end-user (authorization code) might be
considered more reliable than direct authorization via gran type considered more reliable than direct authorization via grant type
username/password. This means will reduce the impact of the username/password. This means will reduce the impact of the
following threats: following threats:
o token leakage o token leakage
o token issuance to malicious software o token issuance to malicious software
o unintended issuance of to powerful tokens with resource owner o unintended issuance of to powerful tokens with resource owner
credentials flow credentials flow
skipping to change at page 49, line 43 skipping to change at page 49, line 20
5.1.5.3. Short expiration time 5.1.5.3. Short expiration time
A short expiration time for tokens is a protection means against the A short expiration time for tokens is a protection means against the
following threats: following threats:
o replay o replay
o reduce impact of token leak o reduce impact of token leak
o reduce likelyhood of sucessful online guessing o reduce likelihood of successful online guessing
Note: Short token duration requires preciser clock synchronisation Note: Short token duration requires preciser clock synchronisation
between authorization server and resource server. Furthermore, between authorization server and resource server. Furthermore,
shorter duration may require more token refreshments (access token) shorter duration may require more token refreshments (access token)
or repeated end-user authorization processes (authorization code and or repeated end-user authorization processes (authorization code and
refresh token). refresh token).
5.1.5.4. Limit number of usages/ One time usage 5.1.5.4. Limit number of usages/ One time usage
The authorization server may restrict the number of request, which The authorization server may restrict the number of requests or
can be performed with a certain token. This mechanism can be used to operations which can be performed with a certain token. This
mitigate the following threats: mechanism can be used to mitigate the following threats:
o replay of tokens o replay of tokens
o reduce likelyhood of sucessful online guessing o reduce likelihood of successful online guessing
Additionally, If an Authorization Server observes multiple attempts For example, if an Authorization Server observes more than one
to redeem a authorization code, the Authorization Server may want to attempt to redeem a authorization code, the Authorization Server MAY
revoke all tokens granted based on the authorization code. want to revoke all access tokens granted based on the authorization
code as well as reject the current request.
As with the authorization code, access tokens MAY also have a limited
number of operations. This forces client applications to either re-
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
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 to
issue tokens with different content to different resource servers and issue tokens with different content to different resource servers and
to explicitely indicate in the token the target server a token is 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 reduce 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 conterfeit o It reduce the impact of a leakage of a valid token to a
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 explicitely defined Deployments may consider to use only 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 match must be validated for every request
with that token. This means can be used, to with that token. This means can be used, to
skipping to change at page 51, line 23 skipping to change at page 51, line 7
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 shall 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 MUST include a
skipping to change at page 51, line 45 skipping to change at page 51, line 29
attacks. The token value MUST be constructed from a attacks. The token value MUST 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 MUST 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). (such as SAML or JWT) that implements [draft-ietf-oauth-assertions].
5.1.6. Access tokens 5.1.6. Access tokens
o keep them in transient memory (accessible by the client app only) o keep them in transient memory (accessible by the client
application only)
o protect from exposure to 3rd parties (malicious application)
o exposure to 3rd parties (malicious app)
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
Authorization Server end-point.
5.2.1. Authorization Codes 5.2.1. Authorization Codes
5.2.1.1. Automatic revocation of derived tokens if abuse is detected 5.2.1.1. Automatic revocation of derived tokens if abuse is detected
If an Authorization Server observes multiple attempts to redeem a If an Authorization Server observes multiple attempts to redeem an
authorization code, the Authorization Server may want to revoke all authorization grant (e.g. such as an authorization code), the
tokens granted based on the authorization code. Authorization Server may want to revoke all tokens granted based on
the authorization grant.
5.2.2. Refresh tokens 5.2.2. Refresh tokens
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 areo 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 MUST 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. This measure is a
countermeasure against refresh token theft or leakage. countermeasure against refresh token theft or leakage.
Note: This binding MUST be protected from unauthorized modifications. Note: This binding MUST be protected from unauthorized modifications.
5.2.2.3. Refresh Token Replacement 5.2.2.3. Refresh Token Rotation
Refresh token replacement 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
cannot determine whether the attacker or the legitimate client is cannot determine whether the attacker or the legitimate client is
trying to access, in case of such an access attempt the valid refresh trying to access, in case of such an access attempt the valid refresh
token and the access authorization associated with it are both token and the access authorization associated with it are both
revoked. revoked.
skipping to change at page 53, line 11 skipping to change at page 52, line 48
The OAuth specification supports this measure in that the tokens The OAuth specification supports this measure in that the tokens
response allows the authorization server to return a new refresh response allows the authorization server to return a new refresh
token even for requests with grant type "refresh_token". token even for requests with grant type "refresh_token".
Note: this measure may cause problems in clustered environments since Note: this measure may cause problems in clustered environments since
usage of the currently valid refresh token must be ensured. In such usage of the currently valid refresh token must be ensured. In such
an environment, other measures might be more appropriate. an environment, other measures might be more appropriate.
5.2.2.4. Refresh Token Revocation 5.2.2.4. Refresh Token Revocation
The authorization server may allow clients or end-users to The authorization server may allow clients or end-users to explicitly
explicitely request the invalidation of refresh tokens. request the invalidation of refresh tokens.
This is a countermeasure againts:
o device theft This is a countermeasure against:
o ... o device theft,
5.2.2.5. Combine refresh token requests with user-provided secret o impersonation of resource owner, or
The exchange of a refresh token can be bound to the presence of a o suspected compromised client applications.
certain user-provided secret, such as a PIN, a password or a SIM
card. This is a kind of multi-factor authentication on the tokens
endpoint, since an attacker must possess both factors in order to be
able to obtain an access token.
5.2.2.6. 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 or token assigned to that device.
As the IMEI can be spoofed, that is not suitable, For mobile phones, As the IMEI can be spoofed, that is not suitable, For mobile phones,
a registration process can be used to assign a unique token to the a registration process can be used to assign a unique token to the
device using an sms message. That token or identifer can then be device using an SMS message. That token or identifier can then be
validated with when authenticating user credentials. validated with when authenticating user credentials.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o phishing attacks o token theft from a particular device
o ...
5.2.2.7. 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 sameorigin, which will block any framing or framing by sites deny and same origin, which will block any framing or framing by
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
o ...
5.2.3. Client authentication and authorization 5.2.3. Public 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,
o Authorize access of clients to certain features on the o Authorize access of clients to certain features on the
authorization or resource server, and authorization or resource server, and
o Log a client identity to log files for analysis or statics. o Log a client identity to log files for analysis or statics.
Due to the different capababilities and characterictics of the Due to the different capabilities and characteristics of the
different client types, there are different ways to support achieve different client types, there are different ways to support achieve
objectives, which will be described in this section. Generally objectives, which will be described in this section. Authorization
spoken, authorization server providers should be aware of the server providers should be aware of the security policy and
security policy and deployment of a particular clients and adapt its deployment of a particular clients and adapt its treatment
treatment accordingly. For example, one approach could be to treat accordingly. For example, one approach could be to treat all clients
all clients as less trustworthy and unsecure. On the other extrem, a as less trustworthy and unsecure. On the other extreme, a service
service provider could activate every client installation by hand of provider could activate every client installation by hand of an
an administrator and that way gain confidence in the identity of the administrator and that way gain confidence in the identity of the
software package and the security of the environment the client is software package and the security of the environment the client is
installed in. And there are several approaches in between. installed in. And there are several approaches in between.
5.2.3.1. Don't issue secrets to clients with inappropriate security 5.2.3.1. Don't issue secrets to public clients or clients with
policy inappropriate security policy
Authorization servers should not issue secrets to clients, if these Authorization servers should not issue secrets to "public" clients
cannot sufficiently protect it. This prevents the server from that cannot protect secrets. This prevents the server from
overestimating the value of a sucessful authentication of the client. overestimating the value of a successful authentication of the
client.
For example, it is of limited benefit to create a single client id For example, it is of limited benefit to create a single client id
and secret which is shared by all installations of a native app. and secret which is shared by all installations of a native
First of all, this secret must be somehow transmitted from the application. Such a scenario requires that this secret must be
developer via the respective distribution channel, e.g. an app transmitted from the developer via the respective distribution
market, to all installations of the app on end-user devices. So the channel, e.g. an application market, to all installations of the
secret is typically burned into the source code of the app or a application on end-user devices. A secret, burned into the source
associated resource bundle, which cannot be entirely protected from code of the application or a associated resource bundle, cannot be
reverse engineering. Second, effectively such secrets cannot be entirely protected from reverse engineering. Secondly, such secrets
revoked since this would immediatly put all installations out of cannot be revoked since this would immediately put all installations
work. Moreover, since the authorization server cannot really trust out of work. Moreover, since the authorization server cannot really
on the client's identity, it would be dangerous to indicate to end- trust on the client's identity, it would be dangerous to indicate to
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. Clients without secret require user consent 5.2.3.2. Public clients without secret require user consent
The authorization may issue a client id, but only accept Authorization servers should not allow automatic authorization for
authorization request, which are approved by the end-user. This public clients. The authorization may issue a client id, but SHOULD
measure precludes automatic authorization processes. This is a require that all authorizations are approved by the end-user. This
countermeasure for clients without secret against the following is a countermeasure for clients without secret against the following
threats: threats:
o ... [[Not sure what is meant here]] o Impersonation of public client applications
o ...
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, but bind this client_id to a The authorization may issue a client_id and bind the client_id to a
certain pre-configured redirect_uri. So any authorization request certain pre-configured redirect_uri. Any authorization request with
with another redirect_uri is refused automatically. Alternatively, another redirection URI is refused automatically. Alternatively, the
the authorization server may not accept any dynamic redirect_uri for authorization server MUST not accept any dynamic redirection URI for
such a client_id and instead always redirect to the well-known pre- such a client_id and instead always redirect to the well-known pre-
configured redirect_uri. This is a countermeasure for clients configured redirection URI. This is a countermeasure for clients
without secrets against the following threats: without secrets against the following threats:
o ...[[Not sure what is meant here]] o Cross-site scripting attacks
o ... 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 ids and A authorization server may issue separate client identifiers and
corresponding secrets to the different deployments of a client. corresponding secrets to the different deployments of a client. The
effect of such an approach would be to turn otherwise "public"
clients back into "confidential" clients.
For web applications, this could mean to create one client_id and For web applications, this could mean to create one client_id and
client_secret per web site a software package is installed on. So client_secret per web site a software package is installed on. So
the provider of that particular site could request client id and the provider of that particular site could request client id and
secret from the authorization server during setup of the web site. secret from the authorization server during setup of the web site.
This would also allow to validate some of the properties of that web This would also allow to validate some of the properties of that web
site, such as redirect_uri, address, and whatever proofs useful. The site, such as redirection URI, address, and whatever proofs useful.
web site provider has to ensure the security of the client secret on The web site provider has to ensure the security of the client secret
the site. on the site.
For native applications, things are more complicated because every For native applications, things are more complicated because every
installation of the app on any device is another deployment. installation of the application on any device is another deployment.
Deployment specific secrets will require Deployment specific secrets will require
1. Either to obtain a client_id and client_secret during download 1. Either to obtain a client_id and client_secret during download
process from the app market, or process from the application market, or
2. During installation on the device. 2. During installation on the device.
Either approach will require an automated mechanism for issuing Either approach will require an automated mechanism for issuing
client ids and secrets, which is currently not defined by OAuth. client ids and secrets, which is currently not defined by OAuth.
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.
This is a countermeasure against the following threats:
o ...
o ...
5.2.3.5. Validation of pre-registered redirect_uri 5.2.3.5. Validation of pre-registered redirect_uri
An authorization server may require clients to register their An authorization server SHOULD require all clients to register their
redirect_uri or a pattern (TBD: make definition more precise) redirect_uri and the redirect_uri should be the full URI as defined
thereof. The way this registration is performed is out of scope of in [I-D.ietf-oauth-v2]. The way this registration is performed is
this document. Every actual redirect_uri sent with the respective out of scope of this document. Every actual redirection URI sent
client_id to the end-user authorization endpoint must comply with with the respective client_id to the end-user authorization endpoint
that pattern. Otherwise the authorization server must assume the must match the registered redirection URI. Where it does not match,
inbound GET request has been sent by an attacker and refuse it. the authorization server must assume the inbound GET request has been
Note: the authorization server MUST NOT redirect the user agent back sent by an attacker and refuse it. Note: the authorization server
to the redirect_uri of such an authorization request. MUST NOT redirect the user agent back to the redirection URI of such
an authorization request.
o Authorization code leakage through conterfeit 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 apps early in the end-user authorization process. detect malicious applications early in the end-user authorization
This reduces the need for a interactive validation by the user process. This reduces the need for a interactive validation by
(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. (
Section 4.1.5. )
o Open Redirector phishing attack via authorization server
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 must
use another redirect_uri in order to get access to the authorization use another redirection URI in order to get access to the
code. Deployments might consider the possibility of an attacker authorization code. Deployments might consider the possibility of an
using spoofing attacks to a victims device to circumvent this attacker using spoofing attacks to a victims device to circumvent
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 feasable. gets involved, that's no longer feasible.
5.2.3.6. Client secret revocation 5.2.3.6. Client secret revocation
An authorization server may revoke a client's secret in order to An authorization server may revoke a client's secret in order to
prevent abuse of a revealed secret. prevent abuse of a revealed secret.
Note: This measure will immediately invalidate any authorization code Note: This measure will immediately invalidate any authorization code
or refresh token issued to the respective client. This might be or refresh token issued to the respective client. This might be
unintentionally for client identifiers and secrets used across unintentionally for client identifiers and secrets used across
multiple deployments of a particular native or web application. multiple deployments of a particular native or web application.
This a countermeasure against: This a countermeasure against:
o ... o Abuse of revealed client secrets for private clients
o ...
5.2.3.7. Use strong client authentication (e.g. client_assertion / 5.2.3.7. Use strong client authentication (e.g. client_assertion /
client_token) client_token)
Assumption: prevents an attacker from obtaining a client secret By using an alternative form of authentication such as client
because this secret is kept in some hardware security module? assertion [draft-ietf-oauth-assertions], the need to distribute
client_secret is eliminated. This may require the use of a secure
private key store or other supplemental authentication system as
specified by the client assertion issuer in its authentication
process.
5.2.4. End-user authorization 5.2.4. End-user authorization
This secion involves considerations for authorization flows involving
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 certs (5.7.2.7. Use strong client authentication (e.g. security certificates (5.7.2.7. Use strong client authentication
client_assertion / client_token)) or validation of a pre-registered (e.g. client_assertion / client_token)) or validation of a pre-
redirect uri (5.7.2.5. Validation of pre-registered redirect_uri ). registered redirect URI (5.7.2.5. Validation of pre-registered
redirection URI ).
5.2.4.2. Informed decisions based on transparency 5.2.4.2. Informed decisions based on transparency
The authorization server shall intelligible explain to the end-user The authorization server SHOULD clearly explain to the end-user what
what happens in the authorization process and what the consequences happens in the authorization process and what the consequences are.
are. For example, the user shall understand what access he is about For example, the user shall understand what access he is about to
to grant to which client for what duration. It shall also be obvious grant to which client for what duration. It shall also be obvious to
to the user, whether the server is able to reliably certify certain 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-users can be involed 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 app the end-user is using. This measure is especially helpful in the application the end-user is using. This measure is especially
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 app o Malicious application
o ... 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 MUST bind every authorization code to the id
of the respective client which initiated the end-user authorization of the respective client which initiated the end-user authorization
process. This measure is a countermeasure against: 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 MUST 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 MUST bind every authorization code to the
actual redirect_uri used as redirect target of the client in the end- actual redirection URI used as redirect target of the client in the
user authorization process. This binding MUST be validated when the end-user authorization process. This binding MUST be validated when
client attempts to exchange the respective authorization code for an the client attempts to exchange the respective authorization code for
access token. This measure is a countermeasure against authorization an access token. This measure is a countermeasure against
code leakage through counterfeit web sites since an attacker cannot authorization code leakage through counterfeit web sites since an
use another redirect_uri to exchange an authorization code into a attacker cannot use another redirection URI to exchange an
token. authorization code into a token.
5.3. Client App Security 5.3. Client App Security
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
[Anything more to say ? :-)] Because of the numbers of copies of client software, there is limited
benefit to create a single client id and secret which is shared by
all installations of an application. Such an application by itself
would be considered a "public" client as it cannot be presumed to be
able to keep client secrets. A secret, burned into the source code
of the application or a associated resource bundle, cannot be
entirely protected from reverse engineering. Secondly, such secrets
cannot be revoked since this would immediately put all installations
out of work. Moreover, since the authorization server cannot really
trust on the client's identity, it would be dangerous to indicate to
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)
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 seggregate 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 separat operating systems even support to store app-specific data in separate
areas of the file systems and protect it from access by other apps. areas of the file systems and protect it from access by other
Additionally, apps can implements confidential data itself using a applications. Additionally, applications can implements confidential
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 must ensure that confidential data are kept confidential even after
readin 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 app. 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
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
The state parameter is used to link client requests and prevent CSRF
attacks, for example against the redirection URI. An attacker could
inject their own authorization code or access token, which can result
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
bank account information to a protected resource controlled by the
attacker).
The client SHOULD utilize the "state" request parameter to send the
authorization server a value that binds the request to the user-
agent's authenticated state (e.g. a hash of the session cookie used
to authenticate the user-agent) when making an authorization request.
Once authorization has been obtained from the end-user, the
authorization server redirects the end-user's user-agent back to the
client with the required binding value contained in the "state"
parameter.
The binding value enables the client to verify the validity of the
request by matching the binding value to the user- agent's
authenticated state.
5.4. Resource Servers 5.4. Resource Servers
The following section details security considerations for resource
servers.
5.4.1. Authorization headers 5.4.1. Authorization headers
Authorization headers are recognized and specially treated by HTTP Authorization headers are recognized and specially treated by HTTP
proxies and servers. Thus the usage of such headers for sending proxies and servers. Thus the usage of such headers for sending
access tokens to resource servers reduces the likelihood of leakage access tokens to resource servers reduces the likelihood of leakage
or unintended storage of authenticated requests in general and or unintended storage of authenticated requests in general and
especially Authorization headers. especially Authorization headers.
5.4.2. Authenticated requests 5.4.2. Authenticated requests
An authorization server may bind tokens to a certain client identitiy An authorization server may bind tokens to a certain client identity
and encourage resource servers to validate that binding. This will and encourage resource servers to validate that binding. This will
require the resource server to authenticate the originator of a require the resource server to authenticate the originator of a
request as the legitimate owner of a particular token. There are a request as the legitimate owner of a particular token. There are a
couple of options to implement this countermeasure: couple of options to implement this countermeasure:
o The authorization server may associate the distinguished name of o The authorization server may associate the distinguished name of
the client with the token (either internally or in the payload of the client with the token (either internally or in the payload of
an self-contained token). The client then uses client an self-contained token). The client then uses client
certificate-based HTTP authentication on the resource server's certificate-based HTTP authentication on the resource server's
endpoint to authenticate its identity and the resource server endpoint to authenticate its identity and the resource server
skipping to change at page 60, line 39 skipping to change at page 61, line 16
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 uniquly identifiable and must measures. Every signed request must be uniquely identifiable and
not be processed twice by the resource server. This countermeasure must not be processed twice by the resource server. This
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, Eric Pflam, We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam,
Shane B Weeden, Skylar Woodward and James H. Manger for their Shane B Weeden, Skylar Woodward, Niv Steingarten and James H. Manger
comments and contributions. 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-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Protocol", draft-ietf-oauth-v2-16 (work 2.0 Authorization Protocol", draft-ietf-oauth-v2-22 (work
in progress), May 2011. in progress), September 2011.
[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
Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-06 Authorization Protocol: Bearer Tokens",
(work in progress), June 2011. draft-ietf-oauth-v2-bearer-11 (work in progress),
October 2011.
[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., Barth, A., and B. Adida, "HTTP
Authentication: MAC Access Authentication", Authentication: MAC Access Authentication",
draft-ietf-oauth-v2-http-mac-00 (work in progress), draft-ietf-oauth-v2-http-mac-00 (work in progress),
May 2011. May 2011.
[I-D.lodderstedt-oauth-revocation] [I-D.lodderstedt-oauth-revocation]
Lodderstedt, T. and S. Dronia, "Token Revocation", Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
draft-lodderstedt-oauth-revocation-02 (work in progress), Revocation", draft-lodderstedt-oauth-revocation-03 (work
March 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
[[ to be removed by RFC editor before publication as an RFC ]] [[ to be removed by RFC editor before publication as an RFC ]]
draft-lodderstedt-oauth-security-01
o section 4.4.1.2 - changed "resource server" to "client" in o section 4.4.1.2 - changed "resource server" to "client" in
countermeasures description. countermeasures description.
o section 4.4.1.6 - changed "client shall authenticate the server" o section 4.4.1.6 - changed "client shall authenticate the server"
to "The browser shall be utilized to authenticate the redirect_uri to "The browser shall be utilized to authenticate the redirection
of the client" URI of the client"
o section 5 - general review and alignment with public/confidential
client terms
o all sections - general clean-up and typo corrections
draft-ietf-oauth-v2-threatmodel-00 draft-ietf-oauth-v2-threatmodel-00
o section 3.4 - added the purposes for using authorization codes. o section 3.4 - added the purposes for using authorization codes.
o extended section 4.4.1.1 o extended section 4.4.1.1
o merged 4.4.1.5 into 4.4.1.2 o merged 4.4.1.5 into 4.4.1.2
o corrected some typos o corrected some typos
o reformulated "session fixation", renamed respective sections into o reformulated "session fixation", renamed respective sections into
"authorization code disclosure through counterfeit client" "authorization code disclosure through counterfeit client"
o added new section "User session impersonation" o added new section "User session impersonation"
o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
skipping to change at page 62, line 30 skipping to change at page 63, line 17
o reformulated "session fixation", renamed respective sections into o reformulated "session fixation", renamed respective sections into
"authorization code disclosure through counterfeit client" "authorization code disclosure through counterfeit client"
o added new section "User session impersonation" o added new section "User session impersonation"
o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
5.1.4.1.4, 5.2.3.5 5.1.4.1.4, 5.2.3.5
o added new threat "DoS using manufactured authorization codes" as o added new threat "DoS using manufactured authorization codes" as
proposed by Eric Pflam proposed by Peifung E Lam
o added XSRF and clickjacking (incl. state parameter explanation) o added XSRF and clickjacking (incl. state parameter explanation)
o changed sub-section order in section 4.4.1 o changed sub-section order in section 4.4.1
o incorporated feedback from Skylar Woodward (client secrets) and o incorporated feedback from Skylar Woodward (client secrets) and
Shane B Weeden (refresh tokens as client instance secret) Shane B Weeden (refresh tokens as client instance secret)
o aligned client section with core draft's client type definition o aligned client section with core draft's client type definition
o converted I-D into WG document o converted I-D into WG document
draft-ietf-oauth-v2-threatmodel-01
o Alignment of terminology with core draft 22 (private/public
client, redirect URI validation policy, replaced definition of the
client categories by reference to respective core section)
o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation
o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation
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. 232 change blocks. 
602 lines changed or deleted 663 lines changed or added

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