idnits 2.17.1 draft-ietf-oauth-v2-threatmodel-02.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 19, 2012) is 4449 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1750' is mentioned on line 2416, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'I-D.lodderstedt-oauth-revocation' is defined on line 2947, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-23 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-v2-bearer-17 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-01 == Outdated reference: A later version (-04) exists of draft-lodderstedt-oauth-revocation-03 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: Informational M. McGloin 5 Expires: August 22, 2012 IBM 6 P. Hunt 7 Oracle Corporation 8 February 19, 2012 10 OAuth 2.0 Threat Model and Security Considerations 11 draft-ietf-oauth-v2-threatmodel-02 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 August 22, 2012. 41 Copyright Notice 43 Copyright (c) 2012 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 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10 70 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11 71 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11 72 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12 73 3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12 74 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12 75 3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12 76 4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14 77 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15 79 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16 80 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18 81 4.1.4. Threat: End-user credentials phished using 82 compromised or embedded browser . . . . . . . . . . . 18 83 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19 84 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19 85 4.2.1. Threat: Password phishing by counterfeit 86 authorization server . . . . . . . . . . . . . . . . . 20 87 4.2.2. Threat: User unintentionally grants too much 88 access scope . . . . . . . . . . . . . . . . . . . . . 20 89 4.2.3. Threat: Malicious client obtains existing 90 authorization by fraud . . . . . . . . . . . . . . . . 21 91 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21 92 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21 93 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22 94 4.3.2. Threat: Obtain access tokens from authorization 95 server database . . . . . . . . . . . . . . . . . . . 22 97 4.3.3. Threat: Obtain client credentials over non secure 98 transport . . . . . . . . . . . . . . . . . . . . . . 22 99 4.3.4. Threat: Obtain client secret from authorization 100 server database . . . . . . . . . . . . . . . . . . . 23 101 4.3.5. Threat: Obtain client secret by online guessing . . . 23 102 4.3.6. Threat: DoS on dynamic client secret creation . . . . 23 103 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23 104 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24 105 4.4.1.1. Threat: Eavesdropping or leaking authorization 106 codes . . . . . . . . . . . . . . . . . . . . . . 24 107 4.4.1.2. Threat: Obtain authorization codes from 108 authorization server database . . . . . . . . . . 25 109 4.4.1.3. Threat: Online guessing of authorization codes . . 25 110 4.4.1.4. Threat: Malicious client obtains authorization . . 26 111 4.4.1.5. Threat: Authorization code phishing . . . . . . . 27 112 4.4.1.6. Threat: User session impersonation . . . . . . . . 28 113 4.4.1.7. Threat: Authorization code leakage through 114 counterfeit client . . . . . . . . . . . . . . . . 28 115 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30 116 4.4.1.9. Threat: Clickjacking attack against 117 authorization . . . . . . . . . . . . . . . . . . 31 118 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31 119 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 120 4.4.1.12. Threat: DoS using manufactured authorization 121 codes . . . . . . . . . . . . . . . . . . . . . . 33 122 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35 123 4.4.2.1. Threat: Access token leak in 124 transport/end-points . . . . . . . . . . . . . . . 35 125 4.4.2.2. Threat: Access token leak in browser history . . . 35 126 4.4.2.3. Threat: Malicious client obtains authorization . . 35 127 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36 128 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 129 4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 130 4.4.3.1. Threat: Accidental exposure of passwords at 131 client site . . . . . . . . . . . . . . . . . . . 38 132 4.4.3.2. Threat: Client obtains scopes without end-user 133 authorization . . . . . . . . . . . . . . . . . . 38 134 4.4.3.3. Threat: Client obtains refresh token through 135 automatic authorization . . . . . . . . . . . . . 38 136 4.4.3.4. Threat: Obtain user passwords on transport . . . . 39 137 4.4.3.5. Threat: Obtain user passwords from 138 authorization server database . . . . . . . . . . 39 139 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40 140 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 141 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 142 4.5.1. Threat: Eavesdropping refresh tokens from 143 authorization server . . . . . . . . . . . . . . . . . 40 144 4.5.2. Threat: Obtaining refresh token from authorization 145 server database . . . . . . . . . . . . . . . . . . . 41 146 4.5.3. Threat: Obtain refresh token by online guessing . . . 41 147 4.5.4. Threat: Obtain refresh token phishing by 148 counterfeit authorization server . . . . . . . . . . . 41 149 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42 150 4.6.1. Threat: Eavesdropping access tokens on transport . . . 42 151 4.6.2. Threat: Replay authorized resource server requests . . 42 152 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42 153 4.6.4. Threat: Access token phishing by counterfeit 154 resource server . . . . . . . . . . . . . . . . . . . 43 155 4.6.5. Threat: Abuse of token by legitimate resource 156 server or client . . . . . . . . . . . . . . . . . . . 44 157 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 158 4.6.7. Threat: Token leakage via logfiles and HTTP 159 referrers . . . . . . . . . . . . . . . . . . . . . . 44 160 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 161 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 162 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 163 5.1.2. Server authentication . . . . . . . . . . . . . . . . 46 164 5.1.3. Always keep the resource owner informed . . . . . . . 46 165 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46 166 5.1.4.1. Credential Storage Protection . . . . . . . . . . 47 167 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48 168 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49 169 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49 170 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49 171 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49 172 5.1.5.4. Limit number of usages/ One time usage . . . . . . 50 173 5.1.5.5. Bind tokens to a particular resource server 174 (Audience) . . . . . . . . . . . . . . . . . . . . 50 175 5.1.5.6. Use endpoint address as token audience . . . . . . 51 176 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 51 177 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51 178 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51 179 5.1.5.10. Encryption of token content . . . . . . . . . . . 51 180 5.1.5.11. Random token value with high entropy . . . . . . . 51 181 5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 52 182 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 52 183 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52 184 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52 185 5.2.1.1. Automatic revocation of derived tokens if 186 abuse is detected . . . . . . . . . . . . . . . . 52 187 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52 188 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52 189 5.2.2.2. Binding of refresh token to client_id . . . . . . 53 190 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 53 191 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53 192 5.2.2.5. Device identification . . . . . . . . . . . . . . 54 193 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 54 194 5.2.3. Client authentication and authorization . . . . . . . 54 195 5.2.3.1. Don't issue secrets to public clients or 196 clients with inappropriate security policy . . . . 55 197 5.2.3.2. Public clients without secret require user 198 consent . . . . . . . . . . . . . . . . . . . . . 55 199 5.2.3.3. Client_id only in combination with redirect_uri . 55 200 5.2.3.4. Deployment-specific client secrets . . . . . . . . 56 201 5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 202 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57 203 5.2.3.7. Use strong client authentication (e.g. 204 client_assertion / client_token) . . . . . . . . . 57 205 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 206 5.2.4.1. Automatic processing of repeated 207 authorizations requires client validation . . . . 58 208 5.2.4.2. Informed decisions based on transparency . . . . . 58 209 5.2.4.3. Validation of client properties by end-user . . . 58 210 5.2.4.4. Binding of authorization code to client_id . . . . 59 211 5.2.4.5. Binding of authorization code to redirect_uri . . 59 212 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 213 5.3.1. Don't store credentials in code or resources 214 bundled with software packages . . . . . . . . . . . . 59 215 5.3.2. Standard web server protection measures (for 216 config files and databases) . . . . . . . . . . . . . 60 217 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 218 5.3.4. Utilize device lock to prevent unauthorized device 219 access . . . . . . . . . . . . . . . . . . . . . . . . 60 220 5.3.5. Platform security measures . . . . . . . . . . . . . . 60 221 5.3.6. Link state parameter to user agent session . . . . . . 60 222 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 223 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 224 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61 225 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 226 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 62 227 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 62 228 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 62 229 8.1. Normative References . . . . . . . . . . . . . . . . . . . 62 230 8.2. Informative References . . . . . . . . . . . . . . . . . . 63 231 Appendix A. Document History . . . . . . . . . . . . . . . . . . 63 232 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 65 234 1. Introduction 236 This document gives security considerations based on a comprehensive 237 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It 238 contains the following content: 240 o Documents any assumptions and scope considered when creating the 241 threat model. 243 o Describes the security features in-built into the OAuth protocol 244 and how they are intended to thwart attacks. 246 o Gives a comprehensive threat model for OAuth and describes the 247 respective counter measures to thwart those threats. 249 Threats include any intentional attacks on OAuth tokens and resources 250 protected by OAuth tokens as well as security risks introduced if the 251 proper security measures are not put in place. Threats are 252 structured along the lines of the protocol structure to aid 253 development teams implement each part of the protocol securely. For 254 example all threats for granting access or all threats for a 255 particular grant type or all threats for protecting the resource 256 server. 258 2. Overview 260 2.1. Scope 262 The security considerations document only considers clients bound to 263 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such 264 deployments have the following characteristics: 266 o Resource server URLs are static and well-known at development 267 time, authorization server URLs can be static or discovered. 269 o Token scope values (e.g. applicable URLs and methods) are well- 270 known at development time. 272 o Client registration: Since registration of clients is out of scope 273 of the current core spec, this document assumes a broad variety of 274 options from static registration during development time to 275 dynamic registration at runtime. 277 The following are considered out of scope : 279 o Communication between authorization server and resource server 281 o Token formats 283 o Except for "Resource Owner Password Credentials" (see 284 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by 285 authorization servers to authenticate the user 287 o Mechanism by which a user obtained an assertion and any resulting 288 attacks mounted as a result of the assertion being false. 290 o Clients not bound to a specific deployment: An example could be a 291 mail client with support for contact list access via the portable 292 contacts API (see [portable-contacts]). Such clients cannot be 293 registered upfront with a particular deployment and should 294 dynamically discover the URLs relevant for the OAuth protocol. 296 2.2. Attack Assumptions 298 The following assumptions relate to an attacker and resources 299 available to an attacker: 301 o It is assumed the attacker has full access to the network between 302 the client and authorization servers and the client and the 303 resource server, respectively. The attacker may eavesdrop on any 304 communications between those parties. He is not assumed to have 305 access to communication between authorization and resource server. 307 o It is assumed an attacker has unlimited resources to mount an 308 attack. 310 o It is assumed that 2 of the 3 parties involved in the OAuth 311 protocol may collude to mount an attack against the 3rd party. 312 For example, the client and authorization server may be under 313 control of an attacker and collude to trick a user to gain access 314 to resources. 316 2.3. Architectural assumptions 318 This section documents the assumptions about the features, 319 limitations, and design options of the different entities of a OAuth 320 deployment along with the security-sensitive data-elements managed by 321 those entity. These assumptions are the foundation of the threat 322 analysis. 324 The OAuth protocol leaves deployments with a certain degree of 325 freedom how to implement and apply the standard. The core 326 specification defines the core concepts of an authorization server 327 and a resource server. Both servers can be implemented in the same 328 server entity, or they may also be different entities. The later is 329 typically the case for multi-service providers with a single 330 authentication and authorization system, and are more typical in 331 middleware architectures. 333 2.3.1. Authorization Servers 335 The following data elements are stored or accessible on the 336 authorization server: 338 o user names and passwords 340 o client ids and secrets 342 o client-specific refresh tokens 344 o client-specific access tokens (in case of handle-based design) 346 o HTTPS certificate/key 348 o per-authorization process (in case of handle-based design): 349 redirect_uri, client_id, authorization code 351 2.3.2. Resource Server 353 The following data elements are stored or accessible on the resource 354 server: 356 o user data (out of scope) 358 o HTTPS certificate/key 360 o authorization server credentials (handle-based design), or 362 o authorization server shared secret/public key (assertion-based 363 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 A full definition of different client types and profiles is given in 373 [I-D.ietf-oauth-v2], Section 2.1. 375 The following data elements are stored or accessible on the client: 377 o client id (and client secret or corresponding client credential) 379 o one or more refresh tokens (persistent) and access tokens 380 (transient) per end-user or other security-context or delegation 381 context 383 o trusted CA certificates (HTTPS) 385 o per-authorization process: redirect_uri, authorization code 387 3. Security Features 389 These are some of the security features which have been built into 390 the OAuth 2.0 protocol to mitigate attacks and security issues. 392 3.1. Tokens 394 OAuth makes extensive use many kinds of tokens (access tokens, 395 refresh tokens, authorization codes). The information content of a 396 token can be represented in two ways as follows: 398 Handle (or artifact) a reference to some internal data structure 399 within the authorization server; the internal data structure 400 contains the attributes of the token, such as user id, scope, etc. 401 Handles enable simple revocation and do not require cryptographic 402 mechanisms to protect token content from being modified. On the 403 other hand, handles require communication between issuing and 404 consuming entity (e.g. authorization and resource server) in order 405 to validate the token and obtain token-bound data. This 406 communication might have an negative impact on performance and 407 scalability if both entities reside on different systems. Handles 408 are therefore typically used if the issuing and consuming entity 409 are the same. A 'handle' token is often referred to as an 410 'opaque' token because the resource server does not need to be 411 able to interpret the token directly, it simply uses the token. 413 Assertions (aka self-contained token) a parseable token. An 414 assertion typically has a duration, an audience, and is digitally 415 signed containing information about the user and the client. 416 Examples of assertion formats are SAML assertions and Kerberos 417 tickets. Assertions can typically directly be validated and used 418 by a resource server without interactions with the authorization 419 server. This results in better performance and scalability in 420 deployment where issuing and consuming entity reside on different 421 systems. Implementing token revocation is more difficult with 422 assertions than with handles. 424 Tokens can be used in two ways to invoke requests on resource servers 425 as follows: 427 bearer token A 'bearer token' is a token that can be used by any 428 client who has received the token (e.g. 429 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to 430 use the token it is important that communication between end- 431 points be secured to ensure that only authorized end-points may 432 capture the token. The bearer token is convenient to client 433 applications as it does not require them to do anything to use 434 them (such as a proof of identity). Bearer tokens have similar 435 characteristics to web single-sign-on (SSO) cookies used in 436 browsers. 438 proof token A 'proof token' is a token that can only be used by a 439 specific client. Each use of the token, requires the client to 440 perform some action that proves that it is the authorized user of 441 the token. Examples of this are MAC tokens, which require the 442 client to digitally sign the resource request with a secret 443 corresponding to the particular token send with the request 444 (e.g.[I-D.ietf-oauth-v2-http-mac]). 446 3.1.1. Scope 448 A Scope represents the access authorization associated with a 449 particular token with respect to resource servers, resources and 450 methods on those resources. Scopes are the OAuth way to explicitly 451 manage the power associated with an access token. A scope can be 452 controlled by the authorization server and/or the end-user in order 453 to limit access to resources for OAuth clients these parties deem 454 less secure or trustworthy. Optionally, the client can request the 455 scope to apply to the token but only for lesser scope than would 456 otherwise be granted, e.g. to reduce the potential impact if this 457 token is sent over non secure channels. A scope is typically 458 complemented by a restriction on a token's lifetime. 460 3.1.2. Expires_In 462 Expires_In allows an authorization server (based on its policies or 463 on behalf of the end-user) to limit the lifetime of the access token. 464 This mechanisms can be used to issue short-living tokens to OAuth 465 clients the authorization server deems less secure or where sending 466 tokens over non secure channels. 468 3.2. Access Token 470 An access token is used by a client to access a resource. Access 471 tokens typically have short life-spans (minutes or hours) that cover 472 typical session lifetimes. An access token may be refreshed through 473 the use of a refresh token. The short lifespan of an access token in 474 combination with the usage of refresh tokens enables the possibility 475 of passive revocation of access authorization on the expiry of the 476 current access token. 478 3.3. Refresh Token 480 A refresh token represents a long-lasting authorization of a certain 481 client to access resources on behalf of a resource owner. Such 482 tokens are exchanged between client and authorization server, only. 483 Clients use this kind of token to obtain ("refresh") new access 484 tokens used for resource server invocations. 486 A refresh token, coupled with a short access token lifetime, can be 487 used to grant longer access to resources without involving end user 488 authorization. This offers an advantage where resource servers and 489 authorization servers are not the same entity, e.g. in a distributed 490 environment, as the refresh token is always exchanged at the 491 authorization server. The authorization server can revoke the 492 refresh token at any time causing the granted access to be revoked 493 once the current access token expires. Because of this, a short 494 access token lifetime is important if timely revocation is a high 495 priority. 497 The refresh token is also a secret bound to the client identifier and 498 client instance which originally requested the authorization and 499 representing the original resource owner grant. This is ensured by 500 the authorization process as follows: 502 1. The resource owner and user-agent safely deliver the 503 authorization code to the client instance in first place. 505 2. The client uses it immediately in secure transport-level 506 communications to the authorization server and then securely 507 stores the long-lived refresh token. 509 3. The client always uses the refresh token in secure transport- 510 level communications to the authorization server to get an access 511 token (and optionally rollover the refresh token). 513 So as long as the confidentiality of the particular token can be 514 ensured by the client, a refresh tokens can also be used as an 515 alternative mean to authenticate the client instance itself. 517 3.4. Authorization Code 519 An Authorization Code represents the intermediate result of a 520 successful end-user authorization process and is used by the client 521 to obtain access and refresh token. Authorization codes are sent to 522 the client's redirection URI instead of tokens for two purposes. 524 1. Instead of (longer-lasting) tokens, the short-lived authorization 525 code is exposed to potential attackers via URI query parameters 526 (HTTP referrer), browser cache, or log file entries. 528 2. It is much simpler to authenticate clients during the direct 529 request between client and authorization server than in the 530 context of the indirect authorization request. The later would 531 require digital signatures. 533 3.5. Redirection URI 535 A redirection URI helps to detect malicious clients and prevents 536 phishing attacks from clients attempting to trick the user into 537 believing the phisher is the client. The value of the actual 538 redirection URI used in the authorization request has to be presented 539 and is verified when an authorization code is exchanged for tokens. 540 This helps to prevent attacks, where the authorization code is 541 revealed through redirectors and counterfeit web application clients. 542 The authorization server should require public clients and 543 confidential clients using implicit grant type to pre-register their 544 redirect URIs and validate against the registered redirection URI in 545 the authorization request. 547 3.6. State parameter 549 The state parameter is used to link requests and callbacks to prevent 550 CSRF attacks where an attacker authorizes access to his own resources 551 and then tricks a users into following a redirect with the attacker's 552 token. This parameter should bind to the authenticated state in a 553 user agent and, as per the core OAuth spec, the user agent must be 554 capable of keeping it in a location accessible only by the client and 555 user agent, i.e. protected by same-origin policy 557 3.7. Client Identity 559 Authentication protocols have typically not taken into account the 560 identity of the software component acting on behalf of the end-user. 561 OAuth does this in order to increase the security level in delegated 562 authorization scenarios and because the client will be able to act 563 without the user being present. 565 OAuth uses the client identifier to collate associated request to the 566 same originator, such as 568 o a particular end-user authorization process and the corresponding 569 request on the token's endpoint to exchange the authorization code 570 for tokens or 572 o the initial authorization and issuance of a token by an end-user 573 to a particular client, and subsequent requests by this client to 574 obtain tokens without user consent (automatic processing of 575 repeated authorization) 577 The client identity may also be used by the authorization server to 578 display relevant registration information to a user when requesting 579 consent for scope requested by a particular client. The client 580 identity may be used to limit the number of request for a particular 581 client or to charge the client per request. Client Identity may 582 furthermore be useful to differentiate access by different clients, 583 e.g. in server log files. 585 OAuth defines two client types, confidential and public, based on 586 their ability to authenticate with the authorization server (i.e. 587 ability to maintain the confidentiality of their client credentials). 588 Confidential clients are capable of maintaining the confidentiality 589 of client credentials (i.e. a client secret associated with the 590 client identifier) or capable of secure client authentication using 591 other means, such as a client assertion (e.g. SAML) or key 592 cryptography. The latter is considered more secure. 594 The authorization server should determine whether the client is 595 capable of keeping its secret confidential or using secure 596 authentication. Alternatively, the end-user can verify the identity 597 of the client, e.g. by only installing trusted applications.The 598 redicrection URI can be used to prevent delivering credentials to a 599 counterfeit client after obtaining end-user authorization in some 600 cases, but can't be used to verify the client identity. 602 Clients can be categorized as follows based on the client type, 603 profile (e.g. native vs web application) and deployment model: 605 Deployment-independent client_id with pre-registered redirect_uri and 606 without client_secret Such an identity is used by multiple 607 installations of the same software package. The identity of such 608 a client can only be validated with the help of the end-user. 609 This is a viable option for native applications in order to 610 identify the client for the purpose of displaying meta information 611 about the client to the user and to differentiate clients in log 612 files. Revocation of such an identity will affect ALL deployments 613 of the respective software. 615 Deployment-independent client_id with pre-registered redirect_uri and 616 with client_secret This is an option for native applications only, 617 since web application would require different redirect URIs. This 618 category is not advisable because the client secret cannot be 619 protected appropriately (see Section 4.1.1). Due to its security 620 weaknesses, such client identities have the same trust level as 621 deployment-independent clients without secret. Revocation will 622 affect ALL deployments. 624 Deployment-specific client_id with pre-registered redirect_uri and 625 with client_secret The client registration process ensures the 626 validation of the client's properties, such as redirection URI, 627 website address, web site name, contacts. Such a client identity 628 can be utilized for all relevant use cases cited above. This 629 level can be achieved for web applications in combination with a 630 manual or user-bound registration process. Achieving this level 631 for native applications is much more difficult. Either the 632 installation of the application is conducted by an administrator, 633 who validates the client's authenticity, or the process from 634 validating the application to the installation of the application 635 on the device and the creation of the client credentials is 636 controlled end-to-end by a single entity (e.g. application market 637 provider). Revocation will affect a single deployment only. 639 Deployment-specific client_id with client_secret without validated 640 properties Such a client can be recognized by the authorization 641 server in transactions with subsequent requests (e.g. 642 authorization and token issuance, refresh token issuance and 643 access token refreshment). The authorization server cannot assure 644 any property of the client to end-users. Automatic processing of 645 re-authorizations could be allowed as well. Such client 646 credentials can be generated automatically without any validation 647 of client properties, which makes it another option especially for 648 native applications. Revocation will affect a single deployment 649 only. 651 4. Security Threat Model 653 This section gives a comprehensive threat model of OAuth 2.0. 654 Threats are grouped first by attacks directed against an OAuth 655 component, which are client, authorization server, and resource 656 server. Subsequently, they are grouped by flow, e.g. obtain token or 657 access protected resources. Every countermeasure description refers 658 to a detailed description in Section 5. 660 4.1. Clients 662 This section describes possible threats directed to OAuth clients. 664 4.1.1. Threat: Obtain Client Secrets 666 The attacker could try to get access to the secret of a particular 667 client in order to: 669 o replay its refresh tokens and authorization codes, or 671 o obtain tokens on behalf of the attacked client with the privileges 672 of that client. 674 The resulting impact would be: 676 o Client authentication of access to authorization server can be 677 bypassed 679 o Stolen refresh tokens or authorization codes can be replayed 681 Depending on the client category, the following attacks could be 682 utilized to obtain the client secret. 684 Attack: Obtain Secret From Source Code or Binary: 686 This applies for all client types. For open source projects, secrets 687 can be extracted directly from source code in their public 688 repositories. Secrets can be extracted from application binaries 689 just as easily when published source is not available to the 690 attacker. Even if an application takes significant measures to 691 obfuscate secrets in their application distribution one should 692 consider that the secret can still be reverse-engineered by anyone 693 with access to a complete functioning application bundle or binary. 695 Countermeasures: 697 o Don't issue secrets to public clients or clients with 698 inappropriate security policy - Section 5.2.3.1 700 o Public clients require user consent - Section 5.2.3.2 702 o Use deployment-specific client secrets - Section 5.2.3.4 704 o Client secret revocation - Section 5.2.3.6 705 Attack: Obtain a Deployment-Specific Secret: 707 An attacker may try to obtain the secret from a client installation, 708 either from a web site (web server) or a particular devices (native 709 application). 711 Countermeasures: 713 o Web server: apply standard web server protection measures (for 714 config files and databases) - Section 5.3.2 716 o Native applications: Store secrets in a secure local storage - 717 Section 5.3.3 719 o Client secret revocation - Section 5.2.3.6 721 4.1.2. Threat: Obtain Refresh Tokens 723 Depending on the client type, there are different ways refresh tokens 724 may be revealed to an attacker. The following sub-sections give a 725 more detailed description of the different attacks with respect to 726 different client types and further specialized countermeasures. 727 Before detailing those threats, here are some generally applicable 728 countermeasures: 730 o The authorization server should validate the client id associated 731 with the particular refresh token with every refresh request- 732 Section 5.2.2.2 734 o Limited scope tokens - Section 5.1.5.1 736 o Refresh token revocation - Section 5.2.2.4 738 o Client secret revocation - Section 5.2.3.6 740 o Refresh tokens can automatically be replaced in order to detect 741 unauthorized token usage by another party (Refresh Token Rotation) 742 - Section 5.2.2.3 744 Attack: Obtain Refresh Token from Web application: 746 An attacker may obtain the refresh tokens issued to a web application 747 by way of overcoming the web server's security controls. Impact: 748 Since a web application manages the user accounts of a certain site, 749 such an attack would result in an exposure of all refresh tokens on 750 that side to the attacker. 752 Countermeasures: 754 o Standard web server protection measures - Section 5.3.2 756 o Use strong client authentication (e.g. client_assertion / 757 client_token), so the attacker cannot obtain the client secret 758 required to exchange the tokens - Section 5.2.3.7 760 Attack: Obtain Refresh Token from Native clients: 762 On native clients, leakage of a refresh token typically affects a 763 single user, only. 765 Read from local file system: The attacker could try get file system 766 access on the device and read the refresh tokens. The attacker could 767 utilize a malicious application for that purpose. 769 Countermeasures: 771 o Store secrets in a secure storage - Section 5.3.3 773 o Utilize device lock to prevent unauthorized device access - 774 Section 5.3.4 776 Attack: Steal device: 778 The host device (e.g. mobile phone) may be stolen. In that case, the 779 attacker gets access to all applications under the identity of the 780 legitimate user. 782 Countermeasures: 784 o Utilize device lock to prevent unauthorized device access - 785 Section 5.3.4 787 o Where a user knows the device has been stolen, they can revoke the 788 affected tokens - Section 5.2.2.4 790 Attack: Clone Device: 792 All device data and applications are copied to another device. 793 Applications are used as-is on the target device. 795 Countermeasures: 797 o Utilize device lock to prevent unauthorized device access - 798 Section 5.3.4 800 o Combine refresh token request with device identification - 801 Section 5.2.2.5 803 o Refresh Token Rotation - Section 5.2.2.3 805 o Where a user knows the device has been cloned, they can use this 806 countermeasure - Refresh Token Revocation - Section 5.2.2.4 808 4.1.3. Threat: Obtain Access Tokens 810 Depending on the client type, there are different ways access tokens 811 may be revealed to an attacker. Access tokens could be stolen from 812 the device if the application stores them in a storage, which is 813 accessible to other applications. 815 Impact: Where the token is a bearer token and no additional mechanism 816 is used to identify the client, the attacker can access all resources 817 associated with the token and its scope. 819 Countermeasures: 821 o Keep access tokens in transient memory and limit grants: 822 Section 5.1.6 824 o Limited scope tokens - Section 5.1.5.1 826 o Keep access tokens in private memory or apply same protection 827 means as for refresh tokens - Section 5.2.2 829 o Keep access token lifetime short - Section 5.1.5.3 831 4.1.4. Threat: End-user credentials phished using compromised or 832 embedded browser 834 A malicious application could attempt to phish end-user passwords by 835 misusing an embedded browser in the end-user authorization process, 836 or by presenting its own user-interface instead of allowing trusted 837 system browser to render the authorization user interface. By doing 838 so, the usual visual trust mechanisms may be bypassed (e.g. TLS 839 confirmation, web site mechanisms). By using an embedded or internal 840 client application user interface, the client application has access 841 to additional information it should not have access to (e.g. uid/ 842 password). 844 Impact: If the client application or the communication is 845 compromised, the user would not be aware and all information in the 846 authorization exchange could be captured such as username and 847 password. 849 Countermeasures: 851 o The OAuth flow is designed so that client applications never need 852 to know user passwords. Client applications should avoid directly 853 asking users for the their credentials. In addition, end users 854 could be educated about phishing attacks and best practices, such 855 as only accessing trusted clients, as OAuth does not provide any 856 protection against malicious applications and the end user is 857 solely responsible for the trustworthiness of any native 858 application installed. 860 o Client applications could be validated prior to publication in an 861 application market for users to access. That validation is out of 862 scope for OAuth but could include validating that the client 863 application handles user authentication in an appropriate way. 865 o Client developers should not write client applications that 866 collect authentication information directly from users and should 867 instead delegate this task to a trusted system component, e.g. the 868 system-browser. 870 4.1.5. Threat: Open Redirectors on client 872 An open redirector is an endpoint using a parameter to automatically 873 redirect a user-agent to the location specified by the parameter 874 value without any validation. If the authorization server allows the 875 client to register only part of the redirection URI, an attacker can 876 use an open redirector operated by the client to construct a 877 redirection URI that will pass the authorization server validation 878 but will send the authorization code or access token to an endpoint 879 under the control of the attacker. 881 Impact: An attacker could gain access to authorization codes or 882 access tokens 884 Countermeasure 886 o require clients to register full redirection URI Section 5.2.3.5 888 4.2. Authorization Endpoint 889 4.2.1. Threat: Password phishing by counterfeit authorization server 891 OAuth makes no attempt to verify the authenticity of the 892 Authorization Server. A hostile party could take advantage of this 893 by intercepting the Client's requests and returning misleading or 894 otherwise incorrect responses. This could be achieved using DNS or 895 ARP spoofing. Wide deployment of OAuth and similar protocols may 896 cause Users to become inured to the practice of being redirected to 897 websites where they are asked to enter their passwords. If Users are 898 not careful to verify the authenticity of these websites before 899 entering their credentials, it will be possible for attackers to 900 exploit this practice to steal Users' passwords. 902 Countermeasures: 904 o Authorization servers should consider such attacks when developing 905 services based on OAuth, and should require transport-layer 906 security for any requests where the authenticity of the 907 authorization server or of request responses is an issue (see 908 Section 5.1.2). 910 o Authorization servers should attempt to educate Users about the 911 risks phishing attacks pose, and should provide mechanisms that 912 make it easy for users to confirm the authenticity of their sites. 914 4.2.2. Threat: User unintentionally grants too much access scope 916 When obtaining end user authorization, the end-user may not 917 understand the scope of the access being granted and to whom or they 918 may end up providing a client with access to resources which should 919 not be permitted. 921 Countermeasures: 923 o Explain the scope (resources and the permissions) the user is 924 about to grant in a understandable way - Section 5.2.4.2 926 o Narrow scope based on client - When obtaining end user 927 authorization and where the client requests scope, the 928 authorization server may want to consider whether to honour that 929 scope based on who the client is. That decision is between the 930 client and authorization server and is outside the scope of this 931 spec. The authorization server may also want to consider what 932 scope to grant based on the client type, e.g. providing lower 933 scope to public clients. - Section 5.1.5.1 935 4.2.3. Threat: Malicious client obtains existing authorization by fraud 937 Authorization servers may wish to automatically process authorization 938 requests from clients which have been previously authorized by the 939 user. When the user is redirected to the authorization server's end- 940 user authorization endpoint to grant access, the authorization server 941 detects that the user has already granted access to that particular 942 client. Instead of prompting the user for approval, the 943 authorization server automatically redirects the user back to the 944 client. 946 A malicious client may exploit that feature and try to obtain such an 947 authorization code instead of the legitimate client. 949 Countermeasures: 951 o Authorization servers should not automatically process repeat 952 authorizations to public clients or unless the client is validated 953 using a pre-registered redirect URI (Section 5.2.3.5 ) 955 o Authorization servers can mitigate the risks associated with 956 automatic processing by limiting the scope of Access Tokens 957 obtained through automated approvals - Section 5.1.5.1 959 4.2.4. Threat: Open redirector 961 An attacker could use the end-user authorization endpoint and the 962 redirection URI parameter to abuse the authorization server as an 963 open redirector. An open redirector is an endpoint using a parameter 964 to automatically redirect a user-agent to the location specified by 965 the parameter value without any validation. 967 Impact: An attacker could utilize a user's trust in your 968 authorization server to launch a phishing attack. 970 Countermeasure 972 o require clients to register full redirection URI Section 5.2.3.5 974 o don't redirect to redirection URI, if client identity or 975 redirection URI can't be verified Section 5.2.3.5 977 4.3. Token endpoint 978 4.3.1. Threat: Eavesdropping access tokens 980 Attackers may attempts to eavesdrop access token on transit from the 981 authorization server to the client. 983 Impact: The attacker is able to access all resources with the 984 permissions covered by the scope of the particular access token. 986 Countermeasures: 988 o As per the core OAuth spec, the authorization servers must ensure 989 that these transmissions are protected using transport-layer 990 mechanisms such as TLS or SSL (see Section 5.1.1). 992 o If end-to-end confidentiality cannot be guaranteed, reducing scope 993 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 994 tokens can be used to reduce the damage in case of leaks. 996 4.3.2. Threat: Obtain access tokens from authorization server database 998 This threat is applicable if the authorization server stores access 999 tokens as handles in a database. An attacker may obtain access 1000 tokens from the authorization server's database by gaining access to 1001 the database or launching a SQL injection attack. Impact: disclosure 1002 of all access tokens 1004 Countermeasures: 1006 o System security measures - Section 5.1.4.1.1 1008 o Store access token hashes only - Section 5.1.4.1.3 1010 o Standard SQL injection Countermeasures - Section 5.1.4.1.2 1012 4.3.3. Threat: Obtain client credentials over non secure transport 1014 An attacker could attempt to eavesdrop the transmission of client 1015 credentials between client and server during the client 1016 authentication process or during OAuth token requests. Impact: 1017 Revelation of a client credential enabling the possibility for 1018 phishing or imitation of a client service. 1020 Countermeasures: 1022 o Implement transport security through - Section 5.1.1 1024 o Alternative authentication means, which do not require to send 1025 plaintext credentials over the wire (Examples: Digest 1026 authentication) 1028 4.3.4. Threat: Obtain client secret from authorization server database 1030 An attacker may obtain valid client_id/secret combinations from the 1031 authorization server's database by gaining access to the database or 1032 launching a SQL injection attack. Impact: disclosure of all 1033 client_id/secret combinations. This allows the attacker to act on 1034 behalf of legitimate clients. 1036 Countermeasures: 1038 o Ensure proper handling of credentials as per Credential Storage 1039 Protection. 1041 4.3.5. Threat: Obtain client secret by online guessing 1043 An attacker may try to guess valid client_id/secret pairs. Impact: 1044 disclosure of single client_id/secret pair. 1046 Countermeasures: 1048 o High entropy of secrets - Section 5.1.4.2.2 1050 o Lock accounts - Section 5.1.4.2.3 1052 o Use Strong Client Authentication - Section 5.2.3.7 1054 4.3.6. Threat: DoS on dynamic client secret creation 1056 If an authorization servers includes a nontrivial amount of entropy 1057 in client secrets and if the authorization server automatically 1058 grants them, an attacker could exhaust the pool by repeatedly 1059 applying for them. 1061 Countermeasures: 1063 o The authorization server should consider some verification step 1064 for new clients. The authorization server should include a 1065 nontrivial amount of entropy in client secrets. 1067 4.4. Obtaining Authorization 1069 This section covers threats which are specific to certain flows 1070 utilized to obtain access tokens. Each flow is characterized by 1071 response types and/or grant types on the end-user authorization and 1072 tokens endpoint, respectively. 1074 4.4.1. Authorization Code 1076 4.4.1.1. Threat: Eavesdropping or leaking authorization codes 1078 An attacker could try to eavesdrop transmission of the authorization 1079 code between authorization server and client. Furthermore, 1080 authorization codes are passed via the browser which may 1081 unintentionally leak those codes to untrusted web sites and attackers 1082 by different ways: 1084 o Referrer headers: browsers frequently pass a "referrer" header 1085 when a web page embeds content, or when a user travels from one 1086 web page to another web page. These referrer headers may be sent 1087 even when the origin site does not trust the destination site. 1088 The referrer header is commonly logged for traffic analysis 1089 purposes. 1091 o Request logs: web server request logs commonly include query 1092 parameters on requests. 1094 o Open redirectors: web sites sometimes need to send users to 1095 another destination via a redirector. Open redirectors pose a 1096 particular risk to web-based delegation protocols because the 1097 redirector can leak verification codes to untrusted destination 1098 sites. 1100 o Browser history: web browsers commonly record visited URLs in the 1101 browser history. Another user of the same web browser may be able 1102 to view URLs that were visited by previous users. 1104 Note: A description of a similar attacks on the SAML protocol can be 1105 found at http://www.oasis-open.org/committees/download.php/3405/ 1106 oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http:// 1107 www.thomasgross.net/publications/papers/ 1108 GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http:// 1109 www.oasis-open.org/committees/download.php/11191/ 1110 sstc-gross-sec-analysis-response-01.pdf. 1112 Countermeasures: 1114 o As per the core OAuth spec, the authorization server as well as 1115 the client must ensure that these transmissions are protected 1116 using transport-layer mechanisms such as TLS or SSL (see 1117 Section 5.1.1). 1119 o The authorization server will require the client to authenticate 1120 wherever possible, so the binding of the authorization code to a 1121 certain client can be validated in a reliable way (see 1122 Section 5.2.4.4). 1124 o Limited duration of authorization codes - Section 5.1.5.3 1126 o The authorization server should enforce a one time usage 1127 restriction (see Section 5.1.5.4). 1129 o If an Authorization Server observes multiple attempts to redeem a 1130 authorization code, the Authorization Server may want to revoke 1131 all tokens granted based on the authorization code (see 1132 Section 5.2.1.1). 1134 o In the absence of these countermeasures, reducing scope 1135 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1136 tokens can be used to reduce the damage in case of leaks. 1138 o The client server may reload the target page of the redirection 1139 URI in order to automatically cleanup the browser cache. 1141 4.4.1.2. Threat: Obtain authorization codes from authorization server 1142 database 1144 This threat is applicable if the authorization server stores 1145 authorization codes as handles in a database. An attacker may obtain 1146 authorization codes from the authorization server's database by 1147 gaining access to the database or launching a SQL injection attack. 1148 Impact: disclosure of all authorization codes, most likely along with 1149 the respective redirect_uri and client_id values. 1151 Countermeasures: 1153 o Best practices for credential storage protection should be 1154 employed - Section 5.1.4.1 1156 o System security measures - Section 5.1.4.1.1 1158 o Store access token hashes only - Section 5.1.4.1.3 1160 o Standard SQL injection countermeasures - Section 5.1.4.1.2 1162 4.4.1.3. Threat: Online guessing of authorization codes 1164 An attacker may try to guess valid authorization code values and send 1165 it using the grant type "code" in order to obtain a valid access 1166 token. 1168 Impact: disclosure of single access token, probably also associated 1169 refresh token. 1171 Countermeasures: 1173 o Handle-based tokens must use high entropy: Section 5.1.5.11 1175 o Assertion-based tokens should be signed: Section 5.1.5.9 1177 o Authenticate the client, adds another value the attacker has to 1178 guess - Section 5.2.3.4 1180 o Binding of authorization code to redirection URI, adds another 1181 value the attacker has to guess - Section 5.2.4.5 1183 o Short expiration time - Section 5.1.5.3 1185 4.4.1.4. Threat: Malicious client obtains authorization 1187 A malicious client could counterfeit a valid client and obtain an 1188 access authorization that way. The malicious client could even 1189 utilize screen scraping techniques in order to simulate the user 1190 consent in the authorization flow. 1192 Assumption: It is not the task of the authorization server to protect 1193 the end-user's device from malicious software. This is the 1194 responsibility of the platform running on the particular device 1195 probably in cooperation with other components of the respective 1196 ecosystem (e.g. an application management infrastructure). The sole 1197 responsibility of the authorization server is to control access to 1198 the end-user's resources living in resource servers and to prevent 1199 unauthorized access to them. Based on this assumption, the following 1200 countermeasures are available to cope with the threat. 1202 Countermeasures: 1204 o The authorization server should authenticate the client, if 1205 possible (see Section 5.2.3.4). Note: the authentication takes 1206 place after the end-user has authorized the access. 1208 o The authorization server should validate the client's redirection 1209 URI against the pre-registered redirection URI, if one exists (see 1210 Section 5.2.3.5). Note: An invalid redirect URI indicates an 1211 invalid client whereas a valid redirect URI not neccesserily 1212 indicates a valid client. The level of confidence depends on the 1213 client type. For web applications, the confidence is high since 1214 the redirect URI refers to the globally unique network endpoint of 1215 this application whose address is also validated using HTTPS 1216 server authentication by the user agent. In contrast for native 1217 clients, the redirect URI typically refers to device local 1218 resources, e.g. a custom scheme. So a malicious client on a 1219 particular device can use the valid redirect URI the legitimate 1220 client uses on all other devices. 1222 o After authenticating the end-user, the authorization server should 1223 ask him/her for consent. In this context, the user should be 1224 explained the purpose, scope, and duration of the authorization. 1225 Moreover, the authorization server should show the user any 1226 identity information it has for that client. It is up to the user 1227 to validate the binding of this data to the particular application 1228 (e.g. Name) and to approve the authorization request. (see 1229 Section 5.2.4.3). 1231 o The authorization server should not perform automatic re- 1232 authorizations for clients it is unable to reliably authenticate 1233 or validate (see Section 5.2.4.1). 1235 o If the authorization server automatically authenticates the end- 1236 user, it may nevertheless require some user input in order to 1237 prevent screen scraping. Examples are CAPTCHAs or user-specific 1238 secrets like PIN codes. 1240 o The authorization server may also limit the scope of tokens it 1241 issues to clients it cannot reliably authenticate (see 1242 Section 5.1.5.1). 1244 4.4.1.5. Threat: Authorization code phishing 1246 A hostile party could impersonate the client site and get access to 1247 the authorization code. This could be achieved using DNS or ARP 1248 spoofing. This applies to clients, which are web applications, thus 1249 the redirect URI is not local to the host where the user's browser is 1250 running. 1252 Impact: This affects web applications and may lead to a disclosure of 1253 authorization codes and, potentially, the corresponding access and 1254 refresh tokens. 1256 Countermeasures: 1258 It is strongly recommended that one of the following countermeasures 1259 is utilized in order to prevent this attack: 1261 o The redirection URI of the client should point to a HTTPS 1262 protected endpoint and the browser should be utilized to 1263 authenticate this redirection URI using server authentication (see 1264 Section 5.1.2). 1266 o The authorization server should require the client to be 1267 authenticated, i.e. confidential client, so the binding of the 1268 authorization code to a certain client can be validated in a 1269 reliable way (see Section 5.2.4.4). 1271 4.4.1.6. Threat: User session impersonation 1273 A hostile party could impersonate the client site and impersonate the 1274 user's session on this client. This could be achieved using DNS or 1275 ARP spoofing. This applies to clients, which are web applications, 1276 thus the redirect URI is not local to the host where the user's 1277 browser is running. 1279 Impact: An attacker who intercepts the authorization code as it is 1280 sent by the browser to the callback endpoint can gain access to 1281 protected resources by submitting the authorization code to the 1282 client. The client will exchange the authorization code for an 1283 access token and use the access token to access protected resources 1284 for the benefit of the attacker, delivering protected resources to 1285 the attacker, or modifying protected resources as directed by the 1286 attacker. If OAuth is used by the client to delegate authentication 1287 to a social site (e.g. as in the implementation of the "Facebook 1288 Login" button), the attacker can use the intercepted authorization 1289 code to log in to the client as the user. 1291 Note: Authenticating the client during authorization code exchange 1292 will not help to detect such an attack as it is the legitimate client 1293 that obtains the tokens. 1295 Countermeasures: 1297 o In order to prevent an attacker from impersonating the end-users 1298 session, the redirection URI of the client should point to a HTTPS 1299 protected endpoint and the browser should be utilized to 1300 authenticate this redirection URI using server authentication (see 1301 Section 5.1.2) 1303 4.4.1.7. Threat: Authorization code leakage through counterfeit client 1305 The attack leverages the authorization code grant type in an attempt 1306 to get another user (victim) to log-in, authorize access to his/her 1307 resources, and subsequently obtain the authorization code and inject 1308 it into a client application using the attacker's account. The goal 1309 is to associate an access authorization for resources of the victim 1310 with the user account of the attacker on a client site. 1312 The attacker abuses an existing client application and combines it 1313 with his own counterfeit client web site. The attack depends on the 1314 victim expecting the client application to request access to a 1315 certain resource server. The victim, seeing only a normal request 1316 from an expected application, approves the request. The attacker 1317 then uses the victim's authorization to gain access to the 1318 information unknowingly authorized by the victim. 1320 The attacker conducts the following flow: 1322 1. The attacker accesses the client web site (or application) and 1323 initiates data access to a particular resource server. The 1324 client web site in turn initiates an authorization request to the 1325 resource server's authorization server. Instead of proceeding 1326 with the authorization process, the attacker modifies the 1327 authorization server end-user authorization URL as constructed by 1328 the client to include a redirection URI parameter referring to a 1329 web site under his control (attacker's web site). 1331 2. The attacker tricks another user (the victim) to open that 1332 modified end-user authorization URI and to authorize access (e.g. 1333 an email link, or blog link). The way the attacker achieve that 1334 goal is out of scope. 1336 3. Having clicked the link, the victim is requested to authenticate 1337 and authorize the client site to have access. 1339 4. After completion of the authorization process, the authorization 1340 server redirects the user agent to the attacker's web site 1341 instead of the original client web site. 1343 5. The attacker obtains the authorization code from his web site by 1344 means out of scope of this document. 1346 6. He then constructs a redirection URI to the target web site (or 1347 application) based on the original authorization request's 1348 redirection URI and the newly obtained authorization code and 1349 directs his user agent to this URL. The authorization code is 1350 injected into the original client site (or application). 1352 7. The client site uses the authorization code to fetch a token from 1353 the authorization server and associates this token with the 1354 attacker's user account on this site. 1356 8. The attacker may now access the victims resources using the 1357 client site. 1359 Impact: The attackers gains access to the victim's resources as 1360 associated with his account on the client site. 1362 Countermeasures: 1364 o The attacker will need to use another redirection URI for its 1365 authorization process than the target web site because it needs to 1366 intercept the flow. So if the authorization server associates the 1367 authorization code with the redirection URI of a particular end- 1368 user authorization and validates this redirection URI with the 1369 redirection URI passed to the token's endpoint, such an attack is 1370 detected (see Section 5.2.4.5). 1372 o The authorization server may also enforce the usage and validation 1373 of pre-registered redirect URIs (see Section 5.2.3.5). This will 1374 allow for an early recognition of session fixation attempts. 1376 o For native applications, one could also consider to use 1377 deployment-specific client ids and secrets (see Section 5.2.3.4, 1378 along with the binding of authorization code to client_id (see 1379 Section 5.2.4.4), to detect such an attack because the attacker 1380 does not have access the deployment-specific secret. Thus he will 1381 not be able to exchange the authorization code. 1383 o The client may consider using other flows, which are not 1384 vulnerable to this kind of attacks such as "Implicit Grant" or 1385 "Resource Owner Password Credentials" (see Section 4.4.2 or 1386 Section 4.4.3). 1388 4.4.1.8. Threat: CSRF attack against redirect-uri 1390 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1391 requests are transmitted from a user that the website trusts or has 1392 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1393 on OAuth approvals can allow an attacker to obtain authorization to 1394 OAuth protected resources without the consent of the User. 1396 This attack works against the redirection URI used in the 1397 authorization code flow. An attacker could authorize an 1398 authorization code to their own protected resources on an 1399 authorization server. He then aborts the redirect flow back to the 1400 client on his device and tricks the victim into executing the 1401 redirect back to the client. The client receives the redirect, 1402 fetches the token(s) from the authorization server and associates the 1403 victim's client session with the resources accessible using the 1404 token. 1406 Impact: The user accesses resources on behalf of the attacker. The 1407 effective impact depends on the type of resource accessed. For 1408 example, the user may upload private items to an attacker's 1409 resources. Or when using OAuth in 3rd party login scenarios, the 1410 user may associate his client account with the attacker's identity at 1411 the external identity provider. This way the attacker could easily 1412 access the victim's data at the client by logging in from another 1413 device with his credentials at the external identity provider. 1415 Countermeasures: 1417 o The state parameter should be used to link the authorization 1418 request with the redirection URI used to deliver the access token. 1419 Section 5.3.6 1421 o Client developers and end-user can be educated not follow 1422 untrusted URLs. 1424 4.4.1.9. Threat: Clickjacking attack against authorization 1426 With Clickjacking, a malicious site loads the target site in a 1427 transparent iframe overlaid on top of a set of dummy buttons which 1428 are carefully constructed to be placed directly under important 1429 buttons on the target site. When a user clicks a visible button, 1430 they are actually clicking a button (such as an "Authorize" button) 1431 on the hidden page. 1433 Impact: An attacker can steal a user's authentication credentials and 1434 access their resources 1436 Countermeasure 1438 o Native applications should use external browsers instead of 1439 embedding browsers in a web view when requesting end-user 1440 authorization 1442 o For newer browsers, avoidance of iFrames can be enforced server 1443 side by using the X-FRAME-OPTION header - Section 5.2.2.6 1445 o For older browsers, javascript framebusting techniques can be used 1446 but may not be effective in all browsers. 1448 4.4.1.10. Threat: Resource Owner Impersonation 1450 When a client requests access to protected resources, the 1451 authorization flow normally involves the resource owner's explicit 1452 response to the access request, either granting or denying access to 1453 the protected resources. A malicious client can exploit knowledge of 1454 the structure of this flow in order to gain authorization without the 1455 resource owner's consent, by transmitting the necessary requests 1456 programmatically, and simulating the flow against the authorization 1457 server. That way, the client may gain access to the victims 1458 resources without her approval. An authorization server will be 1459 vulnerable to this threat, if it uses non-interactive authentication 1460 mechanisms or split the authorization flow across multiple pages. 1462 The malicious client might embed a hidden HTML user agent, interpret 1463 the HTML forms sent by the authorization server, and automatically 1464 answer with the corresponding form post requests. As a pre- 1465 requisite, the attacker must be able to execute the authorization 1466 process in the context of an already authenticated session of the 1467 resource owner with the authorization server. There are different 1468 ways to achieve this: 1470 o The malicious client could abuse an existing session in an 1471 external browser or cross-browser cookies on the particular 1472 device. 1474 o It could also request authorization for a particular scope and 1475 silently abuse the resulting session in his browser instance to 1476 "silently" request another scope. 1478 o Alternatively, the attacker might exploit an authorization 1479 server's ability to authenticate the resource owner automatically 1480 and without user interactions, e.g. based on certificates. 1482 In all cases, such an attack is limited to clients running on the 1483 victim's device, within the user agent or as native app. 1485 Please note: Such attacks cannot be prevented using CSRF 1486 countermeasures, since the attacker just "executes" the URLs as 1487 prepared by the authorization server including any nonce etc. 1489 Countermeasures: 1491 Authorization servers should decide, based on an analysis of the risk 1492 associated with this threat, whether to assume, detect, or to prevent 1493 this threat. 1495 In order to prevent such an attack, the authorization server may 1496 force an user interaction based on non-predictable input values as 1497 part of the user consent approval. The authorization server could 1499 o combine password authentication and user consent in a single form, 1501 o make use of CAPTCHAs, or 1503 o or use one-time secrets send out of bound to the resource owner 1504 (e.g. via text or instance message). 1506 Alternatively in order to allow the resource owner to detect abuse, 1507 the authorization server could notify the resource owner of any 1508 approval by appropriate means, e.g. text or instant message or 1509 e-Mail. 1511 4.4.1.11. Threat: DoS, Exhaustion of resources attacks 1513 If an authorization server includes a nontrivial amount of entropy in 1514 authorization codes or access tokens (limiting the number of possible 1515 codes/tokens) and automatically grants either without user 1516 intervention and has no limit on code or access tokens per user, an 1517 attacker could exhaust the pool by repeatedly directing user(s) 1518 browser to request code or access tokens. This is because more 1519 entropy means a larger number of tokens can be issued. 1521 Countermeasures: 1523 o The authorization server should consider limiting the number of 1524 access tokens granted per user. The authorization server should 1525 include a nontrivial amount of entropy in authorization codes. 1527 4.4.1.12. Threat: DoS using manufactured authorization codes 1529 An attacker who owns a botnet can locate the redirect URIs of clients 1530 that listen on HTTP, access them with random authorization codes, and 1531 cause a large number of HTTPS connections to be concentrated onto the 1532 authorization server. This can result in a DoS attack on the 1533 authorization server. 1535 This attack can still be effective even when CSRF defense/the 'state' 1536 parameter are deployed on the client side. With such a defense, the 1537 attacker might need to incur an additional HTTP request to obtain a 1538 valid CSRF code/ state parameter. This apparently cuts down the 1539 effectiveness of the attack by a factor of 2. However, if the HTTPS/ 1540 HTTP cost ratio is higher than 2 (the cost factor is estimated to be 1541 around 3.5x at 1542 ) the 1543 attacker still achieves a magnification of resource utilization at 1544 the expense of the authorization server. 1546 Impact: There are a few effects that the attacker can accomplish with 1547 this OAuth flow that they cannot easily achieve otherwise. 1549 1. Connection laundering: With the clients as the relay between the 1550 attacker and the authorization server, the authorization server 1551 learns little or no information about the identity of the 1552 attacker. Defenses such rate limiting on the offending attacker 1553 machines are less effective due to the difficulty to identify the 1554 attacking machines. Although an attacker could also launder its 1555 connections through an anonymizing systems such as Tor, the 1556 effectiveness of that approach depends on the capacity of the 1557 annoying system. On the other hand, a potentially large number 1558 of OAuth clients could be utilized for this attack. 1560 2. Asymmetric resource utilization: The attacker incurs the cost of 1561 an HTTP connection and causes an HTTPS connection to be made on 1562 the authorization server; and the attacker can co-ordinate the 1563 timing of such HTTPS connections across multiple clients 1564 relatively easily. Although the attacker could achieve something 1565 similar, say, by including an iframe pointing to the HTTPS URL of 1566 the authorization server in an HTTP web page and lure web users 1567 to visit that page, timing attacks using such a scheme may be 1568 more difficult as it seems nontrivial to synchronize a large 1569 number of users to simultaneously visit a particular site under 1570 the attacker's control. 1572 Countermeasures 1574 o Though not a complete countermeasure by themselves, CSRF defense 1575 and the 'state' parameter created with secure random codes should 1576 be deployed on the client side. The client should forward the 1577 authorization code to the authorization server only after both the 1578 CSRF token and the 'state' parameter are validated. 1580 o If the client authenticates the user, either through a single sign 1581 on protocol ( such as OpenID / Facebook Connect ) or through local 1582 authentication, the client should suspend the access by a user 1583 account if the number of invalid authorization codes submitted by 1584 this user exceeds a certain threshold. 1586 o The authorization server should send an error response to the 1587 client reporting an invalid authorization code and rate limit or 1588 disallow connections from clients whose number of invalid requests 1589 exceeds a threshold. 1591 o The authorization server may in addition sign the authorization 1592 code using the public key from its SSL certificate, and require 1593 the client to validate the signature. To enhance interoperability 1594 between multiple clients and authorization servers, a standard 1595 procedure to create and validate the signature (including what 1596 attributes to sign) may be developed and agreed between the 1597 clients and the servers. 1599 4.4.2. Implicit Grant 1601 In the implicit grant type flow, the access token is directly 1602 returned to the client as a fragment part of the redirection URI. It 1603 is assumed that the token is not sent to the redirection URI target 1604 as HTTP user agents do not send the fragment part of URIs to HTTP 1605 servers. Thus an attacker cannot eavesdrop the access token on this 1606 communication path and It cannot leak through HTTP referee headers. 1608 4.4.2.1. Threat: Access token leak in transport/end-points 1610 This token might be eavesdropped by an attacker. The token is sent 1611 from server to client via a URI fragment of the redirection URI. If 1612 the communication is not secured or the end-point is not secured, the 1613 token could be leaked by parsing the returned URI. 1615 Impact: the attacker would be able to assume the same rights granted 1616 by the token. 1618 Countermeasures: 1620 o The authorization server should ensure confidentiality of the 1621 response from the authorization server to the client (see 1622 Section 5.1.1). 1624 4.4.2.2. Threat: Access token leak in browser history 1626 An attacker could obtain the token from the browser's history. Note 1627 this means the attacker needs access to the particular device. 1629 Countermeasures: 1631 o Shorten token duration (see Section 5.1.5.3) and reduced scope of 1632 the token may reduce the impact of that attack (see 1633 Section 5.1.5.1). 1635 o Make these requests non-cachable 1637 o Native applications can directly embed a browser widget and 1638 therewith gain full control of the cache. So the application can 1639 cleanup browser history after authorization process. 1641 4.4.2.3. Threat: Malicious client obtains authorization 1643 An malicious client could attempt to obtain a token by fraud. 1645 The same countermeasures as for Section 4.4.1.4 are applicable, 1646 except client authentication. 1648 4.4.2.4. Threat: Manipulation of scripts 1650 A hostile party could act as the client web server and replace or 1651 modify the actual implementation of the client (script). This could 1652 be achieved using DNS or ARP spoofing. This applies to clients 1653 implemented within the Web Browser in a scripting language. 1655 Impact: The attacker could obtain user credential information and 1656 assume the full identity of the user. 1658 Countermeasures: 1660 o The authorization server should authenticate the server from which 1661 scripts are obtained (see Section 5.1.2). 1663 o The client should ensure that scripts obtained have not been 1664 altered in transport (see Section 5.1.1). 1666 o Introduce one time per-use secrets (e.g. client_secret) values 1667 that can only be used by scripts in a small time window once 1668 loaded from a server. The intention would be to reduce the 1669 effectiveness of copying client-side scripts for re-use in an 1670 attackers modified code. 1672 4.4.2.5. Threat: CSRF attack against redirect-uri 1674 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1675 requests are transmitted from a user that the website trusts or has 1676 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1677 on OAuth approvals can allow an attacker to obtain authorization to 1678 OAuth protected resources without the consent of the User. 1680 This attack works against the redirection URI used in the implicit 1681 grant flow. An attacker could acquire an access token to their own 1682 protected resources. He could then construct a redirection URI and 1683 embed their access token in that URI. If he can trick the user into 1684 following the redirection URI and the client does not have protection 1685 against this attack, the user may have the attacker's access token 1686 authorized within their client. 1688 Impact: The user accesses resources on behalf of the attacker. The 1689 effective impact depends on the type of resource accessed. For 1690 example, the user may upload private items to an attacker's 1691 resources. Or when using OAuth in 3rd party login scenarios, the 1692 user may associate his client account with the attacker's identity at 1693 the external identity provider. This way the attacker could easily 1694 access the victim's data at the client by logging in from another 1695 device with his credentials at the external identity provider. 1697 Countermeasures: 1699 o The state parameter should be used to link the authorization 1700 request with the redirection URI used deliver the access token. 1701 This will ensure the client is not tricked into completing any 1702 redirect callback unless it is linked to an authorization request 1703 the client initiated. The state parameter should be unguessable 1704 and the client should be capable of keeping the state parameter 1705 secret. 1707 o Client developers and end-user can be educated not follow 1708 untrusted URLs. 1710 4.4.3. Resource Owner Password Credentials 1712 The "Resource Owner Password Credentials" grant type (see 1713 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration 1714 reasons, allows a client to request an access token using an end- 1715 users user-id and password along with its own credential. This grant 1716 type has higher risk because it maintains the uid/password anti- 1717 pattern. Additionally, because the user does not have control over 1718 the authorization process, clients using this grant type are not 1719 limited by scope, but instead have potentially the same capabilities 1720 as the user themselves. As there is no authorization step, the 1721 ability to offer token revocation is bypassed. 1723 Impact: The resource server can only differentiate scope based on the 1724 access token being associated with a particular client. The client 1725 could also acquire long-living tokens and pass them up to a attacker 1726 web service for further abuse. The client, eavesdroppers, or end- 1727 points could eavesdrop user id and password. 1729 Countermeasures: 1731 o Except for migration reasons, minimize use of this grant type 1733 o The authorization server should validate the client id associated 1734 with the particular refresh token with every refresh request - 1735 Section 5.2.2.2 1737 o As per the core Oauth spec, the authorization server must ensure 1738 that these transmissions are protected using transport-layer 1739 mechanisms such as TLS or SSL (see Section 5.1.1). 1741 4.4.3.1. Threat: Accidental exposure of passwords at client site 1743 If the client does not provide enough protection, an attacker or 1744 disgruntled employee could retrieve the passwords for a user. 1746 Countermeasures: 1748 o Use other flows, which do not rely on the client's cooperation for 1749 secure resource owner credential handling 1751 o Use digest authentication instead of plaintext credential 1752 processing 1754 o Obfuscation of passwords in logs 1756 4.4.3.2. Threat: Client obtains scopes without end-user authorization 1758 All interaction with the resource owner is performed by the client. 1759 Thus it might, intentionally or unintentionally, happen that the 1760 client obtains a token with scope unknown for or unintended by the 1761 resource owner. For example, the resource owner might think the 1762 client needs and acquires read-only access to its media storage only 1763 but the client tries to acquire an access token with full access 1764 permissions. 1766 Countermeasures: 1768 o Use other flows, which do not rely on the client's cooperation for 1769 resource owner interaction 1771 o The authorization server may generally restrict the scope of 1772 access tokens (Section 5.1.5.1) issued by this flow. If the 1773 particular client is trustworthy and can be authenticated in a 1774 reliable way, the authorization server could relax that 1775 restriction. Resource owners may prescribe (e.g. in their 1776 preferences) what the maximum scope is for clients using this 1777 flow. 1779 o The authorization server could notify the resource owner by an 1780 appropriate media, e.g. e-Mail, of the grant issued (see 1781 Section 5.1.3). 1783 4.4.3.3. Threat: Client obtains refresh token through automatic 1784 authorization 1786 All interaction with the resource owner is performed by the client. 1787 Thus it might, intentionally or unintentionally, happen that the 1788 client obtains a long-term authorization represented by a refresh 1789 token even if the resource owner did not intend so. 1791 Countermeasures: 1793 o Use other flows, which do not rely on the client's cooperation for 1794 resource owner interaction 1796 o The authorization server may generally refuse to issue refresh 1797 tokens in this flow (see Section 5.2.2.1). If the particular 1798 client is trustworthy and can be authenticated in a reliable way 1799 (see client authentication), the authorization server could relax 1800 that restriction. Resource owners may allow or deny (e.g. in 1801 their preferences) to issue refresh tokens using this flow as 1802 well. 1804 o The authorization server could notify the resource owner by an 1805 appropriate media, e.g. e-Mail, of the refresh token issued (see 1806 Section 5.1.3). 1808 4.4.3.4. Threat: Obtain user passwords on transport 1810 An attacker could attempt to eavesdrop the transmission of end-user 1811 credentials with the grant type "password" between client and server. 1813 Impact: disclosure of a single end-users password. 1815 Countermeasures: 1817 o Confidentiality of Requests - Section 5.1.1 1819 o alternative authentication means, which do not require to send 1820 plaintext credentials over the wire (Examples: Digest 1821 authentication) 1823 4.4.3.5. Threat: Obtain user passwords from authorization server 1824 database 1826 An attacker may obtain valid username/password combinations from the 1827 authorization server's database by gaining access to the database or 1828 launching a SQL injection attack. 1830 Impact: disclosure of all username/password combinations. The impact 1831 may exceed the domain of the authorization server since many users 1832 tend to use the same credentials on different services. 1834 Countermeasures: 1836 o Credential storage protection can be employed - Section 5.1.4.1 1838 4.4.3.6. Threat: Online guessing 1840 An attacker may try to guess valid username/password combinations 1841 using the grant type "password". 1843 Impact: Revelation of a single username/password combination. 1845 Countermeasures: 1847 o Password policy - Section 5.1.4.2.1 1849 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. The threats to 1865 this grant type are similar to Section 4.4.3. 1867 4.5. Refreshing an Access Token 1869 4.5.1. Threat: Eavesdropping refresh tokens from authorization server 1871 An attacker may eavesdrop refresh tokens when they are transmitted 1872 from the authorization server to the client. 1874 Countermeasures: 1876 o As per the core OAuth spec, the Authorization servers must ensure 1877 that these transmissions are protected using transport-layer 1878 mechanisms such as TLS or SSL (see Section 5.1.1). 1880 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1881 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for 1882 issued access tokens can be used to reduce the damage in case of 1883 leaks. 1885 4.5.2. Threat: Obtaining refresh token from authorization server 1886 database 1888 This threat is applicable if the authorization server stores refresh 1889 tokens as handles in a database. An attacker may obtain refresh 1890 tokens from the authorization server's database by gaining access to 1891 the database or launching a SQL injection attack. 1893 Impact: disclosure of all refresh tokens 1895 Countermeasures: 1897 o Credential storage protection - Section 5.1.4.1 1899 o Bind token to client id, if the attacker cannot obtain the 1900 required id and secret - Section 5.1.5.8 1902 4.5.3. Threat: Obtain refresh token by online guessing 1904 An attacker may try to guess valid refresh token values and send it 1905 using the grant type "refresh_token" in order to obtain a valid 1906 access token. 1908 Impact: exposure of single refresh token and derivable access tokens. 1910 Countermeasures: 1912 o For handle-based designs - Section 5.1.5.11 1914 o For assertion-based designs - Section 5.1.5.9 1916 o Bind token to client id, because the attacker would guess the 1917 matching client id, too (see Section 5.1.5.8) 1919 o Authenticate the client, adds another element the attacker has to 1920 guess (see Section 5.2.3.4) 1922 4.5.4. Threat: Obtain refresh token phishing by counterfeit 1923 authorization server 1925 An attacker could try to obtain valid refresh tokens by proxying 1926 requests to the authorization server. Given the assumption that the 1927 authorization server URL is well-known at development time or can at 1928 least be obtained from a well-known resource server, the attacker 1929 must utilize some kind of spoofing in order to succeed. 1931 Countermeasures: 1933 o Server authentication (as described in Section 5.1.2) 1935 4.6. Accessing Protected Resources 1937 4.6.1. Threat: Eavesdropping access tokens on transport 1939 An attacker could try to obtain a valid access token on transport 1940 between client and resource server. As access tokens are shared 1941 secrets between authorization and resource server, they should be 1942 treated with the same care as other credentials (e.g. end-user 1943 passwords). 1945 Countermeasures: 1947 o Access tokens sent as bearer tokens, should not be sent in the 1948 clear over an insecure channel. As per the core OAuth spec, 1949 transmission of access tokens must be protected using transport- 1950 layer mechanisms such as TLS or SSL (see Section 5.1.1). 1952 o A short lifetime reduces impact in case tokens are compromised 1953 (see Section 5.1.5.3). 1955 o The access token can be bound to a client's identity and require 1956 the client to prove legitimate ownership of the token to the 1957 resource server (see Section 5.4.2). 1959 4.6.2. Threat: Replay authorized resource server requests 1961 An attacker could attempt to replay valid requests in order to obtain 1962 or to modify/destroy user data. 1964 Countermeasures: 1966 o The resource server should utilize transport security measure in 1967 order to prevent such attacks (see Section 5.1.1). This would 1968 prevent the attacker from capturing valid requests. 1970 o Alternatively, the resource server could employ signed requests 1971 (see Section 5.4.3) along with nounces and timestamps in order to 1972 uniquely identify requests. The resource server should detect and 1973 refuse every replayed request. 1975 4.6.3. Threat: Guessing access tokens 1977 Where the token is a handle, the attacker may use attempt to guess 1978 the access token values based on knowledge they have from other 1979 access tokens. 1981 Impact: Access to a single user's data. 1983 Countermeasures: 1985 o Handle Tokens should have a reasonable entropy (see 1986 Section 5.1.5.11) in order to make guessing a valid token value 1987 difficult. 1989 o Assertion (or self-contained token ) tokens contents should be 1990 protected by a digital signature (see Section 5.1.5.9). 1992 o Security can be further strengthened by using a short access token 1993 duration (see Section 5.1.5.2 and Section 5.1.5.3). 1995 4.6.4. Threat: Access token phishing by counterfeit resource server 1997 An attacker may pretend to be a particular resource server and to 1998 accept tokens from a particular authorization server. If the client 1999 sends a valid access tokens to this counterfeit resource server, the 2000 server in turn may use that token to access other services on behalf 2001 of the resource owner. 2003 Countermeasures: 2005 o Clients should not make authenticated requests with an access 2006 token to unfamiliar resource servers, regardless of the presence 2007 of a secure channel. If the resource server address is well-known 2008 to the client, it may authenticate the resource servers (see 2009 Section 5.1.2). 2011 o Associate the endpoint address of the resource server the client 2012 talked to with the access token (e.g. in an audience field) and 2013 validate association at legitimate resource server. The endpoint 2014 address validation policy may be strict (exact match) or more 2015 relaxed (e.g. same host). This would require to tell the 2016 authorization server the resource server endpoint address in the 2017 authorization process. 2019 o Associate an access token with a client and authenticate the 2020 client with resource server requests (typically via signature in 2021 order to not disclose secret to a potential attacker). This 2022 prevents the attack because the counterfeit server is assumed to 2023 miss the capabilities to correctly authenticate on behalf of the 2024 legitimate client to the resource server (Section 5.4.2). 2026 o Restrict the token scope (see Section 5.1.5.1) and or limit the 2027 token to a certain resource server (Section 5.1.5.5). 2029 4.6.5. Threat: Abuse of token by legitimate resource server or client 2031 A legitimate resource server could attempt to use an access token to 2032 access another resource servers. Similarly, a client could try to 2033 use a token obtained for one server on another resource server. 2035 Countermeasures: 2037 o Tokens should be restricted to particular resource servers (see 2038 Section 5.1.5.5). 2040 4.6.6. Threat: Leak of confidential data in HTTP-Proxies 2042 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is 2043 optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J., 2044 Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2045 Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and 2046 WWW-Authenticate headers to distinguish authenticated content so that 2047 it can be protected. Proxies and caches, in particular, may fail to 2048 adequately protect requests not using these headers. For example, 2049 private authenticated content may be stored in (and thus retrievable 2050 from) publicly-accessible caches. 2052 Countermeasures: 2054 o Resource servers not using the HTTP Authorization scheme (OAuth 2055 HTTP Authorization Scheme - see Section 5.4.1) should take care to 2056 use other mechanisms, such as the Cache-Control header, to 2057 minimize the risk that authenticated content is not protected. 2059 o Reducing scope (see Section 5.1.5.1) and expiry time 2060 (Section 5.1.5.3) for access tokens can be used to reduce the 2061 damage in case of leaks. 2063 4.6.7. Threat: Token leakage via logfiles and HTTP referrers 2065 If access tokens are sent via URI query parameters, such tokens may 2066 leak to log files and HTTP referrers. 2068 Countermeasures: 2070 o Use authorization headers or POST parameters instead of URI 2071 request parameters (see Section 5.4.1). 2073 o Set logging configuration appropriately 2075 o Prevent unauthorized persons from access to system log files (see 2076 Section 5.1.4.1.1) 2078 o HTTP referrers can be prevented by reloading the target page again 2079 without URI parameters 2081 o Abuse of leaked access tokens can be prevented by enforcing 2082 authenticated requests (see Section 5.4.2). 2084 o The impact of token leakage may be reduced by limiting scope (see 2085 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing 2086 one time token usage (see Section 5.1.5.4). 2088 5. Security Considerations 2090 This section describes the countermeasures as recommended to mitigate 2091 the threats as described in Section 4. 2093 5.1. General 2095 The general section covers consideratios that apply generally across 2096 all OAuth components (client, resource server, token server, and 2097 user-agents). 2099 5.1.1. Confidentiality of Requests 2101 This is applicable to all requests sent from client to authorization 2102 server or resource server. While OAuth provides a mechanism for 2103 verifying the integrity of requests, it provides no guarantee of 2104 request confidentiality. Unless further precautions are taken, 2105 eavesdroppers will have full access to request content and may be 2106 able to mount interception or replay attacks through using content of 2107 request, e.g. secrets or tokens. 2109 Attacks can be mitigated by using transport-layer mechanisms such as 2110 TLS or SSL. VPN may considered as well. 2112 This is a countermeasure against the following threats: 2114 o Replay of access tokens obtained on tokens endpoint or resource 2115 server's endpoint 2117 o Replay of refresh tokens obtained on tokens endpoint 2119 o Replay of authorization codes obtained on tokens endpoint 2120 (redirect?) 2122 o Replay of user passwords and client secrets 2124 5.1.2. Server authentication 2126 HTTPS server authentication or similar means can be used to 2127 authenticate the identity of a server. The goal is to reliably bind 2128 the DNS name of the server to the public key presented by the server 2129 during connection establishment. 2131 The client should validate the binding of the server to its domain 2132 name. If the server fails to prove that binding, it is considered a 2133 man-in-the-middle attack. The security measure depends on the 2134 certification authorities the client trusts for that purpose. 2135 Clients should carefully select those trusted CAs and protect the 2136 storage for trusted CA certificates from modifications. 2138 This is a countermeasure against the following threats: 2140 o Spoofing 2142 o Proxying 2144 o Phishing by counterfeit servers 2146 5.1.3. Always keep the resource owner informed 2148 Transparency to the resource owner is a key element of the OAuth 2149 protocol. The user should always be in control of the authorization 2150 processes and get the necessary information to meet informed 2151 decisions. Moreover, user involvement is a further security 2152 countermeasure. The user can probably recognize certain kinds of 2153 attacks better than the authorization server. Information can be 2154 presented/exchanged during the authorization process, after the 2155 authorization process, and every time the user wishes to get informed 2156 by using techniques such as: 2158 o User consent forms 2160 o Notification messages (e-Mail, SMS, ...) 2162 o Activity/Event logs 2164 o User self-care applications or portals 2166 5.1.4. Credentials 2168 This sections describes countermeasures used to protect all kinds of 2169 credentials from unauthorized access and abuse. Credentials are long 2170 term secrets, such as client secrets and user passwords as well as 2171 all kinds of tokens (refresh and access token) or authorization 2172 codes. 2174 5.1.4.1. Credential Storage Protection 2176 Administrators should undertake industry best practices to protect 2177 the storage of credentials. Such practices may include but are not 2178 limited to the following sub-sections. 2180 5.1.4.1.1. Standard System Security Means 2182 A server system may be locked down so that no attacker may get access 2183 to sensible configuration files and databases. 2185 5.1.4.1.2. Standard SQL Injection Countermeasures 2187 If a client identifier or other authentication component is queried 2188 or compared against a SQL Database it may become possible for an 2189 injection attack to occur if parameters received are not validated 2190 before submission to the database. 2192 o Ensure that server code is using the minimum database privileges 2193 possible to reduce the "surface" of possible attacks. 2195 o Avoid dynamic SQL using concatenated input. If possible, use 2196 static SQL. 2198 o When using dynamic SQL, parameterize queries using bind arguments. 2199 Bind arguments eliminate possibility of SQL injections. 2201 o Filter and sanitize the input. For example, if an identifier has 2202 a known format, ensure that the supplied value matches the 2203 identifier syntax rules. 2205 5.1.4.1.3. No cleartext storage of credentials 2207 The authorization server should not store credential in clear text. 2208 Typical approaches are to store hashes instead. If the credential 2209 lacks a reasonable entropy level (because it is a user password) an 2210 additional salt will harden the storage to prevent offline dictionary 2211 attacks. Note: Some authentication protocols require the 2212 authorization server to have access to the secret in the clear. 2213 Those protocols cannot be implemented if the server only has access 2214 to hashes. 2216 5.1.4.1.4. Encryption of credentials 2218 For client applications, insecurely persisted client credentials are 2219 easy targets for attackers to obtain. Store client credentials using 2220 an encrypted persistence mechanism such as a keystore or database. 2221 Note that compiling client credentials directly into client code 2222 makes client applications vulnerable to scanning as well as difficult 2223 to administer should client credentials change over time. 2225 5.1.4.1.5. Use of asymmetric cryptography 2227 Usage of asymmetric cryptography will free the authorization server 2228 of the obligation to manage credentials. 2230 5.1.4.2. Online attacks on secrets 2232 5.1.4.2.1. Password policy 2234 The authorization server may decide to enforce a complex user 2235 password policy in order to increase the user passwords' entropy. 2236 This will hinder online password attacks. 2238 5.1.4.2.2. High entropy of secrets 2240 When creating token handles or other secrets not intended for usage 2241 by human users, the authorization server should include a reasonable 2242 level of entropy in order to mitigate the risk of guessing attacks. 2244 The token value should be constructed from a cryptographically strong 2245 random or pseudo-random number sequence [RFC1750] generated by the 2246 Authorization Server. The probability of any two Authorization Code 2247 values being identical should be less than or equal to 2^(-128) and 2248 should be less than or equal to 2^(-160). 2250 5.1.4.2.3. Lock accounts 2252 Online attacks on passwords can be mitigated by locking the 2253 respective accounts after a certain number of failed attempts. 2255 Note: This measure can be abused to lock down legitimate service 2256 users. 2258 5.1.4.2.4. Tar pit 2260 The authorization server may react on failed attempts to authenticate 2261 by username/password by temporarily locking the respective account 2262 and delaying the response for a certain duration. This duration may 2263 increase with the number of failed attempts. The objective is to 2264 slow the attackers attempts on a certain username down. 2266 Note: this may require a more complex and stateful design of the 2267 authorization server. 2269 5.1.4.2.5. Usage of CAPTCHAs 2271 The idea is to prevent programs from automatically checking huge 2272 number of passwords by requiring human interaction. 2274 Note: this has a negative impact on user experience. 2276 5.1.5. Tokens (access, refresh, code) 2278 5.1.5.1. Limit token scope 2280 The authorization server may decide to reduce or limit the scope 2281 associated with a token. Basis of this decision is out of scope, 2282 examples are: 2284 o a client-specific policy, e.g. issue only less powerful tokens to 2285 public clients, 2287 o a service-specific policy, e.g. it a very sensible service, 2289 o a resource-owner specific setting, or 2291 o combinations of such policies and preferences. 2293 The authorization server may allow different scopes dependent on the 2294 grant type. For example, end-user authorization via direct 2295 interaction with the end-user (authorization code) might be 2296 considered more reliable than direct authorization via grant type 2297 username/password. This means will reduce the impact of the 2298 following threats: 2300 o token leakage 2302 o token issuance to malicious software 2304 o unintended issuance of to powerful tokens with resource owner 2305 credentials flow 2307 5.1.5.2. Expiration time 2309 Tokens should generally expire after a reasonable duration. This 2310 complements and strengthens other security measures (such as 2311 signatures) and reduces the impact of all kinds of token leaks. 2313 5.1.5.3. Short expiration time 2315 A short expiration time for tokens is a protection means against the 2316 following threats: 2318 o replay 2320 o reduce impact of token leak 2322 o reduce likelihood of successful online guessing 2324 Note: Short token duration requires preciser clock synchronisation 2325 between authorization server and resource server. Furthermore, 2326 shorter duration may require more token refreshments (access token) 2327 or repeated end-user authorization processes (authorization code and 2328 refresh token). 2330 5.1.5.4. Limit number of usages/ One time usage 2332 The authorization server may restrict the number of requests or 2333 operations which can be performed with a certain token. This 2334 mechanism can be used to mitigate the following threats: 2336 o replay of tokens 2338 o reduce likelihood of successful online guessing 2340 For example, if an Authorization Server observes more than one 2341 attempt to redeem a authorization code, the Authorization Server may 2342 want to revoke all access tokens granted based on the authorization 2343 code as well as reject the current request. 2345 As with the authorization code, access tokens may also have a limited 2346 number of operations. This forces client applications to either re- 2347 authenticate and use a refresh token to obtain a fresh access token, 2348 or it forces the client to re-authorize the access token by involving 2349 the user. 2351 5.1.5.5. Bind tokens to a particular resource server (Audience) 2353 Authorization servers in multi-service environments may consider 2354 issuing tokens with different content to different resource servers 2355 and to explicitly indicate in the token the target server a token is 2356 intended to be sent to (see Audience in SAML Assertions). This 2357 countermeasure can be used in the following situations: 2359 o It reduces the impact of a successful replay attempt, since the 2360 token is applicable to a single resource server, only. 2362 o It prevents abuse of a token by a rough resource server or client, 2363 since the token can only be used on that server. It is rejected 2364 by other servers. 2366 o It reduces the impact of a leakage of a valid token to a 2367 counterfeit resource server. 2369 5.1.5.6. Use endpoint address as token audience 2371 This may be used to indicate to a resource server, which endpoint 2372 address has been used to obtain the token. This measure will allow 2373 to detect requests from a counterfeit resource server, since such 2374 token will contain the endpoint address of that server. 2376 5.1.5.7. Audience and Token scopes 2378 Deployments may consider only using tokens with explicitly defined 2379 scope, where every scope is associated with a particular resource 2380 server. This approach can be used to mitigate attacks, where a 2381 resource server or client uses a token for a different then the 2382 intended purpose. 2384 5.1.5.8. Bind token to client id 2386 An authorization server may bind a token to a certain client 2387 identity. This identity should be validated for every request with 2388 that token. This means can be used, to 2390 o detect token leakage and 2392 o prevent token abuse. 2394 Note: Validating the client identity may require the target server to 2395 authenticate the client's identity. This authentication can be based 2396 on secrets managed independent of the token (e.g. pre-registered 2397 client id/secret on authorization server) or sent with the token 2398 itself (e.g. as part of the encrypted token content). 2400 5.1.5.9. Signed tokens 2402 Self-contained tokens should be signed in order to detect any attempt 2403 to modify or produce faked tokens. 2405 5.1.5.10. Encryption of token content 2407 Self-contained may be encrypted for privacy reasons or to protect 2408 system internal data. 2410 5.1.5.11. Random token value with high entropy 2412 When creating token handles, the authorization server should include 2413 a reasonable level of entropy in order to mitigate the risk of 2414 guessing attacks. The token value should be constructed from a 2415 cryptographically strong random or pseudo-random number sequence 2416 [RFC1750] generated by the Authorization Server. The probability of 2417 any two token values being identical should be less than or equal to 2418 2^(-128) and should be less than or equal to 2^(-160). 2420 5.1.5.12. Assertion formats 2422 For service providers intending to implement an assertion-based token 2423 design it is highly recommended to adopt a standard assertion format 2424 (such as SAML or JWT) that implements [draft-ietf-oauth-assertions]. 2426 5.1.6. Access tokens 2428 The following measures should be used to protect access tokens 2430 o keep them in transient memory (accessible by the client 2431 application only) 2433 o protect from exposure to 3rd parties (malicious application) 2435 o limit number of access tokens granted to a user 2437 5.2. Authorization Server 2439 This section describes considerations related to the OAuth 2440 Authorization Server end-point. 2442 5.2.1. Authorization Codes 2444 5.2.1.1. Automatic revocation of derived tokens if abuse is detected 2446 If an Authorization Server observes multiple attempts to redeem an 2447 authorization grant (e.g. such as an authorization code), the 2448 Authorization Server may want to revoke all tokens granted based on 2449 the authorization grant. 2451 5.2.2. Refresh tokens 2453 5.2.2.1. Restricted issuance of refresh tokens 2455 The authorization server may decide based on an appropriate policy 2456 not to issue refresh tokens. Since refresh tokens are long term 2457 credentials, they may be subject theft. For example, if the 2458 authorization server does not trust a client to securely store such 2459 tokens, it may refuse to issue such a client a refresh token. 2461 5.2.2.2. Binding of refresh token to client_id 2463 The authorization server should bind every refresh token to the id of 2464 the client such a token was originally issued to and validate this 2465 binding for every request to refresh that token. If possible (e.g. 2466 confidential clients), the authorization server should authenticate 2467 the respective client. 2469 This is a countermeasure against refresh token theft or leakage. 2471 Note: This binding should be protected from unauthorized 2472 modifications. 2474 5.2.2.3. Refresh Token Rotation 2476 Refresh token rotation is intended to automatically detect and 2477 prevent attempts to use the same refresh token in parallel from 2478 different apps/devices. This happens if a token gets stolen from the 2479 client and is subsequently used by the attacker and the legitimate 2480 client. The basic idea is to change the refresh token value with 2481 every refresh request in order to detect attempts to obtain access 2482 tokens using old refresh tokens. Since the authorization server 2483 cannot determine whether the attacker or the legitimate client is 2484 trying to access, in case of such an access attempt the valid refresh 2485 token and the access authorization associated with it are both 2486 revoked. 2488 The OAuth specification supports this measure in that the tokens 2489 response allows the authorization server to return a new refresh 2490 token even for requests with grant type "refresh_token". 2492 Note: this measure may cause problems in clustered environments since 2493 usage of the currently valid refresh token must be ensured. In such 2494 an environment, other measures might be more appropriate. 2496 5.2.2.4. Refresh Token Revocation 2498 The authorization server may allow clients or end-users to explicitly 2499 request the invalidation of refresh tokens. 2501 This is a countermeasure against: 2503 o device theft, 2505 o impersonation of resource owner, or 2507 o suspected compromised client applications. 2509 5.2.2.5. Device identification 2511 The authorization server may require to bind authentication 2512 credentials to a device identifier. The IMEI is one example of such 2513 an identifier, there are also operating system specific identifiers. 2514 The authorization server could include such an identifier when 2515 authenticating user credentials in order to detect token theft from a 2516 particular device. 2518 5.2.2.6. X-FRAME-OPTION header 2520 For newer browsers, avoidance of iFrames can be enforced server side 2521 by using the X-FRAME-OPTION header. This header can have two values, 2522 deny and same origin, which will block any framing or framing by 2523 sites with a different origin, respectively. 2525 This is a countermeasure against the following threats: 2527 o Clickjacking attacks 2529 5.2.3. Client authentication and authorization 2531 As described in Section 3 (Security Features), clients are 2532 identified, authenticated and authorized for several purposes, such 2533 as a 2535 o Collate sub-sequent requests to the same client, 2537 o Indicate the trustworthiness of a particular client to the end- 2538 user, 2540 o Authorize access of clients to certain features on the 2541 authorization or resource server, and 2543 o Log a client identity to log files for analysis or statics. 2545 Due to the different capabilities and characteristics of the 2546 different client types, there are different ways to support achieve 2547 objectives, which will be described in this section. Authorization 2548 server providers should be aware of the security policy and 2549 deployment of a particular clients and adapt its treatment 2550 accordingly. For example, one approach could be to treat all clients 2551 as less trustworthy and unsecure. On the other extreme, a service 2552 provider could activate every client installation by hand of an 2553 administrator and that way gain confidence in the identity of the 2554 software package and the security of the environment the client is 2555 installed in. And there are several approaches in between. 2557 5.2.3.1. Don't issue secrets to public clients or clients with 2558 inappropriate security policy 2560 Authorization servers should not issue secrets to "public" clients 2561 that cannot protect secrets. This prevents the server from 2562 overestimating the value of a successful authentication of the 2563 client. 2565 For example, it is of limited benefit to create a single client id 2566 and secret which is shared by all installations of a native 2567 application. Such a scenario requires that this secret must be 2568 transmitted from the developer via the respective distribution 2569 channel, e.g. an application market, to all installations of the 2570 application on end-user devices. A secret, burned into the source 2571 code of the application or a associated resource bundle, cannot be 2572 entirely protected from reverse engineering. Secondly, such secrets 2573 cannot be revoked since this would immediately put all installations 2574 out of work. Moreover, since the authorization server cannot really 2575 trust on the client's identity, it would be dangerous to indicate to 2576 end-users the trustworthiness of the client. 2578 There are other ways to achieve a reasonable security level, as 2579 described in the following sections. 2581 5.2.3.2. Public clients without secret require user consent 2583 Authorization servers should not allow automatic authorization for 2584 public clients. The authorization may issue a client id, but should 2585 require that all authorizations are approved by the end-user. This 2586 is a countermeasure for clients without secret against the following 2587 threats: 2589 o Impersonation of public client applications 2591 5.2.3.3. Client_id only in combination with redirect_uri 2593 The authorization may issue a client_id and bind the client_id to a 2594 certain pre-configured redirect_uri. Any authorization request with 2595 another redirection URI is refused automatically. Alternatively, the 2596 authorization server should not accept any dynamic redirection URI 2597 for such a client_id and instead always redirect to the well-known 2598 pre-configured redirection URI. This is a countermeasure for clients 2599 without secrets against the following threats: 2601 o Cross-site scripting attacks 2603 o Impersonation of public client applications 2605 5.2.3.4. Deployment-specific client secrets 2607 A authorization server may issue separate client identifiers and 2608 corresponding secrets to the different deployments of a client. The 2609 effect of such an approach would be to turn otherwise "public" 2610 clients back into "confidential" clients. 2612 For web applications, this could mean to create one client_id and 2613 client_secret per web site a software package is installed on. So 2614 the provider of that particular site could request client id and 2615 secret from the authorization server during setup of the web site. 2616 This would also allow to validate some of the properties of that web 2617 site, such as redirection URI, address, and whatever proofs useful. 2618 The web site provider has to ensure the security of the client secret 2619 on the site. 2621 For native applications, things are more complicated because every 2622 installation of the application on any device is another deployment. 2623 Deployment specific secrets will require 2625 1. Either to obtain a client_id and client_secret during download 2626 process from the application market, or 2628 2. During installation on the device. 2630 Either approach will require an automated mechanism for issuing 2631 client ids and secrets, which is currently not defined by OAuth. 2633 The first approach would allow to achieve a level where the client is 2634 authenticated and identified, whereas the second option only allows 2635 to authenticate the client but not to validate properties of the 2636 client. But this would at least help to prevent several replay 2637 attacks. Moreover, deployment-specific client_id and secret allow to 2638 selectively revoke all refresh tokens of a specific deployment at 2639 once. 2641 5.2.3.5. Validation of pre-registered redirect_uri 2643 An authorization server should require all clients to register their 2644 redirect_uri and the redirect_uri should be the full URI as defined 2645 in [I-D.ietf-oauth-v2]. The way this registration is performed is 2646 out of scope of this document. As per the core spec, every actual 2647 redirection URI sent with the respective client_id to the end-user 2648 authorization endpoint must match the registered redirection URI. 2649 Where it does not match, the authorization server should assume the 2650 inbound GET request has been sent by an attacker and refuse it. 2651 Note: the authorization server should not redirect the user agent 2652 back to the redirection URI of such an authorization request. 2654 o Authorization code leakage through counterfeit web site: allows to 2655 detect attack attempts already after first redirect to end-user 2656 authorization endpoint (Section 4.4.1.7). 2658 o For clients with validated properties, this measure also helps to 2659 detect malicious applications early in the end-user authorization 2660 process. This reduces the need for a interactive validation by 2661 the user (Section 4.4.1.4, Section 4.4.2.3). 2663 o Open Redirector attack via client redirection endpoint. ( 2664 Section 4.1.5. ) 2666 o Open Redirector phishing attack via authorization server 2667 redirection endpoint ( Section 4.2.4 ) 2669 The underlying assumption of this measure is that an attacker will 2670 need to use another redirection URI in order to get access to the 2671 authorization code. Deployments might consider the possibility of an 2672 attacker using spoofing attacks to a victims device to circumvent 2673 this security measure. 2675 Note: Pre-registering clients might not scale in some deployments 2676 (manual process) or require dynamic client registration (not 2677 specified yet). With the lack of dynamic client registration, it 2678 only works for clients bound to certain deployments at development/ 2679 configuration time. As soon as dynamic resource server discovery 2680 gets involved, that's no longer feasible. 2682 5.2.3.6. Client secret revocation 2684 An authorization server may revoke a client's secret in order to 2685 prevent abuse of a revealed secret. 2687 Note: This measure will immediately invalidate any authorization code 2688 or refresh token issued to the respective client. This might be 2689 unintentionally for client identifiers and secrets used across 2690 multiple deployments of a particular native or web application. 2692 This a countermeasure against: 2694 o Abuse of revealed client secrets for private clients 2696 5.2.3.7. Use strong client authentication (e.g. client_assertion / 2697 client_token) 2699 By using an alternative form of authentication such as client 2700 assertion [draft-ietf-oauth-assertions], the need to distribute 2701 client_secret is eliminated. This may require the use of a secure 2702 private key store or other supplemental authentication system as 2703 specified by the client assertion issuer in its authentication 2704 process. 2706 5.2.4. End-user authorization 2708 This secion involves considerations for authorization flows involving 2709 the end-user. 2711 5.2.4.1. Automatic processing of repeated authorizations requires 2712 client validation 2714 Authorization servers should NOT automatically process repeat 2715 authorizations where the client is not authenticated through a client 2716 secret or some other authentication mechanism such as signing with 2717 security certificates (5.7.2.7. Use strong client authentication 2718 (e.g. client_assertion / client_token)) or validation of a pre- 2719 registered redirect URI (5.7.2.5. Validation of pre-registered 2720 redirection URI ). 2722 5.2.4.2. Informed decisions based on transparency 2724 The authorization server should clearly explain to the end-user what 2725 happens in the authorization process and what the consequences are. 2726 For example, the user should understand what access he is about to 2727 grant to which client for what duration. It should also be obvious 2728 to the user, whether the server is able to reliably certify certain 2729 client properties (web site address, security policy). 2731 5.2.4.3. Validation of client properties by end-user 2733 In the authorization process, the user is typically asked to approve 2734 a client's request for authorization. This is an important security 2735 mechanism by itself because the end-user can be involved in the 2736 validation of client properties, such as whether the client name 2737 known to the authorization server fits the name of the web site or 2738 the application the end-user is using. This measure is especially 2739 helpful in all situation where the authorization server is unable to 2740 authenticate the client. It is a countermeasure against: 2742 o Malicious application 2744 o A client application masquerading as another client 2746 5.2.4.4. Binding of authorization code to client_id 2748 The authorization server should bind every authorization code to the 2749 id of the respective client which initiated the end-user 2750 authorization process. This measure is a countermeasure against: 2752 o replay of authorization codes with different client credentials 2753 since an attacker cannot use another client_id to exchange an 2754 authorization code into a token 2756 o Online guessing of authorization codes 2758 Note: This binding should be protected from unauthorized 2759 modifications. 2761 5.2.4.5. Binding of authorization code to redirect_uri 2763 The authorization server should bind every authorization code to the 2764 actual redirection URI used as redirect target of the client in the 2765 end-user authorization process. This binding should be validated 2766 when the client attempts to exchange the respective authorization 2767 code for an access token. This measure is a countermeasure against 2768 authorization code leakage through counterfeit web sites since an 2769 attacker cannot use another redirection URI to exchange an 2770 authorization code into a token. 2772 5.3. Client App Security 2774 This section deals with considerations for client applications. 2776 5.3.1. Don't store credentials in code or resources bundled with 2777 software packages 2779 Because of the numbers of copies of client software, there is limited 2780 benefit to create a single client id and secret which is shared by 2781 all installations of an application. Such an application by itself 2782 would be considered a "public" client as it cannot be presumed to be 2783 able to keep client secrets. A secret, burned into the source code 2784 of the application or a associated resource bundle, cannot be 2785 entirely protected from reverse engineering. Secondly, such secrets 2786 cannot be revoked since this would immediately put all installations 2787 out of work. Moreover, since the authorization server cannot really 2788 trust on the client's identity, it would be dangerous to indicate to 2789 end-users the trustworthiness of the client. 2791 5.3.2. Standard web server protection measures (for config files and 2792 databases) 2794 Use standard web server protection measures - Section 5.3.2 2796 5.3.3. Store secrets in a secure storage 2798 The are different way to store secrets of all kinds (tokens, client 2799 secrets) securely on a device or server. 2801 Most multi-user operation systems segregate the personal storage of 2802 the different system users. Moreover, most modern smartphone 2803 operating systems even support to store app-specific data in separate 2804 areas of the file systems and protect it from access by other 2805 applications. Additionally, applications can implements confidential 2806 data itself using a user-supplied secret, such as PIN or password. 2808 Another option is to swap refresh token storage to a trusted backend 2809 server. This mean in turn requires a resilient authentication 2810 mechanisms between client and backend server. Note: Applications 2811 should ensure that confidential data is kept confidential even after 2812 reading from secure storage, which typically means to keep this data 2813 in the local memory of the application. 2815 5.3.4. Utilize device lock to prevent unauthorized device access 2817 On a typical modern phone, there are many "device lock" options which 2818 can be utilized to provide additional protection where a device is 2819 stolen or misplaced. These include PINs, passwords and other 2820 biomtric featres such as "face recognition". These are not equal in 2821 their level of security they provide. 2823 5.3.5. Platform security measures 2825 o Validation process 2827 o software package signatures 2829 o Remote removal 2831 5.3.6. Link state parameter to user agent session 2833 The state parameter is used to link client requests and prevent CSRF 2834 attacks, for example against the redirection URI. An attacker could 2835 inject their own authorization code or access token, which can result 2836 in the client using an access token associated with the attacker's 2837 protected resources rather than the victim's (e.g. save the victim's 2838 bank account information to a protected resource controlled by the 2839 attacker). 2841 The client should utilize the "state" request parameter to send the 2842 authorization server a value that binds the request to the user- 2843 agent's authenticated state (e.g. a hash of the session cookie used 2844 to authenticate the user-agent) when making an authorization request. 2845 Once authorization has been obtained from the end-user, the 2846 authorization server redirects the end-user's user-agent back to the 2847 client with the required binding value contained in the "state" 2848 parameter. 2850 The binding value enables the client to verify the validity of the 2851 request by matching the binding value to the user- agent's 2852 authenticated state. 2854 5.4. Resource Servers 2856 The following section details security considerations for resource 2857 servers. 2859 5.4.1. Authorization headers 2861 Authorization headers are recognized and specially treated by HTTP 2862 proxies and servers. Thus the usage of such headers for sending 2863 access tokens to resource servers reduces the likelihood of leakage 2864 or unintended storage of authenticated requests in general and 2865 especially Authorization headers. 2867 5.4.2. Authenticated requests 2869 An authorization server may bind tokens to a certain client identity 2870 and encourage resource servers to validate that binding. This will 2871 require the resource server to authenticate the originator of a 2872 request as the legitimate owner of a particular token. There are a 2873 couple of options to implement this countermeasure: 2875 o The authorization server may associate the distinguished name of 2876 the client with the token (either internally or in the payload of 2877 an self-contained token). The client then uses client 2878 certificate-based HTTP authentication on the resource server's 2879 endpoint to authenticate its identity and the resource server 2880 validates the name with the name referenced by the token. 2882 o same as before, but the client uses his private key to sign the 2883 request to the resource server (public key is either contained in 2884 the token or sent along with the request) 2886 o Alternatively, the authorization server may issue a token-bound 2887 secret, which the client uses to sign the request. The resource 2888 server obtains the secret either directly from the authorization 2889 server or it is contained in an encrypted section of the token. 2890 That way the resource server does not "know" the client but is 2891 able to validate whether the authorization server issued the token 2892 to that client 2894 This mechanisms is a countermeasure against abuse of tokens by 2895 counterfeit resource servers. 2897 5.4.3. Signed requests 2899 A resource server may decide to accept signed requests only, either 2900 to replace transport level security measures or to complement such 2901 measures. Every signed request should be uniquely identifiable and 2902 should not be processed twice by the resource server. This 2903 countermeasure helps to mitigate: 2905 o modifications of the message and 2907 o replay attempts 2909 6. IANA Considerations 2911 This document makes no request of IANA. 2913 Note to RFC Editor: this section may be removed on publication as an 2914 RFC. 2916 7. Acknowledgements 2918 We would like to thank Hui-Lan Lu, Francisco Corella, Peifung E Lam, 2919 Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim Bray, and James 2920 H. Manger for their comments and contributions. 2922 8. References 2924 8.1. Normative References 2926 [I-D.ietf-oauth-v2] 2927 Hammer, E., Recordon, D., and D. Hardt, "The OAuth 2.0 2928 Authorization Protocol", draft-ietf-oauth-v2-23 (work in 2929 progress), January 2012. 2931 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2932 Requirement Levels", BCP 14, RFC 2119, March 1997. 2934 8.2. Informative References 2936 [I-D.ietf-oauth-v2-bearer] 2937 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 2938 Authorization Protocol: Bearer Tokens", 2939 draft-ietf-oauth-v2-bearer-17 (work in progress), 2940 February 2012. 2942 [I-D.ietf-oauth-v2-http-mac] 2943 Hammer-Lahav, E., "HTTP Authentication: MAC Access 2944 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in 2945 progress), February 2012. 2947 [I-D.lodderstedt-oauth-revocation] 2948 Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token 2949 Revocation", draft-lodderstedt-oauth-revocation-03 (work 2950 in progress), September 2011. 2952 [portable-contacts] 2953 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008. 2955 Appendix A. Document History 2957 [[ to be removed by RFC editor before publication as an RFC ]] 2959 draft-lodderstedt-oauth-security-01 2961 o section 4.4.1.2 - changed "resource server" to "client" in 2962 countermeasures description. 2964 o section 4.4.1.6 - changed "client shall authenticate the server" 2965 to "The browser shall be utilized to authenticate the redirection 2966 URI of the client" 2968 o section 5 - general review and alignment with public/confidential 2969 client terms 2971 o all sections - general clean-up and typo corrections 2973 draft-ietf-oauth-v2-threatmodel-00 2975 o section 3.4 - added the purposes for using authorization codes. 2977 o extended section 4.4.1.1 2979 o merged 4.4.1.5 into 4.4.1.2 2981 o corrected some typos 2983 o reformulated "session fixation", renamed respective sections into 2984 "authorization code disclosure through counterfeit client" 2986 o added new section "User session impersonation" 2988 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, 2989 5.1.4.1.4, 5.2.3.5 2991 o added new threat "DoS using manufactured authorization codes" as 2992 proposed by Peifung E Lam 2994 o added XSRF and clickjacking (incl. state parameter explanation) 2996 o changed sub-section order in section 4.4.1 2998 o incorporated feedback from Skylar Woodward (client secrets) and 2999 Shane B Weeden (refresh tokens as client instance secret) 3001 o aligned client section with core draft's client type definition 3003 o converted I-D into WG document 3005 draft-ietf-oauth-v2-threatmodel-01 3007 o Alignment of terminology with core draft 22 (private/public 3008 client, redirect URI validation policy, replaced definition of the 3009 client categories by reference to respective core section) 3011 o Synchronisation with the core's security consideration section 3012 (UPDATE 10.12 CSRF, NEW 10.14/15) 3014 o Added Resource Owner Impersonation 3016 o Improved section 5 3018 o Renamed Refresh Token Replacement to Refresh Token Rotation 3020 draft-ietf-oauth-v2-threatmodel-02 3022 o Incoporated Tim Bray's review comments (e.g. removed all normative 3023 language) 3025 Authors' Addresses 3027 Torsten Lodderstedt (editor) 3028 Deutsche Telekom AG 3030 Email: torsten@lodderstedt.net 3032 Mark McGloin 3033 IBM 3035 Email: mark.mcgloin@ie.ibm.com 3037 Phil Hunt 3038 Oracle Corporation 3040 Email: phil.hunt@yahoo.com