draft-ietf-oauth-v2-threatmodel-08.txt   rfc6819.txt 
OAuth Working Group T. Lodderstedt, Ed. Internet Engineering Task Force (IETF) T. Lodderstedt, Ed.
Internet-Draft Deutsche Telekom AG Request for Comments: 6819 Deutsche Telekom AG
Intended status: Informational M. McGloin Category: Informational M. McGloin
Expires: April 9, 2013 IBM ISSN: 2070-1721 IBM
P. Hunt P. Hunt
Oracle Corporation Oracle Corporation
October 6, 2012 January 2013
OAuth 2.0 Threat Model and Security Considerations OAuth 2.0 Threat Model and Security Considerations
draft-ietf-oauth-v2-threatmodel-08
Abstract Abstract
This document gives additional security considerations for OAuth, This document gives additional security considerations for OAuth,
beyond those in the OAuth 2.0 specification, based on a comprehensive beyond those in the OAuth 2.0 specification, based on a comprehensive
threat model for the OAuth 2.0 Protocol. threat model for the OAuth 2.0 protocol.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 9, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6819.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 ........................................................7
2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. Scope ......................................................7
2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 2.2. Attack Assumptions .........................................7
2.3. Architectural assumptions . . . . . . . . . . . . . . . . 8 2.3. Architectural Assumptions ..................................8
2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 2.3.1. Authorization Servers ...............................8
2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 2.3.2. Resource Server .....................................9
2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3.3. Client ..............................................9
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 3. Security Features ...............................................9
3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Tokens ....................................................10
3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Scope ..............................................11
3.1.2. Limited Access Token Lifetime . . . . . . . . . . . . 11 3.1.2. Limited Access Token Lifetime ......................11
3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Token ..............................................11
3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Refresh Token .............................................11
3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12 3.4. Authorization "code" ......................................12
3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 13 3.5. Redirect URI ..............................................13
3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 13 3.6. "state" Parameter .........................................13
3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13 3.7. Client Identifier .........................................13
4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Threat Model ...................................................15
4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Clients ...................................................16
4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15 4.1.1. Threat: Obtaining Client Secrets ...................16
4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 17 4.1.2. Threat: Obtaining Refresh Tokens ...................17
4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 19 4.1.3. Threat: Obtaining Access Tokens ....................19
4.1.4. Threat: End-user credentials phished using 4.1.4. Threat: End-User Credentials Phished Using
compromised or embedded browser . . . . . . . . . . . 19 Compromised or Embedded Browser ....................19
4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 20 4.1.5. Threat: Open Redirectors on Client .................20
4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 20 4.2. Authorization Endpoint ....................................21
4.2.1. Threat: Password phishing by counterfeit 4.2.1. Threat: Password Phishing by Counterfeit
authorization server . . . . . . . . . . . . . . . . . 20 Authorization Server ...............................21
4.2.2. Threat: User unintentionally grants too much 4.2.2. Threat: User Unintentionally Grants Too
access scope . . . . . . . . . . . . . . . . . . . . . 21 Much 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 .............................22
4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22 4.2.4. Threat: Open Redirector ............................22
4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22 4.3. Token Endpoint ............................................23
4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22 4.3.1. Threat: Eavesdropping Access Tokens ................23
4.3.2. Threat: Obtain access tokens from authorization 4.3.2. Threat: Obtaining Access Tokens from
server database . . . . . . . . . . . . . . . . . . . 23 Authorization Server Database ......................23
4.3.3. Threat: Disclosure of client credentials during 4.3.3. Threat: Disclosure of Client Credentials
transmission . . . . . . . . . . . . . . . . . . . . . 23 during Transmission ................................23
4.3.4. Threat: Obtain client secret from authorization 4.3.4. Threat: Obtaining Client Secret from
server database . . . . . . . . . . . . . . . . . . . 23 Authorization Server Database ......................24
4.3.5. Threat: Obtain client secret by online guessing . . . 24 4.3.5. Threat: Obtaining Client Secret by Online Guessing .24
4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24 4.4. Obtaining Authorization ...................................25
4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24 4.4.1. Authorization "code" ...............................25
4.4.1.1. Threat: Eavesdropping or leaking authorization 4.4.1.1. Threat: Eavesdropping or Leaking
codes . . . . . . . . . . . . . . . . . . . . . . 24 Authorization "codes" .....................25
4.4.1.2. Threat: Obtain authorization codes from 4.4.1.2. Threat: Obtaining Authorization "codes"
authorization server database . . . . . . . . . . 25 from Authorization Server Database ........26
4.4.1.3. Threat: Online guessing of authorization codes . . 26 4.4.1.3. Threat: Online Guessing of
4.4.1.4. Threat: Malicious client obtains authorization . . 26 Authorization "codes" .....................27
4.4.1.5. Threat: Authorization code phishing . . . . . . . 28 4.4.1.4. Threat: Malicious Client Obtains
4.4.1.6. Threat: User session impersonation . . . . . . . . 28 Authorization .............................27
4.4.1.7. Threat: Authorization code leakage through 4.4.1.5. Threat: Authorization "code" Phishing .....29
counterfeit client . . . . . . . . . . . . . . . . 29 4.4.1.6. Threat: User Session Impersonation ........29
4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31 4.4.1.7. Threat: Authorization "code" Leakage
4.4.1.9. Threat: Clickjacking attack against through Counterfeit Client ................30
authorization . . . . . . . . . . . . . . . . . . 31 4.4.1.8. Threat: CSRF Attack against redirect-uri ..32
4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 32 4.4.1.9. Threat: Clickjacking Attack against
4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 Authorization .............................33
4.4.1.12. Threat: DoS using manufactured authorization 4.4.1.10. Threat: Resource Owner Impersonation .....33
codes . . . . . . . . . . . . . . . . . . . . . . 34 4.4.1.11. Threat: DoS Attacks That Exhaust
4.4.1.13. Threat: Code substitution (OAuth Login) . . . . . 35 Resources ................................34
4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 36 4.4.1.12. Threat: DoS Using Manufactured
4.4.2.1. Threat: Access token leak in Authorization "codes" ....................35
transport/end-points . . . . . . . . . . . . . . . 36 4.4.1.13. Threat: Code Substitution (OAuth Login) ..36
4.4.2.2. Threat: Access token leak in browser history . . . 37 4.4.2. Implicit Grant .....................................37
4.4.2.3. Threat: Malicious client obtains authorization . . 37 4.4.2.1. Threat: Access Token Leak in
4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37 Transport/Endpoints .......................37
4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 38 4.4.2.2. Threat: Access Token Leak in
4.4.2.6. Threat: Token substitution (OAuth Login) . . . . . 38 Browser History ...........................38
4.4.3. Resource Owner Password Credentials . . . . . . . . . 39 4.4.2.3. Threat: Malicious Client Obtains
4.4.3.1. Threat: Accidental exposure of passwords at Authorization .............................38
client site . . . . . . . . . . . . . . . . . . . 40 4.4.2.4. Threat: Manipulation of Scripts ...........38
4.4.3.2. Threat: Client obtains scopes without end-user 4.4.2.5. Threat: CSRF Attack against redirect-uri ..39
authorization . . . . . . . . . . . . . . . . . . 40 4.4.2.6. Threat: Token Substitution (OAuth Login) ..39
4.4.3.3. Threat: Client obtains refresh token through 4.4.3. Resource Owner Password Credentials ................40
automatic authorization . . . . . . . . . . . . . 41 4.4.3.1. Threat: Accidental Exposure of
4.4.3.4. Threat: Obtain user passwords on transport . . . . 42 Passwords at Client Site ..................41
4.4.3.5. Threat: Obtain user passwords from 4.4.3.2. Threat: Client Obtains Scopes
authorization server database . . . . . . . . . . 42 without End-User Authorization ............42
4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42 4.4.3.3. Threat: Client Obtains Refresh
4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 43 Token through Automatic Authorization .....42
4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 43 4.4.3.4. Threat: Obtaining User Passwords
4.5.1. Threat: Eavesdropping refresh tokens from on Transport ..............................43
authorization server . . . . . . . . . . . . . . . . . 43 4.4.3.5. Threat: Obtaining User Passwords
4.5.2. Threat: Obtaining refresh token from authorization from Authorization Server Database ........43
server database . . . . . . . . . . . . . . . . . . . 43 4.4.3.6. Threat: Online Guessing ...................43
4.5.3. Threat: Obtain refresh token by online guessing . . . 44 4.4.4. Client Credentials .................................44
4.5.4. Threat: Obtain refresh token phishing by
counterfeit authorization server . . . . . . . . . . . 44
4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44 4.5. Refreshing an Access Token ................................44
4.6.1. Threat: Eavesdropping access tokens on transport . . . 44 4.5.1. Threat: Eavesdropping Refresh Tokens from
4.6.2. Threat: Replay authorized resource server requests . . 45 Authorization Server ...............................44
4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45 4.5.2. Threat: Obtaining Refresh Token from
4.6.4. Threat: Access token phishing by counterfeit Authorization Server Database ......................44
resource server . . . . . . . . . . . . . . . . . . . 46 4.5.3. Threat: Obtaining Refresh Token by Online
4.6.5. Threat: Abuse of token by legitimate resource Guessing ...........................................45
server or client . . . . . . . . . . . . . . . . . . . 46 4.5.4. Threat: Refresh Token Phishing by
4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 47 Counterfeit Authorization Server ...................45
4.6.7. Threat: Token leakage via logfiles and HTTP 4.6. Accessing Protected Resources .............................46
referrers . . . . . . . . . . . . . . . . . . . . . . 47 4.6.1. Threat: Eavesdropping Access Tokens on Transport ...46
5. Security Considerations . . . . . . . . . . . . . . . . . . . 48 4.6.2. Threat: Replay of Authorized Resource
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48 Server Requests ....................................46
5.1.1. Ensure confidentiality of requests . . . . . . . . . . 48 4.6.3. Threat: Guessing Access Tokens .....................46
5.1.2. Utiliize server authentication . . . . . . . . . . . . 48 4.6.4. Threat: Access Token Phishing by
5.1.3. Always keep the resource owner informed . . . . . . . 49 Counterfeit Resource Server ........................47
5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49 4.6.5. Threat: Abuse of Token by Legitimate
5.1.4.1. Enforce credential storage protection best Resource Server or Client ..........................48
practices . . . . . . . . . . . . . . . . . . . . 50 4.6.6. Threat: Leak of Confidential Data in HTTP Proxies ..48
5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 51 4.6.7. Threat: Token Leakage via Log Files and
5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 52 HTTP Referrers .....................................48
5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 52 5. Security Considerations ........................................49
5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52 5.1. General ...................................................49
5.1.5.3. Use short expiration time . . . . . . . . . . . . 53 5.1.1. Ensure Confidentiality of Requests .................49
5.1.5.4. Limit number of usages/ One time usage . . . . . . 53 5.1.2. Utilize Server Authentication ......................50
5.1.5.5. Bind tokens to a particular resource server 5.1.3. Always Keep the Resource Owner Informed ............50
(Audience) . . . . . . . . . . . . . . . . . . . . 54 5.1.4. Credentials ........................................51
5.1.5.6. Use endpoint address as token audience . . . . . . 54 5.1.4.1. Enforce Credential Storage
5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54 Protection Best Practices .................51
5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54 5.1.4.2. Online Attacks on Secrets .................52
5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 55 5.1.5. Tokens (Access, Refresh, Code) .....................53
5.1.5.10. Encryption of token content . . . . . . . . . . . 55 5.1.5.1. Limit Token Scope .........................53
5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 55 5.1.5.2. Determine Expiration Time .................54
5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55 5.1.5.3. Use Short Expiration Time .................54
5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55 5.1.5.4. Limit Number of Usages or One-Time Usage ..55
5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55 5.1.5.5. Bind Tokens to a Particular
5.2.1.1. Automatic revocation of derived tokens if Resource Server (Audience) ................55
abuse is detected . . . . . . . . . . . . . . . . 55 5.1.5.6. Use Endpoint Address as Token Audience ....56
5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 56 5.1.5.7. Use Explicitly Defined Scopes for
5.2.2.1. Restricted issuance of refresh tokens . . . . . . 56 Audience and Tokens .......................56
5.2.2.2. Binding of refresh token to client_id . . . . . . 56 5.1.5.8. Bind Token to Client id ...................56
5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56 5.1.5.9. Sign Self-Contained Tokens ................56
5.2.2.4. Revoke refresh tokens . . . . . . . . . . . . . . 57 5.1.5.10. Encrypt Token Content ....................56
5.2.2.5. Device identification . . . . . . . . . . . . . . 57 5.1.5.11. Adopt a Standard Assertion Format ........57
5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57 5.1.6. Access Tokens ......................................57
5.2.3. Client authentication and authorization . . . . . . . 57
5.2.3.1. Don't issue secrets to client with
inappropriate security policy . . . . . . . . . . 58
5.2.3.2. Require user consent for public clients 5.2. Authorization Server ......................................57
without secret . . . . . . . . . . . . . . . . . . 59 5.2.1. Authorization "codes" ..............................57
5.2.3.3. Client_id only in combination with redirect_uri . 59 5.2.1.1. Automatic Revocation of Derived
5.2.3.4. Installation-specific client secrets . . . . . . . 59 Tokens If Abuse Is Detected ...............57
5.2.3.5. Validation of pre-registered redirect_uri . . . . 60 5.2.2. Refresh Tokens .....................................57
5.2.3.6. Revoke client secrets . . . . . . . . . . . . . . 61 5.2.2.1. Restricted Issuance of Refresh Tokens .....57
5.2.3.7. Use strong client authentication (e.g. 5.2.2.2. Binding of Refresh Token to "client_id" ...58
client_assertion / client_token) . . . . . . . . . 61 5.2.2.3. Refresh Token Rotation ....................58
5.2.4. End-user authorization . . . . . . . . . . . . . . . . 61 5.2.2.4. Revocation of Refresh Tokens ..............58
5.2.4.1. Automatic processing of repeated 5.2.2.5. Device Identification .....................59
authorizations requires client validation . . . . 61 5.2.2.6. X-FRAME-OPTIONS Header ....................59
5.2.4.2. Informed decisions based on transparency . . . . . 62 5.2.3. Client Authentication and Authorization ............59
5.2.4.3. Validation of client properties by end-user . . . 62 5.2.3.1. Don't Issue Secrets to Clients with
5.2.4.4. Binding of authorization code to client_id . . . . 62 Inappropriate Security Policy .............60
5.2.4.5. Binding of authorization code to redirect_uri . . 62 5.2.3.2. Require User Consent for Public
5.3. Client App Security . . . . . . . . . . . . . . . . . . . 63 Clients without Secret ....................60
5.3.1. Don't store credentials in code or resources 5.2.3.3. Issue a "client_id" Only in
bundled with software packages . . . . . . . . . . . . 63 Combination with "redirect_uri" ...........61
5.3.2. Standard web server protection measures (for 5.2.3.4. Issue Installation-Specific Client
config files and databases) . . . . . . . . . . . . . 63 Secrets ...................................61
5.3.3. Store secrets in a secure storage . . . . . . . . . . 63 5.2.3.5. Validate Pre-Registered "redirect_uri" ....62
5.3.4. Utilize device lock to prevent unauthorized device 5.2.3.6. Revoke Client Secrets .....................63
access . . . . . . . . . . . . . . . . . . . . . . . . 64 5.2.3.7. Use Strong Client Authentication
5.3.5. Link state parameter to user agent session . . . . . . 64 (e.g., client_assertion/client_token) .....63
5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 64 5.2.4. End-User Authorization .............................63
5.4.1. Authorization headers . . . . . . . . . . . . . . . . 64 5.2.4.1. Automatic Processing of Repeated
5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64 Authorizations Requires Client Validation .63
5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 65 5.2.4.2. Informed Decisions Based on Transparency ..63
5.5. A Word on User Interaction and User-Installed Apps . . . . 65 5.2.4.3. Validation of Client Properties by
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66 End User ..................................64
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 5.2.4.4. Binding of Authorization "code" to
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67 "client_id" ...............................64
8.1. Informative References . . . . . . . . . . . . . . . . . . 67 5.2.4.5. Binding of Authorization "code" to
8.2. Informative References . . . . . . . . . . . . . . . . . . 67 "redirect_uri" ............................64
Appendix A. Document History . . . . . . . . . . . . . . . . . . 69 5.3. Client App Security .......................................65
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.1. Don't Store Credentials in Code or
Resources Bundled with Software Packages ...........65
5.3.2. Use Standard Web Server Protection Measures
(for Config Files and Databases) ...................65
5.3.3. Store Secrets in Secure Storage ....................65
5.3.4. Utilize Device Lock to Prevent Unauthorized
Device Access ......................................66
5.3.5. Link the "state" Parameter to User Agent Session ...66
5.4. Resource Servers ..........................................66
5.4.1. Authorization Headers ..............................66
5.4.2. Authenticated Requests .............................67
5.4.3. Signed Requests ....................................67
5.5. A Word on User Interaction and User-Installed Apps ........68
6. Acknowledgements ...............................................69
7. References .....................................................69
7.1. Normative References ......................................69
7.2. Informative References ....................................69
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 [RFC6749]. It contains the
contains the following content: 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.
o Describes the security features in-built into the OAuth protocol o Describes the security features built into the OAuth protocol and
and how they are intended to thwart attacks. how they are intended to thwart attacks.
o Gives a comprehensive threat model for OAuth and describes the o Gives a comprehensive threat model for OAuth and describes the
respective counter measures to thwart those threats. respective countermeasures to thwart those threats.
Threats include any intentional attacks on OAuth tokens and resources Threats include any intentional attacks on OAuth tokens and resources
protected by OAuth tokens as well as security risks introduced if the protected by OAuth tokens, as well as security risks introduced if
proper security measures are not put in place. Threats are the 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 help
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 Note: This document cannot assess the probability or the risk
associated with a particular threat because those aspects strongly associated with a particular threat because those aspects strongly
depend on the particular application and deployment OAuth is used to depend on the particular application and deployment OAuth is used to
protect. Similar, impacts are given on a rather abstract level. But protect. Similarly, impacts are given on a rather abstract level.
the information given here may serve as a foundation for deployment- But the information given here may serve as a foundation for
specific threat models. Implementors may refine and detail the deployment-specific threat models. Implementors may refine and
abstract threat model in order to account for the specific properties detail the abstract threat model in order to account for the specific
of their deployment and to come up with a risk analysis. As this properties of their deployment and to come up with a risk analysis.
document is based on the base OAuth 2.0 specification, itdoes not As this document is based on the base OAuth 2.0 specification, it
consider proposed extensions, such as client registration or does not consider proposed extensions such as client registration or
discovery, many of which are still under discussion. discovery, many of which are still under discussion.
2. Overview 2. Overview
2.1. Scope 2.1. Scope
The security considerations document only considers clients bound to This 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 [RFC6749]. Such deployments
deployments have the following characteristics: 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.
o Token scope values (e.g. applicable URLs and methods) are well- o Token scope values (e.g., applicable URLs and methods) are well-
known at development time. known at development time.
o Client registration: Since registration of clients is out of scope o Client registration is out of scope of the current core
of the current core spec, this document assumes a broad variety of specification. Therefore, this document assumes a broad variety
options from static registration during development time to of options, from static registration during development time to
dynamic registration at runtime. dynamic registration at runtime.
The following are considered out of scope : The following are considered out of scope:
o Communication between authorization server and resource server o Communication between the authorization server and resource
server.
o Token formats o Token formats.
o Except for "Resource Owner Password Credentials" (see o Except for the resource owner password credentials grant type (see
[I-D.ietf-oauth-v2], section 4.3), the mechanism used by [RFC6749], Section 4.3), the mechanism used by authorization
authorization servers to authenticate the user servers to authenticate the user.
o Mechanism by which a user obtained an assertion and any resulting o Mechanism by which a user obtained an assertion and any resulting
attacks mounted as a result of the assertion being false. attacks mounted as a result of the assertion being false.
o Clients not bound to a specific deployment: An example could be a o Clients not bound to a specific deployment: An example could be a
mail client with support for contact list access via the portable mail client with support for contact list access via the portable
contacts API (see [portable-contacts]). Such clients cannot be contacts API (see [Portable-Contacts]). Such clients cannot be
registered upfront with a particular deployment and should registered upfront with a particular deployment and should
dynamically discover the URLs relevant for the OAuth protocol. dynamically discover the URLs relevant for the OAuth protocol.
2.2. Attack Assumptions 2.2. Attack Assumptions
The following assumptions relate to an attacker and resources The following assumptions relate to an attacker and resources
available to an attacker: available to an attacker. It is assumed that:
o It is assumed the attacker has full access to the network between o the attacker has full access to the network between the client and
the client and authorization servers and the client and the authorization servers and the client and the resource server,
resource server, respectively. The attacker may eavesdrop on any respectively. The attacker may eavesdrop on any communications
communications between those parties. He is not assumed to have between those parties. He is not assumed to have access to
access to communication between authorization and resource server. communication between the authorization server and resource
server.
o It is assumed an attacker has unlimited resources to mount an o an attacker has unlimited resources to mount an attack.
attack.
o It is assumed that 2 of the 3 parties involved in the OAuth o two of the three parties involved in the OAuth protocol may
protocol may collude to mount an attack against the 3rd party. collude to mount an attack against the 3rd party. For example,
For example, the client and authorization server may be under the client and authorization server may be under control of an
control of an attacker and collude to trick a user to gain access attacker and collude to trick a user to gain access to resources.
to resources.
2.3. Architectural assumptions 2.3. Architectural Assumptions
This section documents the assumptions about the features, This section documents assumptions about the features, limitations,
limitations, and design options of the different entities of a OAuth and design options of the different entities of an OAuth deployment
deployment along with the security-sensitive data-elements managed by along with the security-sensitive data elements managed by those
those entity. These assumptions are the foundation of the threat entities. These assumptions are the foundation of the threat
analysis. analysis.
The OAuth protocol leaves deployments with a certain degree of The OAuth protocol leaves deployments with a certain degree of
freedom how to implement and apply the standard. The core freedom regarding how to implement and apply the standard. The core
specification defines the core concepts of an authorization server specification defines the core concepts of an authorization server
and a resource server. Both servers can be implemented in the same and a resource server. Both servers can be implemented in the same
server entity, or they may also be different entities. The later is server entity, or they may also be different entities. The latter is
typically the case for multi-service providers with a single typically the case for multi-service providers with a single
authentication and authorization system, and are more typical in authentication and authorization system and is more typical in
middleware architectures. middleware architectures.
2.3.1. Authorization Servers 2.3.1. Authorization Servers
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 usernames 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 the case of handle-based design;
see Section 3.1) 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 the case of handle-based design;
Section 3.1): 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 - see
Section 3.1), or
o authorization server shared secret/public key (assertion-based o either authorization server credentials (handle-based design; see
design - see Section 3.1) Section 3.1) or authorization server shared secret/public key
(assertion-based 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
In OAuth a client is an application making protected resource In OAuth, a client is an application making protected resource
requests on behalf of the resource owner and with its authorization. requests on behalf of the resource owner and with its authorization.
There are different types of clients with different implementation There are different types of clients with different implementation
and security characteristics, such as web, user-agent-based, and and security characteristics, such as web, user-agent-based, and
native applications. A full definition of the different client types native applications. A full definition of the different client types
and profiles is given in [I-D.ietf-oauth-v2], Section 2.1. and profiles is given in [RFC6749], 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 certification authority (CA) certificates (HTTPS)
o per-authorization process: redirect_uri, authorization code o per-authorization process: "redirect_uri", authorization "code"
3. Security Features 3. Security Features
These are some of the security features which have been built into These are some of the security features that have been built into the
the OAuth 2.0 protocol to mitigate attacks and security issues. OAuth 2.0 protocol to mitigate attacks and security issues.
3.1. Tokens 3.1. Tokens
OAuth makes extensive use many kinds of tokens (access tokens, OAuth makes extensive use of many kinds of tokens (access tokens,
refresh tokens, authorization codes). The information content of a refresh tokens, authorization "codes"). The information content of a
token can be represented in two ways as follows: token can be represented in two ways, as follows:
Handle (or artifact) a reference to some internal data structure Handle (or artifact) A 'handle' is a reference to some internal data
within the authorization server; the internal data structure structure within the authorization server; the internal data
contains the attributes of the token, such as user id, scope, etc. structure contains the attributes of the token, such as user id
Handles enable simple revocation and do not require cryptographic (UID), scope, etc. Handles enable simple revocation and do not
mechanisms to protect token content from being modified. On the require cryptographic mechanisms to protect token content from
other hand, handles require communication between issuing and being modified. On the other hand, handles require communication
consuming entity (e.g. authorization and resource server) in order between the issuing and consuming entity (e.g., the authorization
to validate the token and obtain token-bound data. This server and resource server) in order to validate the token and
communication might have an negative impact on performance and obtain token-bound data. This communication might have a negative
scalability if both entities reside on different systems. Handles impact on performance and scalability if both entities reside on
are therefore typically used if the issuing and consuming entity different systems. Handles are therefore typically used if the
are the same. A 'handle' token is often referred to as an issuing and consuming entity are the same. A 'handle' token is
'opaque' token because the resource server does not need to be often referred to as an 'opaque' token because the resource server
able to interpret the token directly, it simply uses the token. does not need to be able to interpret the token directly; it
simply uses the token.
Assertions (aka self-contained token) a parseable token. An Assertion (aka self-contained token) An assertion is a parseable
assertion typically has a duration, has an audience, and is token. An assertion typically has a duration, has an audience,
digitally signed in order to ensure data integrity and origin and is digitally signed in order to ensure data integrity and
authentication. It contains information about the user and the origin authentication. It contains information about the user and
client. Examples of assertion formats are SAML assertions the client. Examples of assertion formats are Security Assertion
[OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120]. Markup Language (SAML) assertions [OASIS.saml-core-2.0-os] and
Assertions can typically directly be validated and used by a Kerberos tickets [RFC4120]. Assertions can typically be directly
resource server without interactions with the authorization validated and used by a resource server without interactions with
server. This results in better performance and scalability in the authorization server. This results in better performance and
deployment where issuing and consuming entity reside on different scalability in deployments where the issuing and consuming
systems. Implementing token revocation is more difficult with entities reside on different systems. Implementing token
assertions than with handles. 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
as follows: servers, 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., [RFC6750]). Because mere
[I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to possession is enough to use the token, it is important that
use the token it is important that communication between end- communication between endpoints be secured to ensure that only
points be secured to ensure that only authorized end-points may authorized endpoints may capture the token. The bearer token is
capture the token. The bearer token is convenient to client convenient for client applications, as it does not require them to
applications as it does not require them to do anything to use do anything to use them (such as a proof of identity). Bearer
them (such as a proof of identity). Bearer tokens have similar tokens have similar characteristics to web single-sign-on (SSO)
characteristics to web single-sign-on (SSO) cookies used in cookies used in browsers.
browsers.
proof token A 'proof token' is a token that can only be used by a proof token A 'proof token' is a token that can only be used by a
specific client. Each use of the token, requires the client to specific client. Each use of the token requires the client to
perform some action that proves that it is the authorized user of perform some action that proves that it is the authorized user of
the token. Examples of this are MAC tokens, which require the the token. Examples of this are MAC-type access tokens, which
client to digitally sign the resource request with a secret require the client to digitally sign the resource request with a
corresponding to the particular token send with the request secret corresponding to the particular token sent with the request
(e.g.[I-D.ietf-oauth-v2-http-mac]). (e.g., [OAuth-HTTP-MAC]).
3.1.1. Scope 3.1.1. Scope
A Scope represents the access authorization associated with a A scope represents the access authorization associated with a
particular token with respect to resource servers, resources and particular token with respect to resource servers, resources, and
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 that these parties
less secure or trustworthy. Optionally, the client can request the deem less secure or trustworthy. Optionally, the client can request
scope to apply to the token but only for lesser scope than would the scope to apply to the token but only for a lesser scope than
otherwise be granted, e.g. to reduce the potential impact if this would otherwise be granted, e.g., to reduce the potential impact if
token is sent over non secure channels. A scope is typically this 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. Limited Access Token Lifetime 3.1.2. Limited Access Token Lifetime
The protocol parameter expires_in allows an authorization server The protocol parameter "expires_in" allows an authorization server
(based on its policies or on behalf of the end-user) to limit the (based on its policies or on behalf of the end user) to limit the
lifetime of an access token and to pass this information to the lifetime of an access token and to pass this information to the
client. This mechanism can be used to issue short-living tokens to client. This mechanism can be used to issue short-lived tokens to
OAuth clients the authorization server deems less secure or where OAuth clients that the authorization server deems less secure, or
sending tokens over non secure channels. 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,
combination with the usage of refresh tokens enables the possibility in combination with the usage of refresh tokens, enables the
of passive revocation of access authorization on the expiry of the possibility of passive revocation of access authorization on the
current access token. expiry of the current access token.
3.3. Refresh Token 3.3. Refresh Token
A refresh token represents a long-lasting authorization of a certain A refresh token represents a long-lasting authorization of a certain
client to access resources on behalf of a resource owner. Such client to access resources on behalf of a resource owner. Such
tokens are exchanged between client and authorization server, only. tokens are exchanged between the client and authorization server
Clients use this kind of token to obtain ("refresh") new access only. Clients use this kind of token to obtain ("refresh") new
tokens used for resource server invocations. access tokens used for resource server invocations.
A refresh token, coupled with a short access token lifetime, can be A refresh token, coupled with a short access token lifetime, can be
used to grant longer access to resources without involving end user used to grant longer access to resources without involving end-user
authorization. This offers an advantage where resource servers and authorization. This offers an advantage where resource servers and
authorization servers are not the same entity, e.g. in a distributed authorization servers are not the same entity, e.g., in a distributed
environment, as the refresh token is always exchanged at the environment, as the refresh token is always exchanged at the
authorization server. The authorization server can revoke the authorization server. The authorization server can revoke the
refresh token at any time causing the granted access to be revoked refresh token at any time, causing the granted access to be revoked
once the current access token expires. Because of this, a short once the current access token expires. Because of this, a short
access token lifetime is important if timely revocation is a high access token lifetime is important if timely revocation is a high
priority. priority.
The refresh token is also a secret bound to the client identifier and The refresh token is also a secret bound to the client identifier and
client instance which originally requested the authorization and client instance that originally requested the authorization; the
representing the original resource owner grant. This is ensured by refresh token also represents the original resource owner grant.
the authorization process as follows: This is ensured by the authorization process as follows:
1. The resource owner and user-agent safely deliver the 1. The resource owner and user agent safely deliver the
authorization code to the client instance in first place. authorization "code" to the client instance in the first place.
2. The client uses it immediately in secure transport-level 2. The client uses it immediately in secure transport-level
communications to the authorization server and then securely communications to the authorization server and then securely
stores the long-lived refresh token. stores the long-lived refresh token.
3. The client always uses the refresh token in secure transport- 3. The client always uses the refresh token in secure transport-
level communications to the authorization server to get an access level communications to the authorization server to get an access
token (and optionally rollover the refresh token). token (and optionally roll over 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 tokens. Authorization "codes" are sent
the client's redirection URI instead of tokens for two purposes. to the client's redirect URI instead of tokens for two purposes:
1. Browser-based flows expose protocol parameters to potential 1. Browser-based flows expose protocol parameters to potential
attackers via URI query parameters (HTTP referrer), the browser attackers via URI query parameters (HTTP referrer), the browser
cache, or log file entries and could be replayed. In order to cache, or log file entries, and could be replayed. In order to
reduce this threat, short-lived authorization codes are passed reduce this threat, short-lived authorization "codes" are passed
instead of tokens and exchanged for tokens over a more secure instead of tokens and exchanged for tokens over a more secure
direct connection between client and authorization server. direct connection between the client and the 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 the client and the authorization server than in
context of the indirect authorization request. The latter would the context of the indirect authorization request. The latter
require digital signatures. would require digital signatures.
3.5. Redirection URI 3.5. Redirect URI
A redirection URI helps to detect malicious clients and prevents A redirect 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 redirect 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 the implicit grant type to pre-register
redirect URIs and validate against the registered redirection URI in their redirect URIs and validate against the registered redirect URI
the authorization request. in the authorization request.
3.6. State parameter 3.6. "state" Parameter
The state parameter is used to link requests and callbacks to prevent The "state" parameter is used to link requests and callbacks to
Cross-Site Request Forgery attacks (see Section 4.4.1.8) where an prevent cross-site request forgery attacks (see Section 4.4.1.8)
attacker authorizes access to his own resources and then tricks a where an attacker authorizes access to his own resources and then
users into following a redirect with the attacker's token. This tricks a user into following a redirect with the attacker's token.
parameter should bind to the authenticated state in a user agent and, This parameter should bind to the authenticated state in a user agent
as per the core OAuth spec, the user agent must be capable of keeping and, as per the core OAuth spec, the user agent must be capable of
it in a location accessible only by the client and user agent, i.e. keeping it in a location accessible only by the client and user
protected by same-origin policy. agent, i.e., protected by same-origin policy.
3.7. Client Identitifier 3.7. Client Identifier
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 requests to
same originator, such as the same originator, such as
o a particular end-user authorization process and the corresponding o a particular end-user authorization process and the corresponding
request on the token's endpoint to exchange the authorization code request on the token's endpoint to exchange the authorization
for tokens or "code" 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 authorizations)
This identifier 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 a scope requested by a particular client. The client
identifier may be used to limit the number of request for a identifier may be used to limit the number of requests for a
particular client or to charge the client per request. It 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 redirect URI can be used to prevent the delivery of 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 identifier. 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 - see [I-D.ietf-oauth-v2], profile (e.g., native vs. web application; see [RFC6749], Section 9),
Section 9) and deployment model: and deployment model:
Deployment-independent client_id with pre-registered redirect_uri and Deployment-independent "client_id" with pre-registered "redirect_uri"
without client_secret Such an identifier is used by multiple and without "client_secret" Such an identifier is used by
installations of the same software package. The identifier of multiple installations of the same software package. The
such a client can only be validated with the help of the end-user. identifier of such a client can only be validated with the help of
This is a viable option for native applications in order to the end-user. This is a viable option for native applications in
identify the client for the purpose of displaying meta information order to identify the client for the purpose of displaying meta
about the client to the user and to differentiate clients in log information about the client to the user and to differentiate
files. Revocation of the rights associated with such a client clients in log files. Revocation of the rights associated with
identifier will affect ALL deployments of the respective software. such a client 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"
with client_secret This is an option for native applications only, and with "client_secret" This is an option for native
since web application would require different redirect URIs. This applications only, since web applications would require different
category is not advisable because the client secret cannot be redirect URIs. This category is not advisable because the client
protected appropriately (see Section 4.1.1). Due to its security secret cannot be protected appropriately (see Section 4.1.1). Due
weaknesses, such client identities have the same trust level as to its security weaknesses, such client identities have the same
deployment-independent clients without secret. Revocation will trust level as deployment-independent clients without secrets.
affect ALL deployments. Revocation will affect ALL deployments.
Deployment-specific client_id with pre-registered redirect_uri and Deployment-specific "client_id" with pre-registered "redirect_uri"
with client_secret The client registration process ensures the and with "client_secret" The client registration process ensures
validation of the client's properties, such as redirection URI, the validation of the client's properties, such as redirect URI,
website URL, web site name, contacts. Such a client identifier web site URL, web site name, and contacts. Such a client
can be utilized for all relevant use cases cited above. This identifier can be utilized for all relevant use cases cited above.
level can be achieved for web applications in combination with a This level can be achieved for web applications in combination
manual or user-bound registration process. Achieving this level with a manual or user-bound registration process. Achieving this
for native applications is much more difficult. Either the level 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.
Deployment-specific client_id with client_secret without validated Deployment-specific "client_id" with "client_secret" without
properties Such a client can be recognized by the authorization validated properties Such a client can be recognized by the
server in transactions with subsequent requests (e.g. authorization server in transactions with subsequent requests
authorization and token issuance, refresh token issuance and (e.g., authorization and token issuance, refresh token issuance,
access token refreshment). The authorization server cannot assure and access token refreshment). The authorization server cannot
any property of the client to end-users. Automatic processing of assure any property of the client to end users. Automatic
re-authorizations could be allowed as well. Such client processing of re-authorizations could be allowed as well. Such
credentials can be generated automatically without any validation client credentials can be generated automatically without any
of client properties, which makes it another option especially for validation of client properties, which makes it another option,
native applications. Revocation will affect a single deployment especially for native applications. Revocation will affect a
only. single deployment only.
4. 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 the 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
access protected resources. Every countermeasure description refers or access protected resources. Every countermeasure description
to a detailed description in Section 5. refers to a detailed description in Section 5.
4.1. Clients 4.1. Clients
This section describes possible threats directed to OAuth clients. This section describes possible threats directed to OAuth clients.
4.1.1. Threat: Obtain Client Secrets 4.1.1. Threat: Obtaining Client Secrets
The attacker could try to get access to the secret of a particular The attacker could try to get access to the secret of a particular
client in order to: client in order to:
o replay its refresh tokens and authorization codes, or o replay its refresh tokens and authorization "codes", or
o obtain tokens on behalf of the attacked client with the privileges o obtain tokens on behalf of the attacked client with the privileges
of that client_id acting as an instance of the client. of that "client_id" acting as an instance of the client.
The resulting impact would be: The resulting impact would be the following:
o Client authentication of access to authorization server can be o Client authentication of access to the authorization server can be
bypassed bypassed.
o Stolen refresh tokens or authorization codes can be replayed o Stolen refresh tokens or authorization "codes" can be replayed.
Depending on the client category, the following attacks could be Depending on the client category, the following attacks could be
utilized to obtain the client secret. utilized to obtain the client secret.
Attack: Obtain Secret From Source Code or Binary: Attack: Obtain Secret From Source Code or Binary:
This applies for all client types. For open source projects, secrets This applies for all client types. For open source projects, secrets
can be extracted directly from source code in their public can be extracted directly from source code in their public
repositories. Secrets can be extracted from application binaries repositories. Secrets can be extracted from application binaries
just as easily when published source is not available to the just as easily when the published source is not available to the
attacker. Even if an application takes significant measures to attacker. Even if an application takes significant measures to
obfuscate secrets in their application distribution one should obfuscate secrets in their application distribution, one should
consider that the secret can still be reverse-engineered by anyone consider that the secret can still be reverse-engineered by anyone
with access to a complete functioning application bundle or binary. with access to a complete functioning application bundle or binary.
Countermeasures: Countermeasures:
o Don't issue secrets to public clients or clients with o Don't issue secrets to public clients or clients with
inappropriate security policy - Section 5.2.3.1 inappropriate security policy (Section 5.2.3.1).
o Require user consent for public clients- Section 5.2.3.2 o Require user consent for public clients (Section 5.2.3.2).
o Use deployment-specific client secrets - Section 5.2.3.4 o Use deployment-specific client secrets (Section 5.2.3.4).
o Revoke client secrets - Section 5.2.3.6 o Revoke client secrets (Section 5.2.3.6).
Attack: Obtain a Deployment-Specific Secret: Attack: Obtain a Deployment-Specific Secret:
An attacker may try to obtain the secret from a client installation, An attacker may try to obtain the secret from a client installation,
either from a web site (web server) or a particular devices (native either from a web site (web server) or a particular device (native
application). application).
Countermeasures: Countermeasures:
o Web server: apply standard web server protection measures (for o Web server: Apply standard web server protection measures (for
config files and databases) - Section 5.3.2 config files and databases) (see Section 5.3.2).
o Native applications: Store secrets in a secure local storage - o Native applications: Store secrets in secure local storage
Section 5.3.3 (Section 5.3.3).
o Revoke client secrets - Section 5.2.3.6 o Revoke client secrets (Section 5.2.3.6).
4.1.2. Threat: Obtain Refresh Tokens 4.1.2. Threat: Obtaining Refresh Tokens
Depending on the client type, there are different ways refresh tokens Depending on the client type, there are different ways that refresh
may be revealed to an attacker. The following sub-sections give a tokens may be revealed to an attacker. The following sub-sections
more detailed description of the different attacks with respect to give a more detailed description of the different attacks with
different client types and further specialized countermeasures. respect to different client types and further specialized
Before detailing those threats, here are some generally applicable countermeasures. Before detailing those threats, here are some
countermeasures: generally applicable countermeasures:
o The authorization server should validate the client id associated o The authorization server should validate the client id associated
with the particular refresh token with every refresh request- with the particular refresh token with every refresh request
Section 5.2.2.2 (Section 5.2.2.2).
o Limit token scope - Section 5.1.5.1 o Limit token scope (Section 5.1.5.1).
o Revoke refresh tokens - Section 5.2.2.4 o Revoke refresh tokens (Section 5.2.2.4).
o Revoke client secrets - Section 5.2.3.6 o Revoke client secrets (Section 5.2.3.6).
o Refresh tokens can automatically be replaced in order to detect o Refresh tokens can automatically be replaced in order to detect
unauthorized token usage by another party (Refresh Token Rotation) unauthorized token usage by another party (see "Refresh Token
- Section 5.2.2.3 Rotation", Section 5.2.2.3).
Attack: Obtain Refresh Token from Web application: Attack: Obtain Refresh Token from Web Application:
An attacker may obtain the refresh tokens issued to a web application An attacker may obtain the refresh tokens issued to a web application
by way of overcoming the web server's security controls. Impact: by way of overcoming the web server's security controls.
Since a web application manages the user accounts of a certain site,
such an attack would result in an exposure of all refresh tokens on Impact: Since a web application manages the user accounts of a
that site to the attacker. certain site, such an attack would result in an exposure of all
refresh tokens on that site to the attacker.
Countermeasures: Countermeasures:
o Standard web server protection measures - Section 5.3.2 o Standard web server protection measures (Section 5.3.2).
o Use strong client authentication (e.g. client_assertion / o Use strong client authentication (e.g., client_assertion/
client_token), so the attacker cannot obtain the client secret client_token) so the attacker cannot obtain the client secret
required to exchange the tokens - Section 5.2.3.7 required to exchange the tokens (Section 5.2.3.7).
Attack: Obtain Refresh Token from Native clients: Attack: Obtain Refresh Token from Native Clients:
On native clients, leakage of a refresh token typically affects a On native clients, leakage of a refresh token typically affects a
single user, only. single user only.
Read from local file system: The attacker could try get file system Read from local file system: The attacker could try to get file
access on the device and read the refresh tokens. The attacker could system access on the device and read the refresh tokens. The
utilize a malicious application for that purpose. attacker could utilize a malicious application for that purpose.
Countermeasures: Countermeasures:
o Store secrets in a secure storage - Section 5.3.3 o Store secrets in secure storage (Section 5.3.3).
o Utilize device lock to prevent unauthorized device access - o Utilize device lock to prevent unauthorized device access
Section 5.3.4 (Section 5.3.4).
Attack: Steal device: Attack: Steal Device:
The host device (e.g. mobile phone) may be stolen. In that case, the The host device (e.g., mobile phone) may be stolen. In that case,
attacker gets access to all applications under the identity of the the attacker gets access to all applications under the identity of
legitimate user. the legitimate user.
Countermeasures: Countermeasures:
o Utilize device lock to prevent unauthorized device access - o Utilize device lock to prevent unauthorized device access
Section 5.3.4 (Section 5.3.4).
o Where a user knows the device has been stolen, they can revoke the o Where a user knows the device has been stolen, they can revoke the
affected tokens - Section 5.2.2.4 affected tokens (Section 5.2.2.4).
Attack: Clone Device: Attack: Clone Device:
All device data and applications are copied to another device. All device data and applications are copied to another device.
Applications are used as-is on the target device. Applications are used as-is on the target device.
Countermeasures: Countermeasures:
o Utilize device lock to prevent unauthorized device access - o Utilize device lock to prevent unauthorized device access
Section 5.3.4 (Section 5.3.4).
o Combine refresh token request with device identification - o Combine refresh token request with device identification
Section 5.2.2.5 (Section 5.2.2.5).
o Refresh Token Rotation - Section 5.2.2.3 o Refresh token rotation (Section 5.2.2.3).
o Where a user knows the device has been cloned, they can use this
countermeasure - Refresh Token Revocation - Section 5.2.2.4
4.1.3. Threat: Obtain Access Tokens o Where a user knows the device has been cloned, they can use
refresh token revocation (Section 5.2.2.4).
Depending on the client type, there are different ways access tokens 4.1.3. Threat: Obtaining Access Tokens
may be revealed to an attacker. Access tokens could be stolen from
the device if the application stores them in a storage, which is Depending on the client type, there are different ways that access
accessible to other applications. tokens may be revealed to an attacker. Access tokens could be stolen
from the device if the application stores them in a storage device
that is accessible to other applications.
Impact: Where the token is a bearer token and no additional mechanism Impact: Where the token is a bearer token and no additional mechanism
is used to identify the client, the attacker can access all resources is used to identify the client, the attacker can access all resources
associated with the token and its scope. associated with the token and its scope.
Countermeasures: Countermeasures:
o Keep access tokens in transient memory and limit grants: o Keep access tokens in transient memory and limit grants
Section 5.1.6 (Section 5.1.6).
o Limit token scope - Section 5.1.5.1 o Limit token scope (Section 5.1.5.1).
o Keep access tokens in private memory or apply same protection o Keep access tokens in private memory or apply same protection
means as for refresh tokens - Section 5.2.2 means as for refresh tokens (Section 5.2.2).
o Keep access token lifetime short - Section 5.1.5.3 o Keep access token lifetime short (Section 5.1.5.3).
4.1.4. Threat: End-user credentials phished using compromised or 4.1.4. Threat: End-User Credentials Phished Using Compromised or
embedded browser Embedded Browser
A malicious application could attempt to phish end-user passwords by A malicious application could attempt to phish end-user passwords by
misusing an embedded browser in the end-user authorization process, misusing an embedded browser in the end-user authorization process,
or by presenting its own user-interface instead of allowing trusted or by presenting its own user interface instead of allowing a trusted
system browser to render the authorization user interface. By doing system browser to render the authorization user interface. By doing
so, the usual visual trust mechanisms may be bypassed (e.g. TLS so, the usual visual trust mechanisms may be bypassed (e.g.,
confirmation, web site mechanisms). By using an embedded or internal Transport Layer Security (TLS) confirmation, web site mechanisms).
client application user interface, the client application has access By using an embedded or internal client application user interface,
to additional information it should not have access to (e.g. uid/ the client application has access to additional information to which
password). it should not have access (e.g., UID/password).
Impact: If the client application or the communication is Impact: If the client application or the communication is
compromised, the user would not be aware and all information in the compromised, the user would not be aware of this, and all information
authorization exchange could be captured such as username and in the authorization exchange, such as username and password, could
password. be captured.
Countermeasures: Countermeasures:
o The OAuth flow is designed so that client applications never need o The OAuth flow is designed so that client applications never need
to know user passwords. Client applications should avoid directly to know user passwords. Client applications should avoid directly
asking users for the their credentials. In addition, end users asking users for their credentials. In addition, end users could
could be educated about phishing attacks and best practices, such be educated about phishing attacks and best practices, such as
as only accessing trusted clients, as OAuth does not provide any only accessing trusted clients, as OAuth does not provide any
protection against malicious applications and the end user is protection against malicious applications and the end user is
solely responsible for the trustworthiness of any native solely responsible for the trustworthiness of any native
application installed. application installed.
o Client applications could be validated prior to publication in an o Client applications could be validated prior to publication in an
application market for users to access. That validation is out of application market for users to access. That validation is out of
scope for OAuth but could include validating that the client scope for OAuth but could include validating that the client
application handles user authentication in an appropriate way. application handles user authentication in an appropriate way.
o Client developers should not write client applications that o Client developers should not write client applications that
collect authentication information directly from users and should collect authentication information directly from users and should
instead delegate this task to a trusted system component, e.g. the instead delegate this task to a trusted system component, e.g.,
system-browser. the system browser.
4.1.5. Threat: Open Redirectors on client 4.1.5. Threat: Open Redirectors on Client
An open redirector is an endpoint using a parameter to automatically An open redirector is an endpoint using a parameter to automatically
redirect a user-agent to the location specified by the parameter redirect a user agent to the location specified by the parameter
value without any validation. If the authorization server allows the value without any validation. If the authorization server allows the
client to register only part of the redirection URI, an attacker can client to register only part of the redirect URI, an attacker can use
use an open redirector operated by the client to construct a an open redirector operated by the client to construct a redirect URI
redirection URI that will pass the authorization server validation that will pass the authorization server validation but will send the
but will send the authorization code or access token to an endpoint authorization "code" or access token to an endpoint under the control
under the control of the attacker. 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 Countermeasures:
o require clients to register full redirection URI Section 5.2.3.5 o Require clients to register full redirect 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 Address Resolution Protocol (ARP) spoofing. Wide deployment of OAuth
cause users to become inured to the practice of being redirected to and similar protocols may cause users to become inured to the
websites where they are asked to enter their passwords. If users are practice of being redirected to web sites where they are asked to
not careful to verify the authenticity of these websites before enter their passwords. If users are not careful to verify the
entering their credentials, it will be possible for attackers to authenticity of these web sites before entering their credentials, it
exploit this practice to steal Users' passwords. will be possible for attackers to 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 the use of transport- services based on OAuth and should require the use of transport-
layer security for any requests where the authenticity of the layer security for any requests where the authenticity of the
authorization server or of request responses is an issue (see authorization server or of request responses is an issue (see
Section 5.1.2). Section 5.1.2).
o Authorization servers should attempt to educate Users about the o Authorization servers should attempt to educate users about the
risks phishing attacks pose, and should provide mechanisms that risks posed by phishing attacks and should provide mechanisms that
make it easy for users to confirm the authenticity of their sites. make it easy for users to confirm the authenticity of their sites.
4.2.2. Threat: User unintentionally grants too much access scope 4.2.2. Threat: User Unintentionally Grants Too Much Access Scope
When obtaining end user authorization, the end-user may not When obtaining end-user authorization, the end user may not
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 that 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 an 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 the scope, based on the 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 honor that
scope based on the client identifier. That decision is between scope based on the client identifier. That decision is between
the client and authorization server and is outside the scope of the client and authorization server and is outside the scope of
this spec. The authorization server may also want to consider this spec. The authorization server may also want to consider
what scope to grant based on the client type, e.g. providing lower what scope to grant based on the client type, e.g., providing
scope to public clients. - Section 5.1.5.1 lower 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 that have been previously authorized by the
user. When the user is redirected to the authorization server's end- user. When the user is redirected to the authorization server's end-
user authorization endpoint to grant access, the authorization server user authorization endpoint to grant access, the authorization server
detects that the user has already granted access to that particular detects that the user has already granted access to that particular
client. Instead of prompting the user for approval, the client. Instead of prompting the user for approval, the
authorization server automatically redirects the user back to the authorization server automatically redirects the user back to the
client. client.
A malicious client may exploit that feature and try to obtain such an A malicious client may exploit that feature and try to obtain such an
authorization code instead of the legitimate client. authorization "code" instead of the legitimate client.
Countermeasures: Countermeasures:
o Authorization servers should not automatically process repeat o Authorization servers should not automatically process repeat
authorizations to public clients unless the client is validated authorizations to public clients unless the client is validated
using a pre-registered redirect URI (Section 5.2.3.5 ) using a pre-registered redirect URI (Section 5.2.3.5).
o Authorization servers can mitigate the risks associated with o Authorization servers can mitigate the risks associated with
automatic processing by limiting the scope of Access Tokens automatic processing by limiting the scope of access tokens
obtained through automated approvals - Section 5.1.5.1 obtained through automated approvals (Section 5.1.5.1).
4.2.4. Threat: Open redirector 4.2.4. Threat: Open Redirector
An attacker could use the end-user authorization endpoint and the An attacker could use the end-user authorization endpoint and the
redirection URI parameter to abuse the authorization server as an redirect URI parameter to abuse the authorization server as an open
open redirector. An open redirector is an endpoint using a parameter redirector. An open redirector is an endpoint using a parameter to
to automatically redirect a user-agent to the location specified by automatically redirect a user agent to the location specified by the
the parameter value without any validation. 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 an authorization
authorization server to launch a phishing attack. server to launch a phishing attack.
Countermeasure Countermeasures:
o require clients to register full redirection URI Section 5.2.3.5 o Require clients to register any full redirect URIs
(Section 5.2.3.5).
o don't redirect to redirection URI, if client identifier or o Don't redirect to a redirect URI if the client identifier or
redirection URI can't be verified Section 5.2.3.5 redirect 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 attempt to eavesdrop access token in transit from the Attackers may attempt to eavesdrop access tokens 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 (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: Obtaining Access Tokens from Authorization Server
Database
This threat is applicable if the authorization server stores access This threat is applicable if the authorization server stores access
tokens as handles in a database. An attacker may obtain access tokens as handles in a database. An attacker may obtain access
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. Impact: disclosure the database or launching a SQL injection attack.
of all access tokens
Impact: Disclosure of all access tokens.
Countermeasures: Countermeasures:
o Enforce system security measures - Section 5.1.4.1.1 o Enforce system security measures (Section 5.1.4.1.1).
o Store access token hashes only - Section 5.1.4.1.3 o Store access token hashes only (Section 5.1.4.1.3).
o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2 o Enforce standard SQL injection countermeasures
(Section 5.1.4.1.2).
4.3.3. Threat: Disclosure of client credentials during transmission 4.3.3. Threat: Disclosure of Client Credentials during Transmission
An attacker could attempt to eavesdrop the transmission of client An attacker could attempt to eavesdrop the transmission of client
credentials between client and server during the client credentials between the client and server during the client
authentication process or during OAuth token requests. authentication process or during OAuth token requests.
Impact: Revelation of a client credential enabling phishing or Impact: Revelation of a client credential enabling phishing or
impersonation of a client service. impersonation of a client service.
Countermeasures: Countermeasures:
o The transmission of client credentials must be protected using o The transmission of client credentials must be protected using
transport-layer mechanisms such as TLS (see Section 5.1.1). transport-layer mechanisms such as TLS (see Section 5.1.1).
o Alternative authentication means, which do not require to send o Use alternative authentication means that do not require the
plaintext credentials over the wire (e.g. Hash-based Message sending of plaintext credentials over the wire (e.g., Hash-based
Authentication Code) Message Authentication Code).
4.3.4. Threat: Obtain client secret from authorization server database 4.3.4. Threat: Obtaining 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.
client_id/secret combinations. This allows the attacker to act on
behalf of legitimate clients. Impact: Disclosure of all "client_id"/secret combinations. This
allows the attacker to act on behalf of legitimate clients.
Countermeasures: Countermeasures:
o Enforce system security measures - Section 5.1.4.1.1 o Enforce system security measures (Section 5.1.4.1.1).
o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2 o Enforce standard SQL injection countermeasures
(Section 5.1.4.1.2).
o Ensure proper handling of credentials as per Enforce credential o Ensure proper handling of credentials as per "Enforce Credential
storage protection best practices. Storage Protection Best Practices" (Section 5.1.4.1).
4.3.5. Threat: Obtain client secret by online guessing 4.3.5. Threat: Obtaining 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.
disclosure of single client_id/secret pair.
Impact: Disclosure of a single "client_id"/secret pair.
Countermeasures: Countermeasures:
o Use high entropy for secrets - Section 5.1.4.2.2 o Use high entropy for secrets (Section 5.1.4.2.2).
o Lock accounts - Section 5.1.4.2.3 o Lock accounts (Section 5.1.4.2.3).
o Use Strong Client Authentication - Section 5.2.3.7 o Use strong client authentication (Section 5.2.3.7).
4.4. Obtaining Authorization 4.4. Obtaining Authorization
This section covers threats which are specific to certain flows This section covers threats that 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
token 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 the 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
in different ways: in different ways:
o Referrer headers: browsers frequently pass a "referer" header when o Referrer headers: Browsers frequently pass a "referer" header when
a web page embeds content, or when a user travels from one web a web page embeds content, or when a user travels from one web
page to another web page. These referrer headers may be sent even page to another web page. These referrer headers may be sent even
when the origin site does not trust the destination site. The when the origin site does not trust the destination site. The
referrer header is commonly logged for traffic analysis purposes. referrer header is commonly logged for traffic analysis purposes.
o Request logs: web server request logs commonly include query o Request logs: Web server request logs commonly include query
parameters on requests. parameters on requests.
o Open redirectors: web sites sometimes need to send users to o Open redirectors: Web sites sometimes need to send users to
another destination via a redirector. Open redirectors pose a another destination via a redirector. Open redirectors pose a
particular risk to web-based delegation protocols because the particular risk to web-based delegation protocols because the
redirector can leak verification codes to untrusted destination redirector can leak verification codes to untrusted destination
sites. sites.
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 similar attacks on the SAML protocol can be
found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1, found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1;
[gross-sec-analysis], and [Sec-Analysis]; and [OASIS.sstc-sec-analysis-response-01].
[OASIS.sstc-gross-sec-analysis-response-01].
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 (see Section 5.1.1). using transport-layer mechanisms such as TLS (see Section 5.1.1).
o The authorization server will require the client to authenticate o The authorization server will require the client to authenticate
wherever possible, so the binding of the authorization code to a wherever possible, so the binding of the authorization "code" to a
certain client can be validated in a reliable way (see certain client can be validated in a reliable way (see
Section 5.2.4.4). Section 5.2.4.4).
o Use short expiry time for authorization codes - Section 5.1.5.3 o Use short expiry time for authorization "codes" (Section 5.1.5.3).
o The authorization server should enforce a one time usage o The authorization server should enforce a one-time usage
restriction (see Section 5.1.5.4). restriction (see Section 5.1.5.4).
o If an Authorization Server observes multiple attempts to redeem an o If an authorization server observes multiple attempts to redeem an
authorization code, the Authorization Server may want to revoke authorization "code", the authorization server may want to revoke
all tokens granted based on the authorization code (see all tokens granted based on the authorization "code" (see
Section 5.2.1.1). Section 5.2.1.1).
o In the absence of these countermeasures, reducing scope o In the absence of these countermeasures, reducing scope
(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 redirect URI
URI in order to automatically cleanup the browser cache. in order to automatically clean up the browser cache.
4.4.1.2. Threat: Obtain authorization codes from authorization server 4.4.1.2. Threat: Obtaining Authorization "codes" from Authorization
database Server Database
This threat is applicable if the authorization server stores This threat is applicable if the authorization server stores
authorization codes as handles in a database. An attacker may obtain authorization "codes" as handles in a database. An attacker may
authorization codes from the authorization server's database by obtain authorization "codes" from the authorization server's database
gaining access to the database or launching a SQL injection attack. by gaining access to the database or launching a SQL injection
attack.
Impact: disclosure of all authorization codes, most likely along with Impact: Disclosure of all authorization "codes", most likely along
the respective redirect_uri and client_id values. with the respective "redirect_uri" and "client_id" values.
Countermeasures: Countermeasures:
o Best practices for credential storage protection should be o Best practices for credential storage protection should be
employed - Section 5.1.4.1 employed (Section 5.1.4.1).
o Enforce system security measures - Section 5.1.4.1.1 o Enforce system security measures (Section 5.1.4.1.1).
o Store access token hashes only - Section 5.1.4.1.3 o Store access token hashes only (Section 5.1.4.1.3).
o Standard SQL injection countermeasures - Section 5.1.4.1.2 o Enforce standard SQL injection countermeasures
(Section 5.1.4.1.2).
4.4.1.3. Threat: Online guessing of authorization codes 4.4.1.3. Threat: Online Guessing of Authorization "codes"
An attacker may try to guess valid authorization code values and send An attacker may try to guess valid authorization "code" values and
it using the grant type "code" in order to obtain a valid access send the guessed code value using the grant type "code" in order to
token. obtain a valid access token.
Impact: disclosure of single access token, probably also associated Impact: Disclosure of a single access token and probably also an
refresh token. associated refresh token.
Countermeasures: Countermeasures:
o Handle-based tokens must use high entropy: Section 5.1.4.2.2 o Handle-based tokens must use high entropy (Section 5.1.4.2.2).
o Assertion-based tokens should be signed: Section 5.1.5.9 o Assertion-based tokens should be signed (Section 5.1.5.9).
o Authenticate the client, adds another value the attacker has to o Authenticate the client; this adds another value that the attacker
guess - Section 5.2.3.4 has to guess (Section 5.2.3.4).
o Binding of authorization code to redirection URI, adds another o Bind the authorization "code" to the redirect URI; this adds
value the attacker has to guess - Section 5.2.4.5 another value that the attacker has to guess (Section 5.2.4.5).
o Use short expiry time for tokens - Section 5.1.5.3 o Use short expiry time for tokens (Section 5.1.5.3).
4.4.1.4. Threat: Malicious client obtains authorization 4.4.1.4. Threat: Malicious Client Obtains Authorization
A malicious client could pretend to be a valid client and obtain an A malicious client could pretend to be a valid client and obtain an
access authorization that way. The malicious client could even access authorization in this way. The malicious client could even
utilize screen scraping techniques in order to simulate the user utilize screen-scraping techniques in order to simulate a user's
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 maintained in resource servers and to
unauthorized access to them via the OAuth protocol. Based on this prevent unauthorized access to them via the OAuth protocol. Based on
assumption, the following countermeasures are available to cope with this assumption, the following countermeasures are available to cope
the threat. 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 redirect URI
URI against the pre-registered redirection URI, if one exists (see against the pre-registered redirect 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 does not neccesserily invalid client, whereas a valid redirect URI does not necessarily
indicate 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 level of confidence is
the redirect URI refers to the globally unique network endpoint of high, since the redirect URI refers to the globally unique network
this application whose fully qualified domain name (FQDN) is also endpoint of this application, whose fully qualified domain name
validated using HTTPS server authentication by the user agent. In (FQDN) is also validated using HTTPS server authentication by the
contrast for native clients, the redirect URI typically refers to user agent. In contrast, for native clients, the redirect URI
device local resources, e.g. a custom scheme. So a malicious typically refers to device local resources, e.g., a custom scheme.
client on a particular device can use the valid redirect URI the So, a malicious client on a particular device can use the valid
legitimate client uses on all other devices. redirect URI the legitimate client uses on all other devices.
o After authenticating the end-user, the authorization server should o After authenticating the end user, the authorization server should
ask him/her for consent. In this context, the authorization ask him/her for consent. In this context, the authorization
server should explain to the end-user the purpose, scope, and server should explain to the end user the purpose, scope, and
duration of the authorization the client asked for. Moreover, the duration of the authorization the client asked for. Moreover, the
authorization server should show the user any identity information authorization server should show the user any identity information
it has for that client. It is up to the user to validate the it has for that client. It is up to the user to validate the
binding of this data to the particular application (e.g. Name) binding of this data to the particular application (e.g., Name)
and to approve the authorization request. (see 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
authorizations for clients it is unable to reliably authenticate re-authorizations for clients it is unable to reliably
or validate (see Section 5.2.4.1). authenticate 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 (Completely prevent screen scraping. Examples are CAPTCHAs (Completely
Automated Public Turing test to tell Computers and Humans Apart) Automated Public Turing tests to tell Computers and Humans Apart)
or other multi-factor authentication techniques such as random or other multi-factor authentication techniques such as random
questions, token code generators, etc. 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,
the redirect URI is not local to the host where the user's browser is the redirect URI is not local to the host where the user's browser is
running. running.
Impact: This affects web applications and may lead to a disclosure of Impact: This affects web applications and may lead to a disclosure of
authorization codes and, potentially, the corresponding access and authorization "codes" and, potentially, the corresponding access and
refresh tokens. refresh tokens.
Countermeasures: Countermeasures:
It is strongly recommended that one of the following countermeasures It is strongly recommended that one of the following countermeasures
is utilized in order to prevent this attack: be utilized in order to prevent this attack:
o The redirection URI of the client should point to a HTTPS o The redirect URI of the client should point to an HTTPS-protected
protected endpoint and the browser should be utilized to endpoint, and the browser should be utilized to authenticate this
authenticate this redirection URI using server authentication (see redirect URI using server authentication (see Section 5.1.2).
Section 5.1.2).
o The authorization server should require the client to be o The authorization server should require that the client be
authenticated, i.e. confidential client, so the binding of the authenticated, i.e., confidential client, so the binding of the
authorization code to a certain client can be validated in a authorization "code" to a certain client can be validated in a
reliable way (see Section 5.2.4.4). reliable way (see Section 5.2.4.4).
4.4.1.6. Threat: User session impersonation 4.4.1.6. Threat: User Session Impersonation
A hostile party could impersonate the client site and impersonate the A hostile party could impersonate the client site and impersonate the
user's session on this client. This could be achieved using DNS or user's session on this client. This could be achieved using DNS or
ARP spoofing. This applies to clients, which are web applications, ARP spoofing. This applies to clients, which are web applications;
thus the redirect URI is not local to the host where the user's thus, the redirect URI is not local to the host where the user's
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 "Login" button to to a social site (e.g., as in the implementation of a "Login" button
a third-party social network site), the attacker can use the on a third-party social network site), the attacker can use the
intercepted authorization code to log in to the client as the user. intercepted authorization "code" to log into 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
that obtains the tokens. client 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-user's
session, the redirection URI of the client should point to a HTTPS session, the redirect URI of the client should point to an HTTPS
protected endpoint and the browser should be utilized to protected endpoint, and the browser should be utilized to
authenticate this redirection URI using server authentication (see authenticate this redirect URI using server authentication (see
Section 5.1.2) Section 5.1.2).
4.4.1.7. Threat: Authorization code leakage through counterfeit client 4.4.1.7. Threat: Authorization "code" Leakage through Counterfeit
Client
The attack leverages the authorization code grant type in an attempt The attacker leverages the authorization "code" grant type in an
to get another user (victim) to log-in, authorize access to his/her attempt to get another user (victim) to log in, authorize access to
resources, and subsequently obtain the authorization code and inject his/her resources, and subsequently obtain the authorization "code"
it into a client application using the attacker's account. The goal and inject it into a client application using the attacker's account.
is to associate an access authorization for resources of the victim The goal is to associate an access authorization for resources of the
with the user account of the attacker on a client site. victim with the user account of the attacker on a client site.
The attacker abuses an existing client application and combines it The attacker abuses an existing client application and combines it
with his own counterfeit client web site. The attack depends on the with his own counterfeit client web site. The attacker depends on
victim expecting the client application to request access to a the victim expecting the client application to request access to a
certain resource server. The victim, seeing only a normal request certain resource server. The victim, seeing only a normal request
from an expected application, approves the request. The attacker from an expected application, approves the request. The attacker
then uses the victim's authorization to gain access to the then uses the victim's authorization to gain access to the
information unknowingly authorized by the victim. information unknowingly authorized by the victim.
The attacker conducts the following flow: The attacker conducts the following flow:
1. The attacker accesses the client web site (or application) and 1. The attacker accesses the client web site (or application) and
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 redirect URI parameter referring to a web
web site under his control (attacker's web site). 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) into opening that
modified end-user authorization URI and to authorize access (e.g. modified end-user authorization URI and authorizing access (e.g.,
an email link, or blog link). The way the attacker achieves that via an email link or blog link). The way the attacker achieves
goal is out of scope. this 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
means out of scope of this document. by means that are out of scope of this document.
6. He then constructs a redirection URI to the target web site (or 6. He then constructs a redirect 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 redirect 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
the authorization server and associates this token with the from 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 victim's resources using the 8. The attacker may now access the victim's resources using the
client site. client site.
Impact: The attacker 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 redirect URI for its
authorization process rather than the target web site because it authorization process rather than the target web site because it
needs to intercept the flow. So if the authorization server needs to intercept the flow. So, if the authorization server
associates the authorization code with the redirection URI of a associates the authorization "code" with the redirect URI of a
particular end-user authorization and validates this redirection particular end-user authorization and validates this redirect URI
URI with the redirection URI passed to the token's endpoint, such with the redirect URI passed to the token's endpoint, such an
an attack is detected (see Section 5.2.4.5). 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 authorization code disclosure to allow for early recognition of authorization "code" disclosure to
counterfeit clients. counterfeit clients.
o For native applications, one could also consider to use o For native applications, one could also consider using deployment-
deployment-specific client ids and secrets (see Section 5.2.3.4, specific client ids and secrets (see Section 5.2.3.4), along with
along with the binding of authorization code to client_id (see the binding of authorization "codes" to "client_ids" (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 to the deployment-specific secret. Thus, he
not be able to exchange the authorization code. will 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 that are not vulnerable
vulnerable to this kind of attack such as "Implicit Grant" or to this kind of attack, such as the implicit grant type (see
"Resource Owner Password Credentials" (see Section 4.4.2 or Section 4.4.2) or resource owner password credentials (see
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 web site trusts or has
authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
on OAuth approvals can allow an attacker to obtain authorization to on OAuth approvals can allow an attacker to obtain authorization to
OAuth protected resources without the consent of the User. OAuth protected resources without the consent of the user.
This attack works against the redirection URI used in the This attack works against the redirect URI used in the authorization
authorization code flow. An attacker could authorize an "code" flow. An attacker could authorize an authorization "code" to
authorization code to their own protected resources on an their own protected resources on an authorization server. He then
authorization server. He then aborts the redirect flow back to the aborts the redirect flow back to the client on his device and tricks
client on his device and tricks the victim into executing the the victim into executing the redirect back to the client. The
redirect back to the client. The client receives the redirect, client receives the redirect, fetches the token(s) from the
fetches the token(s) from the authorization server and associates the authorization server, and associates the victim's client session with
victim's client session with the resources accessible using the the resources accessible using the token.
token.
Impact: The user accesses resources on behalf of the attacker. The Impact: The user accesses resources on behalf of the attacker. The
effective impact depends on the type of resource accessed. For effective impact depends on the type of resource accessed. For
example, the user may upload private items to an attacker's example, the user may upload private items to an attacker's
resources. Or when using OAuth in 3rd party login scenarios, the resources. Or, when using OAuth in 3rd-party login scenarios, the
user may associate his client account with the attacker's 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. In this way, the attacker could
access the victim's data at the client by logging in from another easily access the victim's data at the client by logging in from
device with his credentials at the external identity provider. another 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 redirect URI used to deliver the access token
Section 5.3.5 (Section 5.3.5).
o Client developers and end-user can be educated to not follow o Client developers and end users 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 (see [iFrame]) overlaid on top of a set of dummy transparent iFrame (see [iFrame]) overlaid on top of a set of dummy
buttons which are carefully constructed to be placed directly under buttons that are carefully constructed to be placed directly under
important buttons on the target site. When a user clicks a visible important buttons on the target site. When a user clicks a visible
button, they are actually clicking a button (such as an "Authorize" button, they are actually clicking a button (such as an "Authorize"
button) on the hidden page. 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 Countermeasures:
o For newer browsers, avoidance of iFrames during authorization can o For newer browsers, avoidance of iFrames during authorization can
be enforced server side by using the X-FRAME-OPTION header - be enforced on the server side by using the X-FRAME-OPTIONS header
Section 5.2.2.6 (Section 5.2.2.6).
o For older browsers, javascript frame-busting (see [framebusting]) o For older browsers, JavaScript frame-busting (see [Framebusting])
techniques can be used 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 victim's 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 splits 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
send the corresponding form post requests. As a pre-requisite, the send the corresponding form HTTP POST requests. As a prerequisite,
attacker must be able to execute the authorization process in the the attacker must be able to execute the authorization process in the
context of an already authenticated session of the resource owner context of an already-authenticated session of the resource owner
with the authorization server. There are different ways to achieve with the authorization server. There are different 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 The malicious client could also request authorization for an o The malicious client could also request authorization for an
initial scope acceptable to the user and then silently abuse the initial scope acceptable to the user and then silently abuse the
resulting session in his browser instance to "silently" request resulting session in his browser instance to "silently" request
another scope. 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, either within the user agent or as a 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 detect and prevent this associated with this threat, whether to detect and prevent 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 a 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 sent out of band to the resource owner o use one-time secrets sent out of band to the resource owner (e.g.,
(e.g. via text or instant message). 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. email.
4.4.1.11. Threat: DoS, Exhaustion of resources attacks 4.4.1.11. Threat: DoS Attacks That Exhaust Resources
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
codes/tokens) and automatically grants either without user possible 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 codes or access tokens per user, an
attacker could exhaust the pool of authorization codes by repeatedly attacker could exhaust the pool of authorization "codes" by
directing the user's browser to request code or access tokens. repeatedly directing the user's browser to request authorization
"codes" or access tokens.
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.
include a nontrivial amount of entropy in authorization codes.
4.4.1.12. Threat: DoS using manufactured authorization codes o The authorization server should include a nontrivial amount of
entropy in 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",
cause a large number of HTTPS connections to be concentrated onto the and cause a large number of HTTPS connections to be concentrated onto
authorization server. This can result in a DoS attack on the the authorization server. This can result in a denial-of-service
authorization server. (DoS) attack on the 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 (see Section 4.4.1.8) is deployed on the client side. With parameter (see Section 4.4.1.8) is deployed on the client side. With
such a defense, the attacker might need to incur an additional HTTP such a defense, the attacker might need to incur an additional HTTP
request to obtain a valid CSRF code/ state parameter. This request to obtain a valid CSRF code/"state" parameter. This
apparently cuts down the effectiveness of the attack by a factor of apparently cuts down the effectiveness of the attack by a factor of
2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
factor is estimated to be around 3.5x at [ssl-latency]) the attacker factor is estimated to be around 3.5x at [SSL-Latency]), the attacker
still achieves a magnification of resource utilization at the expense still achieves a magnification of resource utilization at the expense
of the authorization server. 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 as rate limiting on the offending attacker. Defenses such as rate-limiting on the offending
attacker machines are less effective due to the difficulty to attacker machines are less effective because it is difficult to
identify the attacking machines. Although an attacker could also identify the attacking machines. Although an attacker could also
launder its connections through an anonymizing system such as launder its connections through an anonymizing system such as
Tor, the effectiveness of that approach depends on the capacity Tor, the effectiveness of that approach depends on the capacity
of the anonymizing system. On the other hand, a potentially of the anonymizing system. On the other hand, a potentially
large number 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; the attacker can coordinate the timing
timing of such HTTPS connections across multiple clients of such HTTPS connections across multiple clients relatively
relatively easily. Although the attacker could achieve something easily. Although the attacker could achieve something similar,
similar, say, by including an iframe pointing to the HTTPS URL of say, by including an iFrame pointing to the HTTPS URL of the
the authorization server in an HTTP web page and lure web users authorization server in an HTTP web page and luring web users to
to visit that page, timing attacks using such a scheme may be visit that page, timing attacks using such a scheme may be more
more difficult as it seems nontrivial to synchronize a large difficult, as it seems nontrivial to synchronize a large number
number of users to simultaneously visit a particular site under of users to simultaneously visit a particular site under the
the attacker's control. 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
CSRF token and the 'state' parameter are validated. the CSRF token and the "state" parameter are validated.
o If the client authenticates the user, either through a single- o If the client authenticates the user, either through a single-
sign-on protocol or through local authentication, the client sign-on protocol or through local authentication, the client
should suspend the access by a user account if the number of should suspend the access by a user account if the number of
invalid authorization codes submitted by this user exceeds a invalid authorization "codes" submitted by 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.
4.4.1.13. Threat: Code substitution (OAuth Login) 4.4.1.13. Threat: Code Substitution (OAuth Login)
An attacker could attempt to login to an application or web site An attacker could attempt to log into an application or web site
using a victim's identity. Applications relying on identity data using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios. "social login" scenarios.
As a pre-requisite, a resource server offers an API to obtain As a prerequisite, a resource server offers an API to obtain personal
personal information about a user which could be interpreted as information about a user that could be interpreted as having obtained
having obtained a user identity. In this sense the client is a user identity. In this sense, the client is treating the resource
treating the resource server API as an "identity" API. A client server API as an "identity" API. A client utilizes OAuth to obtain
utilizes OAuth to obtain an access token for the identity API. It an access token for the identity API. It then queries the identity
then queries the identity API for an identifier and uses it to look API for an identifier and uses it to look up its internal user
up its internal user account data (login). The client asssumes that account data (login). The client assumes that, because it was able
because it was able to obtain information about the user, that the to obtain information about the user, the user has been
user has been authenticated. authenticated.
If the client uses the grant type "code", the attacker needs to If the client uses the grant type "code", the attacker needs to
gather a valid authorization code of the respective victim from the gather a valid authorization "code" of the respective victim from the
same identity provider used by the target client application. The same Identity Provider used by the target client application. The
attacker tricks the victim into login into a malicious app (which may attacker tricks the victim into logging into a malicious app (which
appear to be legitimate to the Identity Provider) using the same may appear to be legitimate to the Identity Provider) using the same
identity provider as the target application. This results in the Identity Provider as the target application. This results in the
Identity Provider's authorization server issuing an authorization Identity Provider's authorization server issuing an authorization
code for the respective identity API. The malicious app then sends "code" for the respective identity API. The malicious app then sends
this code to the attacker, which in turn triggers a login process this code to the attacker, which in turn triggers a login process
within the target application. The attacker now manipulates the within the target application. The attacker now manipulates the
authorization response and substitutes their code (bound to their authorization response and substitutes their code (bound to their
identity) for the victim's code. This code is then exchanged by the identity) for the victim's code. This code is then exchanged by the
client for an access token, which in turn is accepted by the identity client for an access token, which in turn is accepted by the identity
API since the audience, with respect to the resource server, is API, since the audience, with respect to the resource server, is
correct. But since the identifier returned by the identity API is correct. But since the identifier returned by the identity API is
determined by the identity in the access token (issued based on the determined by the identity in the access token (issued based on the
victim's code), the attacker is logged into the target application victim's code), the attacker is logged into the target application
under the victim's identity. under the victim's identity.
Impact: the attacker gains access to an application and user-specific Impact: The attacker gains access to an application and user-specific
data within the application. data within the application.
Countermeasures: Countermeasures:
o All clients must indicate their client id with every request to o All clients must indicate their client ids with every request to
exchange an authorization code for an access token. The exchange an authorization "code" for an access token. The
authorization server must validate whether the particular authorization server must validate whether the particular
authorization code has been issued to the particular client. If authorization "code" has been issued to the particular client. If
possible, the client shall be authenticated beforehand. possible, the client shall be authenticated beforehand.
o Clients should use appropriate protocol, such as OpenID (cf. o Clients should use an appropriate protocol, such as OpenID (cf.
[openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on implement user login. Both support audience restrictions on
clients. clients.
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 redirect URI. It is
is assumed that the token is not sent to the redirection URI target assumed that the token is not sent to the redirect URI target, as
as HTTP user agents do not send the fragment part of URIs to HTTP 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 the token cannot leak through HTTP referrer
headers.
4.4.2.1. Threat: Access token leak in transport/end-points 4.4.2.1. Threat: Access Token Leak in Transport/Endpoints
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 the server to the client via a URI fragment of the redirect URI.
the communication is not secured or the end-point is not secured, the If the communication is not secured or the endpoint is not secured,
token could be leaked by parsing the returned URI. the 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 (e.g. using o The authorization server should ensure confidentiality (e.g.,
TLS) of the response from the authorization server to the client using TLS) of the response from the authorization server to the
(see Section 5.1.1). client (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. that this means the attacker needs access to the particular device.
Countermeasures: Countermeasures:
o Use short expiry time for tokens (see Section 5.1.5.3) and reduced o Use short expiry time for tokens (see Section 5.1.5.3). Reduced
scope of the token may reduce the impact of that attack (see scope of the token may reduce the impact of that attack (see
Section 5.1.5.1). Section 5.1.5.1).
o Make responses non-cachable o Make responses non-cacheable.
4.4.2.3. Threat: Malicious client obtains authorization 4.4.2.3. Threat: Malicious Client Obtains Authorization
A malicious client could attempt to obtain a token by fraud. A malicious client could attempt to obtain a token by fraud.
The same countermeasures as for Section 4.4.1.4 are applicable, The same countermeasures as for Section 4.4.1.4 are applicable,
except client authentication. except client authentication.
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.
Impact: The attacker could obtain user credential information and Impact: The attacker could obtain user credential information and
assume the full identity of the user. assume the full identity of the user.
Countermeasures: Countermeasures:
o The authorization server should authenticate the server from which o The authorization server should authenticate the server from which
scripts are obtained (see Section 5.1.2). scripts are obtained (see Section 5.1.2).
o The client should ensure that scripts obtained have not been o The client should ensure that scripts obtained have not been
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. attacker's modified code.
4.4.2.5. Threat: CSRF attack against redirect-uri 4.4.2.5. Threat: CSRF Attack against redirect-uri
CSRF attacks (see Section 4.4.1.8) also work against the redirection CSRF attacks (see Section 4.4.1.8) also work against the redirect URI
URI used in the implicit grant flow. An attacker could acquire an used in the implicit grant flow. An attacker could acquire an access
access token to their own protected resources. He could then token to their own protected resources. He could then construct a
construct a redirection URI and embed their access token in that URI. redirect URI and embed their access token in that URI. If he can
If he can trick the user into following the redirection URI and the trick the user into following the redirect URI and the client does
client does not have protection against this attack, the user may not have protection against this attack, the user may have the
have the attacker's access token authorized within their client. 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. In this way, the attacker could
access the victim's data at the client by logging in from another easily access the victim's data at the client by logging in from
device with his credentials at the external identity provider. another 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 deliver the access token. request with the redirect URI used to deliver the access token.
This will ensure the client is not tricked into completing any This will ensure that the client is not tricked into completing
redirect callback unless it is linked to an authorization request any redirect callback unless it is linked to an authorization
the client initiated. The state parameter should be unguessable request initiated by the client. The "state" parameter should not
and the client should be capable of keeping the state parameter be guessable, and the client should be capable of keeping the
secret. "state" parameter secret.
o Client developers and end-user can be educated not follow o Client developers and end users can be educated to not follow
untrusted URLs. untrusted URLs.
4.4.2.6. Threat: Token substitution (OAuth Login) 4.4.2.6. Threat: Token Substitution (OAuth Login)
An attacker could attempt to login to an application or web site An attacker could attempt to log into an application or web site
using a victim's identity. Applications relying on identity data using a victim's identity. Applications relying on identity data
provided by an OAuth protected service API to login users are provided by an OAuth protected service API to login users are
vulnerable to this threat. This pattern can be found in so-called vulnerable to this threat. This pattern can be found in so-called
"social login" scenarios. "social login" scenarios.
As a pre-requisite, a resource server offers an API to obtain As a prerequisite, a resource server offers an API to obtain personal
personal information about a user which could be interpreted as information about a user that could be interpreted as having obtained
having obtained a user identity. In this sense the client is a user identity. In this sense, the client is treating the resource
treating the resource server API as an "identity" API. A client server API as an "identity" API. A client utilizes OAuth to obtain
utilizes OAuth to obtain an access token for the identity API. It an access token for the identity API. It then queries the identity
then queries the identity API for an identifier and uses it to look API for an identifier and uses it to look up its internal user
up its internal user account data (login). The client asssumes that account data (login). The client assumes that, because it was able
because it was able to obtain information about the user, that the to obtain information about the user, the user has been
user has been authenticated. authenticated.
To succeed, the attacker needs to gather a valid access token of the To succeed, the attacker needs to gather a valid access token of the
respective victim from the same identity provider used by the target respective victim from the same Identity Provider used by the target
client application. The attacker tricks the victim into login into a client application. The attacker tricks the victim into logging into
malicious app (which may appear to be legitimate to the Identity a malicious app (which may appear to be legitimate to the Identity
Provider) using the same identity provider as the target application. Provider) using the same Identity Provider as the target application.
This results in the Identity Provider's authorization server issuing This results in the Identity Provider's authorization server issuing
an access token for the respective identity API. The malicious app an access token for the respective identity API. The malicious app
then sends this access token to the attacker, which in turn triggers then sends this access token to the attacker, which in turn triggers
a login process within the target application. The attacker now a login process within the target application. The attacker now
manipulates the authorization response and substitutes their access manipulates the authorization response and substitutes their access
token (bound to their identity) for the victim's access token. This token (bound to their identity) for the victim's access token. This
token is accepted by the identity API since the audience, with token is accepted by the identity API, since the audience, with
respect to the resource server, is correct. But since the identifier respect to the resource server, is correct. But since the identifier
returned by the identity API is determined by the identity in the returned by the identity API is determined by the identity in the
access token, the attacker is logged into the target application access token, the attacker is logged into the target application
under the victim's identity. under the victim's identity.
Impact: the attacker gains access to an application and user-specific Impact: The attacker gains access to an application and user-specific
data within the application. data within the application.
Countermeasures: Countermeasures:
o Clients should use appropriate protocol, such as OpenID (cf. o Clients should use an appropriate protocol, such as OpenID (cf.
[openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to [OPENID]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
implement user login. Both support audience restrictions on implement user login. Both support audience restrictions on
clients. clients.
4.4.3. Resource Owner Password Credentials 4.4.3. Resource Owner Password Credentials
The "Resource Owner Password Credentials" grant type (see The resource owner password credentials grant type (see [RFC6749],
[I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration Section 4.3), often used for legacy/migration reasons, allows a
reasons, allows a client to request an access token using an end- client to request an access token using an end-user's user id and
users user-id and password along with its own credential. This grant password along with its own credential. This grant type has higher
type has higher risk because it maintains the uid/password anti- risk because it maintains the UID/password anti-pattern.
pattern. Additionally, because the user does not have control over Additionally, because the user does not have control over the
the authorization process, clients using this grant type are not authorization process, clients using this grant type are not limited
limited by scope, but instead have potentially the same capabilities by scope but instead have potentially the same capabilities as the
as the user themselves. As there is no authorization step, the user themselves. As there is no authorization step, the ability to
ability to offer token revocation is bypassed. offer token revocation is bypassed.
Because passwords are often used for more than 1 service, this anti- Because passwords are often used for more than 1 service, this
pattern may also risk whatever else is accessible with the supplied anti-pattern may also put at risk whatever else is accessible with
credential. Additionally any easily derived equivalent (e.g. the supplied credential. Additionally, any easily derived equivalent
joe@example.com and joe@example.net) might easily allow someone to (e.g., joe@example.com and joe@example.net) might easily allow
guess that the same password can be used elsewhere. 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-lived tokens and pass them up to an
web service for further abuse. The client, eavesdroppers, or end- attacker's web service for further abuse. The client, eavesdroppers,
points could eavesdrop user id and password. or endpoints could eavesdrop the 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 specification, the authorization server must
that these transmissions are protected using transport-layer ensure that these transmissions are protected using transport-
mechanisms such as TLS (see Section 5.1.1). layer mechanisms such as TLS (see Section 5.1.1).
o Rather than encouraging users to use a uid and password, service o Rather than encouraging users to use a UID and password, service
providers should instead encourage users not to use the same providers should instead encourage users not to use the same
password for multiple services. password for multiple services.
o Limit use of Resource Owner Password Credential grants to o Limit use of resource owner password credential grants to
scenarios where the client application and the authorizing service scenarios where the client application and the authorizing service
are from the same organization. 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 that do not rely on the client's cooperation for
secure resource owner credential handling secure resource owner credential handling.
o Use digest authentication instead of plaintext credential o Use digest authentication instead of plaintext credential
processing processing.
o Obfuscate passwords in logs o Obfuscate passwords in logs.
4.4.3.2. Threat: Client obtains scopes without end-user authorization 4.4.3.2. Threat: Client Obtains Scopes without End-User Authorization
All interaction with the resource owner is performed by the client. All interaction with the resource owner is performed by the client.
Thus it might, intentionally or unintentionally, happen that the Thus it might, intentionally or unintentionally, happen that the
client obtains a token with scope unknown for or unintended by the client obtains a token with scope unknown for, or unintended by, the
resource owner. For example, the resource owner might think the resource owner. For example, the resource owner might think the
client needs and acquires read-only access to its media storage only client needs and acquires read-only access to its media storage only
but the client tries to acquire an access token with full access but the client tries to acquire an access token with full access
permissions. permissions.
Countermeasures: Countermeasures:
o Use other flows, which do not rely on the client's cooperation for o Use other flows that do not rely on the client's cooperation for
resource owner interaction resource owner interaction.
o The authorization server may generally restrict the scope of o The authorization server may generally restrict the scope of
access tokens (Section 5.1.5.1) issued by this flow. If the access tokens (Section 5.1.5.1) issued by this flow. If the
particular client is trustworthy and can be authenticated in a particular client is trustworthy and can be authenticated in a
reliable way, the authorization server could relax that reliable way, the authorization server could relax that
restriction. Resource owners may prescribe (e.g. in their restriction. Resource owners may prescribe (e.g., in their
preferences) what the maximum scope is for clients using this preferences) what the maximum scope is for clients using this
flow. flow.
o The authorization server could notify the resource owner by an o The authorization server could notify the resource owner by an
appropriate media, e.g. e-Mail, of the grant issued (see appropriate medium, e.g., email, of the grant issued (see
Section 5.1.3). Section 5.1.3).
4.4.3.3. Threat: Client obtains refresh token through automatic 4.4.3.3. Threat: Client Obtains Refresh Token through Automatic
authorization Authorization
All interaction with the resource owner is performed by the client. All interaction with the resource owner is performed by the client.
Thus it might, intentionally or unintentionally, happen that the Thus it might, intentionally or unintentionally, happen that the
client obtains a long-term authorization represented by a refresh client obtains a long-term authorization represented by a refresh
token even if the resource owner did not intend so. token even if the resource owner did not intend so.
Countermeasures: Countermeasures:
o Use other flows, which do not rely on the client's cooperation for o Use other flows that do not rely on the client's cooperation for
resource owner interaction resource owner interaction.
o The authorization server may generally refuse to issue refresh o The authorization server may generally refuse to issue refresh
tokens in this flow (see Section 5.2.2.1). If the particular tokens in this flow (see Section 5.2.2.1). If the particular
client is trustworthy and can be authenticated in a reliable way client is trustworthy and can be authenticated in a reliable way
(see client authentication), the authorization server could relax (see client authentication), the authorization server could relax
that restriction. Resource owners may allow or deny (e.g. in that restriction. Resource owners may allow or deny (e.g., in
their preferences) to issue refresh tokens using this flow as their preferences) the issuing of refresh tokens using this flow
well. as well.
o The authorization server could notify the resource owner by an o The authorization server could notify the resource owner by an
appropriate media, e.g. e-Mail, of the refresh token issued (see appropriate medium, e.g., email, of the refresh token issued (see
Section 5.1.3). Section 5.1.3).
4.4.3.4. Threat: Obtain user passwords on transport 4.4.3.4. Threat: Obtaining User Passwords on Transport
An attacker could attempt to eavesdrop the transmission of end-user An attacker could attempt to eavesdrop the transmission of end-user
credentials with the grant type "password" between client and server. credentials with the grant type "password" between the client and
server.
Impact: disclosure of a single end-users password. Impact: Disclosure of a single end-user's password.
Countermeasures: Countermeasures:
o Ensure confidentiality of requests - Section 5.1.1 o Ensure confidentiality of requests (Section 5.1.1).
o alternative authentication means, which do not require to send o Use alternative authentication means that do not require the
plaintext credentials over the wire (e.g. Hash-based Message sending of plaintext credentials over the wire (e.g., Hash-based
Authentication Code) Message Authentication Code).
4.4.3.5. Threat: Obtain user passwords from authorization server 4.4.3.5. Threat: Obtaining User Passwords from Authorization Server
database Database
An attacker may obtain valid username/password combinations from the An attacker may obtain valid username/password combinations from the
authorization server's database by gaining access to the database or authorization server's database by gaining access to the database or
launching a SQL injection attack. launching a SQL injection attack.
Impact: disclosure of all username/password combinations. The impact Impact: Disclosure of all username/password combinations. The impact
may exceed the domain of the authorization server since many users may exceed the domain of the authorization server, since many users
tend to use the same credentials on different services. tend to use the same credentials on different services.
Countermeasures: Countermeasures:
o Enforce credential storage protection best practices - o Enforce credential storage protection best practices
Section 5.1.4.1 (Section 5.1.4.1).
4.4.3.6. Threat: Online guessing 4.4.3.6. Threat: Online Guessing
An attacker may try to guess valid username/password combinations An attacker may try to guess valid username/password combinations
using the grant type "password". using the grant type "password".
Impact: Revelation of a single username/password combination. Impact: Revelation of a single username/password combination.
Countermeasures: Countermeasures:
o Utilize secure password policy - Section 5.1.4.2.1 o Utilize secure password policy (Section 5.1.4.2.1).
o Lock accounts - Section 5.1.4.2.3 o Lock accounts (Section 5.1.4.2.3).
o Use tar pit - Section 5.1.4.2.4 o Use tar pit (Section 5.1.4.2.4).
o Use CAPTCHAs - Section 5.1.4.2.5 o Use CAPTCHAs (Section 5.1.4.2.5).
o Consider not to use grant type "password"
o Consider not using the 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 [RFC6749], 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 those described in Section 4.4.3.
4.5. Refreshing an Access Token 4.5. Refreshing an Access Token
4.5.1. Threat: Eavesdropping refresh tokens from authorization server 4.5.1. Threat: Eavesdropping Refresh Tokens from Authorization Server
An attacker may eavesdrop refresh tokens when they are transmitted An attacker may eavesdrop refresh tokens when they are transmitted
from the authorization server to the client. from the authorization server to the client.
Countermeasures: Countermeasures:
o 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 (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
tokens as handles in a database. An attacker may obtain refresh tokens as handles in a database. An attacker may obtain refresh
tokens from the authorization server's database by gaining access to tokens from the authorization server's database by gaining access to
the database or launching a SQL injection attack. the database or launching a SQL injection attack.
Impact: disclosure of all refresh tokens Impact: Disclosure of all refresh tokens.
Countermeasures: Countermeasures:
o Enforce credential storage protection best practices - o Enforce credential storage protection best practices
Section 5.1.4.1 (Section 5.1.4.1).
o Bind token to client id, if the attacker cannot obtain the o Bind token to client id, if the attacker cannot obtain the
required id and secret - Section 5.1.5.8 required id and secret (Section 5.1.5.8).
4.5.3. Threat: Obtain refresh token by online guessing 4.5.3. Threat: Obtaining 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 a single refresh token and derivable access
tokens.
Countermeasures: Countermeasures:
o For handle-based designs - Section 5.1.4.2.2 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; this adds another element that the
guess (see Section 5.2.3.4) attacker has to guess (see Section 5.2.3.4).
4.5.4. Threat: Obtain refresh token phishing by counterfeit 4.5.4. Threat: Refresh Token Phishing by Counterfeit Authorization
authorization server Server
An attacker could try to obtain valid refresh tokens by proxying An attacker could try to obtain valid refresh tokens by proxying
requests to the authorization server. Given the assumption that the requests to the authorization server. Given the assumption that the
authorization server URL is well-known at development time or can at authorization server URL is well-known at development time or can at
least be obtained from a well-known resource server, the attacker least be obtained from a well-known resource server, the attacker
must utilize some kind of spoofing in order to succeed. must utilize some kind of spoofing in order to succeed.
Countermeasures: Countermeasures:
o Utilize server authentication (as described in Section 5.1.2) o Utilize server authentication (as described in Section 5.1.2).
4.6. Accessing Protected Resources 4.6. Accessing Protected Resources
4.6.1. Threat: Eavesdropping access tokens on transport 4.6.1. Threat: Eavesdropping Access Tokens on Transport
An attacker could try to obtain a valid access token on transport An attacker could try to obtain a valid access token on transport
between client and resource server. As access tokens are shared between the client and resource server. As access tokens are shared
secrets between authorization and resource server, they should be secrets between the authorization server and resource server, they
treated with the same care as other credentials (e.g. end-user should be treated with the same care as other credentials (e.g., end-
passwords). user 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 (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 identifier 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 of 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 measures o The resource server should utilize transport security measures
(e.g. TLS) in order to prevent such attacks (see Section 5.1.1). (e.g., TLS) in order to prevent such attacks (see Section 5.1.1).
This would 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 nonces 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 attempt to guess the
the access token values based on knowledge they have from other access token values based on knowledge they have from other access
access tokens. 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 level of entropy (see
Section 5.1.4.2.2) in order to make guessing a valid token value Section 5.1.4.2.2) in order to make guessing a valid token value
infeasible. infeasible.
o Assertion (or self-contained token ) tokens contents should be o Assertion (or self-contained token) token 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 Sections 5.1.5.2 and 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 token 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 URL is well-known to of a secure channel. If the resource server URL is well-known 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 URL 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 the association at a legitimate resource server. The
URL validation policy may be strict (exact match) or more relaxed endpoint URL validation policy may be strict (exact match) or more
(e.g. same host). This would require to tell the authorization relaxed (e.g., same host). This would require telling the
server the resource server endpoint URL in the authorization authorization server about the resource server endpoint URL in the
process. authorization 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 a signature,
order to not disclose secret to a potential attacker). This in order to not disclose a 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
lack the capability 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 server. Similarly, a client could try to use
use a token obtained for one server on another resource server. 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 An OAuth HTTP authentication scheme as discussed in [RFC6749] is
optional. However, [RFC2616] relies on the Authorization and WWW- optional. However, [RFC2616] relies on the Authorization and
Authenticate headers to distinguish authenticated content so that it WWW-Authenticate headers to distinguish authenticated content so that
can be protected. Proxies and caches, in particular, may fail to it can be protected. Proxies and caches, in particular, may fail to
adequately protect requests not using these headers. For example, adequately protect requests not using these headers. For example,
private authenticated content may be stored in (and thus retrievable private authenticated content may be stored in (and thus be
from) publicly-accessible caches. retrievable from) publicly accessible caches.
Countermeasures: Countermeasures:
o Clients and resource servers not using the HTTP Authorization o Clients and resource servers not using an OAuth HTTP
scheme (OAuth HTTP Authorization Scheme - see Section 5.4.1) authentication scheme (see Section 5.4.1) should take care to use
should take care to use Cache-Control headers to minimize the risk Cache-Control headers to minimize the risk that authenticated
that authenticated content is not protected. Such Clients should content is not protected. Such clients should send a
send a Cache-Control header containing the "no-store" option Cache-Control header containing the "no-store" option [RFC2616].
[RFC2616]. Resource server success (2XX status) responses to Resource server success (2XX status) responses to these requests
these requests should contain a Cache-Control header with the should contain a Cache-Control header with the "private" option
"private" option [RFC2616]. [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 Log Files 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 the HTTP "referer". 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 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 by
one time token usage (see Section 5.1.5.4). enforcing 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 described in Section 4.
5.1. General 5.1. General
The general section covers considerations that apply generally across This section covers considerations that apply generally across all
all OAuth components (client, resource server, token server, and OAuth components (client, resource server, token server, and user
user-agents). agents).
5.1.1. Ensure confidentiality of requests 5.1.1. Ensure Confidentiality of Requests
This is applicable to all requests sent from client to authorization This is applicable to all requests sent from the client to the
server or resource server. While OAuth provides a mechanism for authorization server or resource server. While OAuth provides a
verifying the integrity of requests, it provides no guarantee of mechanism for verifying the integrity of requests, it provides no
request confidentiality. Unless further precautions are taken, guarantee of request confidentiality. Unless further precautions are
eavesdroppers will have full access to request content and may be taken, eavesdroppers will have full access to request content and may
able to mount interception or replay attacks through using content of be able to mount interception or replay attacks by using the contents
request, e.g. secrets or tokens. of requests, 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 [RFC5246]. A virtual private network (VPN), e.g. based on IPsec TLS [RFC5246]. A virtual private network (VPN), e.g., based on IPsec
VPN [RFC4301], may considered as well. VPNs [RFC4301], may be considered as well.
Note: this document assumes end-to-end TLS protected connections Note: This document assumes end-to-end TLS protected connections
between the respective protocol entities. Deployments deviating from between the respective protocol entities. Deployments deviating from
this assumption by offloading TLS in between (e.g. on the data center this assumption by offloading TLS in between (e.g., on the data
edge) must refine this threat model in order to account for the center edge) must refine this threat model in order to account for
additional (mainly insider) threat this may cause. 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 the token's endpoint or the
server's endpoint resource server's endpoint
o Replay of refresh tokens obtained on tokens endpoint
o Replay of authorization codes obtained on tokens endpoint o Replay of refresh tokens obtained on the token's endpoint
o Replay of authorization "codes" obtained on the token's endpoint
(redirect?) (redirect?)
o Replay of user passwords and client secrets o Replay of user passwords and client secrets
5.1.2. Utiliize server authentication 5.1.2. Utilize Server Authentication
HTTPS server authentication or similar means can be used to HTTPS server authentication or similar means can be used to
authenticate the identity of a server. The goal is to reliably bind authenticate the identity of a server. The goal is to reliably bind
the fully qualified domain name of the server to the public key the fully qualified domain name of the server to the public key
presented by the server during connection establishment (see presented by the server during connection establishment (see
[RFC2818]). [RFC2818]).
The client should validate the binding of the server to its domain The client should validate the binding of the server to its domain
name. If the server fails to prove that binding, it is considered a name. If the server fails to prove that binding, the communication
man-in-the-middle attack. The security measure depends on the is considered a man-in-the-middle attack. This security measure
certification authorities the client trusts for that purpose. depends on the certification authorities the client trusts for that
Clients should carefully select those trusted CAs and protect the purpose. Clients should carefully select those trusted CAs and
storage for trusted CA certificates from modifications. protect the storage for trusted CA certificates from modifications.
This is a countermeasure against the following threats: This is a countermeasure against the following threats:
o Spoofing o Spoofing
o Proxying o Proxying
o Phishing by counterfeit servers o Phishing by counterfeit servers
5.1.3. Always keep the resource owner informed 5.1.3. Always Keep the Resource Owner Informed
Transparency to the resource owner is a key element of the OAuth Transparency to the resource owner is a key element of the OAuth
protocol. The user 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 make 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.g., email, SMS, ...). Note that
notifications can be a phishing vector. Messages should be such notifications can be a phishing vector. Messages should be such
that look-alike phishing messages cannot be derived from them. 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 section 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
term secrets, such as client secrets and user passwords as well as long-term secrets, such as client secrets and user passwords as well
all kinds of tokens (refresh and access token) or authorization as all kinds of tokens (refresh and access tokens) or authorization
codes. "codes".
5.1.4.1. Enforce credential storage protection best practices 5.1.4.1. Enforce Credential Storage Protection Best Practices
Administrators should undertake industry best practices to protect Administrators should undertake industry best practices to protect
the storage of credentials (see for example [owasp]). Such practices the storage of credentials (for example, see [OWASP]). Such
may include but are not limited to the following sub-sections. practices may include but are not limited to the following
sub-sections.
5.1.4.1.1. Enforce Standard System Security Means 5.1.4.1.1. Enforce Standard System Security Means
A server system may be locked down so that no attacker may get access A server system may be locked down so that no attacker may get access
to sensible configuration files and databases. to sensitive configuration files and databases.
5.1.4.1.2. Enforce standard SQL Injection Countermeasures 5.1.4.1.2. Enforce Standard SQL Injection Countermeasures
If a client identifier or other authentication component is queried If a client identifier or other authentication component is queried
or compared against a SQL Database it may become possible for an or compared against a SQL database, it may become possible for an
injection attack to occur if parameters received are not validated injection attack to occur if parameters received are not validated
before submission to the database. before submission to the database.
o Ensure that server code is using the minimum database privileges o Ensure that server code is using the minimum database privileges
possible to reduce the "surface" of possible attacks. possible to reduce the "surface" of possible attacks.
o Avoid dynamic SQL using concatenated input. If possible, use o Avoid dynamic SQL using concatenated input. If possible, use
static SQL. static SQL.
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 the 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 credentials in clear text. The authorization server should not store credentials in clear text.
Typical approaches are to store hashes instead or to encrypt Typical approaches are to store hashes instead or to encrypt
credentials. If the credential lacks a reasonable entropy level credentials. If the credential lacks a reasonable entropy level
(because it is a user password) an additional salt will harden the (because it is a user password), an additional salt will harden the
storage to make offline dictionary attacks more difficult. storage to make offline dictionary attacks more difficult.
Note: Some authentication protocols require the authorization server Note: Some authentication protocols require the authorization server
to have access to the secret in the clear. Those protocols cannot be to have access to the secret in the clear. Those protocols cannot be
implemented if the server only has access to hashes. Credentials implemented if the server only has access to hashes. Credentials
should strongly encrypted in those cases. should be 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. Utilize secure password policy 5.1.4.2.1. Utilize Secure Password Policy
The authorization server may decide to enforce a complex user The authorization server may decide to enforce a complex user
password policy in order to increase the user passwords' entropy to password policy in order to increase the user passwords' entropy to
hinder online password attacks. Note that too much complexity can hinder online password attacks. Note that too much complexity can
increase the liklihood that users re-use passwords or write them down increase the likelihood that users re-use passwords or write them
or otherwise store them insecurely. down, or otherwise store them insecurely.
5.1.4.2.2. Use high entropy for secrets 5.1.4.2.2. Use High Entropy for Secrets
When creating secrets not intended for usage by human users (e.g. When creating secrets not intended for usage by human users (e.g.,
client secrets or token handles), the authorization server should client secrets or token handles), the authorization server should
include a reasonable level of entropy in order to mitigate the risk include a reasonable level of entropy in order to mitigate the risk
of guessing attacks. The token value should be >=128 bits long and of guessing attacks. The token value should be >=128 bits long and
constructed from a cryptographically strong random or pseudo-random constructed from a cryptographically strong random or pseudo-random
number sequence (see [RFC4086] for best current practice) generated number sequence (see [RFC4086] for best current practice) generated
by the Authorization Server. by the authorization server.
5.1.4.2.3. Lock accounts 5.1.4.2.3. Lock Accounts
Online attacks on passwords can be mitigated by locking the Online attacks on passwords can be mitigated by locking the
respective accounts after a certain number of failed attempts. respective accounts after a certain number of failed attempts.
Note: This measure can be abused to lock down legitimate service Note: This measure can be abused to lock down legitimate service
users. users.
5.1.4.2.4. Use tar pit 5.1.4.2.4. Use Tar Pit
The authorization server may react on failed attempts to authenticate The authorization server may react on failed attempts to authenticate
by username/password by temporarily locking the respective account by username/password by temporarily locking the respective account
and delaying the response for a certain duration. This duration may and delaying the response for a certain duration. This duration may
increase with the number of failed attempts. The objective is to increase with the number of failed attempts. The objective is to
slow the attackers attempts on a certain username down. slow the attacker's attempts on a certain username down.
Note: this may require a more complex and stateful design of the Note: This may require a more complex and stateful design of the
authorization server. authorization server.
5.1.4.2.5. Usa CAPTCHAs 5.1.4.2.5. Use CAPTCHAs
The idea is to prevent programs from automatically checking huge The idea is to prevent programs from automatically checking a 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. The 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 sensitive service, o a service-specific policy, e.g., it is 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
following threats: following threats:
o token leakage o token leakage
o token issuance to malicious software o token issuance to malicious software
o unintended issuance of to powerful tokens with resource owner o unintended issuance of powerful tokens with resource owner
credentials flow credentials flow
5.1.5.2. Expiration time 5.1.5.2. Determine 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 Depending on the risk associated with token leakage, tokens may
expire after a few minutes (e.g. for payment transactions) or stay expire after a few minutes (e.g., for payment transactions) or stay
valid for hours (e.g. read access to contacts). valid for hours (e.g., read access to contacts).
The expiration time is determined by a couple of factors, including: The expiration time is determined by several factors, including:
o risk associated to a token leakage o risk associated with token leakage,
o duration of the underlying access grant, o duration of the underlying access grant,
o duration until the modification of an access grant should take o duration until the modification of an access grant should take
effect, and effect, and
o time required for an attacker to guess or produce valid token. o time required for an attacker to guess or produce a valid token.
5.1.5.3. Use short expiration time 5.1.5.3. Use Short Expiration Time
A short expiration time for tokens is a protection means against the A short expiration time for tokens is a means of protection against
following threats: the following threats:
o replay o replay
o reduce impact of token leak o token leak (a short expiration time will reduce impact)
o reduce likelihood of successful online guessing o online guessing (a short expiration time will reduce the
likelihood of success)
Note: Short token duration requires more precise clock Note: Short token duration requires more precise clock
synchronisation between authorization server and resource server. synchronization between the authorization server and resource server.
Furthermore, shorter duration may require more token refreshes Furthermore, shorter duration may require more token refreshes
(access token) or repeated end-user authorization processes (access token) or repeated end-user authorization processes
(authorization code and 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 or 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 that 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 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 an authorization code, the Authorization Server may attempt to redeem an authorization "code", the authorization server
want to revoke all access tokens granted based on the authorization may want to revoke all access tokens granted based on the
code as well as reject the current request. authorization "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
number of operations. This forces client applications to either re- limited number of operations. This either forces client applications
authenticate and use a refresh token to obtain a fresh access token, to re-authenticate and use a refresh token to obtain a fresh access
or it forces the client to re-authorize the access token by involving token, or forces the client to re-authorize the access token by
the user. involving the user.
5.1.5.5. Bind tokens to a particular resource server (Audience) 5.1.5.5. Bind Tokens to a Particular Resource Server (Audience)
Authorization servers in multi-service environments may consider 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 to which a
intended to be sent to. SAML Assertions (see token is intended to be sent. SAML assertions (see
[OASIS.saml-core-2.0-os]) use the Audience element for this purpose. [OASIS.saml-core-2.0-os]) use the Audience element for this purpose.
This countermeasure can be used in the following situations: 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 rogue 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 leakage of a valid token to a counterfeit
counterfeit resource server. 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 URL This may be used to indicate to a resource server which endpoint URL
has been used to obtain the token. This measure will allow to detect has been used to obtain the token. This measure will allow the
requests from a counterfeit resource server, since such token will detection of requests from a counterfeit resource server, since such
contain the endpoint URL of that server. a token will contain the endpoint URL of that server.
5.1.5.7. Audience and Token scopes 5.1.5.7. Use Explicitly Defined Scopes for Audience and Tokens
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 scopes, 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 purpose than
intended purpose. the one intended.
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
identifier. This identifier should be validated for every request identifier. This identifier should be validated for every request
with that token. This means can be used, to with that token. This technique 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 identifier may require the target server Note: Validating the client identifier may require the target server
to authenticate the client's identifier. This authentication can be to authenticate the client's identifier. This authentication can be
based on secrets managed independent of the token (e.g. pre- based on secrets managed independently of the token (e.g.,
registered client id/secret on authorization server) or sent with the pre-registered client id/secret on authorization server) or sent with
token itself (e.g. as part of the encrypted token content). the token itself (e.g., as part of the encrypted token content).
5.1.5.9. Signed tokens 5.1.5.9. Sign Self-Contained 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 (e.g. Hash-based Message to modify or produce faked tokens (e.g., Hash-based Message
Authentication Code or digital signatures) Authentication Code or digital signatures).
5.1.5.10. Encryption of token content 5.1.5.10. Encrypt Token Content
Self-contained tokens may be encrypted for confidentiality reasons or Self-contained tokens may be encrypted for confidentiality reasons or
to protect system internal data. Depending on token format, keys to protect system internal data. Depending on token format, keys
(e.g. symmetric keys) may have to be distributed between server (e.g., symmetric keys) may have to be distributed between server
nodes. The method of distribution should be defined by the token and nodes. The method of distribution should be defined by the token and
encryption used. the encryption used.
5.1.5.11. Assertion formats 5.1.5.11. Adopt a Standard Assertion Format
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 [OASIS.saml-core-2.0-os] or JWT (such as SAML [OASIS.saml-core-2.0-os] or the JavaScript Object
[I-D.ietf-oauth-json-web-token]. Notation Web Token (JWT) [OAuth-JWT]).
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 Pass tokens securely using secure transport (TLS) o Pass tokens securely using secure transport (TLS).
o Ensure client applications do not share tokens with 3rd parties o Ensure that 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 endpoint.
5.2.1. Authorization Codes 5.2.1. Authorization "codes"
5.2.1.1. Automatic revocation of derived tokens if abuse is detected 5.2.1.1. Automatic Revocation of Derived Tokens If Abuse Is Detected
If an Authorization Server observes multiple attempts to redeem an If an authorization server observes multiple attempts to redeem an
authorization grant (e.g. such as an authorization code), the authorization grant (e.g., such as an authorization "code"), the
Authorization Server may want to revoke all tokens granted based on authorization server may want to revoke all tokens granted based on
the authorization grant. the authorization grant.
5.2.2. Refresh tokens 5.2.2. Refresh Tokens
5.2.2.1. Restricted issuance of refresh tokens 5.2.2.1. Restricted Issuance of Refresh Tokens
The authorization server may decide based on an appropriate policy The authorization server may decide, based on an appropriate policy,
not to issue refresh tokens. Since refresh tokens 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 to 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 match every refresh token to the The authorization server should match every refresh token to the
identifier of the client to whom it was issued. The authorization identifier of the client to whom it was issued. The authorization
server should check that the same client_id is present for every server should check that the same "client_id" is present for every
request to refresh the access token. If possible (e.g. confidential request to refresh the access token. If possible (e.g., confidential
clients), the authorization server should authenticate the respective clients), the authorization server should authenticate the respective
client. 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
different apps/devices. This happens if a token gets stolen from the different apps/devices. This happens if a token gets stolen from the
client and is subsequently used by the attacker and the legitimate client and is subsequently used by both the attacker and the
client. The basic idea is to change the refresh token value with legitimate client. The basic idea is to change the refresh token
every refresh request in order to detect attempts to obtain access value with every refresh request in order to detect attempts to
tokens using old refresh tokens. Since the authorization server obtain access tokens using old refresh tokens. Since the
cannot determine whether the attacker or the legitimate client is authorization server cannot determine whether the attacker or the
trying to access, in case of such an access attempt the valid refresh legitimate client is trying to access, in case of such an access
token and the access authorization associated with it are both attempt the valid refresh token and the access authorization
revoked. associated with it are both revoked.
The OAuth specification supports this measure in that the tokens The OAuth specification supports this measure in that the token's
response allows the authorization server to return a new refresh response allows the authorization server to return a new refresh
token even for requests with grant type "refresh_token". token even for requests with grant type "refresh_token".
Note: this measure may cause problems in clustered environments since Note: This measure may cause problems in clustered environments,
usage of the currently valid refresh token must be ensured. In such since usage of the currently valid refresh token must be ensured. In
an environment, other measures might be more appropriate. such an environment, other measures might be more appropriate.
5.2.2.4. Revoke refresh tokens 5.2.2.4. Revocation of Refresh Tokens
The authorization server may allow clients or end-users to explicitly The authorization server may allow clients or end users to explicitly
request the invalidation of refresh tokens. A mechanism to revoke request the invalidation of refresh tokens. A mechanism to revoke
tokens is specified in [I-D.ietf-oauth-revocation]. tokens is specified in [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 a 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 the binding of authentication
credentials to a device identifier. The _International Mobile credentials to a device identifier. The International Mobile Station
Station Equipment Identity_ [IMEI] is one example of such an Equipment Identity [IMEI] is one example of such an identifier; there
identifier, there are also operating system specific identifiers. are also operating system-specific identifiers. The authorization
The authorization server could include such an identifier when server could include such an identifier when authenticating user
authenticating user credentials in order to detect token theft from a credentials in order to detect token theft from a particular device.
particular device.
Note: Any implementation should consider potential privacy Note: Any implementation should consider potential privacy
implications of using device identifiers. implications of using device identifiers.
5.2.2.6. X-FRAME-OPTION header 5.2.2.6. X-FRAME-OPTIONS Header
For newer browsers, avoidance of iFrames can be enforced server side For newer browsers, avoidance of iFrames can be enforced on the
by using the X-FRAME-OPTION header (see server side by using the X-FRAME-OPTIONS header (see
[I-D.gondrom-x-frame-options]). This header can have two values, [X-Frame-Options]). This header can have two values, "DENY" and
"DENY" and "SAMEORIGIN", which will block any framing or framing by "SAMEORIGIN", which will block any framing or any framing by sites
sites with a different origin, respectively. The value "ALLOW-FROM" with a different origin, respectively. The value "ALLOW-FROM"
allows iFrames for a list of trusted origins. specifies a list of trusted origins that iFrames may originate from.
This is a countermeasure against the following threats: This is a countermeasure against the following threat:
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 to:
o Collate requests to the same client, o Collate requests to the same client,
o Indicate to the user the client is recognized by the authorization o Indicate to the user that the client is recognized by the
server, authorization 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 server or resource server, and
o Log a client identifier to log files for analysis or statistics. 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 these 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 client 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 individually by an provider could activate every client installation individually by an
administrator and that way gain confidence in the identity of the administrator and in 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 in which the
installed in. And there are several approaches in between. client is installed. There are several approaches in between.
5.2.3.1. Don't issue secrets to client with inappropriate security 5.2.3.1. Don't Issue Secrets to Clients with Inappropriate Security
policy Policy
Authorization servers should not issue secrets to clients that cannot Authorization servers should not issue secrets to clients that cannot
protect secrets ("public" clients). This reduces probability of the protect secrets ("public" clients). This reduces the probability of
server treating the client as strongly authenticated. the server treating the client as strongly authenticated.
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 that are 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, is not code of the application or an associated resource bundle, is not
protected from reverse engineering. Secondly, such secrets cannot be protected from reverse engineering. Secondly, such secrets cannot be
revoked since this would immediately put all installations out of revoked, since this would immediately put all installations out of
work. Moreover, since the authorization server cannot really trust work. Moreover, since the authorization server cannot really trust
the client's identifier, it would be dangerous to indicate to end- the client's identifier, it would be dangerous to indicate to end
users the trustworthiness of the client. users the trustworthiness of the client.
There are other ways to achieve a reasonable security level, as There are other ways to achieve a reasonable security level, as
described in the following sections. described in the following sections.
5.2.3.2. Require user consent for public clients without secret 5.2.3.2. Require User Consent for Public Clients without Secret
Authorization servers should not allow automatic authorization for Authorization servers should not allow automatic authorization for
public clients. The authorization may issue an individual client id, public clients. The authorization server may issue an individual
but should require that all authorizations are approved by the end- client id but should require that all authorizations are approved by
user. This is a countermeasure for clients without secret against the end user. For clients without secrets, this is a countermeasure
the following threats: against the following threat:
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. Issue a "client_id" Only in Combination with "redirect_uri"
The authorization may issue a client_id and bind the client_id to a The authorization server may issue a "client_id" and bind the
certain pre-configured redirect_uri. Any authorization request with "client_id" to a certain pre-configured "redirect_uri". Any
another redirection URI is refused automatically. Alternatively, the authorization request with another redirect URI is refused
authorization server should not accept any dynamic redirection URI automatically. Alternatively, the authorization server should not
for such a client_id and instead always redirect to the well-known accept any dynamic redirect URI for such a "client_id" and instead
pre-configured redirection URI. This is a countermeasure for clients should always redirect to the well-known pre-configured redirect URI.
without secrets against the following threats: This is a countermeasure for clients 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. Installation-specific client secrets 5.2.3.4. Issue Installation-Specific Client Secrets
An authorization server may issue separate client identifiers and An authorization server may issue separate client identifiers and
corresponding secrets to the different installations of a particular corresponding secrets to the different installations of a particular
client (i.e. software package). The effect of such an approach would client (i.e., software package). The effect of such an approach
be to turn otherwise "public" clients back into "confidential" would be to turn otherwise "public" clients back into "confidential"
clients. clients.
For web applications, this could mean to create one client_id and For web applications, this could mean creating one "client_id" and
client_secret per web site a software package is installed on. So "client_secret" for each web site on which a software package is
the provider of that particular site could request client id and installed. So, the provider of that particular site could request a
secret from the authorization server during setup of the web site. client id and secret from the authorization server during the setup
This would also allow to validate some of the properties of that web of the web site. This would also allow the validation of some of the
site, such as redirection URI, website URL, and whatever proofs properties of that web site, such as redirect URI, web site URL, and
useful. The web site provider has to ensure the security of the whatever else proves useful. The web site provider has to ensure the
client secret on the site. security of the client secret on the site.
For native applications, things are more complicated because every For native applications, things are more complicated because every
copy of a particular application on any device is a different copy of a particular application on any device is a different
installation. Installation-specific secrets in this scenario will installation. Installation-specific secrets in this scenario will
require require obtaining a "client_id" and "client_secret" either
1. Either to obtain a client_id and client_secret during download
process from the application market, or
2. During installation on the device. 1. during the download process from the application market, or
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 certain level of trust in The first approach would allow the achievement of a certain level of
the authenticity of the application, whereas the second option only trust in the authenticity of the application, whereas the second
allows to authenticate the installation but not to validate option only allows the authentication of the installation but not the
properties of the client. But this would at least help to prevent validation of properties of the client. But this would at least help
several replay attacks. Moreover, installation-specific client_id to prevent several replay attacks. Moreover, installation-specific
and secret allow to selectively revoke all refresh tokens of a "client_ids" and secrets allow the selective revocation of all
specific installation at once. refresh tokens of a specific installation at once.
5.2.3.5. Validation of pre-registered redirect_uri 5.2.3.5. Validate 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
in [I-D.ietf-oauth-v2]. The way this registration is performed is defined in [RFC6749]. The way that 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 redirect 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 redirect URI. Where
Where it does not match, the authorization server should assume the it does not match, the authorization server should assume that 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 redirect URI of such an authorization request.
Validating the pre-registered redirect_uri is a countermeasure Validating the pre-registered "redirect_uri" is a countermeasure
against the following threats: against the following threats:
o Authorization code leakage through counterfeit web site: allows to o Authorization "code" leakage through counterfeit web site: allows
detect attack attempts already after first redirect to end-user authorization servers to detect attack attempts after the first
authorization endpoint (Section 4.4.1.7). redirect to an end-user authorization endpoint (Section 4.4.1.7).
o Open Redirector attack via client redirection endpoint. ( o Open redirector attack via a 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 an 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 redirect 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
attacker using spoofing attacks to a victims device to circumvent an attacker using spoofing attacks to a victim's 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, pre- specified yet). With the lack of dynamic client registration, a
registered "redirect_uri" only works for clients bound to certain pre-registered "redirect_uri" only works for clients bound to certain
deployments at development/configuration time. As soon as dynamic deployments at development/configuration time. As soon as dynamic
resource server discovery is required, the pre-registered resource server discovery is required, the pre-registered
redirect_uri may be no longer feasible. "redirect_uri" may no longer be feasible.
5.2.3.6. Revoke client secrets 5.2.3.6. Revoke Client Secrets
An authorization server may revoke a client's secret in order to An authorization server may revoke a client's secret in order to
prevent abuse of a revealed secret. prevent abuse of a revealed secret.
Note: This measure will immediately invalidate any authorization code Note: This measure will immediately invalidate any authorization
or refresh token issued to the respective client. This might be "code" or refresh token issued to the respective client. This might
unintentionally impact client identifiers and secrets used across unintentionally impact client identifiers and secrets used across
multiple deployments of a particular native or web application. multiple deployments of a particular native or web application.
This a countermeasure against: This a countermeasure against:
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 [I-D.ietf-oauth-assertions], the need to distribute a assertion [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 section includes considerations for authorization flows
the end-user. involving the end user.
5.2.4.1. Automatic processing of repeated authorizations requires 5.2.4.1. Automatic Processing of Repeated Authorizations Requires
client validation Client Validation
Authorization servers should NOT automatically process repeat Authorization servers should NOT automatically process repeat
authorizations where the client is not authenticated through a client authorizations where the client is not authenticated through a client
secret or some other authentication mechanism such as a signed secret or some other authentication mechanism such as a signed
authentication assertion certificate (Section 5.2.3.7 Use strong authentication assertion certificate (Section 5.2.3.7) or validation
client authentication (e.g. client_assertion / client_token)) or of a pre-registered redirect URI (Section 5.2.3.5).
validation of a pre-registered redirect URI (Section 5.2.3.5
Validation of pre-registered redirection URI ).
5.2.4.2. Informed decisions based on transparency 5.2.4.2. Informed Decisions Based on Transparency
The authorization server 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 URL, 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 situations 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 A 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
id of the respective client which initiated the end-user the id of the respective client that 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 (e.g. using protected memory and/or a secure database). 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 be able to bind every authorization The authorization server should be able to bind every authorization
code to the actual redirection URI used as redirect target of the "code" to the actual redirect URI used as the redirect target of the
client in the end-user authorization process. This binding should be client in the end-user authorization process. This binding should be
validated when the client attempts to exchange the respective validated when the client attempts to exchange the respective
authorization code for an access token. This measure is a authorization "code" for an access token. This measure is a
countermeasure against authorization code leakage through counterfeit countermeasure against authorization "code" leakage through
web sites since an attacker cannot use another redirection URI to counterfeit web sites, since an attacker cannot use another redirect
exchange an authorization code into a token. URI to 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 number of copies of client software, there is limited
benefit to create a single client id and secret which is shared by benefit in creating a single client id and secret that 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 an associated resource bundle, cannot be of the application or an associated resource bundle, cannot be
protected from reverse engineering. Secondly, such secrets cannot be protected from reverse engineering. Secondly, such secrets cannot be
revoked since this would immediately put all installations out of revoked, since this would immediately put all installations out of
work. Moreover, since the authorization server cannot really trust work. Moreover, since the authorization server cannot really trust
the client's identifier, it would be dangerous to indicate to end- the client's identifier, it would be dangerous to indicate to end
users the trustworthiness of the client. users the trustworthiness of the client.
5.3.2. Standard web server protection measures (for config files and 5.3.2. Use Standard Web Server Protection Measures (for Config Files
databases) and Databases)
Use standard web server protection measures - Section 5.3.2 Use standard web server protection and configuration measures to
protect the integrity of the server, databases, configuration files,
and other operational components of the server.
5.3.3. Store secrets in a secure storage 5.3.3. Store Secrets in Secure Storage
The are different way to store secrets of all kinds (tokens, client There are different ways to store secrets of all kinds (tokens,
secrets) securely on a device or server. client secrets) securely on a device or server.
Most multi-user operating systems segregate the personal storage of Most multi-user operating systems segregate the personal storage of
the different system users. Moreover, most modern smartphone different system users. Moreover, most modern smartphone operating
operating systems even support to store app-specific data in separate systems even support the storage of application-specific data in
areas of the file systems and protect it from access by other separate areas of file systems and protect the data from access by
applications. Additionally, applications can implements confidential other applications. Additionally, applications can implement
data itself using a user-supplied secret, such as PIN or password. confidential data by using a user-supplied secret, such as a 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 option in turn requires a resilient authentication
mechanisms between client and backend server. Note: Applications mechanism between the 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 keeping 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 that
can be utilized to provide additional protection where a device is can be utilized to provide additional protection when 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 biometric features such as "face recognition". These are not equal
the level of security they provide. in the level of security they provide.
5.3.5. Link state parameter to user agent session 5.3.5. Link the "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
attacks, for example against the redirection URI. An attacker could CSRF attacks, for example, attacks against the redirect URI. An
inject their own authorization code or access token, which can result attacker could inject their own authorization "code" or access token,
in the client using an access token associated with the attacker's which can result in the client using an access token associated with
protected resources rather than the victim's (e.g. save the victim's the attacker's protected resources rather than the victim's (e.g.,
bank account information to a protected resource controlled by the save the victim's bank account information to a protected resource
attacker). controlled by the attacker).
The client should utilize the "state" request parameter to send the The client should utilize the "state" request parameter to send the
authorization server a value that binds the request to the user- authorization server a value that binds the request to the user
agent's authenticated state (e.g. a hash of the session cookie used agent's authenticated state (e.g., a hash of the session cookie used
to authenticate the user-agent) when making an authorization request. to authenticate the user agent) when making an authorization request.
Once authorization has been obtained from the end-user, the Once authorization has been obtained from the end user, the
authorization server redirects the end-user's user-agent back to the authorization server redirects the end-user's user agent back to the
client with the required binding value contained in the "state" client with the required binding value contained in the "state"
parameter. parameter.
The binding value enables the client to verify the validity of the The binding value enables the client to verify the validity of the
request by matching the binding value to the user- agent's request by matching the binding value to the user agent's
authenticated state. authenticated state.
5.4. Resource Servers 5.4. Resource Servers
The following section details security considerations for resource The following section details security considerations for resource
servers. servers.
5.4.1. Authorization headers 5.4.1. Authorization Headers
Authorization headers are recognized and specially treated by HTTP Authorization headers are recognized and specially treated by HTTP
proxies and servers. Thus the usage of such headers for sending proxies and servers. Thus, the usage of such headers for sending
access tokens to resource servers reduces the likelihood of leakage access tokens to resource servers reduces the likelihood of leakage
or unintended storage of authenticated requests in general and or unintended storage of authenticated requests in general, and
especially Authorization headers. especially Authorization headers.
5.4.2. Authenticated requests 5.4.2. Authenticated Requests
An authorization server may bind tokens to a certain client An authorization server may bind tokens to a certain client
identifier and enable resource servers to be able to validate that identifier and enable resource servers to validate that association
association on resource access. This will require the resource on resource access. This will require the resource server to
server to authenticate the originator of a request as the legitimate authenticate the originator of a request as the legitimate owner of a
owner of a particular token. There are a couple of options to particular token. There are several options to implement this
implement this countermeasure: countermeasure:
o The authorization server may associate the client identifier with o The authorization server may associate the client identifier with
the token (either internally or in the payload of an self- the token (either internally or in the payload of a self-contained
contained token). The client then uses client certificate-based token). The client then uses client certificate-based HTTP
HTTP authentication on the resource server's endpoint to authentication on the resource server's endpoint to authenticate
authenticate its identity and the resource server validates the its identity, and the resource server validates the name with the
name with the name referenced by the token. name referenced by the token.
o same as before, but the client uses his private key to sign the o Same as the option above, but the client uses his private key to
request to the resource server (public key is either contained in sign the request to the resource server (the public key is either
the token or sent along with the request) contained in 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 MAC (message authentication code) key, which the client uses in a Holder-of-Key proof to
the request (see [I-D.ietf-oauth-v2-http-mac]). The resource authenticate the client's use of the token. The resource server
server obtains the secret either directly from the authorization obtains the secret directly from the authorization server, or the
server or it is contained in an encrypted section of the token. secret is contained in an encrypted section of the token. In that
That way the resource server does not "know" the client but is way, the resource server does not "know" the client but is able to
able to validate whether the authorization server issued the token validate whether the authorization server issued the token to that
to that client client.
Authenticated requests are a countermeasure against abuse of tokens Authenticated requests are a countermeasure against abuse of tokens
by 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
o replay attempts o replay attempts
5.5. A Word on User Interaction and User-Installed Apps 5.5. A Word on User Interaction and User-Installed Apps
OAuth, as a security protocol, is distinctive in that its flow OAuth, as a security protocol, is distinctive in that its flow
usually involves significant user interaction, making the end user a usually involves significant user interaction, making the end user a
part of the security model. This creates some important difficulties part of the security model. This creates some important difficulties
in defending against some of the threats discussed above. Some of in defending against some of the threats discussed above. Some of
these points have already been made, but it's worth repeating and these points have already been made, but it's worth repeating and
highlighting them here. highlighting them here.
o End users must understand what they are being asked to approve o End users must understand what they are being asked to approve
(see Section Section 5.2.4.1). Users often do not have the (see Section 5.2.4.2). Users often do not have the expertise to
expertise to understand the ramifications of saying "yes" to an understand the ramifications of saying "yes" to an authorization
authorization request. and are likely not to be able to see subtle request and are likely not to be able to see subtle differences in
differences in wording of requests. Malicious software can the wording of requests. Malicious software can confuse the user,
confuse the user, tricking the user into approving almost tricking the user into approving almost anything.
anything.
o End-user devices are prone to software compromise. This has been o End-user devices are prone to software compromise. This has been
a long-standing problem, with frequent attacks on web browsers and a long-standing problem, with frequent attacks on web browsers and
other parts of the user's system. But with increasing popularity other parts of the user's system. But with the increasing
of user-installed "apps", the threat posed by compromised or popularity of user-installed "apps", the threat posed by
malicious end-user software is very strong, and is one that is compromised or malicious end-user software is very strong and is
very difficult to mitigate. one that is very difficult to mitigate.
o Be aware that users will demand to install and run such apps, and o Be aware that users will demand to install and run such apps, and
that compromised or malicious ones can steal credentials at many that compromised or malicious ones can steal credentials at many
points in the data flow. They can intercept the very user login points in the data flow. They can intercept the very user login
credentials that OAuth is designed to protect. They can request credentials that OAuth is designed to protect. They can request
authorization far beyond what they have led the user to understand authorization far beyond what they have led the user to understand
and approve. They can automate a response on behalf of the user, and approve. They can automate a response on behalf of the user,
hiding the whole process. No solution is offered here, because hiding the whole process. No solution is offered here, because
none is known; this remains in the space between better security none is known; this remains in the space between better security
and better usability. and better usability.
o Addressing these issues by restricting the use of user-installed o Addressing these issues by restricting the use of user-installed
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 of validating, explicitely point out which effectively capable of validating, explicitly 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. Acknowledgements
This document makes no request of IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Acknowledgements
We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward, Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward,
Niv Steingarten, Tim Bray, and James H. Manger for their comments and Niv Steingarten, Tim Bray, and James H. Manger for their comments and
contributions. contributions.
8. References 7. References
8.1. Informative References
[I-D.ietf-oauth-v2]
Hardt, D., "The OAuth 2.0 Authorization Framework",
draft-ietf-oauth-v2-31 (work in progress), August 2012.
[I-D.ietf-oauth-v2-bearer]
Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage",
draft-ietf-oauth-v2-bearer-23 (work in progress),
August 2012.
8.2. Informative References
[I-D.gondrom-x-frame-options] 7.1. Normative References
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-assertions] [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework",
Campbell, B., Mortimore, C., Jones, M., and Y. Goland, RFC 6749, October 2012.
"Assertion Framework for OAuth 2.0",
draft-ietf-oauth-assertions-06 (work in progress),
September 2012.
[I-D.ietf-oauth-json-web-token] [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token Framework: Bearer Token Usage", RFC 6750, October 2012.
(JWT)", draft-ietf-oauth-json-web-token-03 (work in
progress), July 2012.
[I-D.ietf-oauth-revocation] 7.2. Informative References
Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
Revocation", draft-ietf-oauth-revocation-01 (work in
progress), October 2012.
[I-D.ietf-oauth-v2-http-mac] [Framebusting]
Hammer-Lahav, E., "HTTP Authentication: MAC Access Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
Authentication", draft-ietf-oauth-v2-http-mac-01 (work in "Busting Frame Busting: a Study of Clickjacking
progress), February 2012. Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
Security and Privacy Workshop, May 2010, <http://elie.im/
publication/busting-frame-busting-a-study-of-
clickjacking-vulnerabilities-on-popular-sites>.
[IMEI] 3GPP, "International Mobile station Equipment Identities [IMEI] 3GPP, "International Mobile station Equipment Identities
(IMEI)", 3GPP TS 22.016 3.3.0, July 2002. (IMEI)", 3GPP TS 22.016 11.0.0, September 2012,
<http://www.3gpp.org/ftp/Specs/html-info/22016.htm>.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
"Assertions and Protocol for the OASIS Security Assertion Maler, Ed., "Assertions and Protocols for the OASIS
Markup Language (SAML) V2.0", OASIS Standard saml-core- Security Assertion Markup Language (SAML) V2.0", OASIS
2.0-os, March 2005. Standard saml-core-2.0-os, March 2005,
<http://docs.oasis-open.org/security/saml/
[OASIS.sstc-gross-sec-analysis-response-01] v2.0/saml-core-2.0-os.pdf>.
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] [OASIS.sstc-saml-bindings-1.1]
Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
"Bindings and Profiles for the OASIS Security Assertion "Bindings and Profiles for the OASIS Security Assertion
Markup Language (SAML) V1.1", September 2003. Markup Language (SAML) V1.1", September 2003,
<http://www.oasis-open.org/committees/download.php/3405/
oasis-sstc-saml-bindings-1.1.pdf>.
[OASIS.sstc-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,
<http://www.oasis-open.org/committees/download.php/
11191/sstc-gross-sec-analysis-response-01.pdf>.
[OAuth-ASSERTIONS]
Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
"Assertion Framework for OAuth 2.0", Work in Progress,
December 2012.
[OAuth-HTTP-MAC]
Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed.,
"OAuth 2.0 Message Authentication Code (MAC) Tokens", Work
in Progress, November 2012.
[OAuth-JWT]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", Work in Progress, December 2012.
[OAuth-REVOCATION]
Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token
Revocation", Work in Progress, November 2012.
[OPENID] "OpenID Foundation Home Page", <http://openid.net/>.
[OWASP] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>.
[Portable-Contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [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 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120, Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005. July 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[framebusting] [SSL-Latency]
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.
[openid] "OpenID Foundation Home Page", <http://openid.net/>.
[owasp] "Open Web Application Security Project Home Page",
<https://www.owasp.org/>.
[portable-contacts]
Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
<http://portablecontacts.net/>.
[ssl-latency]
Sissel, J., Ed., "SSL handshake latency and HTTPS Sissel, J., Ed., "SSL handshake latency and HTTPS
optimizations", June 2010. optimizations", June 2010.
Appendix A. Document History [Sec-Analysis]
Gross, T., "Security Analysis of the SAML Single Sign-on
[[ to be removed by RFC editor before publication as an RFC ]] Browser/Artifact Profile", 19th Annual Computer Security
Applications Conference, Las Vegas, December 2003.
draft-lodderstedt-oauth-security-01
o section 4.4.1.2 - changed "resource server" to "client" in
countermeasures description.
o section 4.4.1.6 - changed "client shall authenticate the server"
to "The browser shall be utilized to authenticate the redirection
URI of the client"
o section 5 - general review and alignment with public/confidential
client terms
o all sections - general clean-up and typo corrections
draft-ietf-oauth-v2-threatmodel-00
o section 3.4 - added the purposes for using authorization codes.
o extended section 4.4.1.1
o merged 4.4.1.5 into 4.4.1.2
o corrected some typos
o reformulated "session fixation", renamed respective sections into
"authorization code disclosure through counterfeit client"
o added new section "User session impersonation"
o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
5.1.4.1.4, 5.2.3.5
o added new threat "DoS using manufactured authorization codes" as
proposed by Peifung E Lam
o added XSRF and clickjacking (incl. state parameter explanation)
o changed sub-section order in section 4.4.1
o incorporated feedback from Skylar Woodward (client secrets) and
Shane B Weeden (refresh tokens as client instance secret)
o aligned client section with core draft's client type definition
o converted I-D into WG document
draft-ietf-oauth-v2-threatmodel-01
o Alignment of terminology with core draft 22 (private/public
client, redirect URI validation policy, replaced definition of the
client categories by reference to respective core section)
o Synchronisation with the core's security consideration section
(UPDATE 10.12 CSRF, NEW 10.14/15)
o Added Resource Owner Impersonation
o Improved section 5
o Renamed Refresh Token Replacement to Refresh Token Rotation
draft-ietf-oauth-v2-threatmodel-02
o Incoporated Tim Bray's review comments (e.g. removed all normative
language)
draft-ietf-oauth-v2-threatmodel-03
o removed 2119 boilerplate and normative reference
o incorporated shepherd review feedback
o incorporated AD review feedback
draft-ietf-oauth-v2-threatmodel-07
o added new section on token substituation [X-Frame-Options]
Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
Work in Progress, October 2012.
o made references to core and bearer normative [iFrame] World Wide Web Consortium, "Frames in HTML documents",
W3C HTML 4.01, December 1999,
<http://www.w3.org/TR/html4/present/frames.html#h-16.5>.
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
Email: mark.mcgloin@ie.ibm.com EMail: mark.mcgloin@ie.ibm.com
Phil Hunt Phil Hunt
Oracle Corporation Oracle Corporation
Email: phil.hunt@yahoo.com EMail: phil.hunt@yahoo.com
 End of changes. 642 change blocks. 
1576 lines changed or deleted 1525 lines changed or added

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