< draft-ietf-oauth-v2-threatmodel-05.txt   draft-ietf-oauth-v2-threatmodel-06.txt >
Web Authorization Protocol (oauth) T. Lodderstedt, Ed. OAuth Working Group T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Internet-Draft Deutsche Telekom AG
Intended status: Informational M. McGloin Intended status: Informational M. McGloin
Expires: November 28, 2012 IBM Expires: December 29, 2012 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
May 27, 2012 June 27, 2012
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-05 draft-ietf-oauth-v2-threatmodel-06
Abstract Abstract
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 Protocol.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 November 28, 2012. This Internet-Draft will expire on December 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 12 skipping to change at page 2, line 12
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 . . . . . . . . . . . . . . . . 8
2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8
2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8
2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Limited Access Token Lifetime . . . . . . . . . . . . 11
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11
3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12
3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12 3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 13
3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12 3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13
4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18
4.1.4. Threat: End-user credentials phished using 4.1.4. Threat: End-user credentials phished using
compromised or embedded browser . . . . . . . . . . . 18 compromised or embedded browser . . . . . . . . . . . 19
4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 20
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 20
4.2.1. Threat: Password phishing by counterfeit 4.2.1. Threat: Password phishing by counterfeit
authorization server . . . . . . . . . . . . . . . . . 20 authorization server . . . . . . . . . . . . . . . . . 20
4.2.2. Threat: User unintentionally grants too much 4.2.2. Threat: User unintentionally grants too much
access scope . . . . . . . . . . . . . . . . . . . . . 20 access scope . . . . . . . . . . . . . . . . . . . . . 21
4.2.3. Threat: Malicious client obtains existing 4.2.3. Threat: Malicious client obtains existing
authorization by fraud . . . . . . . . . . . . . . . . 21 authorization by fraud . . . . . . . . . . . . . . . . 21
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22
4.3.2. Threat: Obtain access tokens from authorization 4.3.2. Threat: Obtain access tokens from authorization
server database . . . . . . . . . . . . . . . . . . . 22 server database . . . . . . . . . . . . . . . . . . . 22
4.3.3. Threat: Obtain client credentials over non secure 4.3.3. Threat: Disclosure of client credentials during
transport . . . . . . . . . . . . . . . . . . . . . . 22 transmission . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. Threat: Obtain client secret from authorization 4.3.4. Threat: Obtain client secret from authorization
server database . . . . . . . . . . . . . . . . . . . 23 server database . . . . . . . . . . . . . . . . . . . 23
4.3.5. Threat: Obtain client secret by online guessing . . . 23 4.3.5. Threat: Obtain client secret by online guessing . . . 23
4.3.6. Threat: DoS on dynamic client secret creation . . . . 23
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24
4.4.1.1. Threat: Eavesdropping or leaking authorization 4.4.1.1. Threat: Eavesdropping or leaking authorization
codes . . . . . . . . . . . . . . . . . . . . . . 24 codes . . . . . . . . . . . . . . . . . . . . . . 24
4.4.1.2. Threat: Obtain authorization codes from 4.4.1.2. Threat: Obtain authorization codes from
authorization server database . . . . . . . . . . 25 authorization server database . . . . . . . . . . 25
4.4.1.3. Threat: Online guessing of authorization codes . . 25 4.4.1.3. Threat: Online guessing of authorization codes . . 26
4.4.1.4. Threat: Malicious client obtains authorization . . 26 4.4.1.4. Threat: Malicious client obtains authorization . . 26
4.4.1.5. Threat: Authorization code phishing . . . . . . . 27 4.4.1.5. Threat: Authorization code phishing . . . . . . . 27
4.4.1.6. Threat: User session impersonation . . . . . . . . 28 4.4.1.6. Threat: User session impersonation . . . . . . . . 28
4.4.1.7. Threat: Authorization code leakage through 4.4.1.7. Threat: Authorization code leakage through
counterfeit client . . . . . . . . . . . . . . . . 28 counterfeit client . . . . . . . . . . . . . . . . 29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30
4.4.1.9. Threat: Clickjacking attack against 4.4.1.9. Threat: Clickjacking attack against
authorization . . . . . . . . . . . . . . . . . . 31 authorization . . . . . . . . . . . . . . . . . . 31
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33
4.4.1.12. Threat: DoS using manufactured authorization 4.4.1.12. Threat: DoS using manufactured authorization
codes . . . . . . . . . . . . . . . . . . . . . . 33 codes . . . . . . . . . . . . . . . . . . . . . . 33
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35
4.4.2.1. Threat: Access token leak in 4.4.2.1. Threat: Access token leak in
transport/end-points . . . . . . . . . . . . . . . 35 transport/end-points . . . . . . . . . . . . . . . 35
4.4.2.2. Threat: Access token leak in browser history . . . 35 4.4.2.2. Threat: Access token leak in browser history . . . 35
4.4.2.3. Threat: Malicious client obtains authorization . . 35 4.4.2.3. Threat: Malicious client obtains authorization . . 35
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36
4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 4.4.3. Resource Owner Password Credentials . . . . . . . . . 37
4.4.3.1. Threat: Accidental exposure of passwords at 4.4.3.1. Threat: Accidental exposure of passwords at
client site . . . . . . . . . . . . . . . . . . . 38 client site . . . . . . . . . . . . . . . . . . . 38
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.3.2. Threat: Client obtains scopes without end-user
authorization . . . . . . . . . . . . . . . . . . 38 authorization . . . . . . . . . . . . . . . . . . 38
4.4.3.3. Threat: Client obtains refresh token through 4.4.3.3. Threat: Client obtains refresh token through
automatic authorization . . . . . . . . . . . . . 38 automatic authorization . . . . . . . . . . . . . 39
4.4.3.4. Threat: Obtain user passwords on transport . . . . 39 4.4.3.4. Threat: Obtain user passwords on transport . . . . 39
4.4.3.5. Threat: Obtain user passwords from 4.4.3.5. Threat: Obtain user passwords from
authorization server database . . . . . . . . . . 39 authorization server database . . . . . . . . . . 39
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40
4.5.1. Threat: Eavesdropping refresh tokens from 4.5.1. Threat: Eavesdropping refresh tokens from
authorization server . . . . . . . . . . . . . . . . . 40 authorization server . . . . . . . . . . . . . . . . . 40
4.5.2. Threat: Obtaining refresh token from authorization 4.5.2. Threat: Obtaining refresh token from authorization
server database . . . . . . . . . . . . . . . . . . . 41 server database . . . . . . . . . . . . . . . . . . . 41
4.5.3. Threat: Obtain refresh token by online guessing . . . 41 4.5.3. Threat: Obtain refresh token by online guessing . . . 41
4.5.4. Threat: Obtain refresh token phishing by 4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 41 counterfeit authorization server . . . . . . . . . . . 41
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42
4.6.1. Threat: Eavesdropping access tokens on transport . . . 42 4.6.1. Threat: Eavesdropping access tokens on transport . . . 42
4.6.2. Threat: Replay authorized resource server requests . . 42 4.6.2. Threat: Replay authorized resource server requests . . 42
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 43
4.6.4. Threat: Access token phishing by counterfeit 4.6.4. Threat: Access token phishing by counterfeit
resource server . . . . . . . . . . . . . . . . . . . 43 resource server . . . . . . . . . . . . . . . . . . . 43
4.6.5. Threat: Abuse of token by legitimate resource 4.6.5. Threat: Abuse of token by legitimate resource
server or client . . . . . . . . . . . . . . . . . . . 44 server or client . . . . . . . . . . . . . . . . . . . 44
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6.7. Threat: Token leakage via logfiles and HTTP
referrers . . . . . . . . . . . . . . . . . . . . . . 44 referrers . . . . . . . . . . . . . . . . . . . . . . 44
5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45
5.1.2. Server authentication . . . . . . . . . . . . . . . . 46 5.1.2. Server authentication . . . . . . . . . . . . . . . . 46
5.1.3. Always keep the resource owner informed . . . . . . . 46 5.1.3. Always keep the resource owner informed . . . . . . . 46
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 47
5.1.4.1. Credential Storage Protection . . . . . . . . . . 47 5.1.4.1. Credential Storage Protection . . . . . . . . . . 47
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 50
5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 50
5.1.5.4. Limit number of usages/ One time usage . . . . . . 50 5.1.5.4. Limit number of usages/ One time usage . . . . . . 51
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) . . . . . . . . . . . . . . . . . . . . 51
5.1.5.6. Use endpoint address as token audience . . . . . . 51 5.1.5.6. Use endpoint address as token audience . . . . . . 51
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 51 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 52
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 52
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 52
5.1.5.10. Encryption of token content . . . . . . . . . . . 51 5.1.5.10. Encryption of token content . . . . . . . . . . . 52
5.1.5.11. Random token value with high entropy . . . . . . . 51 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 52
5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 52 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 53
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 52 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 53
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 53
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52
5.2.1.1. Automatic revocation of derived tokens if 5.2.1.1. Automatic revocation of derived tokens if
abuse is detected . . . . . . . . . . . . . . . . 52 abuse is detected . . . . . . . . . . . . . . . . 53
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 53
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 53
5.2.2.2. Binding of refresh token to client_id . . . . . . 53 5.2.2.2. Binding of refresh token to client_id . . . . . . 53
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 53 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 54
5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 54
5.2.2.5. Device identification . . . . . . . . . . . . . . 54 5.2.2.5. Device identification . . . . . . . . . . . . . . 54
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 54 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 55
5.2.3. Client authentication and authorization . . . . . . . 54 5.2.3. Client authentication and authorization . . . . . . . 55
5.2.3.1. Don't issue secrets to public clients or 5.2.3.1. Don't issue secrets to client with
clients with inappropriate security policy . . . . 55 inappropriate security policy . . . . . . . . . . 55
5.2.3.2. Public clients without secret require user 5.2.3.2. Public clients without secret require user
consent . . . . . . . . . . . . . . . . . . . . . 55 consent . . . . . . . . . . . . . . . . . . . . . 56
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 . 56
5.2.3.4. Deployment-specific client secrets . . . . . . . . 56 5.2.3.4. Installation-specific client secrets . . . . . . . 56
5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 5.2.3.5. Validation of pre-registered redirect_uri . . . . 57
5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 58
5.2.3.7. Use strong client authentication (e.g. 5.2.3.7. Use strong client authentication (e.g.
client_assertion / client_token) . . . . . . . . . 58 client_assertion / client_token) . . . . . . . . . 58
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58
5.2.4.1. Automatic processing of repeated 5.2.4.1. Automatic processing of repeated
authorizations requires client validation . . . . 58 authorizations requires client validation . . . . 59
5.2.4.2. Informed decisions based on transparency . . . . . 58 5.2.4.2. Informed decisions based on transparency . . . . . 59
5.2.4.3. Validation of client properties by end-user . . . 58 5.2.4.3. Validation of client properties by end-user . . . 59
5.2.4.4. Binding of authorization code to client_id . . . . 59 5.2.4.4. Binding of authorization code to client_id . . . . 59
5.2.4.5. Binding of authorization code to redirect_uri . . 59 5.2.4.5. Binding of authorization code to redirect_uri . . 60
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 60
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 . . . . . . . . . . . . 60
5.3.2. Standard web server protection measures (for 5.3.2. Standard web server protection measures (for
config files and databases) . . . . . . . . . . . . . 60 config files and databases) . . . . . . . . . . . . . 60
5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60
5.3.4. Utilize device lock to prevent unauthorized device 5.3.4. Utilize device lock to prevent unauthorized device
access . . . . . . . . . . . . . . . . . . . . . . . . 60 access . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.5. Platform security measures . . . . . . . . . . . . . . 60 5.3.5. Link state parameter to user agent session . . . . . . 61
5.3.6. Link state parameter to user agent session . . . . . . 60
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 62
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62
5.5. A Word on User Interaction and User-Installed Apps . . . . 62 5.5. A Word on User Interaction and User-Installed Apps . . . . 63
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 8. Informative References . . . . . . . . . . . . . . . . . . . . 64
8.1. Normative References . . . . . . . . . . . . . . . . . . . 63 Appendix A. Document History . . . . . . . . . . . . . . . . . . 66
8.2. Informative References . . . . . . . . . . . . . . . . . . 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68
Appendix A. Document History . . . . . . . . . . . . . . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
1. Introduction 1. Introduction
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth specification, based on a comprehensive beyond those in the OAuth specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
contains the following content: contains the following content:
o Documents any assumptions and scope considered when creating the o Documents any assumptions and scope considered when creating the
threat model. threat model.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
Threats include any intentional attacks on OAuth tokens and resources Threats include any intentional attacks on OAuth tokens and resources
protected by OAuth tokens as well as security risks introduced if the protected by OAuth tokens as well as security risks introduced if the
proper security measures are not put in place. Threats are proper security measures are not put in place. Threats are
structured along the lines of the protocol structure to aid structured along the lines of the protocol structure to aid
development teams implement each part of the protocol securely. For development teams implement each part of the protocol securely. For
example all threats for granting access or all threats for a example all threats for granting access or all threats for a
particular grant type or all threats for protecting the resource particular grant type or all threats for protecting the resource
server. server.
Note: This document cannot assess the probability nor the risk
associated with a particular threat because those aspects strongly
depend on the particular application and deployment OAuth is used to
protect. Similar, impacts are given on a rather abstract level. But
the information given here may serve as a foundation for deployment-
specific threat models. Implementors may refine and detail the
abstract threat model in order to account for the specific properties
of their deployment and to come up with a risk analysis.
2. Overview 2. Overview
2.1. Scope 2.1. Scope
The security considerations document only considers clients bound to The security considerations document only considers clients bound to
a particular deployment as supported by [I-D.ietf-oauth-v2]. Such a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
deployments have the following characteristics: deployments have the following characteristics:
o Resource server URLs are static and well-known at development o Resource server URLs are static and well-known at development
time, authorization server URLs can be static or discovered. time, authorization server URLs can be static or discovered.
skipping to change at page 8, line 21 skipping to change at page 8, line 33
The following data elements are stored or accessible on the The following data elements are stored or accessible on the
authorization server: authorization server:
o user names and passwords o user names and passwords
o client ids and secrets o client ids and secrets
o client-specific refresh tokens o client-specific refresh tokens
o client-specific access tokens (in case of handle-based design) o client-specific access tokens (in case of handle-based design -
see Section 3.1)
o HTTPS certificate/key o HTTPS certificate/key
o per-authorization process (in case of handle-based design): o per-authorization process (in case of handle-based design -
redirect_uri, client_id, authorization code Section 3.1): redirect_uri, client_id, authorization code
2.3.2. Resource Server 2.3.2. Resource Server
The following data elements are stored or accessible on the resource The following data elements are stored or accessible on the resource
server: server:
o user data (out of scope) o user data (out of scope)
o HTTPS certificate/key o HTTPS certificate/key
o authorization server credentials (handle-based design), or o authorization server credentials (handle-based design - see
Section 3.1), or
o authorization server shared secret/public key (assertion-based o authorization server shared secret/public key (assertion-based
design) design - see Section 3.1)
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 In OAuth a client is an application making protected resource
[I-D.ietf-oauth-v2], Section 2.1. requests on behalf of the resource owner and with its authorization.
There are different types of clients with different implementation
and security characteristics, such as web, user-agent-based, and
native applications. A full definition of the 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 certificates (HTTPS) o trusted CA certificates (HTTPS)
skipping to change at page 9, line 45 skipping to change at page 10, line 14
to validate the token and obtain token-bound data. This to validate the token and obtain token-bound data. This
communication might have an negative impact on performance and communication might have an negative impact on performance and
scalability if both entities reside on different systems. Handles scalability if both entities reside on different systems. Handles
are therefore typically used if the issuing and consuming entity are therefore typically used if the issuing and consuming entity
are the same. A 'handle' token is often referred to as an are the same. A 'handle' token is often referred to as an
'opaque' token because the resource server does not need to be 'opaque' token because the resource server does not need to be
able to interpret the token directly, it simply uses the token. able to interpret the token directly, it simply uses the token.
Assertions (aka self-contained token) a parseable token. An Assertions (aka self-contained token) a parseable token. An
assertion typically has a duration, has an audience, and is assertion typically has a duration, has an audience, and is
digitally signed. It contains information about the user and the digitally signed in order to ensure data integrity and origin
client. Examples of assertion formats are SAML assertions and authentication. It contains information about the user and the
Kerberos tickets. Assertions can typically directly be validated client. Examples of assertion formats are SAML assertions
and used by a resource server without interactions with the [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120].
authorization server. This results in better performance and Assertions can typically directly be validated and used by a
scalability in deployment where issuing and consuming entity resource server without interactions with the authorization
reside on different systems. Implementing token revocation is server. This results in better performance and scalability in
more difficult with assertions than with handles. deployment where issuing and consuming entity reside on different
systems. Implementing token revocation is more difficult with
assertions than with handles.
Tokens can be used in two ways to invoke requests on resource servers Tokens can be used in two ways to invoke requests on resource servers
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
skipping to change at page 10, line 42 skipping to change at page 11, line 13
methods on those resources. Scopes are the OAuth way to explicitly methods on those resources. Scopes are the OAuth way to explicitly
manage the power associated with an access token. A scope can be manage the power associated with an access token. A scope can be
controlled by the authorization server and/or the end-user in order controlled by the authorization server and/or the end-user in order
to limit access to resources for OAuth clients these parties deem to limit access to resources for OAuth clients these parties deem
less secure or trustworthy. Optionally, the client can request the less secure or trustworthy. Optionally, the client can request the
scope to apply to the token but only for lesser scope than would scope to apply to the token but only for lesser scope than would
otherwise be granted, e.g. to reduce the potential impact if this otherwise be granted, e.g. to reduce the potential impact if this
token is sent over non secure channels. A scope is typically token is sent over non secure channels. A scope is typically
complemented by a restriction on a token's lifetime. complemented by a restriction on a token's lifetime.
3.1.2. Expires_In 3.1.2. Limited Access Token Lifetime
Expires_In allows an authorization server (based on its policies or The protocol parameter expires_in allows an authorization server
on behalf of the end-user) to limit the lifetime of the access token. (based on its policies or on behalf of the end-user) to limit the
This mechanisms can be used to issue short-living tokens to OAuth lifetime of an access token and to pass this information to the
clients the authorization server deems less secure or where sending client. This mechanism can be used to issue short-living tokens to
tokens over non secure channels. OAuth clients the authorization server deems less secure or where
sending tokens over non secure channels.
3.2. Access Token 3.2. Access Token
An access token is used by a client to access a resource. Access An access token is used by a client to access a resource. Access
tokens typically have short life-spans (minutes or hours) that cover tokens typically have short life-spans (minutes or hours) that cover
typical session lifetimes. An access token may be refreshed through typical session lifetimes. An access token may be refreshed through
the use of a refresh token. The short lifespan of an access token in the use of a refresh token. The short lifespan of an access token in
combination with the usage of refresh tokens enables the possibility combination with the usage of refresh tokens enables the possibility
of passive revocation of access authorization on the expiry of the of passive revocation of access authorization on the expiry of the
current access token. current access token.
skipping to change at page 12, line 7 skipping to change at page 12, line 25
3. The client always uses the refresh token in secure transport- 3. The client always uses the refresh token in secure transport-
level communications to the authorization server to get an access level communications to the authorization server to get an access
token (and optionally rollover the refresh token). token (and optionally rollover the refresh token).
So as long as the confidentiality of the particular token can be So as long as the confidentiality of the particular token can be
ensured by the client, a refresh token can also be used as an ensured by the client, a refresh token can also be used as an
alternative means to authenticate the client instance itself.. alternative means to authenticate the client instance itself..
3.4. Authorization Code 3.4. Authorization Code
An Authorization Code represents the intermediate result of a An authorization code represents the intermediate result of a
successful end-user authorization process and is used by the client successful end-user authorization process and is used by the client
to obtain access and refresh token. Authorization codes are sent to to obtain access and refresh token. Authorization codes are sent to
the client's redirection URI instead of tokens for two purposes. the client's redirection URI instead of tokens for two purposes.
1. Instead of (longer-lasting) tokens, the short-lived authorization 1. Browser-based flows expose protocol parameters to potential
code is exposed to potential attackers via URI query parameters attackers via URI query parameters (HTTP referrer), the browser
(HTTP referrer), browser cache, or log file entries. cache, or log file entries and could be replayed. In order to
reduce this threat, short-lived authorization codes are passed
instead of tokens and exchanged for tokens over a more secure
direct connection between client and authorization server.
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 latter would
require digital signatures. require digital signatures.
3.5. Redirection URI 3.5. Redirection URI
A redirection URI helps to detect malicious clients and prevents A redirection URI helps to detect malicious clients and prevents
phishing attacks from clients attempting to trick the user into phishing attacks from clients attempting to trick the user into
believing the phisher is the client. The value of the actual believing the phisher is the client. The value of the actual
redirection URI used in the authorization request has to be presented redirection URI used in the authorization request has to be presented
and is verified when an authorization code is exchanged for tokens. and is verified when an authorization code is exchanged for tokens.
This helps to prevent attacks, where the authorization code is This helps to prevent attacks, where the authorization code is
revealed through redirectors and counterfeit web application clients. revealed through redirectors and counterfeit web application clients.
The authorization server should require public clients and The authorization server should require public clients and
confidential clients using implicit grant type to pre-register their confidential clients using implicit grant type to pre-register their
redirect URIs and validate against the registered redirection URI in redirect URIs and validate against the registered redirection URI in
the authorization request. the authorization request.
3.6. State parameter 3.6. State parameter
The state parameter is used to link requests and callbacks to prevent The state parameter is used to link requests and callbacks to prevent
CSRF attacks where an attacker authorizes access to his own resources Cross-Site Request Forgery attacks (see Section 4.4.1.8) where an
and then tricks a users into following a redirect with the attacker's attacker authorizes access to his own resources and then tricks a
token. This parameter should bind to the authenticated state in a users into following a redirect with the attacker's token. This
user agent and, as per the core OAuth spec, the user agent must be parameter should bind to the authenticated state in a user agent and,
capable of keeping it in a location accessible only by the client and as per the core OAuth spec, the user agent must be capable of keeping
user agent, i.e. protected by same-origin policy 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 Identitifier
Authentication protocols have typically not taken into account the Authentication protocols have typically not taken into account the
identity of the software component acting on behalf of the end-user. identity of the software component acting on behalf of the end-user.
OAuth does this in order to increase the security level in delegated OAuth does this in order to increase the security level in delegated
authorization scenarios and because the client will be able to act authorization scenarios and because the client will be able to act
without the user being present. without the user being present.
OAuth uses the client identifier to collate associated request to the OAuth uses the client identifier to collate associated request to the
same originator, such as same originator, such as
o a particular end-user authorization process and the corresponding o a particular end-user authorization process and the corresponding
request on the token's endpoint to exchange the authorization code request on the token's endpoint to exchange the authorization code
for tokens or for tokens or
o the initial authorization and issuance of a token by an end-user o the initial authorization and issuance of a token by an end-user
to a particular client, and subsequent requests by this client to to a particular client, and subsequent requests by this client to
obtain tokens without user consent (automatic processing of obtain tokens without user consent (automatic processing of
repeated authorization) repeated authorization)
The client identity may also be used by the authorization server to This identifier 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 identifier may be used to limit the number of request for a
client or to charge the client per request. Client Identity may particular client or to charge the client per request. It may
furthermore be useful to differentiate access by different clients, furthermore be useful to differentiate access by different clients,
e.g. in server log files. e.g. in server log files.
OAuth defines two client types, confidential and public, based on OAuth defines two client types, confidential and public, based on
their ability to authenticate with the authorization server (i.e. their ability to authenticate with the authorization server (i.e.
ability to maintain the confidentiality of their client credentials). ability to maintain the confidentiality of their client credentials).
Confidential clients are capable of maintaining the confidentiality Confidential clients are capable of maintaining the confidentiality
of client credentials (i.e. a client secret associated with the of client credentials (i.e. a client secret associated with the
client identifier) or capable of secure client authentication using client identifier) or capable of secure client authentication using
other means, such as a client assertion (e.g. SAML) or key other means, such as a client assertion (e.g. SAML) or key
cryptography. The latter is considered more secure. cryptography. The latter is considered more secure.
The authorization server should determine whether the client is The authorization server should determine whether the client is
capable of keeping its secret confidential or using secure capable of keeping its secret confidential or using secure
authentication. Alternatively, the end-user can verify the identity authentication. Alternatively, the end-user can verify the identity
of the client, e.g. by only installing trusted applications.The of the client, e.g. by only installing trusted applications.The
redicrection URI can be used to prevent delivering credentials to a redicrection URI can be used to prevent delivering credentials to a
counterfeit client after obtaining end-user authorization in some counterfeit client after obtaining end-user authorization in some
cases, but can't be used to verify the client identity. cases, but can't be used to verify the client identifier.
Clients can be categorized as follows based on the client type, Clients can be categorized as follows based on the client type,
profile (e.g. native vs web application) and deployment model: profile (e.g. native vs. web application - see [I-D.ietf-oauth-v2],
Section 9) 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 identifier is used by multiple
installations of the same software package. The identity of such installations of the same software package. The identifier of
a client can only be validated with the help of the end-user. such a client can only be validated with the help of the end-user.
This is a viable option for native applications in order to This is a viable option for native applications in order to
identify the client for the purpose of displaying meta information identify the client for the purpose of displaying meta information
about the client to the user and to differentiate clients in log about the client to the user and to differentiate clients in log
files. Revocation of such an identity will affect ALL deployments files. Revocation of the rights associated with such a client
of the respective software. identifier will affect ALL deployments 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 trust level as weaknesses, such client identities have the same trust level as
deployment-independent clients without secret. Revocation will deployment-independent clients without secret. Revocation will
affect ALL deployments. affect ALL deployments.
Deployment-specific client_id with pre-registered redirect_uri and Deployment-specific client_id with pre-registered redirect_uri and
with client_secret The client registration process ensures the with client_secret The client registration process ensures the
validation of the client's properties, such as redirection URI, validation of the client's properties, such as redirection URI,
website address, web site name, contacts. Such a client identity website URL, web site name, contacts. Such a client identifier
can be utilized for all relevant use cases cited above. This can be utilized for all relevant use cases cited above. This
level can be achieved for web applications in combination with a level can be achieved for web applications in combination with a
manual or user-bound registration process. Achieving this level manual or user-bound registration process. Achieving this level
for native applications is much more difficult. Either the for native applications is much more difficult. Either the
installation of the application is conducted by an administrator, installation of the application is conducted by an administrator,
who validates the client's authenticity, or the process from who validates the client's authenticity, or the process from
validating the application to the installation of the application validating the application to the installation of the application
on the device and the creation of the client credentials is on the device and the creation of the client credentials is
controlled end-to-end by a single entity (e.g. application market controlled end-to-end by a single entity (e.g. application market
provider). Revocation will affect a single deployment only. provider). Revocation will affect a single deployment only.
skipping to change at page 14, line 42 skipping to change at page 15, line 18
server in transactions with subsequent requests (e.g. server in transactions with subsequent requests (e.g.
authorization and token issuance, refresh token issuance and authorization and token issuance, refresh token issuance and
access token refreshment). The authorization server cannot assure access token refreshment). The authorization server cannot assure
any property of the client to end-users. Automatic processing of any property of the client to end-users. Automatic processing of
re-authorizations could be allowed as well. Such client re-authorizations could be allowed as well. Such client
credentials can be generated automatically without any validation credentials can be generated automatically without any validation
of client properties, which makes it another option especially for of client properties, which makes it another option especially for
native applications. Revocation will affect a single deployment native applications. Revocation will affect a single deployment
only. only.
4. Security Threat Model 4. Threat Model
This section gives a comprehensive threat model of OAuth 2.0. This section gives a comprehensive threat model of OAuth 2.0.
Threats are grouped first by attacks directed against an OAuth Threats are grouped first by attacks directed against an OAuth
component, which are client, authorization server, and resource component, which are client, authorization server, and resource
server. Subsequently, they are grouped by flow, e.g. obtain token or server. Subsequently, they are grouped by flow, e.g. obtain token or
access protected resources. Every countermeasure description refers access protected resources. Every countermeasure description refers
to a detailed description in Section 5. to a detailed description in Section 5.
4.1. Clients 4.1. Clients
skipping to change at page 20, line 4 skipping to change at page 20, line 24
under the control of the attacker. under the control of the attacker.
Impact: An attacker could gain access to authorization codes or Impact: An attacker could gain access to authorization codes or
access tokens access tokens
Countermeasure Countermeasure
o require clients to register full redirection URI Section 5.2.3.5 o require clients to register full redirection URI Section 5.2.3.5
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
websites where they are asked to enter their passwords. If Users are websites where they are asked to enter their passwords. If users are
not careful to verify the authenticity of these websites before not careful to verify the authenticity of these websites before
entering their credentials, it will be possible for attackers to entering their credentials, it will be possible for attackers to
exploit this practice to steal Users' passwords. exploit this practice to steal Users' passwords.
Countermeasures: Countermeasures:
o Authorization servers should consider such attacks when developing o Authorization servers should consider such attacks when developing
services based on OAuth, and should require transport-layer services based on OAuth, and should require transport-layer
security for any requests where the authenticity of the security for any requests where the authenticity of the
authorization server or of request responses is an issue (see authorization server or of request responses is an issue (see
skipping to change at page 20, line 39 skipping to change at page 21, line 15
4.2.2. Threat: User unintentionally grants too much access scope 4.2.2. Threat: User unintentionally grants too much access scope
When obtaining end user authorization, the end-user may not When obtaining end user authorization, the end-user may not
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 an understandable way - Section 5.2.4.2
o Narrow scope based on client - When obtaining end user o Narrow scope based on client - When obtaining end 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 the client identifier. That decision is between
client and authorization server and is outside the scope of this the client and authorization server and is outside the scope of
spec. The authorization server may also want to consider what this spec. The authorization server may also want to consider
scope to grant based on the client type, e.g. providing lower what scope to grant based on the client type, e.g. providing lower
scope to public clients. - Section 5.1.5.1 scope to public clients. - 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
skipping to change at page 21, line 44 skipping to change at page 22, line 20
to automatically redirect a user-agent to the location specified by to automatically redirect a user-agent to the location specified by
the parameter value without any validation. the parameter value without any validation.
Impact: An attacker could utilize a user's trust in your Impact: An attacker could utilize a user's trust in your
authorization server to launch a phishing attack. authorization server to launch a phishing attack.
Countermeasure Countermeasure
o require clients to register full redirection URI Section 5.2.3.5 o require clients to register full redirection URI Section 5.2.3.5
o don't redirect to redirection URI, if client identity or o don't redirect to redirection URI, if client identifier or
redirection URI can't be verified Section 5.2.3.5 redirection URI can't be verified Section 5.2.3.5
4.3. Token endpoint 4.3. Token endpoint
4.3.1. Threat: Eavesdropping access tokens 4.3.1. Threat: Eavesdropping access tokens
Attackers may attempts to eavesdrop access token on transit from the Attackers may attempt to eavesdrop access token in 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 As per the core OAuth spec, the authorization servers must ensure o As per the core OAuth spec, the authorization servers must ensure
that these transmissions are protected using transport-layer that these transmissions are protected using transport-layer
mechanisms such as TLS or SSL (see Section 5.1.1). mechanisms such as TLS (see Section 5.1.1).
o If end-to-end confidentiality cannot be guaranteed, reducing scope o If end-to-end confidentiality cannot be guaranteed, reducing scope
(see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
tokens can be used to reduce the damage in case of leaks. tokens can be used to reduce the damage in case of leaks.
4.3.2. Threat: Obtain access tokens from authorization server database 4.3.2. Threat: Obtain access tokens from authorization server database
This threat is applicable if the authorization server stores access This threat is applicable if the authorization server stores access
tokens as handles in a database. An attacker may obtain access tokens as handles in a database. An attacker may obtain access
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
skipping to change at page 22, line 38 skipping to change at page 23, line 11
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 injection 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: Disclosure of client credentials during transmission
An attacker could attempt to eavesdrop the transmission of client An attacker could attempt to eavesdrop the transmission of client
credentials between client and server during the client credentials between client and server during the client
authentication process or during OAuth token requests. Impact: authentication process or during OAuth token requests.
Revelation of a client credential enabling the possibility for
phishing or imitation of a client service. Impact: Revelation of a client credential enabling phishing or
impersonation of a client service.
Countermeasures: Countermeasures:
o Implement transport security through - Section 5.1.1 o The transmission of client credentials must be protected using
transport-layer mechanisms such as TLS (see Section 5.1.1).
o Alternative authentication means, which do not require to send o Alternative authentication means, which do not require to send
plaintext credentials over the wire (Examples: Digest plaintext credentials over the wire (e.g. Hash-based Message
authentication) Authentication Code)
4.3.4. Threat: Obtain client secret from authorization server database 4.3.4. Threat: Obtain client secret from authorization server database
An attacker may obtain valid client_id/secret combinations from the An attacker may obtain valid client_id/secret combinations from the
authorization server's database by gaining access to the database or authorization server's database by gaining access to the database or
launching a SQL injection attack. Impact: disclosure of all launching a SQL injection attack. Impact: disclosure of all
client_id/secret combinations. This allows the attacker to act on client_id/secret combinations. This allows the attacker to act on
behalf of legitimate clients. behalf of legitimate clients.
Countermeasures: Countermeasures:
o System security measures - Section 5.1.4.1.1
o Standard SQL injection Countermeasures - Section 5.1.4.1.2
o Ensure proper handling of credentials as per Credential Storage o Ensure proper handling of credentials as per 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 o Use Strong Client Authentication - Section 5.2.3.7
4.3.6. Threat: DoS on dynamic client secret creation
If an authorization servers includes a nontrivial amount of entropy
in client secrets and if the authorization server automatically
grants them, an attacker could exhaust the pool by repeatedly
applying for them.
Countermeasures:
o The authorization server should consider some verification step
for new clients. The authorization server should include a
nontrivial amount of entropy in client secrets.
4.4. Obtaining Authorization 4.4. Obtaining Authorization
This section covers threats which are specific to certain flows This section covers threats which are specific to certain flows
utilized to obtain access tokens. Each flow is characterized by utilized to obtain access tokens. Each flow is characterized by
response types and/or grant types on the end-user authorization and response types and/or grant types on the end-user authorization and
tokens endpoint, respectively. token endpoint, respectively.
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: in different ways:
o Referrer headers: browsers frequently pass a "referrer" header o Referrer headers: browsers frequently pass a "referer" header when
when a web page embeds content, or when a user travels from one a web page embeds content, or when a user travels from one web
web page to another web page. These referrer headers may be sent page to another web page. These referrer headers may be sent even
even when the origin site does not trust the destination site. when the origin site does not trust the destination site. The
The referrer header is commonly logged for traffic analysis referrer header is commonly logged for traffic analysis purposes.
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.
o Browser history: web browsers commonly record visited URLs in the o Browser history: web browsers commonly record visited URLs in the
browser history. Another user of the same web browser may be able browser history. Another user of the same web browser may be able
to view URLs that were visited by previous users. to view URLs that were visited by previous users.
Note: A description of a similar attacks on the SAML protocol can be Note: A description of a similar attacks on the SAML protocol can be
found at http://www.oasis-open.org/committees/download.php/3405/ found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1,
oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http:// [gross-sec-analysis], and
www.thomasgross.net/publications/papers/ [OASIS.sstc-gross-sec-analysis-response-01].
GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http://
www.oasis-open.org/committees/download.php/11191/
sstc-gross-sec-analysis-response-01.pdf.
Countermeasures: Countermeasures:
o As per the core OAuth spec, the authorization server as well as o As per the core OAuth spec, the authorization server as well as
the client must ensure that these transmissions are protected the client must ensure that these transmissions are protected
using transport-layer mechanisms such as TLS or SSL (see using transport-layer mechanisms such as TLS (see Section 5.1.1).
Section 5.1.1).
o The authorization server will require the client to authenticate o The authorization server will require the client to authenticate
wherever possible, so the binding of the authorization code to a wherever possible, so the binding of the authorization code to a
certain client can be validated in a reliable way (see certain client can be validated in a reliable way (see
Section 5.2.4.4). Section 5.2.4.4).
o Limited duration of authorization codes - Section 5.1.5.3 o Limited duration of authorization codes - Section 5.1.5.3
o The authorization server should enforce a one time usage o The authorization server should enforce a one time usage
restriction (see Section 5.1.5.4). restriction (see Section 5.1.5.4).
o If an Authorization Server observes multiple attempts to redeem a o If an Authorization Server observes multiple attempts to redeem an
authorization code, the Authorization Server may want to revoke authorization code, the Authorization Server may want to revoke
all tokens granted based on the authorization code (see all tokens granted based on the authorization code (see
Section 5.2.1.1). Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope o In the absence of these countermeasures, reducing scope
(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 redirection o The client server may reload the target page of the redirection
URI in order to automatically cleanup the browser cache. URI in order to automatically cleanup the browser cache.
skipping to change at page 26, line 7 skipping to change at page 26, line 16
An attacker may try to guess valid authorization code values and send An attacker may try to guess valid authorization code values and send
it using the grant type "code" in order to obtain a valid access it using the grant type "code" in order to obtain a valid access
token. token.
Impact: disclosure of single access token, probably also associated Impact: disclosure of single access token, probably also associated
refresh token. refresh token.
Countermeasures: Countermeasures:
o Handle-based tokens must use high entropy: Section 5.1.5.11 o Handle-based tokens must use high entropy: Section 5.1.4.2.2
o Assertion-based tokens should be signed: Section 5.1.5.9 o Assertion-based tokens should be signed: Section 5.1.5.9
o Authenticate the client, adds another value the attacker has to o Authenticate the client, adds another value the attacker has to
guess - Section 5.2.3.4 guess - Section 5.2.3.4
o Binding of authorization code to redirection URI, adds another o Binding of authorization code to redirection URI, adds another
value the attacker has to guess - Section 5.2.4.5 value the attacker has to guess - Section 5.2.4.5
o Short expiration time - Section 5.1.5.3 o 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 pretend to be a valid client and obtain an
access authorization that way. The malicious client could even access authorization that way. The malicious client could even
utilize screen scraping techniques in order to simulate the user utilize screen scraping techniques in order to simulate the user
consent in the authorization flow. consent in the authorization flow.
Assumption: It is not the task of the authorization server to protect Assumption: It is not the task of the authorization server to protect
the end-user's device from malicious software. This is the the end-user's device from malicious software. This is the
responsibility of the platform running on the particular device responsibility of the platform running on the particular device
probably in cooperation with other components of the respective probably in cooperation with other components of the respective
ecosystem (e.g. an application management infrastructure). The sole ecosystem (e.g. an application management infrastructure). The sole
responsibility of the authorization server is to control access to responsibility of the authorization server is to control access to
the end-user's resources living in resource servers and to prevent the end-user's resources living in resource servers and to prevent
unauthorized access to them. Based on this assumption, the following unauthorized access to them via the OAuth protocol. Based on this
countermeasures are available to cope with the threat. assumption, the following countermeasures are available to cope with
the threat.
Countermeasures: Countermeasures:
o The authorization server should authenticate the client, if o The authorization server should authenticate the client, if
possible (see Section 5.2.3.4). Note: the authentication takes possible (see Section 5.2.3.4). Note: the authentication takes
place after the end-user has authorized the access. place after the end-user has authorized the access.
o The authorization server should validate the client's redirection o The authorization server should validate the client's redirection
URI against the pre-registered redirection URI, if one exists (see URI against the pre-registered redirection URI, if one exists (see
Section 5.2.3.5). Note: An invalid redirect URI indicates an Section 5.2.3.5). Note: An invalid redirect URI indicates an
invalid client whereas a valid redirect URI not neccesserily invalid client whereas a valid redirect URI does not neccesserily
indicates a valid client. The level of confidence depends on the indicate a valid client. The level of confidence depends on the
client type. For web applications, the confidence is high since client type. For web applications, the confidence is high since
the redirect URI refers to the globally unique network endpoint of the redirect URI refers to the globally unique network endpoint of
this application whose address is also validated using HTTPS this application whose fully qualified domain name (FQDN) is also
server authentication by the user agent. In contrast for native validated using HTTPS server authentication by the user agent. In
clients, the redirect URI typically refers to device local contrast for native clients, the redirect URI typically refers to
resources, e.g. a custom scheme. So a malicious client on a device local resources, e.g. a custom scheme. So a malicious
particular device can use the valid redirect URI the legitimate client on a particular device can use the valid redirect URI the
client uses on all other devices. legitimate client uses on all other devices.
o After authenticating the end-user, the authorization server should o After authenticating the end-user, the authorization server should
ask him/her for consent. In this context, the user should be ask him/her for consent. In this context, the authorization
explained the purpose, scope, and duration of the authorization. server should explain to the end-user the purpose, scope, and
Moreover, the authorization server should show the user any duration of the authorization the client asked for. Moreover, the
identity information it has for that client. It is up to the user authorization server should show the user any identity information
to validate the binding of this data to the particular application it has for that client. It is up to the user to validate the
(e.g. Name) and to approve the authorization request. (see binding of this data to the particular application (e.g. Name)
Section 5.2.4.3). and to approve the authorization request. (see Section 5.2.4.3).
o The authorization server should not perform automatic re- o The authorization server should not perform automatic re-
authorizations for clients it is unable to reliably authenticate authorizations for clients it is unable to reliably authenticate
or validate (see Section 5.2.4.1). or validate (see Section 5.2.4.1).
o If the authorization server automatically authenticates the end- o If the authorization server automatically authenticates the end-
user, it may nevertheless require some user input in order to user, it may nevertheless require some user input in order to
prevent screen scraping. Examples are CAPTCHAs or user-specific prevent screen scraping. Examples are CAPTCHAs (Completely
secrets like PIN codes. Automated Public Turing test to tell Computers and Humans Apart)
or other multi-factor authentication techniques such as random
questions, token code generators, etc.
o The authorization server may also limit the scope of tokens it o The authorization server may also limit the scope of tokens it
issues to clients it cannot reliably authenticate (see issues to clients it cannot reliably authenticate (see
Section 5.1.5.1). Section 5.1.5.1).
4.4.1.5. Threat: Authorization code phishing 4.4.1.5. Threat: Authorization code phishing
A hostile party could impersonate the client site and get access to A hostile party could impersonate the client site and get access to
the authorization code. This could be achieved using DNS or ARP the authorization code. This could be achieved using DNS or ARP
spoofing. This applies to clients, which are web applications, thus spoofing. This applies to clients, which are web applications, thus
skipping to change at page 28, line 26 skipping to change at page 28, line 37
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
sent by the browser to the callback endpoint can gain access to sent by the browser to the callback endpoint can gain access to
protected resources by submitting the authorization code to the protected resources by submitting the authorization code to the
client. The client will exchange the authorization code for an client. The client will exchange the authorization code for an
access token and use the access token to access protected resources access token and use the access token to access protected resources
for the benefit of the attacker, delivering protected resources to for the benefit of the attacker, delivering protected resources to
the attacker, or modifying protected resources as directed by the the attacker, or modifying protected resources as directed by the
attacker. If OAuth is used by the client to delegate authentication attacker. If OAuth is used by the client to delegate authentication
to a social site (e.g. as in the implementation of the "Facebook to a social site (e.g. as in the implementation of "Login" button to
Login" button), the attacker can use the intercepted authorization a third-party social network site), the attacker can use the
code to log in to the client as the user. intercepted authorization code to log in to the client as the user.
Note: Authenticating the client during authorization code exchange Note: Authenticating the client during authorization code exchange
will not help to detect such an attack as it is the legitimate client will not help to detect such an attack as it is the legitimate client
that obtains the tokens. that obtains the tokens.
Countermeasures: Countermeasures:
o In order to prevent an attacker from impersonating the end-users o In order to prevent an attacker from impersonating the end-users
session, the redirection URI of the client should point to a HTTPS session, the redirection URI of the client should point to a HTTPS
protected endpoint and the browser should be utilized to protected endpoint and the browser should be utilized to
skipping to change at page 29, line 23 skipping to change at page 29, line 35
initiates data access to a particular resource server. The initiates data access to a particular resource server. The
client 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 redirection URI parameter referring to a the client to include a redirection URI parameter referring to a
web 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 achieves 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
skipping to change at page 29, line 46 skipping to change at page 30, line 9
6. He then constructs a redirection URI to the target web site (or 6. He then constructs a redirection URI to the target web site (or
application) based on the original authorization request's application) based on the original authorization request's
redirection URI and the newly obtained authorization code and redirection URI and the newly obtained authorization code and
directs his user agent to this URL. The authorization code is directs his user agent to this URL. The authorization code is
injected into the 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 victim's resources using the
client site. client site.
Impact: The attackers gains access to the victim's resources as Impact: The attacker 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 will need to use another redirection URI for its o The attacker will need to use another redirection URI for its
authorization process than the target web site because it needs to authorization process rather than the target web site because it
intercept the flow. So if the authorization server associates the needs to intercept the flow. So if the authorization server
authorization code with the redirection URI of a particular end- associates the authorization code with the redirection URI of a
user authorization and validates this redirection URI with the particular end-user authorization and validates this redirection
redirection URI passed to the token's endpoint, such an attack is URI with the redirection URI passed to the token's endpoint, such
detected (see Section 5.2.4.5). an attack is detected (see Section 5.2.4.5).
o The authorization server may also enforce the usage and validation o The authorization server may also enforce the usage and validation
of pre-registered redirect URIs (see Section 5.2.3.5). This will of pre-registered redirect URIs (see Section 5.2.3.5). This will
allow for an early recognition of session fixation attempts. allow for an early recognition of authorization code disclosure to
counterfeit clients.
o For native applications, one could also consider to use o For native applications, one could also consider to use
deployment-specific client ids and secrets (see Section 5.2.3.4, deployment-specific client ids and secrets (see Section 5.2.3.4,
along with the binding of authorization code to client_id (see along with the binding of authorization code to client_id (see
Section 5.2.4.4), to detect such an attack because the attacker Section 5.2.4.4), to detect such an attack because the attacker
does not have access the deployment-specific secret. Thus he will does not have access the deployment-specific secret. Thus he will
not be able to exchange the authorization code. not be able to exchange the authorization code.
o The client may consider using other flows, which are not o The client may consider using other flows, which are not
vulnerable to this kind of attacks such as "Implicit Grant" or vulnerable to this kind of attack 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.
skipping to change at page 31, line 13 skipping to change at page 31, line 24
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 identity 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
access 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 redirection URI used to deliver the access token. request with the redirection URI used to deliver the access token.
Section 5.3.6 Section 5.3.5
o Client developers and end-user can be educated not follow o Client developers and end-user can be educated to 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 (see [iFrame]) overlaid on top of a set of dummy
are carefully constructed to be placed directly under important buttons which are carefully constructed to be placed directly under
buttons on the target site. When a user clicks a visible button, important buttons on the target site. When a user clicks a visible
they are actually clicking a button (such as an "Authorize" button) button, they are actually clicking a button (such as an "Authorize"
on the hidden page. button) 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 For newer browsers, avoidance of iFrames during authorization can
embedding browsers in a web view when requesting end-user be enforced server side by using the X-FRAME-OPTION header -
authorization Section 5.2.2.6
o For newer browsers, avoidance of iFrames can be enforced server
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 frame-busting (see [framebusting])
but may not be effective in all browsers. techniques can be used but may not be effective in all browsers.
4.4.1.10. Threat: Resource Owner Impersonation 4.4.1.10. Threat: Resource Owner Impersonation
When a client requests access to protected resources, the When a client requests access to protected resources, the
authorization flow normally involves the resource owner's explicit authorization flow normally involves the resource owner's explicit
response to the access request, either granting or denying access to response to the access request, either granting or denying access to
the protected resources. A malicious client can exploit knowledge of the protected resources. A malicious client can exploit knowledge of
the structure of this flow in order to gain authorization without the the structure of this flow in order to gain authorization without the
resource owner's consent, by transmitting the necessary requests resource owner's consent, by transmitting the necessary requests
programmatically, and simulating the flow against the authorization programmatically, and simulating the flow against the authorization
server. That way, the client may gain access to the victims server. That way, the client may gain access to the victim's
resources without her approval. An authorization server will be resources without her approval. An authorization server will be
vulnerable to this threat, if it uses non-interactive authentication vulnerable to this threat, if it uses non-interactive authentication
mechanisms or split the authorization flow across multiple pages. mechanisms or splits the authorization flow across multiple pages.
The malicious client might embed a hidden HTML user agent, interpret The malicious client might embed a hidden HTML user agent, interpret
the HTML forms sent by the authorization server, and automatically the HTML forms sent by the authorization server, and automatically
answer with the corresponding form post requests. As a pre- send the corresponding form post requests. As a pre-requisite, the
requisite, the attacker must be able to execute the authorization attacker must be able to execute the authorization process in the
process in the context of an already authenticated session of the context of an already authenticated session of the resource owner
resource owner with the authorization server. There are different with the authorization server. There are different ways to achieve
ways to achieve this: this:
o The malicious client could abuse an existing session in an o The malicious client could abuse an existing session in an
external browser or cross-browser cookies on the particular external browser or cross-browser cookies on the particular
device. device.
o It could also request authorization for a particular scope and o The malicious client could also request authorization for an
silently abuse the resulting session in his browser instance to initial scope acceptable to the user and then silently abuse the
"silently" request another scope. resulting session in his browser instance to "silently" request
another scope.
o Alternatively, the attacker might exploit an authorization o Alternatively, the attacker might exploit an authorization
server's ability to authenticate the resource owner automatically server's ability to authenticate the resource owner automatically
and without user interactions, e.g. based on certificates. and without user interactions, e.g. based on certificates.
In all cases, such an attack is limited to clients running on the In all cases, such an attack is limited to clients running on the
victim's device, within the user agent or as native app. victim's device, within the user agent or as native app.
Please note: Such attacks cannot be prevented using CSRF Please note: Such attacks cannot be prevented using CSRF
countermeasures, since the attacker just "executes" the URLs as countermeasures, since the attacker just "executes" the URLs as
prepared by the authorization server including any nonce etc. prepared by the authorization server including any nonce etc.
Countermeasures: Countermeasures:
Authorization servers should decide, based on an analysis of the risk Authorization servers should decide, based on an analysis of the risk
associated with this threat, whether to assume, detect, or to prevent associated with this threat, whether to detect and prevent this
this threat. threat.
In order to prevent such an attack, the authorization server may In order to prevent such an attack, the authorization server may
force an user interaction based on non-predictable input values as force a user interaction based on non-predictable input values as
part of the user consent approval. The authorization server could part of the user consent approval. The authorization server could
o combine password authentication and user consent in a single form, o combine password authentication and user consent in a single form,
o make use of CAPTCHAs, or o make use of CAPTCHAs, or
o or use one-time secrets send out of bound to the resource owner o or use one-time secrets sent out of band to the resource owner
(e.g. via text or instance message). (e.g. via text or instant message).
Alternatively in order to allow the resource owner to detect abuse, Alternatively in order to allow the resource owner to detect abuse,
the authorization server could notify the resource owner of any the authorization server could notify the resource owner of any
approval by appropriate means, e.g. text or instant message or approval by appropriate means, e.g. text or instant message or
e-Mail. e-Mail.
4.4.1.11. Threat: DoS, Exhaustion of resources attacks 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 of authorization codes by repeatedly
browser to request code or access tokens. This is because more directing the user's browser to request code or access tokens.
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.12. 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 (see Section 4.4.1.8) is deployed on the client side. With
attacker might need to incur an additional HTTP request to obtain a such a defense, the attacker might need to incur an additional HTTP
valid CSRF code/ state parameter. This apparently cuts down the request to obtain a valid CSRF code/ state parameter. This
effectiveness of the attack by a factor of 2. However, if the HTTPS/ apparently cuts down the effectiveness of the attack by a factor of
HTTP cost ratio is higher than 2 (the cost factor is estimated to be 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
around 3.5x at factor is estimated to be around 3.5x at [ssl-latency]) the attacker
<http://www.semicomplete.com/blog/geekery/ssl-latency.html>) the still achieves a magnification of resource utilization at the expense
attacker still achieves a magnification of resource utilization at of the authorization server.
the expense of the authorization server.
Impact: There are a few effects that the attacker can accomplish with Impact: There are a few effects that the attacker can accomplish with
this OAuth flow that they cannot easily achieve otherwise. this OAuth flow that they cannot easily achieve otherwise.
1. Connection laundering: With the clients as the relay between the 1. Connection laundering: With the clients as the relay between the
attacker and the authorization server, the authorization server attacker and the authorization server, the authorization server
learns little or no information about the identity of the learns little or no information about the identity of the
attacker. Defenses such rate limiting on the offending attacker attacker. Defenses such as rate limiting on the offending
machines are less effective due to the difficulty to identify the attacker machines are less effective due to the difficulty to
attacking machines. Although an attacker could also launder its identify the attacking machines. Although an attacker could also
connections through an anonymizing systems such as Tor, the launder its connections through an anonymizing system such as
effectiveness of that approach depends on the capacity of the Tor, the effectiveness of that approach depends on the capacity
annoying system. On the other hand, a potentially large number of the anonymizing system. On the other hand, a potentially
of OAuth clients could be utilized for this attack. large number 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
more difficult as it seems nontrivial to synchronize a large more difficult as it seems nontrivial to synchronize a large
skipping to change at page 34, line 30 skipping to change at page 34, line 39
the attacker's control. the attacker's control.
Countermeasures Countermeasures
o Though not a complete countermeasure by themselves, CSRF defense o Though not a complete countermeasure by themselves, CSRF defense
and the 'state' parameter created with secure random codes should and the 'state' parameter created with secure random codes should
be deployed on the client side. The client should forward the be deployed on the client side. The client should forward the
authorization code to the authorization server only after both the authorization code to the authorization server only after both the
CSRF token and the 'state' parameter are validated. CSRF token and the 'state' parameter are validated.
o If the client authenticates the user, either through a single sign o If the client authenticates the user, either through a single-
on protocol ( such as OpenID / Facebook Connect ) or through local sign-on protocol or through local authentication, the client
authentication, the client should suspend the access by a user should suspend the access by a user account if the number of
account if the number of invalid authorization codes submitted by invalid authorization codes submitted by this user exceeds a
this user exceeds a certain threshold. certain threshold.
o The authorization server should send an error response to the o The authorization server should send an error response to the
client reporting an invalid authorization code and rate limit or client reporting an invalid authorization code and rate limit or
disallow connections from clients whose number of invalid requests disallow connections from clients whose number of invalid requests
exceeds a threshold. exceeds a threshold.
o The authorization server may in addition sign the authorization
code using the public key from its SSL certificate, and require
the client to validate the signature. To enhance interoperability
between multiple clients and authorization servers, a standard
procedure to create and validate the signature (including what
attributes to sign) may be developed and agreed between the
clients and the servers.
4.4.2. Implicit Grant 4.4.2. Implicit Grant
In the implicit grant type flow, the access token is directly In the implicit grant type flow, the access token is directly
returned to the client as a fragment part of the redirection URI. It returned to the client as a fragment part of the redirection URI. It
is assumed that the token is not sent to the redirection URI target is assumed that the token is not sent to the redirection URI target
as HTTP user agents do not send the fragment part of URIs to HTTP as HTTP user agents do not send the fragment part of URIs to HTTP
servers. Thus an attacker cannot eavesdrop the access token on this servers. Thus an attacker cannot eavesdrop the access token on this
communication path and It cannot leak through HTTP referee headers. communication path and it cannot leak through HTTP referee headers.
4.4.2.1. Threat: Access token leak in transport/end-points 4.4.2.1. Threat: Access token leak in transport/end-points
This token might be eavesdropped by an attacker. The token is sent This token might be eavesdropped by an attacker. The token is sent
from server to client via a URI fragment of the redirection URI. If from server to client via a URI fragment of the redirection URI. If
the communication is not secured or the end-point is not secured, the the communication is not secured or the end-point is not secured, the
token could be leaked by parsing the returned URI. token could be leaked by parsing the returned URI.
Impact: the attacker would be able to assume the same rights granted Impact: the attacker would be able to assume the same rights granted
by the token. by the token.
Countermeasures: Countermeasures:
o The authorization server should ensure confidentiality of the o The authorization server should ensure confidentiality (e.g. using
response from the authorization server to the client (see TLS) of the response from the authorization server to the client
Section 5.1.1). (see Section 5.1.1).
4.4.2.2. Threat: Access token leak in browser history 4.4.2.2. Threat: Access token leak in browser history
An attacker could obtain the token from the browser's history. Note An attacker could obtain the token from the browser's history. Note
this means the attacker needs access to the particular device. this means the attacker needs access to the particular device.
Countermeasures: Countermeasures:
o Shorten token duration (see Section 5.1.5.3) and reduced scope of o 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 responses non-cachable
o Native applications can directly embed a browser widget and
therewith gain full control of the cache. So the application can
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. A malicious client could attempt to obtain a token by fraud.
The same countermeasures as for Section 4.4.1.4 are applicable, The same countermeasures as for Section 4.4.1.4 are applicable,
except client authentication. except client authentication.
4.4.2.4. Threat: Manipulation of scripts 4.4.2.4. Threat: Manipulation of scripts
A hostile party could act as the client web server and replace or A hostile party could act as the client web server and replace or
modify the actual implementation of the client (script). This could modify the actual implementation of the client (script). This could
be achieved using DNS or ARP spoofing. This applies to clients be achieved using DNS or ARP spoofing. This applies to clients
implemented within the Web Browser in a scripting language. implemented within the Web Browser in a scripting language.
skipping to change at page 36, line 31 skipping to change at page 36, line 31
altered in transport (see Section 5.1.1). altered in transport (see Section 5.1.1).
o Introduce one time per-use secrets (e.g. client_secret) values o Introduce one time per-use secrets (e.g. client_secret) values
that can only be used by scripts in a small time window once that can only be used by scripts in a small time window once
loaded from a server. The intention would be to reduce the loaded from a server. The intention would be to reduce the
effectiveness of copying client-side scripts for re-use in an effectiveness of copying client-side scripts for re-use in an
attackers modified code. attackers modified code.
4.4.2.5. Threat: CSRF attack against redirect-uri 4.4.2.5. Threat: CSRF attack against redirect-uri
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP CSRF attacks (see Section 4.4.1.8) also work against the redirection
requests are transmitted from a user that the website trusts or has URI used in the implicit grant flow. An attacker could acquire an
authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks access token to their own protected resources. He could then
on OAuth approvals can allow an attacker to obtain authorization to construct a redirection URI and embed their access token in that URI.
OAuth protected resources without the consent of the User. If he can trick the user into following the redirection URI and the
client does not have protection against this attack, the user may
This attack works against the redirection URI used in the implicit have the attacker's access token authorized within their client.
grant flow. An attacker could acquire an access token to their own
protected resources. He could then construct a redirection URI and
embed their access token in that URI. If he can trick the user into
following the redirection URI and the client does not have protection
against this attack, the user may have the attacker's access token
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 identity 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
access 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.
skipping to change at page 37, line 31 skipping to change at page 37, line 25
[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
limited by scope, but instead have potentially the same capabilities limited by scope, but instead have potentially the same capabilities
as the user themselves. As there is no authorization step, the as the user themselves. As there is no authorization step, the
ability to offer token revocation is bypassed. ability to offer token revocation is bypassed.
Because passwords are often used for more than 1 service, this anti-
pattern may also risk whatever else is accessible with the supplied
credential. Additionally any easily derived equivalent (e.g.
joe@example.com and joe@example.net) might easily allow someone to
guess that the same password can be used elsewhere.
Impact: The resource server can only differentiate scope based on the Impact: The resource server can only differentiate scope based on the
access token being associated with a particular client. The client access token being associated with a particular client. The client
could also acquire long-living tokens and pass them up to a attacker could also acquire long-living tokens and pass them up to a attacker
web service for further abuse. The client, eavesdroppers, or end- web service for further abuse. The client, eavesdroppers, or end-
points could eavesdrop user id and password. points could eavesdrop user id and password.
Countermeasures: Countermeasures:
o Except for migration reasons, minimize use of this grant type o Except for migration reasons, minimize use of this grant type
o The authorization server should validate the client id associated o The authorization server should validate the client id associated
with the particular refresh token with every refresh request - with the particular refresh token with every refresh request -
Section 5.2.2.2 Section 5.2.2.2
o As per the core Oauth spec, the authorization server must ensure o As per the core Oauth spec, the authorization server must ensure
that these transmissions are protected using transport-layer that these transmissions are protected using transport-layer
mechanisms such as TLS or SSL (see Section 5.1.1). mechanisms such as TLS (see Section 5.1.1).
o Rather than encouraging users to use a uid and password, service
providers should instead encourage users not to use the same
password for multiple services.
o Limit use of Resource Owner Password Credential grants to
scenarios where the client application and the authorizing service
are from the same organization.
4.4.3.1. Threat: Accidental exposure of passwords at client site 4.4.3.1. Threat: Accidental exposure of passwords at client site
If the client does not provide enough protection, an attacker or If the client does not provide enough protection, an attacker or
disgruntled employee could retrieve the passwords for a user. disgruntled employee could retrieve the passwords for a user.
Countermeasures: Countermeasures:
o Use other flows, which do not rely on the client's cooperation for o Use other flows, which do not rely on the client's cooperation for
secure resource owner credential handling secure resource owner credential handling
skipping to change at page 39, line 35 skipping to change at page 39, line 42
An attacker could attempt to eavesdrop the transmission of end-user An attacker could attempt to eavesdrop the transmission of end-user
credentials with the grant type "password" between client and server. credentials with the grant type "password" between client and server.
Impact: disclosure of a single end-users password. Impact: disclosure of a single end-users password.
Countermeasures: Countermeasures:
o Confidentiality of Requests - Section 5.1.1 o Confidentiality of Requests - Section 5.1.1
o alternative authentication means, which do not require to send o alternative authentication means, which do not require to send
plaintext credentials over the wire (Examples: Digest plaintext credentials over the wire (e.g. Hash-based Message
authentication) Authentication Code)
4.4.3.5. Threat: Obtain user passwords from authorization server 4.4.3.5. Threat: Obtain user passwords from authorization server
database database
An attacker may obtain valid username/password combinations from the An attacker may obtain valid username/password combinations from the
authorization server's database by gaining access to the database or authorization server's database by gaining access to the database or
launching a SQL injection attack. launching a SQL injection attack.
Impact: disclosure of all username/password combinations. The impact Impact: disclosure of all username/password combinations. The impact
may exceed the domain of the authorization server since many users may exceed the domain of the authorization server since many users
skipping to change at page 40, line 24 skipping to change at page 40, line 28
Countermeasures: Countermeasures:
o Password policy - Section 5.1.4.2.1 o Password policy - Section 5.1.4.2.1
o Lock accounts - Section 5.1.4.2.3 o Lock accounts - Section 5.1.4.2.3
o Tar pit - Section 5.1.4.2.4 o Tar pit - Section 5.1.4.2.4
o CAPTCHA - Section 5.1.4.2.5 o CAPTCHA - Section 5.1.4.2.5
o Abandon on grant type "password" o Consider not to use grant type "password"
o Client authentication (see Section 5.2.3) will provide another o Client authentication (see Section 5.2.3) will provide another
authentication factor and thus hinder the attack. authentication factor and thus hinder the attack.
4.4.4. Client Credentials 4.4.4. Client Credentials
Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an
identifier (not secret) combined with an additional means (such as a identifier (not secret) combined with an additional means (such as a
matching client secret) of authenticating a client. The threats to matching client secret) of authenticating a client. The threats to
this grant type are similar to Section 4.4.3. this grant type are similar to Section 4.4.3.
skipping to change at page 40, line 47 skipping to change at page 40, line 51
4.5.1. Threat: Eavesdropping refresh tokens from authorization server 4.5.1. Threat: Eavesdropping refresh tokens from authorization server
An attacker may eavesdrop refresh tokens when they are transmitted An attacker may eavesdrop refresh tokens when they are transmitted
from the authorization server to the client. from the authorization server to the client.
Countermeasures: Countermeasures:
o As per the core OAuth spec, the Authorization servers must ensure o As per the core OAuth spec, the Authorization servers must ensure
that these transmissions are protected using transport-layer that these transmissions are protected using transport-layer
mechanisms such as TLS or SSL (see Section 5.1.1). mechanisms such as TLS (see Section 5.1.1).
o If end-to-end confidentiality cannot be guaranteed, reducing scope o If end-to-end confidentiality cannot be guaranteed, reducing scope
(see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for
issued access tokens can be used to reduce the damage in case of issued access tokens can be used to reduce the damage in case of
leaks. leaks.
4.5.2. Threat: Obtaining refresh token from authorization server 4.5.2. Threat: Obtaining refresh token from authorization server
database database
This threat is applicable if the authorization server stores refresh This threat is applicable if the authorization server stores refresh
skipping to change at page 41, line 32 skipping to change at page 41, line 37
4.5.3. Threat: Obtain refresh token by online guessing 4.5.3. Threat: Obtain refresh token by online guessing
An attacker may try to guess valid refresh token values and send it An attacker may try to guess valid refresh token values and send it
using the grant type "refresh_token" in order to obtain a valid using the grant type "refresh_token" in order to obtain a valid
access token. access token.
Impact: exposure of single refresh token and derivable access tokens. Impact: exposure of single refresh token and derivable access tokens.
Countermeasures: Countermeasures:
o For handle-based designs - Section 5.1.5.11 o For handle-based designs - Section 5.1.4.2.2
o For assertion-based designs - Section 5.1.5.9 o For assertion-based designs - Section 5.1.5.9
o Bind token to client id, because the attacker would guess the o Bind token to client id, because the attacker would guess the
matching client id, too (see Section 5.1.5.8) matching client id, too (see Section 5.1.5.8)
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
skipping to change at page 42, line 22 skipping to change at page 42, line 26
between client and resource server. As access tokens are shared between client and resource server. As access tokens are shared
secrets between authorization and resource server, they should be secrets between authorization and resource server, they should be
treated with the same care as other credentials (e.g. end-user treated with the same care as other credentials (e.g. end-user
passwords). passwords).
Countermeasures: Countermeasures:
o Access tokens sent as bearer tokens, should not be sent in the o Access tokens sent as bearer tokens, should not be sent in the
clear over an insecure channel. As per the core OAuth spec, clear over an insecure channel. As per the core OAuth spec,
transmission of access tokens must be protected using transport- transmission of access tokens must be protected using transport-
layer mechanisms such as TLS or SSL (see Section 5.1.1). layer mechanisms such as TLS (see Section 5.1.1).
o A short lifetime reduces impact in case tokens are compromised o A short lifetime reduces impact in case tokens are compromised
(see Section 5.1.5.3). (see Section 5.1.5.3).
o The access token can be bound to a client's identity and require o The access token can be bound to a client's identifier and require
the client to prove legitimate ownership of the token to the the client to prove legitimate ownership of the token to the
resource server (see Section 5.4.2). resource server (see Section 5.4.2).
4.6.2. Threat: Replay authorized resource server requests 4.6.2. Threat: Replay authorized resource server requests
An attacker could attempt to replay valid requests in order to obtain An attacker could attempt to replay valid requests in order to obtain
or to modify/destroy user data. or to modify/destroy user data.
Countermeasures: Countermeasures:
o The resource server should utilize transport security measure in o The resource server should utilize transport security measures
order to prevent such attacks (see Section 5.1.1). This would (e.g. TLS) in order to prevent such attacks (see Section 5.1.1).
prevent the attacker from capturing valid requests. This would prevent the attacker from capturing valid requests.
o Alternatively, the resource server could employ signed requests o Alternatively, the resource server could employ signed requests
(see Section 5.4.3) along with nounces and timestamps in order to (see Section 5.4.3) along with nonces and timestamps in order to
uniquely identify requests. The resource server should detect and uniquely identify requests. The resource server should detect and
refuse every replayed request. refuse every replayed request.
4.6.3. Threat: Guessing access tokens 4.6.3. Threat: Guessing access tokens
Where the token is a handle, the attacker may use attempt to guess Where the token is a handle, the attacker may use attempt to guess
the access token values based on knowledge they have from other the access token values based on knowledge they have from other
access tokens. access tokens.
Impact: Access to a single user's data. Impact: Access to a single user's data.
Countermeasures: Countermeasures:
o Handle Tokens should have a reasonable entropy (see o Handle Tokens should have a reasonable entropy (see
Section 5.1.5.11) in order to make guessing a valid token value Section 5.1.4.2.2) in order to make guessing a valid token value
difficult. infeasible.
o Assertion (or self-contained token ) tokens contents should be o Assertion (or self-contained token ) tokens contents should be
protected by a digital signature (see Section 5.1.5.9). protected by a digital signature (see Section 5.1.5.9).
o Security can be further strengthened by using a short access token o Security can be further strengthened by using a short access token
duration (see Section 5.1.5.2 and Section 5.1.5.3). duration (see Section 5.1.5.2 and Section 5.1.5.3).
4.6.4. Threat: Access token phishing by counterfeit resource server 4.6.4. Threat: Access token phishing by counterfeit resource server
An attacker may pretend to be a particular resource server and to An attacker may pretend to be a particular resource server and to
accept tokens from a particular authorization server. If the client accept tokens from a particular authorization server. If the client
sends a valid access tokens to this counterfeit resource server, the sends a valid access token to this counterfeit resource server, the
server in turn may use that token to access other services on behalf server in turn may use that token to access other services on behalf
of the resource owner. of the resource owner.
Countermeasures: Countermeasures:
o Clients should not make authenticated requests with an access o Clients should not make authenticated requests with an access
token to unfamiliar resource servers, regardless of the presence token to unfamiliar resource servers, regardless of the presence
of a secure channel. If the resource server address is well-known of a secure channel. If the resource server URL is well-known to
to the client, it may authenticate the resource servers (see the client, it may authenticate the resource servers (see
Section 5.1.2). Section 5.1.2).
o Associate the endpoint address of the resource server the client o Associate the endpoint URL of the resource server the client
talked to with the access token (e.g. in an audience field) and talked to with the access token (e.g. in an audience field) and
validate association at legitimate resource server. The endpoint validate association at legitimate resource server. The endpoint
address validation policy may be strict (exact match) or more URL validation policy may be strict (exact match) or more relaxed
relaxed (e.g. same host). This would require to tell the (e.g. same host). This would require to tell the authorization
authorization server the resource server endpoint address in the server the resource server endpoint URL in the authorization
authorization process. process.
o Associate an access token with a client and authenticate the o Associate an access token with a client and authenticate the
client with resource server requests (typically via signature in client with resource server requests (typically via signature in
order to not disclose secret to a potential attacker). This order to not disclose secret to a potential attacker). This
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 lack the capability 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. Similarly, 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] relies on the Authorization and WWW-
Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Authenticate headers to distinguish authenticated content so that it
Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and can be protected. Proxies and caches, in particular, may fail to
WWW-Authenticate headers to distinguish authenticated content so that
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 Clients and resource servers not using the HTTP Authorization
HTTP Authorization Scheme - see Section 5.4.1) should take care to scheme (OAuth HTTP Authorization Scheme - see Section 5.4.1)
use other mechanisms, such as the Cache-Control header, to should take care to use Cache-Control headers to minimize the risk
minimize the risk that authenticated content is not protected. that authenticated content is not protected. Such Clients should
send a Cache-Control header containing the "no-store" option
[RFC2616]. Resource server success (2XX status) responses to
these requests should contain a Cache-Control header with the
"private" option [RFC2616].
o Reducing scope (see Section 5.1.5.1) and expiry time o Reducing scope (see Section 5.1.5.1) and expiry time
(Section 5.1.5.3) for access tokens can be used to reduce the (Section 5.1.5.3) for access tokens can be used to reduce the
damage in case of leaks. damage in case of leaks.
4.6.7. Threat: Token leakage via logfiles and HTTP referrers 4.6.7. Threat: Token leakage via logfiles and HTTP referrers
If access tokens are sent via URI query parameters, such tokens may If access tokens are sent via URI query parameters, such tokens may
leak to log files and HTTP referrers. leak to log files and the HTTP "referer".
Countermeasures: Countermeasures:
o Use authorization headers or POST parameters instead of URI o Use authorization headers or POST parameters instead of URI
request parameters (see Section 5.4.1). request parameters (see Section 5.4.1).
o Set logging configuration appropriately o Set logging configuration appropriately
o Prevent unauthorized persons from access to system log files (see o Prevent unauthorized persons from access to system log files (see
Section 5.1.4.1.1) Section 5.1.4.1.1)
o HTTP referrers can be prevented by reloading the target page again
without URI parameters
o Abuse of leaked access tokens can be prevented by enforcing o Abuse of leaked access tokens can be prevented by enforcing
authenticated requests (see Section 5.4.2). authenticated requests (see Section 5.4.2).
o The impact of token leakage may be reduced by limiting scope (see o The impact of token leakage may be reduced by limiting scope (see
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 The general section covers considerations that apply generally across
all OAuth components (client, resource server, token server, and all OAuth components (client, resource server, token server, and
user-agents). user-agents).
5.1.1. Confidentiality of Requests 5.1.1. Confidentiality of Requests
This is applicable to all requests sent from client to authorization This is applicable to all requests sent from client to authorization
server or resource server. While OAuth provides a mechanism for server or resource server. While OAuth provides a mechanism for
verifying the integrity of requests, it provides no guarantee of verifying the integrity of requests, it provides no guarantee of
request confidentiality. Unless further precautions are taken, request confidentiality. Unless further precautions are taken,
eavesdroppers will have full access to request content and may be eavesdroppers will have full access to request content and may be
able to mount interception or replay attacks through using content of able to mount interception or replay attacks through using content of
request, e.g. secrets or tokens. request, e.g. secrets or tokens.
Attacks can be mitigated by using transport-layer mechanisms such as Attacks can be mitigated by using transport-layer mechanisms such as
TLS or SSL. VPN may considered as well. TLS [RFC5246]. A virtual private network (VPN), e.g. based on IPsec
VPN [RFC4301], may considered as well.
Note: this document assumes end-to-end TLS protected connections
between the respective protocol entities. Deployments deviating from
this assumption by offloading TLS in between (e.g. on the data center
edge) must refine this threat model in order to account for the
additional (mainly insider) threat this may cause.
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
o Replay of authorization codes obtained on tokens endpoint o Replay of authorization codes obtained on tokens endpoint
(redirect?) (redirect?)
o Replay of user passwords and client secrets o Replay of user passwords and client secrets
5.1.2. Server authentication 5.1.2. 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 fully qualified domain name of the server to the public key
during connection establishment. presented by the server during connection establishment (see
[RFC2818]).
The client should validate the binding of the server to its domain The client should validate the binding of the server to its domain
name. If the server fails to prove that binding, it is considered a name. If the server fails to prove that binding, it is considered a
man-in-the-middle attack. The security measure depends on the man-in-the-middle attack. The security measure depends on the
certification authorities the client trusts for that purpose. certification authorities the client trusts for that purpose.
Clients should carefully select those trusted CAs and protect the Clients should carefully select those trusted CAs and protect the
storage for trusted CA certificates from modifications. storage for trusted CA certificates from modifications.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
skipping to change at page 46, line 40 skipping to change at page 47, line 4
protocol. The user should always be in control of the authorization protocol. The user should always be in control of the authorization
processes and get the necessary information to meet informed processes and get the necessary information to meet informed
decisions. Moreover, user involvement is a further security decisions. Moreover, user involvement is a further security
countermeasure. The user can probably recognize certain kinds of countermeasure. The user can probably recognize certain kinds of
attacks better than the authorization server. Information can be attacks better than the authorization server. Information can be
presented/exchanged during the authorization process, after the presented/exchanged during the authorization process, after the
authorization process, and every time the user wishes to get informed authorization process, and every time the user wishes to get informed
by using techniques such as: by using techniques such as:
o User consent forms o User consent forms
o Notification messages (e.g. e-Mail, SMS, ...). Note that
o Notification messages (e-Mail, SMS, ...) notifications can be a phishing vector. Messages should be such
that look-alike phishing messages cannot be derived from them.
o Activity/Event logs o Activity/Event logs
o User self-care applications or portals o User self-care applications or portals
5.1.4. Credentials 5.1.4. Credentials
This sections describes countermeasures used to protect all kinds of This sections describes countermeasures used to protect all kinds of
credentials from unauthorized access and abuse. Credentials are long credentials from unauthorized access and abuse. Credentials are long
term secrets, such as client secrets and user passwords as well as term secrets, such as client secrets and user passwords as well as
all kinds of tokens (refresh and access token) or authorization all kinds of tokens (refresh and access token) or authorization
codes. codes.
5.1.4.1. Credential Storage Protection 5.1.4.1. Credential Storage Protection
Administrators should undertake industry best practices to protect Administrators should undertake industry best practices to protect
the storage of credentials. Such practices may include but are not the storage of credentials (see for example [owasp]). Such practices
limited to the following sub-sections. may include but are not limited to the following sub-sections.
5.1.4.1.1. Standard System Security Means 5.1.4.1.1. Standard System Security Means
A server system may be locked down so that no attacker may get access A server system may be locked down so that no attacker may get access
to sensible configuration files and databases. to sensible configuration files and databases.
5.1.4.1.2. Standard SQL Injection Countermeasures 5.1.4.1.2. 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
skipping to change at page 47, line 39 skipping to change at page 48, line 7
o When using dynamic SQL, parameterize queries using bind arguments. o When using dynamic SQL, parameterize queries using bind arguments.
Bind arguments eliminate possibility of SQL injections. Bind arguments eliminate possibility of SQL injections.
o Filter and sanitize the input. For example, if an identifier has o Filter and sanitize the input. For example, if an identifier has
a known format, ensure that the supplied value matches the a known format, ensure that the supplied value matches the
identifier syntax rules. identifier syntax rules.
5.1.4.1.3. No cleartext storage of credentials 5.1.4.1.3. No cleartext storage of credentials
The authorization server should not store credential in clear text. The authorization server should not store credentials in clear text.
Typical approaches are to store hashes instead. If the credential Typical approaches are to store hashes instead or to encrypt
lacks a reasonable entropy level (because it is a user password) an credentials. If the credential lacks a reasonable entropy level
additional salt will harden the storage to prevent offline dictionary (because it is a user password) an additional salt will harden the
attacks. Note: Some authentication protocols require the storage to make offline dictionary attacks more difficult.
authorization server to have access to the secret in the clear.
Those protocols cannot be implemented if the server only has access Note: Some authentication protocols require the authorization server
to hashes. to have access to the secret in the clear. Those protocols cannot be
implemented if the server only has access to hashes. Credentials
should strongly encrypted in those cases.
5.1.4.1.4. Encryption of credentials 5.1.4.1.4. Encryption of credentials
For client applications, insecurely persisted client credentials are For client applications, insecurely persisted client credentials are
easy targets for attackers to obtain. Store client credentials using easy targets for attackers to obtain. Store client credentials using
an encrypted persistence mechanism such as a keystore or database. an encrypted persistence mechanism such as a keystore or database.
Note that compiling client credentials directly into client code Note that compiling client credentials directly into client code
makes client applications vulnerable to scanning as well as difficult makes client applications vulnerable to scanning as well as difficult
to administer should client credentials change over time. to administer should client credentials change over time.
5.1.4.1.5. Use of asymmetric cryptography 5.1.4.1.5. Use of asymmetric cryptography
Usage of asymmetric cryptography will free the authorization server Usage of asymmetric cryptography will free the authorization server
of the obligation to manage credentials. of the obligation to manage credentials.
5.1.4.2. Online attacks on secrets 5.1.4.2. Online attacks on secrets
5.1.4.2.1. Password policy 5.1.4.2.1. Password policy
The authorization server may decide to enforce a complex user The authorization server may decide to enforce a complex user
password policy in order to increase the user passwords' entropy. password policy in order to increase the user passwords' entropy to
This will hinder online password attacks. hinder online password attacks. Note that too much complexity can
increase the liklihood that users re-use passwords or write them down
or otherwise store them insecurely.
5.1.4.2.2. High entropy of secrets 5.1.4.2.2. High entropy of secrets
When creating token handles or other secrets not intended for usage When creating secrets not intended for usage by human users (e.g.
by human users, the authorization server should include a reasonable client secrets or token handles), the authorization server should
level of entropy in order to mitigate the risk of guessing attacks. include a reasonable level of entropy in order to mitigate the risk
of guessing attacks. The token value should be >=128 bits long and
The token value should be constructed from a cryptographically strong constructed from a cryptographically strong random or pseudo-random
random or pseudo-random number sequence [RFC1750] generated by the number sequence (see [RFC4086] for best current practice) generated
Authorization Server. The probability of any two Authorization Code by the Authorization Server.
values being identical should be less than or equal to 2^(-128) and
should be less than or equal to 2^(-160).
5.1.4.2.3. Lock accounts 5.1.4.2.3. Lock accounts
Online attacks on passwords can be mitigated by locking the Online attacks on passwords can be mitigated by locking the
respective accounts after a certain number of failed attempts. respective accounts after a certain number of failed attempts.
Note: This measure can be abused to lock down legitimate service Note: This measure can be abused to lock down legitimate service
users. users.
5.1.4.2.4. Tar pit 5.1.4.2.4. Tar pit
skipping to change at page 49, line 17 skipping to change at page 49, line 36
The idea is to prevent programs from automatically checking huge The idea is to prevent programs from automatically checking huge
number of passwords by requiring human interaction. number of passwords by requiring human interaction.
Note: this has a negative impact on user experience. Note: this has a negative impact on user experience.
5.1.5. Tokens (access, refresh, code) 5.1.5. Tokens (access, refresh, code)
5.1.5.1. Limit token scope 5.1.5.1. Limit token scope
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. The 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
public 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 sensitive 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 grant 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
skipping to change at page 49, line 48 skipping to change at page 50, line 18
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
5.1.5.2. Expiration time 5.1.5.2. Expiration time
Tokens should generally expire after a reasonable duration. This Tokens should generally expire after a reasonable duration. This
complements and strengthens other security measures (such as complements and strengthens other security measures (such as
signatures) and reduces the impact of all kinds of token leaks. signatures) and reduces the impact of all kinds of token leaks.
Depending on the risk associated with a token leakage, tokens may
expire after a few minutes (e.g. for payment transactions) or stay
valid for hours (e.g. read access to contacts).
The expiration time is determined by a couple of factors, including:
o risk associated to a token leakage
o duration of the underlying access grant,
o duration until the modification of an access grant should take
effect, and
o time required for an attacker to guess or produce valid token.
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 likelihood of successful online guessing o reduce likelihood of successful online guessing
Note: Short token duration requires preciser clock synchronisation Note: Short token duration requires more precise clock
between authorization server and resource server. Furthermore, synchronisation between authorization server and resource server.
shorter duration may require more token refreshments (access token) Furthermore, shorter duration may require more token refreshes
or repeated end-user authorization processes (authorization code and (access token) or repeated end-user authorization processes
refresh token). (authorization code and 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 requests or The authorization server may restrict the number of requests or
operations which can be performed with a certain token. This operations which can be performed with a certain token. This
mechanism can be used to mitigate the following threats: mechanism can be used to mitigate the following threats:
o replay of tokens o replay of tokens
o reduce likelihood of successful online guessing o guessing
For example, if an Authorization Server observes more than one For example, if an Authorization Server observes more than one
attempt to redeem a authorization code, the Authorization Server may attempt to redeem an authorization code, the Authorization Server may
want to revoke all access tokens granted based on the authorization want to revoke all access tokens granted based on the authorization
code as well as reject the current request. code as well as reject the current request.
As with the authorization code, access tokens may also have a limited As with the authorization code, access tokens may also have a limited
number of operations. This forces client applications to either re- number of operations. This forces client applications to either re-
authenticate and use a refresh token to obtain a fresh access token, authenticate and use a refresh token to obtain a fresh access token,
or it forces the client to re-authorize the access token by involving or it forces the client to re-authorize the access token by involving
the user. the user.
5.1.5.5. Bind tokens to a particular resource server (Audience) 5.1.5.5. Bind tokens to a particular resource server (Audience)
Authorization servers in multi-service environments may consider Authorization servers in multi-service environments may consider
issuing tokens with different content to different resource servers issuing tokens with different content to different resource servers
and to explicitly indicate in the token the target server a token is and to explicitly indicate in the token the target server a token is
intended to be sent to (see Audience in SAML Assertions). This intended to be sent to. SAML Assertions (see
countermeasure can be used in the following situations: [OASIS.saml-core-2.0-os]) use the Audience element for this purpose.
This countermeasure can be used in the following situations:
o It reduces the impact of a successful replay attempt, since the o It reduces the impact of a successful replay attempt, since the
token is applicable to a single resource server, only. token is applicable to a single resource server, only.
o It prevents abuse of a token by a rough resource server or client, o It prevents abuse of a token by a rogue 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 reduces the impact of a leakage of a valid token to a o It reduces the impact of a leakage of a valid token to a
counterfeit resource server. counterfeit resource server.
5.1.5.6. Use endpoint address as token audience 5.1.5.6. Use endpoint address as token audience
This may be used to indicate to a resource server, which endpoint This may be used to indicate to a resource server, which endpoint URL
address has been used to obtain the token. This measure will allow has been used to obtain the token. This measure will allow to detect
to detect requests from a counterfeit resource server, since such requests from a counterfeit resource server, since such token will
token will contain the endpoint address of that server. contain the endpoint URL of that server.
5.1.5.7. Audience and Token scopes 5.1.5.7. Audience and Token scopes
Deployments may consider only using tokens with explicitly defined Deployments may consider only using tokens with explicitly defined
scope, where every scope is associated with a particular resource scope, where every scope is associated with a particular resource
server. This approach can be used to mitigate attacks, where a server. This approach can be used to mitigate attacks, where a
resource server or client uses a token for a different then the resource server or client uses a token for a different then the
intended purpose. intended purpose.
5.1.5.8. Bind token to client id 5.1.5.8. Bind token to client id
An authorization server may bind a token to a certain client An authorization server may bind a token to a certain client
identity. This identity should be validated for every request with identifier. This identifier should be validated for every request
that token. This means can be used, to with that token. This means can be used, to
o detect token leakage and o detect token leakage and
o prevent token abuse. o prevent token abuse.
Note: Validating the client identity may require the target server to Note: Validating the client identifier may require the target server
authenticate the client's identity. This authentication can be based to authenticate the client's identifier. This authentication can be
on secrets managed independent of the token (e.g. pre-registered based on secrets managed independent of the token (e.g. pre-
client id/secret on authorization server) or sent with the token registered client id/secret on authorization server) or sent with the
itself (e.g. as part of the encrypted token content). token itself (e.g. as part of the encrypted token content).
5.1.5.9. Signed tokens 5.1.5.9. Signed tokens
Self-contained tokens should be signed in order to detect any attempt Self-contained tokens should be signed in order to detect any attempt
to modify or produce faked tokens. to modify or produce faked tokens (e.g. Hash-based Message
Authentication Code or digital signatures)
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 tokens may be encrypted for confidentiality reasons or
system internal data. to protect system internal data. Depending on token format, keys
(e.g. symmetric keys) may have to be distributed between server
5.1.5.11. Random token value with high entropy nodes. The method of distribution should be defined by the token and
encryption used.
When creating token handles, the authorization server should include
a reasonable level of entropy in order to mitigate the risk of
guessing attacks. The token value should be constructed from a
cryptographically strong random or pseudo-random number sequence
[RFC4086] generated by the Authorization Server. The probability of
any two token values being identical should be less than or equal to
2^(-128) and should be less than or equal to 2^(-160).
5.1.5.12. Assertion formats 5.1.5.11. Assertion formats
For service providers intending to implement an assertion-based token For service providers intending to implement an assertion-based token
design it is highly recommended to adopt a standard assertion format design it is highly recommended to adopt a standard assertion format
(such as SAML or JWT) that implements [draft-ietf-oauth-assertions]. (such as SAML [OASIS.saml-core-2.0-os] or JWT
[I-D.ietf-oauth-json-web-token].
5.1.6. Access tokens 5.1.6. Access tokens
The following measures should be used to protect access tokens The following measures should be used to protect access tokens
o keep them in transient memory (accessible by the client o keep them in transient memory (accessible by the client
application only) application only)
o protect from exposure to 3rd parties (malicious application) o Pass tokens securely using secure transport (TLS)
o limit number of access tokens granted to a user o Ensure client applications do not share tokens with 3rd parties
5.2. Authorization Server 5.2. Authorization Server
This section describes considerations related to the OAuth This section describes considerations related to the OAuth
Authorization Server end-point. 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
skipping to change at page 53, line 7 skipping to change at page 53, line 42
5.2.2.1. Restricted issuance of refresh tokens 5.2.2.1. Restricted issuance of refresh tokens
The authorization server may decide based on an appropriate policy The authorization server may decide based on an appropriate policy
not to issue refresh tokens. Since refresh tokens are long term not to issue refresh tokens. Since refresh tokens are long term
credentials, they may be subject theft. For example, if the credentials, they may be subject theft. For example, if the
authorization server does not trust a client to securely store such authorization server does not trust a client to securely store such
tokens, it may refuse to issue such a client a refresh token. tokens, it may refuse to issue such a client a refresh token.
5.2.2.2. Binding of refresh token to client_id 5.2.2.2. Binding of refresh token to client_id
The authorization server should bind every refresh token to the id of The authorization server should match every refresh token to the
the client such a token was originally issued to and validate this identifier of the client to whom it was issued. The authorization
binding for every request to refresh that token. If possible (e.g. server should check that the same client_id is present for every
confidential clients), the authorization server should authenticate request to refresh the access token. If possible (e.g. confidential
the respective client. clients), the authorization server should authenticate the respective
client.
This is a countermeasure against refresh token theft or leakage. This is a countermeasure against refresh token theft or leakage.
Note: This binding should be protected from unauthorized Note: This binding should be protected from unauthorized
modifications. modifications.
5.2.2.3. Refresh Token Rotation 5.2.2.3. Refresh Token Rotation
Refresh token rotation is intended to automatically detect and Refresh token rotation is intended to automatically detect and
prevent attempts to use the same refresh token in parallel from prevent attempts to use the same refresh token in parallel from
skipping to change at page 54, line 4 skipping to change at page 54, line 38
The authorization server may allow clients or end-users to explicitly The authorization server may allow clients or end-users to explicitly
request the invalidation of refresh tokens. A mechanism to revoke request the invalidation of refresh tokens. A mechanism to revoke
tokens is specified in [I-D.ietf-oauth-revocation]. tokens is specified in [I-D.ietf-oauth-revocation].
This is a countermeasure against: This is a countermeasure against:
o device theft, o device theft,
o impersonation of resource owner, or o impersonation of resource owner, or
o suspected compromised client applications. o suspected compromised client applications.
5.2.2.5. Device identification 5.2.2.5. Device identification
The authorization server may require to bind authentication The authorization server may require to bind authentication
credentials to a device identifier. The IMEI is one example of such credentials to a device identifier. The _International Mobile
an identifier, there are also operating system specific identifiers. Station Equipment Identity_ [IMEI] is one example of such an
identifier, there are also operating system specific identifiers.
The authorization server could include such an identifier when The authorization server could include such an identifier when
authenticating user credentials in order to detect token theft from a authenticating user credentials in order to detect token theft from a
particular device. particular device.
Note: Any implementation should consider potential privacy
implications of using device identifiers.
5.2.2.6. X-FRAME-OPTION header 5.2.2.6. X-FRAME-OPTION header
For newer browsers, avoidance of iFrames can be enforced server side For newer browsers, avoidance of iFrames can be enforced server side
by using the X-FRAME-OPTION header. This header can have two values, by using the X-FRAME-OPTION header (see
deny and same origin, which will block any framing or framing by [I-D.gondrom-x-frame-options]). This header can have two values,
sites with a different origin, respectively. "DENY" and "SAMEORIGIN", which will block any framing or framing by
sites with a different origin, respectively. The value "ALLOW-FROM"
allows iFrames for a list of trusted origins.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o Clickjacking attacks o Clickjacking attacks
5.2.3. Client authentication and authorization 5.2.3. Client authentication and authorization
As described in Section 3 (Security Features), clients are As described in Section 3 (Security Features), clients are
identified, authenticated and authorized for several purposes, such identified, authenticated and authorized for several purposes, such
as a as a
o Collate sub-sequent requests to the same client, o Collate requests to the same client,
o Indicate the trustworthiness of a particular client to the end- o Indicate to the user the client is recognized by the authorization
user, server,
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 identifier to log files for analysis or statistics.
Due to the different capabilities and characteristics 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 these
objectives, which will be described in this section. Authorization objectives, which will be described in this section. Authorization
server providers should be aware of the security policy and server providers should be aware of the security policy and
deployment of a particular clients and adapt its treatment deployment of a particular clients and adapt its treatment
accordingly. For example, one approach could be to treat all clients accordingly. For example, one approach could be to treat all clients
as less trustworthy and unsecure. On the other extreme, a service as less trustworthy and unsecure. On the other extreme, a service
provider could activate every client installation by hand of an provider could activate every client installation individually by 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 public clients or clients with 5.2.3.1. Don't issue secrets to client with inappropriate security
inappropriate security policy policy
Authorization servers should not issue secrets to "public" clients Authorization servers should not issue secrets to clients that cannot
that cannot protect secrets. This prevents the server from protect secrets ("public" clients). This reduces probability of the
overestimating the value of a successful authentication of the server treating the client as strongly authenticated.
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 and secret which is shared by all installations of a native
application. Such a scenario requires that this secret must be application. Such a scenario requires that this secret must be
transmitted from the developer via the respective distribution transmitted from the developer via the respective distribution
channel, e.g. an application market, to all installations of the channel, e.g. an application market, to all installations of the
application on end-user devices. A secret, burned into the source application on end-user devices. A secret, burned into the source
code of the application or a associated resource bundle, cannot be code of the application or a associated resource bundle, is not
entirely protected from reverse engineering. Secondly, such secrets protected from reverse engineering. Secondly, such secrets cannot be
cannot be revoked since this would immediately put all installations revoked since this would immediately put all installations out of
out of work. Moreover, since the authorization server cannot really work. Moreover, since the authorization server cannot really trust
trust on the client's identity, it would be dangerous to indicate to the client's identifier, it would be dangerous to indicate to end-
end-users the trustworthiness of the client. users the trustworthiness of the client.
There are other ways to achieve a reasonable security level, as There are other ways to achieve a reasonable security level, as
described in the following sections. described in the following sections.
5.2.3.2. Public clients without secret require user consent 5.2.3.2. Public clients without secret require user consent
Authorization servers should not allow automatic authorization for Authorization servers should not allow automatic authorization for
public clients. The authorization may issue a client id, but should public clients. The authorization may issue an individual client id,
require that all authorizations are approved by the end-user. This but should require that all authorizations are approved by the end-
is a countermeasure for clients without secret against the following user. This is a countermeasure for clients without secret against
threats: the following threats:
o Impersonation of public client applications o Impersonation of public client applications
5.2.3.3. Client_id only in combination with redirect_uri 5.2.3.3. Client_id only in combination with redirect_uri
The authorization may issue a client_id and bind the client_id to a The authorization may issue a client_id and bind the client_id to a
certain pre-configured redirect_uri. Any authorization request with certain pre-configured redirect_uri. Any authorization request with
another redirection URI is refused automatically. Alternatively, the another redirection URI is refused automatically. Alternatively, the
authorization server should not accept any dynamic redirection URI authorization server should not accept any dynamic redirection URI
for such a client_id and instead always redirect to the well-known for such a client_id and instead always redirect to the well-known
pre-configured redirection URI. This is a countermeasure for clients pre-configured redirection URI. This is a countermeasure for clients
without secrets against the following threats: without secrets against the following threats:
o Cross-site scripting attacks o Cross-site scripting attacks
o Impersonation of public client applications o Impersonation of public client applications
5.2.3.4. Deployment-specific client secrets 5.2.3.4. Installation-specific client secrets
A authorization server may issue separate client identifiers and An authorization server may issue separate client identifiers and
corresponding secrets to the different deployments of a client. The corresponding secrets to the different installations of a particular
effect of such an approach would be to turn otherwise "public" client (i.e. software package). The effect of such an approach would
clients back into "confidential" clients. 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 redirection URI, address, and whatever proofs useful. site, such as redirection URI, website URL, and whatever proofs
The web site provider has to ensure the security of the client secret useful. The web site provider has to ensure the security of the
on the site. client secret on the site.
For native applications, things are more complicated because every For native applications, things are more complicated because every
installation of the application on any device is another deployment. copy of a particular application on any device is a different
Deployment specific secrets will require installation. Installation-specific secrets in this scenario 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 application 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 certain level of trust in
authenticated and identified, whereas the second option only allows the authenticity of the application, whereas the second option only
to authenticate the client but not to validate properties of the allows to authenticate the installation but not to validate
client. But this would at least help to prevent several replay properties of the client. But this would at least help to prevent
attacks. Moreover, deployment-specific client_id and secret allow to several replay attacks. Moreover, installation-specific client_id
selectively revoke all refresh tokens of a specific deployment at and secret allow to selectively revoke all refresh tokens of a
once. specific installation at once.
5.2.3.5. Validation of pre-registered redirect_uri 5.2.3.5. Validation of pre-registered redirect_uri
An authorization server should require all clients to register their An authorization server should require all clients to register their
redirect_uri and the redirect_uri should be the full URI as defined redirect_uri and the redirect_uri should be the full URI as defined
in [I-D.ietf-oauth-v2]. The way this registration is performed is in [I-D.ietf-oauth-v2]. The way this registration is performed is
out of scope of this document. As per the core spec, every actual out of scope of this document. As per the core spec, every actual
redirection URI sent with the respective client_id to the end-user redirection URI sent with the respective client_id to the end-user
authorization endpoint must match the registered redirection URI. authorization endpoint must match the registered redirection URI.
Where it does not match, the authorization server should assume the Where it does not match, the authorization server should assume the
inbound GET request has been sent by an attacker and refuse it. inbound GET request has been sent by an attacker and refuse it.
Note: the authorization server should not redirect the user agent Note: the authorization server should not redirect the user agent
back to the redirection URI of such an authorization request. back to the redirection URI of such an authorization request.
Validating the pre-registered redirect_uri is a countermeasure
against the following threats:
o Authorization code leakage through counterfeit web site: allows to o Authorization code leakage through counterfeit web site: allows to
detect attack attempts already after first redirect to end-user detect attack attempts already after first redirect to end-user
authorization endpoint (Section 4.4.1.7). authorization endpoint (Section 4.4.1.7).
o For clients with validated properties, this measure also helps to
detect malicious applications early in the end-user authorization
process. This reduces the need for a interactive validation by
the user (Section 4.4.1.4, Section 4.4.2.3).
o Open Redirector attack via client redirection endpoint. ( o Open Redirector attack via client redirection endpoint. (
Section 4.1.5. ) Section 4.1.5. )
o Open Redirector phishing attack via authorization server o Open Redirector phishing attack via authorization server
redirection endpoint ( Section 4.2.4 ) redirection endpoint ( Section 4.2.4 )
The underlying assumption of this measure is that an attacker will The underlying assumption of this measure is that an attacker will
need to use another redirection URI in order to get access to the need to use another redirection URI in order to get access to the
authorization code. Deployments might consider the possibility of an authorization code. Deployments might consider the possibility of an
attacker using spoofing attacks to a victims device to circumvent attacker using spoofing attacks to a victims device to circumvent
this security measure. this security measure.
Note: Pre-registering clients might not scale in some deployments Note: Pre-registering clients might not scale in some deployments
(manual process) or require dynamic client registration (not (manual process) or require dynamic client registration (not
specified yet). With the lack of dynamic client registration, it specified yet). With the lack of dynamic client registration, pre-
only works for clients bound to certain deployments at development/ registered "redirect_uri" only works for clients bound to certain
configuration time. As soon as dynamic resource server discovery deployments at development/configuration time. As soon as dynamic
gets involved, that's no longer feasible. resource server discovery is required, the pre-registered
redirect_uri may be 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 impact client identifiers and secrets used across
multiple deployments of a particular native or web application. multiple deployments of a particular native or web application.
This a countermeasure against: This a countermeasure against:
o Abuse of revealed client secrets for private clients o Abuse of revealed client secrets for private clients
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)
By using an alternative form of authentication such as client By using an alternative form of authentication such as client
assertion [draft-ietf-oauth-assertions], the need to distribute assertion [I-D.ietf-oauth-assertions], the need to distribute a
client_secret is eliminated. This may require the use of a secure client_secret is eliminated. This may require the use of a secure
private key store or other supplemental authentication system as private key store or other supplemental authentication system as
specified by the client assertion issuer in its authentication specified by the client assertion issuer in its authentication
process. process.
5.2.4. End-user authorization 5.2.4. End-user authorization
This secion involves considerations for authorization flows involving This secion involves considerations for authorization flows involving
the end-user. the end-user.
5.2.4.1. Automatic processing of repeated authorizations requires 5.2.4.1. Automatic processing of repeated authorizations requires
client validation client validation
Authorization servers should NOT automatically process repeat Authorization servers should NOT automatically process repeat
authorizations where the client is not authenticated through a client authorizations where the client is not authenticated through a client
secret or some other authentication mechanism such as signing with secret or some other authentication mechanism such as a signed
security certificates (5.7.2.7. Use strong client authentication authentication assertion certificate (Section 5.2.3.7 Use strong
(e.g. client_assertion / client_token)) or validation of a pre- client authentication (e.g. client_assertion / client_token)) or
registered redirect URI (5.7.2.5. Validation of pre-registered validation of a pre-registered redirect URI (Section 5.2.3.5
redirection URI ). 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 should clearly explain to the end-user what The authorization server should clearly explain to the end-user what
happens in the authorization process and what the consequences are. happens in the authorization process and what the consequences are.
For example, the user should understand what access he is about to For example, the user should understand what access he is about to
grant to which client for what duration. It should also be obvious grant to which client for what duration. It should also be obvious
to the user, whether the server is able to reliably certify certain to the user, whether the server is able to reliably certify certain
client properties (web site address, security policy). client properties (web site URL, security policy).
5.2.4.3. Validation of client properties by end-user 5.2.4.3. Validation of client properties by end-user
In the authorization process, the user is typically asked to approve In the authorization process, the user is typically asked to approve
a client's request for authorization. This is an important security a client's request for authorization. This is an important security
mechanism by itself because the end-user can be involved in the mechanism by itself because the end-user can be involved in the
validation of client properties, such as whether the client name validation of client properties, such as whether the client name
known to the authorization server fits the name of the web site or known to the authorization server fits the name of the web site or
the application the end-user is using. This measure is especially the application the end-user is using. This measure is especially
helpful in all situation where the authorization server is unable to helpful in situations where the authorization server is unable to
authenticate the client. It is a countermeasure against: authenticate the client. It is a countermeasure against:
o Malicious application o Malicious application
o A client application masquerading as another client o A client application masquerading as another client
5.2.4.4. Binding of authorization code to client_id 5.2.4.4. Binding of authorization code to client_id
The authorization server should bind every authorization code to the The authorization server should bind every authorization code to the
id of the respective client which initiated the end-user id of the respective client which initiated the end-user
authorization process. This measure is a countermeasure against: authorization process. This measure is a countermeasure against:
o replay of authorization codes with different client credentials o replay of authorization codes with different client credentials
since an attacker cannot use another client_id to exchange an since an attacker cannot use another client_id to exchange an
authorization code into a token authorization code into a token
o Online guessing of authorization codes o Online guessing of authorization codes
Note: This binding should be protected from unauthorized Note: This binding should be protected from unauthorized
modifications. modifications (e.g. using protected memory and/or a secure database).
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 should bind every authorization code to the The authorization server should be able to bind every authorization
actual redirection URI used as redirect target of the client in the code to the actual redirection URI used as redirect target of the
end-user authorization process. This binding should be validated client in the end-user authorization process. This binding should be
when the client attempts to exchange the respective authorization validated when the client attempts to exchange the respective
code for an access token. This measure is a countermeasure against authorization code for an access token. This measure is a
authorization code leakage through counterfeit web sites since an countermeasure against authorization code leakage through counterfeit
attacker cannot use another redirection URI to exchange an web sites since an attacker cannot use another redirection URI to
authorization code into a token. exchange an authorization code into a token.
5.3. Client App Security 5.3. Client App Security
This section deals with considerations for client applications. This section deals with considerations for client applications.
5.3.1. Don't store credentials in code or resources bundled with 5.3.1. Don't store credentials in code or resources bundled with
software packages software packages
Because of the numbers of copies of client software, there is limited 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 benefit to create a single client id and secret which is shared by
all installations of an application. Such an application by itself all installations of an application. Such an application by itself
would be considered a "public" client as it cannot be presumed to be 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 able to keep client secrets. A secret, burned into the source code
of the application or a associated resource bundle, cannot be of the application or an associated resource bundle, cannot be
entirely protected from reverse engineering. Secondly, such secrets protected from reverse engineering. Secondly, such secrets cannot be
cannot be revoked since this would immediately put all installations revoked since this would immediately put all installations out of
out of work. Moreover, since the authorization server cannot really work. Moreover, since the authorization server cannot really trust
trust on the client's identity, it would be dangerous to indicate to the client's identifier, it would be dangerous to indicate to end-
end-users the trustworthiness of the client. users the trustworthiness of the client.
5.3.2. Standard web server protection measures (for config files and 5.3.2. Standard web server protection measures (for config files and
databases) databases)
Use standard web server protection measures - Section 5.3.2 Use standard web server protection measures - Section 5.3.2
5.3.3. Store secrets in a secure storage 5.3.3. Store secrets in a secure storage
The are different way to store secrets of all kinds (tokens, client The are different way to store secrets of all kinds (tokens, client
secrets) securely on a device or server. secrets) securely on a device or server.
Most multi-user operation systems segregate the personal storage of Most multi-user operating systems segregate the personal storage of
the different system users. Moreover, most modern smartphone the different system users. Moreover, most modern smartphone
operating systems even support to store app-specific data in separate operating systems even support to store app-specific data in separate
areas of the file systems and protect it from access by other areas of the file systems and protect it from access by other
applications. Additionally, applications can implements confidential applications. Additionally, applications can implements confidential
data itself using a user-supplied secret, such as PIN or password. data itself using a user-supplied secret, such as PIN or password.
Another option is to swap refresh token storage to a trusted backend Another option is to swap refresh token storage to a trusted backend
server. This mean in turn requires a resilient authentication server. This mean in turn requires a resilient authentication
mechanisms between client and backend server. Note: Applications mechanisms between client and backend server. Note: Applications
should ensure that confidential data is kept confidential even after should ensure that confidential data is kept confidential even after
reading from secure storage, which typically means to keep this data reading from secure storage, which typically means to keep this data
in the local memory of the application. in the local memory of the application.
5.3.4. Utilize device lock to prevent unauthorized device access 5.3.4. Utilize device lock to prevent unauthorized device access
On a typical modern phone, there are many "device lock" options which On a typical modern phone, there are many "device lock" options which
can be utilized to provide additional protection where a device is can be utilized to provide additional protection where a device is
stolen or misplaced. These include PINs, passwords and other stolen or misplaced. These include PINs, passwords and other
biomtric featres such as "face recognition". These are not equal in biomtric featres such as "face recognition". These are not equal in
their level of security they provide. the level of security they provide.
5.3.5. Platform security measures
o Validation process
o software package signatures
o Remote removal
5.3.6. Link state parameter to user agent session 5.3.5. Link state parameter to user agent session
The state parameter is used to link client requests and prevent CSRF The state parameter is used to link client requests and prevent CSRF
attacks, for example against the redirection URI. An attacker could attacks, for example against the redirection URI. An attacker could
inject their own authorization code or access token, which can result inject their own authorization code or access token, which can result
in the client using an access token associated with the attacker's in the client using an access token associated with the attacker's
protected resources rather than the victim's (e.g. save the victim's protected resources rather than the victim's (e.g. save the victim's
bank account information to a protected resource controlled by the bank account information to a protected resource controlled by the
attacker). attacker).
The client should utilize the "state" request parameter to send the The client should utilize the "state" request parameter to send the
skipping to change at page 61, line 34 skipping to change at page 62, line 9
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 identity An authorization server may bind tokens to a certain client
and encourage resource servers to validate that binding. This will identifier and enable resource servers to be able to validate that
require the resource server to authenticate the originator of a association on resource access. This will require the resource
request as the legitimate owner of a particular token. There are a server to authenticate the originator of a request as the legitimate
couple of options to implement this countermeasure: owner of a particular token. There are a couple of options to
implement this countermeasure:
o The authorization server may associate the distinguished name of o The authorization server may associate the client identifier with
the client with the token (either internally or in the payload of the token (either internally or in the payload of an self-
an self-contained token). The client then uses client contained token). The client then uses client certificate-based
certificate-based HTTP authentication on the resource server's HTTP authentication on the resource server's endpoint to
endpoint to authenticate its identity and the resource server authenticate its identity and the resource server validates the
validates the name with the name referenced by the token. name with the name referenced by the token.
o same as before, but the client uses his private key to sign the o same as before, but the client uses his private key to sign the
request to the resource server (public key is either contained in request to the resource server (public key is either contained in
the token or sent along with the request) the token or sent along with the request)
o Alternatively, the authorization server may issue a token-bound o Alternatively, the authorization server may issue a token-bound
secret, which the client uses to sign the request. The resource secret, which the client uses to MAC (message authentication code)
the request (see [I-D.ietf-oauth-v2-http-mac]). The resource
server obtains the secret either directly from the authorization server obtains the secret either directly from the authorization
server or it is contained in an encrypted section of the token. server or it is contained in an encrypted section of the token.
That way the resource server does not "know" the client but is That way the resource server does not "know" the client but is
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 Authenticated requests are a countermeasure against abuse of tokens
counterfeit resource servers. by 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 should be uniquely identifiable and measures. Every signed request should be uniquely identifiable and
should not be processed twice by the resource server. This should not be processed twice by the resource server. This
countermeasure helps to mitigate: countermeasure helps to mitigate:
o modifications of the message and o modifications of the message and
skipping to change at page 63, line 26 skipping to change at page 63, line 50
software may be practical in some limited environments, and can be software may be practical in some limited environments, and can be
used as a countermeasure in those cases. Such restrictions are used as a countermeasure in those cases. Such restrictions are
not practical in the general case, and mechanisms for after-the- not practical in the general case, and mechanisms for after-the-
fact recovery should be in place. fact recovery should be in place.
o While end users are mostly incapable of properly vetting o While end users are mostly incapable of properly vetting
applications they load onto their devices, those who deploy applications they load onto their devices, those who deploy
Authorization Servers might have tools at their disposal to Authorization Servers might have tools at their disposal to
mitigate malicious Clients. For example, a well run Authorization mitigate malicious Clients. For example, a well run Authorization
Server must only assert client properties to the end-user it is Server must only assert client properties to the end-user it is
effectively capable to validate, explicitely point out which effectively capable of validating, explicitely point out which
properties it cannot validate, and indicate to the end-user the properties it cannot validate, and indicate to the end-user the
risk associated with granting access to the particular client. risk associated with granting access to the particular client.
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 Barry Leiba, Hui-Lan Lu, Francisco Corella, We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
Peifung E Lam, Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward,
Bray, and James H. Manger for their comments and contributions. Niv Steingarten, Tim Bray, and James H. Manger for their comments and
contributions.
8. References 8. Informative References
8.1. Normative References [I-D.gondrom-x-frame-options]
Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
draft-gondrom-x-frame-options-00 (work in progress),
March 2012.
[I-D.ietf-oauth-v2] [I-D.ietf-oauth-assertions]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth Jones, M., Campbell, B., and Y. Goland, "OAuth 2.0
2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work Assertion Profile", draft-ietf-oauth-assertions-03 (work
in progress), May 2012. in progress), May 2012.
8.2. Informative References [I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-00 (work in
progress), May 2012.
[I-D.ietf-oauth-revocation] [I-D.ietf-oauth-revocation]
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-00 (work in Revocation", draft-ietf-oauth-revocation-00 (work in
progress), May 2012. progress), May 2012.
[I-D.ietf-oauth-v2]
Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth
2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work
in progress), June 2012.
[I-D.ietf-oauth-v2-bearer] [I-D.ietf-oauth-v2-bearer]
Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0
Authorization Protocol: Bearer Tokens", Authorization Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-19 (work in progress), draft-ietf-oauth-v2-bearer-21 (work in progress),
April 2012. June 2012.
[I-D.ietf-oauth-v2-http-mac] [I-D.ietf-oauth-v2-http-mac]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Hammer-Lahav, E., "HTTP Authentication: MAC Access
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
progress), February 2012. progress), February 2012.
[IMEI] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[OASIS.sstc-gross-sec-analysis-response-01]
Linn, J., Ed. and P. Mishra, Ed., "SSTC Response to
"Security Analysis of the SAML Single Sign-on Browser/
Artifact Profile"", January 2005.
[OASIS.sstc-saml-bindings-1.1]
Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
"Bindings and Profiles for the OASIS Security Assertion
Markup Language (SAML) V1.1", September 2003.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[framebusting]
Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
"Busting Frame Busting: a Study of Clickjacking
Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
Security and Privacy Workshop, 2010.
[gross-sec-analysis]
Gross, T., "Security Analysis of the SAML Single Sign-on
Browser/Artifact Profile, 19th Annual Computer Security
Applications Conference, Las Vegas", December 2003.
[iFrame] World Wide Web Consortium, "Frames in HTML documents",
W3C HTML 4.01, Dec 1999.
[owasp] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>.
[portable-contacts] [portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>. <http://portablecontacts.net/>.
[ssl-latency]
Sissel, J., Ed., "SSL handshake latency and HTTPS
optimizations", June 2010.
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 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"
skipping to change at page 66, line 4 skipping to change at page 67, line 42
o Synchronisation with the core's security consideration section o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15) (UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation o Added Resource Owner Impersonation
o Improved section 5 o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02 draft-ietf-oauth-v2-threatmodel-02
o Incoporated Tim Bray's review comments (e.g. removed all normative o Incoporated Tim Bray's review comments (e.g. removed all normative
language) language)
draft-ietf-oauth-v2-threatmodel-03 draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback o incorporated shepherd review feedback
o incorporated AD review feedback
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. 207 change blocks. 
508 lines changed or deleted 603 lines changed or added

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