idnits 2.17.00 (12 Aug 2021) /tmp/idnits53637/draft-ietf-oauth-v2-threatmodel-06.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-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2012) is 3614 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-oauth-assertions has been published as RFC 7521 == Outdated reference: draft-ietf-oauth-json-web-token has been published as RFC 7519 == Outdated reference: draft-ietf-oauth-revocation has been published as RFC 7009 == Outdated reference: draft-ietf-oauth-v2 has been published as RFC 6749 == Outdated reference: draft-ietf-oauth-v2-bearer has been published as RFC 6750 == Outdated reference: A later version (-05) exists of draft-ietf-oauth-v2-http-mac-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OAuth Working Group T. Lodderstedt, Ed. 3 Internet-Draft Deutsche Telekom AG 4 Intended status: Informational M. McGloin 5 Expires: December 29, 2012 IBM 6 P. Hunt 7 Oracle Corporation 8 June 27, 2012 10 OAuth 2.0 Threat Model and Security Considerations 11 draft-ietf-oauth-v2-threatmodel-06 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 December 29, 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 . . . . . . . . . . . . . . . . 8 58 2.3.1. Authorization Servers . . . . . . . . . . . . . . . . 8 59 2.3.2. Resource Server . . . . . . . . . . . . . . . . . . . 8 60 2.3.3. Client . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 9 62 3.1. Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 3.1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . 10 64 3.1.2. Limited Access Token Lifetime . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 13 70 3.7. Client Identitifier . . . . . . . . . . . . . . . . . . . 13 71 4. Threat Model . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . 19 78 4.1.5. Threat: Open Redirectors on client . . . . . . . . . . 20 79 4.2. Authorization Endpoint . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . 21 84 4.2.3. Threat: Malicious client obtains existing 85 authorization by fraud . . . . . . . . . . . . . . . . 21 86 4.2.4. Threat: Open redirector . . . . . . . . . . . . . . . 22 87 4.3. Token endpoint . . . . . . . . . . . . . . . . . . . . . . 22 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: Disclosure of client credentials during 92 transmission . . . . . . . . . . . . . . . . . . . . . 23 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 97 4.4. Obtaining Authorization . . . . . . . . . . . . . . . . . 24 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 . . 26 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 . . . . . . . . . . . . . . . . 29 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 . . . . . . . 32 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 . . . . . . . . . . . . . 39 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 . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . . . 47 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 . . . . . . . . . . . . . . . . . 50 165 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 50 166 5.1.5.4. Limit number of usages/ One time usage . . . . . . 51 167 5.1.5.5. Bind tokens to a particular resource server 168 (Audience) . . . . . . . . . . . . . . . . . . . . 51 169 5.1.5.6. Use endpoint address as token audience . . . . . . 51 170 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 52 171 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 52 172 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 52 173 5.1.5.10. Encryption of token content . . . . . . . . . . . 52 174 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 52 175 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 53 176 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 53 177 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 53 178 5.2.1.1. Automatic revocation of derived tokens if 179 abuse is detected . . . . . . . . . . . . . . . . 53 180 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 53 181 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 53 182 5.2.2.2. Binding of refresh token to client_id . . . . . . 53 183 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 54 184 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 54 185 5.2.2.5. Device identification . . . . . . . . . . . . . . 54 186 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 55 187 5.2.3. Client authentication and authorization . . . . . . . 55 188 5.2.3.1. Don't issue secrets to client with 189 inappropriate security policy . . . . . . . . . . 55 190 5.2.3.2. Public clients without secret require user 191 consent . . . . . . . . . . . . . . . . . . . . . 56 192 5.2.3.3. Client_id only in combination with redirect_uri . 56 193 5.2.3.4. Installation-specific client secrets . . . . . . . 56 194 5.2.3.5. Validation of pre-registered redirect_uri . . . . 57 195 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 58 196 5.2.3.7. Use strong client authentication (e.g. 197 client_assertion / client_token) . . . . . . . . . 58 198 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 58 199 5.2.4.1. Automatic processing of repeated 200 authorizations requires client validation . . . . 59 201 5.2.4.2. Informed decisions based on transparency . . . . . 59 202 5.2.4.3. Validation of client properties by end-user . . . 59 203 5.2.4.4. Binding of authorization code to client_id . . . . 59 204 5.2.4.5. Binding of authorization code to redirect_uri . . 60 205 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 60 206 5.3.1. Don't store credentials in code or resources 207 bundled with software packages . . . . . . . . . . . . 60 208 5.3.2. Standard web server protection measures (for 209 config files and databases) . . . . . . . . . . . . . 60 210 5.3.3. Store secrets in a secure storage . . . . . . . . . . 60 211 5.3.4. Utilize device lock to prevent unauthorized device 212 access . . . . . . . . . . . . . . . . . . . . . . . . 61 213 5.3.5. Link state parameter to user agent session . . . . . . 61 214 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 61 215 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 61 216 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 62 217 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 62 218 5.5. A Word on User Interaction and User-Installed Apps . . . . 63 219 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 64 220 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 64 221 8. Informative References . . . . . . . . . . . . . . . . . . . . 64 222 Appendix A. Document History . . . . . . . . . . . . . . . . . . 66 223 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 68 225 1. Introduction 227 This document gives additional security considerations for OAuth, 228 beyond those in the OAuth specification, based on a comprehensive 229 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It 230 contains the following content: 232 o Documents any assumptions and scope considered when creating the 233 threat model. 235 o Describes the security features in-built into the OAuth protocol 236 and how they are intended to thwart attacks. 238 o Gives a comprehensive threat model for OAuth and describes the 239 respective counter measures to thwart those threats. 241 Threats include any intentional attacks on OAuth tokens and resources 242 protected by OAuth tokens as well as security risks introduced if the 243 proper security measures are not put in place. Threats are 244 structured along the lines of the protocol structure to aid 245 development teams implement each part of the protocol securely. For 246 example all threats for granting access or all threats for a 247 particular grant type or all threats for protecting the resource 248 server. 250 Note: This document cannot assess the probability nor the risk 251 associated with a particular threat because those aspects strongly 252 depend on the particular application and deployment OAuth is used to 253 protect. Similar, impacts are given on a rather abstract level. But 254 the information given here may serve as a foundation for deployment- 255 specific threat models. Implementors may refine and detail the 256 abstract threat model in order to account for the specific properties 257 of their deployment and to come up with a risk analysis. 259 2. Overview 261 2.1. Scope 263 The security considerations document only considers clients bound to 264 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such 265 deployments have the following characteristics: 267 o Resource server URLs are static and well-known at development 268 time, authorization server URLs can be static or discovered. 270 o Token scope values (e.g. applicable URLs and methods) are well- 271 known at development time. 273 o Client registration: Since registration of clients is out of scope 274 of the current core spec, this document assumes a broad variety of 275 options from static registration during development time to 276 dynamic registration at runtime. 278 The following are considered out of scope : 280 o Communication between authorization server and resource server 282 o Token formats 284 o Except for "Resource Owner Password Credentials" (see 285 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by 286 authorization servers to authenticate the user 288 o Mechanism by which a user obtained an assertion and any resulting 289 attacks mounted as a result of the assertion being false. 291 o Clients not bound to a specific deployment: An example could be a 292 mail client with support for contact list access via the portable 293 contacts API (see [portable-contacts]). Such clients cannot be 294 registered upfront with a particular deployment and should 295 dynamically discover the URLs relevant for the OAuth protocol. 297 2.2. Attack Assumptions 299 The following assumptions relate to an attacker and resources 300 available to an attacker: 302 o It is assumed the attacker has full access to the network between 303 the client and authorization servers and the client and the 304 resource server, respectively. The attacker may eavesdrop on any 305 communications between those parties. He is not assumed to have 306 access to communication between authorization and resource server. 308 o It is assumed an attacker has unlimited resources to mount an 309 attack. 311 o It is assumed that 2 of the 3 parties involved in the OAuth 312 protocol may collude to mount an attack against the 3rd party. 313 For example, the client and authorization server may be under 314 control of an attacker and collude to trick a user to gain access 315 to resources. 317 2.3. Architectural assumptions 319 This section documents the assumptions about the features, 320 limitations, and design options of the different entities of a OAuth 321 deployment along with the security-sensitive data-elements managed by 322 those entity. These assumptions are the foundation of the threat 323 analysis. 325 The OAuth protocol leaves deployments with a certain degree of 326 freedom how to implement and apply the standard. The core 327 specification defines the core concepts of an authorization server 328 and a resource server. Both servers can be implemented in the same 329 server entity, or they may also be different entities. The later is 330 typically the case for multi-service providers with a single 331 authentication and authorization system, and are more typical in 332 middleware architectures. 334 2.3.1. Authorization Servers 336 The following data elements are stored or accessible on the 337 authorization server: 339 o user names and passwords 341 o client ids and secrets 343 o client-specific refresh tokens 345 o client-specific access tokens (in case of handle-based design - 346 see Section 3.1) 348 o HTTPS certificate/key 350 o per-authorization process (in case of handle-based design - 351 Section 3.1): redirect_uri, client_id, authorization code 353 2.3.2. Resource Server 355 The following data elements are stored or accessible on the resource 356 server: 358 o user data (out of scope) 360 o HTTPS certificate/key 362 o authorization server credentials (handle-based design - see 363 Section 3.1), or 365 o authorization server shared secret/public key (assertion-based 366 design - see Section 3.1) 368 o access tokens (per request) 370 It is assumed that a resource server has no knowledge of refresh 371 tokens, user passwords, or client secrets. 373 2.3.3. Client 375 In OAuth a client is an application making protected resource 376 requests on behalf of the resource owner and with its authorization. 377 There are different types of clients with different implementation 378 and security characteristics, such as web, user-agent-based, and 379 native applications. A full definition of the different client types 380 and profiles is given in [I-D.ietf-oauth-v2], Section 2.1. 382 The following data elements are stored or accessible on the client: 384 o client id (and client secret or corresponding client credential) 386 o one or more refresh tokens (persistent) and access tokens 387 (transient) per end-user or other security-context or delegation 388 context 390 o trusted CA certificates (HTTPS) 392 o per-authorization process: redirect_uri, authorization code 394 3. Security Features 396 These are some of the security features which have been built into 397 the OAuth 2.0 protocol to mitigate attacks and security issues. 399 3.1. Tokens 401 OAuth makes extensive use many kinds of tokens (access tokens, 402 refresh tokens, authorization codes). The information content of a 403 token can be represented in two ways as follows: 405 Handle (or artifact) a reference to some internal data structure 406 within the authorization server; the internal data structure 407 contains the attributes of the token, such as user id, scope, etc. 408 Handles enable simple revocation and do not require cryptographic 409 mechanisms to protect token content from being modified. On the 410 other hand, handles require communication between issuing and 411 consuming entity (e.g. authorization and resource server) in order 412 to validate the token and obtain token-bound data. This 413 communication might have an negative impact on performance and 414 scalability if both entities reside on different systems. Handles 415 are therefore typically used if the issuing and consuming entity 416 are the same. A 'handle' token is often referred to as an 417 'opaque' token because the resource server does not need to be 418 able to interpret the token directly, it simply uses the token. 420 Assertions (aka self-contained token) a parseable token. An 421 assertion typically has a duration, has an audience, and is 422 digitally signed in order to ensure data integrity and origin 423 authentication. It contains information about the user and the 424 client. Examples of assertion formats are SAML assertions 425 [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120]. 426 Assertions can typically directly be validated and used by a 427 resource server without interactions with the authorization 428 server. This results in better performance and scalability in 429 deployment where issuing and consuming entity reside on different 430 systems. Implementing token revocation is more difficult with 431 assertions than with handles. 433 Tokens can be used in two ways to invoke requests on resource servers 434 as follows: 436 bearer token A 'bearer token' is a token that can be used by any 437 client who has received the token (e.g. 438 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to 439 use the token it is important that communication between end- 440 points be secured to ensure that only authorized end-points may 441 capture the token. The bearer token is convenient to client 442 applications as it does not require them to do anything to use 443 them (such as a proof of identity). Bearer tokens have similar 444 characteristics to web single-sign-on (SSO) cookies used in 445 browsers. 447 proof token A 'proof token' is a token that can only be used by a 448 specific client. Each use of the token, requires the client to 449 perform some action that proves that it is the authorized user of 450 the token. Examples of this are MAC tokens, which require the 451 client to digitally sign the resource request with a secret 452 corresponding to the particular token send with the request 453 (e.g.[I-D.ietf-oauth-v2-http-mac]). 455 3.1.1. Scope 457 A Scope represents the access authorization associated with a 458 particular token with respect to resource servers, resources and 459 methods on those resources. Scopes are the OAuth way to explicitly 460 manage the power associated with an access token. A scope can be 461 controlled by the authorization server and/or the end-user in order 462 to limit access to resources for OAuth clients these parties deem 463 less secure or trustworthy. Optionally, the client can request the 464 scope to apply to the token but only for lesser scope than would 465 otherwise be granted, e.g. to reduce the potential impact if this 466 token is sent over non secure channels. A scope is typically 467 complemented by a restriction on a token's lifetime. 469 3.1.2. Limited Access Token Lifetime 471 The protocol parameter expires_in allows an authorization server 472 (based on its policies or on behalf of the end-user) to limit the 473 lifetime of an access token and to pass this information to the 474 client. This mechanism can be used to issue short-living tokens to 475 OAuth clients the authorization server deems less secure or where 476 sending tokens over non secure channels. 478 3.2. Access Token 480 An access token is used by a client to access a resource. Access 481 tokens typically have short life-spans (minutes or hours) that cover 482 typical session lifetimes. An access token may be refreshed through 483 the use of a refresh token. The short lifespan of an access token in 484 combination with the usage of refresh tokens enables the possibility 485 of passive revocation of access authorization on the expiry of the 486 current access token. 488 3.3. Refresh Token 490 A refresh token represents a long-lasting authorization of a certain 491 client to access resources on behalf of a resource owner. Such 492 tokens are exchanged between client and authorization server, only. 493 Clients use this kind of token to obtain ("refresh") new access 494 tokens used for resource server invocations. 496 A refresh token, coupled with a short access token lifetime, can be 497 used to grant longer access to resources without involving end user 498 authorization. This offers an advantage where resource servers and 499 authorization servers are not the same entity, e.g. in a distributed 500 environment, as the refresh token is always exchanged at the 501 authorization server. The authorization server can revoke the 502 refresh token at any time causing the granted access to be revoked 503 once the current access token expires. Because of this, a short 504 access token lifetime is important if timely revocation is a high 505 priority. 507 The refresh token is also a secret bound to the client identifier and 508 client instance which originally requested the authorization and 509 representing the original resource owner grant. This is ensured by 510 the authorization process as follows: 512 1. The resource owner and user-agent safely deliver the 513 authorization code to the client instance in first place. 515 2. The client uses it immediately in secure transport-level 516 communications to the authorization server and then securely 517 stores the long-lived refresh token. 519 3. The client always uses the refresh token in secure transport- 520 level communications to the authorization server to get an access 521 token (and optionally rollover the refresh token). 523 So as long as the confidentiality of the particular token can be 524 ensured by the client, a refresh token can also be used as an 525 alternative means to authenticate the client instance itself.. 527 3.4. Authorization Code 529 An authorization code represents the intermediate result of a 530 successful end-user authorization process and is used by the client 531 to obtain access and refresh token. Authorization codes are sent to 532 the client's redirection URI instead of tokens for two purposes. 534 1. Browser-based flows expose protocol parameters to potential 535 attackers via URI query parameters (HTTP referrer), the browser 536 cache, or log file entries and could be replayed. In order to 537 reduce this threat, short-lived authorization codes are passed 538 instead of tokens and exchanged for tokens over a more secure 539 direct connection between client and authorization server. 541 2. It is much simpler to authenticate clients during the direct 542 request between client and authorization server than in the 543 context of the indirect authorization request. The latter would 544 require digital signatures. 546 3.5. Redirection URI 548 A redirection URI helps to detect malicious clients and prevents 549 phishing attacks from clients attempting to trick the user into 550 believing the phisher is the client. The value of the actual 551 redirection URI used in the authorization request has to be presented 552 and is verified when an authorization code is exchanged for tokens. 553 This helps to prevent attacks, where the authorization code is 554 revealed through redirectors and counterfeit web application clients. 555 The authorization server should require public clients and 556 confidential clients using implicit grant type to pre-register their 557 redirect URIs and validate against the registered redirection URI in 558 the authorization request. 560 3.6. State parameter 562 The state parameter is used to link requests and callbacks to prevent 563 Cross-Site Request Forgery attacks (see Section 4.4.1.8) where an 564 attacker authorizes access to his own resources and then tricks a 565 users into following a redirect with the attacker's token. This 566 parameter should bind to the authenticated state in a user agent and, 567 as per the core OAuth spec, the user agent must be capable of keeping 568 it in a location accessible only by the client and user agent, i.e. 569 protected by same-origin policy. 571 3.7. Client Identitifier 573 Authentication protocols have typically not taken into account the 574 identity of the software component acting on behalf of the end-user. 575 OAuth does this in order to increase the security level in delegated 576 authorization scenarios and because the client will be able to act 577 without the user being present. 579 OAuth uses the client identifier to collate associated request to the 580 same originator, such as 582 o a particular end-user authorization process and the corresponding 583 request on the token's endpoint to exchange the authorization code 584 for tokens or 586 o the initial authorization and issuance of a token by an end-user 587 to a particular client, and subsequent requests by this client to 588 obtain tokens without user consent (automatic processing of 589 repeated authorization) 591 This identifier may also be used by the authorization server to 592 display relevant registration information to a user when requesting 593 consent for scope requested by a particular client. The client 594 identifier may be used to limit the number of request for a 595 particular client or to charge the client per request. It may 596 furthermore be useful to differentiate access by different clients, 597 e.g. in server log files. 599 OAuth defines two client types, confidential and public, based on 600 their ability to authenticate with the authorization server (i.e. 601 ability to maintain the confidentiality of their client credentials). 602 Confidential clients are capable of maintaining the confidentiality 603 of client credentials (i.e. a client secret associated with the 604 client identifier) or capable of secure client authentication using 605 other means, such as a client assertion (e.g. SAML) or key 606 cryptography. The latter is considered more secure. 608 The authorization server should determine whether the client is 609 capable of keeping its secret confidential or using secure 610 authentication. Alternatively, the end-user can verify the identity 611 of the client, e.g. by only installing trusted applications.The 612 redicrection URI can be used to prevent delivering credentials to a 613 counterfeit client after obtaining end-user authorization in some 614 cases, but can't be used to verify the client identifier. 616 Clients can be categorized as follows based on the client type, 617 profile (e.g. native vs. web application - see [I-D.ietf-oauth-v2], 618 Section 9) and deployment model: 620 Deployment-independent client_id with pre-registered redirect_uri and 621 without client_secret Such an identifier is used by multiple 622 installations of the same software package. The identifier of 623 such a client can only be validated with the help of the end-user. 624 This is a viable option for native applications in order to 625 identify the client for the purpose of displaying meta information 626 about the client to the user and to differentiate clients in log 627 files. Revocation of the rights associated with such a client 628 identifier will affect ALL deployments of the respective software. 630 Deployment-independent client_id with pre-registered redirect_uri and 631 with client_secret This is an option for native applications only, 632 since web application would require different redirect URIs. This 633 category is not advisable because the client secret cannot be 634 protected appropriately (see Section 4.1.1). Due to its security 635 weaknesses, such client identities have the same trust level as 636 deployment-independent clients without secret. Revocation will 637 affect ALL deployments. 639 Deployment-specific client_id with pre-registered redirect_uri and 640 with client_secret The client registration process ensures the 641 validation of the client's properties, such as redirection URI, 642 website URL, web site name, contacts. Such a client identifier 643 can be utilized for all relevant use cases cited above. This 644 level can be achieved for web applications in combination with a 645 manual or user-bound registration process. Achieving this level 646 for native applications is much more difficult. Either the 647 installation of the application is conducted by an administrator, 648 who validates the client's authenticity, or the process from 649 validating the application to the installation of the application 650 on the device and the creation of the client credentials is 651 controlled end-to-end by a single entity (e.g. application market 652 provider). Revocation will affect a single deployment only. 654 Deployment-specific client_id with client_secret without validated 655 properties Such a client can be recognized by the authorization 656 server in transactions with subsequent requests (e.g. 657 authorization and token issuance, refresh token issuance and 658 access token refreshment). The authorization server cannot assure 659 any property of the client to end-users. Automatic processing of 660 re-authorizations could be allowed as well. Such client 661 credentials can be generated automatically without any validation 662 of client properties, which makes it another option especially for 663 native applications. Revocation will affect a single deployment 664 only. 666 4. Threat Model 668 This section gives a comprehensive threat model of OAuth 2.0. 669 Threats are grouped first by attacks directed against an OAuth 670 component, which are client, authorization server, and resource 671 server. Subsequently, they are grouped by flow, e.g. obtain token or 672 access protected resources. Every countermeasure description refers 673 to a detailed description in Section 5. 675 4.1. Clients 677 This section describes possible threats directed to OAuth clients. 679 4.1.1. Threat: Obtain Client Secrets 681 The attacker could try to get access to the secret of a particular 682 client in order to: 684 o replay its refresh tokens and authorization codes, or 686 o obtain tokens on behalf of the attacked client with the privileges 687 of that client. 689 The resulting impact would be: 691 o Client authentication of access to authorization server can be 692 bypassed 694 o Stolen refresh tokens or authorization codes can be replayed 696 Depending on the client category, the following attacks could be 697 utilized to obtain the client secret. 699 Attack: Obtain Secret From Source Code or Binary: 701 This applies for all client types. For open source projects, secrets 702 can be extracted directly from source code in their public 703 repositories. Secrets can be extracted from application binaries 704 just as easily when published source is not available to the 705 attacker. Even if an application takes significant measures to 706 obfuscate secrets in their application distribution one should 707 consider that the secret can still be reverse-engineered by anyone 708 with access to a complete functioning application bundle or binary. 710 Countermeasures: 712 o Don't issue secrets to public clients or clients with 713 inappropriate security policy - Section 5.2.3.1 715 o Public clients require user consent - Section 5.2.3.2 717 o Use deployment-specific client secrets - Section 5.2.3.4 719 o Client secret revocation - Section 5.2.3.6 721 Attack: Obtain a Deployment-Specific Secret: 723 An attacker may try to obtain the secret from a client installation, 724 either from a web site (web server) or a particular devices (native 725 application). 727 Countermeasures: 729 o Web server: apply standard web server protection measures (for 730 config files and databases) - Section 5.3.2 732 o Native applications: Store secrets in a secure local storage - 733 Section 5.3.3 735 o Client secret revocation - Section 5.2.3.6 737 4.1.2. Threat: Obtain Refresh Tokens 739 Depending on the client type, there are different ways refresh tokens 740 may be revealed to an attacker. The following sub-sections give a 741 more detailed description of the different attacks with respect to 742 different client types and further specialized countermeasures. 743 Before detailing those threats, here are some generally applicable 744 countermeasures: 746 o The authorization server should validate the client id associated 747 with the particular refresh token with every refresh request- 748 Section 5.2.2.2 750 o Limited scope tokens - Section 5.1.5.1 752 o Refresh token revocation - Section 5.2.2.4 754 o Client secret revocation - Section 5.2.3.6 756 o Refresh tokens can automatically be replaced in order to detect 757 unauthorized token usage by another party (Refresh Token Rotation) 758 - Section 5.2.2.3 760 Attack: Obtain Refresh Token from Web application: 762 An attacker may obtain the refresh tokens issued to a web application 763 by way of overcoming the web server's security controls. Impact: 764 Since a web application manages the user accounts of a certain site, 765 such an attack would result in an exposure of all refresh tokens on 766 that side to the attacker. 768 Countermeasures: 770 o Standard web server protection measures - Section 5.3.2 772 o Use strong client authentication (e.g. client_assertion / 773 client_token), so the attacker cannot obtain the client secret 774 required to exchange the tokens - Section 5.2.3.7 776 Attack: Obtain Refresh Token from Native clients: 778 On native clients, leakage of a refresh token typically affects a 779 single user, only. 781 Read from local file system: The attacker could try get file system 782 access on the device and read the refresh tokens. The attacker could 783 utilize a malicious application for that purpose. 785 Countermeasures: 787 o Store secrets in a secure storage - Section 5.3.3 789 o Utilize device lock to prevent unauthorized device access - 790 Section 5.3.4 792 Attack: Steal device: 794 The host device (e.g. mobile phone) may be stolen. In that case, the 795 attacker gets access to all applications under the identity of the 796 legitimate user. 798 Countermeasures: 800 o Utilize device lock to prevent unauthorized device access - 801 Section 5.3.4 803 o Where a user knows the device has been stolen, they can revoke the 804 affected tokens - Section 5.2.2.4 806 Attack: Clone Device: 808 All device data and applications are copied to another device. 809 Applications are used as-is on the target device. 811 Countermeasures: 813 o Utilize device lock to prevent unauthorized device access - 814 Section 5.3.4 816 o Combine refresh token request with device identification - 817 Section 5.2.2.5 819 o Refresh Token Rotation - Section 5.2.2.3 821 o Where a user knows the device has been cloned, they can use this 822 countermeasure - Refresh Token Revocation - Section 5.2.2.4 824 4.1.3. Threat: Obtain Access Tokens 826 Depending on the client type, there are different ways access tokens 827 may be revealed to an attacker. Access tokens could be stolen from 828 the device if the application stores them in a storage, which is 829 accessible to other applications. 831 Impact: Where the token is a bearer token and no additional mechanism 832 is used to identify the client, the attacker can access all resources 833 associated with the token and its scope. 835 Countermeasures: 837 o Keep access tokens in transient memory and limit grants: 838 Section 5.1.6 840 o Limited scope tokens - Section 5.1.5.1 842 o Keep access tokens in private memory or apply same protection 843 means as for refresh tokens - Section 5.2.2 845 o Keep access token lifetime short - Section 5.1.5.3 847 4.1.4. Threat: End-user credentials phished using compromised or 848 embedded browser 850 A malicious application could attempt to phish end-user passwords by 851 misusing an embedded browser in the end-user authorization process, 852 or by presenting its own user-interface instead of allowing trusted 853 system browser to render the authorization user interface. By doing 854 so, the usual visual trust mechanisms may be bypassed (e.g. TLS 855 confirmation, web site mechanisms). By using an embedded or internal 856 client application user interface, the client application has access 857 to additional information it should not have access to (e.g. uid/ 858 password). 860 Impact: If the client application or the communication is 861 compromised, the user would not be aware and all information in the 862 authorization exchange could be captured such as username and 863 password. 865 Countermeasures: 867 o The OAuth flow is designed so that client applications never need 868 to know user passwords. Client applications should avoid directly 869 asking users for the their credentials. In addition, end users 870 could be educated about phishing attacks and best practices, such 871 as only accessing trusted clients, as OAuth does not provide any 872 protection against malicious applications and the end user is 873 solely responsible for the trustworthiness of any native 874 application installed. 876 o Client applications could be validated prior to publication in an 877 application market for users to access. That validation is out of 878 scope for OAuth but could include validating that the client 879 application handles user authentication in an appropriate way. 881 o Client developers should not write client applications that 882 collect authentication information directly from users and should 883 instead delegate this task to a trusted system component, e.g. the 884 system-browser. 886 4.1.5. Threat: Open Redirectors on client 888 An open redirector is an endpoint using a parameter to automatically 889 redirect a user-agent to the location specified by the parameter 890 value without any validation. If the authorization server allows the 891 client to register only part of the redirection URI, an attacker can 892 use an open redirector operated by the client to construct a 893 redirection URI that will pass the authorization server validation 894 but will send the authorization code or access token to an endpoint 895 under the control of the attacker. 897 Impact: An attacker could gain access to authorization codes or 898 access tokens 900 Countermeasure 902 o require clients to register full redirection URI Section 5.2.3.5 904 4.2. Authorization Endpoint 906 4.2.1. Threat: Password phishing by counterfeit authorization server 908 OAuth makes no attempt to verify the authenticity of the 909 Authorization Server. A hostile party could take advantage of this 910 by intercepting the Client's requests and returning misleading or 911 otherwise incorrect responses. This could be achieved using DNS or 912 ARP spoofing. Wide deployment of OAuth and similar protocols may 913 cause users to become inured to the practice of being redirected to 914 websites where they are asked to enter their passwords. If users are 915 not careful to verify the authenticity of these websites before 916 entering their credentials, it will be possible for attackers to 917 exploit this practice to steal Users' passwords. 919 Countermeasures: 921 o Authorization servers should consider such attacks when developing 922 services based on OAuth, and should require transport-layer 923 security for any requests where the authenticity of the 924 authorization server or of request responses is an issue (see 925 Section 5.1.2). 927 o Authorization servers should attempt to educate Users about the 928 risks phishing attacks pose, and should provide mechanisms that 929 make it easy for users to confirm the authenticity of their sites. 931 4.2.2. Threat: User unintentionally grants too much access scope 933 When obtaining end user authorization, the end-user may not 934 understand the scope of the access being granted and to whom or they 935 may end up providing a client with access to resources which should 936 not be permitted. 938 Countermeasures: 940 o Explain the scope (resources and the permissions) the user is 941 about to grant in an understandable way - Section 5.2.4.2 943 o Narrow scope based on client - When obtaining end user 944 authorization and where the client requests scope, the 945 authorization server may want to consider whether to honour that 946 scope based on the client identifier. That decision is between 947 the client and authorization server and is outside the scope of 948 this spec. The authorization server may also want to consider 949 what scope to grant based on the client type, e.g. providing lower 950 scope to public clients. - Section 5.1.5.1 952 4.2.3. Threat: Malicious client obtains existing authorization by fraud 954 Authorization servers may wish to automatically process authorization 955 requests from clients which have been previously authorized by the 956 user. When the user is redirected to the authorization server's end- 957 user authorization endpoint to grant access, the authorization server 958 detects that the user has already granted access to that particular 959 client. Instead of prompting the user for approval, the 960 authorization server automatically redirects the user back to the 961 client. 963 A malicious client may exploit that feature and try to obtain such an 964 authorization code instead of the legitimate client. 966 Countermeasures: 968 o Authorization servers should not automatically process repeat 969 authorizations to public clients or unless the client is validated 970 using a pre-registered redirect URI (Section 5.2.3.5 ) 972 o Authorization servers can mitigate the risks associated with 973 automatic processing by limiting the scope of Access Tokens 974 obtained through automated approvals - Section 5.1.5.1 976 4.2.4. Threat: Open redirector 978 An attacker could use the end-user authorization endpoint and the 979 redirection URI parameter to abuse the authorization server as an 980 open redirector. An open redirector is an endpoint using a parameter 981 to automatically redirect a user-agent to the location specified by 982 the parameter value without any validation. 984 Impact: An attacker could utilize a user's trust in your 985 authorization server to launch a phishing attack. 987 Countermeasure 989 o require clients to register full redirection URI Section 5.2.3.5 991 o don't redirect to redirection URI, if client identifier or 992 redirection URI can't be verified Section 5.2.3.5 994 4.3. Token endpoint 996 4.3.1. Threat: Eavesdropping access tokens 998 Attackers may attempt to eavesdrop access token in transit from the 999 authorization server to the client. 1001 Impact: The attacker is able to access all resources with the 1002 permissions covered by the scope of the particular access token. 1004 Countermeasures: 1006 o As per the core OAuth spec, the authorization servers must ensure 1007 that these transmissions are protected using transport-layer 1008 mechanisms such as TLS (see Section 5.1.1). 1010 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1011 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1012 tokens can be used to reduce the damage in case of leaks. 1014 4.3.2. Threat: Obtain access tokens from authorization server database 1016 This threat is applicable if the authorization server stores access 1017 tokens as handles in a database. An attacker may obtain access 1018 tokens from the authorization server's database by gaining access to 1019 the database or launching a SQL injection attack. Impact: disclosure 1020 of all access tokens 1022 Countermeasures: 1024 o System security measures - Section 5.1.4.1.1 1026 o Store access token hashes only - Section 5.1.4.1.3 1028 o Standard SQL injection Countermeasures - Section 5.1.4.1.2 1030 4.3.3. Threat: Disclosure of client credentials during transmission 1032 An attacker could attempt to eavesdrop the transmission of client 1033 credentials between client and server during the client 1034 authentication process or during OAuth token requests. 1036 Impact: Revelation of a client credential enabling phishing or 1037 impersonation of a client service. 1039 Countermeasures: 1041 o The transmission of client credentials must be protected using 1042 transport-layer mechanisms such as TLS (see Section 5.1.1). 1044 o Alternative authentication means, which do not require to send 1045 plaintext credentials over the wire (e.g. Hash-based Message 1046 Authentication Code) 1048 4.3.4. Threat: Obtain client secret from authorization server database 1050 An attacker may obtain valid client_id/secret combinations from the 1051 authorization server's database by gaining access to the database or 1052 launching a SQL injection attack. Impact: disclosure of all 1053 client_id/secret combinations. This allows the attacker to act on 1054 behalf of legitimate clients. 1056 Countermeasures: 1058 o System security measures - Section 5.1.4.1.1 1060 o Standard SQL injection Countermeasures - Section 5.1.4.1.2 1062 o Ensure proper handling of credentials as per Credential Storage 1063 Protection. 1065 4.3.5. Threat: Obtain client secret by online guessing 1067 An attacker may try to guess valid client_id/secret pairs. Impact: 1068 disclosure of single client_id/secret pair. 1070 Countermeasures: 1072 o High entropy of secrets - Section 5.1.4.2.2 1074 o Lock accounts - Section 5.1.4.2.3 1076 o Use Strong Client Authentication - Section 5.2.3.7 1078 4.4. Obtaining Authorization 1080 This section covers threats which are specific to certain flows 1081 utilized to obtain access tokens. Each flow is characterized by 1082 response types and/or grant types on the end-user authorization and 1083 token endpoint, respectively. 1085 4.4.1. Authorization Code 1087 4.4.1.1. Threat: Eavesdropping or leaking authorization codes 1089 An attacker could try to eavesdrop transmission of the authorization 1090 code between authorization server and client. Furthermore, 1091 authorization codes are passed via the browser which may 1092 unintentionally leak those codes to untrusted web sites and attackers 1093 in different ways: 1095 o Referrer headers: browsers frequently pass a "referer" header when 1096 a web page embeds content, or when a user travels from one web 1097 page to another web page. These referrer headers may be sent even 1098 when the origin site does not trust the destination site. The 1099 referrer header is commonly logged for traffic analysis purposes. 1101 o Request logs: web server request logs commonly include query 1102 parameters on requests. 1104 o Open redirectors: web sites sometimes need to send users to 1105 another destination via a redirector. Open redirectors pose a 1106 particular risk to web-based delegation protocols because the 1107 redirector can leak verification codes to untrusted destination 1108 sites. 1110 o Browser history: web browsers commonly record visited URLs in the 1111 browser history. Another user of the same web browser may be able 1112 to view URLs that were visited by previous users. 1114 Note: A description of a similar attacks on the SAML protocol can be 1115 found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1, 1116 [gross-sec-analysis], and 1117 [OASIS.sstc-gross-sec-analysis-response-01]. 1119 Countermeasures: 1121 o As per the core OAuth spec, the authorization server as well as 1122 the client must ensure that these transmissions are protected 1123 using transport-layer mechanisms such as TLS (see Section 5.1.1). 1125 o The authorization server will require the client to authenticate 1126 wherever possible, so the binding of the authorization code to a 1127 certain client can be validated in a reliable way (see 1128 Section 5.2.4.4). 1130 o Limited duration of authorization codes - Section 5.1.5.3 1132 o The authorization server should enforce a one time usage 1133 restriction (see Section 5.1.5.4). 1135 o If an Authorization Server observes multiple attempts to redeem an 1136 authorization code, the Authorization Server may want to revoke 1137 all tokens granted based on the authorization code (see 1138 Section 5.2.1.1). 1140 o In the absence of these countermeasures, reducing scope 1141 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access 1142 tokens can be used to reduce the damage in case of leaks. 1144 o The client server may reload the target page of the redirection 1145 URI in order to automatically cleanup the browser cache. 1147 4.4.1.2. Threat: Obtain authorization codes from authorization server 1148 database 1150 This threat is applicable if the authorization server stores 1151 authorization codes as handles in a database. An attacker may obtain 1152 authorization codes from the authorization server's database by 1153 gaining access to the database or launching a SQL injection attack. 1154 Impact: disclosure of all authorization codes, most likely along with 1155 the respective redirect_uri and client_id values. 1157 Countermeasures: 1159 o Best practices for credential storage protection should be 1160 employed - Section 5.1.4.1 1162 o System security measures - Section 5.1.4.1.1 1164 o Store access token hashes only - Section 5.1.4.1.3 1166 o Standard SQL injection countermeasures - Section 5.1.4.1.2 1168 4.4.1.3. Threat: Online guessing of authorization codes 1170 An attacker may try to guess valid authorization code values and send 1171 it using the grant type "code" in order to obtain a valid access 1172 token. 1174 Impact: disclosure of single access token, probably also associated 1175 refresh token. 1177 Countermeasures: 1179 o Handle-based tokens must use high entropy: Section 5.1.4.2.2 1181 o Assertion-based tokens should be signed: Section 5.1.5.9 1183 o Authenticate the client, adds another value the attacker has to 1184 guess - Section 5.2.3.4 1186 o Binding of authorization code to redirection URI, adds another 1187 value the attacker has to guess - Section 5.2.4.5 1189 o Short expiration time - Section 5.1.5.3 1191 4.4.1.4. Threat: Malicious client obtains authorization 1193 A malicious client could pretend to be a valid client and obtain an 1194 access authorization that way. The malicious client could even 1195 utilize screen scraping techniques in order to simulate the user 1196 consent in the authorization flow. 1198 Assumption: It is not the task of the authorization server to protect 1199 the end-user's device from malicious software. This is the 1200 responsibility of the platform running on the particular device 1201 probably in cooperation with other components of the respective 1202 ecosystem (e.g. an application management infrastructure). The sole 1203 responsibility of the authorization server is to control access to 1204 the end-user's resources living in resource servers and to prevent 1205 unauthorized access to them via the OAuth protocol. Based on this 1206 assumption, the following countermeasures are available to cope with 1207 the threat. 1209 Countermeasures: 1211 o The authorization server should authenticate the client, if 1212 possible (see Section 5.2.3.4). Note: the authentication takes 1213 place after the end-user has authorized the access. 1215 o The authorization server should validate the client's redirection 1216 URI against the pre-registered redirection URI, if one exists (see 1217 Section 5.2.3.5). Note: An invalid redirect URI indicates an 1218 invalid client whereas a valid redirect URI does not neccesserily 1219 indicate a valid client. The level of confidence depends on the 1220 client type. For web applications, the confidence is high since 1221 the redirect URI refers to the globally unique network endpoint of 1222 this application whose fully qualified domain name (FQDN) is also 1223 validated using HTTPS server authentication by the user agent. In 1224 contrast for native clients, the redirect URI typically refers to 1225 device local resources, e.g. a custom scheme. So a malicious 1226 client on a particular device can use the valid redirect URI the 1227 legitimate client uses on all other devices. 1229 o After authenticating the end-user, the authorization server should 1230 ask him/her for consent. In this context, the authorization 1231 server should explain to the end-user the purpose, scope, and 1232 duration of the authorization the client asked for. Moreover, the 1233 authorization server should show the user any identity information 1234 it has for that client. It is up to the user to validate the 1235 binding of this data to the particular application (e.g. Name) 1236 and to approve the authorization request. (see Section 5.2.4.3). 1238 o The authorization server should not perform automatic re- 1239 authorizations for clients it is unable to reliably authenticate 1240 or validate (see Section 5.2.4.1). 1242 o If the authorization server automatically authenticates the end- 1243 user, it may nevertheless require some user input in order to 1244 prevent screen scraping. Examples are CAPTCHAs (Completely 1245 Automated Public Turing test to tell Computers and Humans Apart) 1246 or other multi-factor authentication techniques such as random 1247 questions, token code generators, etc. 1249 o The authorization server may also limit the scope of tokens it 1250 issues to clients it cannot reliably authenticate (see 1251 Section 5.1.5.1). 1253 4.4.1.5. Threat: Authorization code phishing 1255 A hostile party could impersonate the client site and get access to 1256 the authorization code. This could be achieved using DNS or ARP 1257 spoofing. This applies to clients, which are web applications, thus 1258 the redirect URI is not local to the host where the user's browser is 1259 running. 1261 Impact: This affects web applications and may lead to a disclosure of 1262 authorization codes and, potentially, the corresponding access and 1263 refresh tokens. 1265 Countermeasures: 1267 It is strongly recommended that one of the following countermeasures 1268 is utilized in order to prevent this attack: 1270 o The redirection URI of the client should point to a HTTPS 1271 protected endpoint and the browser should be utilized to 1272 authenticate this redirection URI using server authentication (see 1273 Section 5.1.2). 1275 o The authorization server should require the client to be 1276 authenticated, i.e. confidential client, so the binding of the 1277 authorization code to a certain client can be validated in a 1278 reliable way (see Section 5.2.4.4). 1280 4.4.1.6. Threat: User session impersonation 1282 A hostile party could impersonate the client site and impersonate the 1283 user's session on this client. This could be achieved using DNS or 1284 ARP spoofing. This applies to clients, which are web applications, 1285 thus the redirect URI is not local to the host where the user's 1286 browser is running. 1288 Impact: An attacker who intercepts the authorization code as it is 1289 sent by the browser to the callback endpoint can gain access to 1290 protected resources by submitting the authorization code to the 1291 client. The client will exchange the authorization code for an 1292 access token and use the access token to access protected resources 1293 for the benefit of the attacker, delivering protected resources to 1294 the attacker, or modifying protected resources as directed by the 1295 attacker. If OAuth is used by the client to delegate authentication 1296 to a social site (e.g. as in the implementation of "Login" button to 1297 a third-party social network site), the attacker can use the 1298 intercepted authorization code to log in to the client as the user. 1300 Note: Authenticating the client during authorization code exchange 1301 will not help to detect such an attack as it is the legitimate client 1302 that obtains the tokens. 1304 Countermeasures: 1306 o In order to prevent an attacker from impersonating the end-users 1307 session, the redirection URI of the client should point to a HTTPS 1308 protected endpoint and the browser should be utilized to 1309 authenticate this redirection URI using server authentication (see 1310 Section 5.1.2) 1312 4.4.1.7. Threat: Authorization code leakage through counterfeit client 1314 The attack leverages the authorization code grant type in an attempt 1315 to get another user (victim) to log-in, authorize access to his/her 1316 resources, and subsequently obtain the authorization code and inject 1317 it into a client application using the attacker's account. The goal 1318 is to associate an access authorization for resources of the victim 1319 with the user account of the attacker on a client site. 1321 The attacker abuses an existing client application and combines it 1322 with his own counterfeit client web site. The attack depends on the 1323 victim expecting the client application to request access to a 1324 certain resource server. The victim, seeing only a normal request 1325 from an expected application, approves the request. The attacker 1326 then uses the victim's authorization to gain access to the 1327 information unknowingly authorized by the victim. 1329 The attacker conducts the following flow: 1331 1. The attacker accesses the client web site (or application) and 1332 initiates data access to a particular resource server. The 1333 client web site in turn initiates an authorization request to the 1334 resource server's authorization server. Instead of proceeding 1335 with the authorization process, the attacker modifies the 1336 authorization server end-user authorization URL as constructed by 1337 the client to include a redirection URI parameter referring to a 1338 web site under his control (attacker's web site). 1340 2. The attacker tricks another user (the victim) to open that 1341 modified end-user authorization URI and to authorize access (e.g. 1342 an email link, or blog link). The way the attacker achieves that 1343 goal is out of scope. 1345 3. Having clicked the link, the victim is requested to authenticate 1346 and authorize the client site to have access. 1348 4. After completion of the authorization process, the authorization 1349 server redirects the user agent to the attacker's web site 1350 instead of the original client web site. 1352 5. The attacker obtains the authorization code from his web site by 1353 means out of scope of this document. 1355 6. He then constructs a redirection URI to the target web site (or 1356 application) based on the original authorization request's 1357 redirection URI and the newly obtained authorization code and 1358 directs his user agent to this URL. The authorization code is 1359 injected into the original client site (or application). 1361 7. The client site uses the authorization code to fetch a token from 1362 the authorization server and associates this token with the 1363 attacker's user account on this site. 1365 8. The attacker may now access the victim's resources using the 1366 client site. 1368 Impact: The attacker gains access to the victim's resources as 1369 associated with his account on the client site. 1371 Countermeasures: 1373 o The attacker will need to use another redirection URI for its 1374 authorization process rather than the target web site because it 1375 needs to intercept the flow. So if the authorization server 1376 associates the authorization code with the redirection URI of a 1377 particular end-user authorization and validates this redirection 1378 URI with the redirection URI passed to the token's endpoint, such 1379 an attack is detected (see Section 5.2.4.5). 1381 o The authorization server may also enforce the usage and validation 1382 of pre-registered redirect URIs (see Section 5.2.3.5). This will 1383 allow for an early recognition of authorization code disclosure to 1384 counterfeit clients. 1386 o For native applications, one could also consider to use 1387 deployment-specific client ids and secrets (see Section 5.2.3.4, 1388 along with the binding of authorization code to client_id (see 1389 Section 5.2.4.4), to detect such an attack because the attacker 1390 does not have access the deployment-specific secret. Thus he will 1391 not be able to exchange the authorization code. 1393 o The client may consider using other flows, which are not 1394 vulnerable to this kind of attack such as "Implicit Grant" or 1395 "Resource Owner Password Credentials" (see Section 4.4.2 or 1396 Section 4.4.3). 1398 4.4.1.8. Threat: CSRF attack against redirect-uri 1400 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP 1401 requests are transmitted from a user that the website trusts or has 1402 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks 1403 on OAuth approvals can allow an attacker to obtain authorization to 1404 OAuth protected resources without the consent of the User. 1406 This attack works against the redirection URI used in the 1407 authorization code flow. An attacker could authorize an 1408 authorization code to their own protected resources on an 1409 authorization server. He then aborts the redirect flow back to the 1410 client on his device and tricks the victim into executing the 1411 redirect back to the client. The client receives the redirect, 1412 fetches the token(s) from the authorization server and associates the 1413 victim's client session with the resources accessible using the 1414 token. 1416 Impact: The user accesses resources on behalf of the attacker. The 1417 effective impact depends on the type of resource accessed. For 1418 example, the user may upload private items to an attacker's 1419 resources. Or when using OAuth in 3rd party login scenarios, the 1420 user may associate his client account with the attacker's identity at 1421 the external identity provider. This way the attacker could easily 1422 access the victim's data at the client by logging in from another 1423 device with his credentials at the external identity provider. 1425 Countermeasures: 1427 o The state parameter should be used to link the authorization 1428 request with the redirection URI used to deliver the access token. 1429 Section 5.3.5 1431 o Client developers and end-user can be educated to not follow 1432 untrusted URLs. 1434 4.4.1.9. Threat: Clickjacking attack against authorization 1436 With Clickjacking, a malicious site loads the target site in a 1437 transparent iFrame (see [iFrame]) overlaid on top of a set of dummy 1438 buttons which are carefully constructed to be placed directly under 1439 important buttons on the target site. When a user clicks a visible 1440 button, they are actually clicking a button (such as an "Authorize" 1441 button) on the hidden page. 1443 Impact: An attacker can steal a user's authentication credentials and 1444 access their resources 1446 Countermeasure 1448 o For newer browsers, avoidance of iFrames during authorization can 1449 be enforced server side by using the X-FRAME-OPTION header - 1450 Section 5.2.2.6 1452 o For older browsers, javascript frame-busting (see [framebusting]) 1453 techniques can be used but may not be effective in all browsers. 1455 4.4.1.10. Threat: Resource Owner Impersonation 1457 When a client requests access to protected resources, the 1458 authorization flow normally involves the resource owner's explicit 1459 response to the access request, either granting or denying access to 1460 the protected resources. A malicious client can exploit knowledge of 1461 the structure of this flow in order to gain authorization without the 1462 resource owner's consent, by transmitting the necessary requests 1463 programmatically, and simulating the flow against the authorization 1464 server. That way, the client may gain access to the victim's 1465 resources without her approval. An authorization server will be 1466 vulnerable to this threat, if it uses non-interactive authentication 1467 mechanisms or splits the authorization flow across multiple pages. 1469 The malicious client might embed a hidden HTML user agent, interpret 1470 the HTML forms sent by the authorization server, and automatically 1471 send the corresponding form post requests. As a pre-requisite, the 1472 attacker must be able to execute the authorization process in the 1473 context of an already authenticated session of the resource owner 1474 with the authorization server. There are different ways to achieve 1475 this: 1477 o The malicious client could abuse an existing session in an 1478 external browser or cross-browser cookies on the particular 1479 device. 1481 o The malicious client could also request authorization for an 1482 initial scope acceptable to the user and then silently abuse the 1483 resulting session in his browser instance to "silently" request 1484 another scope. 1486 o Alternatively, the attacker might exploit an authorization 1487 server's ability to authenticate the resource owner automatically 1488 and without user interactions, e.g. based on certificates. 1490 In all cases, such an attack is limited to clients running on the 1491 victim's device, within the user agent or as native app. 1493 Please note: Such attacks cannot be prevented using CSRF 1494 countermeasures, since the attacker just "executes" the URLs as 1495 prepared by the authorization server including any nonce etc. 1497 Countermeasures: 1499 Authorization servers should decide, based on an analysis of the risk 1500 associated with this threat, whether to detect and prevent this 1501 threat. 1503 In order to prevent such an attack, the authorization server may 1504 force a user interaction based on non-predictable input values as 1505 part of the user consent approval. The authorization server could 1507 o combine password authentication and user consent in a single form, 1509 o make use of CAPTCHAs, or 1511 o or use one-time secrets sent out of band to the resource owner 1512 (e.g. via text or instant message). 1514 Alternatively in order to allow the resource owner to detect abuse, 1515 the authorization server could notify the resource owner of any 1516 approval by appropriate means, e.g. text or instant message or 1517 e-Mail. 1519 4.4.1.11. Threat: DoS, Exhaustion of resources attacks 1521 If an authorization server includes a nontrivial amount of entropy in 1522 authorization codes or access tokens (limiting the number of possible 1523 codes/tokens) and automatically grants either without user 1524 intervention and has no limit on code or access tokens per user, an 1525 attacker could exhaust the pool of authorization codes by repeatedly 1526 directing the user's browser to request code or access tokens. 1528 Countermeasures: 1530 o The authorization server should consider limiting the number of 1531 access tokens granted per user. The authorization server should 1532 include a nontrivial amount of entropy in authorization codes. 1534 4.4.1.12. Threat: DoS using manufactured authorization codes 1536 An attacker who owns a botnet can locate the redirect URIs of clients 1537 that listen on HTTP, access them with random authorization codes, and 1538 cause a large number of HTTPS connections to be concentrated onto the 1539 authorization server. This can result in a DoS attack on the 1540 authorization server. 1542 This attack can still be effective even when CSRF defense/the 'state' 1543 parameter (see Section 4.4.1.8) is deployed on the client side. With 1544 such a defense, the attacker might need to incur an additional HTTP 1545 request to obtain a valid CSRF code/ state parameter. This 1546 apparently cuts down the effectiveness of the attack by a factor of 1547 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost 1548 factor is estimated to be around 3.5x at [ssl-latency]) the attacker 1549 still achieves a magnification of resource utilization at the expense 1550 of the authorization server. 1552 Impact: There are a few effects that the attacker can accomplish with 1553 this OAuth flow that they cannot easily achieve otherwise. 1555 1. Connection laundering: With the clients as the relay between the 1556 attacker and the authorization server, the authorization server 1557 learns little or no information about the identity of the 1558 attacker. Defenses such as rate limiting on the offending 1559 attacker machines are less effective due to the difficulty to 1560 identify the attacking machines. Although an attacker could also 1561 launder its connections through an anonymizing system such as 1562 Tor, the effectiveness of that approach depends on the capacity 1563 of the anonymizing system. On the other hand, a potentially 1564 large number of OAuth clients could be utilized for this attack. 1566 2. Asymmetric resource utilization: The attacker incurs the cost of 1567 an HTTP connection and causes an HTTPS connection to be made on 1568 the authorization server; and the attacker can co-ordinate the 1569 timing of such HTTPS connections across multiple clients 1570 relatively easily. Although the attacker could achieve something 1571 similar, say, by including an iframe pointing to the HTTPS URL of 1572 the authorization server in an HTTP web page and lure web users 1573 to visit that page, timing attacks using such a scheme may be 1574 more difficult as it seems nontrivial to synchronize a large 1575 number of users to simultaneously visit a particular site under 1576 the attacker's control. 1578 Countermeasures 1580 o Though not a complete countermeasure by themselves, CSRF defense 1581 and the 'state' parameter created with secure random codes should 1582 be deployed on the client side. The client should forward the 1583 authorization code to the authorization server only after both the 1584 CSRF token and the 'state' parameter are validated. 1586 o If the client authenticates the user, either through a single- 1587 sign-on protocol or through local authentication, the client 1588 should suspend the access by a user account if the number of 1589 invalid authorization codes submitted by this user exceeds a 1590 certain threshold. 1592 o The authorization server should send an error response to the 1593 client reporting an invalid authorization code and rate limit or 1594 disallow connections from clients whose number of invalid requests 1595 exceeds a threshold. 1597 4.4.2. Implicit Grant 1599 In the implicit grant type flow, the access token is directly 1600 returned to the client as a fragment part of the redirection URI. It 1601 is assumed that the token is not sent to the redirection URI target 1602 as HTTP user agents do not send the fragment part of URIs to HTTP 1603 servers. Thus an attacker cannot eavesdrop the access token on this 1604 communication path and it cannot leak through HTTP referee headers. 1606 4.4.2.1. Threat: Access token leak in transport/end-points 1608 This token might be eavesdropped by an attacker. The token is sent 1609 from server to client via a URI fragment of the redirection URI. If 1610 the communication is not secured or the end-point is not secured, the 1611 token could be leaked by parsing the returned URI. 1613 Impact: the attacker would be able to assume the same rights granted 1614 by the token. 1616 Countermeasures: 1618 o The authorization server should ensure confidentiality (e.g. using 1619 TLS) of the response from the authorization server to the client 1620 (see Section 5.1.1). 1622 4.4.2.2. Threat: Access token leak in browser history 1624 An attacker could obtain the token from the browser's history. Note 1625 this means the attacker needs access to the particular device. 1627 Countermeasures: 1629 o Shorten token duration (see Section 5.1.5.3) and reduced scope of 1630 the token may reduce the impact of that attack (see 1631 Section 5.1.5.1). 1633 o Make responses non-cachable 1635 4.4.2.3. Threat: Malicious client obtains authorization 1637 A malicious client could attempt to obtain a token by fraud. 1639 The same countermeasures as for Section 4.4.1.4 are applicable, 1640 except client authentication. 1642 4.4.2.4. Threat: Manipulation of scripts 1644 A hostile party could act as the client web server and replace or 1645 modify the actual implementation of the client (script). This could 1646 be achieved using DNS or ARP spoofing. This applies to clients 1647 implemented within the Web Browser in a scripting language. 1649 Impact: The attacker could obtain user credential information and 1650 assume the full identity of the user. 1652 Countermeasures: 1654 o The authorization server should authenticate the server from which 1655 scripts are obtained (see Section 5.1.2). 1657 o The client should ensure that scripts obtained have not been 1658 altered in transport (see Section 5.1.1). 1660 o Introduce one time per-use secrets (e.g. client_secret) values 1661 that can only be used by scripts in a small time window once 1662 loaded from a server. The intention would be to reduce the 1663 effectiveness of copying client-side scripts for re-use in an 1664 attackers modified code. 1666 4.4.2.5. Threat: CSRF attack against redirect-uri 1668 CSRF attacks (see Section 4.4.1.8) also work against the redirection 1669 URI used in the implicit grant flow. An attacker could acquire an 1670 access token to their own protected resources. He could then 1671 construct a redirection URI and embed their access token in that URI. 1672 If he can trick the user into following the redirection URI and the 1673 client does not have protection against this attack, the user may 1674 have the attacker's access token authorized within their client. 1676 Impact: The user accesses resources on behalf of the attacker. The 1677 effective impact depends on the type of resource accessed. For 1678 example, the user may upload private items to an attacker's 1679 resources. Or when using OAuth in 3rd party login scenarios, the 1680 user may associate his client account with the attacker's identity at 1681 the external identity provider. This way the attacker could easily 1682 access the victim's data at the client by logging in from another 1683 device with his credentials at the external identity provider. 1685 Countermeasures: 1687 o The state parameter should be used to link the authorization 1688 request with the redirection URI used deliver the access token. 1689 This will ensure the client is not tricked into completing any 1690 redirect callback unless it is linked to an authorization request 1691 the client initiated. The state parameter should be unguessable 1692 and the client should be capable of keeping the state parameter 1693 secret. 1695 o Client developers and end-user can be educated not follow 1696 untrusted URLs. 1698 4.4.3. Resource Owner Password Credentials 1700 The "Resource Owner Password Credentials" grant type (see 1701 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration 1702 reasons, allows a client to request an access token using an end- 1703 users user-id and password along with its own credential. This grant 1704 type has higher risk because it maintains the uid/password anti- 1705 pattern. Additionally, because the user does not have control over 1706 the authorization process, clients using this grant type are not 1707 limited by scope, but instead have potentially the same capabilities 1708 as the user themselves. As there is no authorization step, the 1709 ability to offer token revocation is bypassed. 1711 Because passwords are often used for more than 1 service, this anti- 1712 pattern may also risk whatever else is accessible with the supplied 1713 credential. Additionally any easily derived equivalent (e.g. 1714 joe@example.com and joe@example.net) might easily allow someone to 1715 guess that the same password can be used elsewhere. 1717 Impact: The resource server can only differentiate scope based on the 1718 access token being associated with a particular client. The client 1719 could also acquire long-living tokens and pass them up to a attacker 1720 web service for further abuse. The client, eavesdroppers, or end- 1721 points could eavesdrop user id and password. 1723 Countermeasures: 1725 o Except for migration reasons, minimize use of this grant type 1727 o The authorization server should validate the client id associated 1728 with the particular refresh token with every refresh request - 1729 Section 5.2.2.2 1731 o As per the core Oauth spec, the authorization server must ensure 1732 that these transmissions are protected using transport-layer 1733 mechanisms such as TLS (see Section 5.1.1). 1735 o Rather than encouraging users to use a uid and password, service 1736 providers should instead encourage users not to use the same 1737 password for multiple services. 1739 o Limit use of Resource Owner Password Credential grants to 1740 scenarios where the client application and the authorizing service 1741 are from the same organization. 1743 4.4.3.1. Threat: Accidental exposure of passwords at client site 1745 If the client does not provide enough protection, an attacker or 1746 disgruntled employee could retrieve the passwords for a user. 1748 Countermeasures: 1750 o Use other flows, which do not rely on the client's cooperation for 1751 secure resource owner credential handling 1753 o Use digest authentication instead of plaintext credential 1754 processing 1756 o Obfuscation of passwords in logs 1758 4.4.3.2. Threat: Client obtains scopes without end-user authorization 1760 All interaction with the resource owner is performed by the client. 1761 Thus it might, intentionally or unintentionally, happen that the 1762 client obtains a token with scope unknown for or unintended by the 1763 resource owner. For example, the resource owner might think the 1764 client needs and acquires read-only access to its media storage only 1765 but the client tries to acquire an access token with full access 1766 permissions. 1768 Countermeasures: 1770 o Use other flows, which do not rely on the client's cooperation for 1771 resource owner interaction 1773 o The authorization server may generally restrict the scope of 1774 access tokens (Section 5.1.5.1) issued by this flow. If the 1775 particular client is trustworthy and can be authenticated in a 1776 reliable way, the authorization server could relax that 1777 restriction. Resource owners may prescribe (e.g. in their 1778 preferences) what the maximum scope is for clients using this 1779 flow. 1781 o The authorization server could notify the resource owner by an 1782 appropriate media, e.g. e-Mail, of the grant issued (see 1783 Section 5.1.3). 1785 4.4.3.3. Threat: Client obtains refresh token through automatic 1786 authorization 1788 All interaction with the resource owner is performed by the client. 1789 Thus it might, intentionally or unintentionally, happen that the 1790 client obtains a long-term authorization represented by a refresh 1791 token even if the resource owner did not intend so. 1793 Countermeasures: 1795 o Use other flows, which do not rely on the client's cooperation for 1796 resource owner interaction 1798 o The authorization server may generally refuse to issue refresh 1799 tokens in this flow (see Section 5.2.2.1). If the particular 1800 client is trustworthy and can be authenticated in a reliable way 1801 (see client authentication), the authorization server could relax 1802 that restriction. Resource owners may allow or deny (e.g. in 1803 their preferences) to issue refresh tokens using this flow as 1804 well. 1806 o The authorization server could notify the resource owner by an 1807 appropriate media, e.g. e-Mail, of the refresh token issued (see 1808 Section 5.1.3). 1810 4.4.3.4. Threat: Obtain user passwords on transport 1812 An attacker could attempt to eavesdrop the transmission of end-user 1813 credentials with the grant type "password" between client and server. 1815 Impact: disclosure of a single end-users password. 1817 Countermeasures: 1819 o Confidentiality of Requests - Section 5.1.1 1821 o alternative authentication means, which do not require to send 1822 plaintext credentials over the wire (e.g. Hash-based Message 1823 Authentication Code) 1825 4.4.3.5. Threat: Obtain user passwords from authorization server 1826 database 1828 An attacker may obtain valid username/password combinations from the 1829 authorization server's database by gaining access to the database or 1830 launching a SQL injection attack. 1832 Impact: disclosure of all username/password combinations. The impact 1833 may exceed the domain of the authorization server since many users 1834 tend to use the same credentials on different services. 1836 Countermeasures: 1838 o Credential storage protection can be employed - Section 5.1.4.1 1840 4.4.3.6. Threat: Online guessing 1842 An attacker may try to guess valid username/password combinations 1843 using the grant type "password". 1845 Impact: Revelation of a single username/password combination. 1847 Countermeasures: 1849 o Password policy - Section 5.1.4.2.1 1851 o Lock accounts - Section 5.1.4.2.3 1853 o Tar pit - Section 5.1.4.2.4 1855 o CAPTCHA - Section 5.1.4.2.5 1857 o Consider not to use grant type "password" 1859 o Client authentication (see Section 5.2.3) will provide another 1860 authentication factor and thus hinder the attack. 1862 4.4.4. Client Credentials 1864 Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an 1865 identifier (not secret) combined with an additional means (such as a 1866 matching client secret) of authenticating a client. The threats to 1867 this grant type are similar to Section 4.4.3. 1869 4.5. Refreshing an Access Token 1871 4.5.1. Threat: Eavesdropping refresh tokens from authorization server 1873 An attacker may eavesdrop refresh tokens when they are transmitted 1874 from the authorization server to the client. 1876 Countermeasures: 1878 o As per the core OAuth spec, the Authorization servers must ensure 1879 that these transmissions are protected using transport-layer 1880 mechanisms such as TLS (see Section 5.1.1). 1882 o If end-to-end confidentiality cannot be guaranteed, reducing scope 1883 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for 1884 issued access tokens can be used to reduce the damage in case of 1885 leaks. 1887 4.5.2. Threat: Obtaining refresh token from authorization server 1888 database 1890 This threat is applicable if the authorization server stores refresh 1891 tokens as handles in a database. An attacker may obtain refresh 1892 tokens from the authorization server's database by gaining access to 1893 the database or launching a SQL injection attack. 1895 Impact: disclosure of all refresh tokens 1897 Countermeasures: 1899 o Credential storage protection - Section 5.1.4.1 1901 o Bind token to client id, if the attacker cannot obtain the 1902 required id and secret - Section 5.1.5.8 1904 4.5.3. Threat: Obtain refresh token by online guessing 1906 An attacker may try to guess valid refresh token values and send it 1907 using the grant type "refresh_token" in order to obtain a valid 1908 access token. 1910 Impact: exposure of single refresh token and derivable access tokens. 1912 Countermeasures: 1914 o For handle-based designs - Section 5.1.4.2.2 1916 o For assertion-based designs - Section 5.1.5.9 1918 o Bind token to client id, because the attacker would guess the 1919 matching client id, too (see Section 5.1.5.8) 1921 o Authenticate the client, adds another element the attacker has to 1922 guess (see Section 5.2.3.4) 1924 4.5.4. Threat: Obtain refresh token phishing by counterfeit 1925 authorization server 1927 An attacker could try to obtain valid refresh tokens by proxying 1928 requests to the authorization server. Given the assumption that the 1929 authorization server URL is well-known at development time or can at 1930 least be obtained from a well-known resource server, the attacker 1931 must utilize some kind of spoofing in order to succeed. 1933 Countermeasures: 1935 o Server authentication (as described in Section 5.1.2) 1937 4.6. Accessing Protected Resources 1939 4.6.1. Threat: Eavesdropping access tokens on transport 1941 An attacker could try to obtain a valid access token on transport 1942 between client and resource server. As access tokens are shared 1943 secrets between authorization and resource server, they should be 1944 treated with the same care as other credentials (e.g. end-user 1945 passwords). 1947 Countermeasures: 1949 o Access tokens sent as bearer tokens, should not be sent in the 1950 clear over an insecure channel. As per the core OAuth spec, 1951 transmission of access tokens must be protected using transport- 1952 layer mechanisms such as TLS (see Section 5.1.1). 1954 o A short lifetime reduces impact in case tokens are compromised 1955 (see Section 5.1.5.3). 1957 o The access token can be bound to a client's identifier and require 1958 the client to prove legitimate ownership of the token to the 1959 resource server (see Section 5.4.2). 1961 4.6.2. Threat: Replay authorized resource server requests 1963 An attacker could attempt to replay valid requests in order to obtain 1964 or to modify/destroy user data. 1966 Countermeasures: 1968 o The resource server should utilize transport security measures 1969 (e.g. TLS) in order to prevent such attacks (see Section 5.1.1). 1970 This would prevent the attacker from capturing valid requests. 1972 o Alternatively, the resource server could employ signed requests 1973 (see Section 5.4.3) along with nonces and timestamps in order to 1974 uniquely identify requests. The resource server should detect and 1975 refuse every replayed request. 1977 4.6.3. Threat: Guessing access tokens 1979 Where the token is a handle, the attacker may use attempt to guess 1980 the access token values based on knowledge they have from other 1981 access tokens. 1983 Impact: Access to a single user's data. 1985 Countermeasures: 1987 o Handle Tokens should have a reasonable entropy (see 1988 Section 5.1.4.2.2) in order to make guessing a valid token value 1989 infeasible. 1991 o Assertion (or self-contained token ) tokens contents should be 1992 protected by a digital signature (see Section 5.1.5.9). 1994 o Security can be further strengthened by using a short access token 1995 duration (see Section 5.1.5.2 and Section 5.1.5.3). 1997 4.6.4. Threat: Access token phishing by counterfeit resource server 1999 An attacker may pretend to be a particular resource server and to 2000 accept tokens from a particular authorization server. If the client 2001 sends a valid access token to this counterfeit resource server, the 2002 server in turn may use that token to access other services on behalf 2003 of the resource owner. 2005 Countermeasures: 2007 o Clients should not make authenticated requests with an access 2008 token to unfamiliar resource servers, regardless of the presence 2009 of a secure channel. If the resource server URL is well-known to 2010 the client, it may authenticate the resource servers (see 2011 Section 5.1.2). 2013 o Associate the endpoint URL of the resource server the client 2014 talked to with the access token (e.g. in an audience field) and 2015 validate association at legitimate resource server. The endpoint 2016 URL validation policy may be strict (exact match) or more relaxed 2017 (e.g. same host). This would require to tell the authorization 2018 server the resource server endpoint URL in the authorization 2019 process. 2021 o Associate an access token with a client and authenticate the 2022 client with resource server requests (typically via signature in 2023 order to not disclose secret to a potential attacker). This 2024 prevents the attack because the counterfeit server is assumed to 2025 lack the capability to correctly authenticate on behalf of the 2026 legitimate client to the resource server (Section 5.4.2). 2028 o Restrict the token scope (see Section 5.1.5.1) and or limit the 2029 token to a certain resource server (Section 5.1.5.5). 2031 4.6.5. Threat: Abuse of token by legitimate resource server or client 2033 A legitimate resource server could attempt to use an access token to 2034 access another resource servers. Similarly, a client could try to 2035 use a token obtained for one server on another resource server. 2037 Countermeasures: 2039 o Tokens should be restricted to particular resource servers (see 2040 Section 5.1.5.5). 2042 4.6.6. Threat: Leak of confidential data in HTTP-Proxies 2044 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is 2045 optional. However, [RFC2616] relies on the Authorization and WWW- 2046 Authenticate headers to distinguish authenticated content so that it 2047 can be protected. Proxies and caches, in particular, may fail to 2048 adequately protect requests not using these headers. For example, 2049 private authenticated content may be stored in (and thus retrievable 2050 from) publicly-accessible caches. 2052 Countermeasures: 2054 o Clients and resource servers not using the HTTP Authorization 2055 scheme (OAuth HTTP Authorization Scheme - see Section 5.4.1) 2056 should take care to use Cache-Control headers to minimize the risk 2057 that authenticated content is not protected. Such Clients should 2058 send a Cache-Control header containing the "no-store" option 2059 [RFC2616]. Resource server success (2XX status) responses to 2060 these requests should contain a Cache-Control header with the 2061 "private" option [RFC2616]. 2063 o Reducing scope (see Section 5.1.5.1) and expiry time 2064 (Section 5.1.5.3) for access tokens can be used to reduce the 2065 damage in case of leaks. 2067 4.6.7. Threat: Token leakage via logfiles and HTTP referrers 2069 If access tokens are sent via URI query parameters, such tokens may 2070 leak to log files and the HTTP "referer". 2072 Countermeasures: 2074 o Use authorization headers or POST parameters instead of URI 2075 request parameters (see Section 5.4.1). 2077 o Set logging configuration appropriately 2079 o Prevent unauthorized persons from access to system log files (see 2080 Section 5.1.4.1.1) 2082 o Abuse of leaked access tokens can be prevented by enforcing 2083 authenticated requests (see Section 5.4.2). 2085 o The impact of token leakage may be reduced by limiting scope (see 2086 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing 2087 one time token usage (see Section 5.1.5.4). 2089 5. Security Considerations 2091 This section describes the countermeasures as recommended to mitigate 2092 the threats as described in Section 4. 2094 5.1. General 2096 The general section covers considerations that apply generally across 2097 all OAuth components (client, resource server, token server, and 2098 user-agents). 2100 5.1.1. Confidentiality of Requests 2102 This is applicable to all requests sent from client to authorization 2103 server or resource server. While OAuth provides a mechanism for 2104 verifying the integrity of requests, it provides no guarantee of 2105 request confidentiality. Unless further precautions are taken, 2106 eavesdroppers will have full access to request content and may be 2107 able to mount interception or replay attacks through using content of 2108 request, e.g. secrets or tokens. 2110 Attacks can be mitigated by using transport-layer mechanisms such as 2111 TLS [RFC5246]. A virtual private network (VPN), e.g. based on IPsec 2112 VPN [RFC4301], may considered as well. 2114 Note: this document assumes end-to-end TLS protected connections 2115 between the respective protocol entities. Deployments deviating from 2116 this assumption by offloading TLS in between (e.g. on the data center 2117 edge) must refine this threat model in order to account for the 2118 additional (mainly insider) threat this may cause. 2120 This is a countermeasure against the following threats: 2122 o Replay of access tokens obtained on tokens endpoint or resource 2123 server's endpoint 2125 o Replay of refresh tokens obtained on tokens endpoint 2127 o Replay of authorization codes obtained on tokens endpoint 2128 (redirect?) 2130 o Replay of user passwords and client secrets 2132 5.1.2. Server authentication 2134 HTTPS server authentication or similar means can be used to 2135 authenticate the identity of a server. The goal is to reliably bind 2136 the fully qualified domain name of the server to the public key 2137 presented by the server during connection establishment (see 2138 [RFC2818]). 2140 The client should validate the binding of the server to its domain 2141 name. If the server fails to prove that binding, it is considered a 2142 man-in-the-middle attack. The security measure depends on the 2143 certification authorities the client trusts for that purpose. 2144 Clients should carefully select those trusted CAs and protect the 2145 storage for trusted CA certificates from modifications. 2147 This is a countermeasure against the following threats: 2149 o Spoofing 2151 o Proxying 2153 o Phishing by counterfeit servers 2155 5.1.3. Always keep the resource owner informed 2157 Transparency to the resource owner is a key element of the OAuth 2158 protocol. The user should always be in control of the authorization 2159 processes and get the necessary information to meet informed 2160 decisions. Moreover, user involvement is a further security 2161 countermeasure. The user can probably recognize certain kinds of 2162 attacks better than the authorization server. Information can be 2163 presented/exchanged during the authorization process, after the 2164 authorization process, and every time the user wishes to get informed 2165 by using techniques such as: 2167 o User consent forms 2168 o Notification messages (e.g. e-Mail, SMS, ...). Note that 2169 notifications can be a phishing vector. Messages should be such 2170 that look-alike phishing messages cannot be derived from them. 2172 o Activity/Event logs 2174 o User self-care applications or portals 2176 5.1.4. Credentials 2178 This sections describes countermeasures used to protect all kinds of 2179 credentials from unauthorized access and abuse. Credentials are long 2180 term secrets, such as client secrets and user passwords as well as 2181 all kinds of tokens (refresh and access token) or authorization 2182 codes. 2184 5.1.4.1. Credential Storage Protection 2186 Administrators should undertake industry best practices to protect 2187 the storage of credentials (see for example [owasp]). Such practices 2188 may include but are not limited to the following sub-sections. 2190 5.1.4.1.1. Standard System Security Means 2192 A server system may be locked down so that no attacker may get access 2193 to sensible configuration files and databases. 2195 5.1.4.1.2. Standard SQL Injection Countermeasures 2197 If a client identifier or other authentication component is queried 2198 or compared against a SQL Database it may become possible for an 2199 injection attack to occur if parameters received are not validated 2200 before submission to the database. 2202 o Ensure that server code is using the minimum database privileges 2203 possible to reduce the "surface" of possible attacks. 2205 o Avoid dynamic SQL using concatenated input. If possible, use 2206 static SQL. 2208 o When using dynamic SQL, parameterize queries using bind arguments. 2209 Bind arguments eliminate possibility of SQL injections. 2211 o Filter and sanitize the input. For example, if an identifier has 2212 a known format, ensure that the supplied value matches the 2213 identifier syntax rules. 2215 5.1.4.1.3. No cleartext storage of credentials 2217 The authorization server should not store credentials in clear text. 2218 Typical approaches are to store hashes instead or to encrypt 2219 credentials. If the credential lacks a reasonable entropy level 2220 (because it is a user password) an additional salt will harden the 2221 storage to make offline dictionary attacks more difficult. 2223 Note: Some authentication protocols require the authorization server 2224 to have access to the secret in the clear. Those protocols cannot be 2225 implemented if the server only has access to hashes. Credentials 2226 should strongly encrypted in those cases. 2228 5.1.4.1.4. Encryption of credentials 2230 For client applications, insecurely persisted client credentials are 2231 easy targets for attackers to obtain. Store client credentials using 2232 an encrypted persistence mechanism such as a keystore or database. 2233 Note that compiling client credentials directly into client code 2234 makes client applications vulnerable to scanning as well as difficult 2235 to administer should client credentials change over time. 2237 5.1.4.1.5. Use of asymmetric cryptography 2239 Usage of asymmetric cryptography will free the authorization server 2240 of the obligation to manage credentials. 2242 5.1.4.2. Online attacks on secrets 2244 5.1.4.2.1. Password policy 2246 The authorization server may decide to enforce a complex user 2247 password policy in order to increase the user passwords' entropy to 2248 hinder online password attacks. Note that too much complexity can 2249 increase the liklihood that users re-use passwords or write them down 2250 or otherwise store them insecurely. 2252 5.1.4.2.2. High entropy of secrets 2254 When creating secrets not intended for usage by human users (e.g. 2255 client secrets or token handles), the authorization server should 2256 include a reasonable level of entropy in order to mitigate the risk 2257 of guessing attacks. The token value should be >=128 bits long and 2258 constructed from a cryptographically strong random or pseudo-random 2259 number sequence (see [RFC4086] for best current practice) generated 2260 by the Authorization Server. 2262 5.1.4.2.3. Lock accounts 2264 Online attacks on passwords can be mitigated by locking the 2265 respective accounts after a certain number of failed attempts. 2267 Note: This measure can be abused to lock down legitimate service 2268 users. 2270 5.1.4.2.4. Tar pit 2272 The authorization server may react on failed attempts to authenticate 2273 by username/password by temporarily locking the respective account 2274 and delaying the response for a certain duration. This duration may 2275 increase with the number of failed attempts. The objective is to 2276 slow the attackers attempts on a certain username down. 2278 Note: this may require a more complex and stateful design of the 2279 authorization server. 2281 5.1.4.2.5. Usage of CAPTCHAs 2283 The idea is to prevent programs from automatically checking huge 2284 number of passwords by requiring human interaction. 2286 Note: this has a negative impact on user experience. 2288 5.1.5. Tokens (access, refresh, code) 2290 5.1.5.1. Limit token scope 2292 The authorization server may decide to reduce or limit the scope 2293 associated with a token. The basis of this decision is out of scope, 2294 examples are: 2296 o a client-specific policy, e.g. issue only less powerful tokens to 2297 public clients, 2299 o a service-specific policy, e.g. it a very sensitive service, 2301 o a resource-owner specific setting, or 2303 o combinations of such policies and preferences. 2305 The authorization server may allow different scopes dependent on the 2306 grant type. For example, end-user authorization via direct 2307 interaction with the end-user (authorization code) might be 2308 considered more reliable than direct authorization via grant type 2309 username/password. This means will reduce the impact of the 2310 following threats: 2312 o token leakage 2314 o token issuance to malicious software 2316 o unintended issuance of to powerful tokens with resource owner 2317 credentials flow 2319 5.1.5.2. Expiration time 2321 Tokens should generally expire after a reasonable duration. This 2322 complements and strengthens other security measures (such as 2323 signatures) and reduces the impact of all kinds of token leaks. 2324 Depending on the risk associated with a token leakage, tokens may 2325 expire after a few minutes (e.g. for payment transactions) or stay 2326 valid for hours (e.g. read access to contacts). 2328 The expiration time is determined by a couple of factors, including: 2330 o risk associated to a token leakage 2332 o duration of the underlying access grant, 2334 o duration until the modification of an access grant should take 2335 effect, and 2337 o time required for an attacker to guess or produce valid token. 2339 5.1.5.3. Short expiration time 2341 A short expiration time for tokens is a protection means against the 2342 following threats: 2344 o replay 2346 o reduce impact of token leak 2348 o reduce likelihood of successful online guessing 2350 Note: Short token duration requires more precise clock 2351 synchronisation between authorization server and resource server. 2352 Furthermore, shorter duration may require more token refreshes 2353 (access token) or repeated end-user authorization processes 2354 (authorization code and refresh token). 2356 5.1.5.4. Limit number of usages/ One time usage 2358 The authorization server may restrict the number of requests or 2359 operations which can be performed with a certain token. This 2360 mechanism can be used to mitigate the following threats: 2362 o replay of tokens 2364 o guessing 2366 For example, if an Authorization Server observes more than one 2367 attempt to redeem an authorization code, the Authorization Server may 2368 want to revoke all access tokens granted based on the authorization 2369 code as well as reject the current request. 2371 As with the authorization code, access tokens may also have a limited 2372 number of operations. This forces client applications to either re- 2373 authenticate and use a refresh token to obtain a fresh access token, 2374 or it forces the client to re-authorize the access token by involving 2375 the user. 2377 5.1.5.5. Bind tokens to a particular resource server (Audience) 2379 Authorization servers in multi-service environments may consider 2380 issuing tokens with different content to different resource servers 2381 and to explicitly indicate in the token the target server a token is 2382 intended to be sent to. SAML Assertions (see 2383 [OASIS.saml-core-2.0-os]) use the Audience element for this purpose. 2384 This countermeasure can be used in the following situations: 2386 o It reduces the impact of a successful replay attempt, since the 2387 token is applicable to a single resource server, only. 2389 o It prevents abuse of a token by a rogue resource server or client, 2390 since the token can only be used on that server. It is rejected 2391 by other servers. 2393 o It reduces the impact of a leakage of a valid token to a 2394 counterfeit resource server. 2396 5.1.5.6. Use endpoint address as token audience 2398 This may be used to indicate to a resource server, which endpoint URL 2399 has been used to obtain the token. This measure will allow to detect 2400 requests from a counterfeit resource server, since such token will 2401 contain the endpoint URL of that server. 2403 5.1.5.7. Audience and Token scopes 2405 Deployments may consider only using tokens with explicitly defined 2406 scope, where every scope is associated with a particular resource 2407 server. This approach can be used to mitigate attacks, where a 2408 resource server or client uses a token for a different then the 2409 intended purpose. 2411 5.1.5.8. Bind token to client id 2413 An authorization server may bind a token to a certain client 2414 identifier. This identifier should be validated for every request 2415 with that token. This means can be used, to 2417 o detect token leakage and 2419 o prevent token abuse. 2421 Note: Validating the client identifier may require the target server 2422 to authenticate the client's identifier. This authentication can be 2423 based on secrets managed independent of the token (e.g. pre- 2424 registered client id/secret on authorization server) or sent with the 2425 token itself (e.g. as part of the encrypted token content). 2427 5.1.5.9. Signed tokens 2429 Self-contained tokens should be signed in order to detect any attempt 2430 to modify or produce faked tokens (e.g. Hash-based Message 2431 Authentication Code or digital signatures) 2433 5.1.5.10. Encryption of token content 2435 Self-contained tokens may be encrypted for confidentiality reasons or 2436 to protect system internal data. Depending on token format, keys 2437 (e.g. symmetric keys) may have to be distributed between server 2438 nodes. The method of distribution should be defined by the token and 2439 encryption used. 2441 5.1.5.11. Assertion formats 2443 For service providers intending to implement an assertion-based token 2444 design it is highly recommended to adopt a standard assertion format 2445 (such as SAML [OASIS.saml-core-2.0-os] or JWT 2446 [I-D.ietf-oauth-json-web-token]. 2448 5.1.6. Access tokens 2450 The following measures should be used to protect access tokens 2452 o keep them in transient memory (accessible by the client 2453 application only) 2455 o Pass tokens securely using secure transport (TLS) 2457 o Ensure client applications do not share tokens with 3rd parties 2459 5.2. Authorization Server 2461 This section describes considerations related to the OAuth 2462 Authorization Server end-point. 2464 5.2.1. Authorization Codes 2466 5.2.1.1. Automatic revocation of derived tokens if abuse is detected 2468 If an Authorization Server observes multiple attempts to redeem an 2469 authorization grant (e.g. such as an authorization code), the 2470 Authorization Server may want to revoke all tokens granted based on 2471 the authorization grant. 2473 5.2.2. Refresh tokens 2475 5.2.2.1. Restricted issuance of refresh tokens 2477 The authorization server may decide based on an appropriate policy 2478 not to issue refresh tokens. Since refresh tokens are long term 2479 credentials, they may be subject theft. For example, if the 2480 authorization server does not trust a client to securely store such 2481 tokens, it may refuse to issue such a client a refresh token. 2483 5.2.2.2. Binding of refresh token to client_id 2485 The authorization server should match every refresh token to the 2486 identifier of the client to whom it was issued. The authorization 2487 server should check that the same client_id is present for every 2488 request to refresh the access token. If possible (e.g. confidential 2489 clients), the authorization server should authenticate the respective 2490 client. 2492 This is a countermeasure against refresh token theft or leakage. 2494 Note: This binding should be protected from unauthorized 2495 modifications. 2497 5.2.2.3. Refresh Token Rotation 2499 Refresh token rotation is intended to automatically detect and 2500 prevent attempts to use the same refresh token in parallel from 2501 different apps/devices. This happens if a token gets stolen from the 2502 client and is subsequently used by the attacker and the legitimate 2503 client. The basic idea is to change the refresh token value with 2504 every refresh request in order to detect attempts to obtain access 2505 tokens using old refresh tokens. Since the authorization server 2506 cannot determine whether the attacker or the legitimate client is 2507 trying to access, in case of such an access attempt the valid refresh 2508 token and the access authorization associated with it are both 2509 revoked. 2511 The OAuth specification supports this measure in that the tokens 2512 response allows the authorization server to return a new refresh 2513 token even for requests with grant type "refresh_token". 2515 Note: this measure may cause problems in clustered environments since 2516 usage of the currently valid refresh token must be ensured. In such 2517 an environment, other measures might be more appropriate. 2519 5.2.2.4. Refresh Token Revocation 2521 The authorization server may allow clients or end-users to explicitly 2522 request the invalidation of refresh tokens. A mechanism to revoke 2523 tokens is specified in [I-D.ietf-oauth-revocation]. 2525 This is a countermeasure against: 2527 o device theft, 2529 o impersonation of resource owner, or 2531 o suspected compromised client applications. 2533 5.2.2.5. Device identification 2535 The authorization server may require to bind authentication 2536 credentials to a device identifier. The _International Mobile 2537 Station Equipment Identity_ [IMEI] is one example of such an 2538 identifier, there are also operating system specific identifiers. 2539 The authorization server could include such an identifier when 2540 authenticating user credentials in order to detect token theft from a 2541 particular device. 2543 Note: Any implementation should consider potential privacy 2544 implications of using device identifiers. 2546 5.2.2.6. X-FRAME-OPTION header 2548 For newer browsers, avoidance of iFrames can be enforced server side 2549 by using the X-FRAME-OPTION header (see 2550 [I-D.gondrom-x-frame-options]). This header can have two values, 2551 "DENY" and "SAMEORIGIN", which will block any framing or framing by 2552 sites with a different origin, respectively. The value "ALLOW-FROM" 2553 allows iFrames for a list of trusted origins. 2555 This is a countermeasure against the following threats: 2557 o Clickjacking attacks 2559 5.2.3. Client authentication and authorization 2561 As described in Section 3 (Security Features), clients are 2562 identified, authenticated and authorized for several purposes, such 2563 as a 2565 o Collate requests to the same client, 2567 o Indicate to the user the client is recognized by the authorization 2568 server, 2570 o Authorize access of clients to certain features on the 2571 authorization or resource server, and 2573 o Log a client identifier to log files for analysis or statistics. 2575 Due to the different capabilities and characteristics of the 2576 different client types, there are different ways to support these 2577 objectives, which will be described in this section. Authorization 2578 server providers should be aware of the security policy and 2579 deployment of a particular clients and adapt its treatment 2580 accordingly. For example, one approach could be to treat all clients 2581 as less trustworthy and unsecure. On the other extreme, a service 2582 provider could activate every client installation individually by an 2583 administrator and that way gain confidence in the identity of the 2584 software package and the security of the environment the client is 2585 installed in. And there are several approaches in between. 2587 5.2.3.1. Don't issue secrets to client with inappropriate security 2588 policy 2590 Authorization servers should not issue secrets to clients that cannot 2591 protect secrets ("public" clients). This reduces probability of the 2592 server treating the client as strongly authenticated. 2594 For example, it is of limited benefit to create a single client id 2595 and secret which is shared by all installations of a native 2596 application. Such a scenario requires that this secret must be 2597 transmitted from the developer via the respective distribution 2598 channel, e.g. an application market, to all installations of the 2599 application on end-user devices. A secret, burned into the source 2600 code of the application or a associated resource bundle, is not 2601 protected from reverse engineering. Secondly, such secrets cannot be 2602 revoked since this would immediately put all installations out of 2603 work. Moreover, since the authorization server cannot really trust 2604 the client's identifier, it would be dangerous to indicate to end- 2605 users the trustworthiness of the client. 2607 There are other ways to achieve a reasonable security level, as 2608 described in the following sections. 2610 5.2.3.2. Public clients without secret require user consent 2612 Authorization servers should not allow automatic authorization for 2613 public clients. The authorization may issue an individual client id, 2614 but should require that all authorizations are approved by the end- 2615 user. This is a countermeasure for clients without secret against 2616 the following threats: 2618 o Impersonation of public client applications 2620 5.2.3.3. Client_id only in combination with redirect_uri 2622 The authorization may issue a client_id and bind the client_id to a 2623 certain pre-configured redirect_uri. Any authorization request with 2624 another redirection URI is refused automatically. Alternatively, the 2625 authorization server should not accept any dynamic redirection URI 2626 for such a client_id and instead always redirect to the well-known 2627 pre-configured redirection URI. This is a countermeasure for clients 2628 without secrets against the following threats: 2630 o Cross-site scripting attacks 2632 o Impersonation of public client applications 2634 5.2.3.4. Installation-specific client secrets 2636 An authorization server may issue separate client identifiers and 2637 corresponding secrets to the different installations of a particular 2638 client (i.e. software package). The effect of such an approach would 2639 be to turn otherwise "public" clients back into "confidential" 2640 clients. 2642 For web applications, this could mean to create one client_id and 2643 client_secret per web site a software package is installed on. So 2644 the provider of that particular site could request client id and 2645 secret from the authorization server during setup of the web site. 2646 This would also allow to validate some of the properties of that web 2647 site, such as redirection URI, website URL, and whatever proofs 2648 useful. The web site provider has to ensure the security of the 2649 client secret on the site. 2651 For native applications, things are more complicated because every 2652 copy of a particular application on any device is a different 2653 installation. Installation-specific secrets in this scenario will 2654 require 2656 1. Either to obtain a client_id and client_secret during download 2657 process from the application market, or 2659 2. During installation on the device. 2661 Either approach will require an automated mechanism for issuing 2662 client ids and secrets, which is currently not defined by OAuth. 2664 The first approach would allow to achieve a certain level of trust in 2665 the authenticity of the application, whereas the second option only 2666 allows to authenticate the installation but not to validate 2667 properties of the client. But this would at least help to prevent 2668 several replay attacks. Moreover, installation-specific client_id 2669 and secret allow to selectively revoke all refresh tokens of a 2670 specific installation at once. 2672 5.2.3.5. Validation of pre-registered redirect_uri 2674 An authorization server should require all clients to register their 2675 redirect_uri and the redirect_uri should be the full URI as defined 2676 in [I-D.ietf-oauth-v2]. The way this registration is performed is 2677 out of scope of this document. As per the core spec, every actual 2678 redirection URI sent with the respective client_id to the end-user 2679 authorization endpoint must match the registered redirection URI. 2680 Where it does not match, the authorization server should assume the 2681 inbound GET request has been sent by an attacker and refuse it. 2682 Note: the authorization server should not redirect the user agent 2683 back to the redirection URI of such an authorization request. 2684 Validating the pre-registered redirect_uri is a countermeasure 2685 against the following threats: 2687 o Authorization code leakage through counterfeit web site: allows to 2688 detect attack attempts already after first redirect to end-user 2689 authorization endpoint (Section 4.4.1.7). 2691 o Open Redirector attack via client redirection endpoint. ( 2692 Section 4.1.5. ) 2694 o Open Redirector phishing attack via authorization server 2695 redirection endpoint ( Section 4.2.4 ) 2697 The underlying assumption of this measure is that an attacker will 2698 need to use another redirection URI in order to get access to the 2699 authorization code. Deployments might consider the possibility of an 2700 attacker using spoofing attacks to a victims device to circumvent 2701 this security measure. 2703 Note: Pre-registering clients might not scale in some deployments 2704 (manual process) or require dynamic client registration (not 2705 specified yet). With the lack of dynamic client registration, pre- 2706 registered "redirect_uri" only works for clients bound to certain 2707 deployments at development/configuration time. As soon as dynamic 2708 resource server discovery is required, the pre-registered 2709 redirect_uri may be no longer feasible. 2711 5.2.3.6. Client secret revocation 2713 An authorization server may revoke a client's secret in order to 2714 prevent abuse of a revealed secret. 2716 Note: This measure will immediately invalidate any authorization code 2717 or refresh token issued to the respective client. This might be 2718 unintentionally impact client identifiers and secrets used across 2719 multiple deployments of a particular native or web application. 2721 This a countermeasure against: 2723 o Abuse of revealed client secrets for private clients 2725 5.2.3.7. Use strong client authentication (e.g. client_assertion / 2726 client_token) 2728 By using an alternative form of authentication such as client 2729 assertion [I-D.ietf-oauth-assertions], the need to distribute a 2730 client_secret is eliminated. This may require the use of a secure 2731 private key store or other supplemental authentication system as 2732 specified by the client assertion issuer in its authentication 2733 process. 2735 5.2.4. End-user authorization 2737 This secion involves considerations for authorization flows involving 2738 the end-user. 2740 5.2.4.1. Automatic processing of repeated authorizations requires 2741 client validation 2743 Authorization servers should NOT automatically process repeat 2744 authorizations where the client is not authenticated through a client 2745 secret or some other authentication mechanism such as a signed 2746 authentication assertion certificate (Section 5.2.3.7 Use strong 2747 client authentication (e.g. client_assertion / client_token)) or 2748 validation of a pre-registered redirect URI (Section 5.2.3.5 2749 Validation of pre-registered redirection URI ). 2751 5.2.4.2. Informed decisions based on transparency 2753 The authorization server should clearly explain to the end-user what 2754 happens in the authorization process and what the consequences are. 2755 For example, the user should understand what access he is about to 2756 grant to which client for what duration. It should also be obvious 2757 to the user, whether the server is able to reliably certify certain 2758 client properties (web site URL, security policy). 2760 5.2.4.3. Validation of client properties by end-user 2762 In the authorization process, the user is typically asked to approve 2763 a client's request for authorization. This is an important security 2764 mechanism by itself because the end-user can be involved in the 2765 validation of client properties, such as whether the client name 2766 known to the authorization server fits the name of the web site or 2767 the application the end-user is using. This measure is especially 2768 helpful in situations where the authorization server is unable to 2769 authenticate the client. It is a countermeasure against: 2771 o Malicious application 2773 o A client application masquerading as another client 2775 5.2.4.4. Binding of authorization code to client_id 2777 The authorization server should bind every authorization code to the 2778 id of the respective client which initiated the end-user 2779 authorization process. This measure is a countermeasure against: 2781 o replay of authorization codes with different client credentials 2782 since an attacker cannot use another client_id to exchange an 2783 authorization code into a token 2785 o Online guessing of authorization codes 2787 Note: This binding should be protected from unauthorized 2788 modifications (e.g. using protected memory and/or a secure database). 2790 5.2.4.5. Binding of authorization code to redirect_uri 2792 The authorization server should be able to bind every authorization 2793 code to the actual redirection URI used as redirect target of the 2794 client in the end-user authorization process. This binding should be 2795 validated when the client attempts to exchange the respective 2796 authorization code for an access token. This measure is a 2797 countermeasure against authorization code leakage through counterfeit 2798 web sites since an attacker cannot use another redirection URI to 2799 exchange an authorization code into a token. 2801 5.3. Client App Security 2803 This section deals with considerations for client applications. 2805 5.3.1. Don't store credentials in code or resources bundled with 2806 software packages 2808 Because of the numbers of copies of client software, there is limited 2809 benefit to create a single client id and secret which is shared by 2810 all installations of an application. Such an application by itself 2811 would be considered a "public" client as it cannot be presumed to be 2812 able to keep client secrets. A secret, burned into the source code 2813 of the application or an associated resource bundle, cannot be 2814 protected from reverse engineering. Secondly, such secrets cannot be 2815 revoked since this would immediately put all installations out of 2816 work. Moreover, since the authorization server cannot really trust 2817 the client's identifier, it would be dangerous to indicate to end- 2818 users the trustworthiness of the client. 2820 5.3.2. Standard web server protection measures (for config files and 2821 databases) 2823 Use standard web server protection measures - Section 5.3.2 2825 5.3.3. Store secrets in a secure storage 2827 The are different way to store secrets of all kinds (tokens, client 2828 secrets) securely on a device or server. 2830 Most multi-user operating systems segregate the personal storage of 2831 the different system users. Moreover, most modern smartphone 2832 operating systems even support to store app-specific data in separate 2833 areas of the file systems and protect it from access by other 2834 applications. Additionally, applications can implements confidential 2835 data itself using a user-supplied secret, such as PIN or password. 2837 Another option is to swap refresh token storage to a trusted backend 2838 server. This mean in turn requires a resilient authentication 2839 mechanisms between client and backend server. Note: Applications 2840 should ensure that confidential data is kept confidential even after 2841 reading from secure storage, which typically means to keep this data 2842 in the local memory of the application. 2844 5.3.4. Utilize device lock to prevent unauthorized device access 2846 On a typical modern phone, there are many "device lock" options which 2847 can be utilized to provide additional protection where a device is 2848 stolen or misplaced. These include PINs, passwords and other 2849 biomtric featres such as "face recognition". These are not equal in 2850 the level of security they provide. 2852 5.3.5. Link state parameter to user agent session 2854 The state parameter is used to link client requests and prevent CSRF 2855 attacks, for example against the redirection URI. An attacker could 2856 inject their own authorization code or access token, which can result 2857 in the client using an access token associated with the attacker's 2858 protected resources rather than the victim's (e.g. save the victim's 2859 bank account information to a protected resource controlled by the 2860 attacker). 2862 The client should utilize the "state" request parameter to send the 2863 authorization server a value that binds the request to the user- 2864 agent's authenticated state (e.g. a hash of the session cookie used 2865 to authenticate the user-agent) when making an authorization request. 2866 Once authorization has been obtained from the end-user, the 2867 authorization server redirects the end-user's user-agent back to the 2868 client with the required binding value contained in the "state" 2869 parameter. 2871 The binding value enables the client to verify the validity of the 2872 request by matching the binding value to the user- agent's 2873 authenticated state. 2875 5.4. Resource Servers 2877 The following section details security considerations for resource 2878 servers. 2880 5.4.1. Authorization headers 2882 Authorization headers are recognized and specially treated by HTTP 2883 proxies and servers. Thus the usage of such headers for sending 2884 access tokens to resource servers reduces the likelihood of leakage 2885 or unintended storage of authenticated requests in general and 2886 especially Authorization headers. 2888 5.4.2. Authenticated requests 2890 An authorization server may bind tokens to a certain client 2891 identifier and enable resource servers to be able to validate that 2892 association on resource access. This will require the resource 2893 server to authenticate the originator of a request as the legitimate 2894 owner of a particular token. There are a couple of options to 2895 implement this countermeasure: 2897 o The authorization server may associate the client identifier with 2898 the token (either internally or in the payload of an self- 2899 contained token). The client then uses client certificate-based 2900 HTTP authentication on the resource server's endpoint to 2901 authenticate its identity and the resource server validates the 2902 name with the name referenced by the token. 2904 o same as before, but the client uses his private key to sign the 2905 request to the resource server (public key is either contained in 2906 the token or sent along with the request) 2908 o Alternatively, the authorization server may issue a token-bound 2909 secret, which the client uses to MAC (message authentication code) 2910 the request (see [I-D.ietf-oauth-v2-http-mac]). The resource 2911 server obtains the secret either directly from the authorization 2912 server or it is contained in an encrypted section of the token. 2913 That way the resource server does not "know" the client but is 2914 able to validate whether the authorization server issued the token 2915 to that client 2917 Authenticated requests are a countermeasure against abuse of tokens 2918 by counterfeit resource servers. 2920 5.4.3. Signed requests 2922 A resource server may decide to accept signed requests only, either 2923 to replace transport level security measures or to complement such 2924 measures. Every signed request should be uniquely identifiable and 2925 should not be processed twice by the resource server. This 2926 countermeasure helps to mitigate: 2928 o modifications of the message and 2930 o replay attempts 2932 5.5. A Word on User Interaction and User-Installed Apps 2934 OAuth, as a security protocol, is distinctive in that its flow 2935 usually involves significant user interaction, making the end user a 2936 part of the security model. This creates some important difficulties 2937 in defending against some of the threats discussed above. Some of 2938 these points have already been made, but it's worth repeating and 2939 highlighting them here. 2941 o End users must understand what they are being asked to approve 2942 (see Section Section 5.2.4.1). Users often do not have the 2943 expertise to understand the ramifications of saying "yes" to an 2944 authorization request. and are likely not to be able to see subtle 2945 differences in wording of requests. Malicious software can 2946 confuse the user, tricking the user into approving almost 2947 anything. 2949 o End-user devices are prone to software compromise. This has been 2950 a long-standing problem, with frequent attacks on web browsers and 2951 other parts of the user's system. But with increasing popularity 2952 of user-installed "apps", the threat posed by compromised or 2953 malicious end-user software is very strong, and is one that is 2954 very difficult to mitigate. 2956 o Be aware that users will demand to install and run such apps, and 2957 that compromised or malicious ones can steal credentials at many 2958 points in the data flow. They can intercept the very user login 2959 credentials that OAuth is designed to protect. They can request 2960 authorization far beyond what they have led the user to understand 2961 and approve. They can automate a response on behalf of the user, 2962 hiding the whole process. No solution is offered here, because 2963 none is known; this remains in the space between better security 2964 and better usability. 2966 o Addressing these issues by restricting the use of user-installed 2967 software may be practical in some limited environments, and can be 2968 used as a countermeasure in those cases. Such restrictions are 2969 not practical in the general case, and mechanisms for after-the- 2970 fact recovery should be in place. 2972 o While end users are mostly incapable of properly vetting 2973 applications they load onto their devices, those who deploy 2974 Authorization Servers might have tools at their disposal to 2975 mitigate malicious Clients. For example, a well run Authorization 2976 Server must only assert client properties to the end-user it is 2977 effectively capable of validating, explicitely point out which 2978 properties it cannot validate, and indicate to the end-user the 2979 risk associated with granting access to the particular client. 2981 6. IANA Considerations 2983 This document makes no request of IANA. 2985 Note to RFC Editor: this section may be removed on publication as an 2986 RFC. 2988 7. Acknowledgements 2990 We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu, 2991 Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward, 2992 Niv Steingarten, Tim Bray, and James H. Manger for their comments and 2993 contributions. 2995 8. Informative References 2997 [I-D.gondrom-x-frame-options] 2998 Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options", 2999 draft-gondrom-x-frame-options-00 (work in progress), 3000 March 2012. 3002 [I-D.ietf-oauth-assertions] 3003 Jones, M., Campbell, B., and Y. Goland, "OAuth 2.0 3004 Assertion Profile", draft-ietf-oauth-assertions-03 (work 3005 in progress), May 2012. 3007 [I-D.ietf-oauth-json-web-token] 3008 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 3009 (JWT)", draft-ietf-oauth-json-web-token-00 (work in 3010 progress), May 2012. 3012 [I-D.ietf-oauth-revocation] 3013 Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token 3014 Revocation", draft-ietf-oauth-revocation-00 (work in 3015 progress), May 2012. 3017 [I-D.ietf-oauth-v2] 3018 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 3019 2.0 Authorization Framework", draft-ietf-oauth-v2-28 (work 3020 in progress), June 2012. 3022 [I-D.ietf-oauth-v2-bearer] 3023 Jones, M., Hardt, D., and D. Recordon, "The OAuth 2.0 3024 Authorization Framework: Bearer Token Usage", 3025 draft-ietf-oauth-v2-bearer-21 (work in progress), 3026 June 2012. 3028 [I-D.ietf-oauth-v2-http-mac] 3029 Hammer-Lahav, E., "HTTP Authentication: MAC Access 3030 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in 3031 progress), February 2012. 3033 [IMEI] 3GPP, "International Mobile station Equipment Identities 3034 (IMEI)", 3GPP TS 22.016 3.3.0, July 2002. 3036 [OASIS.saml-core-2.0-os] 3037 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 3038 "Assertions and Protocol for the OASIS Security Assertion 3039 Markup Language (SAML) V2.0", OASIS Standard saml-core- 3040 2.0-os, March 2005. 3042 [OASIS.sstc-gross-sec-analysis-response-01] 3043 Linn, J., Ed. and P. Mishra, Ed., "SSTC Response to 3044 "Security Analysis of the SAML Single Sign-on Browser/ 3045 Artifact Profile"", January 2005. 3047 [OASIS.sstc-saml-bindings-1.1] 3048 Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed., 3049 "Bindings and Profiles for the OASIS Security Assertion 3050 Markup Language (SAML) V1.1", September 2003. 3052 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 3053 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 3054 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 3056 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3058 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness 3059 Requirements for Security", BCP 106, RFC 4086, June 2005. 3061 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 3062 Kerberos Network Authentication Service (V5)", RFC 4120, 3063 July 2005. 3065 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 3066 Internet Protocol", RFC 4301, December 2005. 3068 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 3069 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 3071 [framebusting] 3072 Rydstedt, G., Bursztein, Boneh, D., and C. Jackson, 3073 "Busting Frame Busting: a Study of Clickjacking 3074 Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0 3075 Security and Privacy Workshop, 2010. 3077 [gross-sec-analysis] 3078 Gross, T., "Security Analysis of the SAML Single Sign-on 3079 Browser/Artifact Profile, 19th Annual Computer Security 3080 Applications Conference, Las Vegas", December 2003. 3082 [iFrame] World Wide Web Consortium, "Frames in HTML documents", 3083 W3C HTML 4.01, Dec 1999. 3085 [owasp] "Open Web Application Security Project Home Page", 3086 . 3088 [portable-contacts] 3089 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008, 3090 . 3092 [ssl-latency] 3093 Sissel, J., Ed., "SSL handshake latency and HTTPS 3094 optimizations", June 2010. 3096 Appendix A. Document History 3098 [[ to be removed by RFC editor before publication as an RFC ]] 3100 draft-lodderstedt-oauth-security-01 3102 o section 4.4.1.2 - changed "resource server" to "client" in 3103 countermeasures description. 3105 o section 4.4.1.6 - changed "client shall authenticate the server" 3106 to "The browser shall be utilized to authenticate the redirection 3107 URI of the client" 3109 o section 5 - general review and alignment with public/confidential 3110 client terms 3112 o all sections - general clean-up and typo corrections 3114 draft-ietf-oauth-v2-threatmodel-00 3116 o section 3.4 - added the purposes for using authorization codes. 3118 o extended section 4.4.1.1 3120 o merged 4.4.1.5 into 4.4.1.2 3122 o corrected some typos 3123 o reformulated "session fixation", renamed respective sections into 3124 "authorization code disclosure through counterfeit client" 3126 o added new section "User session impersonation" 3128 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2, 3129 5.1.4.1.4, 5.2.3.5 3131 o added new threat "DoS using manufactured authorization codes" as 3132 proposed by Peifung E Lam 3134 o added XSRF and clickjacking (incl. state parameter explanation) 3136 o changed sub-section order in section 4.4.1 3138 o incorporated feedback from Skylar Woodward (client secrets) and 3139 Shane B Weeden (refresh tokens as client instance secret) 3141 o aligned client section with core draft's client type definition 3143 o converted I-D into WG document 3145 draft-ietf-oauth-v2-threatmodel-01 3147 o Alignment of terminology with core draft 22 (private/public 3148 client, redirect URI validation policy, replaced definition of the 3149 client categories by reference to respective core section) 3151 o Synchronisation with the core's security consideration section 3152 (UPDATE 10.12 CSRF, NEW 10.14/15) 3154 o Added Resource Owner Impersonation 3156 o Improved section 5 3158 o Renamed Refresh Token Replacement to Refresh Token Rotation 3160 draft-ietf-oauth-v2-threatmodel-02 3162 o Incoporated Tim Bray's review comments (e.g. removed all normative 3163 language) 3165 draft-ietf-oauth-v2-threatmodel-03 3167 o removed 2119 boilerplate and normative reference 3169 o incorporated shepherd review feedback 3170 o incorporated AD review feedback 3172 Authors' Addresses 3174 Torsten Lodderstedt (editor) 3175 Deutsche Telekom AG 3177 Email: torsten@lodderstedt.net 3179 Mark McGloin 3180 IBM 3182 Email: mark.mcgloin@ie.ibm.com 3184 Phil Hunt 3185 Oracle Corporation 3187 Email: phil.hunt@yahoo.com