idnits 2.17.1 draft-ietf-oauth-v2-threatmodel-04.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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2949: '... Server MUST only assert client p...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 25, 2012) is 4347 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC1750' is mentioned on line 2412, but not defined ** Obsolete undefined reference: RFC 1750 (Obsoleted by RFC 4086) == Unused Reference: 'I-D.lodderstedt-oauth-revocation' is defined on line 2989, but no explicit reference was found in the text == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-26 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-v2-bearer-19 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-01 Summary: 2 errors (**), 0 flaws (~~), 8 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: November 26, 2012 IBM 6 P. Hunt 7 Oracle Corporation 8 May 25, 2012 10 OAuth 2.0 Threat Model and Security Considerations 11 draft-ietf-oauth-v2-threatmodel-04 13 Abstract 15 This document gives additional security considerations for OAuth, 16 beyond those in the OAuth specification, based on a comprehensive 17 threat model for the OAuth 2.0 Protocol. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on November 26, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.2. Attack Assumptions . . . . . . . . . . . . . . . . . . . . 7 57 2.3. Architectural assumptions . . . . . . . . . . . . . . . . 7 58 2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 59 2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 60 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.1.2. Expires_In . . . . . . . . . . . . . . . . . . . . . . 10 65 3.2. Access Token . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.3. Refresh Token . . . . . . . . . . . . . . . . . . . . . . 11 67 3.4. Authorization Code . . . . . . . . . . . . . . . . . . . . 12 68 3.5. Redirection URI . . . . . . . . . . . . . . . . . . . . . 12 69 3.6. State parameter . . . . . . . . . . . . . . . . . . . . . 12 70 3.7. Client Identity . . . . . . . . . . . . . . . . . . . . . 12 71 4. Security Threat Model . . . . . . . . . . . . . . . . . . . . 14 72 4.1. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.1.1. Threat: Obtain Client Secrets . . . . . . . . . . . . 15 74 4.1.2. Threat: Obtain Refresh Tokens . . . . . . . . . . . . 16 75 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 18 76 4.1.4. Threat: End-user credentials phished using 77 compromised or embedded browser . . . . . . . . . . . 18 78 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 19 79 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 19 80 4.2.1. Threat: Password phishing by counterfeit 81 authorization server . . . . . . . . . . . . . . . . . 20 82 4.2.2. Threat: User unintentionally grants too much 83 access scope . . . . . . . . . . . . . . . . . . . . . 20 84 4.2.3. Threat: Malicious client obtains existing 85 authorization by fraud . . . . . . . . . . . . . . . . 21 86 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 21 87 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 21 88 4.3.1. Threat: Eavesdropping access tokens . . . . . . . . . 22 89 4.3.2. Threat: Obtain access tokens from authorization 90 server database . . . . . . . . . . . . . . . . . . . 22 91 4.3.3. Threat: Obtain client credentials over non secure 92 transport . . . . . . . . . . . . . . . . . . . . . . 22 93 4.3.4. Threat: Obtain client secret from authorization 94 server database . . . . . . . . . . . . . . . . . . . 23 95 4.3.5. Threat: Obtain client secret by online guessing . . . 23 96 4.3.6. Threat: DoS on dynamic client secret creation . . . . 23 97 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 23 98 4.4.1. Authorization Code . . . . . . . . . . . . . . . . . . 24 99 4.4.1.1. Threat: Eavesdropping or leaking authorization 100 codes . . . . . . . . . . . . . . . . . . . . . . 24 101 4.4.1.2. Threat: Obtain authorization codes from 102 authorization server database . . . . . . . . . . 25 103 4.4.1.3. Threat: Online guessing of authorization codes . . 25 104 4.4.1.4. Threat: Malicious client obtains authorization . . 26 105 4.4.1.5. Threat: Authorization code phishing . . . . . . . 27 106 4.4.1.6. Threat: User session impersonation . . . . . . . . 28 107 4.4.1.7. Threat: Authorization code leakage through 108 counterfeit client . . . . . . . . . . . . . . . . 28 109 4.4.1.8. Threat: CSRF attack against redirect-uri . . . . . 30 110 4.4.1.9. Threat: Clickjacking attack against 111 authorization . . . . . . . . . . . . . . . . . . 31 112 4.4.1.10. Threat: Resource Owner Impersonation . . . . . . . 31 113 4.4.1.11. Threat: DoS, Exhaustion of resources attacks . . . 33 114 4.4.1.12. Threat: DoS using manufactured authorization 115 codes . . . . . . . . . . . . . . . . . . . . . . 33 116 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 35 117 4.4.2.1. Threat: Access token leak in 118 transport/end-points . . . . . . . . . . . . . . . 35 119 4.4.2.2. Threat: Access token leak in browser history . . . 35 120 4.4.2.3. Threat: Malicious client obtains authorization . . 35 121 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 36 122 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 36 123 4.4.3. Resource Owner Password Credentials . . . . . . . . . 37 124 4.4.3.1. Threat: Accidental exposure of passwords at 125 client site . . . . . . . . . . . . . . . . . . . 38 126 4.4.3.2. Threat: Client obtains scopes without end-user 127 authorization . . . . . . . . . . . . . . . . . . 38 128 4.4.3.3. Threat: Client obtains refresh token through 129 automatic authorization . . . . . . . . . . . . . 38 130 4.4.3.4. Threat: Obtain user passwords on transport . . . . 39 131 4.4.3.5. Threat: Obtain user passwords from 132 authorization server database . . . . . . . . . . 39 133 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 40 134 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 40 135 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 40 136 4.5.1. Threat: Eavesdropping refresh tokens from 137 authorization server . . . . . . . . . . . . . . . . . 40 138 4.5.2. Threat: Obtaining refresh token from authorization 139 server database . . . . . . . . . . . . . . . . . . . 41 140 4.5.3. Threat: Obtain refresh token by online guessing . . . 41 141 4.5.4. Threat: Obtain refresh token phishing by 142 counterfeit authorization server . . . . . . . . . . . 41 143 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 42 144 4.6.1. Threat: Eavesdropping access tokens on transport . . . 42 145 4.6.2. Threat: Replay authorized resource server requests . . 42 146 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 42 147 4.6.4. Threat: Access token phishing by counterfeit 148 resource server . . . . . . . . . . . . . . . . . . . 43 149 4.6.5. Threat: Abuse of token by legitimate resource 150 server or client . . . . . . . . . . . . . . . . . . . 44 151 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 44 152 4.6.7. Threat: Token leakage via logfiles and HTTP 153 referrers . . . . . . . . . . . . . . . . . . . . . . 44 154 5. Security Considerations . . . . . . . . . . . . . . . . . . . 45 155 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 45 156 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 45 157 5.1.2. Server authentication . . . . . . . . . . . . . . . . 46 158 5.1.3. Always keep the resource owner informed . . . . . . . 46 159 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 46 160 5.1.4.1. Credential Storage Protection . . . . . . . . . . 47 161 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 48 162 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 49 163 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 49 164 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 49 165 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 49 166 5.1.5.4. Limit number of usages/ One time usage . . . . . . 50 167 5.1.5.5. Bind tokens to a particular resource server 168 (Audience) . . . . . . . . . . . . . . . . . . . . 50 169 5.1.5.6. Use endpoint address as token audience . . . . . . 51 170 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 51 171 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 51 172 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 51 173 5.1.5.10. Encryption of token content . . . . . . . . . . . 51 174 5.1.5.11. Random token value with high entropy . . . . . . . 51 175 5.1.5.12. Assertion formats . . . . . . . . . . . . . . . . 52 176 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 52 177 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 52 178 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 52 179 5.2.1.1. Automatic revocation of derived tokens if 180 abuse is detected . . . . . . . . . . . . . . . . 52 181 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 52 182 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 52 183 5.2.2.2. Binding of refresh token to client_id . . . . . . 53 184 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 53 185 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 53 186 5.2.2.5. Device identification . . . . . . . . . . . . . . 54 187 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 54 188 5.2.3. Client authentication and authorization . . . . . . . 54 189 5.2.3.1. Don't issue secrets to public clients or 190 clients with inappropriate security policy . . . . 55 191 5.2.3.2. Public clients without secret require user 192 consent . . . . . . . . . . . . . . . . . . . . . 55 193 5.2.3.3. Client_id only in combination with redirect_uri . 55 194 5.2.3.4. Deployment-specific client secrets . . . . . . . . 56 195 5.2.3.5. Validation of pre-registered redirect_uri . . . . 56 196 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 57 197 5.2.3.7. Use strong client authentication (e.g. 198 client_assertion / client_token) . . . . . . . . . 57 199 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 200 5.2.4.1. Automatic processing of repeated 201 authorizations requires client validation . . . . 58 202 5.2.4.2. Informed decisions based on transparency . . . . . 58 203 5.2.4.3. Validation of client properties by end-user . . . 58 204 5.2.4.4. Binding of authorization code to client_id . . . . 59 205 5.2.4.5. Binding of authorization code to redirect_uri . . 59 206 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 59 207 5.3.1. Don't store credentials in code or resources 208 bundled with software packages . . . . . . . . . . . . 59 209 5.3.2. Standard web server protection measures (for 210 config files and databases) . . . . . . . . . . . . . 60 211 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 212 5.3.4. Utilize device lock to prevent unauthorized device 213 access . . . . . . . . . . . . . . . . . . . . . . . . 60 214 5.3.5. Platform security measures . . . . . . . . . . . . . . 60 215 5.3.6. Link state parameter to user agent session . . . . . . 60 216 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 217 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 218 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 61 219 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 220 5.5. A Word on User Interaction and User-Installed Apps . . . . 62 221 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 63 222 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 63 223 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 224 8.1. Normative References . . . . . . . . . . . . . . . . . . . 63 225 8.2. Informative References . . . . . . . . . . . . . . . . . . 64 226 Appendix A. Document History . . . . . . . . . . . . . . . . . . 64 227 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 229 1. Introduction 231 This document gives additional security considerations for OAuth, 232 beyond those in the OAuth specification, based on a comprehensive 233 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It 234 contains the following content: 236 o Documents any assumptions and scope considered when creating the 237 threat model. 239 o Describes the security features in-built into the OAuth protocol 240 and how they are intended to thwart attacks. 242 o Gives a comprehensive threat model for OAuth and describes the 243 respective counter measures to thwart those threats. 245 Threats include any intentional attacks on OAuth tokens and resources 246 protected by OAuth tokens as well as security risks introduced if the 247 proper security measures are not put in place. Threats are 248 structured along the lines of the protocol structure to aid 249 development teams implement each part of the protocol securely. For 250 example all threats for granting access or all threats for a 251 particular grant type or all threats for protecting the resource 252 server. 254 2. Overview 256 2.1. Scope 258 The security considerations document only considers clients bound to 259 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such 260 deployments have the following characteristics: 262 o Resource server URLs are static and well-known at development 263 time, authorization server URLs can be static or discovered. 265 o Token scope values (e.g. applicable URLs and methods) are well- 266 known at development time. 268 o Client registration: Since registration of clients is out of scope 269 of the current core spec, this document assumes a broad variety of 270 options from static registration during development time to 271 dynamic registration at runtime. 273 The following are considered out of scope : 275 o Communication between authorization server and resource server 277 o Token formats 279 o Except for "Resource Owner Password Credentials" (see 280 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by 281 authorization servers to authenticate the user 283 o Mechanism by which a user obtained an assertion and any resulting 284 attacks mounted as a result of the assertion being false. 286 o Clients not bound to a specific deployment: An example could be a 287 mail client with support for contact list access via the portable 288 contacts API (see [portable-contacts]). Such clients cannot be 289 registered upfront with a particular deployment and should 290 dynamically discover the URLs relevant for the OAuth protocol. 292 2.2. Attack Assumptions 294 The following assumptions relate to an attacker and resources 295 available to an attacker: 297 o It is assumed the attacker has full access to the network between 298 the client and authorization servers and the client and the 299 resource server, respectively. The attacker may eavesdrop on any 300 communications between those parties. He is not assumed to have 301 access to communication between authorization and resource server. 303 o It is assumed an attacker has unlimited resources to mount an 304 attack. 306 o It is assumed that 2 of the 3 parties involved in the OAuth 307 protocol may collude to mount an attack against the 3rd party. 308 For example, the client and authorization server may be under 309 control of an attacker and collude to trick a user to gain access 310 to resources. 312 2.3. Architectural assumptions 314 This section documents the assumptions about the features, 315 limitations, and design options of the different entities of a OAuth 316 deployment along with the security-sensitive data-elements managed by 317 those entity. These assumptions are the foundation of the threat 318 analysis. 320 The OAuth protocol leaves deployments with a certain degree of 321 freedom how to implement and apply the standard. The core 322 specification defines the core concepts of an authorization server 323 and a resource server. Both servers can be implemented in the same 324 server entity, or they may also be different entities. The later is 325 typically the case for multi-service providers with a single 326 authentication and authorization system, and are more typical in 327 middleware architectures. 329 2.3.1. Authorization Servers 331 The following data elements are stored or accessible on the 332 authorization server: 334 o user names and passwords 336 o client ids and secrets 338 o client-specific refresh tokens 340 o client-specific access tokens (in case of handle-based design) 342 o HTTPS certificate/key 344 o per-authorization process (in case of handle-based design): 345 redirect_uri, client_id, authorization code 347 2.3.2. Resource Server 349 The following data elements are stored or accessible on the resource 350 server: 352 o user data (out of scope) 354 o HTTPS certificate/key 356 o authorization server credentials (handle-based design), or 358 o authorization server shared secret/public key (assertion-based 359 design) 361 o access tokens (per request) 363 It is assumed that a resource server has no knowledge of refresh 364 tokens, user passwords, or client secrets. 366 2.3.3. Client 368 A full definition of different client types and profiles is given in 369 [I-D.ietf-oauth-v2], Section 2.1. 371 The following data elements are stored or accessible on the client: 373 o client id (and client secret or corresponding client credential) 375 o one or more refresh tokens (persistent) and access tokens 376 (transient) per end-user or other security-context or delegation 377 context 379 o trusted CA certificates (HTTPS) 381 o per-authorization process: redirect_uri, authorization code 383 3. Security Features 385 These are some of the security features which have been built into 386 the OAuth 2.0 protocol to mitigate attacks and security issues. 388 3.1. Tokens 390 OAuth makes extensive use many kinds of tokens (access tokens, 391 refresh tokens, authorization codes). The information content of a 392 token can be represented in two ways as follows: 394 Handle (or artifact) a reference to some internal data structure 395 within the authorization server; the internal data structure 396 contains the attributes of the token, such as user id, scope, etc. 397 Handles enable simple revocation and do not require cryptographic 398 mechanisms to protect token content from being modified. On the 399 other hand, handles require communication between issuing and 400 consuming entity (e.g. authorization and resource server) in order 401 to validate the token and obtain token-bound data. This 402 communication might have an negative impact on performance and 403 scalability if both entities reside on different systems. Handles 404 are therefore typically used if the issuing and consuming entity 405 are the same. A 'handle' token is often referred to as an 406 'opaque' token because the resource server does not need to be 407 able to interpret the token directly, it simply uses the token. 409 Assertions (aka self-contained token) a parseable token. An 410 assertion typically has a duration, has an audience, and is 411 digitally signed. It contains information about the user and the 412 client. Examples of assertion formats are SAML assertions and 413 Kerberos tickets. Assertions can typically directly be validated 414 and used by a resource server without interactions with the 415 authorization server. This results in better performance and 416 scalability in deployment where issuing and consuming entity 417 reside on different systems. Implementing token revocation is 418 more difficult with assertions than with handles. 420 Tokens can be used in two ways to invoke requests on resource servers 421 as follows: 423 bearer token A 'bearer token' is a token that can be used by any 424 client who has received the token (e.g. 425 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to 426 use the token it is important that communication between end- 427 points be secured to ensure that only authorized end-points may 428 capture the token. The bearer token is convenient to client 429 applications as it does not require them to do anything to use 430 them (such as a proof of identity). Bearer tokens have similar 431 characteristics to web single-sign-on (SSO) cookies used in 432 browsers. 434 proof token A 'proof token' is a token that can only be used by a 435 specific client. Each use of the token, requires the client to 436 perform some action that proves that it is the authorized user of 437 the token. Examples of this are MAC tokens, which require the 438 client to digitally sign the resource request with a secret 439 corresponding to the particular token send with the request 440 (e.g.[I-D.ietf-oauth-v2-http-mac]). 442 3.1.1. Scope 444 A Scope represents the access authorization associated with a 445 particular token with respect to resource servers, resources and 446 methods on those resources. Scopes are the OAuth way to explicitly 447 manage the power associated with an access token. A scope can be 448 controlled by the authorization server and/or the end-user in order 449 to limit access to resources for OAuth clients these parties deem 450 less secure or trustworthy. Optionally, the client can request the 451 scope to apply to the token but only for lesser scope than would 452 otherwise be granted, e.g. to reduce the potential impact if this 453 token is sent over non secure channels. A scope is typically 454 complemented by a restriction on a token's lifetime. 456 3.1.2. Expires_In 458 Expires_In allows an authorization server (based on its policies or 459 on behalf of the end-user) to limit the lifetime of the access token. 460 This mechanisms can be used to issue short-living tokens to OAuth 461 clients the authorization server deems less secure or where sending 462 tokens over non secure channels. 464 3.2. Access Token 466 An access token is used by a client to access a resource. Access 467 tokens typically have short life-spans (minutes or hours) that cover 468 typical session lifetimes. An access token may be refreshed through 469 the use of a refresh token. The short lifespan of an access token in 470 combination with the usage of refresh tokens enables the possibility 471 of passive revocation of access authorization on the expiry of the 472 current access token. 474 3.3. Refresh Token 476 A refresh token represents a long-lasting authorization of a certain 477 client to access resources on behalf of a resource owner. Such 478 tokens are exchanged between client and authorization server, only. 479 Clients use this kind of token to obtain ("refresh") new access 480 tokens used for resource server invocations. 482 A refresh token, coupled with a short access token lifetime, can be 483 used to grant longer access to resources without involving end user 484 authorization. This offers an advantage where resource servers and 485 authorization servers are not the same entity, e.g. in a distributed 486 environment, as the refresh token is always exchanged at the 487 authorization server. The authorization server can revoke the 488 refresh token at any time causing the granted access to be revoked 489 once the current access token expires. Because of this, a short 490 access token lifetime is important if timely revocation is a high 491 priority. 493 The refresh token is also a secret bound to the client identifier and 494 client instance which originally requested the authorization and 495 representing the original resource owner grant. This is ensured by 496 the authorization process as follows: 498 1. The resource owner and user-agent safely deliver the 499 authorization code to the client instance in first place. 501 2. The client uses it immediately in secure transport-level 502 communications to the authorization server and then securely 503 stores the long-lived refresh token. 505 3. The client always uses the refresh token in secure transport- 506 level communications to the authorization server to get an access 507 token (and optionally rollover the refresh token). 509 So as long as the confidentiality of the particular token can be 510 ensured by the client, a refresh token can also be used as an 511 alternative means to authenticate the client instance itself.. 513 3.4. Authorization Code 515 An Authorization Code represents the intermediate result of a 516 successful end-user authorization process and is used by the client 517 to obtain access and refresh token. Authorization codes are sent to 518 the client's redirection URI instead of tokens for two purposes. 520 1. Instead of (longer-lasting) tokens, the short-lived authorization 521 code is exposed to potential attackers via URI query parameters 522 (HTTP referrer), browser cache, or log file entries. 524 2. It is much simpler to authenticate clients during the direct 525 request between client and authorization server than in the 526 context of the indirect authorization request. The later would 527 require digital signatures. 529 3.5. Redirection URI 531 A redirection URI helps to detect malicious clients and prevents 532 phishing attacks from clients attempting to trick the user into 533 believing the phisher is the client. The value of the actual 534 redirection URI used in the authorization request has to be presented 535 and is verified when an authorization code is exchanged for tokens. 536 This helps to prevent attacks, where the authorization code is 537 revealed through redirectors and counterfeit web application clients. 538 The authorization server should require public clients and 539 confidential clients using implicit grant type to pre-register their 540 redirect URIs and validate against the registered redirection URI in 541 the authorization request. 543 3.6. State parameter 545 The state parameter is used to link requests and callbacks to prevent 546 CSRF attacks where an attacker authorizes access to his own resources 547 and then tricks a users into following a redirect with the attacker's 548 token. This parameter should bind to the authenticated state in a 549 user agent and, as per the core OAuth spec, the user agent must be 550 capable of keeping it in a location accessible only by the client and 551 user agent, i.e. protected by same-origin policy 553 3.7. Client Identity 555 Authentication protocols have typically not taken into account the 556 identity of the software component acting on behalf of the end-user. 557 OAuth does this in order to increase the security level in delegated 558 authorization scenarios and because the client will be able to act 559 without the user being present. 561 OAuth uses the client identifier to collate associated request to the 562 same originator, such as 564 o a particular end-user authorization process and the corresponding 565 request on the token's endpoint to exchange the authorization code 566 for tokens or 568 o the initial authorization and issuance of a token by an end-user 569 to a particular client, and subsequent requests by this client to 570 obtain tokens without user consent (automatic processing of 571 repeated authorization) 573 The client identity may also be used by the authorization server to 574 display relevant registration information to a user when requesting 575 consent for scope requested by a particular client. The client 576 identity may be used to limit the number of request for a particular 577 client or to charge the client per request. Client Identity may 578 furthermore be useful to differentiate access by different clients, 579 e.g. in server log files. 581 OAuth defines two client types, confidential and public, based on 582 their ability to authenticate with the authorization server (i.e. 583 ability to maintain the confidentiality of their client credentials). 584 Confidential clients are capable of maintaining the confidentiality 585 of client credentials (i.e. a client secret associated with the 586 client identifier) or capable of secure client authentication using 587 other means, such as a client assertion (e.g. SAML) or key 588 cryptography. The latter is considered more secure. 590 The authorization server should determine whether the client is 591 capable of keeping its secret confidential or using secure 592 authentication. Alternatively, the end-user can verify the identity 593 of the client, e.g. by only installing trusted applications.The 594 redicrection URI can be used to prevent delivering credentials to a 595 counterfeit client after obtaining end-user authorization in some 596 cases, but can't be used to verify the client identity. 598 Clients can be categorized as follows based on the client type, 599 profile (e.g. native vs web application) and deployment model: 601 Deployment-independent client_id with pre-registered redirect_uri and 602 without client_secret Such an identity is used by multiple 603 installations of the same software package. The identity of such 604 a client can only be validated with the help of the end-user. 605 This is a viable option for native applications in order to 606 identify the client for the purpose of displaying meta information 607 about the client to the user and to differentiate clients in log 608 files. Revocation of such an identity will affect ALL deployments 609 of the respective software. 611 Deployment-independent client_id with pre-registered redirect_uri and 612 with client_secret This is an option for native applications only, 613 since web application would require different redirect URIs. This 614 category is not advisable because the client secret cannot be 615 protected appropriately (see Section 4.1.1). Due to its security 616 weaknesses, such client identities have the same trust level as 617 deployment-independent clients without secret. Revocation will 618 affect ALL deployments. 620 Deployment-specific client_id with pre-registered redirect_uri and 621 with client_secret The client registration process ensures the 622 validation of the client's properties, such as redirection URI, 623 website address, web site name, contacts. Such a client identity 624 can be utilized for all relevant use cases cited above. This 625 level can be achieved for web applications in combination with a 626 manual or user-bound registration process. Achieving this level 627 for native applications is much more difficult. Either the 628 installation of the application is conducted by an administrator, 629 who validates the client's authenticity, or the process from 630 validating the application to the installation of the application 631 on the device and the creation of the client credentials is 632 controlled end-to-end by a single entity (e.g. application market 633 provider). Revocation will affect a single deployment only. 635 Deployment-specific client_id with client_secret without validated 636 properties Such a client can be recognized by the authorization 637 server in transactions with subsequent requests (e.g. 638 authorization and token issuance, refresh token issuance and 639 access token refreshment). The authorization server cannot assure 640 any property of the client to end-users. Automatic processing of 641 re-authorizations could be allowed as well. Such client 642 credentials can be generated automatically without any validation 643 of client properties, which makes it another option especially for 644 native applications. Revocation will affect a single deployment 645 only. 647 4. Security Threat Model 649 This section gives a comprehensive threat model of OAuth 2.0. 650 Threats are grouped first by attacks directed against an OAuth 651 component, which are client, authorization server, and resource 652 server. Subsequently, they are grouped by flow, e.g. obtain token or 653 access protected resources. Every countermeasure description refers 654 to a detailed description in Section 5. 656 4.1. Clients 658 This section describes possible threats directed to OAuth clients. 660 4.1.1. Threat: Obtain Client Secrets 662 The attacker could try to get access to the secret of a particular 663 client in order to: 665 o replay its refresh tokens and authorization codes, or 667 o obtain tokens on behalf of the attacked client with the privileges 668 of that client. 670 The resulting impact would be: 672 o Client authentication of access to authorization server can be 673 bypassed 675 o Stolen refresh tokens or authorization codes can be replayed 677 Depending on the client category, the following attacks could be 678 utilized to obtain the client secret. 680 Attack: Obtain Secret From Source Code or Binary: 682 This applies for all client types. For open source projects, secrets 683 can be extracted directly from source code in their public 684 repositories. Secrets can be extracted from application binaries 685 just as easily when published source is not available to the 686 attacker. Even if an application takes significant measures to 687 obfuscate secrets in their application distribution one should 688 consider that the secret can still be reverse-engineered by anyone 689 with access to a complete functioning application bundle or binary. 691 Countermeasures: 693 o Don't issue secrets to public clients or clients with 694 inappropriate security policy - Section 5.2.3.1 696 o Public clients require user consent - Section 5.2.3.2 698 o Use deployment-specific client secrets - Section 5.2.3.4 700 o Client secret revocation - Section 5.2.3.6 701 Attack: Obtain a Deployment-Specific Secret: 703 An attacker may try to obtain the secret from a client installation, 704 either from a web site (web server) or a particular devices (native 705 application). 707 Countermeasures: 709 o Web server: apply standard web server protection measures (for 710 config files and databases) - Section 5.3.2 712 o Native applications: Store secrets in a secure local storage - 713 Section 5.3.3 715 o Client secret revocation - Section 5.2.3.6 717 4.1.2. Threat: Obtain Refresh Tokens 719 Depending on the client type, there are different ways refresh tokens 720 may be revealed to an attacker. The following sub-sections give a 721 more detailed description of the different attacks with respect to 722 different client types and further specialized countermeasures. 723 Before detailing those threats, here are some generally applicable 724 countermeasures: 726 o The authorization server should validate the client id associated 727 with the particular refresh token with every refresh request- 728 Section 5.2.2.2 730 o Limited scope tokens - Section 5.1.5.1 732 o Refresh token revocation - Section 5.2.2.4 734 o Client secret revocation - Section 5.2.3.6 736 o Refresh tokens can automatically be replaced in order to detect 737 unauthorized token usage by another party (Refresh Token Rotation) 738 - Section 5.2.2.3 740 Attack: Obtain Refresh Token from Web application: 742 An attacker may obtain the refresh tokens issued to a web application 743 by way of overcoming the web server's security controls. Impact: 744 Since a web application manages the user accounts of a certain site, 745 such an attack would result in an exposure of all refresh tokens on 746 that side to the attacker. 748 Countermeasures: 750 o Standard web server protection measures - Section 5.3.2 752 o Use strong client authentication (e.g. client_assertion / 753 client_token), so the attacker cannot obtain the client secret 754 required to exchange the tokens - Section 5.2.3.7 756 Attack: Obtain Refresh Token from Native clients: 758 On native clients, leakage of a refresh token typically affects a 759 single user, only. 761 Read from local file system: The attacker could try get file system 762 access on the device and read the refresh tokens. The attacker could 763 utilize a malicious application for that purpose. 765 Countermeasures: 767 o Store secrets in a secure storage - Section 5.3.3 769 o Utilize device lock to prevent unauthorized device access - 770 Section 5.3.4 772 Attack: Steal device: 774 The host device (e.g. mobile phone) may be stolen. In that case, the 775 attacker gets access to all applications under the identity of the 776 legitimate user. 778 Countermeasures: 780 o Utilize device lock to prevent unauthorized device access - 781 Section 5.3.4 783 o Where a user knows the device has been stolen, they can revoke the 784 affected tokens - Section 5.2.2.4 786 Attack: Clone Device: 788 All device data and applications are copied to another device. 789 Applications are used as-is on the target device. 791 Countermeasures: 793 o Utilize device lock to prevent unauthorized device access - 794 Section 5.3.4 796 o Combine refresh token request with device identification - 797 Section 5.2.2.5 799 o Refresh Token Rotation - Section 5.2.2.3 801 o Where a user knows the device has been cloned, they can use this 802 countermeasure - Refresh Token Revocation - Section 5.2.2.4 804 4.1.3. Threat: Obtain Access Tokens 806 Depending on the client type, there are different ways access tokens 807 may be revealed to an attacker. Access tokens could be stolen from 808 the device if the application stores them in a storage, which is 809 accessible to other applications. 811 Impact: Where the token is a bearer token and no additional mechanism 812 is used to identify the client, the attacker can access all resources 813 associated with the token and its scope. 815 Countermeasures: 817 o Keep access tokens in transient memory and limit grants: 818 Section 5.1.6 820 o Limited scope tokens - Section 5.1.5.1 822 o Keep access tokens in private memory or apply same protection 823 means as for refresh tokens - Section 5.2.2 825 o Keep access token lifetime short - Section 5.1.5.3 827 4.1.4. Threat: End-user credentials phished using compromised or 828 embedded browser 830 A malicious application could attempt to phish end-user passwords by 831 misusing an embedded browser in the end-user authorization process, 832 or by presenting its own user-interface instead of allowing trusted 833 system browser to render the authorization user interface. By doing 834 so, the usual visual trust mechanisms may be bypassed (e.g. TLS 835 confirmation, web site mechanisms). By using an embedded or internal 836 client application user interface, the client application has access 837 to additional information it should not have access to (e.g. uid/ 838 password). 840 Impact: If the client application or the communication is 841 compromised, the user would not be aware and all information in the 842 authorization exchange could be captured such as username and 843 password. 845 Countermeasures: 847 o The OAuth flow is designed so that client applications never need 848 to know user passwords. Client applications should avoid directly 849 asking users for the their credentials. In addition, end users 850 could be educated about phishing attacks and best practices, such 851 as only accessing trusted clients, as OAuth does not provide any 852 protection against malicious applications and the end user is 853 solely responsible for the trustworthiness of any native 854 application installed. 856 o Client applications could be validated prior to publication in an 857 application market for users to access. That validation is out of 858 scope for OAuth but could include validating that the client 859 application handles user authentication in an appropriate way. 861 o Client developers should not write client applications that 862 collect authentication information directly from users and should 863 instead delegate this task to a trusted system component, e.g. the 864 system-browser. 866 4.1.5. Threat: Open Redirectors on client 868 An open redirector is an endpoint using a parameter to automatically 869 redirect a user-agent to the location specified by the parameter 870 value without any validation. If the authorization server allows the 871 client to register only part of the redirection URI, an attacker can 872 use an open redirector operated by the client to construct a 873 redirection URI that will pass the authorization server validation 874 but will send the authorization code or access token to an endpoint 875 under the control of the attacker. 877 Impact: An attacker could gain access to authorization codes or 878 access tokens 880 Countermeasure 882 o require clients to register full redirection URI Section 5.2.3.5 884 4.2. Authorization Endpoint 885 4.2.1. Threat: Password phishing by counterfeit authorization server 887 OAuth makes no attempt to verify the authenticity of the 888 Authorization Server. A hostile party could take advantage of this 889 by intercepting the Client's requests and returning misleading or 890 otherwise incorrect responses. This could be achieved using DNS or 891 ARP spoofing. Wide deployment of OAuth and similar protocols may 892 cause Users to become inured to the practice of being redirected to 893 websites where they are asked to enter their passwords. If Users are 894 not careful to verify the authenticity of these websites before 895 entering their credentials, it will be possible for attackers to 896 exploit this practice to steal Users' passwords. 898 Countermeasures: 900 o Authorization servers should consider such attacks when developing 901 services based on OAuth, and should require transport-layer 902 security for any requests where the authenticity of the 903 authorization server or of request responses is an issue (see 904 Section 5.1.2). 906 o Authorization servers should attempt to educate Users about the 907 risks phishing attacks pose, and should provide mechanisms that 908 make it easy for users to confirm the authenticity of their sites. 910 4.2.2. Threat: User unintentionally grants too much access scope 912 When obtaining end user authorization, the end-user may not 913 understand the scope of the access being granted and to whom or they 914 may end up providing a client with access to resources which should 915 not be permitted. 917 Countermeasures: 919 o Explain the scope (resources and the permissions) the user is 920 about to grant in a understandable way - Section 5.2.4.2 922 o Narrow scope based on client - When obtaining end user 923 authorization and where the client requests scope, the 924 authorization server may want to consider whether to honour that 925 scope based on who the client is. That decision is between the 926 client and authorization server and is outside the scope of this 927 spec. The authorization server may also want to consider what 928 scope to grant based on the client type, e.g. providing lower 929 scope to public clients. - Section 5.1.5.1 931 4.2.3. Threat: Malicious client obtains existing authorization by fraud 933 Authorization servers may wish to automatically process authorization 934 requests from clients which have been previously authorized by the 935 user. When the user is redirected to the authorization server's end- 936 user authorization endpoint to grant access, the authorization server 937 detects that the user has already granted access to that particular 938 client. Instead of prompting the user for approval, the 939 authorization server automatically redirects the user back to the 940 client. 942 A malicious client may exploit that feature and try to obtain such an 943 authorization code instead of the legitimate client. 945 Countermeasures: 947 o Authorization servers should not automatically process repeat 948 authorizations to public clients or unless the client is validated 949 using a pre-registered redirect URI (Section 5.2.3.5 ) 951 o Authorization servers can mitigate the risks associated with 952 automatic processing by limiting the scope of Access Tokens 953 obtained through automated approvals - Section 5.1.5.1 955 4.2.4. Threat: Open redirector 957 An attacker could use the end-user authorization endpoint and the 958 redirection URI parameter to abuse the authorization server as an 959 open redirector. An open redirector is an endpoint using a parameter 960 to automatically redirect a user-agent to the location specified by 961 the parameter value without any validation. 963 Impact: An attacker could utilize a user's trust in your 964 authorization server to launch a phishing attack. 966 Countermeasure 968 o require clients to register full redirection URI Section 5.2.3.5 970 o don't redirect to redirection URI, if client identity or 971 redirection URI can't be verified Section 5.2.3.5 973 4.3. Token endpoint 974 4.3.1. Threat: Eavesdropping access tokens 976 Attackers may attempts to eavesdrop access token on transit from the 977 authorization server to the client. 979 Impact: The attacker is able to access all resources with the 980 permissions covered by the scope of the particular access token. 982 Countermeasures: 984 o As per the core OAuth spec, the authorization servers must ensure 985 that these transmissions are protected using transport-layer 986 mechanisms such as TLS or SSL (see Section 5.1.1). 988 o If end-to-end confidentiality cannot be guaranteed, reducing scope 989 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 990 tokens can be used to reduce the damage in case of leaks. 992 4.3.2. Threat: Obtain access tokens from authorization server database 994 This threat is applicable if the authorization server stores access 995 tokens as handles in a database. An attacker may obtain access 996 tokens from the authorization server's database by gaining access to 997 the database or launching a SQL injection attack. Impact: disclosure 998 of all access tokens 1000 Countermeasures: 1002 o System security measures - Section 5.1.4.1.1 1004 o Store access token hashes only - Section 5.1.4.1.3 1006 o Standard SQL injection Countermeasures - Section 5.1.4.1.2 1008 4.3.3. Threat: Obtain client credentials over non secure transport 1010 An attacker could attempt to eavesdrop the transmission of client 1011 credentials between client and server during the client 1012 authentication process or during OAuth token requests. Impact: 1013 Revelation of a client credential enabling the possibility for 1014 phishing or imitation of a client service. 1016 Countermeasures: 1018 o Implement transport security through - Section 5.1.1 1020 o Alternative authentication means, which do not require to send 1021 plaintext credentials over the wire (Examples: Digest 1022 authentication) 1024 4.3.4. Threat: Obtain client secret from authorization server database 1026 An attacker may obtain valid client_id/secret combinations from the 1027 authorization server's database by gaining access to the database or 1028 launching a SQL injection attack. Impact: disclosure of all 1029 client_id/secret combinations. This allows the attacker to act on 1030 behalf of legitimate clients. 1032 Countermeasures: 1034 o Ensure proper handling of credentials as per Credential Storage 1035 Protection. 1037 4.3.5. Threat: Obtain client secret by online guessing 1039 An attacker may try to guess valid client_id/secret pairs. Impact: 1040 disclosure of single client_id/secret pair. 1042 Countermeasures: 1044 o High entropy of secrets - Section 5.1.4.2.2 1046 o Lock accounts - Section 5.1.4.2.3 1048 o Use Strong Client Authentication - Section 5.2.3.7 1050 4.3.6. Threat: DoS on dynamic client secret creation 1052 If an authorization servers includes a nontrivial amount of entropy 1053 in client secrets and if the authorization server automatically 1054 grants them, an attacker could exhaust the pool by repeatedly 1055 applying for them. 1057 Countermeasures: 1059 o The authorization server should consider some verification step 1060 for new clients. The authorization server should include a 1061 nontrivial amount of entropy in client secrets. 1063 4.4. Obtaining Authorization 1065 This section covers threats which are specific to certain flows 1066 utilized to obtain access tokens. Each flow is characterized by 1067 response types and/or grant types on the end-user authorization and 1068 tokens endpoint, respectively. 1070 4.4.1. Authorization Code 1072 4.4.1.1. Threat: Eavesdropping or leaking authorization codes 1074 An attacker could try to eavesdrop transmission of the authorization 1075 code between authorization server and client. Furthermore, 1076 authorization codes are passed via the browser which may 1077 unintentionally leak those codes to untrusted web sites and attackers 1078 by different ways: 1080 o Referrer headers: browsers frequently pass a "referrer" header 1081 when a web page embeds content, or when a user travels from one 1082 web page to another web page. These referrer headers may be sent 1083 even when the origin site does not trust the destination site. 1084 The referrer header is commonly logged for traffic analysis 1085 purposes. 1087 o Request logs: web server request logs commonly include query 1088 parameters on requests. 1090 o Open redirectors: web sites sometimes need to send users to 1091 another destination via a redirector. Open redirectors pose a 1092 particular risk to web-based delegation protocols because the 1093 redirector can leak verification codes to untrusted destination 1094 sites. 1096 o Browser history: web browsers commonly record visited URLs in the 1097 browser history. Another user of the same web browser may be able 1098 to view URLs that were visited by previous users. 1100 Note: A description of a similar attacks on the SAML protocol can be 1101 found at http://www.oasis-open.org/committees/download.php/3405/ 1102 oasis-sstc-saml-bindings-1.1.pdf (S.4.1.1.9.1), http:// 1103 www.thomasgross.net/publications/papers/ 1104 GroPfi2006-SAML2_Analysis_Janus.WSSS_06.pdf and http:// 1105 www.oasis-open.org/committees/download.php/11191/ 1106 sstc-gross-sec-analysis-response-01.pdf. 1108 Countermeasures: 1110 o As per the core OAuth spec, the authorization server as well as 1111 the client must ensure that these transmissions are protected 1112 using transport-layer mechanisms such as TLS or SSL (see 1113 Section 5.1.1). 1115 o The authorization server will require the client to authenticate 1116 wherever possible, so the binding of the authorization code to a 1117 certain client can be validated in a reliable way (see 1118 Section 5.2.4.4). 1120 o Limited duration of authorization codes - Section 5.1.5.3 1122 o The authorization server should enforce a one time usage 1123 restriction (see Section 5.1.5.4). 1125 o If an Authorization Server observes multiple attempts to redeem a 1126 authorization code, the Authorization Server may want to revoke 1127 all tokens granted based on the authorization code (see 1128 Section 5.2.1.1). 1130 o In the absence of these countermeasures, reducing scope 1131 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1132 tokens can be used to reduce the damage in case of leaks. 1134 o The client server may reload the target page of the redirection 1135 URI in order to automatically cleanup the browser cache. 1137 4.4.1.2. Threat: Obtain authorization codes from authorization server 1138 database 1140 This threat is applicable if the authorization server stores 1141 authorization codes as handles in a database. An attacker may obtain 1142 authorization codes from the authorization server's database by 1143 gaining access to the database or launching a SQL injection attack. 1144 Impact: disclosure of all authorization codes, most likely along with 1145 the respective redirect_uri and client_id values. 1147 Countermeasures: 1149 o Best practices for credential storage protection should be 1150 employed - Section 5.1.4.1 1152 o System security measures - Section 5.1.4.1.1 1154 o Store access token hashes only - Section 5.1.4.1.3 1156 o Standard SQL injection countermeasures - Section 5.1.4.1.2 1158 4.4.1.3. Threat: Online guessing of authorization codes 1160 An attacker may try to guess valid authorization code values and send 1161 it using the grant type "code" in order to obtain a valid access 1162 token. 1164 Impact: disclosure of single access token, probably also associated 1165 refresh token. 1167 Countermeasures: 1169 o Handle-based tokens must use high entropy: Section 5.1.5.11 1171 o Assertion-based tokens should be signed: Section 5.1.5.9 1173 o Authenticate the client, adds another value the attacker has to 1174 guess - Section 5.2.3.4 1176 o Binding of authorization code to redirection URI, adds another 1177 value the attacker has to guess - Section 5.2.4.5 1179 o Short expiration time - Section 5.1.5.3 1181 4.4.1.4. Threat: Malicious client obtains authorization 1183 A malicious client could counterfeit a valid client and obtain an 1184 access authorization that way. The malicious client could even 1185 utilize screen scraping techniques in order to simulate the user 1186 consent in the authorization flow. 1188 Assumption: It is not the task of the authorization server to protect 1189 the end-user's device from malicious software. This is the 1190 responsibility of the platform running on the particular device 1191 probably in cooperation with other components of the respective 1192 ecosystem (e.g. an application management infrastructure). The sole 1193 responsibility of the authorization server is to control access to 1194 the end-user's resources living in resource servers and to prevent 1195 unauthorized access to them. Based on this assumption, the following 1196 countermeasures are available to cope with the threat. 1198 Countermeasures: 1200 o The authorization server should authenticate the client, if 1201 possible (see Section 5.2.3.4). Note: the authentication takes 1202 place after the end-user has authorized the access. 1204 o The authorization server should validate the client's redirection 1205 URI against the pre-registered redirection URI, if one exists (see 1206 Section 5.2.3.5). Note: An invalid redirect URI indicates an 1207 invalid client whereas a valid redirect URI not neccesserily 1208 indicates a valid client. The level of confidence depends on the 1209 client type. For web applications, the confidence is high since 1210 the redirect URI refers to the globally unique network endpoint of 1211 this application whose address is also validated using HTTPS 1212 server authentication by the user agent. In contrast for native 1213 clients, the redirect URI typically refers to device local 1214 resources, e.g. a custom scheme. So a malicious client on a 1215 particular device can use the valid redirect URI the legitimate 1216 client uses on all other devices. 1218 o After authenticating the end-user, the authorization server should 1219 ask him/her for consent. In this context, the user should be 1220 explained the purpose, scope, and duration of the authorization. 1221 Moreover, the authorization server should show the user any 1222 identity information it has for that client. It is up to the user 1223 to validate the binding of this data to the particular application 1224 (e.g. Name) and to approve the authorization request. (see 1225 Section 5.2.4.3). 1227 o The authorization server should not perform automatic re- 1228 authorizations for clients it is unable to reliably authenticate 1229 or validate (see Section 5.2.4.1). 1231 o If the authorization server automatically authenticates the end- 1232 user, it may nevertheless require some user input in order to 1233 prevent screen scraping. Examples are CAPTCHAs or user-specific 1234 secrets like PIN codes. 1236 o The authorization server may also limit the scope of tokens it 1237 issues to clients it cannot reliably authenticate (see 1238 Section 5.1.5.1). 1240 4.4.1.5. Threat: Authorization code phishing 1242 A hostile party could impersonate the client site and get access to 1243 the authorization code. This could be achieved using DNS or ARP 1244 spoofing. This applies to clients, which are web applications, thus 1245 the redirect URI is not local to the host where the user's browser is 1246 running. 1248 Impact: This affects web applications and may lead to a disclosure of 1249 authorization codes and, potentially, the corresponding access and 1250 refresh tokens. 1252 Countermeasures: 1254 It is strongly recommended that one of the following countermeasures 1255 is utilized in order to prevent this attack: 1257 o The redirection URI of the client should point to a HTTPS 1258 protected endpoint and the browser should be utilized to 1259 authenticate this redirection URI using server authentication (see 1260 Section 5.1.2). 1262 o The authorization server should require the client to be 1263 authenticated, i.e. confidential client, so the binding of the 1264 authorization code to a certain client can be validated in a 1265 reliable way (see Section 5.2.4.4). 1267 4.4.1.6. Threat: User session impersonation 1269 A hostile party could impersonate the client site and impersonate the 1270 user's session on this client. This could be achieved using DNS or 1271 ARP spoofing. This applies to clients, which are web applications, 1272 thus the redirect URI is not local to the host where the user's 1273 browser is running. 1275 Impact: An attacker who intercepts the authorization code as it is 1276 sent by the browser to the callback endpoint can gain access to 1277 protected resources by submitting the authorization code to the 1278 client. The client will exchange the authorization code for an 1279 access token and use the access token to access protected resources 1280 for the benefit of the attacker, delivering protected resources to 1281 the attacker, or modifying protected resources as directed by the 1282 attacker. If OAuth is used by the client to delegate authentication 1283 to a social site (e.g. as in the implementation of the "Facebook 1284 Login" button), the attacker can use the intercepted authorization 1285 code to log in to the client as the user. 1287 Note: Authenticating the client during authorization code exchange 1288 will not help to detect such an attack as it is the legitimate client 1289 that obtains the tokens. 1291 Countermeasures: 1293 o In order to prevent an attacker from impersonating the end-users 1294 session, the redirection URI of the client should point to a HTTPS 1295 protected endpoint and the browser should be utilized to 1296 authenticate this redirection URI using server authentication (see 1297 Section 5.1.2) 1299 4.4.1.7. Threat: Authorization code leakage through counterfeit client 1301 The attack leverages the authorization code grant type in an attempt 1302 to get another user (victim) to log-in, authorize access to his/her 1303 resources, and subsequently obtain the authorization code and inject 1304 it into a client application using the attacker's account. The goal 1305 is to associate an access authorization for resources of the victim 1306 with the user account of the attacker on a client site. 1308 The attacker abuses an existing client application and combines it 1309 with his own counterfeit client web site. The attack depends on the 1310 victim expecting the client application to request access to a 1311 certain resource server. The victim, seeing only a normal request 1312 from an expected application, approves the request. The attacker 1313 then uses the victim's authorization to gain access to the 1314 information unknowingly authorized by the victim. 1316 The attacker conducts the following flow: 1318 1. The attacker accesses the client web site (or application) and 1319 initiates data access to a particular resource server. The 1320 client web site in turn initiates an authorization request to the 1321 resource server's authorization server. Instead of proceeding 1322 with the authorization process, the attacker modifies the 1323 authorization server end-user authorization URL as constructed by 1324 the client to include a redirection URI parameter referring to a 1325 web site under his control (attacker's web site). 1327 2. The attacker tricks another user (the victim) to open that 1328 modified end-user authorization URI and to authorize access (e.g. 1329 an email link, or blog link). The way the attacker achieve that 1330 goal is out of scope. 1332 3. Having clicked the link, the victim is requested to authenticate 1333 and authorize the client site to have access. 1335 4. After completion of the authorization process, the authorization 1336 server redirects the user agent to the attacker's web site 1337 instead of the original client web site. 1339 5. The attacker obtains the authorization code from his web site by 1340 means out of scope of this document. 1342 6. He then constructs a redirection URI to the target web site (or 1343 application) based on the original authorization request's 1344 redirection URI and the newly obtained authorization code and 1345 directs his user agent to this URL. The authorization code is 1346 injected into the original client site (or application). 1348 7. The client site uses the authorization code to fetch a token from 1349 the authorization server and associates this token with the 1350 attacker's user account on this site. 1352 8. The attacker may now access the victims resources using the 1353 client site. 1355 Impact: The attackers gains access to the victim's resources as 1356 associated with his account on the client site. 1358 Countermeasures: 1360 o The attacker will need to use another redirection URI for its 1361 authorization process than the target web site because it needs to 1362 intercept the flow. So if the authorization server associates the 1363 authorization code with the redirection URI of a particular end- 1364 user authorization and validates this redirection URI with the 1365 redirection URI passed to the token's endpoint, such an attack is 1366 detected (see Section 5.2.4.5). 1368 o The authorization server may also enforce the usage and validation 1369 of pre-registered redirect URIs (see Section 5.2.3.5). This will 1370 allow for an early recognition of session fixation attempts. 1372 o For native applications, one could also consider to use 1373 deployment-specific client ids and secrets (see Section 5.2.3.4, 1374 along with the binding of authorization code to client_id (see 1375 Section 5.2.4.4), to detect such an attack because the attacker 1376 does not have access the deployment-specific secret. Thus he will 1377 not be able to exchange the authorization code. 1379 o The client may consider using other flows, which are not 1380 vulnerable to this kind of attacks such as "Implicit Grant" or 1381 "Resource Owner Password Credentials" (see Section 4.4.2 or 1382 Section 4.4.3). 1384 4.4.1.8. Threat: CSRF attack against redirect-uri 1386 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1387 requests are transmitted from a user that the website trusts or has 1388 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1389 on OAuth approvals can allow an attacker to obtain authorization to 1390 OAuth protected resources without the consent of the User. 1392 This attack works against the redirection URI used in the 1393 authorization code flow. An attacker could authorize an 1394 authorization code to their own protected resources on an 1395 authorization server. He then aborts the redirect flow back to the 1396 client on his device and tricks the victim into executing the 1397 redirect back to the client. The client receives the redirect, 1398 fetches the token(s) from the authorization server and associates the 1399 victim's client session with the resources accessible using the 1400 token. 1402 Impact: The user accesses resources on behalf of the attacker. The 1403 effective impact depends on the type of resource accessed. For 1404 example, the user may upload private items to an attacker's 1405 resources. Or when using OAuth in 3rd party login scenarios, the 1406 user may associate his client account with the attacker's identity at 1407 the external identity provider. This way the attacker could easily 1408 access the victim's data at the client by logging in from another 1409 device with his credentials at the external identity provider. 1411 Countermeasures: 1413 o The state parameter should be used to link the authorization 1414 request with the redirection URI used to deliver the access token. 1415 Section 5.3.6 1417 o Client developers and end-user can be educated not follow 1418 untrusted URLs. 1420 4.4.1.9. Threat: Clickjacking attack against authorization 1422 With Clickjacking, a malicious site loads the target site in a 1423 transparent iframe overlaid on top of a set of dummy buttons which 1424 are carefully constructed to be placed directly under important 1425 buttons on the target site. When a user clicks a visible button, 1426 they are actually clicking a button (such as an "Authorize" button) 1427 on the hidden page. 1429 Impact: An attacker can steal a user's authentication credentials and 1430 access their resources 1432 Countermeasure 1434 o Native applications should use external browsers instead of 1435 embedding browsers in a web view when requesting end-user 1436 authorization 1438 o For newer browsers, avoidance of iFrames can be enforced server 1439 side by using the X-FRAME-OPTION header - Section 5.2.2.6 1441 o For older browsers, javascript framebusting techniques can be used 1442 but may not be effective in all browsers. 1444 4.4.1.10. Threat: Resource Owner Impersonation 1446 When a client requests access to protected resources, the 1447 authorization flow normally involves the resource owner's explicit 1448 response to the access request, either granting or denying access to 1449 the protected resources. A malicious client can exploit knowledge of 1450 the structure of this flow in order to gain authorization without the 1451 resource owner's consent, by transmitting the necessary requests 1452 programmatically, and simulating the flow against the authorization 1453 server. That way, the client may gain access to the victims 1454 resources without her approval. An authorization server will be 1455 vulnerable to this threat, if it uses non-interactive authentication 1456 mechanisms or split the authorization flow across multiple pages. 1458 The malicious client might embed a hidden HTML user agent, interpret 1459 the HTML forms sent by the authorization server, and automatically 1460 answer with the corresponding form post requests. As a pre- 1461 requisite, the attacker must be able to execute the authorization 1462 process in the context of an already authenticated session of the 1463 resource owner with the authorization server. There are different 1464 ways to achieve this: 1466 o The malicious client could abuse an existing session in an 1467 external browser or cross-browser cookies on the particular 1468 device. 1470 o It could also request authorization for a particular scope and 1471 silently abuse the resulting session in his browser instance to 1472 "silently" request another scope. 1474 o Alternatively, the attacker might exploit an authorization 1475 server's ability to authenticate the resource owner automatically 1476 and without user interactions, e.g. based on certificates. 1478 In all cases, such an attack is limited to clients running on the 1479 victim's device, within the user agent or as native app. 1481 Please note: Such attacks cannot be prevented using CSRF 1482 countermeasures, since the attacker just "executes" the URLs as 1483 prepared by the authorization server including any nonce etc. 1485 Countermeasures: 1487 Authorization servers should decide, based on an analysis of the risk 1488 associated with this threat, whether to assume, detect, or to prevent 1489 this threat. 1491 In order to prevent such an attack, the authorization server may 1492 force an user interaction based on non-predictable input values as 1493 part of the user consent approval. The authorization server could 1495 o combine password authentication and user consent in a single form, 1497 o make use of CAPTCHAs, or 1499 o or use one-time secrets send out of bound to the resource owner 1500 (e.g. via text or instance message). 1502 Alternatively in order to allow the resource owner to detect abuse, 1503 the authorization server could notify the resource owner of any 1504 approval by appropriate means, e.g. text or instant message or 1505 e-Mail. 1507 4.4.1.11. Threat: DoS, Exhaustion of resources attacks 1509 If an authorization server includes a nontrivial amount of entropy in 1510 authorization codes or access tokens (limiting the number of possible 1511 codes/tokens) and automatically grants either without user 1512 intervention and has no limit on code or access tokens per user, an 1513 attacker could exhaust the pool by repeatedly directing user(s) 1514 browser to request code or access tokens. This is because more 1515 entropy means a larger number of tokens can be issued. 1517 Countermeasures: 1519 o The authorization server should consider limiting the number of 1520 access tokens granted per user. The authorization server should 1521 include a nontrivial amount of entropy in authorization codes. 1523 4.4.1.12. Threat: DoS using manufactured authorization codes 1525 An attacker who owns a botnet can locate the redirect URIs of clients 1526 that listen on HTTP, access them with random authorization codes, and 1527 cause a large number of HTTPS connections to be concentrated onto the 1528 authorization server. This can result in a DoS attack on the 1529 authorization server. 1531 This attack can still be effective even when CSRF defense/the 'state' 1532 parameter are deployed on the client side. With such a defense, the 1533 attacker might need to incur an additional HTTP request to obtain a 1534 valid CSRF code/ state parameter. This apparently cuts down the 1535 effectiveness of the attack by a factor of 2. However, if the HTTPS/ 1536 HTTP cost ratio is higher than 2 (the cost factor is estimated to be 1537 around 3.5x at 1538 ) the 1539 attacker still achieves a magnification of resource utilization at 1540 the expense of the authorization server. 1542 Impact: There are a few effects that the attacker can accomplish with 1543 this OAuth flow that they cannot easily achieve otherwise. 1545 1. Connection laundering: With the clients as the relay between the 1546 attacker and the authorization server, the authorization server 1547 learns little or no information about the identity of the 1548 attacker. Defenses such rate limiting on the offending attacker 1549 machines are less effective due to the difficulty to identify the 1550 attacking machines. Although an attacker could also launder its 1551 connections through an anonymizing systems such as Tor, the 1552 effectiveness of that approach depends on the capacity of the 1553 annoying system. On the other hand, a potentially large number 1554 of OAuth clients could be utilized for this attack. 1556 2. Asymmetric resource utilization: The attacker incurs the cost of 1557 an HTTP connection and causes an HTTPS connection to be made on 1558 the authorization server; and the attacker can co-ordinate the 1559 timing of such HTTPS connections across multiple clients 1560 relatively easily. Although the attacker could achieve something 1561 similar, say, by including an iframe pointing to the HTTPS URL of 1562 the authorization server in an HTTP web page and lure web users 1563 to visit that page, timing attacks using such a scheme may be 1564 more difficult as it seems nontrivial to synchronize a large 1565 number of users to simultaneously visit a particular site under 1566 the attacker's control. 1568 Countermeasures 1570 o Though not a complete countermeasure by themselves, CSRF defense 1571 and the 'state' parameter created with secure random codes should 1572 be deployed on the client side. The client should forward the 1573 authorization code to the authorization server only after both the 1574 CSRF token and the 'state' parameter are validated. 1576 o If the client authenticates the user, either through a single sign 1577 on protocol ( such as OpenID / Facebook Connect ) or through local 1578 authentication, the client should suspend the access by a user 1579 account if the number of invalid authorization codes submitted by 1580 this user exceeds a certain threshold. 1582 o The authorization server should send an error response to the 1583 client reporting an invalid authorization code and rate limit or 1584 disallow connections from clients whose number of invalid requests 1585 exceeds a threshold. 1587 o The authorization server may in addition sign the authorization 1588 code using the public key from its SSL certificate, and require 1589 the client to validate the signature. To enhance interoperability 1590 between multiple clients and authorization servers, a standard 1591 procedure to create and validate the signature (including what 1592 attributes to sign) may be developed and agreed between the 1593 clients and the servers. 1595 4.4.2. Implicit Grant 1597 In the implicit grant type flow, the access token is directly 1598 returned to the client as a fragment part of the redirection URI. It 1599 is assumed that the token is not sent to the redirection URI target 1600 as HTTP user agents do not send the fragment part of URIs to HTTP 1601 servers. Thus an attacker cannot eavesdrop the access token on this 1602 communication path and It cannot leak through HTTP referee headers. 1604 4.4.2.1. Threat: Access token leak in transport/end-points 1606 This token might be eavesdropped by an attacker. The token is sent 1607 from server to client via a URI fragment of the redirection URI. If 1608 the communication is not secured or the end-point is not secured, the 1609 token could be leaked by parsing the returned URI. 1611 Impact: the attacker would be able to assume the same rights granted 1612 by the token. 1614 Countermeasures: 1616 o The authorization server should ensure confidentiality of the 1617 response from the authorization server to the client (see 1618 Section 5.1.1). 1620 4.4.2.2. Threat: Access token leak in browser history 1622 An attacker could obtain the token from the browser's history. Note 1623 this means the attacker needs access to the particular device. 1625 Countermeasures: 1627 o Shorten token duration (see Section 5.1.5.3) and reduced scope of 1628 the token may reduce the impact of that attack (see 1629 Section 5.1.5.1). 1631 o Make these requests non-cachable 1633 o Native applications can directly embed a browser widget and 1634 therewith gain full control of the cache. So the application can 1635 cleanup browser history after authorization process. 1637 4.4.2.3. Threat: Malicious client obtains authorization 1639 An malicious client could attempt to obtain a token by fraud. 1641 The same countermeasures as for Section 4.4.1.4 are applicable, 1642 except client authentication. 1644 4.4.2.4. Threat: Manipulation of scripts 1646 A hostile party could act as the client web server and replace or 1647 modify the actual implementation of the client (script). This could 1648 be achieved using DNS or ARP spoofing. This applies to clients 1649 implemented within the Web Browser in a scripting language. 1651 Impact: The attacker could obtain user credential information and 1652 assume the full identity of the user. 1654 Countermeasures: 1656 o The authorization server should authenticate the server from which 1657 scripts are obtained (see Section 5.1.2). 1659 o The client should ensure that scripts obtained have not been 1660 altered in transport (see Section 5.1.1). 1662 o Introduce one time per-use secrets (e.g. client_secret) values 1663 that can only be used by scripts in a small time window once 1664 loaded from a server. The intention would be to reduce the 1665 effectiveness of copying client-side scripts for re-use in an 1666 attackers modified code. 1668 4.4.2.5. Threat: CSRF attack against redirect-uri 1670 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1671 requests are transmitted from a user that the website trusts or has 1672 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1673 on OAuth approvals can allow an attacker to obtain authorization to 1674 OAuth protected resources without the consent of the User. 1676 This attack works against the redirection URI used in the implicit 1677 grant flow. An attacker could acquire an access token to their own 1678 protected resources. He could then construct a redirection URI and 1679 embed their access token in that URI. If he can trick the user into 1680 following the redirection URI and the client does not have protection 1681 against this attack, the user may have the attacker's access token 1682 authorized within their client. 1684 Impact: The user accesses resources on behalf of the attacker. The 1685 effective impact depends on the type of resource accessed. For 1686 example, the user may upload private items to an attacker's 1687 resources. Or when using OAuth in 3rd party login scenarios, the 1688 user may associate his client account with the attacker's identity at 1689 the external identity provider. This way the attacker could easily 1690 access the victim's data at the client by logging in from another 1691 device with his credentials at the external identity provider. 1693 Countermeasures: 1695 o The state parameter should be used to link the authorization 1696 request with the redirection URI used deliver the access token. 1697 This will ensure the client is not tricked into completing any 1698 redirect callback unless it is linked to an authorization request 1699 the client initiated. The state parameter should be unguessable 1700 and the client should be capable of keeping the state parameter 1701 secret. 1703 o Client developers and end-user can be educated not follow 1704 untrusted URLs. 1706 4.4.3. Resource Owner Password Credentials 1708 The "Resource Owner Password Credentials" grant type (see 1709 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration 1710 reasons, allows a client to request an access token using an end- 1711 users user-id and password along with its own credential. This grant 1712 type has higher risk because it maintains the uid/password anti- 1713 pattern. Additionally, because the user does not have control over 1714 the authorization process, clients using this grant type are not 1715 limited by scope, but instead have potentially the same capabilities 1716 as the user themselves. As there is no authorization step, the 1717 ability to offer token revocation is bypassed. 1719 Impact: The resource server can only differentiate scope based on the 1720 access token being associated with a particular client. The client 1721 could also acquire long-living tokens and pass them up to a attacker 1722 web service for further abuse. The client, eavesdroppers, or end- 1723 points could eavesdrop user id and password. 1725 Countermeasures: 1727 o Except for migration reasons, minimize use of this grant type 1729 o The authorization server should validate the client id associated 1730 with the particular refresh token with every refresh request - 1731 Section 5.2.2.2 1733 o As per the core Oauth spec, the authorization server must ensure 1734 that these transmissions are protected using transport-layer 1735 mechanisms such as TLS or SSL (see Section 5.1.1). 1737 4.4.3.1. Threat: Accidental exposure of passwords at client site 1739 If the client does not provide enough protection, an attacker or 1740 disgruntled employee could retrieve the passwords for a user. 1742 Countermeasures: 1744 o Use other flows, which do not rely on the client's cooperation for 1745 secure resource owner credential handling 1747 o Use digest authentication instead of plaintext credential 1748 processing 1750 o Obfuscation of passwords in logs 1752 4.4.3.2. Threat: Client obtains scopes without end-user authorization 1754 All interaction with the resource owner is performed by the client. 1755 Thus it might, intentionally or unintentionally, happen that the 1756 client obtains a token with scope unknown for or unintended by the 1757 resource owner. For example, the resource owner might think the 1758 client needs and acquires read-only access to its media storage only 1759 but the client tries to acquire an access token with full access 1760 permissions. 1762 Countermeasures: 1764 o Use other flows, which do not rely on the client's cooperation for 1765 resource owner interaction 1767 o The authorization server may generally restrict the scope of 1768 access tokens (Section 5.1.5.1) issued by this flow. If the 1769 particular client is trustworthy and can be authenticated in a 1770 reliable way, the authorization server could relax that 1771 restriction. Resource owners may prescribe (e.g. in their 1772 preferences) what the maximum scope is for clients using this 1773 flow. 1775 o The authorization server could notify the resource owner by an 1776 appropriate media, e.g. e-Mail, of the grant issued (see 1777 Section 5.1.3). 1779 4.4.3.3. Threat: Client obtains refresh token through automatic 1780 authorization 1782 All interaction with the resource owner is performed by the client. 1783 Thus it might, intentionally or unintentionally, happen that the 1784 client obtains a long-term authorization represented by a refresh 1785 token even if the resource owner did not intend so. 1787 Countermeasures: 1789 o Use other flows, which do not rely on the client's cooperation for 1790 resource owner interaction 1792 o The authorization server may generally refuse to issue refresh 1793 tokens in this flow (see Section 5.2.2.1). If the particular 1794 client is trustworthy and can be authenticated in a reliable way 1795 (see client authentication), the authorization server could relax 1796 that restriction. Resource owners may allow or deny (e.g. in 1797 their preferences) to issue refresh tokens using this flow as 1798 well. 1800 o The authorization server could notify the resource owner by an 1801 appropriate media, e.g. e-Mail, of the refresh token issued (see 1802 Section 5.1.3). 1804 4.4.3.4. Threat: Obtain user passwords on transport 1806 An attacker could attempt to eavesdrop the transmission of end-user 1807 credentials with the grant type "password" between client and server. 1809 Impact: disclosure of a single end-users password. 1811 Countermeasures: 1813 o Confidentiality of Requests - Section 5.1.1 1815 o alternative authentication means, which do not require to send 1816 plaintext credentials over the wire (Examples: Digest 1817 authentication) 1819 4.4.3.5. Threat: Obtain user passwords from authorization server 1820 database 1822 An attacker may obtain valid username/password combinations from the 1823 authorization server's database by gaining access to the database or 1824 launching a SQL injection attack. 1826 Impact: disclosure of all username/password combinations. The impact 1827 may exceed the domain of the authorization server since many users 1828 tend to use the same credentials on different services. 1830 Countermeasures: 1832 o Credential storage protection can be employed - Section 5.1.4.1 1834 4.4.3.6. Threat: Online guessing 1836 An attacker may try to guess valid username/password combinations 1837 using the grant type "password". 1839 Impact: Revelation of a single username/password combination. 1841 Countermeasures: 1843 o Password policy - Section 5.1.4.2.1 1845 o Lock accounts - Section 5.1.4.2.3 1847 o Tar pit - Section 5.1.4.2.4 1849 o CAPTCHA - Section 5.1.4.2.5 1851 o Abandon on grant type "password" 1853 o Client authentication (see Section 5.2.3) will provide another 1854 authentication factor and thus hinder the attack. 1856 4.4.4. Client Credentials 1858 Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an 1859 identifier (not secret) combined with an additional means (such as a 1860 matching client secret) of authenticating a client. The threats to 1861 this grant type are similar to Section 4.4.3. 1863 4.5. Refreshing an Access Token 1865 4.5.1. Threat: Eavesdropping refresh tokens from authorization server 1867 An attacker may eavesdrop refresh tokens when they are transmitted 1868 from the authorization server to the client. 1870 Countermeasures: 1872 o As per the core OAuth spec, the Authorization servers must ensure 1873 that these transmissions are protected using transport-layer 1874 mechanisms such as TLS or SSL (see Section 5.1.1). 1876 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1877 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for 1878 issued access tokens can be used to reduce the damage in case of 1879 leaks. 1881 4.5.2. Threat: Obtaining refresh token from authorization server 1882 database 1884 This threat is applicable if the authorization server stores refresh 1885 tokens as handles in a database. An attacker may obtain refresh 1886 tokens from the authorization server's database by gaining access to 1887 the database or launching a SQL injection attack. 1889 Impact: disclosure of all refresh tokens 1891 Countermeasures: 1893 o Credential storage protection - Section 5.1.4.1 1895 o Bind token to client id, if the attacker cannot obtain the 1896 required id and secret - Section 5.1.5.8 1898 4.5.3. Threat: Obtain refresh token by online guessing 1900 An attacker may try to guess valid refresh token values and send it 1901 using the grant type "refresh_token" in order to obtain a valid 1902 access token. 1904 Impact: exposure of single refresh token and derivable access tokens. 1906 Countermeasures: 1908 o For handle-based designs - Section 5.1.5.11 1910 o For assertion-based designs - Section 5.1.5.9 1912 o Bind token to client id, because the attacker would guess the 1913 matching client id, too (see Section 5.1.5.8) 1915 o Authenticate the client, adds another element the attacker has to 1916 guess (see Section 5.2.3.4) 1918 4.5.4. Threat: Obtain refresh token phishing by counterfeit 1919 authorization server 1921 An attacker could try to obtain valid refresh tokens by proxying 1922 requests to the authorization server. Given the assumption that the 1923 authorization server URL is well-known at development time or can at 1924 least be obtained from a well-known resource server, the attacker 1925 must utilize some kind of spoofing in order to succeed. 1927 Countermeasures: 1929 o Server authentication (as described in Section 5.1.2) 1931 4.6. Accessing Protected Resources 1933 4.6.1. Threat: Eavesdropping access tokens on transport 1935 An attacker could try to obtain a valid access token on transport 1936 between client and resource server. As access tokens are shared 1937 secrets between authorization and resource server, they should be 1938 treated with the same care as other credentials (e.g. end-user 1939 passwords). 1941 Countermeasures: 1943 o Access tokens sent as bearer tokens, should not be sent in the 1944 clear over an insecure channel. As per the core OAuth spec, 1945 transmission of access tokens must be protected using transport- 1946 layer mechanisms such as TLS or SSL (see Section 5.1.1). 1948 o A short lifetime reduces impact in case tokens are compromised 1949 (see Section 5.1.5.3). 1951 o The access token can be bound to a client's identity and require 1952 the client to prove legitimate ownership of the token to the 1953 resource server (see Section 5.4.2). 1955 4.6.2. Threat: Replay authorized resource server requests 1957 An attacker could attempt to replay valid requests in order to obtain 1958 or to modify/destroy user data. 1960 Countermeasures: 1962 o The resource server should utilize transport security measure in 1963 order to prevent such attacks (see Section 5.1.1). This would 1964 prevent the attacker from capturing valid requests. 1966 o Alternatively, the resource server could employ signed requests 1967 (see Section 5.4.3) along with nounces and timestamps in order to 1968 uniquely identify requests. The resource server should detect and 1969 refuse every replayed request. 1971 4.6.3. Threat: Guessing access tokens 1973 Where the token is a handle, the attacker may use attempt to guess 1974 the access token values based on knowledge they have from other 1975 access tokens. 1977 Impact: Access to a single user's data. 1979 Countermeasures: 1981 o Handle Tokens should have a reasonable entropy (see 1982 Section 5.1.5.11) in order to make guessing a valid token value 1983 difficult. 1985 o Assertion (or self-contained token ) tokens contents should be 1986 protected by a digital signature (see Section 5.1.5.9). 1988 o Security can be further strengthened by using a short access token 1989 duration (see Section 5.1.5.2 and Section 5.1.5.3). 1991 4.6.4. Threat: Access token phishing by counterfeit resource server 1993 An attacker may pretend to be a particular resource server and to 1994 accept tokens from a particular authorization server. If the client 1995 sends a valid access tokens to this counterfeit resource server, the 1996 server in turn may use that token to access other services on behalf 1997 of the resource owner. 1999 Countermeasures: 2001 o Clients should not make authenticated requests with an access 2002 token to unfamiliar resource servers, regardless of the presence 2003 of a secure channel. If the resource server address is well-known 2004 to the client, it may authenticate the resource servers (see 2005 Section 5.1.2). 2007 o Associate the endpoint address of the resource server the client 2008 talked to with the access token (e.g. in an audience field) and 2009 validate association at legitimate resource server. The endpoint 2010 address validation policy may be strict (exact match) or more 2011 relaxed (e.g. same host). This would require to tell the 2012 authorization server the resource server endpoint address in the 2013 authorization process. 2015 o Associate an access token with a client and authenticate the 2016 client with resource server requests (typically via signature in 2017 order to not disclose secret to a potential attacker). This 2018 prevents the attack because the counterfeit server is assumed to 2019 miss the capabilities to correctly authenticate on behalf of the 2020 legitimate client to the resource server (Section 5.4.2). 2022 o Restrict the token scope (see Section 5.1.5.1) and or limit the 2023 token to a certain resource server (Section 5.1.5.5). 2025 4.6.5. Threat: Abuse of token by legitimate resource server or client 2027 A legitimate resource server could attempt to use an access token to 2028 access another resource servers. Similarly, a client could try to 2029 use a token obtained for one server on another resource server. 2031 Countermeasures: 2033 o Tokens should be restricted to particular resource servers (see 2034 Section 5.1.5.5). 2036 4.6.6. Threat: Leak of confidential data in HTTP-Proxies 2038 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is 2039 optional. However, [RFC2616](Fielding, R., Gettys, J., Mogul, J., 2040 Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2041 Transfer Protocol -- HTTP/1.1," .) relies on the Authorization and 2042 WWW-Authenticate headers to distinguish authenticated content so that 2043 it can be protected. Proxies and caches, in particular, may fail to 2044 adequately protect requests not using these headers. For example, 2045 private authenticated content may be stored in (and thus retrievable 2046 from) publicly-accessible caches. 2048 Countermeasures: 2050 o Resource servers not using the HTTP Authorization scheme (OAuth 2051 HTTP Authorization Scheme - see Section 5.4.1) should take care to 2052 use other mechanisms, such as the Cache-Control header, to 2053 minimize the risk that authenticated content is not protected. 2055 o Reducing scope (see Section 5.1.5.1) and expiry time 2056 (Section 5.1.5.3) for access tokens can be used to reduce the 2057 damage in case of leaks. 2059 4.6.7. Threat: Token leakage via logfiles and HTTP referrers 2061 If access tokens are sent via URI query parameters, such tokens may 2062 leak to log files and HTTP referrers. 2064 Countermeasures: 2066 o Use authorization headers or POST parameters instead of URI 2067 request parameters (see Section 5.4.1). 2069 o Set logging configuration appropriately 2071 o Prevent unauthorized persons from access to system log files (see 2072 Section 5.1.4.1.1) 2074 o HTTP referrers can be prevented by reloading the target page again 2075 without URI parameters 2077 o Abuse of leaked access tokens can be prevented by enforcing 2078 authenticated requests (see Section 5.4.2). 2080 o The impact of token leakage may be reduced by limiting scope (see 2081 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing 2082 one time token usage (see Section 5.1.5.4). 2084 5. Security Considerations 2086 This section describes the countermeasures as recommended to mitigate 2087 the threats as described in Section 4. 2089 5.1. General 2091 The general section covers consideratios that apply generally across 2092 all OAuth components (client, resource server, token server, and 2093 user-agents). 2095 5.1.1. Confidentiality of Requests 2097 This is applicable to all requests sent from client to authorization 2098 server or resource server. While OAuth provides a mechanism for 2099 verifying the integrity of requests, it provides no guarantee of 2100 request confidentiality. Unless further precautions are taken, 2101 eavesdroppers will have full access to request content and may be 2102 able to mount interception or replay attacks through using content of 2103 request, e.g. secrets or tokens. 2105 Attacks can be mitigated by using transport-layer mechanisms such as 2106 TLS or SSL. VPN may considered as well. 2108 This is a countermeasure against the following threats: 2110 o Replay of access tokens obtained on tokens endpoint or resource 2111 server's endpoint 2113 o Replay of refresh tokens obtained on tokens endpoint 2115 o Replay of authorization codes obtained on tokens endpoint 2116 (redirect?) 2118 o Replay of user passwords and client secrets 2120 5.1.2. Server authentication 2122 HTTPS server authentication or similar means can be used to 2123 authenticate the identity of a server. The goal is to reliably bind 2124 the DNS name of the server to the public key presented by the server 2125 during connection establishment. 2127 The client should validate the binding of the server to its domain 2128 name. If the server fails to prove that binding, it is considered a 2129 man-in-the-middle attack. The security measure depends on the 2130 certification authorities the client trusts for that purpose. 2131 Clients should carefully select those trusted CAs and protect the 2132 storage for trusted CA certificates from modifications. 2134 This is a countermeasure against the following threats: 2136 o Spoofing 2138 o Proxying 2140 o Phishing by counterfeit servers 2142 5.1.3. Always keep the resource owner informed 2144 Transparency to the resource owner is a key element of the OAuth 2145 protocol. The user should always be in control of the authorization 2146 processes and get the necessary information to meet informed 2147 decisions. Moreover, user involvement is a further security 2148 countermeasure. The user can probably recognize certain kinds of 2149 attacks better than the authorization server. Information can be 2150 presented/exchanged during the authorization process, after the 2151 authorization process, and every time the user wishes to get informed 2152 by using techniques such as: 2154 o User consent forms 2156 o Notification messages (e-Mail, SMS, ...) 2158 o Activity/Event logs 2160 o User self-care applications or portals 2162 5.1.4. Credentials 2164 This sections describes countermeasures used to protect all kinds of 2165 credentials from unauthorized access and abuse. Credentials are long 2166 term secrets, such as client secrets and user passwords as well as 2167 all kinds of tokens (refresh and access token) or authorization 2168 codes. 2170 5.1.4.1. Credential Storage Protection 2172 Administrators should undertake industry best practices to protect 2173 the storage of credentials. Such practices may include but are not 2174 limited to the following sub-sections. 2176 5.1.4.1.1. Standard System Security Means 2178 A server system may be locked down so that no attacker may get access 2179 to sensible configuration files and databases. 2181 5.1.4.1.2. Standard SQL Injection Countermeasures 2183 If a client identifier or other authentication component is queried 2184 or compared against a SQL Database it may become possible for an 2185 injection attack to occur if parameters received are not validated 2186 before submission to the database. 2188 o Ensure that server code is using the minimum database privileges 2189 possible to reduce the "surface" of possible attacks. 2191 o Avoid dynamic SQL using concatenated input. If possible, use 2192 static SQL. 2194 o When using dynamic SQL, parameterize queries using bind arguments. 2195 Bind arguments eliminate possibility of SQL injections. 2197 o Filter and sanitize the input. For example, if an identifier has 2198 a known format, ensure that the supplied value matches the 2199 identifier syntax rules. 2201 5.1.4.1.3. No cleartext storage of credentials 2203 The authorization server should not store credential in clear text. 2204 Typical approaches are to store hashes instead. If the credential 2205 lacks a reasonable entropy level (because it is a user password) an 2206 additional salt will harden the storage to prevent offline dictionary 2207 attacks. Note: Some authentication protocols require the 2208 authorization server to have access to the secret in the clear. 2209 Those protocols cannot be implemented if the server only has access 2210 to hashes. 2212 5.1.4.1.4. Encryption of credentials 2214 For client applications, insecurely persisted client credentials are 2215 easy targets for attackers to obtain. Store client credentials using 2216 an encrypted persistence mechanism such as a keystore or database. 2217 Note that compiling client credentials directly into client code 2218 makes client applications vulnerable to scanning as well as difficult 2219 to administer should client credentials change over time. 2221 5.1.4.1.5. Use of asymmetric cryptography 2223 Usage of asymmetric cryptography will free the authorization server 2224 of the obligation to manage credentials. 2226 5.1.4.2. Online attacks on secrets 2228 5.1.4.2.1. Password policy 2230 The authorization server may decide to enforce a complex user 2231 password policy in order to increase the user passwords' entropy. 2232 This will hinder online password attacks. 2234 5.1.4.2.2. High entropy of secrets 2236 When creating token handles or other secrets not intended for usage 2237 by human users, the authorization server should include a reasonable 2238 level of entropy in order to mitigate the risk of guessing attacks. 2240 The token value should be constructed from a cryptographically strong 2241 random or pseudo-random number sequence [RFC1750] generated by the 2242 Authorization Server. The probability of any two Authorization Code 2243 values being identical should be less than or equal to 2^(-128) and 2244 should be less than or equal to 2^(-160). 2246 5.1.4.2.3. Lock accounts 2248 Online attacks on passwords can be mitigated by locking the 2249 respective accounts after a certain number of failed attempts. 2251 Note: This measure can be abused to lock down legitimate service 2252 users. 2254 5.1.4.2.4. Tar pit 2256 The authorization server may react on failed attempts to authenticate 2257 by username/password by temporarily locking the respective account 2258 and delaying the response for a certain duration. This duration may 2259 increase with the number of failed attempts. The objective is to 2260 slow the attackers attempts on a certain username down. 2262 Note: this may require a more complex and stateful design of the 2263 authorization server. 2265 5.1.4.2.5. Usage of CAPTCHAs 2267 The idea is to prevent programs from automatically checking huge 2268 number of passwords by requiring human interaction. 2270 Note: this has a negative impact on user experience. 2272 5.1.5. Tokens (access, refresh, code) 2274 5.1.5.1. Limit token scope 2276 The authorization server may decide to reduce or limit the scope 2277 associated with a token. Basis of this decision is out of scope, 2278 examples are: 2280 o a client-specific policy, e.g. issue only less powerful tokens to 2281 public clients, 2283 o a service-specific policy, e.g. it a very sensible service, 2285 o a resource-owner specific setting, or 2287 o combinations of such policies and preferences. 2289 The authorization server may allow different scopes dependent on the 2290 grant type. For example, end-user authorization via direct 2291 interaction with the end-user (authorization code) might be 2292 considered more reliable than direct authorization via grant type 2293 username/password. This means will reduce the impact of the 2294 following threats: 2296 o token leakage 2298 o token issuance to malicious software 2300 o unintended issuance of to powerful tokens with resource owner 2301 credentials flow 2303 5.1.5.2. Expiration time 2305 Tokens should generally expire after a reasonable duration. This 2306 complements and strengthens other security measures (such as 2307 signatures) and reduces the impact of all kinds of token leaks. 2309 5.1.5.3. Short expiration time 2311 A short expiration time for tokens is a protection means against the 2312 following threats: 2314 o replay 2316 o reduce impact of token leak 2318 o reduce likelihood of successful online guessing 2320 Note: Short token duration requires preciser clock synchronisation 2321 between authorization server and resource server. Furthermore, 2322 shorter duration may require more token refreshments (access token) 2323 or repeated end-user authorization processes (authorization code and 2324 refresh token). 2326 5.1.5.4. Limit number of usages/ One time usage 2328 The authorization server may restrict the number of requests or 2329 operations which can be performed with a certain token. This 2330 mechanism can be used to mitigate the following threats: 2332 o replay of tokens 2334 o reduce likelihood of successful online guessing 2336 For example, if an Authorization Server observes more than one 2337 attempt to redeem a authorization code, the Authorization Server may 2338 want to revoke all access tokens granted based on the authorization 2339 code as well as reject the current request. 2341 As with the authorization code, access tokens may also have a limited 2342 number of operations. This forces client applications to either re- 2343 authenticate and use a refresh token to obtain a fresh access token, 2344 or it forces the client to re-authorize the access token by involving 2345 the user. 2347 5.1.5.5. Bind tokens to a particular resource server (Audience) 2349 Authorization servers in multi-service environments may consider 2350 issuing tokens with different content to different resource servers 2351 and to explicitly indicate in the token the target server a token is 2352 intended to be sent to (see Audience in SAML Assertions). This 2353 countermeasure can be used in the following situations: 2355 o It reduces the impact of a successful replay attempt, since the 2356 token is applicable to a single resource server, only. 2358 o It prevents abuse of a token by a rough resource server or client, 2359 since the token can only be used on that server. It is rejected 2360 by other servers. 2362 o It reduces the impact of a leakage of a valid token to a 2363 counterfeit resource server. 2365 5.1.5.6. Use endpoint address as token audience 2367 This may be used to indicate to a resource server, which endpoint 2368 address has been used to obtain the token. This measure will allow 2369 to detect requests from a counterfeit resource server, since such 2370 token will contain the endpoint address of that server. 2372 5.1.5.7. Audience and Token scopes 2374 Deployments may consider only using tokens with explicitly defined 2375 scope, where every scope is associated with a particular resource 2376 server. This approach can be used to mitigate attacks, where a 2377 resource server or client uses a token for a different then the 2378 intended purpose. 2380 5.1.5.8. Bind token to client id 2382 An authorization server may bind a token to a certain client 2383 identity. This identity should be validated for every request with 2384 that token. This means can be used, to 2386 o detect token leakage and 2388 o prevent token abuse. 2390 Note: Validating the client identity may require the target server to 2391 authenticate the client's identity. This authentication can be based 2392 on secrets managed independent of the token (e.g. pre-registered 2393 client id/secret on authorization server) or sent with the token 2394 itself (e.g. as part of the encrypted token content). 2396 5.1.5.9. Signed tokens 2398 Self-contained tokens should be signed in order to detect any attempt 2399 to modify or produce faked tokens. 2401 5.1.5.10. Encryption of token content 2403 Self-contained may be encrypted for privacy reasons or to protect 2404 system internal data. 2406 5.1.5.11. Random token value with high entropy 2408 When creating token handles, the authorization server should include 2409 a reasonable level of entropy in order to mitigate the risk of 2410 guessing attacks. The token value should be constructed from a 2411 cryptographically strong random or pseudo-random number sequence 2412 [RFC1750] generated by the Authorization Server. The probability of 2413 any two token values being identical should be less than or equal to 2414 2^(-128) and should be less than or equal to 2^(-160). 2416 5.1.5.12. Assertion formats 2418 For service providers intending to implement an assertion-based token 2419 design it is highly recommended to adopt a standard assertion format 2420 (such as SAML or JWT) that implements [draft-ietf-oauth-assertions]. 2422 5.1.6. Access tokens 2424 The following measures should be used to protect access tokens 2426 o keep them in transient memory (accessible by the client 2427 application only) 2429 o protect from exposure to 3rd parties (malicious application) 2431 o limit number of access tokens granted to a user 2433 5.2. Authorization Server 2435 This section describes considerations related to the OAuth 2436 Authorization Server end-point. 2438 5.2.1. Authorization Codes 2440 5.2.1.1. Automatic revocation of derived tokens if abuse is detected 2442 If an Authorization Server observes multiple attempts to redeem an 2443 authorization grant (e.g. such as an authorization code), the 2444 Authorization Server may want to revoke all tokens granted based on 2445 the authorization grant. 2447 5.2.2. Refresh tokens 2449 5.2.2.1. Restricted issuance of refresh tokens 2451 The authorization server may decide based on an appropriate policy 2452 not to issue refresh tokens. Since refresh tokens are long term 2453 credentials, they may be subject theft. For example, if the 2454 authorization server does not trust a client to securely store such 2455 tokens, it may refuse to issue such a client a refresh token. 2457 5.2.2.2. Binding of refresh token to client_id 2459 The authorization server should bind every refresh token to the id of 2460 the client such a token was originally issued to and validate this 2461 binding for every request to refresh that token. If possible (e.g. 2462 confidential clients), the authorization server should authenticate 2463 the respective client. 2465 This is a countermeasure against refresh token theft or leakage. 2467 Note: This binding should be protected from unauthorized 2468 modifications. 2470 5.2.2.3. Refresh Token Rotation 2472 Refresh token rotation is intended to automatically detect and 2473 prevent attempts to use the same refresh token in parallel from 2474 different apps/devices. This happens if a token gets stolen from the 2475 client and is subsequently used by the attacker and the legitimate 2476 client. The basic idea is to change the refresh token value with 2477 every refresh request in order to detect attempts to obtain access 2478 tokens using old refresh tokens. Since the authorization server 2479 cannot determine whether the attacker or the legitimate client is 2480 trying to access, in case of such an access attempt the valid refresh 2481 token and the access authorization associated with it are both 2482 revoked. 2484 The OAuth specification supports this measure in that the tokens 2485 response allows the authorization server to return a new refresh 2486 token even for requests with grant type "refresh_token". 2488 Note: this measure may cause problems in clustered environments since 2489 usage of the currently valid refresh token must be ensured. In such 2490 an environment, other measures might be more appropriate. 2492 5.2.2.4. Refresh Token Revocation 2494 The authorization server may allow clients or end-users to explicitly 2495 request the invalidation of refresh tokens. 2497 This is a countermeasure against: 2499 o device theft, 2501 o impersonation of resource owner, or 2503 o suspected compromised client applications. 2505 5.2.2.5. Device identification 2507 The authorization server may require to bind authentication 2508 credentials to a device identifier. The IMEI is one example of such 2509 an identifier, there are also operating system specific identifiers. 2510 The authorization server could include such an identifier when 2511 authenticating user credentials in order to detect token theft from a 2512 particular device. 2514 5.2.2.6. X-FRAME-OPTION header 2516 For newer browsers, avoidance of iFrames can be enforced server side 2517 by using the X-FRAME-OPTION header. This header can have two values, 2518 deny and same origin, which will block any framing or framing by 2519 sites with a different origin, respectively. 2521 This is a countermeasure against the following threats: 2523 o Clickjacking attacks 2525 5.2.3. Client authentication and authorization 2527 As described in Section 3 (Security Features), clients are 2528 identified, authenticated and authorized for several purposes, such 2529 as a 2531 o Collate sub-sequent requests to the same client, 2533 o Indicate the trustworthiness of a particular client to the end- 2534 user, 2536 o Authorize access of clients to certain features on the 2537 authorization or resource server, and 2539 o Log a client identity to log files for analysis or statics. 2541 Due to the different capabilities and characteristics of the 2542 different client types, there are different ways to support achieve 2543 objectives, which will be described in this section. Authorization 2544 server providers should be aware of the security policy and 2545 deployment of a particular clients and adapt its treatment 2546 accordingly. For example, one approach could be to treat all clients 2547 as less trustworthy and unsecure. On the other extreme, a service 2548 provider could activate every client installation by hand of an 2549 administrator and that way gain confidence in the identity of the 2550 software package and the security of the environment the client is 2551 installed in. And there are several approaches in between. 2553 5.2.3.1. Don't issue secrets to public clients or clients with 2554 inappropriate security policy 2556 Authorization servers should not issue secrets to "public" clients 2557 that cannot protect secrets. This prevents the server from 2558 overestimating the value of a successful authentication of the 2559 client. 2561 For example, it is of limited benefit to create a single client id 2562 and secret which is shared by all installations of a native 2563 application. Such a scenario requires that this secret must be 2564 transmitted from the developer via the respective distribution 2565 channel, e.g. an application market, to all installations of the 2566 application on end-user devices. A secret, burned into the source 2567 code of the application or a associated resource bundle, cannot be 2568 entirely protected from reverse engineering. Secondly, such secrets 2569 cannot be revoked since this would immediately put all installations 2570 out of work. Moreover, since the authorization server cannot really 2571 trust on the client's identity, it would be dangerous to indicate to 2572 end-users the trustworthiness of the client. 2574 There are other ways to achieve a reasonable security level, as 2575 described in the following sections. 2577 5.2.3.2. Public clients without secret require user consent 2579 Authorization servers should not allow automatic authorization for 2580 public clients. The authorization may issue a client id, but should 2581 require that all authorizations are approved by the end-user. This 2582 is a countermeasure for clients without secret against the following 2583 threats: 2585 o Impersonation of public client applications 2587 5.2.3.3. Client_id only in combination with redirect_uri 2589 The authorization may issue a client_id and bind the client_id to a 2590 certain pre-configured redirect_uri. Any authorization request with 2591 another redirection URI is refused automatically. Alternatively, the 2592 authorization server should not accept any dynamic redirection URI 2593 for such a client_id and instead always redirect to the well-known 2594 pre-configured redirection URI. This is a countermeasure for clients 2595 without secrets against the following threats: 2597 o Cross-site scripting attacks 2599 o Impersonation of public client applications 2601 5.2.3.4. Deployment-specific client secrets 2603 A authorization server may issue separate client identifiers and 2604 corresponding secrets to the different deployments of a client. The 2605 effect of such an approach would be to turn otherwise "public" 2606 clients back into "confidential" clients. 2608 For web applications, this could mean to create one client_id and 2609 client_secret per web site a software package is installed on. So 2610 the provider of that particular site could request client id and 2611 secret from the authorization server during setup of the web site. 2612 This would also allow to validate some of the properties of that web 2613 site, such as redirection URI, address, and whatever proofs useful. 2614 The web site provider has to ensure the security of the client secret 2615 on the site. 2617 For native applications, things are more complicated because every 2618 installation of the application on any device is another deployment. 2619 Deployment specific secrets will require 2621 1. Either to obtain a client_id and client_secret during download 2622 process from the application market, or 2624 2. During installation on the device. 2626 Either approach will require an automated mechanism for issuing 2627 client ids and secrets, which is currently not defined by OAuth. 2629 The first approach would allow to achieve a level where the client is 2630 authenticated and identified, whereas the second option only allows 2631 to authenticate the client but not to validate properties of the 2632 client. But this would at least help to prevent several replay 2633 attacks. Moreover, deployment-specific client_id and secret allow to 2634 selectively revoke all refresh tokens of a specific deployment at 2635 once. 2637 5.2.3.5. Validation of pre-registered redirect_uri 2639 An authorization server should require all clients to register their 2640 redirect_uri and the redirect_uri should be the full URI as defined 2641 in [I-D.ietf-oauth-v2]. The way this registration is performed is 2642 out of scope of this document. As per the core spec, every actual 2643 redirection URI sent with the respective client_id to the end-user 2644 authorization endpoint must match the registered redirection URI. 2645 Where it does not match, the authorization server should assume the 2646 inbound GET request has been sent by an attacker and refuse it. 2647 Note: the authorization server should not redirect the user agent 2648 back to the redirection URI of such an authorization request. 2650 o Authorization code leakage through counterfeit web site: allows to 2651 detect attack attempts already after first redirect to end-user 2652 authorization endpoint (Section 4.4.1.7). 2654 o For clients with validated properties, this measure also helps to 2655 detect malicious applications early in the end-user authorization 2656 process. This reduces the need for a interactive validation by 2657 the user (Section 4.4.1.4, Section 4.4.2.3). 2659 o Open Redirector attack via client redirection endpoint. ( 2660 Section 4.1.5. ) 2662 o Open Redirector phishing attack via authorization server 2663 redirection endpoint ( Section 4.2.4 ) 2665 The underlying assumption of this measure is that an attacker will 2666 need to use another redirection URI in order to get access to the 2667 authorization code. Deployments might consider the possibility of an 2668 attacker using spoofing attacks to a victims device to circumvent 2669 this security measure. 2671 Note: Pre-registering clients might not scale in some deployments 2672 (manual process) or require dynamic client registration (not 2673 specified yet). With the lack of dynamic client registration, it 2674 only works for clients bound to certain deployments at development/ 2675 configuration time. As soon as dynamic resource server discovery 2676 gets involved, that's no longer feasible. 2678 5.2.3.6. Client secret revocation 2680 An authorization server may revoke a client's secret in order to 2681 prevent abuse of a revealed secret. 2683 Note: This measure will immediately invalidate any authorization code 2684 or refresh token issued to the respective client. This might be 2685 unintentionally for client identifiers and secrets used across 2686 multiple deployments of a particular native or web application. 2688 This a countermeasure against: 2690 o Abuse of revealed client secrets for private clients 2692 5.2.3.7. Use strong client authentication (e.g. client_assertion / 2693 client_token) 2695 By using an alternative form of authentication such as client 2696 assertion [draft-ietf-oauth-assertions], the need to distribute 2697 client_secret is eliminated. This may require the use of a secure 2698 private key store or other supplemental authentication system as 2699 specified by the client assertion issuer in its authentication 2700 process. 2702 5.2.4. End-user authorization 2704 This secion involves considerations for authorization flows involving 2705 the end-user. 2707 5.2.4.1. Automatic processing of repeated authorizations requires 2708 client validation 2710 Authorization servers should NOT automatically process repeat 2711 authorizations where the client is not authenticated through a client 2712 secret or some other authentication mechanism such as signing with 2713 security certificates (5.7.2.7. Use strong client authentication 2714 (e.g. client_assertion / client_token)) or validation of a pre- 2715 registered redirect URI (5.7.2.5. Validation of pre-registered 2716 redirection URI ). 2718 5.2.4.2. Informed decisions based on transparency 2720 The authorization server should clearly explain to the end-user what 2721 happens in the authorization process and what the consequences are. 2722 For example, the user should understand what access he is about to 2723 grant to which client for what duration. It should also be obvious 2724 to the user, whether the server is able to reliably certify certain 2725 client properties (web site address, security policy). 2727 5.2.4.3. Validation of client properties by end-user 2729 In the authorization process, the user is typically asked to approve 2730 a client's request for authorization. This is an important security 2731 mechanism by itself because the end-user can be involved in the 2732 validation of client properties, such as whether the client name 2733 known to the authorization server fits the name of the web site or 2734 the application the end-user is using. This measure is especially 2735 helpful in all situation where the authorization server is unable to 2736 authenticate the client. It is a countermeasure against: 2738 o Malicious application 2740 o A client application masquerading as another client 2742 5.2.4.4. Binding of authorization code to client_id 2744 The authorization server should bind every authorization code to the 2745 id of the respective client which initiated the end-user 2746 authorization process. This measure is a countermeasure against: 2748 o replay of authorization codes with different client credentials 2749 since an attacker cannot use another client_id to exchange an 2750 authorization code into a token 2752 o Online guessing of authorization codes 2754 Note: This binding should be protected from unauthorized 2755 modifications. 2757 5.2.4.5. Binding of authorization code to redirect_uri 2759 The authorization server should bind every authorization code to the 2760 actual redirection URI used as redirect target of the client in the 2761 end-user authorization process. This binding should be validated 2762 when the client attempts to exchange the respective authorization 2763 code for an access token. This measure is a countermeasure against 2764 authorization code leakage through counterfeit web sites since an 2765 attacker cannot use another redirection URI to exchange an 2766 authorization code into a token. 2768 5.3. Client App Security 2770 This section deals with considerations for client applications. 2772 5.3.1. Don't store credentials in code or resources bundled with 2773 software packages 2775 Because of the numbers of copies of client software, there is limited 2776 benefit to create a single client id and secret which is shared by 2777 all installations of an application. Such an application by itself 2778 would be considered a "public" client as it cannot be presumed to be 2779 able to keep client secrets. A secret, burned into the source code 2780 of the application or a associated resource bundle, cannot be 2781 entirely protected from reverse engineering. Secondly, such secrets 2782 cannot be revoked since this would immediately put all installations 2783 out of work. Moreover, since the authorization server cannot really 2784 trust on the client's identity, it would be dangerous to indicate to 2785 end-users the trustworthiness of the client. 2787 5.3.2. Standard web server protection measures (for config files and 2788 databases) 2790 Use standard web server protection measures - Section 5.3.2 2792 5.3.3. Store secrets in a secure storage 2794 The are different way to store secrets of all kinds (tokens, client 2795 secrets) securely on a device or server. 2797 Most multi-user operation systems segregate the personal storage of 2798 the different system users. Moreover, most modern smartphone 2799 operating systems even support to store app-specific data in separate 2800 areas of the file systems and protect it from access by other 2801 applications. Additionally, applications can implements confidential 2802 data itself using a user-supplied secret, such as PIN or password. 2804 Another option is to swap refresh token storage to a trusted backend 2805 server. This mean in turn requires a resilient authentication 2806 mechanisms between client and backend server. Note: Applications 2807 should ensure that confidential data is kept confidential even after 2808 reading from secure storage, which typically means to keep this data 2809 in the local memory of the application. 2811 5.3.4. Utilize device lock to prevent unauthorized device access 2813 On a typical modern phone, there are many "device lock" options which 2814 can be utilized to provide additional protection where a device is 2815 stolen or misplaced. These include PINs, passwords and other 2816 biomtric featres such as "face recognition". These are not equal in 2817 their level of security they provide. 2819 5.3.5. Platform security measures 2821 o Validation process 2823 o software package signatures 2825 o Remote removal 2827 5.3.6. Link state parameter to user agent session 2829 The state parameter is used to link client requests and prevent CSRF 2830 attacks, for example against the redirection URI. An attacker could 2831 inject their own authorization code or access token, which can result 2832 in the client using an access token associated with the attacker's 2833 protected resources rather than the victim's (e.g. save the victim's 2834 bank account information to a protected resource controlled by the 2835 attacker). 2837 The client should utilize the "state" request parameter to send the 2838 authorization server a value that binds the request to the user- 2839 agent's authenticated state (e.g. a hash of the session cookie used 2840 to authenticate the user-agent) when making an authorization request. 2841 Once authorization has been obtained from the end-user, the 2842 authorization server redirects the end-user's user-agent back to the 2843 client with the required binding value contained in the "state" 2844 parameter. 2846 The binding value enables the client to verify the validity of the 2847 request by matching the binding value to the user- agent's 2848 authenticated state. 2850 5.4. Resource Servers 2852 The following section details security considerations for resource 2853 servers. 2855 5.4.1. Authorization headers 2857 Authorization headers are recognized and specially treated by HTTP 2858 proxies and servers. Thus the usage of such headers for sending 2859 access tokens to resource servers reduces the likelihood of leakage 2860 or unintended storage of authenticated requests in general and 2861 especially Authorization headers. 2863 5.4.2. Authenticated requests 2865 An authorization server may bind tokens to a certain client identity 2866 and encourage resource servers to validate that binding. This will 2867 require the resource server to authenticate the originator of a 2868 request as the legitimate owner of a particular token. There are a 2869 couple of options to implement this countermeasure: 2871 o The authorization server may associate the distinguished name of 2872 the client with the token (either internally or in the payload of 2873 an self-contained token). The client then uses client 2874 certificate-based HTTP authentication on the resource server's 2875 endpoint to authenticate its identity and the resource server 2876 validates the name with the name referenced by the token. 2878 o same as before, but the client uses his private key to sign the 2879 request to the resource server (public key is either contained in 2880 the token or sent along with the request) 2882 o Alternatively, the authorization server may issue a token-bound 2883 secret, which the client uses to sign the request. The resource 2884 server obtains the secret either directly from the authorization 2885 server or it is contained in an encrypted section of the token. 2886 That way the resource server does not "know" the client but is 2887 able to validate whether the authorization server issued the token 2888 to that client 2890 This mechanisms is a countermeasure against abuse of tokens by 2891 counterfeit resource servers. 2893 5.4.3. Signed requests 2895 A resource server may decide to accept signed requests only, either 2896 to replace transport level security measures or to complement such 2897 measures. Every signed request should be uniquely identifiable and 2898 should not be processed twice by the resource server. This 2899 countermeasure helps to mitigate: 2901 o modifications of the message and 2903 o replay attempts 2905 5.5. A Word on User Interaction and User-Installed Apps 2907 OAuth, as a security protocol, is distinctive in that its flow 2908 usually involves significant user interaction, making the end user a 2909 part of the security model. This creates some important difficulties 2910 in defending against some of the threats discussed above. Some of 2911 these points have already been made, but it's worth repeating and 2912 highlighting them here. 2914 o End users must understand what they are being asked to approve 2915 (see Section Section 5.2.4.1). Users often do not have the 2916 expertise to understand the ramifications of saying "yes" to an 2917 authorization request. and are likely not to be able to see subtle 2918 differences in wording of requests. Malicious software can 2919 confuse the user, tricking the user into approving almost 2920 anything. 2922 o End-user devices are prone to software compromise. This has been 2923 a long-standing problem, with frequent attacks on web browsers and 2924 other parts of the user's system. But with increasing popularity 2925 of user-installed "apps", the threat posed by compromised or 2926 malicious end-user software is very strong, and is one that is 2927 very difficult to mitigate. 2929 o Be aware that users will demand to install and run such apps, and 2930 that compromised or malicious ones can steal credentials at many 2931 points in the data flow. They can intercept the very user login 2932 credentials that OAuth is designed to protect. They can request 2933 authorization far beyond what they have led the user to understand 2934 and approve. They can automate a response on behalf of the user, 2935 hiding the whole process. No solution is offered here, because 2936 none is known; this remains in the space between better security 2937 and better usability. 2939 o Addressing these issues by restricting the use of user-installed 2940 software may be practical in some limited environments, and can be 2941 used as a countermeasure in those cases. Such restrictions are 2942 not practical in the general case, and mechanisms for after-the- 2943 fact recovery should be in place. 2945 o While end users are mostly incapable of properly vetting 2946 applications they load onto their devices, those who deploy 2947 Authorization Servers might have tools at their disposal to 2948 mitigate malicious Clients. For example, a well run Authorization 2949 Server MUST only assert client properties to the end-user it is 2950 effectively capable to validate, explicitely point out which 2951 properties it cannot validate and indicate to the end-user the 2952 risk associated with granting access to the particular client. 2954 6. IANA Considerations 2956 This document makes no request of IANA. 2958 Note to RFC Editor: this section may be removed on publication as an 2959 RFC. 2961 7. Acknowledgements 2963 We would like to thank Barry Leiba, Hui-Lan Lu, Francisco Corella, 2964 Peifung E Lam, Shane B Weeden, Skylar Woodward, Niv Steingarten, Tim 2965 Bray, and James H. Manger for their comments and contributions. 2967 8. References 2969 8.1. Normative References 2971 [I-D.ietf-oauth-v2] 2972 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 2973 2.0 Authorization Framework", draft-ietf-oauth-v2-26 (work 2974 in progress), May 2012. 2976 8.2. Informative References 2978 [I-D.ietf-oauth-v2-bearer] 2979 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 2980 Authorization Protocol: Bearer Tokens", 2981 draft-ietf-oauth-v2-bearer-19 (work in progress), 2982 April 2012. 2984 [I-D.ietf-oauth-v2-http-mac] 2985 Hammer-Lahav, E., "HTTP Authentication: MAC Access 2986 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in 2987 progress), February 2012. 2989 [I-D.lodderstedt-oauth-revocation] 2990 Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token 2991 Revocation", draft-lodderstedt-oauth-revocation-04 (work 2992 in progress), March 2012. 2994 [portable-contacts] 2995 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, 2996 . 2998 Appendix A. Document History 3000 [[ to be removed by RFC editor before publication as an RFC ]] 3002 draft-lodderstedt-oauth-security-01 3004 o section 4.4.1.2 - changed "resource server" to "client" in 3005 countermeasures description. 3007 o section 4.4.1.6 - changed "client shall authenticate the server" 3008 to "The browser shall be utilized to authenticate the redirection 3009 URI of the client" 3011 o section 5 - general review and alignment with public/confidential 3012 client terms 3014 o all sections - general clean-up and typo corrections 3016 draft-ietf-oauth-v2-threatmodel-00 3018 o section 3.4 - added the purposes for using authorization codes. 3020 o extended section 4.4.1.1 3022 o merged 4.4.1.5 into 4.4.1.2 3024 o corrected some typos 3026 o reformulated "session fixation", renamed respective sections into 3027 "authorization code disclosure through counterfeit client" 3029 o added new section "User session impersonation" 3031 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, 3032 5.1.4.1.4, 5.2.3.5 3034 o added new threat "DoS using manufactured authorization codes" as 3035 proposed by Peifung E Lam 3037 o added XSRF and clickjacking (incl. state parameter explanation) 3039 o changed sub-section order in section 4.4.1 3041 o incorporated feedback from Skylar Woodward (client secrets) and 3042 Shane B Weeden (refresh tokens as client instance secret) 3044 o aligned client section with core draft's client type definition 3046 o converted I-D into WG document 3048 draft-ietf-oauth-v2-threatmodel-01 3050 o Alignment of terminology with core draft 22 (private/public 3051 client, redirect URI validation policy, replaced definition of the 3052 client categories by reference to respective core section) 3054 o Synchronisation with the core's security consideration section 3055 (UPDATE 10.12 CSRF, NEW 10.14/15) 3057 o Added Resource Owner Impersonation 3059 o Improved section 5 3061 o Renamed Refresh Token Replacement to Refresh Token Rotation 3063 draft-ietf-oauth-v2-threatmodel-02 3065 o Incoporated Tim Bray's review comments (e.g. removed all normative 3066 language) 3068 o removed 2119 boilerplate and normative reference 3070 o incorporated shepherd review feedback 3072 Authors' Addresses 3074 Torsten Lodderstedt (editor) 3075 Deutsche Telekom AG 3077 Email: torsten@lodderstedt.net 3079 Mark McGloin 3080 IBM 3082 Email: mark.mcgloin@ie.ibm.com 3084 Phil Hunt 3085 Oracle Corporation 3087 Email: phil.hunt@yahoo.com