idnits 2.17.00 (12 Aug 2021) /tmp/idnits33688/draft-ietf-oauth-v2-threatmodel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Clients SHOULD not make authenticated requests with an access token to unfamiliar resource servers, regardless of the presence of a secure channel. If the resource server address is well-known to the client, it may authenticate the resource servers (see Section 5.1.2). -- The document date (July 01, 2011) is 3976 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1750' is mentioned on line 2404, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'I-D.lodderstedt-oauth-revocation' is defined on line 2882, but no explicit reference was found in the text == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 == Outdated reference: draft-ietf-oauth-v2-bearer has been published as RFC 6750 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-00 == Outdated reference: A later version (-04) exists of draft-lodderstedt-oauth-revocation-02 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Web Authorization Protocol (oauth) T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Standards Track M. McGloin 5 Expires: January 2, 2012 IBM 6 P. Hunt 7 Oracle Corporation 8 July 01, 2011 10 OAuth 2.0 Threat Model and Security Considerations 11 draft-ietf-oauth-v2-threatmodel-00 13 Abstract 15 This document gives security considerations based on a comprehensive 16 threat model for the OAuth 2.0 Protocol. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 2, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 62 2.3. Architectural assumptions . . . . . . . . . . . . . . . . 7 63 2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 64 2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 65 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 8 66 2.3.3.1. Web Application . . . . . . . . . . . . . . . . . 9 67 2.3.3.2. Native Applications . . . . . . . . . . . . . . . 9 68 2.3.3.3. User-agent-based Applications . . . . . . . . . . 10 69 2.3.3.4. Autonomous . . . . . . . . . . . . . . . . . . . . 11 70 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 11 71 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 12 73 3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 12 74 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 13 75 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 13 76 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 14 77 3.5. Redirect-URI . . . . . . . . . . . . . . . . . . . . . . . 14 78 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 14 79 3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 14 80 4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 16 81 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 17 83 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 18 84 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 20 85 4.1.4. Threat: End-user credentials phished using 86 compromised or embedded browser . . . . . . . . . . . 20 87 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 21 88 4.2.1. Threat: Password phishing by counterfeit 89 authorization server . . . . . . . . . . . . . . . . . 21 90 4.2.2. Threat: User unintentionally grants too much 91 access scope . . . . . . . . . . . . . . . . . . . . . 21 92 4.2.3. Threat: Malicious client obtains existing 93 authorization by fraud . . . . . . . . . . . . . . . . 22 94 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22 95 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 23 96 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 23 97 4.3.2. Threat: Obtain access tokens from authorization 98 server database . . . . . . . . . . . . . . . . . . . 23 99 4.3.3. Threat: Obtain client credentials over non secure 100 transport . . . . . . . . . . . . . . . . . . . . . . 23 101 4.3.4. Threat: Obtain client secret from authorization 102 server database . . . . . . . . . . . . . . . . . . . 24 103 4.3.5. Threat: Obtain client secret by online guessing . . . 24 104 4.3.6. Threat: DoS on dynamic client secret creation . . . . 24 105 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 25 106 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 25 107 4.4.1.1. Threat: Eavesdropping or leaking authorization 108 codes . . . . . . . . . . . . . . . . . . . . . . 25 109 4.4.1.2. Threat: Obtain authorization codes from 110 authorization server database . . . . . . . . . . 26 111 4.4.1.3. Threat: Online guessing of authorization codes . . 27 112 4.4.1.4. Threat: Malicious client obtains authorization . . 27 113 4.4.1.5. Threat: Authorization code phishing . . . . . . . 28 114 4.4.1.6. Threat: User session impersonation . . . . . . . . 29 115 4.4.1.7. Threat: Authorization code leakage through 116 counterfeit client . . . . . . . . . . . . . . . . 29 117 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 31 118 4.4.1.9. Threat: Clickjacking attack against 119 authorization . . . . . . . . . . . . . . . . . . 32 120 4.4.1.10. Threat: DoS, Exhaustion of resources attacks . . . 32 121 4.4.1.11. Threat: DoS using manufactured authorization 122 codes . . . . . . . . . . . . . . . . . . . . . . 33 123 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 34 124 4.4.2.1. Threat: Access token leak in 125 transport/end-points . . . . . . . . . . . . . . . 34 126 4.4.2.2. Threat: Access token leak in browser history . . . 35 127 4.4.2.3. Threat: Malicious client obtains authorization . . 35 128 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 35 129 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 130 4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 131 4.4.3.1. Threat: Accidental exposure of passwords at 132 client site . . . . . . . . . . . . . . . . . . . 37 133 4.4.3.2. Threat: Client obtains scopes without end-user 134 authorization . . . . . . . . . . . . . . . . . . 38 135 4.4.3.3. Threat: Client obtains refresh token through 136 automatic authorization . . . . . . . . . . . . . 38 137 4.4.3.4. Threat: Obtain user passwords on transport . . . . 39 138 4.4.3.5. Threat: Obtain user passwords from 139 authorization server database . . . . . . . . . . 39 140 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 39 141 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 142 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 143 4.5.1. Threat: Eavesdropping refresh tokens from 144 authorization server . . . . . . . . . . . . . . . . . 40 145 4.5.2. Threat: Obtaining refresh token from authorization 146 server database . . . . . . . . . . . . . . . . . . . 40 147 4.5.3. Threat: Obtain refresh token by online guessing . . . 41 148 4.5.4. Threat: Obtain refresh token phishing by 149 counterfeit authorization server . . . . . . . . . . . 41 150 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 41 151 4.6.1. Threat: Eavesdropping access tokens on transport . . . 41 152 4.6.2. Threat: Replay authorized resource server requests . . 42 153 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42 154 4.6.4. Threat: Access token phishing by counterfeit 155 resource server . . . . . . . . . . . . . . . . . . . 43 156 4.6.5. Threat: Abuse of token by legitimate resource 157 server or client . . . . . . . . . . . . . . . . . . . 43 158 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 159 4.6.7. Threat: Token leakage via logfiles and HTTP 160 referrers . . . . . . . . . . . . . . . . . . . . . . 44 161 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 162 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 163 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 164 5.1.2. Server authentication . . . . . . . . . . . . . . . . 45 165 5.1.3. Always keep the resource owner informed . . . . . . . 46 166 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46 167 5.1.4.1. Credential storage protection . . . . . . . . . . 46 168 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 47 169 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 48 170 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 48 171 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49 172 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49 173 5.1.5.4. Limit number of usages/ One time usage . . . . . . 50 174 5.1.5.5. Bind tokens to a particular resource server 175 (Audience) . . . . . . . . . . . . . . . . . . . . 50 176 5.1.5.6. Use endpoint address as token audience . . . . . . 50 177 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 50 178 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51 179 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51 180 5.1.5.10. Encryption of token content . . . . . . . . . . . 51 181 5.1.5.11. Random token value with high entropy . . . . . . . 51 182 5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 51 183 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 51 184 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52 185 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52 186 5.2.1.1. Automatic revocation of derived tokens if 187 abuse is detected . . . . . . . . . . . . . . . . 52 188 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52 189 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52 190 5.2.2.2. Binding of refresh token to client_id . . . . . . 52 191 5.2.2.3. Refresh Token Replacement . . . . . . . . . . . . 52 192 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53 193 5.2.2.5. Combine refresh token requests with 194 user-provided secret . . . . . . . . . . . . . . . 53 195 5.2.2.6. Device identification . . . . . . . . . . . . . . 53 196 5.2.2.7. X-FRAME-OPTION header . . . . . . . . . . . . . . 53 197 5.2.3. Client authentication and authorization . . . . . . . 54 198 5.2.3.1. Don't issue secrets to clients with 199 inappropriate security policy . . . . . . . . . . 54 200 5.2.3.2. Clients without secret require user consent . . . 55 201 5.2.3.3. Client_id only in combination with redirect_uri . 55 202 5.2.3.4. Deployment-specific client secrets . . . . . . . . 55 203 5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 204 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57 205 5.2.3.7. Use strong client authentication (e.g. 206 client_assertion / client_token) . . . . . . . . . 57 207 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 57 208 5.2.4.1. Automatic processing of repeated 209 authorizations requires client validation . . . . 57 210 5.2.4.2. Informed decisions based on transparency . . . . . 58 211 5.2.4.3. Validation of client properties by end-user . . . 58 212 5.2.4.4. Binding of authorization code to client_id . . . . 58 213 5.2.4.5. Binding of authorization code to redirect_uri . . 58 214 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 215 5.3.1. Don't store credentials in code or resources 216 bundled with software packages . . . . . . . . . . . . 59 217 5.3.2. Standard web server protection measures (for 218 config files and databases) . . . . . . . . . . . . . 59 219 5.3.3. Store secrets in a secure storage . . . . . . . . . . 59 220 5.3.4. Utilize device lock to prevent unauthorized device 221 access . . . . . . . . . . . . . . . . . . . . . . . . 59 222 5.3.5. Platform security measures . . . . . . . . . . . . . . 59 223 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 59 224 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 59 225 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 60 226 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 60 227 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 228 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 61 229 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 61 230 8.1. Normative References . . . . . . . . . . . . . . . . . . . 61 231 8.2. Informative References . . . . . . . . . . . . . . . . . . 61 232 Appendix A. Document History . . . . . . . . . . . . . . . . . . 61 233 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 235 1. Introduction 237 This document gives security considerations based on a comprehensive 238 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It 239 contains the following content: 241 o Documents any assumptions and scope considered when creating the 242 threat model. 244 o Describes the security features in-built into the OAuth protocol 245 and how they are intended to thwart attacks. 247 o Gives a comprehensive threat model for OAuth and describes the 248 respective counter measures to thwart those threats. 250 Threats include any intentional attacks on OAuth tokens and resources 251 protected by OAuth tokens as well as security risks introduced if the 252 proper security measures are not put in place. Threats are 253 structured along the lines of the protocol structure to aid 254 development teams implement each part of the protocol securely. For 255 example all threats for granting access or all threats for a 256 particular client profile or all threats for protecting the resource 257 server. 259 2. Overview 261 2.1. Scope 263 The security considerations document only considers clients bound to 264 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such 265 deployments have the following characteristics: 267 o Resource server URLs are static and well-known at development 268 time, authorization server URLs can be static or discovered. 270 o Token scope values (e.g. applicable URLs and methods) are well- 271 known at development time. 273 o Client registration: Since registration of clients is out of scope 274 of the current core spec, this document assumes a broad variety of 275 options from static registration during development time to 276 dynamic registration at runtime. 278 The following are considered out of scope : 280 o Communication between authorization server and resource server 282 o Token formats 284 o Except for "Resource Owner Password Credentials" (see 285 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by 286 authorization servers to authenticate the user 288 o Mechanism by which a user obtained an assertion and any resulting 289 attacks mounted as a result of the assertion being false. 291 o Clients are not bound to a specific deployment: An example could 292 by a mail client with support for contact list access via the 293 portable contacts API (see [portable-contacts]). Such clients 294 cannot be registered upfront with a particular deployment and must 295 dynamically discover the URLs relevant for the Oauth protocol. 297 2.2. Attack Assumptions 299 The following assumptions relate to an attacker and resources 300 available to an attacker: 302 o It is assumed the attacker has full access to the network between 303 the client and authorization servers and the client and the 304 resource server, respectively. The attacker may eaves drop on any 305 communications between those parties. He is not assumed to have 306 access to communication between authorization and resource server. 308 o It is assumed an attacker has unlimited resources to mount an 309 attack. 311 o It is assumed that 2 of the 3 parties involved in the OAuth 312 protocol may collude to mount an attack against the 3rd party. 313 For example, the client and authorization server may be under 314 control of an attacker and collude to trick a user to gain access 315 to resources. 317 2.3. Architectural assumptions 319 This section documents the assumptions about the features, 320 limitations and design options of the different entities of a OAuth 321 deployment along with the security-sensitive data-elements managed by 322 those entity. These assumptions are the foundation of the treat 323 analysis. 325 The OAuth protocol leaves deployments with a certain degree of 326 freedom how to implement and apply the standard. The core 327 specification defines the core concepts of an authorization server 328 and a resource server. Both servers can be implemented in the same 329 server entity, or they may also be different entities. The later is 330 typically the case for multi-service providers with a single 331 authentication and authorization system, and are more typical in 332 middleware architectures. 334 2.3.1. Authorization Servers 336 The following data elements MAY be stored or accessible on the 337 authorization server: 339 o user names and passwords 341 o client ids and secrets 343 o client-specific refresh tokens 345 o client-specific access tokens (in case of handle-based design) 347 o HTTPS certificate/key 349 o per authorization process (in case of handle-based design): 350 redirect_uri, client_id, authorization code 352 2.3.2. Resource Server 354 The following data elements MAY be stored or accessible on the 355 resource server: 357 o user data (out of scope) 359 o HTTPS certificate/key 361 o authz server credentials (handle-based design), or 363 o authz server shared secret/public key (assertion-based design) 365 o access tokens (per request) 367 It is assumed that a resource server has no knowledge of refresh 368 tokens, user passwords, or client secrets. 370 2.3.3. Client 372 The following data elements are stored or accessible on the client: 374 o client id (and client secret or corresponding client credential) 376 o one or more refresh tokens (persistent) and access tokens 377 (transient) per end-user or other security-context or delegation 378 context 380 o trusted CA certs (HTTPS) 382 o per authorization process: redirect_uri, authorization code 384 2.3.3.1. Web Application 386 A web application is a client running on a web server, typically with 387 its own user management. End-users access the client via an HTML 388 user interface rendered in a user- agent on the end-user's device. 389 The client credentials as well as any token issued to the client are 390 stored on the web server and are not exposed to or accessible by the 391 end-user. Tokens are bound to a single user identity at the site. 392 The potential number of tokens affected by a security breach depends 393 on number of site users. 395 Such clients are implemented using the authorization code grant type 396 (see Section 4.4.1). 398 2.3.3.2. Native Applications 400 A native application is a client which is installed and executes on 401 the end-user's device, such as a notebook, PC, Tablet, Smartphone, or 402 Gaming Console. The OAuth protocol data and credentials are 403 accessible to the end-user. It is assumed that such an application 404 can protect dynamically issued credentials, such as refresh tokens, 405 from eavesdropping by other applications residing on the same device. 407 Massively distributed applications such as these cannot reliably keep 408 secrets confidential, which are issued per software package. This is 409 because such secrets would need to be transferred to the user device 410 as part of the installation process. An attacker could reverse 411 engineer any secret from the binary or accompanying resources. 412 Native Applications are able to protect per installation/instance 413 secrets (e.g. refresh tokens) to some extent. 415 Device platforms typically allow users to lock the device with a PIN 416 code and to segregate different apps or users (multi-user operation 417 systems). 419 Some devices can be identified/authenticated (to varying degrees of 420 assurance): 422 o Handsets and smart phones by its International Mobile Equipment 423 Identity (IMEI) 425 o Set top boxes, gaming consoles, others by using certificates and 426 TPM module - Note: This does not help to identify client apps but 427 may be used to bound tokens to devices and to detect token theft 429 Mobile devices, such as handsets or smart phones have the following 430 special characteristics: 432 o Limited input capabilities, therefore such clients typically 433 obtain a refresh token in order to provide automatic login for 434 sub-sequent application sessions 436 o As mobile and small devices, they can get cloned, stolen or lost 437 easier than other devices. 439 o Security breach will affect single user (or a few users) only. 441 For the purposes of this document, the scenario of attackers who 442 control a smartphone device entirely is out of scope. 444 There are several implementation options for native applications: 446 o The authorization code grant type in combination with an embedded 447 or external browser (Section 4.4.1) 449 o The implict grant type in combination with an embedded or external 450 browser (Section 4.4.2) 452 o The resource owner password credentials grant type can be used as 453 well (Section 4.4.3) 455 Different threats exists for those implementation options, which are 456 discussed in the respective sections of the threat model. 458 2.3.3.3. User-agent-based Applications 460 A user-agent-based application is a client in which the client code 461 is downloaded from a web server and executes within a user-agent on 462 the end-user's device. The OAuth protocol data and credentials are 463 accessible to the end-user. Since such applications directly reside 464 within the user-agent, they can make seamless use of the user-agent 465 capabilities in the end-user authorization process. 467 Such client are implemented using the implicit grant grant type 468 (Section 4.4.2). 470 2.3.3.4. Autonomous 472 Autonomous clients access resource services using rights grants by 473 client credentials only. Thus the autonomous client becomes the 474 "user". Authenticating autonomous clients is conceptually similar to 475 end-user authentication since the issued tokens refer to the client's 476 identity. Autonomous clients shall always be required to use a 477 secret or some other form of authentication (e.g. client assertion in 478 the form of a SAML assertion or STS token) acceptable to the 479 authorization/token services. The client must ensure the 480 confidentiality of client_secret or other credential. 482 Such client are implemented using the client credentials grant type. 484 3. Security Features 486 These are some of the security features which have been built into 487 the OAuth 2.0 protocol to mitigate attacks and security issues. 489 3.1. Tokens 491 OAuth makes extensive use of all kinds of tokens (access tokens, 492 refresh tokens, authorization codes). The information content of a 493 token can be represented in two ways as follows: 495 Handle (or artifact) a reference to some internal data structure 496 within the authorization server, the internal data structure 497 contains the attributes of the token, such as user id, scope, etc. 498 Handles enable simple revocation and do not require cryptographic 499 mechanisms to protected token content from being modified. On the 500 other hand, handles require communication between issuing and 501 consuming entity (e.g. authorization and resource server) in order 502 to validate the token and obtain token-bound data. This 503 communication might have an negative impact on performance and 504 scalability if both entities reside on different system. Handles 505 are therefore typically used if the issuing and consuming entity 506 are the same. A 'handle' token is often referred to as an 507 'opaque' token because the resource server does not need to be 508 able to interpret the token directly, it simply uses the token. 510 Assertions (aka self-contained token) a parseable token. An 511 assertion typically has a duration, an audience, and is digitally 512 signed containing information about the user and the client. 513 Examples of assertion formats are SAML assertions and Kerberos 514 tickets. Assertions can typically directly be validated and used 515 by a resource server without interactions with the authorization 516 server. This results in better performance and scalability in 517 deployment where issuing and consuming entity reside on different 518 systems. Implementing token revocation is more difficult with 519 assertions than with handles. 521 Tokens can be used in two ways to invoke requests on resource servers 522 as follows: 524 bearer token A 'bearer token' is a token that can be used by any 525 client who has received the token (e.g. 526 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to 527 use the token it is important that communication between end- 528 points be secured to ensure that only authorized end-points may 529 capture the token. The bearer token is convenient to client 530 applications as it does not require them to do anything to use 531 them (such as a proof of identity). Bearer tokens have similar 532 characteristics to web SSO cookies used in browsers. 534 proof token A 'proof token' is a token that can only be used by a 535 specific client. Each use of the token, requires the client to 536 perform some action that proves that it is the authorized user of 537 the token. Examples of this are MAC tokens, which require the 538 client to digitally sign the resource request with a secret 539 corresponding to the particular token send with the request 540 (e.g.[I-D.ietf-oauth-v2-http-mac]). 542 3.1.1. Scope 544 A Scope represents the access authorization associated with a 545 particular token with respect to resource servers, resources and 546 methods on those resources. Scopes are the OAuth way to explicitly 547 manage the power associated with an access token. A scope can be 548 controlled by the authorization server and/or the end-user in order 549 to limit access to resources for OAuth clients these parties deem 550 less secure or trustworthy. Optionally, the client can request the 551 scope to apply to the token but only for lesser scope than would 552 otherwise be granted, e.g. to reduce the potential impact if this 553 token is sent over non secure channels. A scope is typically 554 complemented by a restriction on a token's lifetime. 556 3.1.2. Expires_In 558 Expires_In allows an authorization server (based on its policies or 559 on behalf of the end-user) to limit the lifetime of the access token. 560 This mechanisms can be used to issue short-living tokens to OAuth 561 clients the authorization server deems less secure or where sending 562 tokens over non secure channels. 564 3.2. Access Token 566 An access token is used by a client to access a resource. Access 567 tokens typically have short life-spans (minutes or hours) that cover 568 typical session lifetimes. An access token may be refreshed through 569 the use of a refresh token. The short lifespan of an access token in 570 combination with the usage of refresh tokens enables the possibility 571 of passive revocation of access authorization on the expiry of the 572 current access token. 574 3.3. Refresh Token 576 A refresh token represents a long-lasting authorization of a certain 577 client to access resources on behalf of a resource owner. Such 578 tokens are exchanged between client and authorization server, only. 579 Clients use this kind of token to obtain ("refresh") new access 580 tokens used for resource server invocations. 582 A refresh token, coupled with a short access token lifetime, can be 583 used to grant longer access to resources without involving end user 584 authorization. This offers an advantage where resource servers and 585 authorization servers are not the same entity, e.g. in a distributed 586 environment, as the refresh token must always be exchanged at the 587 authorization server. The authorization server can revoke the 588 refresh token at any time causing the granted access to be revoked 589 once the current access token expires. Because of this, a short 590 access token lifetime is important if timely revocation is a high 591 priority. 593 The refresh token is also a secret bound to the client identifier and 594 _instance_ which originally requested the authorization and 595 representing the original resource owner grant. This is ensured by 596 the authorization process as follows: 598 1. The resource owner and user-agent safely deliver the 599 authorization code to the client instance in first place. 601 2. The client uses it immediately in secure transport-level 602 communications to the authorization server and then securely 603 stores the long-lived refresh token. 605 3. The client always uses the refresh token in secure transport- 606 level communications to the authorization server to get an access 607 token (and optionally rollover the refresh token). 609 So as long as the confidentiality of the particular token can be 610 ensured by the client, a refresh tokens can also be used as an 611 alternative mean to authenticate the client instance itself. 613 3.4. Authorization Code 615 An Authorization Code represents the intermediary result of a 616 successful end-user authorization process and is used by the client 617 to obtain access and refresh token. Authorization codes are sent to 618 the client's redirect_uri instead of tokens for two purposes. 620 1. Instead of (longer-lasting) tokens, the short-living 621 authorization code is exposed to potential attackers via URI 622 query parameters (HTTP referrer), browser cacher or log file 623 entries. 625 2. It is much simpler to authenticate clients during the direct 626 request between client and authorization server than in the 627 context of the indirect authorization request. The later would 628 require digital signatures. 630 3.5. Redirect-URI 632 A Redirect-uri helps to identify clients and prevents phishing 633 attacks from other clients attempting to trick the user into 634 believing the phisher is the client. The value of the actual 635 redirect_uri used in the authorization request has to be presented 636 and is verified when an authorization code is exchanged for tokens. 637 This helps to prevent attacks, where the authorization code is 638 revealed through redirectors and counterfeit web app clients. 639 Moreover, the authorization server may require clients to pre- 640 register their redirect URIs and validate the redirect_uri in the 641 authorization request in order to detect malicious clients. 643 3.6. State parameter 645 The state parameter is used to link requests and callbacks to prevent 646 CSRF attacks where an attacker authorizes access to his own resources 647 and then tricks a users into following a redirect with the attacker's 648 token. 650 3.7. Client Identity 652 Authentication protocols have typically not taken into account the 653 identity of the software component acting on behalf of the end-user. 654 OAuth does this in order to increase the security level in delegated 655 authorization scenarios and because the client will be able to act 656 without the user's presence. Depending on the client type, the 657 client identity can and should be authenticated (see below). 659 OAuth uses the _client_id_ (client identity) to collate associated 660 request to the same originator, such as 661 o a particular end-user authorization process and the corresponding 662 request on the tokens endpoint to exchange the authorization code 663 for tokens or 665 o the initial authorization and issuance of a tokens by an end-user 666 to a particular client and sub-sequent requests by this client to 667 obtain tokens w/o user consent (automatic processing of repeated 668 authorization) 670 The client identity may also be used by the authorization server to 671 display relevant registration information to a user when requesting 672 consent for scope requested by a particular client. The client 673 identity may be used to limit the number of request for a particular 674 client or to charge the client per request. Client Identity may 675 furthermore be useful to differentiate access by different clients, 676 e.g. in server log files. 678 The _client_secret_ is used to verify the client identifier. The 679 authorization server should only rely on this form of client 680 authentication where these secrets can be deployed to the clients in 681 a secure manner and the client is capable of keeping its secret 682 confidential. Alternatively, the client identity can also be 683 verified using the _redirect_uri_ or by the _end-user_. 685 Clients (and the trustworthiness of its identity) can be classifed by 686 using the following parameters: 688 o Deployment-specific or -independent client_id (Note: for native 689 apps, every installation of a particular app on a certain device 690 is considered a deployment.) 692 o Validated properties, such as app name or redirect_uri 694 o Client_secret available 696 Typical client categories are: 698 Deployment-independent client_id with pre-registered redirect_uri and 699 without client_secret Such an identity is used by multiple 700 installations of the same software package. The identity of such 701 a client can only be validated with the help of the end-user. 702 This is a viable option for native apps in order to identify the 703 client for the purpose of displaying meta information about the 704 client to the user and to differentiate clients in log files. 705 Revocation of such an identity will affect ALL deployments of the 706 respective software. 708 Deployment-independent client_id with pre-registered redirect_uri and 709 with client_secret This is an option for native applications only, 710 since web application would require different redirect URIs. This 711 category is not advisable because the client secret cannot be 712 protected appropriately (see Section 4.1.1). Due to its security 713 weaknesses, such client identities have the same trustlevel as 714 deployment-independent clients without secret. Revocation will 715 affect ALL deployments. 717 Deployment-specific client_id with pre-registered redirect_uri and 718 with client_secret The client registration process insures the 719 validation of the client's properties, such as redirect_uri, 720 website address, web site name, contacts. Such a client identity 721 can be utilized for all relevant use cases cited above. This 722 level can be achieved for web applications in combination with a 723 manual or user-bound registration process. Achieving this level 724 for native applications is much more difficult. Either the 725 installation of the app is conducted by an administrator, who 726 validates the clients authenticity, or the process from validating 727 the app to the installation of the app on the device and the 728 creation of the client credentials is controlled end-to-end by a 729 single entity (e.g. app market provider). Revocation will affect 730 a single deployment only. 732 Deployment-specific client_id with client_secret without validated 733 properties Such a client can be recognized by the authorization 734 server in transactions with subsequent requests (e.g. 735 authorization and token issuance, refresh token issuance and 736 access token refreshment). The authorization server cannot assure 737 any property of the client to end-users. Automatic processing of 738 re-authorizations could be allowed as well. Such client 739 credentials can be generated automatically without any validation 740 of client properties, which makes it another option especially for 741 native apps. Revocation will affect a single deployment only. 743 Use of the client secret is considered a relatively weak form of 744 credential for the client. Use of stronger mechanisms such as a 745 client assertion (e.g. SAML), key cryptography, are preferred. 747 4. Security Threat Model 749 This sections gives a comprehensive threat model of OAuth 2.0. 750 Threats are grouped first by attackes directed against an OAuth 751 component, which are client, authorization server, and resource 752 server. Subsequently, they are grouped by flow, e.g. obtain token or 753 access protected resources. Every countermeasure description refers 754 to a detailed description in Section 5. 756 4.1. Clients 758 This section describes possible threats directed to OAuth clients. 760 4.1.1. Threat: Obtain Client Secrets 762 The attacker could try to get access to the secret of a particular 763 client in order to: 765 o replay its refresh tokens and authorization codes, or 767 o obtain tokens on behalf of the attacked client with the privileges 768 of that client. 770 The resulting impact would be: 772 o Client authentication of access to authorization server can be 773 bypassed 775 o Stolen refresh tokens or authorization codes can be replayed 777 Depending on the client category, there are the following approaches 778 an attacker could utilize to obtain the client secret. 780 *Attack: Obtain Secret From Source Code or Binary.* This applies for 781 all client profiles. For open source projects, secrets can be 782 extracted directly from source code in their public repositories. 783 Secrets can be extracted from application binaries just as easily 784 when published source is not available to the attacker. Even if an 785 application takes significant measures to obfuscate secrets in their 786 application distribution one should consider that the secret can 787 still be reverse-engineered by anyone with access to a complete 788 functioning application bundle or binary. 790 _Countermeasures:_ 792 o Don't issue secrets to clients with inappropriate security policy 793 - Section 5.2.3.1 795 o Clients without secrect require user consent - Section 5.2.3.2 797 o Use deployment-specific client secrets - Section 5.2.3.4 799 o Client secret revocation - Section 5.2.3.6 801 __ 803 *Attack: Obtain a Deployment-Specific Secret.* An attacker may try to 804 obtain the secret from a client installation, either from a web site 805 (web server) or a particular devices (native app). 807 _Countermeasures:_ 809 o Web server: apply standard web server protection measures (for 810 config files and databases) - Section 5.3.2 812 o Native apps: Store secrets in a secure local storage - 813 Section 5.3.3 815 o Client secret revocation - Section 5.2.3.6 817 4.1.2. Threat: Obtain Refresh Tokens 819 Depending on the client type, there are different ways refresh tokens 820 may be revealed to an attacker. The following sub-sections give a 821 more detailed description of the different attacks with respect to 822 different client types and further specialized countermeasures. Some 823 generally applicable countermeasure to mitigate such attacks shall be 824 given in advance: 826 o The authorization server must validate the client id associated 827 with the particular refresh token with every refresh request- 828 Section 5.2.2.2 830 o Limited scope tokens - Section 5.1.5.1 832 o Refresh token revocation - Section 5.2.2.4 834 o Client secret revocation - Section 5.2.3.6 836 o Refresh tokens can automatically be replaced in order to detect 837 unauthorized token usage by another party (Refresh Token 838 Replacement) - Section 5.2.2.3 840 ** 842 *Attack: Obtain Refresh Token from Web application.* An attack may 843 obtain the refresh tokens issued to a web server client. Impact: 844 Exposure of all refresh tokens on that side. 846 _Countermeasures:_ 848 o Standard web server protection measures - Section 5.3.2 850 o Use strong client authentication (e.g. client_assertion / 851 client_token), so the attacker cannot obtain the client secret 852 required to exchange the tokens - Section 5.2.3.7 854 ** 856 *Attack: Obtain Refresh Token from Native clients.* On native 857 clients, leakage of a refresh token typically affects a single user, 858 only. 860 _Read from local filesystem:_ The attacker could try get file system 861 access on the device and read the refresh tokens. The attacker could 862 utilize a malicious app for that purpose. 864 _Countermeasures:_ 866 o Store secrets in a secure storage - Section 5.3.3 868 o Utilize device lock to prevent unauthorized device access - 869 Section 5.3.4 871 __ 873 _Steal device_: The host device (e.g. mobile phone) may be stolen. 874 In that case, the attacker gets access to all apps under the identity 875 of the legitimate user. 877 _Countermeasures:_ 879 o Utilize device lock to prevent unauthorized device access - 880 Section 5.3.4 882 o Combine refresh token requests with user-provided secret - 883 Section 5.2.2.5 885 o Where a user knows the device has been stolen, they can revoke the 886 affected tokens - Section 5.2.2.4 888 __ 890 _Clone device: _All device data and applications are copied to 891 another device. Applications are used as-is on the target device. 893 _Countermeasures:_ 895 o Combine refresh token request with device identification - 896 Section 5.2.2.6 898 o Combine refresh token requests with user-provided secret - 899 Section 5.2.2.5 901 o Refresh Token Replacement - Section 5.2.2.3 903 o Where a user knows the device has been cloned, they can use this 904 countermeasure - Refresh Token Revocation - Section 5.2.2.4 906 __ 908 _Obtain refresh tokens from backup:_ A refresh token could be 909 obtained from the backup of a client application, or device. 911 _Countermeasures:_ 913 o tbd 915 4.1.3. Threat: Obtain Access Tokens 917 Depending on the client type, there are different ways access tokens 918 may be revealed to an attacker. Access tokens could be stolen from 919 the device if the app stores them in a storage, which is accessible 920 to other applications. 922 Impact: Where the token is a bearer token and no additional mechanism 923 is used to identify the client, the attacker can access all resources 924 associated with the token and its scope. 926 Countermeasures: 928 o Keep access tokens in transient memory and limit grants: 929 Section 5.1.6 931 o Limited scope tokens - Section 5.1.5.1 933 o Keep access tokens in private memory or apply same protection 934 means as for refresh tokens - Section 5.2.2 936 o Keep access token lifetime short - Section 5.1.5.3 938 4.1.4. Threat: End-user credentials phished using compromised or 939 embedded browser 941 A malicious app could attempt to phish end-user passwords by misusing 942 an embedded browser in the end-user authorization process, or by 943 presenting its own user-interface instead of allowing trusted system 944 browser to render the authorization UI. By doing so, the usual 945 visual trust mechanisms may be bypassed (e.g. TLS confirmation, web 946 site mechanisms). By using an embedded or internal client app UI, 947 the client app has access to additional information it should not 948 have access to (e.g. uid/password). 950 Impact: If the client app or the communication is compromised, the 951 user would not be aware and all information in the authorization 952 exchange could be captured such as username and password. 954 Countermeasures: 956 o Client developers and end-user can be educated to trust an 957 external System-Browser only. 959 o Client apps could be validated prior publication in a app market. 961 o Client developers should not collect authentication information 962 directly from users and should instead use redirects to and back 963 from a trusted external system-browser. 965 4.2. Authorization Endpoint 967 4.2.1. Threat: Password phishing by counterfeit authorization server 969 OAuth makes no attempt to verify the authenticity of the 970 Authorization Server. A hostile party could take advantage of this 971 by intercepting the Client's requests and returning misleading or 972 otherwise incorrect responses. This could be achieved using DNS or 973 ARP spoofing. Wide deployment of OAuth and similar protocols may 974 cause Users to become inured to the practice of being redirected to 975 websites where they are asked to enter their passwords. If Users are 976 not careful to verify the authenticity of these websites before 977 entering their credentials, it will be possible for attackers to 978 exploit this practice to steal Users' passwords. 980 Countermeasures: 982 o Authorization servers should consider such attacks when developing 983 services based on OAuth, and should require transport-layer 984 security for any requests where the authenticity of the 985 authorization server or of request responses is an issue (see 986 Section 5.1.2). 988 o Authorization servers should attempt to educate Users about the 989 risks phishing attacks pose, and should provide mechanisms that 990 make it easy for users to confirm the authenticity of their sites. 992 4.2.2. Threat: User unintentionally grants too much access scope 994 When obtaining end user authorization, the end-user may not 995 understand the scope of the access being granted and to whom or they 996 may end up providing a client with access to resources which should 997 not be permitted. 999 Countermeasures: 1001 o Explain the scope (resources and the permissions) the user is 1002 about to grant in a understandable way - Section 5.2.4.2 1004 o Narrow scope based on client-specific policy - When obtaining end 1005 user authorization and where the client requests scope, the 1006 authorization server may want to consider whether to honour that 1007 scope based on who the client is. That decision is between the 1008 client and authorization server and is outside the scope of this 1009 spec. The authorization server may also want to consider what 1010 scope to grant based on the profile used, e.g. providing lower 1011 scope where no client secret is provided from a native 1012 application. - Section 5.1.5.1 1014 4.2.3. Threat: Malicious client obtains existing authorization by fraud 1016 Authorization servers may wish to automatically process authorization 1017 requests from clients which have been previously authorized by the 1018 user. When the user is redirected to the authorization server's end- 1019 user authorization endpoint to grant access, the authorization server 1020 detects that the user has already granted access to that particular 1021 client. Instead of prompting the user for approval, the 1022 authorization server automatically redirects the user back to the 1023 client. 1025 A malicious client may exploit that feature and try to obtain such an 1026 authorization code instead of the legimate client. 1028 Countermeasures: 1030 o Authorization servers should not automatically process repeat 1031 authorizations where the client is not authenticated through a 1032 client secret or some other authentication mechanism such as 1033 signing with security certs (see Section 5.2.3.7) or validation of 1034 a pre-registered redirect uri (Section 5.2.3.5 ) 1036 o Authorization servers can mitigate the risks associated with 1037 automatic processing by limiting the scope of Access Tokens 1038 obtained through automated approvals - Section 5.1.5.1 1040 4.2.4. Threat: Open redirector 1042 An attacker could use the end-user authorization endpoint and the 1043 redirect_uri parameter to abuse the authorization server as 1044 redirector. 1046 Impact? 1047 Countermeasure 1049 o don't redirect to redirect_uri, if client identity or redirect_uri 1050 could not be verified 1052 4.3. Token endpoint 1054 4.3.1. Threat: Eavesdropping access tokens 1056 Attackers may attempts to eaversdrop access token on transit from the 1057 authorization server to the client. 1059 Impact: The attacker is able to access all resources with the 1060 permissions covered by the scope of the particular access token. 1062 Countermeasures: 1064 o Authorization servers MUST ensure that these transmissions are 1065 protected using transport-layer mechanisms such as TLS or SSL (see 1066 Section 5.1.1). 1068 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1069 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1070 tokens can be used to reduce the damage in case of leaks. 1072 4.3.2. Threat: Obtain access tokens from authorization server database 1074 This threat is applicable if the authorization server stores access 1075 tokens as handles in a database. An attacker may obtain access 1076 tokens from the authorization server's database by gaining access to 1077 the database or launching a SQL injection attack. Impact: disclosure 1078 of all access tokens 1080 Countermeasures: 1082 o System security measures - Section 5.1.4.1.1 1084 o Store access token hashes only - Section 5.1.4.1.3 1086 o Standard SQL inj. Countermeasures - Section 5.1.4.1.2 1088 4.3.3. Threat: Obtain client credentials over non secure transport 1090 An attacker could attempt to eavesdrop the transmission of client 1091 credentials between client and server during the client 1092 authentication process or during Oauth token requests. Impact: 1093 Revelation of a client credential enabling the possibility for 1094 phishing or immitation of a client service. 1096 Countermeasures: 1098 o Implement transport security through Confidentiality of Requests 1100 o Alternative authentication means, which do not require to send 1101 plaintext credentials over the wire (Examples: Digest 1102 authentication) 1104 4.3.4. Threat: Obtain client secret from authorization server database 1106 An attacker may obtain valid client_id/secret combinations from the 1107 authorization server's database by gaining access to the database or 1108 launching a SQL injection attack. Impact: disclosure of all 1109 client_id/secret combinations. This allows the attacker to act on 1110 behalf of legitimate clients. 1112 Countermeasures: 1114 o Ensure proper handling of credentials as per Credential storage 1115 protection. 1117 4.3.5. Threat: Obtain client secret by online guessing 1119 An attacker may try to guess valid client_id/secret pairs. Impact: 1120 disclosure of single client_id/secret pair. 1122 Countermeasures: 1124 o High entropy of secrets - Section 5.1.4.2.2 1126 o Lock accounts - Section 5.1.4.2.3 1128 4.3.6. Threat: DoS on dynamic client secret creation 1130 If an authorization servers includes a nontrivial amount of entropy 1131 in client secrets and if the authorization server automatically 1132 grants them, an attacker could exhaust the pool by repeatedly 1133 applying for them. 1135 Countermeasures: 1137 o The authorization server should consider some verification step 1138 for new clients. The authorization server should include a 1139 nontrivial amount of entropy in client secrets. 1141 4.4. Obtaining Authorization 1143 This section covers threats which are specific to certain flows 1144 utilized to obtain access tokens. Each flow is characterized by 1145 response types and/or grant types on the end-user authorization and 1146 tokens endpoint, respectively. 1148 4.4.1. Authorization Code 1150 4.4.1.1. Threat: Eavesdropping or leaking authorization codes 1152 An attacker could try to eavesdrop transmission of the authorization 1153 code between authorization server and client. Furthermore, 1154 authorization codes are passed via the browser which may 1155 unintentionally leak those codes to untrusted web sites and attackers 1156 by different ways: 1158 o Referer headers: browsers frequently pass a "referer" header when 1159 a web page embeds content, or when a user travels from one web 1160 page to another web page. These referer headers may be sent even 1161 when the origin site does not trust the destination site. The 1162 referer header is commonly logged for traffic analysis purposes. 1164 o Request logs: web server request logs commonly include query 1165 parameters on requests. 1167 o Open redirectors: web sites sometimes need to send users to 1168 another destination via a redirector. Open redirectors pose a 1169 particular risk to web-based delegation protocols because the 1170 redirector can leak verification codes to untrusted destination 1171 sites. 1173 o Browser history: web browsers commonly record visited URLs in the 1174 browser history. Another user of the same web browser may be able 1175 to view URLs that were visited by previous users. 1177 Note: A description of a similar attacks on the SAML protocol can be 1178 found at http://www.oasis-open.org/committees/download.php/3405/ 1179 oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http:// 1180 www.thomasgross.net/publications/papers/ 1181 GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http:// 1182 www.oasis-open.org/committees/download.php/11191/ 1183 sstc-gross-sec-analysis-response-01.pdf. 1185 Countermeasures: 1187 o Authorization server as well as the client MUST ensure that these 1188 transmissions are protected using transport-layer mechanisms such 1189 as TLS or SSL (see Section 5.1.1). 1191 o The authorization server shall require the client to authenticate 1192 wherever possible, so the binding of the authorization code to a 1193 certain client can be validated in a reliable way (see 1194 Section 5.2.4.4). 1196 o Limited duration of authorization codes - Section 5.1.5.3 1198 o The authorization server SHOULD enforce a one time usage 1199 restriction (see Section 5.1.5.4). 1201 o If an Authorization Server observes multiple attempts to redeem a 1202 authorization code, the Authorization Server may want to revoke 1203 all tokens granted based on the authorization code (see 1204 Section 5.2.1.1). 1206 o In the absence of these countermeasures, reducing scope 1207 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1208 tokens can be used to reduce the damage in case of leaks. 1210 o The client server may reload the target page of the redirect_uri 1211 in order to automatically cleanup the browser cache. 1213 4.4.1.2. Threat: Obtain authorization codes from authorization server 1214 database 1216 This threat is applicable if the authorization server stores 1217 authorization codes as handles in a database. An attacker may obtain 1218 authorization codes from the authorization server's database by 1219 gaining access to the database or launching a SQL injection attack. 1220 Impact: disclosure of all authorization codes, most likely along with 1221 the respective redirect_uri and client_id values. 1223 Countermeasures: 1225 o Credential storage protection can be employed - Section 5.1.4.1 1227 o System security measures - Section 5.1.4.1.1 1229 o Store access token hashes only - Section 5.1.4.1.3 1231 o Standard SQL inj. Countermeasures - Section 5.1.4.1.2 1233 4.4.1.3. Threat: Online guessing of authorization codes 1235 An attacker may try to guess valid authorization code values and send 1236 it using the grant type "code" in order to obtain a valid access 1237 token. Impact: disclosure of single access token (+probably refresh 1238 token) 1240 Countermeasures: 1242 o For handle-based designs: Section 5.1.5.11 1244 o For assertion-based designs: Section 5.1.5.9 1246 o Authenticate the client, adds another value the attacker has to 1247 guess - Section 5.2.3.4 1249 o Binding of authorization code to redirect_uri, adds another value 1250 the attacker has to guess - Section 5.2.4.5 1252 o Short expiration time - Section 5.1.5.3 1254 4.4.1.4. Threat: Malicious client obtains authorization 1256 A malicious client could counterfeit a valid client and obtain an 1257 access authorization that way. The malicious client could even 1258 utilize screen scraping techniques in order to simulate the user 1259 consent in the authorization flow. 1261 Assumption: It is not the task of the authorization server to protect 1262 the end-user's device from malicious software. This is the 1263 responsibility of the platform running on the particular device 1264 probably in cooperation with other components of the respective 1265 ecosystem (e.g. an application management infrastructure). The sole 1266 responsibility of the authorization server is to control access to 1267 the end-user's resources living in resource servers and to prevent 1268 unauthorized access to them. Based on this assumption, the following 1269 countermeasures are available to cope with the threat. 1271 Countermeasures: 1273 o The authorization server should authentication the client, if 1274 possible (see Section 5.2.3.4). Note: the authentication takes 1275 place after the end-user has authorized the access. 1277 o The authorization server should validate the client's redirect_uri 1278 against the pre-registered redirect_uri, if one exists (see 1279 Section 5.2.3.5). Note: The validation of the redirect_uri is the 1280 only technical mean to recognize a malicious client id in advance 1281 of the authorization process. Further note this does not work for 1282 native applications because in contrast to web applications this 1283 URI is not bound to a single communication endpoint. The valid 1284 client's redirect_uri (typically with custom scheme) can be used 1285 by a malicious on any device. 1287 o After authenticating the end-user, the authorization server should 1288 ask him/her for consent. In this context, the user shall be 1289 explained the purpose, scope, and duration of the authorization. 1290 Moreover, the authorization server must view to the end-user the 1291 meta data it associates with the particular client. It is up to 1292 the user to validate the binding of this data to the particular 1293 application (e.g. Name) and to approve the authorization request. 1294 (see Section 5.2.4.3). 1296 o The authorization server must not perform automatic re- 1297 authorizations for clients it is unable to reliably authenticate 1298 or validate (see Section 5.2.4.1). 1300 o If the authorization server automatically authenticates the end- 1301 user, it may nevertheless require some user input in order to 1302 prevent screen scraping. Examples are CAPTCHAs or user-specific 1303 secret like PIN codes. 1305 o The authorization server may also limit the scope of tokens it 1306 issues to clients it cannot reliably authenticate (see 1307 Section 5.1.5.1). 1309 4.4.1.5. Threat: Authorization code phishing 1311 A hostile party could impersonate the client site and get access to 1312 the authorization code. This could be achieved using DNS or ARP 1313 spoofing. This applies to clients, which are web applications, thus 1314 the redirect URI is not local to the host where the user's browser is 1315 running. 1317 Impact: This affects web applications and may lead to a disclosure of 1318 authorization codes and, potentially, the corresponding access and 1319 refresh tokens. 1321 Countermeasures: 1323 o The authorization server MUST require the client to authenticate 1324 with a secret, so the binding of the authorization code to a 1325 certain client can be validated in a reliable way (see 1326 Section 5.2.4.4). 1328 o The redirect_uri of the client SHOULD point to a HTTPS protected 1329 endpoint and the browser shall be utilized to authenticate this 1330 redirect_uri using server authentication (see Section 5.1.2). 1332 4.4.1.6. Threat: User session impersonation 1334 A hostile party could impersonate the client site and impersonate the 1335 user's session on this client. This could be achieved using DNS or 1336 ARP spoofing. This applies to clients, which are web applications, 1337 thus the redirect URI is not local to the host where the user's 1338 browser is running. 1340 Impact: An attacker who intercepts the authorization code as it is 1341 sent by the browser to the callback endpoint can gain access to 1342 protected resources by submitting the authorization code to the 1343 client. The client will exchange the authorization code for an 1344 access token and use the access token to access protected resources 1345 for the benefit of the attacker, delivering protected resources to 1346 the attacker, or modifying protected resources as directed by the 1347 attacker. If OAuth is used by the client to delegate authentication 1348 to a social site (e.g. as in the implementation of the "Facebook 1349 Login" button), the attacker can use the intercepted authorization 1350 code to log in to the client as the user. 1352 Note: Authenticating the client during authorization code exchange 1353 will not help to detect such an attack as it is the legitimate client 1354 that obtains the tokens. 1356 Countermeasures: 1358 o In order to prevent an attacker from impersonating the end-users 1359 session, the redirect_uri of the client MUST point to a HTTPS 1360 protected endpoint and the browser shall be utilized to 1361 authenticate this redirect_uri using server authentication (see 1362 Section 5.1.2) 1364 4.4.1.7. Threat: Authorization code leakage through counterfeit client 1366 The attack leverages the authorization code grant type in an attempt 1367 to get another user (victim) to log-in, authorize access to his/her 1368 resources, and sub-sequently obtain the authorization code and inject 1369 it into a client application using the attacker's account. The goal 1370 is to associate an access authorization for resources of the victim 1371 with the user account of the attacker on a client site. 1373 The attacker abuses an existing client application and combines it 1374 with his own counterfeit client web site. The attack depends on the 1375 victim expecting the client application to request access to a 1376 certain resource server. The victim, seeing only a normal request 1377 from an expected application, approves the request. The attacker 1378 then uses the victim's authorization to gain access to the 1379 information unknowingly authorized by the victim. 1381 The attacker conducts the following flow: 1383 1. The attacker accesses the client web site (or application) and 1384 initates data access to a particular resource server. The client 1385 web site in turn initiates an authorization request to the 1386 resource server's authorization server. Instead of proceeding 1387 with the authorization process, the attacker modifies the 1388 authorization server end-user authorization URL as constructed by 1389 the client to include a redirect_uri parameter refering to a web 1390 site under his control (attacker's web site). 1392 2. The attacker tricks another user (the victim) to open that 1393 modified end-user authorization URI and to authorize access (e.g. 1394 an email link, or blog link). The way the attacker achieve that 1395 goal is out of scope. 1397 3. Having clicked the link, the victim is requested to authenticate 1398 and authorize the client site to have access. 1400 4. After completion of the authorization process, the authorization 1401 server redirects the user agent to the attacker's web site 1402 instead of the original client web site. 1404 5. The attacker obtains the authorization code from his web site by 1405 means out of scope of this document. 1407 6. He then constructs a redirect_uri to the target web site (or app) 1408 based on the original authorization request's redirect_uri and 1409 the newly obtained authorization code and directs his user agent 1410 to this URL. The authorization code is injected into the 1411 original client site (or application). 1413 7. The client site uses the authorization code to fetch a token from 1414 the authorization server and associates this token with the 1415 attacker's user account on this site. 1417 8. The attacker may now access the victims resources using the 1418 client site. 1420 Impact: The attackes gains access to the victim's resources as 1421 associated with his account on the client site. 1423 Countermeasures: 1425 o The attacker must use another redirect_uri for its authorization 1426 process than the target web site because it needs to intercept the 1427 flow. So if the authorization server associates the authorization 1428 code with the redirect_uri of a particular end-user authorization 1429 and validates this redirect_uri with the redirect_uri passed to 1430 the tokens endpount, such an attack is detected (see 1431 Section 5.2.4.5). 1433 o The authorization server may also enforce the usage and validation 1434 of pre-registered redirect URIs (see Section 5.2.3.5). This will 1435 allow for an early recognition of sesssion fixation attempts. 1437 o For native apps, one could also consider to use deployment- 1438 specific client ids and secrets (see Section 5.2.3.4, along with 1439 the binding of authorization code to client_id (see 1440 Section 5.2.4.4), to detect such an attack because the attacker 1441 does not have access the deployment-specific secret. Thus he will 1442 not be able to exchange the authorization code. 1444 o The client may consider to use other flows, which are not 1445 vulnerable to this kind of attacks such as "Implicit Grant" or 1446 "Resource Owner Password Credentials" (see Section 4.4.2 or 1447 Section 4.4.3). 1449 4.4.1.8. Threat: CSRF attack against redirect-uri 1451 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1452 requests are transmitted from a user that the website trusts or has 1453 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1454 on OAuth approvals can allow an attacker to obtain authorization to 1455 OAuth protected resources without the consent of the User. 1457 This attack works against the redirect-uri used in the authorization 1458 code flow. An attacker could authorize an authorization code to 1459 their own protected resources on an authorization server. He then 1460 aborts the redirect flow back to the client on his device and tricks 1461 the victim into executing the redirect back to the client. The 1462 client receives the redirect, fetches the token(s) from the 1463 authorization server and asscociates the victim's client session with 1464 the resources accessible using the token. 1466 Impact: The user accesses resources on behalf of the attacker. The 1467 effective impact depends on the type of resource accessed. For 1468 example, the user may upload private items to an attacker's 1469 resources. Or when using OAuth in 3rd party login scenarios, the 1470 user may associate his client account with the attacker's idenity at 1471 the external identity provider. This way the attacker could easily 1472 accces the victim's data at the client by logging in from another 1473 device with his credentials at the external identity provider. 1475 Countermeasures: 1477 o The state parameter should be used to link the authorization 1478 request with the redirect-uri used deliver the access token. This 1479 will ensure the client is not tricked into completing any redirect 1480 callback unless it is linked to an authorization request the 1481 client initiated. The state parameter should be unguessable and 1482 the client should be capable of keeping the state parameter 1483 secret. 1485 o Client developers and end-user can be educated not follow 1486 untrusted urls. 1488 4.4.1.9. Threat: Clickjacking attack against authorization 1490 With Clickjacking, a malicious site loads the target site in a 1491 transparent iframe overlaid on top of a set of dummy buttons which 1492 are carefully constructed to be placed directly under important 1493 buttons on the target site. When a user clicks a visible button, 1494 they are actually clicking a button (such as an "Authorize" button) 1495 on the hidden page. 1497 Impact: An attacker can steal a user's authentication credentials and 1498 access their resources 1500 Countermeasure 1502 o Native applications SHOULD use external browsers instead of 1503 embedding browsers in an iFrame when requesting end-user 1504 authorization 1506 o For newer browsers, avoidance of iFrames can be enforced server 1507 side by using the X-FRAME-OPTION header - Section 5.2.2.7 1509 o For older browsers, javascript framebusting techniques can be used 1510 but may not be effective in all browsers. 1512 4.4.1.10. Threat: DoS, Exhaustion of resources attacks 1514 If an authorization server includes a nontrivial amount of entropy in 1515 authorization codes or access tokens (limiting the number of possible 1516 codes/tokens) and automatically grants either without user 1517 intervention and has no limit on code or access tokens per user, an 1518 attacker could exhaust the pool by repeatedly directing user(s) 1519 browser to request code or access tokens. This is because more 1520 entropy means a larger number of tokens can be issued. 1522 Countermeasures: 1524 o The authorization server should consider limiting the number of 1525 access tokens granted per user. The authorization server should 1526 include a nontrivial amount of entropy in authorization codes. 1528 4.4.1.11. Threat: DoS using manufactured authorization codes 1530 An attacker who owns a botnet can locate the redirect URIs of clients 1531 that listen on HTTP, access them with random authorization codes, and 1532 cause a large number of HTTPS connections to be concentrated onto the 1533 authorization server. This can result in a DoS attack on the 1534 authorization server. 1536 This attack can still be effective even when CSRF defense/the 'state' 1537 parameter are deployed on the client side. With such a defense, the 1538 attacker might need to incur an additional HTTP request to obtain a 1539 valid CSRF code/ state parameter. This apparently cuts down the 1540 effectiveness of the attack by a factor of 2. However, if the HTTPS/ 1541 HTTP cost ratio is higher than 2 (the cost factor is estimated to be 1542 around 3.5x at 1543 http://www.semicomplete.com/blog/geekery/ssl-latency.html), the 1544 attacker still achieves a magnification of resource utilization at 1545 the expense of the authorization server. 1547 Impact: There are a few effects that the attacker can accomplish with 1548 this OAuth flow that they cannot easily achieve otherwise. 1550 1. Connection laundering: With the clients as the relay between the 1551 attacker and the authorization server, the authorization server 1552 learns little or no information about the identity of the 1553 attacker. Defenses such rate limiting on the offending attacker 1554 machines are less effective due to the difficulty to identify the 1555 attacking machines. Although an attacker could also launder its 1556 connections through an anonymizing systems such as Tor, the 1557 effectiveness of that approach depends on the capacity of the 1558 anonyming system. On the other hand, a potentially large number 1559 of OAuth clients could be utilized for this attack. 1561 2. Asymmetric resource utilization: The attacker incurs the cost of 1562 an HTTP connection and causes an HTTPS connection to be made on 1563 the authorization server; and the attacker can co-ordinate the 1564 timing of such HTTPS connections across multiple clients 1565 relatively easily. Although the attacker could achieve something 1566 similar, say, by including an iframe pointing to the HTTPS URL of 1567 the authorization server in an HTTP web page and lure web users 1568 to visit that page, timing attacks using such a scheme may be 1569 more difficult as it seems nontrivial to synchronize a large 1570 number of users to simultaneously visit a particular site under 1571 the attacker's control. 1573 Countermeasures 1575 o Though not a complete countermeasure by themselves, CSRF defense 1576 and the 'state' parameter created with secure random codes SHOULD 1577 be deployed on the client side. The client SHOULD forward the 1578 authorization code to the authorization server only after both the 1579 CSRF token and the 'state' parameter are validated. 1581 o If the client authenticates the user, either through a single sign 1582 on protocol ( such as OpenID / Facebook Connect ) or through local 1583 authentication, the client SHOULD suspend the access by a user 1584 account if the number of invalid authorization codes submitted by 1585 this user exceeds a certain threshold. 1587 o The authorization server SHOULD send an error response to the 1588 client reporting an invalid authorization code and rate limit or 1589 disallow connections from clients whose number of invalid requests 1590 exceeds a threshold. 1592 o The authorization server MAY in addition sign the authorization 1593 code using the public key from its SSL certificate, and require 1594 the client to validate the signature. To enhance interoperability 1595 between multiple clients and authorization servers, a standard 1596 procedure to create and validate the signature (including what 1597 attributes to sign) MAY be developed and agreed between the 1598 clients and the servers. 1600 4.4.2. Implicit Grant 1602 he implict grant flow, the access token is directly returned to the 1603 client as fragment part of the redirect_uri. It is assumed that the 1604 token is not send to the redirect_uri target since HTTP user agents 1605 do not send fragments server requests. Thus an attacker cannot 1606 eavesdrop the access token on this communication path and It cannot 1607 leak through HTTP referer headers. 1609 4.4.2.1. Threat: Access token leak in transport/end-points 1611 This token might be eavesdropped by an attacker. The token is sent 1612 from server to client via a URI fragment of the redirect_uri. If the 1613 communication is not secured or the end-point is not secured, the 1614 token could be leaked by parsing the returned URI. 1616 Impact: the attacker would be able to assume the same rights granted 1617 by the token. 1619 Countermeasures: 1621 o The authorization server must ensure confidentialty of the 1622 response from the authorizaton server to the client (see 1623 Section 5.1.1). 1625 4.4.2.2. Threat: Access token leak in browser history 1627 An attacker could obtain the token from the browsers history. Note 1628 this means the attacker needs access to the particular device. 1630 Countermeasures: 1632 o Shorten token duration (see Section 5.1.5.3) and reduced scope of 1633 the token may reduce the impact of that attack (see 1634 Section 5.1.5.1). 1636 o Make these requests non-cachable 1638 o Native apps can directly embedd a browser widget and therewith 1639 gain full control of the cache. So the app can cleanup browser 1640 history after authorization process. 1642 4.4.2.3. Threat: Malicious client obtains authorization 1644 An malicious client could attempt to obtain a token by fraud. 1646 The same countermeasures as for Section 4.4.1.4 are applicable, 1647 except client authentication. 1649 4.4.2.4. Threat: Manipulation of scripts 1651 A hostile party could act as the client web server and replace or 1652 modify the actual implementation of the client (script). This could 1653 be achieved using DNS or ARP spoofing. This applies to clients 1654 implemented within the Web Browser in a scripting language. 1656 Impact: The attacker could obtain user credential information and 1657 assume the full identity of the user. 1659 Countermeasures: 1661 o The authorization server must authenticate the server from which 1662 scripts are obtained (see Section 5.1.2). 1664 o The client must ensure that scripts obtained have not been altered 1665 in transport (see Section 5.1.1). 1667 o Introduce one time per-use secrets (e.g. client_secret) values 1668 that can only be used by scripts in a small time window once 1669 loaded from a server. The intention would be to reduce the 1670 effectiveness of copying client-side scripts for re-use in an 1671 attackers modified code. [[pending discussion]] 1673 4.4.2.5. Threat: CSRF attack against redirect-uri 1675 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1676 requests are transmitted from a user that the website trusts or has 1677 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1678 on OAuth approvals can allow an attacker to obtain authorization to 1679 OAuth protected resources without the consent of the User. 1681 This attack works against the redirect-uri used in the implicit grant 1682 flow. An attacker could acquire an access token to their own 1683 protected resources. He could then construct a redirect-uri and 1684 embed their access token in that uri. If he can trick the user into 1685 following the redirect-uri and the client does not have protection 1686 against this attack, the user may have the attacker's access token 1687 authorized within their client. 1689 Impact: The user accesses resources on behalf of the attacker. The 1690 effective impact depends on the type of resource accessed. For 1691 example, the user may upload private items to an attacker's 1692 resources. Or when using OAuth in 3rd party login scenarios, the 1693 user may associate his client account with the attacker's idenity at 1694 the external identity provider. This way the attacker could easily 1695 accces the victim's data at the client by logging in from another 1696 device with his credentials at the external identity provider. 1698 Countermeasures: 1700 o The state parameter should be used to link the authorization 1701 request with the redirect-uri used deliver the access token. This 1702 will ensure the client is not tricked into completing any redirect 1703 callback unless it is linked to an authorization request the 1704 client initiated. The state parameter should be unguessable and 1705 the client should be capable of keeping the state parameter 1706 secret. 1708 o Client developers and end-user can be educated not follow 1709 untrusted urls. 1711 4.4.3. Resource Owner Password Credentials 1713 The "Resource Owner Password Credentials" grant type (see 1714 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration 1715 reasons, allows a client to request an access token using an end- 1716 users user-id and password along with its own credential. This grant 1717 type has higher risk because it maintains the uid/password anti- 1718 pattern. Additionally, because the user does not have control over 1719 the authorization process, clients using this grant type are not 1720 limited by scope, but instead have potentially the same capabilities 1721 as the user themselves. As there is no authorization step, the 1722 ability to offer token revocation is bypassed. 1724 Impact: The resource server can only differentiate scope based on the 1725 access token being associated with a particular client. The client 1726 could also acquire long-living tokens and pass them up to a attacker 1727 web service for further abuse. The client, eavesdroppers, or end- 1728 points could eavesdrop user id and password. 1730 Countermeasures: 1732 o Except for migration reasons, minimize use of this grant type 1734 o The authorization server must validate the client id associated 1735 with the particular refresh token with every refresh request - 1736 Section 5.2.2.2 1738 o Authorization server MUST ensure that these transmissions are 1739 protected using transport-layer mechanisms such as TLS or SSL (see 1740 Section 5.1.1). 1742 4.4.3.1. Threat: Accidental exposure of passwords at client site 1744 If the client does not provide enough protection, an attacker or 1745 disgruntled employee could retrieve the passwords for a user. 1747 Countermeasures: 1749 o Use other flows, which do not rely on the client's cooperation for 1750 secure resource owner credential handling 1752 o Use digest authentication instead of plaintext credential 1753 processing 1755 o Obfuscation of passwords in logs 1757 4.4.3.2. Threat: Client obtains scopes without end-user authorization 1759 All interaction with the resource owner is performed by the client. 1760 Thus it might, intentionally or unintentionally, happen that the 1761 client obtains a token with scope unknown for or unintended by the 1762 resource owner. For example, the resource owner might think the 1763 client needs and acquires read-only access to its media storage only 1764 but the client tries to acquire an access token with full access 1765 permissions. 1767 Countermeasures: 1769 o Use other flows, which do not rely on the client's cooperation for 1770 resource owner interaction 1772 o The authorization server may generally restrict the scope of 1773 access tokens (Section 5.1.5.1) issued by this flow. If the 1774 particular client is trustworthy and can be authenticated in a 1775 reliable way, the authorization server could relax that 1776 restriction. Resource owners may prescribe (e.g. in their 1777 preferences) what the maximum permission for client using this 1778 flow shall be. 1780 o The authorization server could notify the resource owner by an 1781 appropriate media, e.g. e-Mail, of the grant issued (see 1782 Section 5.1.3). 1784 4.4.3.3. Threat: Client obtains refresh token through automatic 1785 authorization 1787 All interaction with the resource owner is performed by the client. 1788 Thus it might, intentionally or unintentionally, happen that the 1789 client obtains a long-term authorization represented by a refresh 1790 token even if the resource owner did not intend so. 1792 Countermeasures: 1794 o Use other flows, which do not rely on the client's cooperation for 1795 resource owner interaction 1797 o The authorization server may generally refuse to issue refresh 1798 tokens in this flow (see Section 5.2.2.1). If the particular 1799 client is trustworthy and can be authenticated in a reliable way 1800 (see client authentication), the authorization server could relax 1801 that restriction. Resource owners may allow or deny (e.g. in 1802 their preferences) to issue refresh tokens using this flow as 1803 well. 1805 o The authorization server could notify the resource owner by an 1806 appropriate media, e.g. e-Mail, of the refresh token issued (see 1807 Section 5.1.3). 1809 4.4.3.4. Threat: Obtain user passwords on transport 1811 An attacker could attempt to eavesdrop the transmission of end-user 1812 credentials with the grant type "password" between client and server. 1814 Impact: disclosure of a single end-users password. 1816 Countermeasures: 1818 o Confidentiality of Requests - Section 5.1.1 1820 o alternative authentication means, which do not require to send 1821 plaintext credentials over the wire (Examples: Digest 1822 authentication) 1824 4.4.3.5. Threat: Obtain user passwords from authorization server 1825 database 1827 An attacker may obtain valid username/password combinations from the 1828 authorization server's database by gaining access to the database or 1829 launching a SQL injection attack. 1831 Impact: disclosure of all username/password combinations. The impact 1832 may exceed the domain of the authorization server since many users 1833 tend to use the same credentials on different services. 1835 Countermeasures: 1837 o Credential storage protection can be employed - Section 5.1.4.1 1839 4.4.3.6. Threat: Online guessing 1841 An attacker may try to guess valid username/password combinations 1842 using the grant type "password". 1844 Impact: Revelation of a single username/password combination. 1846 Countermeasures: 1848 o Password policy - Section 5.1.4.2.1 1850 o Lock accounts - Section 5.1.4.2.3 1851 o Tar pit - Section 5.1.4.2.4 1853 o CAPTCHA - Section 5.1.4.2.5 1855 o Abandon on grant type "password" 1857 o Client authentication (see Section 5.2.3) will provide another 1858 authentication factor and thus hinder the attack. 1860 4.4.4. Client Credentials 1862 Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an 1863 identifier (not secret) combined with an additional means (such as a 1864 matching client secret) of authenticating a client. 1866 [[Threats seem to be covered elsewhere such as Section 4.4.1.1]] 1868 4.5. Refreshing an Access Token 1870 4.5.1. Threat: Eavesdropping refresh tokens from authorization server 1872 dAn attacker may eavesdrop refresh tokens when they are transmitted 1873 from the authorization server to the client. 1875 Countermeasures: 1877 o Authorization servers MUST ensure that these transmissions are 1878 protected using transport-layer mechanisms such as TLS or SSL (see 1879 Section 5.1.1). 1881 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1882 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for 1883 issued access tokens can be used to reduce the damage in case of 1884 leaks. 1886 4.5.2. Threat: Obtaining refresh token from authorization server 1887 database 1889 This threat is applicable if the authorization server stores refresh 1890 tokens as handles in a database. An attacker may obtain refresh 1891 tokens from the authorization server's database by gaining access to 1892 the database or launching a SQL injection attack. 1894 Impact: disclosure of all refresh tokens 1896 Countermeasures: 1898 o Credential storage protection - Section 5.1.4.1 1900 o Bind token to client id, if the attacker cannot obtain the 1901 required id and secret - Section 5.1.5.8 1903 4.5.3. Threat: Obtain refresh token by online guessing 1905 An attacker may try to guess valid refresh token values and send it 1906 using the grant type "refresh_token" in order to obtain a valid 1907 access token. 1909 Impact: exposure of single refresh token and derivable access tokens. 1911 Countermeasures: 1913 o For handle-based designs - Section 5.1.5.11 1915 o For assertion-based designs - Section 5.1.5.9 1917 o Bind token to client id, because the attacker would guess the 1918 matching client id, too (see Section 5.1.5.8) 1920 o Authenticate the client, adds another element the attacker has to 1921 guess (see Section 5.2.3.4) 1923 4.5.4. Threat: Obtain refresh token phishing by counterfeit 1924 authorization server 1926 An attacker could try to obtain valid refresh tokens by proxying 1927 requests to the authorization server. Given the assumption that the 1928 authorization server URL is well-known at development time or can at 1929 least be obtained from a well-known resource server, the attacker 1930 must utilize some kind of spoofing in order to suceed. 1932 Countermeasures: 1934 o Server authentication (as described in Section 5.1.2) 1936 4.6. Accessing Protected Resources 1938 4.6.1. Threat: Eavesdropping access tokens on transport 1940 An attacker could try to obtain a valid access token on transport 1941 between client and resource server. As access tokens are shared 1942 secrets between authorization and resource server, they MUST by 1943 treated with the same care as other credentials (e.g. end-user 1944 passwords). 1946 Countermeasures: 1948 o Access tokens sent as bearer tokens, SHOULD NOT be sent in the 1949 clear over an insecure channel. Instead transport protection 1950 means shall be utilized to prevent eavesdropping by an attacker 1951 (see Section 5.1.1). 1953 o A short lifetime reduces impact in case tokens are compromised 1954 (see Section 5.1.5.3). 1956 o The access token can be bound to a client's identity and require 1957 the client to authenticate with the resource server (see 1958 Section 5.4.2). Client authentication MUST be performed without 1959 exposing the required secret to the transport channel. 1961 4.6.2. Threat: Replay authorized resource server requests 1963 An attacker could attempt to replay valid requests in order to obtain 1964 or to modify/destroy user data. 1966 Countermeasures: 1968 o The resource server should utilize transport security measure in 1969 order to prevent such attacks (see Section 5.1.1). This would 1970 prevent the attacker from capturing valid requests. 1972 o Alternatively, the resource server could employ signed requests 1973 (see Section 5.4.3) along with nounces and timestamps in order to 1974 uniquely identify requests. The resource server MUST detect and 1975 refuse every replayed request. 1977 4.6.3. Threat: Guessing access tokens 1979 Where the token is a handle, the attacker may use attempt to guess 1980 the access token values based on knowledge they have from other 1981 access tokens. 1983 Impact: Access to a single user's data. 1985 Countermeasures: 1987 o Handle Tokens should have a reasonable entropy (see 1988 Section 5.1.5.11) in order to make guessing a valid token value 1989 difficult. 1991 o Assertion (or self-contained token ) tokens contents SHALL be 1992 protected by a digital signature (see Section 5.1.5.9). 1994 o Security can be further strengthened by using a short access token 1995 duration (see Section 5.1.5.2 and Section 5.1.5.3). 1997 4.6.4. Threat: Access token phishing by counterfeit resource server 1999 An attacker may pretend to be a particular resource server and to 2000 accept tokens from a particular authorization server. If the client 2001 sends a valid access tokens to this counterfeit resource server, the 2002 server in turn may use that token to access other services on behalf 2003 of the resource owner. 2005 Countermeasures: 2007 o Clients SHOULD not make authenticated requests with an access 2008 token to unfamiliar resource servers, regardless of the presence 2009 of a secure channel. If the resource server address is well-known 2010 to the client, it may authenticate the resource servers (see 2011 Section 5.1.2). 2013 o Associate the endpoint address of the resource server the client 2014 talked to with the access token (e.g. in an audience field) and 2015 validate association at legitimate resource server. The endpoint 2016 address validation policy may be strict (exact match) or more 2017 relaxed (e.g. same host). This would require to tell the 2018 authorization server the resource server endpoint address in the 2019 authorization process. 2021 o Associate an access token with a client and authenticate the 2022 client with resource server requests (typically via signature in 2023 order to not disclose secret to a potential attacker). This 2024 prevents the attack because the counterfeit server is assumed to 2025 miss the capabilities to correctly authenticate on behalf of the 2026 legitimate client to the resource server (Section 5.4.2). 2028 o Restrict the token scope (see Section 5.1.5.1) and or limit the 2029 token to a certain resource server (Section 5.1.5.5). 2031 4.6.5. Threat: Abuse of token by legitimate resource server or client 2033 A legitimate resource server could attempt to use an access token to 2034 access another resource servers. Similarily, a client could try to 2035 use a token obtained for one server on another resource server. 2037 Countermeasures: 2039 o Tokens should be restricted to particular resource servers (see 2040 Section 5.1.5.5). 2042 4.6.6. Threat: Leak of confidential data in HTTP-Proxies 2044 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is 2045 optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J., 2046 Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2047 Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and 2048 WWW-Authenticate headers to distinguish authenticated content so that 2049 it can be protected. Proxies and caches, in particular, may fail to 2050 adequately protect requests not using these headers. For example, 2051 private authenticated content may be stored in (and thus retrievable 2052 from) publicly-accessible caches. 2054 CounterMeasures: 2056 o Resource servers not using the HTTP Authorization scheme (OAuth 2057 HTTP Authorization Scheme - see Section 5.4.1) should take care to 2058 use other mechanisms, such as the Cache-Control header, to ensure 2059 that authenticated content is protected. 2061 o Reducing scope (see Section 5.1.5.1) and expiry time 2062 (Section 5.1.5.3) for access tokens can be used to reduce the 2063 damage in case of leaks. 2065 4.6.7. Threat: Token leakage via logfiles and HTTP referrers 2067 If access tokens are sent via URI query parameters, such tokens may 2068 leak to log files and HTTP referrers. 2070 Countermeasures: 2072 o Use authorization headers or POST parameters instead of URI 2073 request parameters (see Section 5.4.1). 2075 o Set logging configuration appropriately 2077 o Prevent unauthorized persons from access to system log files (see 2078 Section 5.1.4.1.1) 2080 o HTTP referrers can be prevented by reloading the target page again 2081 without URI parameters 2083 o Abuse of leaked access tokens can be prevented by enforcing 2084 authenticated requests (see Section 5.4.2). 2086 o The impact of token leakage may be reduced by limiting scope (see 2087 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing 2088 one time token usage (see Section 5.1.5.4). 2090 5. Security Considerations 2092 This section describes the countermeasures as recommended to mitigate 2093 the threats as described in Section 4. 2095 5.1. General 2097 5.1.1. Confidentiality of Requests 2099 This is applicable to all requests sent from client to authorization 2100 server or resource server. While OAuth provides a mechanism for 2101 verifying the integrity of requests, it provides no guarantee of 2102 request confidentiality. Unless further precautions are taken, 2103 eavesdroppers will have full access to request content and may be 2104 able to mount attacks through using content of request, e.g. secrets 2105 or tokens, or mount replay attacks. 2107 Attacks can be mitigated by using transport-layer mechanisms such as 2108 TLS or SSL. VPN may considered as well. 2110 This is a countermeasure against the following threats: 2112 o Replay of access tokens obtained on tokens endpoint or resource 2113 server's endpoint 2115 o Replay of refresh tokens obtained on tokens endpoint 2117 o Replay of authorization codes obtained on tokens endpoint 2118 (redirect?) 2120 o Replay of user passwords and client secrets 2122 5.1.2. Server authentication 2124 HTTPS server authentication or similar means can be used to 2125 authenticate the identity of a server. The goal is to reliably bind 2126 the DNS name of the server to the public key presented by the server 2127 during connection establishment. 2129 The client MUST validate the binding of the server to its domain 2130 name. If the server fails to prove that binding, it is condered a 2131 men-in-the-middle. The security measure depends on the certification 2132 authorities the client trusts for that purpose. Clients should 2133 carefully select those trusted CAs and protect the storage for 2134 trusted CA certificates from modifications. 2136 This is a countermeasure against the following threats: 2138 o Spoofing 2140 o Proxying 2142 o Phishing by conterfeit servers 2144 5.1.3. Always keep the resource owner informed 2146 Transparency to the resource owner is a key element of the OAuth 2147 protocol. The user shall always be in control of the authorization 2148 processes and get the necessary information to meet informed 2149 decisions. Moreover, user involvement is a further security 2150 countermeasure. The user can probably recognize certain kinds of 2151 attacks better than the authorization server. Information can be 2152 presented/exchanged during the authorization process, after the 2153 authorization process, and every time the user wishes to get informed 2154 by using techniques such as: 2156 o User consent forms 2158 o Notification messages (e-Mail, SMS, ...) 2160 o Activity/Event logs 2162 o User self-care apps or portals 2164 5.1.4. Credentials 2166 This sections describes countermeasures used to protect all kind of 2167 credentials from unauthorized access and abuse. Credentials are long 2168 term secrets, such as client secrets and user passwords as well as 2169 all kinds of tokens (refresh and access token) or authorization 2170 codes. 2172 5.1.4.1. Credential storage protection 2174 5.1.4.1.1. Standard system security means 2176 A server system may be locked down so that no attacker may get access 2177 to sensible configuration files and databases. 2179 5.1.4.1.2. Standard SQL inj. Countermeasures 2181 If a client identifier or other authentication component is queried 2182 or compared against a SQL Database it may become possible for an 2183 injection attack to occur if parameters received are not validated 2184 before submission to the database. 2186 o Ensure that server code is using the minimum database privileges 2187 possible to reduce the "surface" of possible attacks. 2189 o Avoid dynamic SQL using concatenated input. If possible, use 2190 static SQL. 2192 o When using dynamic SQL, parameterize queries using bind arguments. 2193 Bind arguments eliminate possibility of SQL injections. 2195 o Filter and sanitize the input. For example, if an identifier has 2196 a known format, ensure that the supplied value matches the 2197 identifier syntax rules. 2199 5.1.4.1.3. No cleartext storage of credentials 2201 The authorization server may consider to not store credential in 2202 clear text. Typical approaches are to store hashes instead. If the 2203 credential lacks a reasonable entropy level (because it is a user 2204 password) an additional salt will harden the storage to prevent 2205 offline dictionary attacks. Note: Some authentication protocols 2206 require the authorization server to have access to the secret in the 2207 clear. Those protocols cannot be implemented if the server only has 2208 access to hashes. 2210 5.1.4.1.4. Encryption of credentials 2212 For client applicatinos, insecurely persisted client credentials are 2213 easy targets for attackers to obtain. Store client credentials using 2214 an encrypted persistence mechanism such as a keystore or database. 2215 Note that compiling client credentials directly into client code 2216 makes client applications vulnerable to scanning as well as difficult 2217 to administer should client credentials change over time. 2219 5.1.4.1.5. Use of asymmetric cryptography 2221 Usage of asymmetric cryptography will free the authorization server 2222 of the obligation to manage credentials. Nevertheless, it MUST 2223 ensure the integrity of the respective public keys. 2225 5.1.4.2. Online attacks on secrets 2227 5.1.4.2.1. Password policy 2229 The authorization server may decide to enforce a complex user 2230 password policy in order to increase the user passwords' entropy. 2231 This will hinder online password attacks. 2233 5.1.4.2.2. High entropy of secrets 2235 When creating token handles or other secrets not intended for usage 2236 by human users, the authorization server MUST include a reasonable 2237 level of entropy in order to mitigate the risk of guessing attacks. 2239 The token value MUST be constructed from a cryptographically strong 2240 random or pseudo-random number sequence [RFC1750] generated by the 2241 Authorization Server. The probability of any two Authorization Code 2242 values being identical MUST be less than or equal to 2^(-128) and 2243 SHOULD be less than or equal to 2^(-160). 2245 5.1.4.2.3. Lock accounts 2247 Online attacks on passwords can be mitigated by locking the 2248 respective accounts after a certain number of failed attempts. 2250 Note: This measure can be abused to lock down legitimate service 2251 users. 2253 5.1.4.2.4. Tar pit 2255 The authorization server may react on failed attempts to authenticate 2256 by username/password by temporarily locking the respective account 2257 and delaying the response for a certain duration. This duration may 2258 increase with the number of failed attempts. The objective is to 2259 slow the attackes attempts on a certain username down. 2261 Note: this may require a more complex and stateful design of the 2262 authorization server. 2264 5.1.4.2.5. Usage of CAPTCHAs 2266 The idea is to prevent programms from automatically checkinga huge 2267 number of passwords by requiring human interaction. 2269 Note: this has a negative impact on user experience. 2271 5.1.5. Tokens (access, refresh, code) 2273 5.1.5.1. Limit token scope 2275 The authorization server may decide to reduce or limit the scope 2276 associated with a token. Basis of this decision is out of scope, 2277 examples are: 2279 o a client-specific policy, e.g. issue only less powerful tokens to 2280 unauthenticated clients, 2282 o a service-specific policy, e.g. it a very sensible service, 2284 o a resource-owner specific setting, or 2286 o combinations of such policies and preferences. 2288 The authorization server may allow different scopes dependent on the 2289 grant type. For example, end-user authorization via direct 2290 interaction with the end-user (authorization code) might be 2291 considered more reliable than direct authorization via gran type 2292 username/password. This means will reduce the impact of the 2293 following threats: 2295 o token leakage 2297 o token issuance to malicious software 2299 o unintended issuance of to powerful tokens with resource owner 2300 credentials flow 2302 5.1.5.2. Expiration time 2304 Tokens should generally expire after a reasonable duration. This 2305 complements and strengthens other security measures (such as 2306 signatures) and reduces the impact of all kinds of token leaks. 2308 5.1.5.3. Short expiration time 2310 A short expiration time for tokens is a protection means against the 2311 following threats: 2313 o replay 2315 o reduce impact of token leak 2317 o reduce likelyhood of sucessful online guessing 2319 Note: Short token duration requires preciser clock synchronisation 2320 between authorization server and resource server. Furthermore, 2321 shorter duration may require more token refreshments (access token) 2322 or repeated end-user authorization processes (authorization code and 2323 refresh token). 2325 5.1.5.4. Limit number of usages/ One time usage 2327 The authorization server may restrict the number of request, which 2328 can be performed with a certain token. This mechanism can be used to 2329 mitigate the following threats: 2331 o replay of tokens 2333 o reduce likelyhood of sucessful online guessing 2335 Additionally, If an Authorization Server observes multiple attempts 2336 to redeem a authorization code, the Authorization Server may want to 2337 revoke all tokens granted based on the authorization code. 2339 5.1.5.5. Bind tokens to a particular resource server (Audience) 2341 Authorization servers in multi-service environments may consider to 2342 issue tokens with different content to different resource servers and 2343 to explicitely indicate in the token the target server a token is 2344 intended to be sent to (see Audience in SAML Assertions). This 2345 countermeasure can be used in the following situations: 2347 o It reduce the impact of a successful replay attempt, since the 2348 token is applicable to a single resource server, only. 2350 o It prevents abuse of a token by a rough resource server or client, 2351 since the token can only be used on that server. It is rejected 2352 by other servers. 2354 o It reduce the impact of a leakage of a valid token to a conterfeit 2355 resource server. 2357 5.1.5.6. Use endpoint address as token audience 2359 This may be used to indicate to a resource server, which endpoint 2360 address has been used to obtain the token. This measure will allow 2361 to detect requests from a counterfeit resource server, since such 2362 token will contain the endpoint address of that server. 2364 5.1.5.7. Audience and Token scopes 2366 Deployments may consider to use only tokens with explicitely defined 2367 scope, where every scope is associated with a particular resource 2368 server. This approach can be used to mitigate attacks, where a 2369 resource server or client uses a token for a different then the 2370 intended purpose. 2372 5.1.5.8. Bind token to client id 2374 An authorization server may bind a token to a certain client 2375 identity. This identity match must be validated for every request 2376 with that token. This means can be used, to 2378 o detect token leakage and 2380 o prevent token abuse. 2382 Note: Validating the client identity may require the target server to 2383 authenticate the client's identity. This authentication can be based 2384 on secrets managed independent of the token (e.g. pre-registered 2385 client id/secret on authorization server) or sent with the token 2386 itself (e.g. as part of the encrypted token content). 2388 5.1.5.9. Signed tokens 2390 Self-contained tokens shall be signed in order to detect any attempt 2391 to modify or produce faked tokens. 2393 5.1.5.10. Encryption of token content 2395 Self-contained may be encrypted for privacy reasons or to protect 2396 system internal data. 2398 5.1.5.11. Random token value with high entropy 2400 When creating token handles, the authorization server MUST include a 2401 reasonable level of entropy in order to mitigate the risk of guessing 2402 attacks. The token value MUST be constructed from a 2403 cryptographically strong random or pseudo-random number sequence 2404 [RFC1750] generated by the Authorization Server. The probability of 2405 any two token values being identical MUST be less than or equal to 2406 2^(-128) and SHOULD be less than or equal to 2^(-160). 2408 5.1.5.12. Assertion formats 2410 For service providers intending to implement an assertion-based token 2411 design it is highly recommended to adopt a standard assertion format 2412 (such as SAML or JWT). 2414 5.1.6. Access tokens 2416 o keep them in transient memory (accessible by the client app only) 2418 o exposure to 3rd parties (malicious app) 2419 o limit number of access tokens granted to a user 2421 5.2. Authorization Server 2423 5.2.1. Authorization Codes 2425 5.2.1.1. Automatic revocation of derived tokens if abuse is detected 2427 If an Authorization Server observes multiple attempts to redeem a 2428 authorization code, the Authorization Server may want to revoke all 2429 tokens granted based on the authorization code. 2431 5.2.2. Refresh tokens 2433 5.2.2.1. Restricted issuance of refresh tokens 2435 The authorization server may decide based on an appropriate policy 2436 not to issue refresh tokens. Since refresh tokens areo long term 2437 credentials, they may be subject theft. For example, if the 2438 authorization server does not trust a client to securely store such 2439 tokens, it may refuse to issue such a client a refresh token. 2441 5.2.2.2. Binding of refresh token to client_id 2443 The authorization server MUST bind every refresh token to the id of 2444 the client such a token was originally issued to and validate this 2445 binding for every request to refresh that token. This measure is a 2446 countermeasure against refresh token theft or leakage. 2448 Note: This binding MUST be protected from unauthorized modifications. 2450 5.2.2.3. Refresh Token Replacement 2452 Refresh token replacement is intended to automatically detect and 2453 prevent attempts to use the same refresh token in parallel from 2454 different apps/devices. This happens if a token gets stolen from the 2455 client and is subsequently used by the attacker and the legitimate 2456 client. The basic idea is to change the refresh token value with 2457 every refresh request in order to detect attempts to obtain access 2458 tokens using old refresh tokens. Since the authorization server 2459 cannot determine whether the attacker or the legitimate client is 2460 trying to access, in case of such an access attempt the valid refresh 2461 token and the access authorization associated with it are both 2462 revoked. 2464 The OAuth specification supports this measure in that the tokens 2465 response allows the authorization server to return a new refresh 2466 token even for requests with grant type "refresh_token". 2468 Note: this measure may cause problems in clustered environments since 2469 usage of the currently valid refresh token must be ensured. In such 2470 an environment, other measures might be more appropriate. 2472 5.2.2.4. Refresh Token Revocation 2474 The authorization server may allow clients or end-users to 2475 explicitely request the invalidation of refresh tokens. 2477 This is a countermeasure againts: 2479 o device theft 2481 o ... 2483 5.2.2.5. Combine refresh token requests with user-provided secret 2485 The exchange of a refresh token can be bound to the presence of a 2486 certain user-provided secret, such as a PIN, a password or a SIM 2487 card. This is a kind of multi-factor authentication on the tokens 2488 endpoint, since an attacker must possess both factors in order to be 2489 able to obtain an access token. 2491 5.2.2.6. Device identification 2493 The authorization server may require to bind authentication 2494 credentials to a device identifier or token assigned to that device. 2495 As the IMEI can be spoofed, that is not suitable, For mobile phones, 2496 a registration process can be used to assign a unique token to the 2497 device using an sms message. That token or identifer can then be 2498 validated with when authenticating user credentials. 2500 This is a countermeasure against the following threats: 2502 o phishing attacks 2504 o ... 2506 5.2.2.7. X-FRAME-OPTION header 2508 For newer browsers, avoidance of iFrames can be enforced server side 2509 by using the X-FRAME-OPTION header. This header can have two values, 2510 deny and sameorigin, which will block any framing or framing by sites 2511 with a different origin, respectively. 2513 This is a countermeasure against the following threats: 2515 o clickjacking attacks 2517 o ... 2519 5.2.3. Client authentication and authorization 2521 As described in Section 3 (Security Features), clients are 2522 identified, authenticated and authorized for several purposes, such 2523 as a 2525 o Collate sub-sequent requests to the same client, 2527 o Indicate the trustworthiness of a particular client to the end- 2528 user, 2530 o Authorize access of clients to certain features on the 2531 authorization or resource server, and 2533 o Log a client identity to log files for analysis or statics. 2535 Due to the different capababilities and characterictics of the 2536 different client types, there are different ways to support achieve 2537 objectives, which will be described in this section. Generally 2538 spoken, authorization server providers should be aware of the 2539 security policy and deployment of a particular clients and adapt its 2540 treatment accordingly. For example, one approach could be to treat 2541 all clients as less trustworthy and unsecure. On the other extrem, a 2542 service provider could activate every client installation by hand of 2543 an administrator and that way gain confidence in the identity of the 2544 software package and the security of the environment the client is 2545 installed in. And there are several approaches in between. 2547 5.2.3.1. Don't issue secrets to clients with inappropriate security 2548 policy 2550 Authorization servers should not issue secrets to clients, if these 2551 cannot sufficiently protect it. This prevents the server from 2552 overestimating the value of a sucessful authentication of the client. 2554 For example, it is of limited benefit to create a single client id 2555 and secret which is shared by all installations of a native app. 2556 First of all, this secret must be somehow transmitted from the 2557 developer via the respective distribution channel, e.g. an app 2558 market, to all installations of the app on end-user devices. So the 2559 secret is typically burned into the source code of the app or a 2560 associated resource bundle, which cannot be entirely protected from 2561 reverse engineering. Second, effectively such secrets cannot be 2562 revoked since this would immediatly put all installations out of 2563 work. Moreover, since the authorization server cannot really trust 2564 on the client's identity, it would be dangerous to indicate to end- 2565 users the trustworthiness of the client. 2567 There are other ways to achieve a reasonable security level, as 2568 described in the following sections. 2570 5.2.3.2. Clients without secret require user consent 2572 The authorization may issue a client id, but only accept 2573 authorization request, which are approved by the end-user. This 2574 measure precludes automatic authorization processes. This is a 2575 countermeasure for clients without secret against the following 2576 threats: 2578 o ... [[Not sure what is meant here]] 2580 o ... 2582 5.2.3.3. Client_id only in combination with redirect_uri 2584 The authorization may issue a client id, but bind this client_id to a 2585 certain pre-configured redirect_uri. So any authorization request 2586 with another redirect_uri is refused automatically. Alternatively, 2587 the authorization server may not accept any dynamic redirect_uri for 2588 such a client_id and instead always redirect to the well-known pre- 2589 configured redirect_uri. This is a countermeasure for clients 2590 without secrets against the following threats: 2592 o ...[[Not sure what is meant here]] 2594 o ... 2596 5.2.3.4. Deployment-specific client secrets 2598 A authorization server may issue separate client ids and 2599 corresponding secrets to the different deployments of a client. 2601 For web applications, this could mean to create one client_id and 2602 client_secret per web site a software package is installed on. So 2603 the provider of that particular site could request client id and 2604 secret from the authorization server during setup of the web site. 2605 This would also allow to validate some of the properties of that web 2606 site, such as redirect_uri, address, and whatever proofs useful. The 2607 web site provider has to ensure the security of the client secret on 2608 the site. 2610 For native applications, things are more complicated because every 2611 installation of the app on any device is another deployment. 2612 Deployment specific secrets will require 2614 1. Either to obtain a client_id and client_secret during download 2615 process from the app market, or 2617 2. During installation on the device. 2619 Either approach will require an automated mechanism for issuing 2620 client ids and secrets, which is currently not defined by OAuth. 2622 The first approach would allow to achieve a level where the client is 2623 authenticated and identified, whereas the second option only allows 2624 to authenticate the client but not to validate properties of the 2625 client. But this would at least help to prevent several replay 2626 attacks. Moreover, deployment-specific client_id and secret allow to 2627 selectively revoke all refresh tokens of a specific deployment at 2628 once. 2630 This is a countermeasure against the following threats: 2632 o ... 2634 o ... 2636 5.2.3.5. Validation of pre-registered redirect_uri 2638 An authorization server may require clients to register their 2639 redirect_uri or a pattern (TBD: make definition more precise) 2640 thereof. The way this registration is performed is out of scope of 2641 this document. Every actual redirect_uri sent with the respective 2642 client_id to the end-user authorization endpoint must comply with 2643 that pattern. Otherwise the authorization server must assume the 2644 inbound GET request has been sent by an attacker and refuse it. 2645 Note: the authorization server MUST NOT redirect the user agent back 2646 to the redirect_uri of such an authorization request. 2648 o Authorization code leakage through conterfeit web site: allows to 2649 detect attack attempts already after first redirect to end-user 2650 authorization endpoint (Section 4.4.1.7). 2652 o For clients with validated properties, this measure also helps to 2653 detect malicious apps early in the end-user authorization process. 2654 This reduces the need for a interactive validation by the user 2655 (Section 4.4.1.4, Section 4.4.2.3). 2657 The underlying assumption of this measure is that an attacker must 2658 use another redirect_uri in order to get access to the authorization 2659 code. Deployments might consider the possibility of an attacker 2660 using spoofing attacks to a victims device to circumvent this 2661 security measure. 2663 Note: Pre-registering clients might not scale in some deployments 2664 (manual process) or require dynamic client registration (not 2665 specified yet). With the lack of dynamic client registration, it 2666 only works for clients bound to certain deployments at development/ 2667 configuration time. As soon as dynamic resource server discovery 2668 gets involved, that's no longer feasable. 2670 5.2.3.6. Client secret revocation 2672 An authorization server may revoke a client's secret in order to 2673 prevent abuse of a revealed secret. 2675 Note: This measure will immediately invalidate any authorization code 2676 or refresh token issued to the respective client. This might be 2677 unintentionally for client identifiers and secrets used across 2678 multiple deployments of a particular native or web application. 2680 This a countermeasure against: 2682 o ... 2684 o ... 2686 5.2.3.7. Use strong client authentication (e.g. client_assertion / 2687 client_token) 2689 Assumption: prevents an attacker from obtaining a client secret 2690 because this secret is kept in some hardware security module? 2692 5.2.4. End-user authorization 2694 5.2.4.1. Automatic processing of repeated authorizations requires 2695 client validation 2697 Authorization servers should not automatically process repeat 2698 authorizations where the client is not authenticated through a client 2699 secret or some other authentication mechanism such as signing with 2700 security certs (5.7.2.7. Use strong client authentication (e.g. 2701 client_assertion / client_token)) or validation of a pre-registered 2702 redirect uri (5.7.2.5. Validation of pre-registered redirect_uri ). 2704 5.2.4.2. Informed decisions based on transparency 2706 The authorization server shall intelligible explain to the end-user 2707 what happens in the authorization process and what the consequences 2708 are. For example, the user shall understand what access he is about 2709 to grant to which client for what duration. It shall also be obvious 2710 to the user, whether the server is able to reliably certify certain 2711 client properties (web site address, security policy). 2713 5.2.4.3. Validation of client properties by end-user 2715 In the authorization process, the user is typically asked to approve 2716 a client's request for authorization. This is an important security 2717 mechanism by itself because the end-users can be involed in the 2718 validation of client properties, such as whether the client name 2719 known to the authorization server fits the name of the web site or 2720 the app the end-user is using. This measure is especially helpful in 2721 all situation where the authorization server is unable to 2722 authenticate the client. It is a countermeasure against: 2724 o Malicious app 2726 o ... 2728 5.2.4.4. Binding of authorization code to client_id 2730 The authorization server MUST bind every authorization code to the id 2731 of the respective client which initiated the end-user authorization 2732 process. This measure is a countermeasure against: 2734 o replay of authorization codes with different client credentials 2735 since an attacker cannot use another client_id to exchange an 2736 authorization code into a token 2738 o Online guessing of authorization codes 2740 Note: This binding MUST be protected from unauthorized modifications. 2742 5.2.4.5. Binding of authorization code to redirect_uri 2744 The authorization server MUST bind every authorization code to the 2745 actual redirect_uri used as redirect target of the client in the end- 2746 user authorization process. This binding MUST be validated when the 2747 client attempts to exchange the respective authorization code for an 2748 access token. This measure is a countermeasure against authorization 2749 code leakage through counterfeit web sites since an attacker cannot 2750 use another redirect_uri to exchange an authorization code into a 2751 token. 2753 5.3. Client App Security 2755 5.3.1. Don't store credentials in code or resources bundled with 2756 software packages 2758 [Anything more to say ? :-)] 2760 5.3.2. Standard web server protection measures (for config files and 2761 databases) 2763 5.3.3. Store secrets in a secure storage 2765 The are different way to store secrets of all kinds (tokens, client 2766 secrets) securely on a device or server. 2768 Most multi-user operation systems seggregate the personal storage of 2769 the different system users. Moreover, most modern smartphone 2770 operating systems even support to store app-specific data in separat 2771 areas of the file systems and protect it from access by other apps. 2772 Additionally, apps can implements confidential data itself using a 2773 user-supplied secret, such as PIN or password. 2775 Another option is to swap refresh token storage to a trusted backend 2776 server. This mean in turn requires a resilient authentication 2777 mechanisms between client and backend server. Note: Applications 2778 must ensure that confidential data are kept confidential even after 2779 readin from secure storage, which typically means to keep this data 2780 in the local memory of the app. 2782 5.3.4. Utilize device lock to prevent unauthorized device access 2784 5.3.5. Platform security measures 2786 o Validation process 2788 o software package signatures 2790 o Remote removal 2792 5.4. Resource Servers 2794 5.4.1. Authorization headers 2796 Authorization headers are recognized and specially treated by HTTP 2797 proxies and servers. Thus the usage of such headers for sending 2798 access tokens to resource servers reduces the likelihood of leakage 2799 or unintended storage of authenticated requests in general and 2800 especially Authorization headers. 2802 5.4.2. Authenticated requests 2804 An authorization server may bind tokens to a certain client identitiy 2805 and encourage resource servers to validate that binding. This will 2806 require the resource server to authenticate the originator of a 2807 request as the legitimate owner of a particular token. There are a 2808 couple of options to implement this countermeasure: 2810 o The authorization server may associate the distinguished name of 2811 the client with the token (either internally or in the payload of 2812 an self-contained token). The client then uses client 2813 certificate-based HTTP authentication on the resource server's 2814 endpoint to authenticate its identity and the resource server 2815 validates the name with the name referenced by the token. 2817 o same as before, but the client uses his private key to sign the 2818 request to the resource server (public key is either contained in 2819 the token or sent along with the request) 2821 o Alternatively, the authorization server may issue a token-bound 2822 secret, which the client uses to sign the request. The resource 2823 server obtains the secret either directly from the authorization 2824 server or it is contained in an encrypted section of the token. 2825 That way the resource server does not "know" the client but is 2826 able to validate whether the authorization server issued the token 2827 to that client 2829 This mechanisms is a countermeasure against abuse of tokens by 2830 counterfeit resource servers. 2832 5.4.3. Signed requests 2834 A resource server may decide to accept signed requests only, either 2835 to replace transport level security measures or to complement such 2836 measures. Every signed request must be uniquly identifiable and must 2837 not be processed twice by the resource server. This countermeasure 2838 helps to mitigate: 2840 o modifications of the message and 2842 o replay attempts 2844 6. IANA Considerations 2846 This document makes no request of IANA. 2848 Note to RFC Editor: this section may be removed on publication as an 2849 RFC. 2851 7. Acknowledgements 2853 We would like to thank Hui-Lan Lu, Francisco Corella, Eric Pflam, 2854 Shane B Weeden, Skylar Woodward and James H. Manger for their 2855 comments and contributions. 2857 8. References 2859 8.1. Normative References 2861 [I-D.ietf-oauth-v2] 2862 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2863 2.0 Authorization Protocol", draft-ietf-oauth-v2-16 (work 2864 in progress), May 2011. 2866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2867 Requirement Levels", BCP 14, RFC 2119, March 1997. 2869 8.2. Informative References 2871 [I-D.ietf-oauth-v2-bearer] 2872 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 2873 Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-06 2874 (work in progress), June 2011. 2876 [I-D.ietf-oauth-v2-http-mac] 2877 Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP 2878 Authentication: MAC Access Authentication", 2879 draft-ietf-oauth-v2-http-mac-00 (work in progress), 2880 May 2011. 2882 [I-D.lodderstedt-oauth-revocation] 2883 Lodderstedt, T. and S. Dronia, "Token Revocation", 2884 draft-lodderstedt-oauth-revocation-02 (work in progress), 2885 March 2011. 2887 [portable-contacts] 2888 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008. 2890 Appendix A. Document History 2892 [[ to be removed by RFC editor before publication as an RFC ]] 2893 o section 4.4.1.2 - changed "resource server" to "client" in 2894 countermeasures description. 2896 o section 4.4.1.6 - changed "client shall authenticate the server" 2897 to "The browser shall be utilized to authenticate the redirect_uri 2898 of the client" 2900 draft-ietf-oauth-v2-threatmodel-00 2902 o section 3.4 - added the purposes for using authorization codes. 2904 o extended section 4.4.1.1 2906 o merged 4.4.1.5 into 4.4.1.2 2908 o corrected some typos 2910 o reformulated "session fixation", renamed respective sections into 2911 "authorization code disclosure through counterfeit client" 2913 o added new section "User session impersonation" 2915 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, 2916 5.1.4.1.4, 5.2.3.5 2918 o added new threat "DoS using manufactured authorization codes" as 2919 proposed by Eric Pflam 2921 o added XSRF and clickjacking (incl. state parameter explanation) 2923 o changed sub-section order in section 4.4.1 2925 o incorporated feedback from Skylar Woodward (client secrets) and 2926 Shane B Weeden (refresh tokens as client instance secret) 2928 o aligned client section with core draft's client type definition 2930 o converted I-D into WG document 2932 Authors' Addresses 2934 Torsten Lodderstedt (editor) 2935 Deutsche Telekom AG 2937 Email: torsten@lodderstedt.net 2939 Mark McGloin 2940 IBM 2942 Email: mark.mcgloin@ie.ibm.com 2944 Phil Hunt 2945 Oracle Corporation 2947 Email: phil.hunt@yahoo.com