idnits 2.17.1
draft-ietf-oauth-v2-threatmodel-07.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 (August 14, 2012) is 4272 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-18) exists of
draft-ietf-oauth-assertions-04
== Outdated reference: A later version (-32) exists of
draft-ietf-oauth-json-web-token-03
== Outdated reference: A later version (-11) exists of
draft-ietf-oauth-revocation-00
== 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 2818
(Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 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: February 15, 2013 IBM
6 P. Hunt
7 Oracle Corporation
8 August 14, 2012
10 OAuth 2.0 Threat Model and Security Considerations
11 draft-ietf-oauth-v2-threatmodel-07
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 February 15, 2013.
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.1.13. Threat: Code substitution (OAuth Login) . . . . . 35
117 4.4.2. Implicit Grant . . . . . . . . . . . . . . . . . . . . 36
118 4.4.2.1. Threat: Access token leak in
119 transport/end-points . . . . . . . . . . . . . . . 36
120 4.4.2.2. Threat: Access token leak in browser history . . . 36
121 4.4.2.3. Threat: Malicious client obtains authorization . . 36
122 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37
123 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 37
124 4.4.2.6. Threat: Token substitution (OAuth Login) . . . . . 38
125 4.4.3. Resource Owner Password Credentials . . . . . . . . . 39
126 4.4.3.1. Threat: Accidental exposure of passwords at
127 client site . . . . . . . . . . . . . . . . . . . 40
128 4.4.3.2. Threat: Client obtains scopes without end-user
129 authorization . . . . . . . . . . . . . . . . . . 40
130 4.4.3.3. Threat: Client obtains refresh token through
131 automatic authorization . . . . . . . . . . . . . 41
132 4.4.3.4. Threat: Obtain user passwords on transport . . . . 41
133 4.4.3.5. Threat: Obtain user passwords from
134 authorization server database . . . . . . . . . . 41
135 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42
136 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 42
137 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 42
138 4.5.1. Threat: Eavesdropping refresh tokens from
139 authorization server . . . . . . . . . . . . . . . . . 42
140 4.5.2. Threat: Obtaining refresh token from authorization
141 server database . . . . . . . . . . . . . . . . . . . 43
142 4.5.3. Threat: Obtain refresh token by online guessing . . . 43
143 4.5.4. Threat: Obtain refresh token phishing by
144 counterfeit authorization server . . . . . . . . . . . 43
146 4.6. Accessing Protected Resources . . . . . . . . . . . . . . 44
147 4.6.1. Threat: Eavesdropping access tokens on transport . . . 44
148 4.6.2. Threat: Replay authorized resource server requests . . 44
149 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45
150 4.6.4. Threat: Access token phishing by counterfeit
151 resource server . . . . . . . . . . . . . . . . . . . 45
152 4.6.5. Threat: Abuse of token by legitimate resource
153 server or client . . . . . . . . . . . . . . . . . . . 46
154 4.6.6. Threat: Leak of confidential data in HTTP-Proxies . . 46
155 4.6.7. Threat: Token leakage via logfiles and HTTP
156 referrers . . . . . . . . . . . . . . . . . . . . . . 46
157 5. Security Considerations . . . . . . . . . . . . . . . . . . . 47
158 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 47
159 5.1.1. Confidentiality of Requests . . . . . . . . . . . . . 47
160 5.1.2. Server authentication . . . . . . . . . . . . . . . . 48
161 5.1.3. Always keep the resource owner informed . . . . . . . 48
162 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49
163 5.1.4.1. Credential Storage Protection . . . . . . . . . . 49
164 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 50
165 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 51
166 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 51
167 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52
168 5.1.5.3. Short expiration time . . . . . . . . . . . . . . 52
169 5.1.5.4. Limit number of usages/ One time usage . . . . . . 53
170 5.1.5.5. Bind tokens to a particular resource server
171 (Audience) . . . . . . . . . . . . . . . . . . . . 53
172 5.1.5.6. Use endpoint address as token audience . . . . . . 53
173 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54
174 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54
175 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 54
176 5.1.5.10. Encryption of token content . . . . . . . . . . . 54
177 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 54
178 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55
179 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55
180 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55
181 5.2.1.1. Automatic revocation of derived tokens if
182 abuse is detected . . . . . . . . . . . . . . . . 55
183 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 55
184 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 55
185 5.2.2.2. Binding of refresh token to client_id . . . . . . 55
186 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56
187 5.2.2.4. Refresh Token Revocation . . . . . . . . . . . . . 56
188 5.2.2.5. Device identification . . . . . . . . . . . . . . 56
189 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57
190 5.2.3. Client authentication and authorization . . . . . . . 57
191 5.2.3.1. Don't issue secrets to client with
192 inappropriate security policy . . . . . . . . . . 57
193 5.2.3.2. Public clients without secret require user
194 consent . . . . . . . . . . . . . . . . . . . . . 58
195 5.2.3.3. Client_id only in combination with redirect_uri . 58
196 5.2.3.4. Installation-specific client secrets . . . . . . . 58
197 5.2.3.5. Validation of pre-registered redirect_uri . . . . 59
198 5.2.3.6. Client secret revocation . . . . . . . . . . . . . 60
199 5.2.3.7. Use strong client authentication (e.g.
200 client_assertion / client_token) . . . . . . . . . 60
201 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 60
202 5.2.4.1. Automatic processing of repeated
203 authorizations requires client validation . . . . 61
204 5.2.4.2. Informed decisions based on transparency . . . . . 61
205 5.2.4.3. Validation of client properties by end-user . . . 61
206 5.2.4.4. Binding of authorization code to client_id . . . . 61
207 5.2.4.5. Binding of authorization code to redirect_uri . . 62
208 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 62
209 5.3.1. Don't store credentials in code or resources
210 bundled with software packages . . . . . . . . . . . . 62
211 5.3.2. Standard web server protection measures (for
212 config files and databases) . . . . . . . . . . . . . 62
213 5.3.3. Store secrets in a secure storage . . . . . . . . . . 62
214 5.3.4. Utilize device lock to prevent unauthorized device
215 access . . . . . . . . . . . . . . . . . . . . . . . . 63
216 5.3.5. Link state parameter to user agent session . . . . . . 63
217 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 63
218 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 63
219 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64
220 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 64
221 5.5. A Word on User Interaction and User-Installed Apps . . . . 65
222 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
223 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 66
224 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66
225 8.1. Informative References . . . . . . . . . . . . . . . . . . 66
226 8.2. Informative References . . . . . . . . . . . . . . . . . . 66
227 Appendix A. Document History . . . . . . . . . . . . . . . . . . 68
228 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
230 1. Introduction
232 This document gives additional security considerations for OAuth,
233 beyond those in the OAuth specification, based on a comprehensive
234 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
235 contains the following content:
237 o Documents any assumptions and scope considered when creating the
238 threat model.
240 o Describes the security features in-built into the OAuth protocol
241 and how they are intended to thwart attacks.
243 o Gives a comprehensive threat model for OAuth and describes the
244 respective counter measures to thwart those threats.
246 Threats include any intentional attacks on OAuth tokens and resources
247 protected by OAuth tokens as well as security risks introduced if the
248 proper security measures are not put in place. Threats are
249 structured along the lines of the protocol structure to aid
250 development teams implement each part of the protocol securely. For
251 example all threats for granting access or all threats for a
252 particular grant type or all threats for protecting the resource
253 server.
255 Note: This document cannot assess the probability nor the risk
256 associated with a particular threat because those aspects strongly
257 depend on the particular application and deployment OAuth is used to
258 protect. Similar, impacts are given on a rather abstract level. But
259 the information given here may serve as a foundation for deployment-
260 specific threat models. Implementors may refine and detail the
261 abstract threat model in order to account for the specific properties
262 of their deployment and to come up with a risk analysis.
264 2. Overview
266 2.1. Scope
268 The security considerations document only considers clients bound to
269 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
270 deployments have the following characteristics:
272 o Resource server URLs are static and well-known at development
273 time, authorization server URLs can be static or discovered.
275 o Token scope values (e.g. applicable URLs and methods) are well-
276 known at development time.
278 o Client registration: Since registration of clients is out of scope
279 of the current core spec, this document assumes a broad variety of
280 options from static registration during development time to
281 dynamic registration at runtime.
283 The following are considered out of scope :
285 o Communication between authorization server and resource server
287 o Token formats
289 o Except for "Resource Owner Password Credentials" (see
290 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by
291 authorization servers to authenticate the user
293 o Mechanism by which a user obtained an assertion and any resulting
294 attacks mounted as a result of the assertion being false.
296 o Clients not bound to a specific deployment: An example could be a
297 mail client with support for contact list access via the portable
298 contacts API (see [portable-contacts]). Such clients cannot be
299 registered upfront with a particular deployment and should
300 dynamically discover the URLs relevant for the OAuth protocol.
302 2.2. Attack Assumptions
304 The following assumptions relate to an attacker and resources
305 available to an attacker:
307 o It is assumed the attacker has full access to the network between
308 the client and authorization servers and the client and the
309 resource server, respectively. The attacker may eavesdrop on any
310 communications between those parties. He is not assumed to have
311 access to communication between authorization and resource server.
313 o It is assumed an attacker has unlimited resources to mount an
314 attack.
316 o It is assumed that 2 of the 3 parties involved in the OAuth
317 protocol may collude to mount an attack against the 3rd party.
318 For example, the client and authorization server may be under
319 control of an attacker and collude to trick a user to gain access
320 to resources.
322 2.3. Architectural assumptions
324 This section documents the assumptions about the features,
325 limitations, and design options of the different entities of a OAuth
326 deployment along with the security-sensitive data-elements managed by
327 those entity. These assumptions are the foundation of the threat
328 analysis.
330 The OAuth protocol leaves deployments with a certain degree of
331 freedom how to implement and apply the standard. The core
332 specification defines the core concepts of an authorization server
333 and a resource server. Both servers can be implemented in the same
334 server entity, or they may also be different entities. The later is
335 typically the case for multi-service providers with a single
336 authentication and authorization system, and are more typical in
337 middleware architectures.
339 2.3.1. Authorization Servers
341 The following data elements are stored or accessible on the
342 authorization server:
344 o user names and passwords
346 o client ids and secrets
348 o client-specific refresh tokens
350 o client-specific access tokens (in case of handle-based design -
351 see Section 3.1)
353 o HTTPS certificate/key
355 o per-authorization process (in case of handle-based design -
356 Section 3.1): redirect_uri, client_id, authorization code
358 2.3.2. Resource Server
360 The following data elements are stored or accessible on the resource
361 server:
363 o user data (out of scope)
365 o HTTPS certificate/key
367 o authorization server credentials (handle-based design - see
368 Section 3.1), or
370 o authorization server shared secret/public key (assertion-based
371 design - see Section 3.1)
373 o access tokens (per request)
375 It is assumed that a resource server has no knowledge of refresh
376 tokens, user passwords, or client secrets.
378 2.3.3. Client
380 In OAuth a client is an application making protected resource
381 requests on behalf of the resource owner and with its authorization.
382 There are different types of clients with different implementation
383 and security characteristics, such as web, user-agent-based, and
384 native applications. A full definition of the different client types
385 and profiles is given in [I-D.ietf-oauth-v2], Section 2.1.
387 The following data elements are stored or accessible on the client:
389 o client id (and client secret or corresponding client credential)
391 o one or more refresh tokens (persistent) and access tokens
392 (transient) per end-user or other security-context or delegation
393 context
395 o trusted CA certificates (HTTPS)
397 o per-authorization process: redirect_uri, authorization code
399 3. Security Features
401 These are some of the security features which have been built into
402 the OAuth 2.0 protocol to mitigate attacks and security issues.
404 3.1. Tokens
406 OAuth makes extensive use many kinds of tokens (access tokens,
407 refresh tokens, authorization codes). The information content of a
408 token can be represented in two ways as follows:
410 Handle (or artifact) a reference to some internal data structure
411 within the authorization server; the internal data structure
412 contains the attributes of the token, such as user id, scope, etc.
413 Handles enable simple revocation and do not require cryptographic
414 mechanisms to protect token content from being modified. On the
415 other hand, handles require communication between issuing and
416 consuming entity (e.g. authorization and resource server) in order
417 to validate the token and obtain token-bound data. This
418 communication might have an negative impact on performance and
419 scalability if both entities reside on different systems. Handles
420 are therefore typically used if the issuing and consuming entity
421 are the same. A 'handle' token is often referred to as an
422 'opaque' token because the resource server does not need to be
423 able to interpret the token directly, it simply uses the token.
425 Assertions (aka self-contained token) a parseable token. An
426 assertion typically has a duration, has an audience, and is
427 digitally signed in order to ensure data integrity and origin
428 authentication. It contains information about the user and the
429 client. Examples of assertion formats are SAML assertions
430 [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120].
431 Assertions can typically directly be validated and used by a
432 resource server without interactions with the authorization
433 server. This results in better performance and scalability in
434 deployment where issuing and consuming entity reside on different
435 systems. Implementing token revocation is more difficult with
436 assertions than with handles.
438 Tokens can be used in two ways to invoke requests on resource servers
439 as follows:
441 bearer token A 'bearer token' is a token that can be used by any
442 client who has received the token (e.g.
443 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to
444 use the token it is important that communication between end-
445 points be secured to ensure that only authorized end-points may
446 capture the token. The bearer token is convenient to client
447 applications as it does not require them to do anything to use
448 them (such as a proof of identity). Bearer tokens have similar
449 characteristics to web single-sign-on (SSO) cookies used in
450 browsers.
452 proof token A 'proof token' is a token that can only be used by a
453 specific client. Each use of the token, requires the client to
454 perform some action that proves that it is the authorized user of
455 the token. Examples of this are MAC tokens, which require the
456 client to digitally sign the resource request with a secret
457 corresponding to the particular token send with the request
458 (e.g.[I-D.ietf-oauth-v2-http-mac]).
460 3.1.1. Scope
462 A Scope represents the access authorization associated with a
463 particular token with respect to resource servers, resources and
464 methods on those resources. Scopes are the OAuth way to explicitly
465 manage the power associated with an access token. A scope can be
466 controlled by the authorization server and/or the end-user in order
467 to limit access to resources for OAuth clients these parties deem
468 less secure or trustworthy. Optionally, the client can request the
469 scope to apply to the token but only for lesser scope than would
470 otherwise be granted, e.g. to reduce the potential impact if this
471 token is sent over non secure channels. A scope is typically
472 complemented by a restriction on a token's lifetime.
474 3.1.2. Limited Access Token Lifetime
476 The protocol parameter expires_in allows an authorization server
477 (based on its policies or on behalf of the end-user) to limit the
478 lifetime of an access token and to pass this information to the
479 client. This mechanism can be used to issue short-living tokens to
480 OAuth clients the authorization server deems less secure or where
481 sending tokens over non secure channels.
483 3.2. Access Token
485 An access token is used by a client to access a resource. Access
486 tokens typically have short life-spans (minutes or hours) that cover
487 typical session lifetimes. An access token may be refreshed through
488 the use of a refresh token. The short lifespan of an access token in
489 combination with the usage of refresh tokens enables the possibility
490 of passive revocation of access authorization on the expiry of the
491 current access token.
493 3.3. Refresh Token
495 A refresh token represents a long-lasting authorization of a certain
496 client to access resources on behalf of a resource owner. Such
497 tokens are exchanged between client and authorization server, only.
498 Clients use this kind of token to obtain ("refresh") new access
499 tokens used for resource server invocations.
501 A refresh token, coupled with a short access token lifetime, can be
502 used to grant longer access to resources without involving end user
503 authorization. This offers an advantage where resource servers and
504 authorization servers are not the same entity, e.g. in a distributed
505 environment, as the refresh token is always exchanged at the
506 authorization server. The authorization server can revoke the
507 refresh token at any time causing the granted access to be revoked
508 once the current access token expires. Because of this, a short
509 access token lifetime is important if timely revocation is a high
510 priority.
512 The refresh token is also a secret bound to the client identifier and
513 client instance which originally requested the authorization and
514 representing the original resource owner grant. This is ensured by
515 the authorization process as follows:
517 1. The resource owner and user-agent safely deliver the
518 authorization code to the client instance in first place.
520 2. The client uses it immediately in secure transport-level
521 communications to the authorization server and then securely
522 stores the long-lived refresh token.
524 3. The client always uses the refresh token in secure transport-
525 level communications to the authorization server to get an access
526 token (and optionally rollover the refresh token).
528 So as long as the confidentiality of the particular token can be
529 ensured by the client, a refresh token can also be used as an
530 alternative means to authenticate the client instance itself..
532 3.4. Authorization Code
534 An authorization code represents the intermediate result of a
535 successful end-user authorization process and is used by the client
536 to obtain access and refresh token. Authorization codes are sent to
537 the client's redirection URI instead of tokens for two purposes.
539 1. Browser-based flows expose protocol parameters to potential
540 attackers via URI query parameters (HTTP referrer), the browser
541 cache, or log file entries and could be replayed. In order to
542 reduce this threat, short-lived authorization codes are passed
543 instead of tokens and exchanged for tokens over a more secure
544 direct connection between client and authorization server.
546 2. It is much simpler to authenticate clients during the direct
547 request between client and authorization server than in the
548 context of the indirect authorization request. The latter would
549 require digital signatures.
551 3.5. Redirection URI
553 A redirection URI helps to detect malicious clients and prevents
554 phishing attacks from clients attempting to trick the user into
555 believing the phisher is the client. The value of the actual
556 redirection URI used in the authorization request has to be presented
557 and is verified when an authorization code is exchanged for tokens.
558 This helps to prevent attacks, where the authorization code is
559 revealed through redirectors and counterfeit web application clients.
560 The authorization server should require public clients and
561 confidential clients using implicit grant type to pre-register their
562 redirect URIs and validate against the registered redirection URI in
563 the authorization request.
565 3.6. State parameter
567 The state parameter is used to link requests and callbacks to prevent
568 Cross-Site Request Forgery attacks (see Section 4.4.1.8) where an
569 attacker authorizes access to his own resources and then tricks a
570 users into following a redirect with the attacker's token. This
571 parameter should bind to the authenticated state in a user agent and,
572 as per the core OAuth spec, the user agent must be capable of keeping
573 it in a location accessible only by the client and user agent, i.e.
574 protected by same-origin policy.
576 3.7. Client Identitifier
578 Authentication protocols have typically not taken into account the
579 identity of the software component acting on behalf of the end-user.
580 OAuth does this in order to increase the security level in delegated
581 authorization scenarios and because the client will be able to act
582 without the user being present.
584 OAuth uses the client identifier to collate associated request to the
585 same originator, such as
587 o a particular end-user authorization process and the corresponding
588 request on the token's endpoint to exchange the authorization code
589 for tokens or
591 o the initial authorization and issuance of a token by an end-user
592 to a particular client, and subsequent requests by this client to
593 obtain tokens without user consent (automatic processing of
594 repeated authorization)
596 This identifier may also be used by the authorization server to
597 display relevant registration information to a user when requesting
598 consent for scope requested by a particular client. The client
599 identifier may be used to limit the number of request for a
600 particular client or to charge the client per request. It may
601 furthermore be useful to differentiate access by different clients,
602 e.g. in server log files.
604 OAuth defines two client types, confidential and public, based on
605 their ability to authenticate with the authorization server (i.e.
606 ability to maintain the confidentiality of their client credentials).
607 Confidential clients are capable of maintaining the confidentiality
608 of client credentials (i.e. a client secret associated with the
609 client identifier) or capable of secure client authentication using
610 other means, such as a client assertion (e.g. SAML) or key
611 cryptography. The latter is considered more secure.
613 The authorization server should determine whether the client is
614 capable of keeping its secret confidential or using secure
615 authentication. Alternatively, the end-user can verify the identity
616 of the client, e.g. by only installing trusted applications.The
617 redicrection URI can be used to prevent delivering credentials to a
618 counterfeit client after obtaining end-user authorization in some
619 cases, but can't be used to verify the client identifier.
621 Clients can be categorized as follows based on the client type,
622 profile (e.g. native vs. web application - see [I-D.ietf-oauth-v2],
623 Section 9) and deployment model:
625 Deployment-independent client_id with pre-registered redirect_uri and
626 without client_secret Such an identifier is used by multiple
627 installations of the same software package. The identifier of
628 such a client can only be validated with the help of the end-user.
629 This is a viable option for native applications in order to
630 identify the client for the purpose of displaying meta information
631 about the client to the user and to differentiate clients in log
632 files. Revocation of the rights associated with such a client
633 identifier will affect ALL deployments of the respective software.
635 Deployment-independent client_id with pre-registered redirect_uri and
636 with client_secret This is an option for native applications only,
637 since web application would require different redirect URIs. This
638 category is not advisable because the client secret cannot be
639 protected appropriately (see Section 4.1.1). Due to its security
640 weaknesses, such client identities have the same trust level as
641 deployment-independent clients without secret. Revocation will
642 affect ALL deployments.
644 Deployment-specific client_id with pre-registered redirect_uri and
645 with client_secret The client registration process ensures the
646 validation of the client's properties, such as redirection URI,
647 website URL, web site name, contacts. Such a client identifier
648 can be utilized for all relevant use cases cited above. This
649 level can be achieved for web applications in combination with a
650 manual or user-bound registration process. Achieving this level
651 for native applications is much more difficult. Either the
652 installation of the application is conducted by an administrator,
653 who validates the client's authenticity, or the process from
654 validating the application to the installation of the application
655 on the device and the creation of the client credentials is
656 controlled end-to-end by a single entity (e.g. application market
657 provider). Revocation will affect a single deployment only.
659 Deployment-specific client_id with client_secret without validated
660 properties Such a client can be recognized by the authorization
661 server in transactions with subsequent requests (e.g.
662 authorization and token issuance, refresh token issuance and
663 access token refreshment). The authorization server cannot assure
664 any property of the client to end-users. Automatic processing of
665 re-authorizations could be allowed as well. Such client
666 credentials can be generated automatically without any validation
667 of client properties, which makes it another option especially for
668 native applications. Revocation will affect a single deployment
669 only.
671 4. Threat Model
673 This section gives a comprehensive threat model of OAuth 2.0.
674 Threats are grouped first by attacks directed against an OAuth
675 component, which are client, authorization server, and resource
676 server. Subsequently, they are grouped by flow, e.g. obtain token or
677 access protected resources. Every countermeasure description refers
678 to a detailed description in Section 5.
680 4.1. Clients
682 This section describes possible threats directed to OAuth clients.
684 4.1.1. Threat: Obtain Client Secrets
686 The attacker could try to get access to the secret of a particular
687 client in order to:
689 o replay its refresh tokens and authorization codes, or
691 o obtain tokens on behalf of the attacked client with the privileges
692 of that client.
694 The resulting impact would be:
696 o Client authentication of access to authorization server can be
697 bypassed
699 o Stolen refresh tokens or authorization codes can be replayed
701 Depending on the client category, the following attacks could be
702 utilized to obtain the client secret.
704 Attack: Obtain Secret From Source Code or Binary:
706 This applies for all client types. For open source projects, secrets
707 can be extracted directly from source code in their public
708 repositories. Secrets can be extracted from application binaries
709 just as easily when published source is not available to the
710 attacker. Even if an application takes significant measures to
711 obfuscate secrets in their application distribution one should
712 consider that the secret can still be reverse-engineered by anyone
713 with access to a complete functioning application bundle or binary.
715 Countermeasures:
717 o Don't issue secrets to public clients or clients with
718 inappropriate security policy - Section 5.2.3.1
720 o Public clients require user consent - Section 5.2.3.2
722 o Use deployment-specific client secrets - Section 5.2.3.4
724 o Client secret revocation - Section 5.2.3.6
726 Attack: Obtain a Deployment-Specific Secret:
728 An attacker may try to obtain the secret from a client installation,
729 either from a web site (web server) or a particular devices (native
730 application).
732 Countermeasures:
734 o Web server: apply standard web server protection measures (for
735 config files and databases) - Section 5.3.2
737 o Native applications: Store secrets in a secure local storage -
738 Section 5.3.3
740 o Client secret revocation - Section 5.2.3.6
742 4.1.2. Threat: Obtain Refresh Tokens
744 Depending on the client type, there are different ways refresh tokens
745 may be revealed to an attacker. The following sub-sections give a
746 more detailed description of the different attacks with respect to
747 different client types and further specialized countermeasures.
748 Before detailing those threats, here are some generally applicable
749 countermeasures:
751 o The authorization server should validate the client id associated
752 with the particular refresh token with every refresh request-
753 Section 5.2.2.2
755 o Limited scope tokens - Section 5.1.5.1
757 o Refresh token revocation - Section 5.2.2.4
759 o Client secret revocation - Section 5.2.3.6
761 o Refresh tokens can automatically be replaced in order to detect
762 unauthorized token usage by another party (Refresh Token Rotation)
763 - Section 5.2.2.3
765 Attack: Obtain Refresh Token from Web application:
767 An attacker may obtain the refresh tokens issued to a web application
768 by way of overcoming the web server's security controls. Impact:
769 Since a web application manages the user accounts of a certain site,
770 such an attack would result in an exposure of all refresh tokens on
771 that side to the attacker.
773 Countermeasures:
775 o Standard web server protection measures - Section 5.3.2
777 o Use strong client authentication (e.g. client_assertion /
778 client_token), so the attacker cannot obtain the client secret
779 required to exchange the tokens - Section 5.2.3.7
781 Attack: Obtain Refresh Token from Native clients:
783 On native clients, leakage of a refresh token typically affects a
784 single user, only.
786 Read from local file system: The attacker could try get file system
787 access on the device and read the refresh tokens. The attacker could
788 utilize a malicious application for that purpose.
790 Countermeasures:
792 o Store secrets in a secure storage - Section 5.3.3
794 o Utilize device lock to prevent unauthorized device access -
795 Section 5.3.4
797 Attack: Steal device:
799 The host device (e.g. mobile phone) may be stolen. In that case, the
800 attacker gets access to all applications under the identity of the
801 legitimate user.
803 Countermeasures:
805 o Utilize device lock to prevent unauthorized device access -
806 Section 5.3.4
808 o Where a user knows the device has been stolen, they can revoke the
809 affected tokens - Section 5.2.2.4
811 Attack: Clone Device:
813 All device data and applications are copied to another device.
814 Applications are used as-is on the target device.
816 Countermeasures:
818 o Utilize device lock to prevent unauthorized device access -
819 Section 5.3.4
821 o Combine refresh token request with device identification -
822 Section 5.2.2.5
824 o Refresh Token Rotation - Section 5.2.2.3
826 o Where a user knows the device has been cloned, they can use this
827 countermeasure - Refresh Token Revocation - Section 5.2.2.4
829 4.1.3. Threat: Obtain Access Tokens
831 Depending on the client type, there are different ways access tokens
832 may be revealed to an attacker. Access tokens could be stolen from
833 the device if the application stores them in a storage, which is
834 accessible to other applications.
836 Impact: Where the token is a bearer token and no additional mechanism
837 is used to identify the client, the attacker can access all resources
838 associated with the token and its scope.
840 Countermeasures:
842 o Keep access tokens in transient memory and limit grants:
843 Section 5.1.6
845 o Limited scope tokens - Section 5.1.5.1
847 o Keep access tokens in private memory or apply same protection
848 means as for refresh tokens - Section 5.2.2
850 o Keep access token lifetime short - Section 5.1.5.3
852 4.1.4. Threat: End-user credentials phished using compromised or
853 embedded browser
855 A malicious application could attempt to phish end-user passwords by
856 misusing an embedded browser in the end-user authorization process,
857 or by presenting its own user-interface instead of allowing trusted
858 system browser to render the authorization user interface. By doing
859 so, the usual visual trust mechanisms may be bypassed (e.g. TLS
860 confirmation, web site mechanisms). By using an embedded or internal
861 client application user interface, the client application has access
862 to additional information it should not have access to (e.g. uid/
863 password).
865 Impact: If the client application or the communication is
866 compromised, the user would not be aware and all information in the
867 authorization exchange could be captured such as username and
868 password.
870 Countermeasures:
872 o The OAuth flow is designed so that client applications never need
873 to know user passwords. Client applications should avoid directly
874 asking users for the their credentials. In addition, end users
875 could be educated about phishing attacks and best practices, such
876 as only accessing trusted clients, as OAuth does not provide any
877 protection against malicious applications and the end user is
878 solely responsible for the trustworthiness of any native
879 application installed.
881 o Client applications could be validated prior to publication in an
882 application market for users to access. That validation is out of
883 scope for OAuth but could include validating that the client
884 application handles user authentication in an appropriate way.
886 o Client developers should not write client applications that
887 collect authentication information directly from users and should
888 instead delegate this task to a trusted system component, e.g. the
889 system-browser.
891 4.1.5. Threat: Open Redirectors on client
893 An open redirector is an endpoint using a parameter to automatically
894 redirect a user-agent to the location specified by the parameter
895 value without any validation. If the authorization server allows the
896 client to register only part of the redirection URI, an attacker can
897 use an open redirector operated by the client to construct a
898 redirection URI that will pass the authorization server validation
899 but will send the authorization code or access token to an endpoint
900 under the control of the attacker.
902 Impact: An attacker could gain access to authorization codes or
903 access tokens
905 Countermeasure
907 o require clients to register full redirection URI Section 5.2.3.5
909 4.2. Authorization Endpoint
911 4.2.1. Threat: Password phishing by counterfeit authorization server
913 OAuth makes no attempt to verify the authenticity of the
914 Authorization Server. A hostile party could take advantage of this
915 by intercepting the Client's requests and returning misleading or
916 otherwise incorrect responses. This could be achieved using DNS or
917 ARP spoofing. Wide deployment of OAuth and similar protocols may
918 cause users to become inured to the practice of being redirected to
919 websites where they are asked to enter their passwords. If users are
920 not careful to verify the authenticity of these websites before
921 entering their credentials, it will be possible for attackers to
922 exploit this practice to steal Users' passwords.
924 Countermeasures:
926 o Authorization servers should consider such attacks when developing
927 services based on OAuth, and should require transport-layer
928 security for any requests where the authenticity of the
929 authorization server or of request responses is an issue (see
930 Section 5.1.2).
932 o Authorization servers should attempt to educate Users about the
933 risks phishing attacks pose, and should provide mechanisms that
934 make it easy for users to confirm the authenticity of their sites.
936 4.2.2. Threat: User unintentionally grants too much access scope
938 When obtaining end user authorization, the end-user may not
939 understand the scope of the access being granted and to whom or they
940 may end up providing a client with access to resources which should
941 not be permitted.
943 Countermeasures:
945 o Explain the scope (resources and the permissions) the user is
946 about to grant in an understandable way - Section 5.2.4.2
948 o Narrow scope based on client - When obtaining end user
949 authorization and where the client requests scope, the
950 authorization server may want to consider whether to honour that
951 scope based on the client identifier. That decision is between
952 the client and authorization server and is outside the scope of
953 this spec. The authorization server may also want to consider
954 what scope to grant based on the client type, e.g. providing lower
955 scope to public clients. - Section 5.1.5.1
957 4.2.3. Threat: Malicious client obtains existing authorization by fraud
959 Authorization servers may wish to automatically process authorization
960 requests from clients which have been previously authorized by the
961 user. When the user is redirected to the authorization server's end-
962 user authorization endpoint to grant access, the authorization server
963 detects that the user has already granted access to that particular
964 client. Instead of prompting the user for approval, the
965 authorization server automatically redirects the user back to the
966 client.
968 A malicious client may exploit that feature and try to obtain such an
969 authorization code instead of the legitimate client.
971 Countermeasures:
973 o Authorization servers should not automatically process repeat
974 authorizations to public clients or unless the client is validated
975 using a pre-registered redirect URI (Section 5.2.3.5 )
977 o Authorization servers can mitigate the risks associated with
978 automatic processing by limiting the scope of Access Tokens
979 obtained through automated approvals - Section 5.1.5.1
981 4.2.4. Threat: Open redirector
983 An attacker could use the end-user authorization endpoint and the
984 redirection URI parameter to abuse the authorization server as an
985 open redirector. An open redirector is an endpoint using a parameter
986 to automatically redirect a user-agent to the location specified by
987 the parameter value without any validation.
989 Impact: An attacker could utilize a user's trust in your
990 authorization server to launch a phishing attack.
992 Countermeasure
994 o require clients to register full redirection URI Section 5.2.3.5
996 o don't redirect to redirection URI, if client identifier or
997 redirection URI can't be verified Section 5.2.3.5
999 4.3. Token endpoint
1001 4.3.1. Threat: Eavesdropping access tokens
1003 Attackers may attempt to eavesdrop access token in transit from the
1004 authorization server to the client.
1006 Impact: The attacker is able to access all resources with the
1007 permissions covered by the scope of the particular access token.
1009 Countermeasures:
1011 o As per the core OAuth spec, the authorization servers must ensure
1012 that these transmissions are protected using transport-layer
1013 mechanisms such as TLS (see Section 5.1.1).
1015 o If end-to-end confidentiality cannot be guaranteed, reducing scope
1016 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
1017 tokens can be used to reduce the damage in case of leaks.
1019 4.3.2. Threat: Obtain access tokens from authorization server database
1021 This threat is applicable if the authorization server stores access
1022 tokens as handles in a database. An attacker may obtain access
1023 tokens from the authorization server's database by gaining access to
1024 the database or launching a SQL injection attack. Impact: disclosure
1025 of all access tokens
1027 Countermeasures:
1029 o System security measures - Section 5.1.4.1.1
1031 o Store access token hashes only - Section 5.1.4.1.3
1033 o Standard SQL injection Countermeasures - Section 5.1.4.1.2
1035 4.3.3. Threat: Disclosure of client credentials during transmission
1037 An attacker could attempt to eavesdrop the transmission of client
1038 credentials between client and server during the client
1039 authentication process or during OAuth token requests.
1041 Impact: Revelation of a client credential enabling phishing or
1042 impersonation of a client service.
1044 Countermeasures:
1046 o The transmission of client credentials must be protected using
1047 transport-layer mechanisms such as TLS (see Section 5.1.1).
1049 o Alternative authentication means, which do not require to send
1050 plaintext credentials over the wire (e.g. Hash-based Message
1051 Authentication Code)
1053 4.3.4. Threat: Obtain client secret from authorization server database
1055 An attacker may obtain valid client_id/secret combinations from the
1056 authorization server's database by gaining access to the database or
1057 launching a SQL injection attack. Impact: disclosure of all
1058 client_id/secret combinations. This allows the attacker to act on
1059 behalf of legitimate clients.
1061 Countermeasures:
1063 o System security measures - Section 5.1.4.1.1
1065 o Standard SQL injection Countermeasures - Section 5.1.4.1.2
1067 o Ensure proper handling of credentials as per Credential Storage
1068 Protection.
1070 4.3.5. Threat: Obtain client secret by online guessing
1072 An attacker may try to guess valid client_id/secret pairs. Impact:
1073 disclosure of single client_id/secret pair.
1075 Countermeasures:
1077 o High entropy of secrets - Section 5.1.4.2.2
1079 o Lock accounts - Section 5.1.4.2.3
1081 o Use Strong Client Authentication - Section 5.2.3.7
1083 4.4. Obtaining Authorization
1085 This section covers threats which are specific to certain flows
1086 utilized to obtain access tokens. Each flow is characterized by
1087 response types and/or grant types on the end-user authorization and
1088 token endpoint, respectively.
1090 4.4.1. Authorization Code
1092 4.4.1.1. Threat: Eavesdropping or leaking authorization codes
1094 An attacker could try to eavesdrop transmission of the authorization
1095 code between authorization server and client. Furthermore,
1096 authorization codes are passed via the browser which may
1097 unintentionally leak those codes to untrusted web sites and attackers
1098 in different ways:
1100 o Referrer headers: browsers frequently pass a "referer" header when
1101 a web page embeds content, or when a user travels from one web
1102 page to another web page. These referrer headers may be sent even
1103 when the origin site does not trust the destination site. The
1104 referrer header is commonly logged for traffic analysis purposes.
1106 o Request logs: web server request logs commonly include query
1107 parameters on requests.
1109 o Open redirectors: web sites sometimes need to send users to
1110 another destination via a redirector. Open redirectors pose a
1111 particular risk to web-based delegation protocols because the
1112 redirector can leak verification codes to untrusted destination
1113 sites.
1115 o Browser history: web browsers commonly record visited URLs in the
1116 browser history. Another user of the same web browser may be able
1117 to view URLs that were visited by previous users.
1119 Note: A description of a similar attacks on the SAML protocol can be
1120 found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1,
1121 [gross-sec-analysis], and
1122 [OASIS.sstc-gross-sec-analysis-response-01].
1124 Countermeasures:
1126 o As per the core OAuth spec, the authorization server as well as
1127 the client must ensure that these transmissions are protected
1128 using transport-layer mechanisms such as TLS (see Section 5.1.1).
1130 o The authorization server will require the client to authenticate
1131 wherever possible, so the binding of the authorization code to a
1132 certain client can be validated in a reliable way (see
1133 Section 5.2.4.4).
1135 o Limited duration of authorization codes - Section 5.1.5.3
1137 o The authorization server should enforce a one time usage
1138 restriction (see Section 5.1.5.4).
1140 o If an Authorization Server observes multiple attempts to redeem an
1141 authorization code, the Authorization Server may want to revoke
1142 all tokens granted based on the authorization code (see
1143 Section 5.2.1.1).
1145 o In the absence of these countermeasures, reducing scope
1146 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
1147 tokens can be used to reduce the damage in case of leaks.
1149 o The client server may reload the target page of the redirection
1150 URI in order to automatically cleanup the browser cache.
1152 4.4.1.2. Threat: Obtain authorization codes from authorization server
1153 database
1155 This threat is applicable if the authorization server stores
1156 authorization codes as handles in a database. An attacker may obtain
1157 authorization codes from the authorization server's database by
1158 gaining access to the database or launching a SQL injection attack.
1159 Impact: disclosure of all authorization codes, most likely along with
1160 the respective redirect_uri and client_id values.
1162 Countermeasures:
1164 o Best practices for credential storage protection should be
1165 employed - Section 5.1.4.1
1167 o System security measures - Section 5.1.4.1.1
1169 o Store access token hashes only - Section 5.1.4.1.3
1171 o Standard SQL injection countermeasures - Section 5.1.4.1.2
1173 4.4.1.3. Threat: Online guessing of authorization codes
1175 An attacker may try to guess valid authorization code values and send
1176 it using the grant type "code" in order to obtain a valid access
1177 token.
1179 Impact: disclosure of single access token, probably also associated
1180 refresh token.
1182 Countermeasures:
1184 o Handle-based tokens must use high entropy: Section 5.1.4.2.2
1186 o Assertion-based tokens should be signed: Section 5.1.5.9
1188 o Authenticate the client, adds another value the attacker has to
1189 guess - Section 5.2.3.4
1191 o Binding of authorization code to redirection URI, adds another
1192 value the attacker has to guess - Section 5.2.4.5
1194 o Short expiration time - Section 5.1.5.3
1196 4.4.1.4. Threat: Malicious client obtains authorization
1198 A malicious client could pretend to be a valid client and obtain an
1199 access authorization that way. The malicious client could even
1200 utilize screen scraping techniques in order to simulate the user
1201 consent in the authorization flow.
1203 Assumption: It is not the task of the authorization server to protect
1204 the end-user's device from malicious software. This is the
1205 responsibility of the platform running on the particular device
1206 probably in cooperation with other components of the respective
1207 ecosystem (e.g. an application management infrastructure). The sole
1208 responsibility of the authorization server is to control access to
1209 the end-user's resources living in resource servers and to prevent
1210 unauthorized access to them via the OAuth protocol. Based on this
1211 assumption, the following countermeasures are available to cope with
1212 the threat.
1214 Countermeasures:
1216 o The authorization server should authenticate the client, if
1217 possible (see Section 5.2.3.4). Note: the authentication takes
1218 place after the end-user has authorized the access.
1220 o The authorization server should validate the client's redirection
1221 URI against the pre-registered redirection URI, if one exists (see
1222 Section 5.2.3.5). Note: An invalid redirect URI indicates an
1223 invalid client whereas a valid redirect URI does not neccesserily
1224 indicate a valid client. The level of confidence depends on the
1225 client type. For web applications, the confidence is high since
1226 the redirect URI refers to the globally unique network endpoint of
1227 this application whose fully qualified domain name (FQDN) is also
1228 validated using HTTPS server authentication by the user agent. In
1229 contrast for native clients, the redirect URI typically refers to
1230 device local resources, e.g. a custom scheme. So a malicious
1231 client on a particular device can use the valid redirect URI the
1232 legitimate client uses on all other devices.
1234 o After authenticating the end-user, the authorization server should
1235 ask him/her for consent. In this context, the authorization
1236 server should explain to the end-user the purpose, scope, and
1237 duration of the authorization the client asked for. Moreover, the
1238 authorization server should show the user any identity information
1239 it has for that client. It is up to the user to validate the
1240 binding of this data to the particular application (e.g. Name)
1241 and to approve the authorization request. (see Section 5.2.4.3).
1243 o The authorization server should not perform automatic re-
1244 authorizations for clients it is unable to reliably authenticate
1245 or validate (see Section 5.2.4.1).
1247 o If the authorization server automatically authenticates the end-
1248 user, it may nevertheless require some user input in order to
1249 prevent screen scraping. Examples are CAPTCHAs (Completely
1250 Automated Public Turing test to tell Computers and Humans Apart)
1251 or other multi-factor authentication techniques such as random
1252 questions, token code generators, etc.
1254 o The authorization server may also limit the scope of tokens it
1255 issues to clients it cannot reliably authenticate (see
1256 Section 5.1.5.1).
1258 4.4.1.5. Threat: Authorization code phishing
1260 A hostile party could impersonate the client site and get access to
1261 the authorization code. This could be achieved using DNS or ARP
1262 spoofing. This applies to clients, which are web applications, thus
1263 the redirect URI is not local to the host where the user's browser is
1264 running.
1266 Impact: This affects web applications and may lead to a disclosure of
1267 authorization codes and, potentially, the corresponding access and
1268 refresh tokens.
1270 Countermeasures:
1272 It is strongly recommended that one of the following countermeasures
1273 is utilized in order to prevent this attack:
1275 o The redirection URI of the client should point to a HTTPS
1276 protected endpoint and the browser should be utilized to
1277 authenticate this redirection URI using server authentication (see
1278 Section 5.1.2).
1280 o The authorization server should require the client to be
1281 authenticated, i.e. confidential client, so the binding of the
1282 authorization code to a certain client can be validated in a
1283 reliable way (see Section 5.2.4.4).
1285 4.4.1.6. Threat: User session impersonation
1287 A hostile party could impersonate the client site and impersonate the
1288 user's session on this client. This could be achieved using DNS or
1289 ARP spoofing. This applies to clients, which are web applications,
1290 thus the redirect URI is not local to the host where the user's
1291 browser is running.
1293 Impact: An attacker who intercepts the authorization code as it is
1294 sent by the browser to the callback endpoint can gain access to
1295 protected resources by submitting the authorization code to the
1296 client. The client will exchange the authorization code for an
1297 access token and use the access token to access protected resources
1298 for the benefit of the attacker, delivering protected resources to
1299 the attacker, or modifying protected resources as directed by the
1300 attacker. If OAuth is used by the client to delegate authentication
1301 to a social site (e.g. as in the implementation of "Login" button to
1302 a third-party social network site), the attacker can use the
1303 intercepted authorization code to log in to the client as the user.
1305 Note: Authenticating the client during authorization code exchange
1306 will not help to detect such an attack as it is the legitimate client
1307 that obtains the tokens.
1309 Countermeasures:
1311 o In order to prevent an attacker from impersonating the end-users
1312 session, the redirection URI of the client should point to a HTTPS
1313 protected endpoint and the browser should be utilized to
1314 authenticate this redirection URI using server authentication (see
1315 Section 5.1.2)
1317 4.4.1.7. Threat: Authorization code leakage through counterfeit client
1319 The attack leverages the authorization code grant type in an attempt
1320 to get another user (victim) to log-in, authorize access to his/her
1321 resources, and subsequently obtain the authorization code and inject
1322 it into a client application using the attacker's account. The goal
1323 is to associate an access authorization for resources of the victim
1324 with the user account of the attacker on a client site.
1326 The attacker abuses an existing client application and combines it
1327 with his own counterfeit client web site. The attack depends on the
1328 victim expecting the client application to request access to a
1329 certain resource server. The victim, seeing only a normal request
1330 from an expected application, approves the request. The attacker
1331 then uses the victim's authorization to gain access to the
1332 information unknowingly authorized by the victim.
1334 The attacker conducts the following flow:
1336 1. The attacker accesses the client web site (or application) and
1337 initiates data access to a particular resource server. The
1338 client web site in turn initiates an authorization request to the
1339 resource server's authorization server. Instead of proceeding
1340 with the authorization process, the attacker modifies the
1341 authorization server end-user authorization URL as constructed by
1342 the client to include a redirection URI parameter referring to a
1343 web site under his control (attacker's web site).
1345 2. The attacker tricks another user (the victim) to open that
1346 modified end-user authorization URI and to authorize access (e.g.
1347 an email link, or blog link). The way the attacker achieves that
1348 goal is out of scope.
1350 3. Having clicked the link, the victim is requested to authenticate
1351 and authorize the client site to have access.
1353 4. After completion of the authorization process, the authorization
1354 server redirects the user agent to the attacker's web site
1355 instead of the original client web site.
1357 5. The attacker obtains the authorization code from his web site by
1358 means out of scope of this document.
1360 6. He then constructs a redirection URI to the target web site (or
1361 application) based on the original authorization request's
1362 redirection URI and the newly obtained authorization code and
1363 directs his user agent to this URL. The authorization code is
1364 injected into the original client site (or application).
1366 7. The client site uses the authorization code to fetch a token from
1367 the authorization server and associates this token with the
1368 attacker's user account on this site.
1370 8. The attacker may now access the victim's resources using the
1371 client site.
1373 Impact: The attacker gains access to the victim's resources as
1374 associated with his account on the client site.
1376 Countermeasures:
1378 o The attacker will need to use another redirection URI for its
1379 authorization process rather than the target web site because it
1380 needs to intercept the flow. So if the authorization server
1381 associates the authorization code with the redirection URI of a
1382 particular end-user authorization and validates this redirection
1383 URI with the redirection URI passed to the token's endpoint, such
1384 an attack is detected (see Section 5.2.4.5).
1386 o The authorization server may also enforce the usage and validation
1387 of pre-registered redirect URIs (see Section 5.2.3.5). This will
1388 allow for an early recognition of authorization code disclosure to
1389 counterfeit clients.
1391 o For native applications, one could also consider to use
1392 deployment-specific client ids and secrets (see Section 5.2.3.4,
1393 along with the binding of authorization code to client_id (see
1394 Section 5.2.4.4), to detect such an attack because the attacker
1395 does not have access the deployment-specific secret. Thus he will
1396 not be able to exchange the authorization code.
1398 o The client may consider using other flows, which are not
1399 vulnerable to this kind of attack such as "Implicit Grant" or
1400 "Resource Owner Password Credentials" (see Section 4.4.2 or
1401 Section 4.4.3).
1403 4.4.1.8. Threat: CSRF attack against redirect-uri
1405 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
1406 requests are transmitted from a user that the website trusts or has
1407 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
1408 on OAuth approvals can allow an attacker to obtain authorization to
1409 OAuth protected resources without the consent of the User.
1411 This attack works against the redirection URI used in the
1412 authorization code flow. An attacker could authorize an
1413 authorization code to their own protected resources on an
1414 authorization server. He then aborts the redirect flow back to the
1415 client on his device and tricks the victim into executing the
1416 redirect back to the client. The client receives the redirect,
1417 fetches the token(s) from the authorization server and associates the
1418 victim's client session with the resources accessible using the
1419 token.
1421 Impact: The user accesses resources on behalf of the attacker. The
1422 effective impact depends on the type of resource accessed. For
1423 example, the user may upload private items to an attacker's
1424 resources. Or when using OAuth in 3rd party login scenarios, the
1425 user may associate his client account with the attacker's identity at
1426 the external identity provider. This way the attacker could easily
1427 access the victim's data at the client by logging in from another
1428 device with his credentials at the external identity provider.
1430 Countermeasures:
1432 o The state parameter should be used to link the authorization
1433 request with the redirection URI used to deliver the access token.
1434 Section 5.3.5
1436 o Client developers and end-user can be educated to not follow
1437 untrusted URLs.
1439 4.4.1.9. Threat: Clickjacking attack against authorization
1441 With Clickjacking, a malicious site loads the target site in a
1442 transparent iFrame (see [iFrame]) overlaid on top of a set of dummy
1443 buttons which are carefully constructed to be placed directly under
1444 important buttons on the target site. When a user clicks a visible
1445 button, they are actually clicking a button (such as an "Authorize"
1446 button) on the hidden page.
1448 Impact: An attacker can steal a user's authentication credentials and
1449 access their resources
1451 Countermeasure
1453 o For newer browsers, avoidance of iFrames during authorization can
1454 be enforced server side by using the X-FRAME-OPTION header -
1455 Section 5.2.2.6
1457 o For older browsers, javascript frame-busting (see [framebusting])
1458 techniques can be used but may not be effective in all browsers.
1460 4.4.1.10. Threat: Resource Owner Impersonation
1462 When a client requests access to protected resources, the
1463 authorization flow normally involves the resource owner's explicit
1464 response to the access request, either granting or denying access to
1465 the protected resources. A malicious client can exploit knowledge of
1466 the structure of this flow in order to gain authorization without the
1467 resource owner's consent, by transmitting the necessary requests
1468 programmatically, and simulating the flow against the authorization
1469 server. That way, the client may gain access to the victim's
1470 resources without her approval. An authorization server will be
1471 vulnerable to this threat, if it uses non-interactive authentication
1472 mechanisms or splits the authorization flow across multiple pages.
1474 The malicious client might embed a hidden HTML user agent, interpret
1475 the HTML forms sent by the authorization server, and automatically
1476 send the corresponding form post requests. As a pre-requisite, the
1477 attacker must be able to execute the authorization process in the
1478 context of an already authenticated session of the resource owner
1479 with the authorization server. There are different ways to achieve
1480 this:
1482 o The malicious client could abuse an existing session in an
1483 external browser or cross-browser cookies on the particular
1484 device.
1486 o The malicious client could also request authorization for an
1487 initial scope acceptable to the user and then silently abuse the
1488 resulting session in his browser instance to "silently" request
1489 another scope.
1491 o Alternatively, the attacker might exploit an authorization
1492 server's ability to authenticate the resource owner automatically
1493 and without user interactions, e.g. based on certificates.
1495 In all cases, such an attack is limited to clients running on the
1496 victim's device, within the user agent or as native app.
1498 Please note: Such attacks cannot be prevented using CSRF
1499 countermeasures, since the attacker just "executes" the URLs as
1500 prepared by the authorization server including any nonce etc.
1502 Countermeasures:
1504 Authorization servers should decide, based on an analysis of the risk
1505 associated with this threat, whether to detect and prevent this
1506 threat.
1508 In order to prevent such an attack, the authorization server may
1509 force a user interaction based on non-predictable input values as
1510 part of the user consent approval. The authorization server could
1512 o combine password authentication and user consent in a single form,
1514 o make use of CAPTCHAs, or
1516 o or use one-time secrets sent out of band to the resource owner
1517 (e.g. via text or instant message).
1519 Alternatively in order to allow the resource owner to detect abuse,
1520 the authorization server could notify the resource owner of any
1521 approval by appropriate means, e.g. text or instant message or
1522 e-Mail.
1524 4.4.1.11. Threat: DoS, Exhaustion of resources attacks
1526 If an authorization server includes a nontrivial amount of entropy in
1527 authorization codes or access tokens (limiting the number of possible
1528 codes/tokens) and automatically grants either without user
1529 intervention and has no limit on code or access tokens per user, an
1530 attacker could exhaust the pool of authorization codes by repeatedly
1531 directing the user's browser to request code or access tokens.
1533 Countermeasures:
1535 o The authorization server should consider limiting the number of
1536 access tokens granted per user. The authorization server should
1537 include a nontrivial amount of entropy in authorization codes.
1539 4.4.1.12. Threat: DoS using manufactured authorization codes
1541 An attacker who owns a botnet can locate the redirect URIs of clients
1542 that listen on HTTP, access them with random authorization codes, and
1543 cause a large number of HTTPS connections to be concentrated onto the
1544 authorization server. This can result in a DoS attack on the
1545 authorization server.
1547 This attack can still be effective even when CSRF defense/the 'state'
1548 parameter (see Section 4.4.1.8) is deployed on the client side. With
1549 such a defense, the attacker might need to incur an additional HTTP
1550 request to obtain a valid CSRF code/ state parameter. This
1551 apparently cuts down the effectiveness of the attack by a factor of
1552 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
1553 factor is estimated to be around 3.5x at [ssl-latency]) the attacker
1554 still achieves a magnification of resource utilization at the expense
1555 of the authorization server.
1557 Impact: There are a few effects that the attacker can accomplish with
1558 this OAuth flow that they cannot easily achieve otherwise.
1560 1. Connection laundering: With the clients as the relay between the
1561 attacker and the authorization server, the authorization server
1562 learns little or no information about the identity of the
1563 attacker. Defenses such as rate limiting on the offending
1564 attacker machines are less effective due to the difficulty to
1565 identify the attacking machines. Although an attacker could also
1566 launder its connections through an anonymizing system such as
1567 Tor, the effectiveness of that approach depends on the capacity
1568 of the anonymizing system. On the other hand, a potentially
1569 large number of OAuth clients could be utilized for this attack.
1571 2. Asymmetric resource utilization: The attacker incurs the cost of
1572 an HTTP connection and causes an HTTPS connection to be made on
1573 the authorization server; and the attacker can co-ordinate the
1574 timing of such HTTPS connections across multiple clients
1575 relatively easily. Although the attacker could achieve something
1576 similar, say, by including an iframe pointing to the HTTPS URL of
1577 the authorization server in an HTTP web page and lure web users
1578 to visit that page, timing attacks using such a scheme may be
1579 more difficult as it seems nontrivial to synchronize a large
1580 number of users to simultaneously visit a particular site under
1581 the attacker's control.
1583 Countermeasures
1585 o Though not a complete countermeasure by themselves, CSRF defense
1586 and the 'state' parameter created with secure random codes should
1587 be deployed on the client side. The client should forward the
1588 authorization code to the authorization server only after both the
1589 CSRF token and the 'state' parameter are validated.
1591 o If the client authenticates the user, either through a single-
1592 sign-on protocol or through local authentication, the client
1593 should suspend the access by a user account if the number of
1594 invalid authorization codes submitted by this user exceeds a
1595 certain threshold.
1597 o The authorization server should send an error response to the
1598 client reporting an invalid authorization code and rate limit or
1599 disallow connections from clients whose number of invalid requests
1600 exceeds a threshold.
1602 4.4.1.13. Threat: Code substitution (OAuth Login)
1604 An attacker could attempt to login to an application or web site
1605 using a victim's identity. Applications relying on identity data
1606 provided by an OAuth protected service API to login users are
1607 vulnerable to this threat. This pattern can be found in so-called
1608 "social login" scenarios.
1610 As a pre-requisite, a resource server offers an API to obtain
1611 personal information about a user which could be interpreted as
1612 having obtained a user identity. In this sense the client is
1613 treating the resource server API as an "identity" API. A client
1614 utilizes OAuth to obtain an access token for the identity API. It
1615 then queries the identity API for an identifier and uses it to look
1616 up its internal user account data (login). The client asssumes that
1617 because it was able to obtain information about the user, that the
1618 user has been authenticated.
1620 If the client uses the grant type "code", the attacker needs to
1621 gather a valid authorization code of the respective victim from the
1622 same identity provider used by the target client application. The
1623 attacker tricks the victim into login into a malicious app (which may
1624 appear to be legitimate to the Identity Provider) using the same
1625 identity provider as the target application. This results in the
1626 Identity Provider's authorization server issuing an authorization
1627 code for the respective identity API. The malicious app then sends
1628 this code to the attacker, which in turn triggers a login process
1629 within the target application. The attacker now manipulates the
1630 authorization response and substitutes their code (bound to their
1631 identity) for the victim's code. This code is then exchanged by the
1632 client for an access token, which in turn is accepted by the identity
1633 API since the audience, with respect to the resource server, is
1634 correct. But since the identifier returned by the identity API is
1635 determined by the identity in the access token (issued based on the
1636 victim's code), the attacker is logged into the target application
1637 under the victim's identity.
1639 Impact: the attacker gains access to an application and user-specific
1640 data within the application.
1642 Countermeasures:
1644 o All clients must indicate their client id with every request to
1645 exchange an authorization code for an access token. The
1646 authorization server must validate whether the particular
1647 authorization code has been issued to the particular client. If
1648 possible, the client shall be authenticated beforehand.
1650 o Clients should use appropriate protocol, such as OpenID (cf.
1651 [openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
1652 implement user login. Both support audience restrictions on
1653 clients.
1655 4.4.2. Implicit Grant
1657 In the implicit grant type flow, the access token is directly
1658 returned to the client as a fragment part of the redirection URI. It
1659 is assumed that the token is not sent to the redirection URI target
1660 as HTTP user agents do not send the fragment part of URIs to HTTP
1661 servers. Thus an attacker cannot eavesdrop the access token on this
1662 communication path and it cannot leak through HTTP referee headers.
1664 4.4.2.1. Threat: Access token leak in transport/end-points
1666 This token might be eavesdropped by an attacker. The token is sent
1667 from server to client via a URI fragment of the redirection URI. If
1668 the communication is not secured or the end-point is not secured, the
1669 token could be leaked by parsing the returned URI.
1671 Impact: the attacker would be able to assume the same rights granted
1672 by the token.
1674 Countermeasures:
1676 o The authorization server should ensure confidentiality (e.g. using
1677 TLS) of the response from the authorization server to the client
1678 (see Section 5.1.1).
1680 4.4.2.2. Threat: Access token leak in browser history
1682 An attacker could obtain the token from the browser's history. Note
1683 this means the attacker needs access to the particular device.
1685 Countermeasures:
1687 o Shorten token duration (see Section 5.1.5.3) and reduced scope of
1688 the token may reduce the impact of that attack (see
1689 Section 5.1.5.1).
1691 o Make responses non-cachable
1693 4.4.2.3. Threat: Malicious client obtains authorization
1695 A malicious client could attempt to obtain a token by fraud.
1697 The same countermeasures as for Section 4.4.1.4 are applicable,
1698 except client authentication.
1700 4.4.2.4. Threat: Manipulation of scripts
1702 A hostile party could act as the client web server and replace or
1703 modify the actual implementation of the client (script). This could
1704 be achieved using DNS or ARP spoofing. This applies to clients
1705 implemented within the Web Browser in a scripting language.
1707 Impact: The attacker could obtain user credential information and
1708 assume the full identity of the user.
1710 Countermeasures:
1712 o The authorization server should authenticate the server from which
1713 scripts are obtained (see Section 5.1.2).
1715 o The client should ensure that scripts obtained have not been
1716 altered in transport (see Section 5.1.1).
1718 o Introduce one time per-use secrets (e.g. client_secret) values
1719 that can only be used by scripts in a small time window once
1720 loaded from a server. The intention would be to reduce the
1721 effectiveness of copying client-side scripts for re-use in an
1722 attackers modified code.
1724 4.4.2.5. Threat: CSRF attack against redirect-uri
1726 CSRF attacks (see Section 4.4.1.8) also work against the redirection
1727 URI used in the implicit grant flow. An attacker could acquire an
1728 access token to their own protected resources. He could then
1729 construct a redirection URI and embed their access token in that URI.
1730 If he can trick the user into following the redirection URI and the
1731 client does not have protection against this attack, the user may
1732 have the attacker's access token authorized within their client.
1734 Impact: The user accesses resources on behalf of the attacker. The
1735 effective impact depends on the type of resource accessed. For
1736 example, the user may upload private items to an attacker's
1737 resources. Or when using OAuth in 3rd party login scenarios, the
1738 user may associate his client account with the attacker's identity at
1739 the external identity provider. This way the attacker could easily
1740 access the victim's data at the client by logging in from another
1741 device with his credentials at the external identity provider.
1743 Countermeasures:
1745 o The state parameter should be used to link the authorization
1746 request with the redirection URI used deliver the access token.
1747 This will ensure the client is not tricked into completing any
1748 redirect callback unless it is linked to an authorization request
1749 the client initiated. The state parameter should be unguessable
1750 and the client should be capable of keeping the state parameter
1751 secret.
1753 o Client developers and end-user can be educated not follow
1754 untrusted URLs.
1756 4.4.2.6. Threat: Token substitution (OAuth Login)
1758 An attacker could attempt to login to an application or web site
1759 using a victim's identity. Applications relying on identity data
1760 provided by an OAuth protected service API to login users are
1761 vulnerable to this threat. This pattern can be found in so-called
1762 "social login" scenarios.
1764 As a pre-requisite, a resource server offers an API to obtain
1765 personal information about a user which could be interpreted as
1766 having obtained a user identity. In this sense the client is
1767 treating the resource server API as an "identity" API. A client
1768 utilizes OAuth to obtain an access token for the identity API. It
1769 then queries the identity API for an identifier and uses it to look
1770 up its internal user account data (login). The client asssumes that
1771 because it was able to obtain information about the user, that the
1772 user has been authenticated.
1774 To succeed, the attacker needs to gather a valid access token of the
1775 respective victim from the same identity provider used by the target
1776 client application. The attacker tricks the victim into login into a
1777 malicious app (which may appear to be legitimate to the Identity
1778 Provider) using the same identity provider as the target application.
1779 This results in the Identity Provider's authorization server issuing
1780 an access token for the respective identity API. The malicious app
1781 then sends this access token to the attacker, which in turn triggers
1782 a login process within the target application. The attacker now
1783 manipulates the authorization response and substitutes their access
1784 token (bound to their identity) for the victim's access token. This
1785 token is accepted by the identity API since the audience, with
1786 respect to the resource server, is correct. But since the identifier
1787 returned by the identity API is determined by the identity in the
1788 access token, the attacker is logged into the target application
1789 under the victim's identity.
1791 Impact: the attacker gains access to an application and user-specific
1792 data within the application.
1794 Countermeasures:
1796 o Clients should use appropriate protocol, such as OpenID (cf.
1797 [openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
1798 implement user login. Both support audience restrictions on
1799 clients.
1801 4.4.3. Resource Owner Password Credentials
1803 The "Resource Owner Password Credentials" grant type (see
1804 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration
1805 reasons, allows a client to request an access token using an end-
1806 users user-id and password along with its own credential. This grant
1807 type has higher risk because it maintains the uid/password anti-
1808 pattern. Additionally, because the user does not have control over
1809 the authorization process, clients using this grant type are not
1810 limited by scope, but instead have potentially the same capabilities
1811 as the user themselves. As there is no authorization step, the
1812 ability to offer token revocation is bypassed.
1814 Because passwords are often used for more than 1 service, this anti-
1815 pattern may also risk whatever else is accessible with the supplied
1816 credential. Additionally any easily derived equivalent (e.g.
1817 joe@example.com and joe@example.net) might easily allow someone to
1818 guess that the same password can be used elsewhere.
1820 Impact: The resource server can only differentiate scope based on the
1821 access token being associated with a particular client. The client
1822 could also acquire long-living tokens and pass them up to a attacker
1823 web service for further abuse. The client, eavesdroppers, or end-
1824 points could eavesdrop user id and password.
1826 Countermeasures:
1828 o Except for migration reasons, minimize use of this grant type
1830 o The authorization server should validate the client id associated
1831 with the particular refresh token with every refresh request -
1832 Section 5.2.2.2
1834 o As per the core Oauth spec, the authorization server must ensure
1835 that these transmissions are protected using transport-layer
1836 mechanisms such as TLS (see Section 5.1.1).
1838 o Rather than encouraging users to use a uid and password, service
1839 providers should instead encourage users not to use the same
1840 password for multiple services.
1842 o Limit use of Resource Owner Password Credential grants to
1843 scenarios where the client application and the authorizing service
1844 are from the same organization.
1846 4.4.3.1. Threat: Accidental exposure of passwords at client site
1848 If the client does not provide enough protection, an attacker or
1849 disgruntled employee could retrieve the passwords for a user.
1851 Countermeasures:
1853 o Use other flows, which do not rely on the client's cooperation for
1854 secure resource owner credential handling
1856 o Use digest authentication instead of plaintext credential
1857 processing
1859 o Obfuscation of passwords in logs
1861 4.4.3.2. Threat: Client obtains scopes without end-user authorization
1863 All interaction with the resource owner is performed by the client.
1864 Thus it might, intentionally or unintentionally, happen that the
1865 client obtains a token with scope unknown for or unintended by the
1866 resource owner. For example, the resource owner might think the
1867 client needs and acquires read-only access to its media storage only
1868 but the client tries to acquire an access token with full access
1869 permissions.
1871 Countermeasures:
1873 o Use other flows, which do not rely on the client's cooperation for
1874 resource owner interaction
1876 o The authorization server may generally restrict the scope of
1877 access tokens (Section 5.1.5.1) issued by this flow. If the
1878 particular client is trustworthy and can be authenticated in a
1879 reliable way, the authorization server could relax that
1880 restriction. Resource owners may prescribe (e.g. in their
1881 preferences) what the maximum scope is for clients using this
1882 flow.
1884 o The authorization server could notify the resource owner by an
1885 appropriate media, e.g. e-Mail, of the grant issued (see
1886 Section 5.1.3).
1888 4.4.3.3. Threat: Client obtains refresh token through automatic
1889 authorization
1891 All interaction with the resource owner is performed by the client.
1892 Thus it might, intentionally or unintentionally, happen that the
1893 client obtains a long-term authorization represented by a refresh
1894 token even if the resource owner did not intend so.
1896 Countermeasures:
1898 o Use other flows, which do not rely on the client's cooperation for
1899 resource owner interaction
1901 o The authorization server may generally refuse to issue refresh
1902 tokens in this flow (see Section 5.2.2.1). If the particular
1903 client is trustworthy and can be authenticated in a reliable way
1904 (see client authentication), the authorization server could relax
1905 that restriction. Resource owners may allow or deny (e.g. in
1906 their preferences) to issue refresh tokens using this flow as
1907 well.
1909 o The authorization server could notify the resource owner by an
1910 appropriate media, e.g. e-Mail, of the refresh token issued (see
1911 Section 5.1.3).
1913 4.4.3.4. Threat: Obtain user passwords on transport
1915 An attacker could attempt to eavesdrop the transmission of end-user
1916 credentials with the grant type "password" between client and server.
1918 Impact: disclosure of a single end-users password.
1920 Countermeasures:
1922 o Confidentiality of Requests - Section 5.1.1
1924 o alternative authentication means, which do not require to send
1925 plaintext credentials over the wire (e.g. Hash-based Message
1926 Authentication Code)
1928 4.4.3.5. Threat: Obtain user passwords from authorization server
1929 database
1931 An attacker may obtain valid username/password combinations from the
1932 authorization server's database by gaining access to the database or
1933 launching a SQL injection attack.
1935 Impact: disclosure of all username/password combinations. The impact
1936 may exceed the domain of the authorization server since many users
1937 tend to use the same credentials on different services.
1939 Countermeasures:
1941 o Credential storage protection can be employed - Section 5.1.4.1
1943 4.4.3.6. Threat: Online guessing
1945 An attacker may try to guess valid username/password combinations
1946 using the grant type "password".
1948 Impact: Revelation of a single username/password combination.
1950 Countermeasures:
1952 o Password policy - Section 5.1.4.2.1
1954 o Lock accounts - Section 5.1.4.2.3
1956 o Tar pit - Section 5.1.4.2.4
1958 o CAPTCHA - Section 5.1.4.2.5
1960 o Consider not to use grant type "password"
1962 o Client authentication (see Section 5.2.3) will provide another
1963 authentication factor and thus hinder the attack.
1965 4.4.4. Client Credentials
1967 Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an
1968 identifier (not secret) combined with an additional means (such as a
1969 matching client secret) of authenticating a client. The threats to
1970 this grant type are similar to Section 4.4.3.
1972 4.5. Refreshing an Access Token
1974 4.5.1. Threat: Eavesdropping refresh tokens from authorization server
1976 An attacker may eavesdrop refresh tokens when they are transmitted
1977 from the authorization server to the client.
1979 Countermeasures:
1981 o As per the core OAuth spec, the Authorization servers must ensure
1982 that these transmissions are protected using transport-layer
1983 mechanisms such as TLS (see Section 5.1.1).
1985 o If end-to-end confidentiality cannot be guaranteed, reducing scope
1986 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for
1987 issued access tokens can be used to reduce the damage in case of
1988 leaks.
1990 4.5.2. Threat: Obtaining refresh token from authorization server
1991 database
1993 This threat is applicable if the authorization server stores refresh
1994 tokens as handles in a database. An attacker may obtain refresh
1995 tokens from the authorization server's database by gaining access to
1996 the database or launching a SQL injection attack.
1998 Impact: disclosure of all refresh tokens
2000 Countermeasures:
2002 o Credential storage protection - Section 5.1.4.1
2004 o Bind token to client id, if the attacker cannot obtain the
2005 required id and secret - Section 5.1.5.8
2007 4.5.3. Threat: Obtain refresh token by online guessing
2009 An attacker may try to guess valid refresh token values and send it
2010 using the grant type "refresh_token" in order to obtain a valid
2011 access token.
2013 Impact: exposure of single refresh token and derivable access tokens.
2015 Countermeasures:
2017 o For handle-based designs - Section 5.1.4.2.2
2019 o For assertion-based designs - Section 5.1.5.9
2021 o Bind token to client id, because the attacker would guess the
2022 matching client id, too (see Section 5.1.5.8)
2024 o Authenticate the client, adds another element the attacker has to
2025 guess (see Section 5.2.3.4)
2027 4.5.4. Threat: Obtain refresh token phishing by counterfeit
2028 authorization server
2030 An attacker could try to obtain valid refresh tokens by proxying
2031 requests to the authorization server. Given the assumption that the
2032 authorization server URL is well-known at development time or can at
2033 least be obtained from a well-known resource server, the attacker
2034 must utilize some kind of spoofing in order to succeed.
2036 Countermeasures:
2038 o Server authentication (as described in Section 5.1.2)
2040 4.6. Accessing Protected Resources
2042 4.6.1. Threat: Eavesdropping access tokens on transport
2044 An attacker could try to obtain a valid access token on transport
2045 between client and resource server. As access tokens are shared
2046 secrets between authorization and resource server, they should be
2047 treated with the same care as other credentials (e.g. end-user
2048 passwords).
2050 Countermeasures:
2052 o Access tokens sent as bearer tokens, should not be sent in the
2053 clear over an insecure channel. As per the core OAuth spec,
2054 transmission of access tokens must be protected using transport-
2055 layer mechanisms such as TLS (see Section 5.1.1).
2057 o A short lifetime reduces impact in case tokens are compromised
2058 (see Section 5.1.5.3).
2060 o The access token can be bound to a client's identifier and require
2061 the client to prove legitimate ownership of the token to the
2062 resource server (see Section 5.4.2).
2064 4.6.2. Threat: Replay authorized resource server requests
2066 An attacker could attempt to replay valid requests in order to obtain
2067 or to modify/destroy user data.
2069 Countermeasures:
2071 o The resource server should utilize transport security measures
2072 (e.g. TLS) in order to prevent such attacks (see Section 5.1.1).
2073 This would prevent the attacker from capturing valid requests.
2075 o Alternatively, the resource server could employ signed requests
2076 (see Section 5.4.3) along with nonces and timestamps in order to
2077 uniquely identify requests. The resource server should detect and
2078 refuse every replayed request.
2080 4.6.3. Threat: Guessing access tokens
2082 Where the token is a handle, the attacker may use attempt to guess
2083 the access token values based on knowledge they have from other
2084 access tokens.
2086 Impact: Access to a single user's data.
2088 Countermeasures:
2090 o Handle Tokens should have a reasonable entropy (see
2091 Section 5.1.4.2.2) in order to make guessing a valid token value
2092 infeasible.
2094 o Assertion (or self-contained token ) tokens contents should be
2095 protected by a digital signature (see Section 5.1.5.9).
2097 o Security can be further strengthened by using a short access token
2098 duration (see Section 5.1.5.2 and Section 5.1.5.3).
2100 4.6.4. Threat: Access token phishing by counterfeit resource server
2102 An attacker may pretend to be a particular resource server and to
2103 accept tokens from a particular authorization server. If the client
2104 sends a valid access token to this counterfeit resource server, the
2105 server in turn may use that token to access other services on behalf
2106 of the resource owner.
2108 Countermeasures:
2110 o Clients should not make authenticated requests with an access
2111 token to unfamiliar resource servers, regardless of the presence
2112 of a secure channel. If the resource server URL is well-known to
2113 the client, it may authenticate the resource servers (see
2114 Section 5.1.2).
2116 o Associate the endpoint URL of the resource server the client
2117 talked to with the access token (e.g. in an audience field) and
2118 validate association at legitimate resource server. The endpoint
2119 URL validation policy may be strict (exact match) or more relaxed
2120 (e.g. same host). This would require to tell the authorization
2121 server the resource server endpoint URL in the authorization
2122 process.
2124 o Associate an access token with a client and authenticate the
2125 client with resource server requests (typically via signature in
2126 order to not disclose secret to a potential attacker). This
2127 prevents the attack because the counterfeit server is assumed to
2128 lack the capability to correctly authenticate on behalf of the
2129 legitimate client to the resource server (Section 5.4.2).
2131 o Restrict the token scope (see Section 5.1.5.1) and or limit the
2132 token to a certain resource server (Section 5.1.5.5).
2134 4.6.5. Threat: Abuse of token by legitimate resource server or client
2136 A legitimate resource server could attempt to use an access token to
2137 access another resource servers. Similarly, a client could try to
2138 use a token obtained for one server on another resource server.
2140 Countermeasures:
2142 o Tokens should be restricted to particular resource servers (see
2143 Section 5.1.5.5).
2145 4.6.6. Threat: Leak of confidential data in HTTP-Proxies
2147 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is
2148 optional. However, [RFC2616] relies on the Authorization and WWW-
2149 Authenticate headers to distinguish authenticated content so that it
2150 can be protected. Proxies and caches, in particular, may fail to
2151 adequately protect requests not using these headers. For example,
2152 private authenticated content may be stored in (and thus retrievable
2153 from) publicly-accessible caches.
2155 Countermeasures:
2157 o Clients and resource servers not using the HTTP Authorization
2158 scheme (OAuth HTTP Authorization Scheme - see Section 5.4.1)
2159 should take care to use Cache-Control headers to minimize the risk
2160 that authenticated content is not protected. Such Clients should
2161 send a Cache-Control header containing the "no-store" option
2162 [RFC2616]. Resource server success (2XX status) responses to
2163 these requests should contain a Cache-Control header with the
2164 "private" option [RFC2616].
2166 o Reducing scope (see Section 5.1.5.1) and expiry time
2167 (Section 5.1.5.3) for access tokens can be used to reduce the
2168 damage in case of leaks.
2170 4.6.7. Threat: Token leakage via logfiles and HTTP referrers
2172 If access tokens are sent via URI query parameters, such tokens may
2173 leak to log files and the HTTP "referer".
2175 Countermeasures:
2177 o Use authorization headers or POST parameters instead of URI
2178 request parameters (see Section 5.4.1).
2180 o Set logging configuration appropriately
2182 o Prevent unauthorized persons from access to system log files (see
2183 Section 5.1.4.1.1)
2185 o Abuse of leaked access tokens can be prevented by enforcing
2186 authenticated requests (see Section 5.4.2).
2188 o The impact of token leakage may be reduced by limiting scope (see
2189 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing
2190 one time token usage (see Section 5.1.5.4).
2192 5. Security Considerations
2194 This section describes the countermeasures as recommended to mitigate
2195 the threats as described in Section 4.
2197 5.1. General
2199 The general section covers considerations that apply generally across
2200 all OAuth components (client, resource server, token server, and
2201 user-agents).
2203 5.1.1. Confidentiality of Requests
2205 This is applicable to all requests sent from client to authorization
2206 server or resource server. While OAuth provides a mechanism for
2207 verifying the integrity of requests, it provides no guarantee of
2208 request confidentiality. Unless further precautions are taken,
2209 eavesdroppers will have full access to request content and may be
2210 able to mount interception or replay attacks through using content of
2211 request, e.g. secrets or tokens.
2213 Attacks can be mitigated by using transport-layer mechanisms such as
2214 TLS [RFC5246]. A virtual private network (VPN), e.g. based on IPsec
2215 VPN [RFC4301], may considered as well.
2217 Note: this document assumes end-to-end TLS protected connections
2218 between the respective protocol entities. Deployments deviating from
2219 this assumption by offloading TLS in between (e.g. on the data center
2220 edge) must refine this threat model in order to account for the
2221 additional (mainly insider) threat this may cause.
2223 This is a countermeasure against the following threats:
2225 o Replay of access tokens obtained on tokens endpoint or resource
2226 server's endpoint
2228 o Replay of refresh tokens obtained on tokens endpoint
2230 o Replay of authorization codes obtained on tokens endpoint
2231 (redirect?)
2233 o Replay of user passwords and client secrets
2235 5.1.2. Server authentication
2237 HTTPS server authentication or similar means can be used to
2238 authenticate the identity of a server. The goal is to reliably bind
2239 the fully qualified domain name of the server to the public key
2240 presented by the server during connection establishment (see
2241 [RFC2818]).
2243 The client should validate the binding of the server to its domain
2244 name. If the server fails to prove that binding, it is considered a
2245 man-in-the-middle attack. The security measure depends on the
2246 certification authorities the client trusts for that purpose.
2247 Clients should carefully select those trusted CAs and protect the
2248 storage for trusted CA certificates from modifications.
2250 This is a countermeasure against the following threats:
2252 o Spoofing
2254 o Proxying
2256 o Phishing by counterfeit servers
2258 5.1.3. Always keep the resource owner informed
2260 Transparency to the resource owner is a key element of the OAuth
2261 protocol. The user should always be in control of the authorization
2262 processes and get the necessary information to meet informed
2263 decisions. Moreover, user involvement is a further security
2264 countermeasure. The user can probably recognize certain kinds of
2265 attacks better than the authorization server. Information can be
2266 presented/exchanged during the authorization process, after the
2267 authorization process, and every time the user wishes to get informed
2268 by using techniques such as:
2270 o User consent forms
2271 o Notification messages (e.g. e-Mail, SMS, ...). Note that
2272 notifications can be a phishing vector. Messages should be such
2273 that look-alike phishing messages cannot be derived from them.
2275 o Activity/Event logs
2277 o User self-care applications or portals
2279 5.1.4. Credentials
2281 This sections describes countermeasures used to protect all kinds of
2282 credentials from unauthorized access and abuse. Credentials are long
2283 term secrets, such as client secrets and user passwords as well as
2284 all kinds of tokens (refresh and access token) or authorization
2285 codes.
2287 5.1.4.1. Credential Storage Protection
2289 Administrators should undertake industry best practices to protect
2290 the storage of credentials (see for example [owasp]). Such practices
2291 may include but are not limited to the following sub-sections.
2293 5.1.4.1.1. Standard System Security Means
2295 A server system may be locked down so that no attacker may get access
2296 to sensible configuration files and databases.
2298 5.1.4.1.2. Standard SQL Injection Countermeasures
2300 If a client identifier or other authentication component is queried
2301 or compared against a SQL Database it may become possible for an
2302 injection attack to occur if parameters received are not validated
2303 before submission to the database.
2305 o Ensure that server code is using the minimum database privileges
2306 possible to reduce the "surface" of possible attacks.
2308 o Avoid dynamic SQL using concatenated input. If possible, use
2309 static SQL.
2311 o When using dynamic SQL, parameterize queries using bind arguments.
2312 Bind arguments eliminate possibility of SQL injections.
2314 o Filter and sanitize the input. For example, if an identifier has
2315 a known format, ensure that the supplied value matches the
2316 identifier syntax rules.
2318 5.1.4.1.3. No cleartext storage of credentials
2320 The authorization server should not store credentials in clear text.
2321 Typical approaches are to store hashes instead or to encrypt
2322 credentials. If the credential lacks a reasonable entropy level
2323 (because it is a user password) an additional salt will harden the
2324 storage to make offline dictionary attacks more difficult.
2326 Note: Some authentication protocols require the authorization server
2327 to have access to the secret in the clear. Those protocols cannot be
2328 implemented if the server only has access to hashes. Credentials
2329 should strongly encrypted in those cases.
2331 5.1.4.1.4. Encryption of credentials
2333 For client applications, insecurely persisted client credentials are
2334 easy targets for attackers to obtain. Store client credentials using
2335 an encrypted persistence mechanism such as a keystore or database.
2336 Note that compiling client credentials directly into client code
2337 makes client applications vulnerable to scanning as well as difficult
2338 to administer should client credentials change over time.
2340 5.1.4.1.5. Use of asymmetric cryptography
2342 Usage of asymmetric cryptography will free the authorization server
2343 of the obligation to manage credentials.
2345 5.1.4.2. Online attacks on secrets
2347 5.1.4.2.1. Password policy
2349 The authorization server may decide to enforce a complex user
2350 password policy in order to increase the user passwords' entropy to
2351 hinder online password attacks. Note that too much complexity can
2352 increase the liklihood that users re-use passwords or write them down
2353 or otherwise store them insecurely.
2355 5.1.4.2.2. High entropy of secrets
2357 When creating secrets not intended for usage by human users (e.g.
2358 client secrets or token handles), the authorization server should
2359 include a reasonable level of entropy in order to mitigate the risk
2360 of guessing attacks. The token value should be >=128 bits long and
2361 constructed from a cryptographically strong random or pseudo-random
2362 number sequence (see [RFC4086] for best current practice) generated
2363 by the Authorization Server.
2365 5.1.4.2.3. Lock accounts
2367 Online attacks on passwords can be mitigated by locking the
2368 respective accounts after a certain number of failed attempts.
2370 Note: This measure can be abused to lock down legitimate service
2371 users.
2373 5.1.4.2.4. Tar pit
2375 The authorization server may react on failed attempts to authenticate
2376 by username/password by temporarily locking the respective account
2377 and delaying the response for a certain duration. This duration may
2378 increase with the number of failed attempts. The objective is to
2379 slow the attackers attempts on a certain username down.
2381 Note: this may require a more complex and stateful design of the
2382 authorization server.
2384 5.1.4.2.5. Usage of CAPTCHAs
2386 The idea is to prevent programs from automatically checking huge
2387 number of passwords by requiring human interaction.
2389 Note: this has a negative impact on user experience.
2391 5.1.5. Tokens (access, refresh, code)
2393 5.1.5.1. Limit token scope
2395 The authorization server may decide to reduce or limit the scope
2396 associated with a token. The basis of this decision is out of scope,
2397 examples are:
2399 o a client-specific policy, e.g. issue only less powerful tokens to
2400 public clients,
2402 o a service-specific policy, e.g. it a very sensitive service,
2404 o a resource-owner specific setting, or
2406 o combinations of such policies and preferences.
2408 The authorization server may allow different scopes dependent on the
2409 grant type. For example, end-user authorization via direct
2410 interaction with the end-user (authorization code) might be
2411 considered more reliable than direct authorization via grant type
2412 username/password. This means will reduce the impact of the
2413 following threats:
2415 o token leakage
2417 o token issuance to malicious software
2419 o unintended issuance of to powerful tokens with resource owner
2420 credentials flow
2422 5.1.5.2. Expiration time
2424 Tokens should generally expire after a reasonable duration. This
2425 complements and strengthens other security measures (such as
2426 signatures) and reduces the impact of all kinds of token leaks.
2427 Depending on the risk associated with a token leakage, tokens may
2428 expire after a few minutes (e.g. for payment transactions) or stay
2429 valid for hours (e.g. read access to contacts).
2431 The expiration time is determined by a couple of factors, including:
2433 o risk associated to a token leakage
2435 o duration of the underlying access grant,
2437 o duration until the modification of an access grant should take
2438 effect, and
2440 o time required for an attacker to guess or produce valid token.
2442 5.1.5.3. Short expiration time
2444 A short expiration time for tokens is a protection means against the
2445 following threats:
2447 o replay
2449 o reduce impact of token leak
2451 o reduce likelihood of successful online guessing
2453 Note: Short token duration requires more precise clock
2454 synchronisation between authorization server and resource server.
2455 Furthermore, shorter duration may require more token refreshes
2456 (access token) or repeated end-user authorization processes
2457 (authorization code and refresh token).
2459 5.1.5.4. Limit number of usages/ One time usage
2461 The authorization server may restrict the number of requests or
2462 operations which can be performed with a certain token. This
2463 mechanism can be used to mitigate the following threats:
2465 o replay of tokens
2467 o guessing
2469 For example, if an Authorization Server observes more than one
2470 attempt to redeem an authorization code, the Authorization Server may
2471 want to revoke all access tokens granted based on the authorization
2472 code as well as reject the current request.
2474 As with the authorization code, access tokens may also have a limited
2475 number of operations. This forces client applications to either re-
2476 authenticate and use a refresh token to obtain a fresh access token,
2477 or it forces the client to re-authorize the access token by involving
2478 the user.
2480 5.1.5.5. Bind tokens to a particular resource server (Audience)
2482 Authorization servers in multi-service environments may consider
2483 issuing tokens with different content to different resource servers
2484 and to explicitly indicate in the token the target server a token is
2485 intended to be sent to. SAML Assertions (see
2486 [OASIS.saml-core-2.0-os]) use the Audience element for this purpose.
2487 This countermeasure can be used in the following situations:
2489 o It reduces the impact of a successful replay attempt, since the
2490 token is applicable to a single resource server, only.
2492 o It prevents abuse of a token by a rogue resource server or client,
2493 since the token can only be used on that server. It is rejected
2494 by other servers.
2496 o It reduces the impact of a leakage of a valid token to a
2497 counterfeit resource server.
2499 5.1.5.6. Use endpoint address as token audience
2501 This may be used to indicate to a resource server, which endpoint URL
2502 has been used to obtain the token. This measure will allow to detect
2503 requests from a counterfeit resource server, since such token will
2504 contain the endpoint URL of that server.
2506 5.1.5.7. Audience and Token scopes
2508 Deployments may consider only using tokens with explicitly defined
2509 scope, where every scope is associated with a particular resource
2510 server. This approach can be used to mitigate attacks, where a
2511 resource server or client uses a token for a different then the
2512 intended purpose.
2514 5.1.5.8. Bind token to client id
2516 An authorization server may bind a token to a certain client
2517 identifier. This identifier should be validated for every request
2518 with that token. This means can be used, to
2520 o detect token leakage and
2522 o prevent token abuse.
2524 Note: Validating the client identifier may require the target server
2525 to authenticate the client's identifier. This authentication can be
2526 based on secrets managed independent of the token (e.g. pre-
2527 registered client id/secret on authorization server) or sent with the
2528 token itself (e.g. as part of the encrypted token content).
2530 5.1.5.9. Signed tokens
2532 Self-contained tokens should be signed in order to detect any attempt
2533 to modify or produce faked tokens (e.g. Hash-based Message
2534 Authentication Code or digital signatures)
2536 5.1.5.10. Encryption of token content
2538 Self-contained tokens may be encrypted for confidentiality reasons or
2539 to protect system internal data. Depending on token format, keys
2540 (e.g. symmetric keys) may have to be distributed between server
2541 nodes. The method of distribution should be defined by the token and
2542 encryption used.
2544 5.1.5.11. Assertion formats
2546 For service providers intending to implement an assertion-based token
2547 design it is highly recommended to adopt a standard assertion format
2548 (such as SAML [OASIS.saml-core-2.0-os] or JWT
2549 [I-D.ietf-oauth-json-web-token].
2551 5.1.6. Access tokens
2553 The following measures should be used to protect access tokens
2555 o keep them in transient memory (accessible by the client
2556 application only)
2558 o Pass tokens securely using secure transport (TLS)
2560 o Ensure client applications do not share tokens with 3rd parties
2562 5.2. Authorization Server
2564 This section describes considerations related to the OAuth
2565 Authorization Server end-point.
2567 5.2.1. Authorization Codes
2569 5.2.1.1. Automatic revocation of derived tokens if abuse is detected
2571 If an Authorization Server observes multiple attempts to redeem an
2572 authorization grant (e.g. such as an authorization code), the
2573 Authorization Server may want to revoke all tokens granted based on
2574 the authorization grant.
2576 5.2.2. Refresh tokens
2578 5.2.2.1. Restricted issuance of refresh tokens
2580 The authorization server may decide based on an appropriate policy
2581 not to issue refresh tokens. Since refresh tokens are long term
2582 credentials, they may be subject theft. For example, if the
2583 authorization server does not trust a client to securely store such
2584 tokens, it may refuse to issue such a client a refresh token.
2586 5.2.2.2. Binding of refresh token to client_id
2588 The authorization server should match every refresh token to the
2589 identifier of the client to whom it was issued. The authorization
2590 server should check that the same client_id is present for every
2591 request to refresh the access token. If possible (e.g. confidential
2592 clients), the authorization server should authenticate the respective
2593 client.
2595 This is a countermeasure against refresh token theft or leakage.
2597 Note: This binding should be protected from unauthorized
2598 modifications.
2600 5.2.2.3. Refresh Token Rotation
2602 Refresh token rotation is intended to automatically detect and
2603 prevent attempts to use the same refresh token in parallel from
2604 different apps/devices. This happens if a token gets stolen from the
2605 client and is subsequently used by the attacker and the legitimate
2606 client. The basic idea is to change the refresh token value with
2607 every refresh request in order to detect attempts to obtain access
2608 tokens using old refresh tokens. Since the authorization server
2609 cannot determine whether the attacker or the legitimate client is
2610 trying to access, in case of such an access attempt the valid refresh
2611 token and the access authorization associated with it are both
2612 revoked.
2614 The OAuth specification supports this measure in that the tokens
2615 response allows the authorization server to return a new refresh
2616 token even for requests with grant type "refresh_token".
2618 Note: this measure may cause problems in clustered environments since
2619 usage of the currently valid refresh token must be ensured. In such
2620 an environment, other measures might be more appropriate.
2622 5.2.2.4. Refresh Token Revocation
2624 The authorization server may allow clients or end-users to explicitly
2625 request the invalidation of refresh tokens. A mechanism to revoke
2626 tokens is specified in [I-D.ietf-oauth-revocation].
2628 This is a countermeasure against:
2630 o device theft,
2632 o impersonation of resource owner, or
2634 o suspected compromised client applications.
2636 5.2.2.5. Device identification
2638 The authorization server may require to bind authentication
2639 credentials to a device identifier. The _International Mobile
2640 Station Equipment Identity_ [IMEI] is one example of such an
2641 identifier, there are also operating system specific identifiers.
2642 The authorization server could include such an identifier when
2643 authenticating user credentials in order to detect token theft from a
2644 particular device.
2646 Note: Any implementation should consider potential privacy
2647 implications of using device identifiers.
2649 5.2.2.6. X-FRAME-OPTION header
2651 For newer browsers, avoidance of iFrames can be enforced server side
2652 by using the X-FRAME-OPTION header (see
2653 [I-D.gondrom-x-frame-options]). This header can have two values,
2654 "DENY" and "SAMEORIGIN", which will block any framing or framing by
2655 sites with a different origin, respectively. The value "ALLOW-FROM"
2656 allows iFrames for a list of trusted origins.
2658 This is a countermeasure against the following threats:
2660 o Clickjacking attacks
2662 5.2.3. Client authentication and authorization
2664 As described in Section 3 (Security Features), clients are
2665 identified, authenticated and authorized for several purposes, such
2666 as a
2668 o Collate requests to the same client,
2670 o Indicate to the user the client is recognized by the authorization
2671 server,
2673 o Authorize access of clients to certain features on the
2674 authorization or resource server, and
2676 o Log a client identifier to log files for analysis or statistics.
2678 Due to the different capabilities and characteristics of the
2679 different client types, there are different ways to support these
2680 objectives, which will be described in this section. Authorization
2681 server providers should be aware of the security policy and
2682 deployment of a particular clients and adapt its treatment
2683 accordingly. For example, one approach could be to treat all clients
2684 as less trustworthy and unsecure. On the other extreme, a service
2685 provider could activate every client installation individually by an
2686 administrator and that way gain confidence in the identity of the
2687 software package and the security of the environment the client is
2688 installed in. And there are several approaches in between.
2690 5.2.3.1. Don't issue secrets to client with inappropriate security
2691 policy
2693 Authorization servers should not issue secrets to clients that cannot
2694 protect secrets ("public" clients). This reduces probability of the
2695 server treating the client as strongly authenticated.
2697 For example, it is of limited benefit to create a single client id
2698 and secret which is shared by all installations of a native
2699 application. Such a scenario requires that this secret must be
2700 transmitted from the developer via the respective distribution
2701 channel, e.g. an application market, to all installations of the
2702 application on end-user devices. A secret, burned into the source
2703 code of the application or a associated resource bundle, is not
2704 protected from reverse engineering. Secondly, such secrets cannot be
2705 revoked since this would immediately put all installations out of
2706 work. Moreover, since the authorization server cannot really trust
2707 the client's identifier, it would be dangerous to indicate to end-
2708 users the trustworthiness of the client.
2710 There are other ways to achieve a reasonable security level, as
2711 described in the following sections.
2713 5.2.3.2. Public clients without secret require user consent
2715 Authorization servers should not allow automatic authorization for
2716 public clients. The authorization may issue an individual client id,
2717 but should require that all authorizations are approved by the end-
2718 user. This is a countermeasure for clients without secret against
2719 the following threats:
2721 o Impersonation of public client applications
2723 5.2.3.3. Client_id only in combination with redirect_uri
2725 The authorization may issue a client_id and bind the client_id to a
2726 certain pre-configured redirect_uri. Any authorization request with
2727 another redirection URI is refused automatically. Alternatively, the
2728 authorization server should not accept any dynamic redirection URI
2729 for such a client_id and instead always redirect to the well-known
2730 pre-configured redirection URI. This is a countermeasure for clients
2731 without secrets against the following threats:
2733 o Cross-site scripting attacks
2735 o Impersonation of public client applications
2737 5.2.3.4. Installation-specific client secrets
2739 An authorization server may issue separate client identifiers and
2740 corresponding secrets to the different installations of a particular
2741 client (i.e. software package). The effect of such an approach would
2742 be to turn otherwise "public" clients back into "confidential"
2743 clients.
2745 For web applications, this could mean to create one client_id and
2746 client_secret per web site a software package is installed on. So
2747 the provider of that particular site could request client id and
2748 secret from the authorization server during setup of the web site.
2749 This would also allow to validate some of the properties of that web
2750 site, such as redirection URI, website URL, and whatever proofs
2751 useful. The web site provider has to ensure the security of the
2752 client secret on the site.
2754 For native applications, things are more complicated because every
2755 copy of a particular application on any device is a different
2756 installation. Installation-specific secrets in this scenario will
2757 require
2759 1. Either to obtain a client_id and client_secret during download
2760 process from the application market, or
2762 2. During installation on the device.
2764 Either approach will require an automated mechanism for issuing
2765 client ids and secrets, which is currently not defined by OAuth.
2767 The first approach would allow to achieve a certain level of trust in
2768 the authenticity of the application, whereas the second option only
2769 allows to authenticate the installation but not to validate
2770 properties of the client. But this would at least help to prevent
2771 several replay attacks. Moreover, installation-specific client_id
2772 and secret allow to selectively revoke all refresh tokens of a
2773 specific installation at once.
2775 5.2.3.5. Validation of pre-registered redirect_uri
2777 An authorization server should require all clients to register their
2778 redirect_uri and the redirect_uri should be the full URI as defined
2779 in [I-D.ietf-oauth-v2]. The way this registration is performed is
2780 out of scope of this document. As per the core spec, every actual
2781 redirection URI sent with the respective client_id to the end-user
2782 authorization endpoint must match the registered redirection URI.
2783 Where it does not match, the authorization server should assume the
2784 inbound GET request has been sent by an attacker and refuse it.
2785 Note: the authorization server should not redirect the user agent
2786 back to the redirection URI of such an authorization request.
2787 Validating the pre-registered redirect_uri is a countermeasure
2788 against the following threats:
2790 o Authorization code leakage through counterfeit web site: allows to
2791 detect attack attempts already after first redirect to end-user
2792 authorization endpoint (Section 4.4.1.7).
2794 o Open Redirector attack via client redirection endpoint. (
2795 Section 4.1.5. )
2797 o Open Redirector phishing attack via authorization server
2798 redirection endpoint ( Section 4.2.4 )
2800 The underlying assumption of this measure is that an attacker will
2801 need to use another redirection URI in order to get access to the
2802 authorization code. Deployments might consider the possibility of an
2803 attacker using spoofing attacks to a victims device to circumvent
2804 this security measure.
2806 Note: Pre-registering clients might not scale in some deployments
2807 (manual process) or require dynamic client registration (not
2808 specified yet). With the lack of dynamic client registration, pre-
2809 registered "redirect_uri" only works for clients bound to certain
2810 deployments at development/configuration time. As soon as dynamic
2811 resource server discovery is required, the pre-registered
2812 redirect_uri may be no longer feasible.
2814 5.2.3.6. Client secret revocation
2816 An authorization server may revoke a client's secret in order to
2817 prevent abuse of a revealed secret.
2819 Note: This measure will immediately invalidate any authorization code
2820 or refresh token issued to the respective client. This might be
2821 unintentionally impact client identifiers and secrets used across
2822 multiple deployments of a particular native or web application.
2824 This a countermeasure against:
2826 o Abuse of revealed client secrets for private clients
2828 5.2.3.7. Use strong client authentication (e.g. client_assertion /
2829 client_token)
2831 By using an alternative form of authentication such as client
2832 assertion [I-D.ietf-oauth-assertions], the need to distribute a
2833 client_secret is eliminated. This may require the use of a secure
2834 private key store or other supplemental authentication system as
2835 specified by the client assertion issuer in its authentication
2836 process.
2838 5.2.4. End-user authorization
2840 This secion involves considerations for authorization flows involving
2841 the end-user.
2843 5.2.4.1. Automatic processing of repeated authorizations requires
2844 client validation
2846 Authorization servers should NOT automatically process repeat
2847 authorizations where the client is not authenticated through a client
2848 secret or some other authentication mechanism such as a signed
2849 authentication assertion certificate (Section 5.2.3.7 Use strong
2850 client authentication (e.g. client_assertion / client_token)) or
2851 validation of a pre-registered redirect URI (Section 5.2.3.5
2852 Validation of pre-registered redirection URI ).
2854 5.2.4.2. Informed decisions based on transparency
2856 The authorization server should clearly explain to the end-user what
2857 happens in the authorization process and what the consequences are.
2858 For example, the user should understand what access he is about to
2859 grant to which client for what duration. It should also be obvious
2860 to the user, whether the server is able to reliably certify certain
2861 client properties (web site URL, security policy).
2863 5.2.4.3. Validation of client properties by end-user
2865 In the authorization process, the user is typically asked to approve
2866 a client's request for authorization. This is an important security
2867 mechanism by itself because the end-user can be involved in the
2868 validation of client properties, such as whether the client name
2869 known to the authorization server fits the name of the web site or
2870 the application the end-user is using. This measure is especially
2871 helpful in situations where the authorization server is unable to
2872 authenticate the client. It is a countermeasure against:
2874 o Malicious application
2876 o A client application masquerading as another client
2878 5.2.4.4. Binding of authorization code to client_id
2880 The authorization server should bind every authorization code to the
2881 id of the respective client which initiated the end-user
2882 authorization process. This measure is a countermeasure against:
2884 o replay of authorization codes with different client credentials
2885 since an attacker cannot use another client_id to exchange an
2886 authorization code into a token
2888 o Online guessing of authorization codes
2890 Note: This binding should be protected from unauthorized
2891 modifications (e.g. using protected memory and/or a secure database).
2893 5.2.4.5. Binding of authorization code to redirect_uri
2895 The authorization server should be able to bind every authorization
2896 code to the actual redirection URI used as redirect target of the
2897 client in the end-user authorization process. This binding should be
2898 validated when the client attempts to exchange the respective
2899 authorization code for an access token. This measure is a
2900 countermeasure against authorization code leakage through counterfeit
2901 web sites since an attacker cannot use another redirection URI to
2902 exchange an authorization code into a token.
2904 5.3. Client App Security
2906 This section deals with considerations for client applications.
2908 5.3.1. Don't store credentials in code or resources bundled with
2909 software packages
2911 Because of the numbers of copies of client software, there is limited
2912 benefit to create a single client id and secret which is shared by
2913 all installations of an application. Such an application by itself
2914 would be considered a "public" client as it cannot be presumed to be
2915 able to keep client secrets. A secret, burned into the source code
2916 of the application or an associated resource bundle, cannot be
2917 protected from reverse engineering. Secondly, such secrets cannot be
2918 revoked since this would immediately put all installations out of
2919 work. Moreover, since the authorization server cannot really trust
2920 the client's identifier, it would be dangerous to indicate to end-
2921 users the trustworthiness of the client.
2923 5.3.2. Standard web server protection measures (for config files and
2924 databases)
2926 Use standard web server protection measures - Section 5.3.2
2928 5.3.3. Store secrets in a secure storage
2930 The are different way to store secrets of all kinds (tokens, client
2931 secrets) securely on a device or server.
2933 Most multi-user operating systems segregate the personal storage of
2934 the different system users. Moreover, most modern smartphone
2935 operating systems even support to store app-specific data in separate
2936 areas of the file systems and protect it from access by other
2937 applications. Additionally, applications can implements confidential
2938 data itself using a user-supplied secret, such as PIN or password.
2940 Another option is to swap refresh token storage to a trusted backend
2941 server. This mean in turn requires a resilient authentication
2942 mechanisms between client and backend server. Note: Applications
2943 should ensure that confidential data is kept confidential even after
2944 reading from secure storage, which typically means to keep this data
2945 in the local memory of the application.
2947 5.3.4. Utilize device lock to prevent unauthorized device access
2949 On a typical modern phone, there are many "device lock" options which
2950 can be utilized to provide additional protection where a device is
2951 stolen or misplaced. These include PINs, passwords and other
2952 biomtric featres such as "face recognition". These are not equal in
2953 the level of security they provide.
2955 5.3.5. Link state parameter to user agent session
2957 The state parameter is used to link client requests and prevent CSRF
2958 attacks, for example against the redirection URI. An attacker could
2959 inject their own authorization code or access token, which can result
2960 in the client using an access token associated with the attacker's
2961 protected resources rather than the victim's (e.g. save the victim's
2962 bank account information to a protected resource controlled by the
2963 attacker).
2965 The client should utilize the "state" request parameter to send the
2966 authorization server a value that binds the request to the user-
2967 agent's authenticated state (e.g. a hash of the session cookie used
2968 to authenticate the user-agent) when making an authorization request.
2969 Once authorization has been obtained from the end-user, the
2970 authorization server redirects the end-user's user-agent back to the
2971 client with the required binding value contained in the "state"
2972 parameter.
2974 The binding value enables the client to verify the validity of the
2975 request by matching the binding value to the user- agent's
2976 authenticated state.
2978 5.4. Resource Servers
2980 The following section details security considerations for resource
2981 servers.
2983 5.4.1. Authorization headers
2985 Authorization headers are recognized and specially treated by HTTP
2986 proxies and servers. Thus the usage of such headers for sending
2987 access tokens to resource servers reduces the likelihood of leakage
2988 or unintended storage of authenticated requests in general and
2989 especially Authorization headers.
2991 5.4.2. Authenticated requests
2993 An authorization server may bind tokens to a certain client
2994 identifier and enable resource servers to be able to validate that
2995 association on resource access. This will require the resource
2996 server to authenticate the originator of a request as the legitimate
2997 owner of a particular token. There are a couple of options to
2998 implement this countermeasure:
3000 o The authorization server may associate the client identifier with
3001 the token (either internally or in the payload of an self-
3002 contained token). The client then uses client certificate-based
3003 HTTP authentication on the resource server's endpoint to
3004 authenticate its identity and the resource server validates the
3005 name with the name referenced by the token.
3007 o same as before, but the client uses his private key to sign the
3008 request to the resource server (public key is either contained in
3009 the token or sent along with the request)
3011 o Alternatively, the authorization server may issue a token-bound
3012 secret, which the client uses to MAC (message authentication code)
3013 the request (see [I-D.ietf-oauth-v2-http-mac]). The resource
3014 server obtains the secret either directly from the authorization
3015 server or it is contained in an encrypted section of the token.
3016 That way the resource server does not "know" the client but is
3017 able to validate whether the authorization server issued the token
3018 to that client
3020 Authenticated requests are a countermeasure against abuse of tokens
3021 by counterfeit resource servers.
3023 5.4.3. Signed requests
3025 A resource server may decide to accept signed requests only, either
3026 to replace transport level security measures or to complement such
3027 measures. Every signed request should be uniquely identifiable and
3028 should not be processed twice by the resource server. This
3029 countermeasure helps to mitigate:
3031 o modifications of the message and
3033 o replay attempts
3035 5.5. A Word on User Interaction and User-Installed Apps
3037 OAuth, as a security protocol, is distinctive in that its flow
3038 usually involves significant user interaction, making the end user a
3039 part of the security model. This creates some important difficulties
3040 in defending against some of the threats discussed above. Some of
3041 these points have already been made, but it's worth repeating and
3042 highlighting them here.
3044 o End users must understand what they are being asked to approve
3045 (see Section Section 5.2.4.1). Users often do not have the
3046 expertise to understand the ramifications of saying "yes" to an
3047 authorization request. and are likely not to be able to see subtle
3048 differences in wording of requests. Malicious software can
3049 confuse the user, tricking the user into approving almost
3050 anything.
3052 o End-user devices are prone to software compromise. This has been
3053 a long-standing problem, with frequent attacks on web browsers and
3054 other parts of the user's system. But with increasing popularity
3055 of user-installed "apps", the threat posed by compromised or
3056 malicious end-user software is very strong, and is one that is
3057 very difficult to mitigate.
3059 o Be aware that users will demand to install and run such apps, and
3060 that compromised or malicious ones can steal credentials at many
3061 points in the data flow. They can intercept the very user login
3062 credentials that OAuth is designed to protect. They can request
3063 authorization far beyond what they have led the user to understand
3064 and approve. They can automate a response on behalf of the user,
3065 hiding the whole process. No solution is offered here, because
3066 none is known; this remains in the space between better security
3067 and better usability.
3069 o Addressing these issues by restricting the use of user-installed
3070 software may be practical in some limited environments, and can be
3071 used as a countermeasure in those cases. Such restrictions are
3072 not practical in the general case, and mechanisms for after-the-
3073 fact recovery should be in place.
3075 o While end users are mostly incapable of properly vetting
3076 applications they load onto their devices, those who deploy
3077 Authorization Servers might have tools at their disposal to
3078 mitigate malicious Clients. For example, a well run Authorization
3079 Server must only assert client properties to the end-user it is
3080 effectively capable of validating, explicitely point out which
3081 properties it cannot validate, and indicate to the end-user the
3082 risk associated with granting access to the particular client.
3084 6. IANA Considerations
3086 This document makes no request of IANA.
3088 Note to RFC Editor: this section may be removed on publication as an
3089 RFC.
3091 7. Acknowledgements
3093 We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
3094 Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward,
3095 Niv Steingarten, Tim Bray, and James H. Manger for their comments and
3096 contributions.
3098 8. References
3100 8.1. Informative References
3102 [I-D.ietf-oauth-v2]
3103 Hardt, D., "The OAuth 2.0 Authorization Framework",
3104 draft-ietf-oauth-v2-31 (work in progress), August 2012.
3106 [I-D.ietf-oauth-v2-bearer]
3107 Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
3108 Framework: Bearer Token Usage",
3109 draft-ietf-oauth-v2-bearer-23 (work in progress),
3110 August 2012.
3112 8.2. Informative References
3114 [I-D.gondrom-x-frame-options]
3115 Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
3116 draft-gondrom-x-frame-options-00 (work in progress),
3117 March 2012.
3119 [I-D.ietf-oauth-assertions]
3120 Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
3121 "Assertion Framework for OAuth 2.0",
3122 draft-ietf-oauth-assertions-04 (work in progress),
3123 July 2012.
3125 [I-D.ietf-oauth-json-web-token]
3126 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
3127 (JWT)", draft-ietf-oauth-json-web-token-03 (work in
3128 progress), July 2012.
3130 [I-D.ietf-oauth-revocation]
3131 Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
3132 Revocation", draft-ietf-oauth-revocation-00 (work in
3133 progress), May 2012.
3135 [I-D.ietf-oauth-v2-http-mac]
3136 Hammer-Lahav, E., "HTTP Authentication: MAC Access
3137 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
3138 progress), February 2012.
3140 [IMEI] 3GPP, "International Mobile station Equipment Identities
3141 (IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
3143 [OASIS.saml-core-2.0-os]
3144 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
3145 "Assertions and Protocol for the OASIS Security Assertion
3146 Markup Language (SAML) V2.0", OASIS Standard saml-core-
3147 2.0-os, March 2005.
3149 [OASIS.sstc-gross-sec-analysis-response-01]
3150 Linn, J., Ed. and P. Mishra, Ed., "SSTC Response to
3151 "Security Analysis of the SAML Single Sign-on Browser/
3152 Artifact Profile"", January 2005.
3154 [OASIS.sstc-saml-bindings-1.1]
3155 Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
3156 "Bindings and Profiles for the OASIS Security Assertion
3157 Markup Language (SAML) V1.1", September 2003.
3159 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3160 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3161 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3163 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3165 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
3166 Requirements for Security", BCP 106, RFC 4086, June 2005.
3168 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
3169 Kerberos Network Authentication Service (V5)", RFC 4120,
3170 July 2005.
3172 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
3173 Internet Protocol", RFC 4301, December 2005.
3175 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3176 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3178 [framebusting]
3179 Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
3180 "Busting Frame Busting: a Study of Clickjacking
3181 Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
3182 Security and Privacy Workshop, 2010.
3184 [gross-sec-analysis]
3185 Gross, T., "Security Analysis of the SAML Single Sign-on
3186 Browser/Artifact Profile, 19th Annual Computer Security
3187 Applications Conference, Las Vegas", December 2003.
3189 [iFrame] World Wide Web Consortium, "Frames in HTML documents",
3190 W3C HTML 4.01, Dec 1999.
3192 [openid] "OpenID Foundation Home Page", .
3194 [owasp] "Open Web Application Security Project Home Page",
3195 .
3197 [portable-contacts]
3198 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
3199 .
3201 [ssl-latency]
3202 Sissel, J., Ed., "SSL handshake latency and HTTPS
3203 optimizations", June 2010.
3205 Appendix A. Document History
3207 [[ to be removed by RFC editor before publication as an RFC ]]
3209 draft-lodderstedt-oauth-security-01
3211 o section 4.4.1.2 - changed "resource server" to "client" in
3212 countermeasures description.
3214 o section 4.4.1.6 - changed "client shall authenticate the server"
3215 to "The browser shall be utilized to authenticate the redirection
3216 URI of the client"
3218 o section 5 - general review and alignment with public/confidential
3219 client terms
3221 o all sections - general clean-up and typo corrections
3223 draft-ietf-oauth-v2-threatmodel-00
3224 o section 3.4 - added the purposes for using authorization codes.
3226 o extended section 4.4.1.1
3228 o merged 4.4.1.5 into 4.4.1.2
3230 o corrected some typos
3232 o reformulated "session fixation", renamed respective sections into
3233 "authorization code disclosure through counterfeit client"
3235 o added new section "User session impersonation"
3237 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
3238 5.1.4.1.4, 5.2.3.5
3240 o added new threat "DoS using manufactured authorization codes" as
3241 proposed by Peifung E Lam
3243 o added XSRF and clickjacking (incl. state parameter explanation)
3245 o changed sub-section order in section 4.4.1
3247 o incorporated feedback from Skylar Woodward (client secrets) and
3248 Shane B Weeden (refresh tokens as client instance secret)
3250 o aligned client section with core draft's client type definition
3252 o converted I-D into WG document
3254 draft-ietf-oauth-v2-threatmodel-01
3256 o Alignment of terminology with core draft 22 (private/public
3257 client, redirect URI validation policy, replaced definition of the
3258 client categories by reference to respective core section)
3260 o Synchronisation with the core's security consideration section
3261 (UPDATE 10.12 CSRF, NEW 10.14/15)
3263 o Added Resource Owner Impersonation
3265 o Improved section 5
3267 o Renamed Refresh Token Replacement to Refresh Token Rotation
3269 draft-ietf-oauth-v2-threatmodel-02
3270 o Incoporated Tim Bray's review comments (e.g. removed all normative
3271 language)
3273 draft-ietf-oauth-v2-threatmodel-03
3275 o removed 2119 boilerplate and normative reference
3277 o incorporated shepherd review feedback
3279 draft-ietf-oauth-v2-threatmodel-06
3281 o incorporated AD review feedback
3283 draft-ietf-oauth-v2-threatmodel-07
3285 o added new section on token substituation
3287 o made references to core and bearer normative
3289 Authors' Addresses
3291 Torsten Lodderstedt (editor)
3292 Deutsche Telekom AG
3294 Email: torsten@lodderstedt.net
3296 Mark McGloin
3297 IBM
3299 Email: mark.mcgloin@ie.ibm.com
3301 Phil Hunt
3302 Oracle Corporation
3304 Email: phil.hunt@yahoo.com