idnits 2.17.1
draft-ietf-oauth-v2-threatmodel-08.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 (October 6, 2012) is 4219 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-06
== 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-01
== 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: April 9, 2013 IBM
6 P. Hunt
7 Oracle Corporation
8 October 6, 2012
10 OAuth 2.0 Threat Model and Security Considerations
11 draft-ietf-oauth-v2-threatmodel-08
13 Abstract
15 This document gives additional security considerations for OAuth,
16 beyond those in the OAuth 2.0 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 April 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . 17
75 4.1.3. Threat: Obtain Access Tokens . . . . . . . . . . . . . 19
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 . . . . . . . . . . . . . . . . . . . 23
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 . . . 24
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 . . . . . . . 28
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 . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . 34
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 . . . 37
121 4.4.2.3. Threat: Malicious client obtains authorization . . 37
122 4.4.2.4. Threat: Manipulation of scripts . . . . . . . . . 37
123 4.4.2.5. Threat: CSRF attack against redirect-uri . . . . . 38
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 . . . . 42
133 4.4.3.5. Threat: Obtain user passwords from
134 authorization server database . . . . . . . . . . 42
135 4.4.3.6. Threat: Online guessing . . . . . . . . . . . . . 42
136 4.4.4. Client Credentials . . . . . . . . . . . . . . . . . . 43
137 4.5. Refreshing an Access Token . . . . . . . . . . . . . . . . 43
138 4.5.1. Threat: Eavesdropping refresh tokens from
139 authorization server . . . . . . . . . . . . . . . . . 43
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 . . . 44
143 4.5.4. Threat: Obtain refresh token phishing by
144 counterfeit authorization server . . . . . . . . . . . 44
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 . . 45
149 4.6.3. Threat: Guessing access tokens . . . . . . . . . . . . 45
150 4.6.4. Threat: Access token phishing by counterfeit
151 resource server . . . . . . . . . . . . . . . . . . . 46
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 . . 47
155 4.6.7. Threat: Token leakage via logfiles and HTTP
156 referrers . . . . . . . . . . . . . . . . . . . . . . 47
157 5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
158 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 48
159 5.1.1. Ensure confidentiality of requests . . . . . . . . . . 48
160 5.1.2. Utiliize server authentication . . . . . . . . . . . . 48
161 5.1.3. Always keep the resource owner informed . . . . . . . 49
162 5.1.4. Credentials . . . . . . . . . . . . . . . . . . . . . 49
163 5.1.4.1. Enforce credential storage protection best
164 practices . . . . . . . . . . . . . . . . . . . . 50
165 5.1.4.2. Online attacks on secrets . . . . . . . . . . . . 51
166 5.1.5. Tokens (access, refresh, code) . . . . . . . . . . . . 52
167 5.1.5.1. Limit token scope . . . . . . . . . . . . . . . . 52
168 5.1.5.2. Expiration time . . . . . . . . . . . . . . . . . 52
169 5.1.5.3. Use short expiration time . . . . . . . . . . . . 53
170 5.1.5.4. Limit number of usages/ One time usage . . . . . . 53
171 5.1.5.5. Bind tokens to a particular resource server
172 (Audience) . . . . . . . . . . . . . . . . . . . . 54
173 5.1.5.6. Use endpoint address as token audience . . . . . . 54
174 5.1.5.7. Audience and Token scopes . . . . . . . . . . . . 54
175 5.1.5.8. Bind token to client id . . . . . . . . . . . . . 54
176 5.1.5.9. Signed tokens . . . . . . . . . . . . . . . . . . 55
177 5.1.5.10. Encryption of token content . . . . . . . . . . . 55
178 5.1.5.11. Assertion formats . . . . . . . . . . . . . . . . 55
179 5.1.6. Access tokens . . . . . . . . . . . . . . . . . . . . 55
180 5.2. Authorization Server . . . . . . . . . . . . . . . . . . . 55
181 5.2.1. Authorization Codes . . . . . . . . . . . . . . . . . 55
182 5.2.1.1. Automatic revocation of derived tokens if
183 abuse is detected . . . . . . . . . . . . . . . . 55
184 5.2.2. Refresh tokens . . . . . . . . . . . . . . . . . . . . 56
185 5.2.2.1. Restricted issuance of refresh tokens . . . . . . 56
186 5.2.2.2. Binding of refresh token to client_id . . . . . . 56
187 5.2.2.3. Refresh Token Rotation . . . . . . . . . . . . . . 56
188 5.2.2.4. Revoke refresh tokens . . . . . . . . . . . . . . 57
189 5.2.2.5. Device identification . . . . . . . . . . . . . . 57
190 5.2.2.6. X-FRAME-OPTION header . . . . . . . . . . . . . . 57
191 5.2.3. Client authentication and authorization . . . . . . . 57
192 5.2.3.1. Don't issue secrets to client with
193 inappropriate security policy . . . . . . . . . . 58
195 5.2.3.2. Require user consent for public clients
196 without secret . . . . . . . . . . . . . . . . . . 59
197 5.2.3.3. Client_id only in combination with redirect_uri . 59
198 5.2.3.4. Installation-specific client secrets . . . . . . . 59
199 5.2.3.5. Validation of pre-registered redirect_uri . . . . 60
200 5.2.3.6. Revoke client secrets . . . . . . . . . . . . . . 61
201 5.2.3.7. Use strong client authentication (e.g.
202 client_assertion / client_token) . . . . . . . . . 61
203 5.2.4. End-user authorization . . . . . . . . . . . . . . . . 61
204 5.2.4.1. Automatic processing of repeated
205 authorizations requires client validation . . . . 61
206 5.2.4.2. Informed decisions based on transparency . . . . . 62
207 5.2.4.3. Validation of client properties by end-user . . . 62
208 5.2.4.4. Binding of authorization code to client_id . . . . 62
209 5.2.4.5. Binding of authorization code to redirect_uri . . 62
210 5.3. Client App Security . . . . . . . . . . . . . . . . . . . 63
211 5.3.1. Don't store credentials in code or resources
212 bundled with software packages . . . . . . . . . . . . 63
213 5.3.2. Standard web server protection measures (for
214 config files and databases) . . . . . . . . . . . . . 63
215 5.3.3. Store secrets in a secure storage . . . . . . . . . . 63
216 5.3.4. Utilize device lock to prevent unauthorized device
217 access . . . . . . . . . . . . . . . . . . . . . . . . 64
218 5.3.5. Link state parameter to user agent session . . . . . . 64
219 5.4. Resource Servers . . . . . . . . . . . . . . . . . . . . . 64
220 5.4.1. Authorization headers . . . . . . . . . . . . . . . . 64
221 5.4.2. Authenticated requests . . . . . . . . . . . . . . . . 64
222 5.4.3. Signed requests . . . . . . . . . . . . . . . . . . . 65
223 5.5. A Word on User Interaction and User-Installed Apps . . . . 65
224 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 66
225 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
226 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
227 8.1. Informative References . . . . . . . . . . . . . . . . . . 67
228 8.2. Informative References . . . . . . . . . . . . . . . . . . 67
229 Appendix A. Document History . . . . . . . . . . . . . . . . . . 69
230 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 71
232 1. Introduction
234 This document gives additional security considerations for OAuth,
235 beyond those in the OAuth specification, based on a comprehensive
236 threat model for the OAuth 2.0 Protocol [I-D.ietf-oauth-v2]. It
237 contains the following content:
239 o Documents any assumptions and scope considered when creating the
240 threat model.
242 o Describes the security features in-built into the OAuth protocol
243 and how they are intended to thwart attacks.
245 o Gives a comprehensive threat model for OAuth and describes the
246 respective counter measures to thwart those threats.
248 Threats include any intentional attacks on OAuth tokens and resources
249 protected by OAuth tokens as well as security risks introduced if the
250 proper security measures are not put in place. Threats are
251 structured along the lines of the protocol structure to aid
252 development teams implement each part of the protocol securely. For
253 example all threats for granting access or all threats for a
254 particular grant type or all threats for protecting the resource
255 server.
257 Note: This document cannot assess the probability nor the risk
258 associated with a particular threat because those aspects strongly
259 depend on the particular application and deployment OAuth is used to
260 protect. Similar, impacts are given on a rather abstract level. But
261 the information given here may serve as a foundation for deployment-
262 specific threat models. Implementors may refine and detail the
263 abstract threat model in order to account for the specific properties
264 of their deployment and to come up with a risk analysis. As this
265 document is based on the base OAuth 2.0 specification, itdoes not
266 consider proposed extensions, such as client registration or
267 discovery, many of which are still under discussion.
269 2. Overview
271 2.1. Scope
273 The security considerations document only considers clients bound to
274 a particular deployment as supported by [I-D.ietf-oauth-v2]. Such
275 deployments have the following characteristics:
277 o Resource server URLs are static and well-known at development
278 time, authorization server URLs can be static or discovered.
280 o Token scope values (e.g. applicable URLs and methods) are well-
281 known at development time.
283 o Client registration: Since registration of clients is out of scope
284 of the current core spec, this document assumes a broad variety of
285 options from static registration during development time to
286 dynamic registration at runtime.
288 The following are considered out of scope :
290 o Communication between authorization server and resource server
292 o Token formats
294 o Except for "Resource Owner Password Credentials" (see
295 [I-D.ietf-oauth-v2], section 4.3), the mechanism used by
296 authorization servers to authenticate the user
298 o Mechanism by which a user obtained an assertion and any resulting
299 attacks mounted as a result of the assertion being false.
301 o Clients not bound to a specific deployment: An example could be a
302 mail client with support for contact list access via the portable
303 contacts API (see [portable-contacts]). Such clients cannot be
304 registered upfront with a particular deployment and should
305 dynamically discover the URLs relevant for the OAuth protocol.
307 2.2. Attack Assumptions
309 The following assumptions relate to an attacker and resources
310 available to an attacker:
312 o It is assumed the attacker has full access to the network between
313 the client and authorization servers and the client and the
314 resource server, respectively. The attacker may eavesdrop on any
315 communications between those parties. He is not assumed to have
316 access to communication between authorization and resource server.
318 o It is assumed an attacker has unlimited resources to mount an
319 attack.
321 o It is assumed that 2 of the 3 parties involved in the OAuth
322 protocol may collude to mount an attack against the 3rd party.
323 For example, the client and authorization server may be under
324 control of an attacker and collude to trick a user to gain access
325 to resources.
327 2.3. Architectural assumptions
329 This section documents the assumptions about the features,
330 limitations, and design options of the different entities of a OAuth
331 deployment along with the security-sensitive data-elements managed by
332 those entity. These assumptions are the foundation of the threat
333 analysis.
335 The OAuth protocol leaves deployments with a certain degree of
336 freedom how to implement and apply the standard. The core
337 specification defines the core concepts of an authorization server
338 and a resource server. Both servers can be implemented in the same
339 server entity, or they may also be different entities. The later is
340 typically the case for multi-service providers with a single
341 authentication and authorization system, and are more typical in
342 middleware architectures.
344 2.3.1. Authorization Servers
346 The following data elements are stored or accessible on the
347 authorization server:
349 o user names and passwords
351 o client ids and secrets
353 o client-specific refresh tokens
355 o client-specific access tokens (in case of handle-based design -
356 see Section 3.1)
358 o HTTPS certificate/key
360 o per-authorization process (in case of handle-based design -
361 Section 3.1): redirect_uri, client_id, authorization code
363 2.3.2. Resource Server
365 The following data elements are stored or accessible on the resource
366 server:
368 o user data (out of scope)
370 o HTTPS certificate/key
371 o authorization server credentials (handle-based design - see
372 Section 3.1), or
374 o authorization server shared secret/public key (assertion-based
375 design - see Section 3.1)
377 o access tokens (per request)
379 It is assumed that a resource server has no knowledge of refresh
380 tokens, user passwords, or client secrets.
382 2.3.3. Client
384 In OAuth a client is an application making protected resource
385 requests on behalf of the resource owner and with its authorization.
386 There are different types of clients with different implementation
387 and security characteristics, such as web, user-agent-based, and
388 native applications. A full definition of the different client types
389 and profiles is given in [I-D.ietf-oauth-v2], Section 2.1.
391 The following data elements are stored or accessible on the client:
393 o client id (and client secret or corresponding client credential)
395 o one or more refresh tokens (persistent) and access tokens
396 (transient) per end-user or other security-context or delegation
397 context
399 o trusted CA certificates (HTTPS)
401 o per-authorization process: redirect_uri, authorization code
403 3. Security Features
405 These are some of the security features which have been built into
406 the OAuth 2.0 protocol to mitigate attacks and security issues.
408 3.1. Tokens
410 OAuth makes extensive use many kinds of tokens (access tokens,
411 refresh tokens, authorization codes). The information content of a
412 token can be represented in two ways as follows:
414 Handle (or artifact) a reference to some internal data structure
415 within the authorization server; the internal data structure
416 contains the attributes of the token, such as user id, scope, etc.
417 Handles enable simple revocation and do not require cryptographic
418 mechanisms to protect token content from being modified. On the
419 other hand, handles require communication between issuing and
420 consuming entity (e.g. authorization and resource server) in order
421 to validate the token and obtain token-bound data. This
422 communication might have an negative impact on performance and
423 scalability if both entities reside on different systems. Handles
424 are therefore typically used if the issuing and consuming entity
425 are the same. A 'handle' token is often referred to as an
426 'opaque' token because the resource server does not need to be
427 able to interpret the token directly, it simply uses the token.
429 Assertions (aka self-contained token) a parseable token. An
430 assertion typically has a duration, has an audience, and is
431 digitally signed in order to ensure data integrity and origin
432 authentication. It contains information about the user and the
433 client. Examples of assertion formats are SAML assertions
434 [OASIS.saml-core-2.0-os] and Kerberos tickets [RFC4120].
435 Assertions can typically directly be validated and used by a
436 resource server without interactions with the authorization
437 server. This results in better performance and scalability in
438 deployment where issuing and consuming entity reside on different
439 systems. Implementing token revocation is more difficult with
440 assertions than with handles.
442 Tokens can be used in two ways to invoke requests on resource servers
443 as follows:
445 bearer token A 'bearer token' is a token that can be used by any
446 client who has received the token (e.g.
447 [I-D.ietf-oauth-v2-bearer]). Because mere possession is enough to
448 use the token it is important that communication between end-
449 points be secured to ensure that only authorized end-points may
450 capture the token. The bearer token is convenient to client
451 applications as it does not require them to do anything to use
452 them (such as a proof of identity). Bearer tokens have similar
453 characteristics to web single-sign-on (SSO) cookies used in
454 browsers.
456 proof token A 'proof token' is a token that can only be used by a
457 specific client. Each use of the token, requires the client to
458 perform some action that proves that it is the authorized user of
459 the token. Examples of this are MAC tokens, which require the
460 client to digitally sign the resource request with a secret
461 corresponding to the particular token send with the request
462 (e.g.[I-D.ietf-oauth-v2-http-mac]).
464 3.1.1. Scope
466 A Scope represents the access authorization associated with a
467 particular token with respect to resource servers, resources and
468 methods on those resources. Scopes are the OAuth way to explicitly
469 manage the power associated with an access token. A scope can be
470 controlled by the authorization server and/or the end-user in order
471 to limit access to resources for OAuth clients these parties deem
472 less secure or trustworthy. Optionally, the client can request the
473 scope to apply to the token but only for lesser scope than would
474 otherwise be granted, e.g. to reduce the potential impact if this
475 token is sent over non secure channels. A scope is typically
476 complemented by a restriction on a token's lifetime.
478 3.1.2. Limited Access Token Lifetime
480 The protocol parameter expires_in allows an authorization server
481 (based on its policies or on behalf of the end-user) to limit the
482 lifetime of an access token and to pass this information to the
483 client. This mechanism can be used to issue short-living tokens to
484 OAuth clients the authorization server deems less secure or where
485 sending tokens over non secure channels.
487 3.2. Access Token
489 An access token is used by a client to access a resource. Access
490 tokens typically have short life-spans (minutes or hours) that cover
491 typical session lifetimes. An access token may be refreshed through
492 the use of a refresh token. The short lifespan of an access token in
493 combination with the usage of refresh tokens enables the possibility
494 of passive revocation of access authorization on the expiry of the
495 current access token.
497 3.3. Refresh Token
499 A refresh token represents a long-lasting authorization of a certain
500 client to access resources on behalf of a resource owner. Such
501 tokens are exchanged between client and authorization server, only.
502 Clients use this kind of token to obtain ("refresh") new access
503 tokens used for resource server invocations.
505 A refresh token, coupled with a short access token lifetime, can be
506 used to grant longer access to resources without involving end user
507 authorization. This offers an advantage where resource servers and
508 authorization servers are not the same entity, e.g. in a distributed
509 environment, as the refresh token is always exchanged at the
510 authorization server. The authorization server can revoke the
511 refresh token at any time causing the granted access to be revoked
512 once the current access token expires. Because of this, a short
513 access token lifetime is important if timely revocation is a high
514 priority.
516 The refresh token is also a secret bound to the client identifier and
517 client instance which originally requested the authorization and
518 representing the original resource owner grant. This is ensured by
519 the authorization process as follows:
521 1. The resource owner and user-agent safely deliver the
522 authorization code to the client instance in first place.
524 2. The client uses it immediately in secure transport-level
525 communications to the authorization server and then securely
526 stores the long-lived refresh token.
528 3. The client always uses the refresh token in secure transport-
529 level communications to the authorization server to get an access
530 token (and optionally rollover the refresh token).
532 So as long as the confidentiality of the particular token can be
533 ensured by the client, a refresh token can also be used as an
534 alternative means to authenticate the client instance itself..
536 3.4. Authorization Code
538 An authorization code represents the intermediate result of a
539 successful end-user authorization process and is used by the client
540 to obtain access and refresh token. Authorization codes are sent to
541 the client's redirection URI instead of tokens for two purposes.
543 1. Browser-based flows expose protocol parameters to potential
544 attackers via URI query parameters (HTTP referrer), the browser
545 cache, or log file entries and could be replayed. In order to
546 reduce this threat, short-lived authorization codes are passed
547 instead of tokens and exchanged for tokens over a more secure
548 direct connection between client and authorization server.
550 2. It is much simpler to authenticate clients during the direct
551 request between client and authorization server than in the
552 context of the indirect authorization request. The latter would
553 require digital signatures.
555 3.5. Redirection URI
557 A redirection URI helps to detect malicious clients and prevents
558 phishing attacks from clients attempting to trick the user into
559 believing the phisher is the client. The value of the actual
560 redirection URI used in the authorization request has to be presented
561 and is verified when an authorization code is exchanged for tokens.
562 This helps to prevent attacks, where the authorization code is
563 revealed through redirectors and counterfeit web application clients.
564 The authorization server should require public clients and
565 confidential clients using implicit grant type to pre-register their
566 redirect URIs and validate against the registered redirection URI in
567 the authorization request.
569 3.6. State parameter
571 The state parameter is used to link requests and callbacks to prevent
572 Cross-Site Request Forgery attacks (see Section 4.4.1.8) where an
573 attacker authorizes access to his own resources and then tricks a
574 users into following a redirect with the attacker's token. This
575 parameter should bind to the authenticated state in a user agent and,
576 as per the core OAuth spec, the user agent must be capable of keeping
577 it in a location accessible only by the client and user agent, i.e.
578 protected by same-origin policy.
580 3.7. Client Identitifier
582 Authentication protocols have typically not taken into account the
583 identity of the software component acting on behalf of the end-user.
584 OAuth does this in order to increase the security level in delegated
585 authorization scenarios and because the client will be able to act
586 without the user being present.
588 OAuth uses the client identifier to collate associated request to the
589 same originator, such as
591 o a particular end-user authorization process and the corresponding
592 request on the token's endpoint to exchange the authorization code
593 for tokens or
595 o the initial authorization and issuance of a token by an end-user
596 to a particular client, and subsequent requests by this client to
597 obtain tokens without user consent (automatic processing of
598 repeated authorization)
600 This identifier may also be used by the authorization server to
601 display relevant registration information to a user when requesting
602 consent for scope requested by a particular client. The client
603 identifier may be used to limit the number of request for a
604 particular client or to charge the client per request. It may
605 furthermore be useful to differentiate access by different clients,
606 e.g. in server log files.
608 OAuth defines two client types, confidential and public, based on
609 their ability to authenticate with the authorization server (i.e.
610 ability to maintain the confidentiality of their client credentials).
611 Confidential clients are capable of maintaining the confidentiality
612 of client credentials (i.e. a client secret associated with the
613 client identifier) or capable of secure client authentication using
614 other means, such as a client assertion (e.g. SAML) or key
615 cryptography. The latter is considered more secure.
617 The authorization server should determine whether the client is
618 capable of keeping its secret confidential or using secure
619 authentication. Alternatively, the end-user can verify the identity
620 of the client, e.g. by only installing trusted applications.The
621 redicrection URI can be used to prevent delivering credentials to a
622 counterfeit client after obtaining end-user authorization in some
623 cases, but can't be used to verify the client identifier.
625 Clients can be categorized as follows based on the client type,
626 profile (e.g. native vs. web application - see [I-D.ietf-oauth-v2],
627 Section 9) and deployment model:
629 Deployment-independent client_id with pre-registered redirect_uri and
630 without client_secret Such an identifier is used by multiple
631 installations of the same software package. The identifier of
632 such a client can only be validated with the help of the end-user.
633 This is a viable option for native applications in order to
634 identify the client for the purpose of displaying meta information
635 about the client to the user and to differentiate clients in log
636 files. Revocation of the rights associated with such a client
637 identifier will affect ALL deployments of the respective software.
639 Deployment-independent client_id with pre-registered redirect_uri and
640 with client_secret This is an option for native applications only,
641 since web application would require different redirect URIs. This
642 category is not advisable because the client secret cannot be
643 protected appropriately (see Section 4.1.1). Due to its security
644 weaknesses, such client identities have the same trust level as
645 deployment-independent clients without secret. Revocation will
646 affect ALL deployments.
648 Deployment-specific client_id with pre-registered redirect_uri and
649 with client_secret The client registration process ensures the
650 validation of the client's properties, such as redirection URI,
651 website URL, web site name, contacts. Such a client identifier
652 can be utilized for all relevant use cases cited above. This
653 level can be achieved for web applications in combination with a
654 manual or user-bound registration process. Achieving this level
655 for native applications is much more difficult. Either the
656 installation of the application is conducted by an administrator,
657 who validates the client's authenticity, or the process from
658 validating the application to the installation of the application
659 on the device and the creation of the client credentials is
660 controlled end-to-end by a single entity (e.g. application market
661 provider). Revocation will affect a single deployment only.
663 Deployment-specific client_id with client_secret without validated
664 properties Such a client can be recognized by the authorization
665 server in transactions with subsequent requests (e.g.
666 authorization and token issuance, refresh token issuance and
667 access token refreshment). The authorization server cannot assure
668 any property of the client to end-users. Automatic processing of
669 re-authorizations could be allowed as well. Such client
670 credentials can be generated automatically without any validation
671 of client properties, which makes it another option especially for
672 native applications. Revocation will affect a single deployment
673 only.
675 4. Threat Model
677 This section gives a comprehensive threat model of OAuth 2.0.
678 Threats are grouped first by attacks directed against an OAuth
679 component, which are client, authorization server, and resource
680 server. Subsequently, they are grouped by flow, e.g. obtain token or
681 access protected resources. Every countermeasure description refers
682 to a detailed description in Section 5.
684 4.1. Clients
686 This section describes possible threats directed to OAuth clients.
688 4.1.1. Threat: Obtain Client Secrets
690 The attacker could try to get access to the secret of a particular
691 client in order to:
693 o replay its refresh tokens and authorization codes, or
695 o obtain tokens on behalf of the attacked client with the privileges
696 of that client_id acting as an instance of the client.
698 The resulting impact would be:
700 o Client authentication of access to authorization server can be
701 bypassed
703 o Stolen refresh tokens or authorization codes can be replayed
705 Depending on the client category, the following attacks could be
706 utilized to obtain the client secret.
708 Attack: Obtain Secret From Source Code or Binary:
710 This applies for all client types. For open source projects, secrets
711 can be extracted directly from source code in their public
712 repositories. Secrets can be extracted from application binaries
713 just as easily when published source is not available to the
714 attacker. Even if an application takes significant measures to
715 obfuscate secrets in their application distribution one should
716 consider that the secret can still be reverse-engineered by anyone
717 with access to a complete functioning application bundle or binary.
719 Countermeasures:
721 o Don't issue secrets to public clients or clients with
722 inappropriate security policy - Section 5.2.3.1
724 o Require user consent for public clients- Section 5.2.3.2
726 o Use deployment-specific client secrets - Section 5.2.3.4
728 o Revoke client secrets - Section 5.2.3.6
730 Attack: Obtain a Deployment-Specific Secret:
732 An attacker may try to obtain the secret from a client installation,
733 either from a web site (web server) or a particular devices (native
734 application).
736 Countermeasures:
738 o Web server: apply standard web server protection measures (for
739 config files and databases) - Section 5.3.2
741 o Native applications: Store secrets in a secure local storage -
742 Section 5.3.3
744 o Revoke client secrets - Section 5.2.3.6
746 4.1.2. Threat: Obtain Refresh Tokens
748 Depending on the client type, there are different ways refresh tokens
749 may be revealed to an attacker. The following sub-sections give a
750 more detailed description of the different attacks with respect to
751 different client types and further specialized countermeasures.
752 Before detailing those threats, here are some generally applicable
753 countermeasures:
755 o The authorization server should validate the client id associated
756 with the particular refresh token with every refresh request-
757 Section 5.2.2.2
759 o Limit token scope - Section 5.1.5.1
761 o Revoke refresh tokens - Section 5.2.2.4
763 o Revoke client secrets - Section 5.2.3.6
765 o Refresh tokens can automatically be replaced in order to detect
766 unauthorized token usage by another party (Refresh Token Rotation)
767 - Section 5.2.2.3
769 Attack: Obtain Refresh Token from Web application:
771 An attacker may obtain the refresh tokens issued to a web application
772 by way of overcoming the web server's security controls. Impact:
773 Since a web application manages the user accounts of a certain site,
774 such an attack would result in an exposure of all refresh tokens on
775 that site to the attacker.
777 Countermeasures:
779 o Standard web server protection measures - Section 5.3.2
781 o Use strong client authentication (e.g. client_assertion /
782 client_token), so the attacker cannot obtain the client secret
783 required to exchange the tokens - Section 5.2.3.7
785 Attack: Obtain Refresh Token from Native clients:
787 On native clients, leakage of a refresh token typically affects a
788 single user, only.
790 Read from local file system: The attacker could try get file system
791 access on the device and read the refresh tokens. The attacker could
792 utilize a malicious application for that purpose.
794 Countermeasures:
796 o Store secrets in a secure storage - Section 5.3.3
798 o Utilize device lock to prevent unauthorized device access -
799 Section 5.3.4
801 Attack: Steal device:
803 The host device (e.g. mobile phone) may be stolen. In that case, the
804 attacker gets access to all applications under the identity of the
805 legitimate user.
807 Countermeasures:
809 o Utilize device lock to prevent unauthorized device access -
810 Section 5.3.4
812 o Where a user knows the device has been stolen, they can revoke the
813 affected tokens - Section 5.2.2.4
815 Attack: Clone Device:
817 All device data and applications are copied to another device.
818 Applications are used as-is on the target device.
820 Countermeasures:
822 o Utilize device lock to prevent unauthorized device access -
823 Section 5.3.4
825 o Combine refresh token request with device identification -
826 Section 5.2.2.5
828 o Refresh Token Rotation - Section 5.2.2.3
829 o Where a user knows the device has been cloned, they can use this
830 countermeasure - Refresh Token Revocation - Section 5.2.2.4
832 4.1.3. Threat: Obtain Access Tokens
834 Depending on the client type, there are different ways access tokens
835 may be revealed to an attacker. Access tokens could be stolen from
836 the device if the application stores them in a storage, which is
837 accessible to other applications.
839 Impact: Where the token is a bearer token and no additional mechanism
840 is used to identify the client, the attacker can access all resources
841 associated with the token and its scope.
843 Countermeasures:
845 o Keep access tokens in transient memory and limit grants:
846 Section 5.1.6
848 o Limit token scope - Section 5.1.5.1
850 o Keep access tokens in private memory or apply same protection
851 means as for refresh tokens - Section 5.2.2
853 o Keep access token lifetime short - Section 5.1.5.3
855 4.1.4. Threat: End-user credentials phished using compromised or
856 embedded browser
858 A malicious application could attempt to phish end-user passwords by
859 misusing an embedded browser in the end-user authorization process,
860 or by presenting its own user-interface instead of allowing trusted
861 system browser to render the authorization user interface. By doing
862 so, the usual visual trust mechanisms may be bypassed (e.g. TLS
863 confirmation, web site mechanisms). By using an embedded or internal
864 client application user interface, the client application has access
865 to additional information it should not have access to (e.g. uid/
866 password).
868 Impact: If the client application or the communication is
869 compromised, the user would not be aware and all information in the
870 authorization exchange could be captured such as username and
871 password.
873 Countermeasures:
875 o The OAuth flow is designed so that client applications never need
876 to know user passwords. Client applications should avoid directly
877 asking users for the their credentials. In addition, end users
878 could be educated about phishing attacks and best practices, such
879 as only accessing trusted clients, as OAuth does not provide any
880 protection against malicious applications and the end user is
881 solely responsible for the trustworthiness of any native
882 application installed.
884 o Client applications could be validated prior to publication in an
885 application market for users to access. That validation is out of
886 scope for OAuth but could include validating that the client
887 application handles user authentication in an appropriate way.
889 o Client developers should not write client applications that
890 collect authentication information directly from users and should
891 instead delegate this task to a trusted system component, e.g. the
892 system-browser.
894 4.1.5. Threat: Open Redirectors on client
896 An open redirector is an endpoint using a parameter to automatically
897 redirect a user-agent to the location specified by the parameter
898 value without any validation. If the authorization server allows the
899 client to register only part of the redirection URI, an attacker can
900 use an open redirector operated by the client to construct a
901 redirection URI that will pass the authorization server validation
902 but will send the authorization code or access token to an endpoint
903 under the control of the attacker.
905 Impact: An attacker could gain access to authorization codes or
906 access tokens
908 Countermeasure
910 o require clients to register full redirection URI Section 5.2.3.5
912 4.2. Authorization Endpoint
914 4.2.1. Threat: Password phishing by counterfeit authorization server
916 OAuth makes no attempt to verify the authenticity of the
917 Authorization Server. A hostile party could take advantage of this
918 by intercepting the Client's requests and returning misleading or
919 otherwise incorrect responses. This could be achieved using DNS or
920 ARP spoofing. Wide deployment of OAuth and similar protocols may
921 cause users to become inured to the practice of being redirected to
922 websites where they are asked to enter their passwords. If users are
923 not careful to verify the authenticity of these websites before
924 entering their credentials, it will be possible for attackers to
925 exploit this practice to steal Users' passwords.
927 Countermeasures:
929 o Authorization servers should consider such attacks when developing
930 services based on OAuth, and should require the use of transport-
931 layer security for any requests where the authenticity of the
932 authorization server or of request responses is an issue (see
933 Section 5.1.2).
935 o Authorization servers should attempt to educate Users about the
936 risks phishing attacks pose, and should provide mechanisms that
937 make it easy for users to confirm the authenticity of their sites.
939 4.2.2. Threat: User unintentionally grants too much access scope
941 When obtaining end user authorization, the end-user may not
942 understand the scope of the access being granted and to whom or they
943 may end up providing a client with access to resources which should
944 not be permitted.
946 Countermeasures:
948 o Explain the scope (resources and the permissions) the user is
949 about to grant in an understandable way - Section 5.2.4.2
951 o Narrow scope based on client - When obtaining end user
952 authorization and where the client requests scope, the
953 authorization server may want to consider whether to honour that
954 scope based on the client identifier. That decision is between
955 the client and authorization server and is outside the scope of
956 this spec. The authorization server may also want to consider
957 what scope to grant based on the client type, e.g. providing lower
958 scope to public clients. - Section 5.1.5.1
960 4.2.3. Threat: Malicious client obtains existing authorization by fraud
962 Authorization servers may wish to automatically process authorization
963 requests from clients which have been previously authorized by the
964 user. When the user is redirected to the authorization server's end-
965 user authorization endpoint to grant access, the authorization server
966 detects that the user has already granted access to that particular
967 client. Instead of prompting the user for approval, the
968 authorization server automatically redirects the user back to the
969 client.
971 A malicious client may exploit that feature and try to obtain such an
972 authorization code instead of the legitimate client.
974 Countermeasures:
976 o Authorization servers should not automatically process repeat
977 authorizations to public clients unless the client is validated
978 using a pre-registered redirect URI (Section 5.2.3.5 )
980 o Authorization servers can mitigate the risks associated with
981 automatic processing by limiting the scope of Access Tokens
982 obtained through automated approvals - Section 5.1.5.1
984 4.2.4. Threat: Open redirector
986 An attacker could use the end-user authorization endpoint and the
987 redirection URI parameter to abuse the authorization server as an
988 open redirector. An open redirector is an endpoint using a parameter
989 to automatically redirect a user-agent to the location specified by
990 the parameter value without any validation.
992 Impact: An attacker could utilize a user's trust in your
993 authorization server to launch a phishing attack.
995 Countermeasure
997 o require clients to register full redirection URI Section 5.2.3.5
999 o don't redirect to redirection URI, if client identifier or
1000 redirection URI can't be verified Section 5.2.3.5
1002 4.3. Token endpoint
1004 4.3.1. Threat: Eavesdropping access tokens
1006 Attackers may attempt to eavesdrop access token in transit from the
1007 authorization server to the client.
1009 Impact: The attacker is able to access all resources with the
1010 permissions covered by the scope of the particular access token.
1012 Countermeasures:
1014 o As per the core OAuth spec, the authorization servers must ensure
1015 that these transmissions are protected using transport-layer
1016 mechanisms such as TLS (see Section 5.1.1).
1018 o If end-to-end confidentiality cannot be guaranteed, reducing scope
1019 (see Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
1020 tokens can be used to reduce the damage in case of leaks.
1022 4.3.2. Threat: Obtain access tokens from authorization server database
1024 This threat is applicable if the authorization server stores access
1025 tokens as handles in a database. An attacker may obtain access
1026 tokens from the authorization server's database by gaining access to
1027 the database or launching a SQL injection attack. Impact: disclosure
1028 of all access tokens
1030 Countermeasures:
1032 o Enforce system security measures - Section 5.1.4.1.1
1034 o Store access token hashes only - Section 5.1.4.1.3
1036 o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
1038 4.3.3. Threat: Disclosure of client credentials during transmission
1040 An attacker could attempt to eavesdrop the transmission of client
1041 credentials between client and server during the client
1042 authentication process or during OAuth token requests.
1044 Impact: Revelation of a client credential enabling phishing or
1045 impersonation of a client service.
1047 Countermeasures:
1049 o The transmission of client credentials must be protected using
1050 transport-layer mechanisms such as TLS (see Section 5.1.1).
1052 o Alternative authentication means, which do not require to send
1053 plaintext credentials over the wire (e.g. Hash-based Message
1054 Authentication Code)
1056 4.3.4. Threat: Obtain client secret from authorization server database
1058 An attacker may obtain valid client_id/secret combinations from the
1059 authorization server's database by gaining access to the database or
1060 launching a SQL injection attack. Impact: disclosure of all
1061 client_id/secret combinations. This allows the attacker to act on
1062 behalf of legitimate clients.
1064 Countermeasures:
1066 o Enforce system security measures - Section 5.1.4.1.1
1068 o Enforce standard SQL injection Countermeasures - Section 5.1.4.1.2
1070 o Ensure proper handling of credentials as per Enforce credential
1071 storage protection best practices.
1073 4.3.5. Threat: Obtain client secret by online guessing
1075 An attacker may try to guess valid client_id/secret pairs. Impact:
1076 disclosure of single client_id/secret pair.
1078 Countermeasures:
1080 o Use high entropy for secrets - Section 5.1.4.2.2
1082 o Lock accounts - Section 5.1.4.2.3
1084 o Use Strong Client Authentication - Section 5.2.3.7
1086 4.4. Obtaining Authorization
1088 This section covers threats which are specific to certain flows
1089 utilized to obtain access tokens. Each flow is characterized by
1090 response types and/or grant types on the end-user authorization and
1091 token endpoint, respectively.
1093 4.4.1. Authorization Code
1095 4.4.1.1. Threat: Eavesdropping or leaking authorization codes
1097 An attacker could try to eavesdrop transmission of the authorization
1098 code between authorization server and client. Furthermore,
1099 authorization codes are passed via the browser which may
1100 unintentionally leak those codes to untrusted web sites and attackers
1101 in different ways:
1103 o Referrer headers: browsers frequently pass a "referer" header when
1104 a web page embeds content, or when a user travels from one web
1105 page to another web page. These referrer headers may be sent even
1106 when the origin site does not trust the destination site. The
1107 referrer header is commonly logged for traffic analysis purposes.
1109 o Request logs: web server request logs commonly include query
1110 parameters on requests.
1112 o Open redirectors: web sites sometimes need to send users to
1113 another destination via a redirector. Open redirectors pose a
1114 particular risk to web-based delegation protocols because the
1115 redirector can leak verification codes to untrusted destination
1116 sites.
1118 o Browser history: web browsers commonly record visited URLs in the
1119 browser history. Another user of the same web browser may be able
1120 to view URLs that were visited by previous users.
1122 Note: A description of a similar attacks on the SAML protocol can be
1123 found at [OASIS.sstc-saml-bindings-1.1], Section 4.1.1.9.1,
1124 [gross-sec-analysis], and
1125 [OASIS.sstc-gross-sec-analysis-response-01].
1127 Countermeasures:
1129 o As per the core OAuth spec, the authorization server as well as
1130 the client must ensure that these transmissions are protected
1131 using transport-layer mechanisms such as TLS (see Section 5.1.1).
1133 o The authorization server will require the client to authenticate
1134 wherever possible, so the binding of the authorization code to a
1135 certain client can be validated in a reliable way (see
1136 Section 5.2.4.4).
1138 o Use short expiry time for authorization codes - Section 5.1.5.3
1140 o The authorization server should enforce a one time usage
1141 restriction (see Section 5.1.5.4).
1143 o If an Authorization Server observes multiple attempts to redeem an
1144 authorization code, the Authorization Server may want to revoke
1145 all tokens granted based on the authorization code (see
1146 Section 5.2.1.1).
1148 o In the absence of these countermeasures, reducing scope
1149 (Section 5.1.5.1) and expiry time (Section 5.1.5.3) for access
1150 tokens can be used to reduce the damage in case of leaks.
1152 o The client server may reload the target page of the redirection
1153 URI in order to automatically cleanup the browser cache.
1155 4.4.1.2. Threat: Obtain authorization codes from authorization server
1156 database
1158 This threat is applicable if the authorization server stores
1159 authorization codes as handles in a database. An attacker may obtain
1160 authorization codes from the authorization server's database by
1161 gaining access to the database or launching a SQL injection attack.
1163 Impact: disclosure of all authorization codes, most likely along with
1164 the respective redirect_uri and client_id values.
1166 Countermeasures:
1168 o Best practices for credential storage protection should be
1169 employed - Section 5.1.4.1
1171 o Enforce system security measures - Section 5.1.4.1.1
1173 o Store access token hashes only - Section 5.1.4.1.3
1175 o Standard SQL injection countermeasures - Section 5.1.4.1.2
1177 4.4.1.3. Threat: Online guessing of authorization codes
1179 An attacker may try to guess valid authorization code values and send
1180 it using the grant type "code" in order to obtain a valid access
1181 token.
1183 Impact: disclosure of single access token, probably also associated
1184 refresh token.
1186 Countermeasures:
1188 o Handle-based tokens must use high entropy: Section 5.1.4.2.2
1190 o Assertion-based tokens should be signed: Section 5.1.5.9
1192 o Authenticate the client, adds another value the attacker has to
1193 guess - Section 5.2.3.4
1195 o Binding of authorization code to redirection URI, adds another
1196 value the attacker has to guess - Section 5.2.4.5
1198 o Use short expiry time for tokens - Section 5.1.5.3
1200 4.4.1.4. Threat: Malicious client obtains authorization
1202 A malicious client could pretend to be a valid client and obtain an
1203 access authorization that way. The malicious client could even
1204 utilize screen scraping techniques in order to simulate the user
1205 consent in the authorization flow.
1207 Assumption: It is not the task of the authorization server to protect
1208 the end-user's device from malicious software. This is the
1209 responsibility of the platform running on the particular device
1210 probably in cooperation with other components of the respective
1211 ecosystem (e.g. an application management infrastructure). The sole
1212 responsibility of the authorization server is to control access to
1213 the end-user's resources living in resource servers and to prevent
1214 unauthorized access to them via the OAuth protocol. Based on this
1215 assumption, the following countermeasures are available to cope with
1216 the threat.
1218 Countermeasures:
1220 o The authorization server should authenticate the client, if
1221 possible (see Section 5.2.3.4). Note: the authentication takes
1222 place after the end-user has authorized the access.
1224 o The authorization server should validate the client's redirection
1225 URI against the pre-registered redirection URI, if one exists (see
1226 Section 5.2.3.5). Note: An invalid redirect URI indicates an
1227 invalid client whereas a valid redirect URI does not neccesserily
1228 indicate a valid client. The level of confidence depends on the
1229 client type. For web applications, the confidence is high since
1230 the redirect URI refers to the globally unique network endpoint of
1231 this application whose fully qualified domain name (FQDN) is also
1232 validated using HTTPS server authentication by the user agent. In
1233 contrast for native clients, the redirect URI typically refers to
1234 device local resources, e.g. a custom scheme. So a malicious
1235 client on a particular device can use the valid redirect URI the
1236 legitimate client uses on all other devices.
1238 o After authenticating the end-user, the authorization server should
1239 ask him/her for consent. In this context, the authorization
1240 server should explain to the end-user the purpose, scope, and
1241 duration of the authorization the client asked for. Moreover, the
1242 authorization server should show the user any identity information
1243 it has for that client. It is up to the user to validate the
1244 binding of this data to the particular application (e.g. Name)
1245 and to approve the authorization request. (see Section 5.2.4.3).
1247 o The authorization server should not perform automatic re-
1248 authorizations for clients it is unable to reliably authenticate
1249 or validate (see Section 5.2.4.1).
1251 o If the authorization server automatically authenticates the end-
1252 user, it may nevertheless require some user input in order to
1253 prevent screen scraping. Examples are CAPTCHAs (Completely
1254 Automated Public Turing test to tell Computers and Humans Apart)
1255 or other multi-factor authentication techniques such as random
1256 questions, token code generators, etc.
1258 o The authorization server may also limit the scope of tokens it
1259 issues to clients it cannot reliably authenticate (see
1260 Section 5.1.5.1).
1262 4.4.1.5. Threat: Authorization code phishing
1264 A hostile party could impersonate the client site and get access to
1265 the authorization code. This could be achieved using DNS or ARP
1266 spoofing. This applies to clients, which are web applications, thus
1267 the redirect URI is not local to the host where the user's browser is
1268 running.
1270 Impact: This affects web applications and may lead to a disclosure of
1271 authorization codes and, potentially, the corresponding access and
1272 refresh tokens.
1274 Countermeasures:
1276 It is strongly recommended that one of the following countermeasures
1277 is utilized in order to prevent this attack:
1279 o The redirection URI of the client should point to a HTTPS
1280 protected endpoint and the browser should be utilized to
1281 authenticate this redirection URI using server authentication (see
1282 Section 5.1.2).
1284 o The authorization server should require the client to be
1285 authenticated, i.e. confidential client, so the binding of the
1286 authorization code to a certain client can be validated in a
1287 reliable way (see Section 5.2.4.4).
1289 4.4.1.6. Threat: User session impersonation
1291 A hostile party could impersonate the client site and impersonate the
1292 user's session on this client. This could be achieved using DNS or
1293 ARP spoofing. This applies to clients, which are web applications,
1294 thus the redirect URI is not local to the host where the user's
1295 browser is running.
1297 Impact: An attacker who intercepts the authorization code as it is
1298 sent by the browser to the callback endpoint can gain access to
1299 protected resources by submitting the authorization code to the
1300 client. The client will exchange the authorization code for an
1301 access token and use the access token to access protected resources
1302 for the benefit of the attacker, delivering protected resources to
1303 the attacker, or modifying protected resources as directed by the
1304 attacker. If OAuth is used by the client to delegate authentication
1305 to a social site (e.g. as in the implementation of "Login" button to
1306 a third-party social network site), the attacker can use the
1307 intercepted authorization code to log in to the client as the user.
1309 Note: Authenticating the client during authorization code exchange
1310 will not help to detect such an attack as it is the legitimate client
1311 that obtains the tokens.
1313 Countermeasures:
1315 o In order to prevent an attacker from impersonating the end-users
1316 session, the redirection URI of the client should point to a HTTPS
1317 protected endpoint and the browser should be utilized to
1318 authenticate this redirection URI using server authentication (see
1319 Section 5.1.2)
1321 4.4.1.7. Threat: Authorization code leakage through counterfeit client
1323 The attack leverages the authorization code grant type in an attempt
1324 to get another user (victim) to log-in, authorize access to his/her
1325 resources, and subsequently obtain the authorization code and inject
1326 it into a client application using the attacker's account. The goal
1327 is to associate an access authorization for resources of the victim
1328 with the user account of the attacker on a client site.
1330 The attacker abuses an existing client application and combines it
1331 with his own counterfeit client web site. The attack depends on the
1332 victim expecting the client application to request access to a
1333 certain resource server. The victim, seeing only a normal request
1334 from an expected application, approves the request. The attacker
1335 then uses the victim's authorization to gain access to the
1336 information unknowingly authorized by the victim.
1338 The attacker conducts the following flow:
1340 1. The attacker accesses the client web site (or application) and
1341 initiates data access to a particular resource server. The
1342 client web site in turn initiates an authorization request to the
1343 resource server's authorization server. Instead of proceeding
1344 with the authorization process, the attacker modifies the
1345 authorization server end-user authorization URL as constructed by
1346 the client to include a redirection URI parameter referring to a
1347 web site under his control (attacker's web site).
1349 2. The attacker tricks another user (the victim) to open that
1350 modified end-user authorization URI and to authorize access (e.g.
1351 an email link, or blog link). The way the attacker achieves that
1352 goal is out of scope.
1354 3. Having clicked the link, the victim is requested to authenticate
1355 and authorize the client site to have access.
1357 4. After completion of the authorization process, the authorization
1358 server redirects the user agent to the attacker's web site
1359 instead of the original client web site.
1361 5. The attacker obtains the authorization code from his web site by
1362 means out of scope of this document.
1364 6. He then constructs a redirection URI to the target web site (or
1365 application) based on the original authorization request's
1366 redirection URI and the newly obtained authorization code and
1367 directs his user agent to this URL. The authorization code is
1368 injected into the original client site (or application).
1370 7. The client site uses the authorization code to fetch a token from
1371 the authorization server and associates this token with the
1372 attacker's user account on this site.
1374 8. The attacker may now access the victim's resources using the
1375 client site.
1377 Impact: The attacker gains access to the victim's resources as
1378 associated with his account on the client site.
1380 Countermeasures:
1382 o The attacker will need to use another redirection URI for its
1383 authorization process rather than the target web site because it
1384 needs to intercept the flow. So if the authorization server
1385 associates the authorization code with the redirection URI of a
1386 particular end-user authorization and validates this redirection
1387 URI with the redirection URI passed to the token's endpoint, such
1388 an attack is detected (see Section 5.2.4.5).
1390 o The authorization server may also enforce the usage and validation
1391 of pre-registered redirect URIs (see Section 5.2.3.5). This will
1392 allow for an early recognition of authorization code disclosure to
1393 counterfeit clients.
1395 o For native applications, one could also consider to use
1396 deployment-specific client ids and secrets (see Section 5.2.3.4,
1397 along with the binding of authorization code to client_id (see
1398 Section 5.2.4.4), to detect such an attack because the attacker
1399 does not have access the deployment-specific secret. Thus he will
1400 not be able to exchange the authorization code.
1402 o The client may consider using other flows, which are not
1403 vulnerable to this kind of attack such as "Implicit Grant" or
1404 "Resource Owner Password Credentials" (see Section 4.4.2 or
1405 Section 4.4.3).
1407 4.4.1.8. Threat: CSRF attack against redirect-uri
1409 Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
1410 requests are transmitted from a user that the website trusts or has
1411 authenticated (e.g., via HTTP redirects or HTML forms). CSRF attacks
1412 on OAuth approvals can allow an attacker to obtain authorization to
1413 OAuth protected resources without the consent of the User.
1415 This attack works against the redirection URI used in the
1416 authorization code flow. An attacker could authorize an
1417 authorization code to their own protected resources on an
1418 authorization server. He then aborts the redirect flow back to the
1419 client on his device and tricks the victim into executing the
1420 redirect back to the client. The client receives the redirect,
1421 fetches the token(s) from the authorization server and associates the
1422 victim's client session with the resources accessible using the
1423 token.
1425 Impact: The user accesses resources on behalf of the attacker. The
1426 effective impact depends on the type of resource accessed. For
1427 example, the user may upload private items to an attacker's
1428 resources. Or when using OAuth in 3rd party login scenarios, the
1429 user may associate his client account with the attacker's identity at
1430 the external identity provider. This way the attacker could easily
1431 access the victim's data at the client by logging in from another
1432 device with his credentials at the external identity provider.
1434 Countermeasures:
1436 o The state parameter should be used to link the authorization
1437 request with the redirection URI used to deliver the access token.
1438 Section 5.3.5
1440 o Client developers and end-user can be educated to not follow
1441 untrusted URLs.
1443 4.4.1.9. Threat: Clickjacking attack against authorization
1445 With Clickjacking, a malicious site loads the target site in a
1446 transparent iFrame (see [iFrame]) overlaid on top of a set of dummy
1447 buttons which are carefully constructed to be placed directly under
1448 important buttons on the target site. When a user clicks a visible
1449 button, they are actually clicking a button (such as an "Authorize"
1450 button) on the hidden page.
1452 Impact: An attacker can steal a user's authentication credentials and
1453 access their resources
1455 Countermeasure
1457 o For newer browsers, avoidance of iFrames during authorization can
1458 be enforced server side by using the X-FRAME-OPTION header -
1459 Section 5.2.2.6
1461 o For older browsers, javascript frame-busting (see [framebusting])
1462 techniques can be used but may not be effective in all browsers.
1464 4.4.1.10. Threat: Resource Owner Impersonation
1466 When a client requests access to protected resources, the
1467 authorization flow normally involves the resource owner's explicit
1468 response to the access request, either granting or denying access to
1469 the protected resources. A malicious client can exploit knowledge of
1470 the structure of this flow in order to gain authorization without the
1471 resource owner's consent, by transmitting the necessary requests
1472 programmatically, and simulating the flow against the authorization
1473 server. That way, the client may gain access to the victim's
1474 resources without her approval. An authorization server will be
1475 vulnerable to this threat, if it uses non-interactive authentication
1476 mechanisms or splits the authorization flow across multiple pages.
1478 The malicious client might embed a hidden HTML user agent, interpret
1479 the HTML forms sent by the authorization server, and automatically
1480 send the corresponding form post requests. As a pre-requisite, the
1481 attacker must be able to execute the authorization process in the
1482 context of an already authenticated session of the resource owner
1483 with the authorization server. There are different ways to achieve
1484 this:
1486 o The malicious client could abuse an existing session in an
1487 external browser or cross-browser cookies on the particular
1488 device.
1490 o The malicious client could also request authorization for an
1491 initial scope acceptable to the user and then silently abuse the
1492 resulting session in his browser instance to "silently" request
1493 another scope.
1495 o Alternatively, the attacker might exploit an authorization
1496 server's ability to authenticate the resource owner automatically
1497 and without user interactions, e.g. based on certificates.
1499 In all cases, such an attack is limited to clients running on the
1500 victim's device, within the user agent or as native app.
1502 Please note: Such attacks cannot be prevented using CSRF
1503 countermeasures, since the attacker just "executes" the URLs as
1504 prepared by the authorization server including any nonce etc.
1506 Countermeasures:
1508 Authorization servers should decide, based on an analysis of the risk
1509 associated with this threat, whether to detect and prevent this
1510 threat.
1512 In order to prevent such an attack, the authorization server may
1513 force a user interaction based on non-predictable input values as
1514 part of the user consent approval. The authorization server could
1516 o combine password authentication and user consent in a single form,
1518 o make use of CAPTCHAs, or
1520 o or use one-time secrets sent out of band to the resource owner
1521 (e.g. via text or instant message).
1523 Alternatively in order to allow the resource owner to detect abuse,
1524 the authorization server could notify the resource owner of any
1525 approval by appropriate means, e.g. text or instant message or
1526 e-Mail.
1528 4.4.1.11. Threat: DoS, Exhaustion of resources attacks
1530 If an authorization server includes a nontrivial amount of entropy in
1531 authorization codes or access tokens (limiting the number of possible
1532 codes/tokens) and automatically grants either without user
1533 intervention and has no limit on code or access tokens per user, an
1534 attacker could exhaust the pool of authorization codes by repeatedly
1535 directing the user's browser to request code or access tokens.
1537 Countermeasures:
1539 o The authorization server should consider limiting the number of
1540 access tokens granted per user. The authorization server should
1541 include a nontrivial amount of entropy in authorization codes.
1543 4.4.1.12. Threat: DoS using manufactured authorization codes
1545 An attacker who owns a botnet can locate the redirect URIs of clients
1546 that listen on HTTP, access them with random authorization codes, and
1547 cause a large number of HTTPS connections to be concentrated onto the
1548 authorization server. This can result in a DoS attack on the
1549 authorization server.
1551 This attack can still be effective even when CSRF defense/the 'state'
1552 parameter (see Section 4.4.1.8) is deployed on the client side. With
1553 such a defense, the attacker might need to incur an additional HTTP
1554 request to obtain a valid CSRF code/ state parameter. This
1555 apparently cuts down the effectiveness of the attack by a factor of
1556 2. However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
1557 factor is estimated to be around 3.5x at [ssl-latency]) the attacker
1558 still achieves a magnification of resource utilization at the expense
1559 of the authorization server.
1561 Impact: There are a few effects that the attacker can accomplish with
1562 this OAuth flow that they cannot easily achieve otherwise.
1564 1. Connection laundering: With the clients as the relay between the
1565 attacker and the authorization server, the authorization server
1566 learns little or no information about the identity of the
1567 attacker. Defenses such as rate limiting on the offending
1568 attacker machines are less effective due to the difficulty to
1569 identify the attacking machines. Although an attacker could also
1570 launder its connections through an anonymizing system such as
1571 Tor, the effectiveness of that approach depends on the capacity
1572 of the anonymizing system. On the other hand, a potentially
1573 large number of OAuth clients could be utilized for this attack.
1575 2. Asymmetric resource utilization: The attacker incurs the cost of
1576 an HTTP connection and causes an HTTPS connection to be made on
1577 the authorization server; and the attacker can co-ordinate the
1578 timing of such HTTPS connections across multiple clients
1579 relatively easily. Although the attacker could achieve something
1580 similar, say, by including an iframe pointing to the HTTPS URL of
1581 the authorization server in an HTTP web page and lure web users
1582 to visit that page, timing attacks using such a scheme may be
1583 more difficult as it seems nontrivial to synchronize a large
1584 number of users to simultaneously visit a particular site under
1585 the attacker's control.
1587 Countermeasures
1588 o Though not a complete countermeasure by themselves, CSRF defense
1589 and the 'state' parameter created with secure random codes should
1590 be deployed on the client side. The client should forward the
1591 authorization code to the authorization server only after both the
1592 CSRF token and the 'state' parameter are validated.
1594 o If the client authenticates the user, either through a single-
1595 sign-on protocol or through local authentication, the client
1596 should suspend the access by a user account if the number of
1597 invalid authorization codes submitted by this user exceeds a
1598 certain threshold.
1600 o The authorization server should send an error response to the
1601 client reporting an invalid authorization code and rate limit or
1602 disallow connections from clients whose number of invalid requests
1603 exceeds a threshold.
1605 4.4.1.13. Threat: Code substitution (OAuth Login)
1607 An attacker could attempt to login to an application or web site
1608 using a victim's identity. Applications relying on identity data
1609 provided by an OAuth protected service API to login users are
1610 vulnerable to this threat. This pattern can be found in so-called
1611 "social login" scenarios.
1613 As a pre-requisite, a resource server offers an API to obtain
1614 personal information about a user which could be interpreted as
1615 having obtained a user identity. In this sense the client is
1616 treating the resource server API as an "identity" API. A client
1617 utilizes OAuth to obtain an access token for the identity API. It
1618 then queries the identity API for an identifier and uses it to look
1619 up its internal user account data (login). The client asssumes that
1620 because it was able to obtain information about the user, that the
1621 user has been authenticated.
1623 If the client uses the grant type "code", the attacker needs to
1624 gather a valid authorization code of the respective victim from the
1625 same identity provider used by the target client application. The
1626 attacker tricks the victim into login into a malicious app (which may
1627 appear to be legitimate to the Identity Provider) using the same
1628 identity provider as the target application. This results in the
1629 Identity Provider's authorization server issuing an authorization
1630 code for the respective identity API. The malicious app then sends
1631 this code to the attacker, which in turn triggers a login process
1632 within the target application. The attacker now manipulates the
1633 authorization response and substitutes their code (bound to their
1634 identity) for the victim's code. This code is then exchanged by the
1635 client for an access token, which in turn is accepted by the identity
1636 API since the audience, with respect to the resource server, is
1637 correct. But since the identifier returned by the identity API is
1638 determined by the identity in the access token (issued based on the
1639 victim's code), the attacker is logged into the target application
1640 under the victim's identity.
1642 Impact: the attacker gains access to an application and user-specific
1643 data within the application.
1645 Countermeasures:
1647 o All clients must indicate their client id with every request to
1648 exchange an authorization code for an access token. The
1649 authorization server must validate whether the particular
1650 authorization code has been issued to the particular client. If
1651 possible, the client shall be authenticated beforehand.
1653 o Clients should use appropriate protocol, such as OpenID (cf.
1654 [openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
1655 implement user login. Both support audience restrictions on
1656 clients.
1658 4.4.2. Implicit Grant
1660 In the implicit grant type flow, the access token is directly
1661 returned to the client as a fragment part of the redirection URI. It
1662 is assumed that the token is not sent to the redirection URI target
1663 as HTTP user agents do not send the fragment part of URIs to HTTP
1664 servers. Thus an attacker cannot eavesdrop the access token on this
1665 communication path and it cannot leak through HTTP referee headers.
1667 4.4.2.1. Threat: Access token leak in transport/end-points
1669 This token might be eavesdropped by an attacker. The token is sent
1670 from server to client via a URI fragment of the redirection URI. If
1671 the communication is not secured or the end-point is not secured, the
1672 token could be leaked by parsing the returned URI.
1674 Impact: the attacker would be able to assume the same rights granted
1675 by the token.
1677 Countermeasures:
1679 o The authorization server should ensure confidentiality (e.g. using
1680 TLS) of the response from the authorization server to the client
1681 (see Section 5.1.1).
1683 4.4.2.2. Threat: Access token leak in browser history
1685 An attacker could obtain the token from the browser's history. Note
1686 this means the attacker needs access to the particular device.
1688 Countermeasures:
1690 o Use short expiry time for tokens (see Section 5.1.5.3) and reduced
1691 scope of the token may reduce the impact of that attack (see
1692 Section 5.1.5.1).
1694 o Make responses non-cachable
1696 4.4.2.3. Threat: Malicious client obtains authorization
1698 A malicious client could attempt to obtain a token by fraud.
1700 The same countermeasures as for Section 4.4.1.4 are applicable,
1701 except client authentication.
1703 4.4.2.4. Threat: Manipulation of scripts
1705 A hostile party could act as the client web server and replace or
1706 modify the actual implementation of the client (script). This could
1707 be achieved using DNS or ARP spoofing. This applies to clients
1708 implemented within the Web Browser in a scripting language.
1710 Impact: The attacker could obtain user credential information and
1711 assume the full identity of the user.
1713 Countermeasures:
1715 o The authorization server should authenticate the server from which
1716 scripts are obtained (see Section 5.1.2).
1718 o The client should ensure that scripts obtained have not been
1719 altered in transport (see Section 5.1.1).
1721 o Introduce one time per-use secrets (e.g. client_secret) values
1722 that can only be used by scripts in a small time window once
1723 loaded from a server. The intention would be to reduce the
1724 effectiveness of copying client-side scripts for re-use in an
1725 attackers modified code.
1727 4.4.2.5. Threat: CSRF attack against redirect-uri
1729 CSRF attacks (see Section 4.4.1.8) also work against the redirection
1730 URI used in the implicit grant flow. An attacker could acquire an
1731 access token to their own protected resources. He could then
1732 construct a redirection URI and embed their access token in that URI.
1733 If he can trick the user into following the redirection URI and the
1734 client does not have protection against this attack, the user may
1735 have the attacker's access token authorized within their client.
1737 Impact: The user accesses resources on behalf of the attacker. The
1738 effective impact depends on the type of resource accessed. For
1739 example, the user may upload private items to an attacker's
1740 resources. Or when using OAuth in 3rd party login scenarios, the
1741 user may associate his client account with the attacker's identity at
1742 the external identity provider. This way the attacker could easily
1743 access the victim's data at the client by logging in from another
1744 device with his credentials at the external identity provider.
1746 Countermeasures:
1748 o The state parameter should be used to link the authorization
1749 request with the redirection URI used deliver the access token.
1750 This will ensure the client is not tricked into completing any
1751 redirect callback unless it is linked to an authorization request
1752 the client initiated. The state parameter should be unguessable
1753 and the client should be capable of keeping the state parameter
1754 secret.
1756 o Client developers and end-user can be educated not follow
1757 untrusted URLs.
1759 4.4.2.6. Threat: Token substitution (OAuth Login)
1761 An attacker could attempt to login to an application or web site
1762 using a victim's identity. Applications relying on identity data
1763 provided by an OAuth protected service API to login users are
1764 vulnerable to this threat. This pattern can be found in so-called
1765 "social login" scenarios.
1767 As a pre-requisite, a resource server offers an API to obtain
1768 personal information about a user which could be interpreted as
1769 having obtained a user identity. In this sense the client is
1770 treating the resource server API as an "identity" API. A client
1771 utilizes OAuth to obtain an access token for the identity API. It
1772 then queries the identity API for an identifier and uses it to look
1773 up its internal user account data (login). The client asssumes that
1774 because it was able to obtain information about the user, that the
1775 user has been authenticated.
1777 To succeed, the attacker needs to gather a valid access token of the
1778 respective victim from the same identity provider used by the target
1779 client application. The attacker tricks the victim into login into a
1780 malicious app (which may appear to be legitimate to the Identity
1781 Provider) using the same identity provider as the target application.
1782 This results in the Identity Provider's authorization server issuing
1783 an access token for the respective identity API. The malicious app
1784 then sends this access token to the attacker, which in turn triggers
1785 a login process within the target application. The attacker now
1786 manipulates the authorization response and substitutes their access
1787 token (bound to their identity) for the victim's access token. This
1788 token is accepted by the identity API since the audience, with
1789 respect to the resource server, is correct. But since the identifier
1790 returned by the identity API is determined by the identity in the
1791 access token, the attacker is logged into the target application
1792 under the victim's identity.
1794 Impact: the attacker gains access to an application and user-specific
1795 data within the application.
1797 Countermeasures:
1799 o Clients should use appropriate protocol, such as OpenID (cf.
1800 [openid]) or SAML (cf. [OASIS.sstc-saml-bindings-1.1]) to
1801 implement user login. Both support audience restrictions on
1802 clients.
1804 4.4.3. Resource Owner Password Credentials
1806 The "Resource Owner Password Credentials" grant type (see
1807 [I-D.ietf-oauth-v2], Section 4.3), often used for legacy/migration
1808 reasons, allows a client to request an access token using an end-
1809 users user-id and password along with its own credential. This grant
1810 type has higher risk because it maintains the uid/password anti-
1811 pattern. Additionally, because the user does not have control over
1812 the authorization process, clients using this grant type are not
1813 limited by scope, but instead have potentially the same capabilities
1814 as the user themselves. As there is no authorization step, the
1815 ability to offer token revocation is bypassed.
1817 Because passwords are often used for more than 1 service, this anti-
1818 pattern may also risk whatever else is accessible with the supplied
1819 credential. Additionally any easily derived equivalent (e.g.
1820 joe@example.com and joe@example.net) might easily allow someone to
1821 guess that the same password can be used elsewhere.
1823 Impact: The resource server can only differentiate scope based on the
1824 access token being associated with a particular client. The client
1825 could also acquire long-living tokens and pass them up to a attacker
1826 web service for further abuse. The client, eavesdroppers, or end-
1827 points could eavesdrop user id and password.
1829 Countermeasures:
1831 o Except for migration reasons, minimize use of this grant type
1833 o The authorization server should validate the client id associated
1834 with the particular refresh token with every refresh request -
1835 Section 5.2.2.2
1837 o As per the core Oauth spec, the authorization server must ensure
1838 that these transmissions are protected using transport-layer
1839 mechanisms such as TLS (see Section 5.1.1).
1841 o Rather than encouraging users to use a uid and password, service
1842 providers should instead encourage users not to use the same
1843 password for multiple services.
1845 o Limit use of Resource Owner Password Credential grants to
1846 scenarios where the client application and the authorizing service
1847 are from the same organization.
1849 4.4.3.1. Threat: Accidental exposure of passwords at client site
1851 If the client does not provide enough protection, an attacker or
1852 disgruntled employee could retrieve the passwords for a user.
1854 Countermeasures:
1856 o Use other flows, which do not rely on the client's cooperation for
1857 secure resource owner credential handling
1859 o Use digest authentication instead of plaintext credential
1860 processing
1862 o Obfuscate passwords in logs
1864 4.4.3.2. Threat: Client obtains scopes without end-user authorization
1866 All interaction with the resource owner is performed by the client.
1867 Thus it might, intentionally or unintentionally, happen that the
1868 client obtains a token with scope unknown for or unintended by the
1869 resource owner. For example, the resource owner might think the
1870 client needs and acquires read-only access to its media storage only
1871 but the client tries to acquire an access token with full access
1872 permissions.
1874 Countermeasures:
1876 o Use other flows, which do not rely on the client's cooperation for
1877 resource owner interaction
1879 o The authorization server may generally restrict the scope of
1880 access tokens (Section 5.1.5.1) issued by this flow. If the
1881 particular client is trustworthy and can be authenticated in a
1882 reliable way, the authorization server could relax that
1883 restriction. Resource owners may prescribe (e.g. in their
1884 preferences) what the maximum scope is for clients using this
1885 flow.
1887 o The authorization server could notify the resource owner by an
1888 appropriate media, e.g. e-Mail, of the grant issued (see
1889 Section 5.1.3).
1891 4.4.3.3. Threat: Client obtains refresh token through automatic
1892 authorization
1894 All interaction with the resource owner is performed by the client.
1895 Thus it might, intentionally or unintentionally, happen that the
1896 client obtains a long-term authorization represented by a refresh
1897 token even if the resource owner did not intend so.
1899 Countermeasures:
1901 o Use other flows, which do not rely on the client's cooperation for
1902 resource owner interaction
1904 o The authorization server may generally refuse to issue refresh
1905 tokens in this flow (see Section 5.2.2.1). If the particular
1906 client is trustworthy and can be authenticated in a reliable way
1907 (see client authentication), the authorization server could relax
1908 that restriction. Resource owners may allow or deny (e.g. in
1909 their preferences) to issue refresh tokens using this flow as
1910 well.
1912 o The authorization server could notify the resource owner by an
1913 appropriate media, e.g. e-Mail, of the refresh token issued (see
1914 Section 5.1.3).
1916 4.4.3.4. Threat: Obtain user passwords on transport
1918 An attacker could attempt to eavesdrop the transmission of end-user
1919 credentials with the grant type "password" between client and server.
1921 Impact: disclosure of a single end-users password.
1923 Countermeasures:
1925 o Ensure confidentiality of requests - Section 5.1.1
1927 o alternative authentication means, which do not require to send
1928 plaintext credentials over the wire (e.g. Hash-based Message
1929 Authentication Code)
1931 4.4.3.5. Threat: Obtain user passwords from authorization server
1932 database
1934 An attacker may obtain valid username/password combinations from the
1935 authorization server's database by gaining access to the database or
1936 launching a SQL injection attack.
1938 Impact: disclosure of all username/password combinations. The impact
1939 may exceed the domain of the authorization server since many users
1940 tend to use the same credentials on different services.
1942 Countermeasures:
1944 o Enforce credential storage protection best practices -
1945 Section 5.1.4.1
1947 4.4.3.6. Threat: Online guessing
1949 An attacker may try to guess valid username/password combinations
1950 using the grant type "password".
1952 Impact: Revelation of a single username/password combination.
1954 Countermeasures:
1956 o Utilize secure password policy - Section 5.1.4.2.1
1958 o Lock accounts - Section 5.1.4.2.3
1960 o Use tar pit - Section 5.1.4.2.4
1962 o Use CAPTCHAs - Section 5.1.4.2.5
1963 o Consider not to use grant type "password"
1965 o Client authentication (see Section 5.2.3) will provide another
1966 authentication factor and thus hinder the attack.
1968 4.4.4. Client Credentials
1970 Client credentials (see [I-D.ietf-oauth-v2], Section 3) consist of an
1971 identifier (not secret) combined with an additional means (such as a
1972 matching client secret) of authenticating a client. The threats to
1973 this grant type are similar to Section 4.4.3.
1975 4.5. Refreshing an Access Token
1977 4.5.1. Threat: Eavesdropping refresh tokens from authorization server
1979 An attacker may eavesdrop refresh tokens when they are transmitted
1980 from the authorization server to the client.
1982 Countermeasures:
1984 o As per the core OAuth spec, the Authorization servers must ensure
1985 that these transmissions are protected using transport-layer
1986 mechanisms such as TLS (see Section 5.1.1).
1988 o If end-to-end confidentiality cannot be guaranteed, reducing scope
1989 (see Section 5.1.5.1) and expiry time (see Section 5.1.5.3) for
1990 issued access tokens can be used to reduce the damage in case of
1991 leaks.
1993 4.5.2. Threat: Obtaining refresh token from authorization server
1994 database
1996 This threat is applicable if the authorization server stores refresh
1997 tokens as handles in a database. An attacker may obtain refresh
1998 tokens from the authorization server's database by gaining access to
1999 the database or launching a SQL injection attack.
2001 Impact: disclosure of all refresh tokens
2003 Countermeasures:
2005 o Enforce credential storage protection best practices -
2006 Section 5.1.4.1
2008 o Bind token to client id, if the attacker cannot obtain the
2009 required id and secret - Section 5.1.5.8
2011 4.5.3. Threat: Obtain refresh token by online guessing
2013 An attacker may try to guess valid refresh token values and send it
2014 using the grant type "refresh_token" in order to obtain a valid
2015 access token.
2017 Impact: exposure of single refresh token and derivable access tokens.
2019 Countermeasures:
2021 o For handle-based designs - Section 5.1.4.2.2
2023 o For assertion-based designs - Section 5.1.5.9
2025 o Bind token to client id, because the attacker would guess the
2026 matching client id, too (see Section 5.1.5.8)
2028 o Authenticate the client, adds another element the attacker has to
2029 guess (see Section 5.2.3.4)
2031 4.5.4. Threat: Obtain refresh token phishing by counterfeit
2032 authorization server
2034 An attacker could try to obtain valid refresh tokens by proxying
2035 requests to the authorization server. Given the assumption that the
2036 authorization server URL is well-known at development time or can at
2037 least be obtained from a well-known resource server, the attacker
2038 must utilize some kind of spoofing in order to succeed.
2040 Countermeasures:
2042 o Utilize server authentication (as described in Section 5.1.2)
2044 4.6. Accessing Protected Resources
2046 4.6.1. Threat: Eavesdropping access tokens on transport
2048 An attacker could try to obtain a valid access token on transport
2049 between client and resource server. As access tokens are shared
2050 secrets between authorization and resource server, they should be
2051 treated with the same care as other credentials (e.g. end-user
2052 passwords).
2054 Countermeasures:
2056 o Access tokens sent as bearer tokens, should not be sent in the
2057 clear over an insecure channel. As per the core OAuth spec,
2058 transmission of access tokens must be protected using transport-
2059 layer mechanisms such as TLS (see Section 5.1.1).
2061 o A short lifetime reduces impact in case tokens are compromised
2062 (see Section 5.1.5.3).
2064 o The access token can be bound to a client's identifier and require
2065 the client to prove legitimate ownership of the token to the
2066 resource server (see Section 5.4.2).
2068 4.6.2. Threat: Replay authorized resource server requests
2070 An attacker could attempt to replay valid requests in order to obtain
2071 or to modify/destroy user data.
2073 Countermeasures:
2075 o The resource server should utilize transport security measures
2076 (e.g. TLS) in order to prevent such attacks (see Section 5.1.1).
2077 This would prevent the attacker from capturing valid requests.
2079 o Alternatively, the resource server could employ signed requests
2080 (see Section 5.4.3) along with nonces and timestamps in order to
2081 uniquely identify requests. The resource server should detect and
2082 refuse every replayed request.
2084 4.6.3. Threat: Guessing access tokens
2086 Where the token is a handle, the attacker may use attempt to guess
2087 the access token values based on knowledge they have from other
2088 access tokens.
2090 Impact: Access to a single user's data.
2092 Countermeasures:
2094 o Handle Tokens should have a reasonable entropy (see
2095 Section 5.1.4.2.2) in order to make guessing a valid token value
2096 infeasible.
2098 o Assertion (or self-contained token ) tokens contents should be
2099 protected by a digital signature (see Section 5.1.5.9).
2101 o Security can be further strengthened by using a short access token
2102 duration (see Section 5.1.5.2 and Section 5.1.5.3).
2104 4.6.4. Threat: Access token phishing by counterfeit resource server
2106 An attacker may pretend to be a particular resource server and to
2107 accept tokens from a particular authorization server. If the client
2108 sends a valid access token to this counterfeit resource server, the
2109 server in turn may use that token to access other services on behalf
2110 of the resource owner.
2112 Countermeasures:
2114 o Clients should not make authenticated requests with an access
2115 token to unfamiliar resource servers, regardless of the presence
2116 of a secure channel. If the resource server URL is well-known to
2117 the client, it may authenticate the resource servers (see
2118 Section 5.1.2).
2120 o Associate the endpoint URL of the resource server the client
2121 talked to with the access token (e.g. in an audience field) and
2122 validate association at legitimate resource server. The endpoint
2123 URL validation policy may be strict (exact match) or more relaxed
2124 (e.g. same host). This would require to tell the authorization
2125 server the resource server endpoint URL in the authorization
2126 process.
2128 o Associate an access token with a client and authenticate the
2129 client with resource server requests (typically via signature in
2130 order to not disclose secret to a potential attacker). This
2131 prevents the attack because the counterfeit server is assumed to
2132 lack the capability to correctly authenticate on behalf of the
2133 legitimate client to the resource server (Section 5.4.2).
2135 o Restrict the token scope (see Section 5.1.5.1) and or limit the
2136 token to a certain resource server (Section 5.1.5.5).
2138 4.6.5. Threat: Abuse of token by legitimate resource server or client
2140 A legitimate resource server could attempt to use an access token to
2141 access another resource servers. Similarly, a client could try to
2142 use a token obtained for one server on another resource server.
2144 Countermeasures:
2146 o Tokens should be restricted to particular resource servers (see
2147 Section 5.1.5.5).
2149 4.6.6. Threat: Leak of confidential data in HTTP-Proxies
2151 The HTTP Authorization scheme (OAuth HTTP Authorization Scheme) is
2152 optional. However, [RFC2616] relies on the Authorization and WWW-
2153 Authenticate headers to distinguish authenticated content so that it
2154 can be protected. Proxies and caches, in particular, may fail to
2155 adequately protect requests not using these headers. For example,
2156 private authenticated content may be stored in (and thus retrievable
2157 from) publicly-accessible caches.
2159 Countermeasures:
2161 o Clients and resource servers not using the HTTP Authorization
2162 scheme (OAuth HTTP Authorization Scheme - see Section 5.4.1)
2163 should take care to use Cache-Control headers to minimize the risk
2164 that authenticated content is not protected. Such Clients should
2165 send a Cache-Control header containing the "no-store" option
2166 [RFC2616]. Resource server success (2XX status) responses to
2167 these requests should contain a Cache-Control header with the
2168 "private" option [RFC2616].
2170 o Reducing scope (see Section 5.1.5.1) and expiry time
2171 (Section 5.1.5.3) for access tokens can be used to reduce the
2172 damage in case of leaks.
2174 4.6.7. Threat: Token leakage via logfiles and HTTP referrers
2176 If access tokens are sent via URI query parameters, such tokens may
2177 leak to log files and the HTTP "referer".
2179 Countermeasures:
2181 o Use authorization headers or POST parameters instead of URI
2182 request parameters (see Section 5.4.1).
2184 o Set logging configuration appropriately
2186 o Prevent unauthorized persons from access to system log files (see
2187 Section 5.1.4.1.1)
2189 o Abuse of leaked access tokens can be prevented by enforcing
2190 authenticated requests (see Section 5.4.2).
2192 o The impact of token leakage may be reduced by limiting scope (see
2193 Section 5.1.5.1) and duration (see Section 5.1.5.3) and enforcing
2194 one time token usage (see Section 5.1.5.4).
2196 5. Security Considerations
2198 This section describes the countermeasures as recommended to mitigate
2199 the threats as described in Section 4.
2201 5.1. General
2203 The general section covers considerations that apply generally across
2204 all OAuth components (client, resource server, token server, and
2205 user-agents).
2207 5.1.1. Ensure confidentiality of requests
2209 This is applicable to all requests sent from client to authorization
2210 server or resource server. While OAuth provides a mechanism for
2211 verifying the integrity of requests, it provides no guarantee of
2212 request confidentiality. Unless further precautions are taken,
2213 eavesdroppers will have full access to request content and may be
2214 able to mount interception or replay attacks through using content of
2215 request, e.g. secrets or tokens.
2217 Attacks can be mitigated by using transport-layer mechanisms such as
2218 TLS [RFC5246]. A virtual private network (VPN), e.g. based on IPsec
2219 VPN [RFC4301], may considered as well.
2221 Note: this document assumes end-to-end TLS protected connections
2222 between the respective protocol entities. Deployments deviating from
2223 this assumption by offloading TLS in between (e.g. on the data center
2224 edge) must refine this threat model in order to account for the
2225 additional (mainly insider) threat this may cause.
2227 This is a countermeasure against the following threats:
2229 o Replay of access tokens obtained on tokens endpoint or resource
2230 server's endpoint
2232 o Replay of refresh tokens obtained on tokens endpoint
2234 o Replay of authorization codes obtained on tokens endpoint
2235 (redirect?)
2237 o Replay of user passwords and client secrets
2239 5.1.2. Utiliize server authentication
2241 HTTPS server authentication or similar means can be used to
2242 authenticate the identity of a server. The goal is to reliably bind
2243 the fully qualified domain name of the server to the public key
2244 presented by the server during connection establishment (see
2245 [RFC2818]).
2247 The client should validate the binding of the server to its domain
2248 name. If the server fails to prove that binding, it is considered a
2249 man-in-the-middle attack. The security measure depends on the
2250 certification authorities the client trusts for that purpose.
2251 Clients should carefully select those trusted CAs and protect the
2252 storage for trusted CA certificates from modifications.
2254 This is a countermeasure against the following threats:
2256 o Spoofing
2258 o Proxying
2260 o Phishing by counterfeit servers
2262 5.1.3. Always keep the resource owner informed
2264 Transparency to the resource owner is a key element of the OAuth
2265 protocol. The user should always be in control of the authorization
2266 processes and get the necessary information to meet informed
2267 decisions. Moreover, user involvement is a further security
2268 countermeasure. The user can probably recognize certain kinds of
2269 attacks better than the authorization server. Information can be
2270 presented/exchanged during the authorization process, after the
2271 authorization process, and every time the user wishes to get informed
2272 by using techniques such as:
2274 o User consent forms
2276 o Notification messages (e.g. e-Mail, SMS, ...). Note that
2277 notifications can be a phishing vector. Messages should be such
2278 that look-alike phishing messages cannot be derived from them.
2280 o Activity/Event logs
2282 o User self-care applications or portals
2284 5.1.4. Credentials
2286 This sections describes countermeasures used to protect all kinds of
2287 credentials from unauthorized access and abuse. Credentials are long
2288 term secrets, such as client secrets and user passwords as well as
2289 all kinds of tokens (refresh and access token) or authorization
2290 codes.
2292 5.1.4.1. Enforce credential storage protection best practices
2294 Administrators should undertake industry best practices to protect
2295 the storage of credentials (see for example [owasp]). Such practices
2296 may include but are not limited to the following sub-sections.
2298 5.1.4.1.1. Enforce Standard System Security Means
2300 A server system may be locked down so that no attacker may get access
2301 to sensible configuration files and databases.
2303 5.1.4.1.2. Enforce standard SQL Injection Countermeasures
2305 If a client identifier or other authentication component is queried
2306 or compared against a SQL Database it may become possible for an
2307 injection attack to occur if parameters received are not validated
2308 before submission to the database.
2310 o Ensure that server code is using the minimum database privileges
2311 possible to reduce the "surface" of possible attacks.
2313 o Avoid dynamic SQL using concatenated input. If possible, use
2314 static SQL.
2316 o When using dynamic SQL, parameterize queries using bind arguments.
2317 Bind arguments eliminate possibility of SQL injections.
2319 o Filter and sanitize the input. For example, if an identifier has
2320 a known format, ensure that the supplied value matches the
2321 identifier syntax rules.
2323 5.1.4.1.3. No cleartext storage of credentials
2325 The authorization server should not store credentials in clear text.
2326 Typical approaches are to store hashes instead or to encrypt
2327 credentials. If the credential lacks a reasonable entropy level
2328 (because it is a user password) an additional salt will harden the
2329 storage to make offline dictionary attacks more difficult.
2331 Note: Some authentication protocols require the authorization server
2332 to have access to the secret in the clear. Those protocols cannot be
2333 implemented if the server only has access to hashes. Credentials
2334 should strongly encrypted in those cases.
2336 5.1.4.1.4. Encryption of credentials
2338 For client applications, insecurely persisted client credentials are
2339 easy targets for attackers to obtain. Store client credentials using
2340 an encrypted persistence mechanism such as a keystore or database.
2341 Note that compiling client credentials directly into client code
2342 makes client applications vulnerable to scanning as well as difficult
2343 to administer should client credentials change over time.
2345 5.1.4.1.5. Use of asymmetric cryptography
2347 Usage of asymmetric cryptography will free the authorization server
2348 of the obligation to manage credentials.
2350 5.1.4.2. Online attacks on secrets
2352 5.1.4.2.1. Utilize secure password policy
2354 The authorization server may decide to enforce a complex user
2355 password policy in order to increase the user passwords' entropy to
2356 hinder online password attacks. Note that too much complexity can
2357 increase the liklihood that users re-use passwords or write them down
2358 or otherwise store them insecurely.
2360 5.1.4.2.2. Use high entropy for secrets
2362 When creating secrets not intended for usage by human users (e.g.
2363 client secrets or token handles), the authorization server should
2364 include a reasonable level of entropy in order to mitigate the risk
2365 of guessing attacks. The token value should be >=128 bits long and
2366 constructed from a cryptographically strong random or pseudo-random
2367 number sequence (see [RFC4086] for best current practice) generated
2368 by the Authorization Server.
2370 5.1.4.2.3. Lock accounts
2372 Online attacks on passwords can be mitigated by locking the
2373 respective accounts after a certain number of failed attempts.
2375 Note: This measure can be abused to lock down legitimate service
2376 users.
2378 5.1.4.2.4. Use tar pit
2380 The authorization server may react on failed attempts to authenticate
2381 by username/password by temporarily locking the respective account
2382 and delaying the response for a certain duration. This duration may
2383 increase with the number of failed attempts. The objective is to
2384 slow the attackers attempts on a certain username down.
2386 Note: this may require a more complex and stateful design of the
2387 authorization server.
2389 5.1.4.2.5. Usa CAPTCHAs
2391 The idea is to prevent programs from automatically checking huge
2392 number of passwords by requiring human interaction.
2394 Note: this has a negative impact on user experience.
2396 5.1.5. Tokens (access, refresh, code)
2398 5.1.5.1. Limit token scope
2400 The authorization server may decide to reduce or limit the scope
2401 associated with a token. The basis of this decision is out of scope,
2402 examples are:
2404 o a client-specific policy, e.g. issue only less powerful tokens to
2405 public clients,
2407 o a service-specific policy, e.g. it a very sensitive service,
2409 o a resource-owner specific setting, or
2411 o combinations of such policies and preferences.
2413 The authorization server may allow different scopes dependent on the
2414 grant type. For example, end-user authorization via direct
2415 interaction with the end-user (authorization code) might be
2416 considered more reliable than direct authorization via grant type
2417 username/password. This means will reduce the impact of the
2418 following threats:
2420 o token leakage
2422 o token issuance to malicious software
2424 o unintended issuance of to powerful tokens with resource owner
2425 credentials flow
2427 5.1.5.2. Expiration time
2429 Tokens should generally expire after a reasonable duration. This
2430 complements and strengthens other security measures (such as
2431 signatures) and reduces the impact of all kinds of token leaks.
2432 Depending on the risk associated with a token leakage, tokens may
2433 expire after a few minutes (e.g. for payment transactions) or stay
2434 valid for hours (e.g. read access to contacts).
2436 The expiration time is determined by a couple of factors, including:
2438 o risk associated to a token leakage
2440 o duration of the underlying access grant,
2442 o duration until the modification of an access grant should take
2443 effect, and
2445 o time required for an attacker to guess or produce valid token.
2447 5.1.5.3. Use short expiration time
2449 A short expiration time for tokens is a protection means against the
2450 following threats:
2452 o replay
2454 o reduce impact of token leak
2456 o reduce likelihood of successful online guessing
2458 Note: Short token duration requires more precise clock
2459 synchronisation between authorization server and resource server.
2460 Furthermore, shorter duration may require more token refreshes
2461 (access token) or repeated end-user authorization processes
2462 (authorization code and refresh token).
2464 5.1.5.4. Limit number of usages/ One time usage
2466 The authorization server may restrict the number of requests or
2467 operations which can be performed with a certain token. This
2468 mechanism can be used to mitigate the following threats:
2470 o replay of tokens
2472 o guessing
2474 For example, if an Authorization Server observes more than one
2475 attempt to redeem an authorization code, the Authorization Server may
2476 want to revoke all access tokens granted based on the authorization
2477 code as well as reject the current request.
2479 As with the authorization code, access tokens may also have a limited
2480 number of operations. This forces client applications to either re-
2481 authenticate and use a refresh token to obtain a fresh access token,
2482 or it forces the client to re-authorize the access token by involving
2483 the user.
2485 5.1.5.5. Bind tokens to a particular resource server (Audience)
2487 Authorization servers in multi-service environments may consider
2488 issuing tokens with different content to different resource servers
2489 and to explicitly indicate in the token the target server a token is
2490 intended to be sent to. SAML Assertions (see
2491 [OASIS.saml-core-2.0-os]) use the Audience element for this purpose.
2492 This countermeasure can be used in the following situations:
2494 o It reduces the impact of a successful replay attempt, since the
2495 token is applicable to a single resource server, only.
2497 o It prevents abuse of a token by a rogue resource server or client,
2498 since the token can only be used on that server. It is rejected
2499 by other servers.
2501 o It reduces the impact of a leakage of a valid token to a
2502 counterfeit resource server.
2504 5.1.5.6. Use endpoint address as token audience
2506 This may be used to indicate to a resource server, which endpoint URL
2507 has been used to obtain the token. This measure will allow to detect
2508 requests from a counterfeit resource server, since such token will
2509 contain the endpoint URL of that server.
2511 5.1.5.7. Audience and Token scopes
2513 Deployments may consider only using tokens with explicitly defined
2514 scope, where every scope is associated with a particular resource
2515 server. This approach can be used to mitigate attacks, where a
2516 resource server or client uses a token for a different then the
2517 intended purpose.
2519 5.1.5.8. Bind token to client id
2521 An authorization server may bind a token to a certain client
2522 identifier. This identifier should be validated for every request
2523 with that token. This means can be used, to
2525 o detect token leakage and
2527 o prevent token abuse.
2529 Note: Validating the client identifier may require the target server
2530 to authenticate the client's identifier. This authentication can be
2531 based on secrets managed independent of the token (e.g. pre-
2532 registered client id/secret on authorization server) or sent with the
2533 token itself (e.g. as part of the encrypted token content).
2535 5.1.5.9. Signed tokens
2537 Self-contained tokens should be signed in order to detect any attempt
2538 to modify or produce faked tokens (e.g. Hash-based Message
2539 Authentication Code or digital signatures)
2541 5.1.5.10. Encryption of token content
2543 Self-contained tokens may be encrypted for confidentiality reasons or
2544 to protect system internal data. Depending on token format, keys
2545 (e.g. symmetric keys) may have to be distributed between server
2546 nodes. The method of distribution should be defined by the token and
2547 encryption used.
2549 5.1.5.11. Assertion formats
2551 For service providers intending to implement an assertion-based token
2552 design it is highly recommended to adopt a standard assertion format
2553 (such as SAML [OASIS.saml-core-2.0-os] or JWT
2554 [I-D.ietf-oauth-json-web-token].
2556 5.1.6. Access tokens
2558 The following measures should be used to protect access tokens
2560 o keep them in transient memory (accessible by the client
2561 application only)
2563 o Pass tokens securely using secure transport (TLS)
2565 o Ensure client applications do not share tokens with 3rd parties
2567 5.2. Authorization Server
2569 This section describes considerations related to the OAuth
2570 Authorization Server end-point.
2572 5.2.1. Authorization Codes
2574 5.2.1.1. Automatic revocation of derived tokens if abuse is detected
2576 If an Authorization Server observes multiple attempts to redeem an
2577 authorization grant (e.g. such as an authorization code), the
2578 Authorization Server may want to revoke all tokens granted based on
2579 the authorization grant.
2581 5.2.2. Refresh tokens
2583 5.2.2.1. Restricted issuance of refresh tokens
2585 The authorization server may decide based on an appropriate policy
2586 not to issue refresh tokens. Since refresh tokens are long term
2587 credentials, they may be subject theft. For example, if the
2588 authorization server does not trust a client to securely store such
2589 tokens, it may refuse to issue such a client a refresh token.
2591 5.2.2.2. Binding of refresh token to client_id
2593 The authorization server should match every refresh token to the
2594 identifier of the client to whom it was issued. The authorization
2595 server should check that the same client_id is present for every
2596 request to refresh the access token. If possible (e.g. confidential
2597 clients), the authorization server should authenticate the respective
2598 client.
2600 This is a countermeasure against refresh token theft or leakage.
2602 Note: This binding should be protected from unauthorized
2603 modifications.
2605 5.2.2.3. Refresh Token Rotation
2607 Refresh token rotation is intended to automatically detect and
2608 prevent attempts to use the same refresh token in parallel from
2609 different apps/devices. This happens if a token gets stolen from the
2610 client and is subsequently used by the attacker and the legitimate
2611 client. The basic idea is to change the refresh token value with
2612 every refresh request in order to detect attempts to obtain access
2613 tokens using old refresh tokens. Since the authorization server
2614 cannot determine whether the attacker or the legitimate client is
2615 trying to access, in case of such an access attempt the valid refresh
2616 token and the access authorization associated with it are both
2617 revoked.
2619 The OAuth specification supports this measure in that the tokens
2620 response allows the authorization server to return a new refresh
2621 token even for requests with grant type "refresh_token".
2623 Note: this measure may cause problems in clustered environments since
2624 usage of the currently valid refresh token must be ensured. In such
2625 an environment, other measures might be more appropriate.
2627 5.2.2.4. Revoke refresh tokens
2629 The authorization server may allow clients or end-users to explicitly
2630 request the invalidation of refresh tokens. A mechanism to revoke
2631 tokens is specified in [I-D.ietf-oauth-revocation].
2633 This is a countermeasure against:
2635 o device theft,
2637 o impersonation of resource owner, or
2639 o suspected compromised client applications.
2641 5.2.2.5. Device identification
2643 The authorization server may require to bind authentication
2644 credentials to a device identifier. The _International Mobile
2645 Station Equipment Identity_ [IMEI] is one example of such an
2646 identifier, there are also operating system specific identifiers.
2647 The authorization server could include such an identifier when
2648 authenticating user credentials in order to detect token theft from a
2649 particular device.
2651 Note: Any implementation should consider potential privacy
2652 implications of using device identifiers.
2654 5.2.2.6. X-FRAME-OPTION header
2656 For newer browsers, avoidance of iFrames can be enforced server side
2657 by using the X-FRAME-OPTION header (see
2658 [I-D.gondrom-x-frame-options]). This header can have two values,
2659 "DENY" and "SAMEORIGIN", which will block any framing or framing by
2660 sites with a different origin, respectively. The value "ALLOW-FROM"
2661 allows iFrames for a list of trusted origins.
2663 This is a countermeasure against the following threats:
2665 o Clickjacking attacks
2667 5.2.3. Client authentication and authorization
2669 As described in Section 3 (Security Features), clients are
2670 identified, authenticated and authorized for several purposes, such
2671 as a
2672 o Collate requests to the same client,
2674 o Indicate to the user the client is recognized by the authorization
2675 server,
2677 o Authorize access of clients to certain features on the
2678 authorization or resource server, and
2680 o Log a client identifier to log files for analysis or statistics.
2682 Due to the different capabilities and characteristics of the
2683 different client types, there are different ways to support these
2684 objectives, which will be described in this section. Authorization
2685 server providers should be aware of the security policy and
2686 deployment of a particular clients and adapt its treatment
2687 accordingly. For example, one approach could be to treat all clients
2688 as less trustworthy and unsecure. On the other extreme, a service
2689 provider could activate every client installation individually by an
2690 administrator and that way gain confidence in the identity of the
2691 software package and the security of the environment the client is
2692 installed in. And there are several approaches in between.
2694 5.2.3.1. Don't issue secrets to client with inappropriate security
2695 policy
2697 Authorization servers should not issue secrets to clients that cannot
2698 protect secrets ("public" clients). This reduces probability of the
2699 server treating the client as strongly authenticated.
2701 For example, it is of limited benefit to create a single client id
2702 and secret which is shared by all installations of a native
2703 application. Such a scenario requires that this secret must be
2704 transmitted from the developer via the respective distribution
2705 channel, e.g. an application market, to all installations of the
2706 application on end-user devices. A secret, burned into the source
2707 code of the application or a associated resource bundle, is not
2708 protected from reverse engineering. Secondly, such secrets cannot be
2709 revoked since this would immediately put all installations out of
2710 work. Moreover, since the authorization server cannot really trust
2711 the client's identifier, it would be dangerous to indicate to end-
2712 users the trustworthiness of the client.
2714 There are other ways to achieve a reasonable security level, as
2715 described in the following sections.
2717 5.2.3.2. Require user consent for public clients without secret
2719 Authorization servers should not allow automatic authorization for
2720 public clients. The authorization may issue an individual client id,
2721 but should require that all authorizations are approved by the end-
2722 user. This is a countermeasure for clients without secret against
2723 the following threats:
2725 o Impersonation of public client applications
2727 5.2.3.3. Client_id only in combination with redirect_uri
2729 The authorization may issue a client_id and bind the client_id to a
2730 certain pre-configured redirect_uri. Any authorization request with
2731 another redirection URI is refused automatically. Alternatively, the
2732 authorization server should not accept any dynamic redirection URI
2733 for such a client_id and instead always redirect to the well-known
2734 pre-configured redirection URI. This is a countermeasure for clients
2735 without secrets against the following threats:
2737 o Cross-site scripting attacks
2739 o Impersonation of public client applications
2741 5.2.3.4. Installation-specific client secrets
2743 An authorization server may issue separate client identifiers and
2744 corresponding secrets to the different installations of a particular
2745 client (i.e. software package). The effect of such an approach would
2746 be to turn otherwise "public" clients back into "confidential"
2747 clients.
2749 For web applications, this could mean to create one client_id and
2750 client_secret per web site a software package is installed on. So
2751 the provider of that particular site could request client id and
2752 secret from the authorization server during setup of the web site.
2753 This would also allow to validate some of the properties of that web
2754 site, such as redirection URI, website URL, and whatever proofs
2755 useful. The web site provider has to ensure the security of the
2756 client secret on the site.
2758 For native applications, things are more complicated because every
2759 copy of a particular application on any device is a different
2760 installation. Installation-specific secrets in this scenario will
2761 require
2762 1. Either to obtain a client_id and client_secret during download
2763 process from the application market, or
2765 2. During installation on the device.
2767 Either approach will require an automated mechanism for issuing
2768 client ids and secrets, which is currently not defined by OAuth.
2770 The first approach would allow to achieve a certain level of trust in
2771 the authenticity of the application, whereas the second option only
2772 allows to authenticate the installation but not to validate
2773 properties of the client. But this would at least help to prevent
2774 several replay attacks. Moreover, installation-specific client_id
2775 and secret allow to selectively revoke all refresh tokens of a
2776 specific installation at once.
2778 5.2.3.5. Validation of pre-registered redirect_uri
2780 An authorization server should require all clients to register their
2781 redirect_uri and the redirect_uri should be the full URI as defined
2782 in [I-D.ietf-oauth-v2]. The way this registration is performed is
2783 out of scope of this document. As per the core spec, every actual
2784 redirection URI sent with the respective client_id to the end-user
2785 authorization endpoint must match the registered redirection URI.
2786 Where it does not match, the authorization server should assume the
2787 inbound GET request has been sent by an attacker and refuse it.
2788 Note: the authorization server should not redirect the user agent
2789 back to the redirection URI of such an authorization request.
2790 Validating the pre-registered redirect_uri is a countermeasure
2791 against the following threats:
2793 o Authorization code leakage through counterfeit web site: allows to
2794 detect attack attempts already after first redirect to end-user
2795 authorization endpoint (Section 4.4.1.7).
2797 o Open Redirector attack via client redirection endpoint. (
2798 Section 4.1.5. )
2800 o Open Redirector phishing attack via authorization server
2801 redirection endpoint ( Section 4.2.4 )
2803 The underlying assumption of this measure is that an attacker will
2804 need to use another redirection URI in order to get access to the
2805 authorization code. Deployments might consider the possibility of an
2806 attacker using spoofing attacks to a victims device to circumvent
2807 this security measure.
2809 Note: Pre-registering clients might not scale in some deployments
2810 (manual process) or require dynamic client registration (not
2811 specified yet). With the lack of dynamic client registration, pre-
2812 registered "redirect_uri" only works for clients bound to certain
2813 deployments at development/configuration time. As soon as dynamic
2814 resource server discovery is required, the pre-registered
2815 redirect_uri may be no longer feasible.
2817 5.2.3.6. Revoke client secrets
2819 An authorization server may revoke a client's secret in order to
2820 prevent abuse of a revealed secret.
2822 Note: This measure will immediately invalidate any authorization code
2823 or refresh token issued to the respective client. This might be
2824 unintentionally impact client identifiers and secrets used across
2825 multiple deployments of a particular native or web application.
2827 This a countermeasure against:
2829 o Abuse of revealed client secrets for private clients
2831 5.2.3.7. Use strong client authentication (e.g. client_assertion /
2832 client_token)
2834 By using an alternative form of authentication such as client
2835 assertion [I-D.ietf-oauth-assertions], the need to distribute a
2836 client_secret is eliminated. This may require the use of a secure
2837 private key store or other supplemental authentication system as
2838 specified by the client assertion issuer in its authentication
2839 process.
2841 5.2.4. End-user authorization
2843 This secion involves considerations for authorization flows involving
2844 the end-user.
2846 5.2.4.1. Automatic processing of repeated authorizations requires
2847 client validation
2849 Authorization servers should NOT automatically process repeat
2850 authorizations where the client is not authenticated through a client
2851 secret or some other authentication mechanism such as a signed
2852 authentication assertion certificate (Section 5.2.3.7 Use strong
2853 client authentication (e.g. client_assertion / client_token)) or
2854 validation of a pre-registered redirect URI (Section 5.2.3.5
2855 Validation of pre-registered redirection URI ).
2857 5.2.4.2. Informed decisions based on transparency
2859 The authorization server should clearly explain to the end-user what
2860 happens in the authorization process and what the consequences are.
2861 For example, the user should understand what access he is about to
2862 grant to which client for what duration. It should also be obvious
2863 to the user, whether the server is able to reliably certify certain
2864 client properties (web site URL, security policy).
2866 5.2.4.3. Validation of client properties by end-user
2868 In the authorization process, the user is typically asked to approve
2869 a client's request for authorization. This is an important security
2870 mechanism by itself because the end-user can be involved in the
2871 validation of client properties, such as whether the client name
2872 known to the authorization server fits the name of the web site or
2873 the application the end-user is using. This measure is especially
2874 helpful in situations where the authorization server is unable to
2875 authenticate the client. It is a countermeasure against:
2877 o Malicious application
2879 o A client application masquerading as another client
2881 5.2.4.4. Binding of authorization code to client_id
2883 The authorization server should bind every authorization code to the
2884 id of the respective client which initiated the end-user
2885 authorization process. This measure is a countermeasure against:
2887 o replay of authorization codes with different client credentials
2888 since an attacker cannot use another client_id to exchange an
2889 authorization code into a token
2891 o Online guessing of authorization codes
2893 Note: This binding should be protected from unauthorized
2894 modifications (e.g. using protected memory and/or a secure database).
2896 5.2.4.5. Binding of authorization code to redirect_uri
2898 The authorization server should be able to bind every authorization
2899 code to the actual redirection URI used as redirect target of the
2900 client in the end-user authorization process. This binding should be
2901 validated when the client attempts to exchange the respective
2902 authorization code for an access token. This measure is a
2903 countermeasure against authorization code leakage through counterfeit
2904 web sites since an attacker cannot use another redirection URI to
2905 exchange an authorization code into a token.
2907 5.3. Client App Security
2909 This section deals with considerations for client applications.
2911 5.3.1. Don't store credentials in code or resources bundled with
2912 software packages
2914 Because of the numbers of copies of client software, there is limited
2915 benefit to create a single client id and secret which is shared by
2916 all installations of an application. Such an application by itself
2917 would be considered a "public" client as it cannot be presumed to be
2918 able to keep client secrets. A secret, burned into the source code
2919 of the application or an associated resource bundle, cannot be
2920 protected from reverse engineering. Secondly, such secrets cannot be
2921 revoked since this would immediately put all installations out of
2922 work. Moreover, since the authorization server cannot really trust
2923 the client's identifier, it would be dangerous to indicate to end-
2924 users the trustworthiness of the client.
2926 5.3.2. Standard web server protection measures (for config files and
2927 databases)
2929 Use standard web server protection measures - Section 5.3.2
2931 5.3.3. Store secrets in a secure storage
2933 The are different way to store secrets of all kinds (tokens, client
2934 secrets) securely on a device or server.
2936 Most multi-user operating systems segregate the personal storage of
2937 the different system users. Moreover, most modern smartphone
2938 operating systems even support to store app-specific data in separate
2939 areas of the file systems and protect it from access by other
2940 applications. Additionally, applications can implements confidential
2941 data itself using a user-supplied secret, such as PIN or password.
2943 Another option is to swap refresh token storage to a trusted backend
2944 server. This mean in turn requires a resilient authentication
2945 mechanisms between client and backend server. Note: Applications
2946 should ensure that confidential data is kept confidential even after
2947 reading from secure storage, which typically means to keep this data
2948 in the local memory of the application.
2950 5.3.4. Utilize device lock to prevent unauthorized device access
2952 On a typical modern phone, there are many "device lock" options which
2953 can be utilized to provide additional protection where a device is
2954 stolen or misplaced. These include PINs, passwords and other
2955 biomtric featres such as "face recognition". These are not equal in
2956 the level of security they provide.
2958 5.3.5. Link state parameter to user agent session
2960 The state parameter is used to link client requests and prevent CSRF
2961 attacks, for example against the redirection URI. An attacker could
2962 inject their own authorization code or access token, which can result
2963 in the client using an access token associated with the attacker's
2964 protected resources rather than the victim's (e.g. save the victim's
2965 bank account information to a protected resource controlled by the
2966 attacker).
2968 The client should utilize the "state" request parameter to send the
2969 authorization server a value that binds the request to the user-
2970 agent's authenticated state (e.g. a hash of the session cookie used
2971 to authenticate the user-agent) when making an authorization request.
2972 Once authorization has been obtained from the end-user, the
2973 authorization server redirects the end-user's user-agent back to the
2974 client with the required binding value contained in the "state"
2975 parameter.
2977 The binding value enables the client to verify the validity of the
2978 request by matching the binding value to the user- agent's
2979 authenticated state.
2981 5.4. Resource Servers
2983 The following section details security considerations for resource
2984 servers.
2986 5.4.1. Authorization headers
2988 Authorization headers are recognized and specially treated by HTTP
2989 proxies and servers. Thus the usage of such headers for sending
2990 access tokens to resource servers reduces the likelihood of leakage
2991 or unintended storage of authenticated requests in general and
2992 especially Authorization headers.
2994 5.4.2. Authenticated requests
2996 An authorization server may bind tokens to a certain client
2997 identifier and enable resource servers to be able to validate that
2998 association on resource access. This will require the resource
2999 server to authenticate the originator of a request as the legitimate
3000 owner of a particular token. There are a couple of options to
3001 implement this countermeasure:
3003 o The authorization server may associate the client identifier with
3004 the token (either internally or in the payload of an self-
3005 contained token). The client then uses client certificate-based
3006 HTTP authentication on the resource server's endpoint to
3007 authenticate its identity and the resource server validates the
3008 name with the name referenced by the token.
3010 o same as before, but the client uses his private key to sign the
3011 request to the resource server (public key is either contained in
3012 the token or sent along with the request)
3014 o Alternatively, the authorization server may issue a token-bound
3015 secret, which the client uses to MAC (message authentication code)
3016 the request (see [I-D.ietf-oauth-v2-http-mac]). The resource
3017 server obtains the secret either directly from the authorization
3018 server or it is contained in an encrypted section of the token.
3019 That way the resource server does not "know" the client but is
3020 able to validate whether the authorization server issued the token
3021 to that client
3023 Authenticated requests are a countermeasure against abuse of tokens
3024 by counterfeit resource servers.
3026 5.4.3. Signed requests
3028 A resource server may decide to accept signed requests only, either
3029 to replace transport level security measures or to complement such
3030 measures. Every signed request should be uniquely identifiable and
3031 should not be processed twice by the resource server. This
3032 countermeasure helps to mitigate:
3034 o modifications of the message and
3036 o replay attempts
3038 5.5. A Word on User Interaction and User-Installed Apps
3040 OAuth, as a security protocol, is distinctive in that its flow
3041 usually involves significant user interaction, making the end user a
3042 part of the security model. This creates some important difficulties
3043 in defending against some of the threats discussed above. Some of
3044 these points have already been made, but it's worth repeating and
3045 highlighting them here.
3047 o End users must understand what they are being asked to approve
3048 (see Section Section 5.2.4.1). Users often do not have the
3049 expertise to understand the ramifications of saying "yes" to an
3050 authorization request. and are likely not to be able to see subtle
3051 differences in wording of requests. Malicious software can
3052 confuse the user, tricking the user into approving almost
3053 anything.
3055 o End-user devices are prone to software compromise. This has been
3056 a long-standing problem, with frequent attacks on web browsers and
3057 other parts of the user's system. But with increasing popularity
3058 of user-installed "apps", the threat posed by compromised or
3059 malicious end-user software is very strong, and is one that is
3060 very difficult to mitigate.
3062 o Be aware that users will demand to install and run such apps, and
3063 that compromised or malicious ones can steal credentials at many
3064 points in the data flow. They can intercept the very user login
3065 credentials that OAuth is designed to protect. They can request
3066 authorization far beyond what they have led the user to understand
3067 and approve. They can automate a response on behalf of the user,
3068 hiding the whole process. No solution is offered here, because
3069 none is known; this remains in the space between better security
3070 and better usability.
3072 o Addressing these issues by restricting the use of user-installed
3073 software may be practical in some limited environments, and can be
3074 used as a countermeasure in those cases. Such restrictions are
3075 not practical in the general case, and mechanisms for after-the-
3076 fact recovery should be in place.
3078 o While end users are mostly incapable of properly vetting
3079 applications they load onto their devices, those who deploy
3080 Authorization Servers might have tools at their disposal to
3081 mitigate malicious Clients. For example, a well run Authorization
3082 Server must only assert client properties to the end-user it is
3083 effectively capable of validating, explicitely point out which
3084 properties it cannot validate, and indicate to the end-user the
3085 risk associated with granting access to the particular client.
3087 6. IANA Considerations
3089 This document makes no request of IANA.
3091 Note to RFC Editor: this section may be removed on publication as an
3092 RFC.
3094 7. Acknowledgements
3096 We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
3097 Francisco Corella, Peifung E Lam, Shane B Weeden, Skylar Woodward,
3098 Niv Steingarten, Tim Bray, and James H. Manger for their comments and
3099 contributions.
3101 8. References
3103 8.1. Informative References
3105 [I-D.ietf-oauth-v2]
3106 Hardt, D., "The OAuth 2.0 Authorization Framework",
3107 draft-ietf-oauth-v2-31 (work in progress), August 2012.
3109 [I-D.ietf-oauth-v2-bearer]
3110 Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
3111 Framework: Bearer Token Usage",
3112 draft-ietf-oauth-v2-bearer-23 (work in progress),
3113 August 2012.
3115 8.2. Informative References
3117 [I-D.gondrom-x-frame-options]
3118 Ross, D. and T. Gondrom, "HTTP Header X-Frame-Options",
3119 draft-gondrom-x-frame-options-00 (work in progress),
3120 March 2012.
3122 [I-D.ietf-oauth-assertions]
3123 Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
3124 "Assertion Framework for OAuth 2.0",
3125 draft-ietf-oauth-assertions-06 (work in progress),
3126 September 2012.
3128 [I-D.ietf-oauth-json-web-token]
3129 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
3130 (JWT)", draft-ietf-oauth-json-web-token-03 (work in
3131 progress), July 2012.
3133 [I-D.ietf-oauth-revocation]
3134 Lodderstedt, T., Dronia, S., and M. Scurtescu, "Token
3135 Revocation", draft-ietf-oauth-revocation-01 (work in
3136 progress), October 2012.
3138 [I-D.ietf-oauth-v2-http-mac]
3139 Hammer-Lahav, E., "HTTP Authentication: MAC Access
3140 Authentication", draft-ietf-oauth-v2-http-mac-01 (work in
3141 progress), February 2012.
3143 [IMEI] 3GPP, "International Mobile station Equipment Identities
3144 (IMEI)", 3GPP TS 22.016 3.3.0, July 2002.
3146 [OASIS.saml-core-2.0-os]
3147 Cantor, S., Kemp, J., Philpott, R., and E. Maler,
3148 "Assertions and Protocol for the OASIS Security Assertion
3149 Markup Language (SAML) V2.0", OASIS Standard saml-core-
3150 2.0-os, March 2005.
3152 [OASIS.sstc-gross-sec-analysis-response-01]
3153 Linn, J., Ed. and P. Mishra, Ed., "SSTC Response to
3154 "Security Analysis of the SAML Single Sign-on Browser/
3155 Artifact Profile"", January 2005.
3157 [OASIS.sstc-saml-bindings-1.1]
3158 Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
3159 "Bindings and Profiles for the OASIS Security Assertion
3160 Markup Language (SAML) V1.1", September 2003.
3162 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
3163 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
3164 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
3166 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
3168 [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
3169 Requirements for Security", BCP 106, RFC 4086, June 2005.
3171 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
3172 Kerberos Network Authentication Service (V5)", RFC 4120,
3173 July 2005.
3175 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
3176 Internet Protocol", RFC 4301, December 2005.
3178 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
3179 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
3181 [framebusting]
3182 Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
3183 "Busting Frame Busting: a Study of Clickjacking
3184 Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
3185 Security and Privacy Workshop, 2010.
3187 [gross-sec-analysis]
3188 Gross, T., "Security Analysis of the SAML Single Sign-on
3189 Browser/Artifact Profile, 19th Annual Computer Security
3190 Applications Conference, Las Vegas", December 2003.
3192 [iFrame] World Wide Web Consortium, "Frames in HTML documents",
3193 W3C HTML 4.01, Dec 1999.
3195 [openid] "OpenID Foundation Home Page", .
3197 [owasp] "Open Web Application Security Project Home Page",
3198 .
3200 [portable-contacts]
3201 Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
3202 .
3204 [ssl-latency]
3205 Sissel, J., Ed., "SSL handshake latency and HTTPS
3206 optimizations", June 2010.
3208 Appendix A. Document History
3210 [[ to be removed by RFC editor before publication as an RFC ]]
3212 draft-lodderstedt-oauth-security-01
3214 o section 4.4.1.2 - changed "resource server" to "client" in
3215 countermeasures description.
3217 o section 4.4.1.6 - changed "client shall authenticate the server"
3218 to "The browser shall be utilized to authenticate the redirection
3219 URI of the client"
3221 o section 5 - general review and alignment with public/confidential
3222 client terms
3224 o all sections - general clean-up and typo corrections
3226 draft-ietf-oauth-v2-threatmodel-00
3228 o section 3.4 - added the purposes for using authorization codes.
3230 o extended section 4.4.1.1
3232 o merged 4.4.1.5 into 4.4.1.2
3234 o corrected some typos
3235 o reformulated "session fixation", renamed respective sections into
3236 "authorization code disclosure through counterfeit client"
3238 o added new section "User session impersonation"
3240 o worked out or reworked sections 2.3.3, 4.4.2.4, 4.4.4, 5.1.4.1.2,
3241 5.1.4.1.4, 5.2.3.5
3243 o added new threat "DoS using manufactured authorization codes" as
3244 proposed by Peifung E Lam
3246 o added XSRF and clickjacking (incl. state parameter explanation)
3248 o changed sub-section order in section 4.4.1
3250 o incorporated feedback from Skylar Woodward (client secrets) and
3251 Shane B Weeden (refresh tokens as client instance secret)
3253 o aligned client section with core draft's client type definition
3255 o converted I-D into WG document
3257 draft-ietf-oauth-v2-threatmodel-01
3259 o Alignment of terminology with core draft 22 (private/public
3260 client, redirect URI validation policy, replaced definition of the
3261 client categories by reference to respective core section)
3263 o Synchronisation with the core's security consideration section
3264 (UPDATE 10.12 CSRF, NEW 10.14/15)
3266 o Added Resource Owner Impersonation
3268 o Improved section 5
3270 o Renamed Refresh Token Replacement to Refresh Token Rotation
3272 draft-ietf-oauth-v2-threatmodel-02
3274 o Incoporated Tim Bray's review comments (e.g. removed all normative
3275 language)
3277 draft-ietf-oauth-v2-threatmodel-03
3279 o removed 2119 boilerplate and normative reference
3281 o incorporated shepherd review feedback
3282 o incorporated AD review feedback
3284 draft-ietf-oauth-v2-threatmodel-07
3286 o added new section on token substituation
3288 o made references to core and bearer normative
3290 Authors' Addresses
3292 Torsten Lodderstedt (editor)
3293 Deutsche Telekom AG
3295 Email: torsten@lodderstedt.net
3297 Mark McGloin
3298 IBM
3300 Email: mark.mcgloin@ie.ibm.com
3302 Phil Hunt
3303 Oracle Corporation
3305 Email: phil.hunt@yahoo.com