<pre>Internet Engineering Task Force (IETF)               T. Lodderstedt, Ed.
Request for Comments: 6819                           Deutsche Telekom AG
Category: Informational                                       M. McGloin
ISSN: 2070-1721                                                      IBM
                                                                 P. Hunt
                                                      Oracle Corporation
                                                            January 2013


           <span class="h1">OAuth 2.0 Threat Model and Security Considerations</span>

Abstract

   This document gives additional security considerations for OAuth,
   beyond those in the OAuth 2.0 specification, based on a comprehensive
   threat model for the OAuth 2.0 protocol.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6819">http://www.rfc-editor.org/info/rfc6819</a>.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




<span class="grey">Lodderstedt, et al.           Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-6">6</a>
   <a href="#section-2">2</a>. Overview ........................................................<a href="#page-7">7</a>
      <a href="#section-2.1">2.1</a>. Scope ......................................................<a href="#page-7">7</a>
      <a href="#section-2.2">2.2</a>. Attack Assumptions .........................................<a href="#page-7">7</a>
      <a href="#section-2.3">2.3</a>. Architectural Assumptions ..................................<a href="#page-8">8</a>
           <a href="#section-2.3.1">2.3.1</a>. Authorization Servers ...............................<a href="#page-8">8</a>
           <a href="#section-2.3.2">2.3.2</a>. Resource Server .....................................<a href="#page-9">9</a>
           <a href="#section-2.3.3">2.3.3</a>. Client ..............................................<a href="#page-9">9</a>
   <a href="#section-3">3</a>. Security Features ...............................................<a href="#page-9">9</a>
      <a href="#section-3.1">3.1</a>. Tokens ....................................................<a href="#page-10">10</a>
           <a href="#section-3.1.1">3.1.1</a>. Scope ..............................................<a href="#page-11">11</a>
           <a href="#section-3.1.2">3.1.2</a>. Limited Access Token Lifetime ......................<a href="#page-11">11</a>
      <a href="#section-3.2">3.2</a>. Access Token ..............................................<a href="#page-11">11</a>
      <a href="#section-3.3">3.3</a>. Refresh Token .............................................<a href="#page-11">11</a>
      <a href="#section-3.4">3.4</a>. Authorization "code" ......................................<a href="#page-12">12</a>
      <a href="#section-3.5">3.5</a>. Redirect URI ..............................................<a href="#page-13">13</a>
      <a href="#section-3.6">3.6</a>. "state" Parameter .........................................<a href="#page-13">13</a>
      <a href="#section-3.7">3.7</a>. Client Identifier .........................................<a href="#page-13">13</a>
   <a href="#section-4">4</a>. Threat Model ...................................................<a href="#page-15">15</a>
      <a href="#section-4.1">4.1</a>. Clients ...................................................<a href="#page-16">16</a>
           <a href="#section-4.1.1">4.1.1</a>. Threat: Obtaining Client Secrets ...................<a href="#page-16">16</a>
           <a href="#section-4.1.2">4.1.2</a>. Threat: Obtaining Refresh Tokens ...................<a href="#page-17">17</a>
           <a href="#section-4.1.3">4.1.3</a>. Threat: Obtaining Access Tokens ....................<a href="#page-19">19</a>
           4.1.4. Threat: End-User Credentials Phished Using
                  Compromised or Embedded Browser ....................<a href="#page-19">19</a>
           <a href="#section-4.1.5">4.1.5</a>. Threat: Open Redirectors on Client .................<a href="#page-20">20</a>
      <a href="#section-4.2">4.2</a>. Authorization Endpoint ....................................<a href="#page-21">21</a>
           4.2.1. Threat: Password Phishing by Counterfeit
                  Authorization Server ...............................<a href="#page-21">21</a>
           4.2.2. Threat: User Unintentionally Grants Too
                  Much Access Scope ..................................<a href="#page-21">21</a>
           4.2.3. Threat: Malicious Client Obtains Existing
                  Authorization by Fraud .............................<a href="#page-22">22</a>
           <a href="#section-4.2.4">4.2.4</a>. Threat: Open Redirector ............................<a href="#page-22">22</a>
      <a href="#section-4.3">4.3</a>. Token Endpoint ............................................<a href="#page-23">23</a>
           <a href="#section-4.3.1">4.3.1</a>. Threat: Eavesdropping Access Tokens ................<a href="#page-23">23</a>
           4.3.2. Threat: Obtaining Access Tokens from
                  Authorization Server Database ......................<a href="#page-23">23</a>
           4.3.3. Threat: Disclosure of Client Credentials
                  during Transmission ................................<a href="#page-23">23</a>
           4.3.4. Threat: Obtaining Client Secret from
                  Authorization Server Database ......................<a href="#page-24">24</a>
           4.3.5. Threat: Obtaining Client Secret by Online Guessing .24






<span class="grey">Lodderstedt, et al.           Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


      <a href="#section-4.4">4.4</a>. Obtaining Authorization ...................................<a href="#page-25">25</a>
           <a href="#section-4.4.1">4.4.1</a>. Authorization "code" ...............................<a href="#page-25">25</a>
                  4.4.1.1. Threat: Eavesdropping or Leaking
                           Authorization "codes" .....................<a href="#page-25">25</a>
                  4.4.1.2. Threat: Obtaining Authorization "codes"
                           from Authorization Server Database ........<a href="#page-26">26</a>
                  4.4.1.3. Threat: Online Guessing of
                           Authorization "codes" .....................<a href="#page-27">27</a>
                  4.4.1.4. Threat: Malicious Client Obtains
                           Authorization .............................<a href="#page-27">27</a>
                  <a href="#section-4.4.1.5">4.4.1.5</a>. Threat: Authorization "code" Phishing .....<a href="#page-29">29</a>
                  <a href="#section-4.4.1.6">4.4.1.6</a>. Threat: User Session Impersonation ........<a href="#page-29">29</a>
                  4.4.1.7. Threat: Authorization "code" Leakage
                           through Counterfeit Client ................<a href="#page-30">30</a>
                  <a href="#section-4.4.1.8">4.4.1.8</a>. Threat: CSRF Attack against redirect-uri ..32
                  4.4.1.9. Threat: Clickjacking Attack against
                           Authorization .............................<a href="#page-33">33</a>
                  <a href="#section-4.4.1.10">4.4.1.10</a>. Threat: Resource Owner Impersonation .....<a href="#page-33">33</a>
                  4.4.1.11. Threat: DoS Attacks That Exhaust
                            Resources ................................<a href="#page-34">34</a>
                  4.4.1.12. Threat: DoS Using Manufactured
                            Authorization "codes" ....................<a href="#page-35">35</a>
                  <a href="#section-4.4.1.13">4.4.1.13</a>. Threat: Code Substitution (OAuth Login) ..36
           <a href="#section-4.4.2">4.4.2</a>. Implicit Grant .....................................<a href="#page-37">37</a>
                  4.4.2.1. Threat: Access Token Leak in
                           Transport/Endpoints .......................<a href="#page-37">37</a>
                  4.4.2.2. Threat: Access Token Leak in
                           Browser History ...........................<a href="#page-38">38</a>
                  4.4.2.3. Threat: Malicious Client Obtains
                           Authorization .............................<a href="#page-38">38</a>
                  <a href="#section-4.4.2.4">4.4.2.4</a>. Threat: Manipulation of Scripts ...........<a href="#page-38">38</a>
                  <a href="#section-4.4.2.5">4.4.2.5</a>. Threat: CSRF Attack against redirect-uri ..39
                  <a href="#section-4.4.2.6">4.4.2.6</a>. Threat: Token Substitution (OAuth Login) ..39
           <a href="#section-4.4.3">4.4.3</a>. Resource Owner Password Credentials ................<a href="#page-40">40</a>
                  4.4.3.1. Threat: Accidental Exposure of
                           Passwords at Client Site ..................<a href="#page-41">41</a>
                  4.4.3.2. Threat: Client Obtains Scopes
                           without End-User Authorization ............<a href="#page-42">42</a>
                  4.4.3.3. Threat: Client Obtains Refresh
                           Token through Automatic Authorization .....<a href="#page-42">42</a>
                  4.4.3.4. Threat: Obtaining User Passwords
                           on Transport ..............................<a href="#page-43">43</a>
                  4.4.3.5. Threat: Obtaining User Passwords
                           from Authorization Server Database ........<a href="#page-43">43</a>
                  <a href="#section-4.4.3.6">4.4.3.6</a>. Threat: Online Guessing ...................<a href="#page-43">43</a>
           <a href="#section-4.4.4">4.4.4</a>. Client Credentials .................................<a href="#page-44">44</a>





<span class="grey">Lodderstedt, et al.           Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


      <a href="#section-4.5">4.5</a>. Refreshing an Access Token ................................<a href="#page-44">44</a>
           4.5.1. Threat: Eavesdropping Refresh Tokens from
                  Authorization Server ...............................<a href="#page-44">44</a>
           4.5.2. Threat: Obtaining Refresh Token from
                  Authorization Server Database ......................<a href="#page-44">44</a>
           4.5.3. Threat: Obtaining Refresh Token by Online
                  Guessing ...........................................<a href="#page-45">45</a>
           4.5.4. Threat: Refresh Token Phishing by
                  Counterfeit Authorization Server ...................<a href="#page-45">45</a>
      <a href="#section-4.6">4.6</a>. Accessing Protected Resources .............................<a href="#page-46">46</a>
           <a href="#section-4.6.1">4.6.1</a>. Threat: Eavesdropping Access Tokens on Transport ...<a href="#page-46">46</a>
           4.6.2. Threat: Replay of Authorized Resource
                  Server Requests ....................................<a href="#page-46">46</a>
           <a href="#section-4.6.3">4.6.3</a>. Threat: Guessing Access Tokens .....................<a href="#page-46">46</a>
           4.6.4. Threat: Access Token Phishing by
                  Counterfeit Resource Server ........................<a href="#page-47">47</a>
           4.6.5. Threat: Abuse of Token by Legitimate
                  Resource Server or Client ..........................<a href="#page-48">48</a>
           <a href="#section-4.6.6">4.6.6</a>. Threat: Leak of Confidential Data in HTTP Proxies ..48
           4.6.7. Threat: Token Leakage via Log Files and
                  HTTP Referrers .....................................<a href="#page-48">48</a>
   <a href="#section-5">5</a>. Security Considerations ........................................<a href="#page-49">49</a>
      <a href="#section-5.1">5.1</a>. General ...................................................<a href="#page-49">49</a>
           <a href="#section-5.1.1">5.1.1</a>. Ensure Confidentiality of Requests .................<a href="#page-49">49</a>
           <a href="#section-5.1.2">5.1.2</a>. Utilize Server Authentication ......................<a href="#page-50">50</a>
           <a href="#section-5.1.3">5.1.3</a>. Always Keep the Resource Owner Informed ............<a href="#page-50">50</a>
           <a href="#section-5.1.4">5.1.4</a>. Credentials ........................................<a href="#page-51">51</a>
                  5.1.4.1. Enforce Credential Storage
                           Protection Best Practices .................<a href="#page-51">51</a>
                  <a href="#section-5.1.4.2">5.1.4.2</a>. Online Attacks on Secrets .................<a href="#page-52">52</a>
           <a href="#section-5.1.5">5.1.5</a>. Tokens (Access, Refresh, Code) .....................<a href="#page-53">53</a>
                  <a href="#section-5.1.5.1">5.1.5.1</a>. Limit Token Scope .........................<a href="#page-53">53</a>
                  <a href="#section-5.1.5.2">5.1.5.2</a>. Determine Expiration Time .................<a href="#page-54">54</a>
                  <a href="#section-5.1.5.3">5.1.5.3</a>. Use Short Expiration Time .................<a href="#page-54">54</a>
                  <a href="#section-5.1.5.4">5.1.5.4</a>. Limit Number of Usages or One-Time Usage ..55
                  5.1.5.5. Bind Tokens to a Particular
                           Resource Server (Audience) ................<a href="#page-55">55</a>
                  <a href="#section-5.1.5.6">5.1.5.6</a>. Use Endpoint Address as Token Audience ....<a href="#page-56">56</a>
                  5.1.5.7. Use Explicitly Defined Scopes for
                           Audience and Tokens .......................<a href="#page-56">56</a>
                  <a href="#section-5.1.5.8">5.1.5.8</a>. Bind Token to Client id ...................<a href="#page-56">56</a>
                  <a href="#section-5.1.5.9">5.1.5.9</a>. Sign Self-Contained Tokens ................<a href="#page-56">56</a>
                  <a href="#section-5.1.5.10">5.1.5.10</a>. Encrypt Token Content ....................<a href="#page-56">56</a>
                  <a href="#section-5.1.5.11">5.1.5.11</a>. Adopt a Standard Assertion Format ........<a href="#page-57">57</a>
           <a href="#section-5.1.6">5.1.6</a>. Access Tokens ......................................<a href="#page-57">57</a>






<span class="grey">Lodderstedt, et al.           Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


      <a href="#section-5.2">5.2</a>. Authorization Server ......................................<a href="#page-57">57</a>
           <a href="#section-5.2.1">5.2.1</a>. Authorization "codes" ..............................<a href="#page-57">57</a>
                  5.2.1.1. Automatic Revocation of Derived
                           Tokens If Abuse Is Detected ...............<a href="#page-57">57</a>
           <a href="#section-5.2.2">5.2.2</a>. Refresh Tokens .....................................<a href="#page-57">57</a>
                  <a href="#section-5.2.2.1">5.2.2.1</a>. Restricted Issuance of Refresh Tokens .....<a href="#page-57">57</a>
                  <a href="#section-5.2.2.2">5.2.2.2</a>. Binding of Refresh Token to "client_id" ...<a href="#page-58">58</a>
                  <a href="#section-5.2.2.3">5.2.2.3</a>. Refresh Token Rotation ....................<a href="#page-58">58</a>
                  <a href="#section-5.2.2.4">5.2.2.4</a>. Revocation of Refresh Tokens ..............<a href="#page-58">58</a>
                  <a href="#section-5.2.2.5">5.2.2.5</a>. Device Identification .....................<a href="#page-59">59</a>
                  <a href="#section-5.2.2.6">5.2.2.6</a>. X-FRAME-OPTIONS Header ....................<a href="#page-59">59</a>
           <a href="#section-5.2.3">5.2.3</a>. Client Authentication and Authorization ............<a href="#page-59">59</a>
                  5.2.3.1. Don't Issue Secrets to Clients with
                           Inappropriate Security Policy .............<a href="#page-60">60</a>
                  5.2.3.2. Require User Consent for Public
                           Clients without Secret ....................<a href="#page-60">60</a>
                  5.2.3.3. Issue a "client_id" Only in
                           Combination with "redirect_uri" ...........<a href="#page-61">61</a>
                  5.2.3.4. Issue Installation-Specific Client
                           Secrets ...................................<a href="#page-61">61</a>
                  <a href="#section-5.2.3.5">5.2.3.5</a>. Validate Pre-Registered "redirect_uri" ....<a href="#page-62">62</a>
                  <a href="#section-5.2.3.6">5.2.3.6</a>. Revoke Client Secrets .....................<a href="#page-63">63</a>
                  5.2.3.7. Use Strong Client Authentication
                           (e.g., client_assertion/client_token) .....<a href="#page-63">63</a>
           <a href="#section-5.2.4">5.2.4</a>. End-User Authorization .............................<a href="#page-63">63</a>
                  5.2.4.1. Automatic Processing of Repeated
                           Authorizations Requires Client Validation .63
                  <a href="#section-5.2.4.2">5.2.4.2</a>. Informed Decisions Based on Transparency ..63
                  5.2.4.3. Validation of Client Properties by
                           End User ..................................<a href="#page-64">64</a>
                  5.2.4.4. Binding of Authorization "code" to
                           "client_id" ...............................<a href="#page-64">64</a>
                  5.2.4.5. Binding of Authorization "code" to
                           "redirect_uri" ............................<a href="#page-64">64</a>
      <a href="#section-5.3">5.3</a>. Client App Security .......................................<a href="#page-65">65</a>
           5.3.1. Don't Store Credentials in Code or
                  Resources Bundled with Software Packages ...........<a href="#page-65">65</a>
           5.3.2. Use Standard Web Server Protection Measures
                  (for Config Files and Databases) ...................<a href="#page-65">65</a>
           <a href="#section-5.3.3">5.3.3</a>. Store Secrets in Secure Storage ....................<a href="#page-65">65</a>
           5.3.4. Utilize Device Lock to Prevent Unauthorized
                  Device Access ......................................<a href="#page-66">66</a>
           <a href="#section-5.3.5">5.3.5</a>. Link the "state" Parameter to User Agent Session ...<a href="#page-66">66</a>
      <a href="#section-5.4">5.4</a>. Resource Servers ..........................................<a href="#page-66">66</a>
           <a href="#section-5.4.1">5.4.1</a>. Authorization Headers ..............................<a href="#page-66">66</a>
           <a href="#section-5.4.2">5.4.2</a>. Authenticated Requests .............................<a href="#page-67">67</a>
           <a href="#section-5.4.3">5.4.3</a>. Signed Requests ....................................<a href="#page-67">67</a>
      <a href="#section-5.5">5.5</a>. A Word on User Interaction and User-Installed Apps ........<a href="#page-68">68</a>



<span class="grey">Lodderstedt, et al.           Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   <a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-69">69</a>
   <a href="#section-7">7</a>. References .....................................................<a href="#page-69">69</a>
      <a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-69">69</a>
      <a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-69">69</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   This document gives additional security considerations for OAuth,
   beyond those in the OAuth specification, based on a comprehensive
   threat model for the OAuth 2.0 protocol [<a href="./rfc6749" title="&quot;The OAuth 2.0 Authorization Framework&quot;">RFC6749</a>].  It contains the
   following content:

   o  Documents any assumptions and scope considered when creating the
      threat model.

   o  Describes the security features built into the OAuth protocol and
      how they are intended to thwart attacks.

   o  Gives a comprehensive threat model for OAuth and describes the
      respective countermeasures to thwart those threats.

   Threats include any intentional attacks on OAuth tokens and resources
   protected by OAuth tokens, as well as security risks introduced if
   the proper security measures are not put in place.  Threats are
   structured along the lines of the protocol structure to help
   development teams implement each part of the protocol securely, for
   example, all threats for granting access, or all threats for a
   particular grant type, or all threats for protecting the resource
   server.

   Note: This document cannot assess the probability or the risk
   associated with a particular threat because those aspects strongly
   depend on the particular application and deployment OAuth is used to
   protect.  Similarly, impacts are given on a rather abstract level.
   But the information given here may serve as a foundation for
   deployment-specific threat models.  Implementors may refine and
   detail the abstract threat model in order to account for the specific
   properties of their deployment and to come up with a risk analysis.
   As this document is based on the base OAuth 2.0 specification, it
   does not consider proposed extensions such as client registration or
   discovery, many of which are still under discussion.










<span class="grey">Lodderstedt, et al.           Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Overview</span>

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Scope</span>

   This security considerations document only considers clients bound to
   a particular deployment as supported by [<a href="./rfc6749" title="&quot;The OAuth 2.0 Authorization Framework&quot;">RFC6749</a>].  Such deployments
   have the following characteristics:

   o  Resource server URLs are static and well-known at development
      time; authorization server URLs can be static or discovered.

   o  Token scope values (e.g., applicable URLs and methods) are well-
      known at development time.

   o  Client registration is out of scope of the current core
      specification.  Therefore, this document assumes a broad variety
      of options, from static registration during development time to
      dynamic registration at runtime.

   The following are considered out of scope:

   o  Communication between the authorization server and resource
      server.

   o  Token formats.

   o  Except for the resource owner password credentials grant type (see
      <a href="./rfc6749#section-4.3">[RFC6749], Section&nbsp;4.3</a>), the mechanism used by authorization
      servers to authenticate the user.

   o  Mechanism by which a user obtained an assertion and any resulting
      attacks mounted as a result of the assertion being false.

   o  Clients not bound to a specific deployment: An example could be a
      mail client with support for contact list access via the portable
      contacts API (see [<a href="#ref-Portable-Contacts">Portable-Contacts</a>]).  Such clients cannot be
      registered upfront with a particular deployment and should
      dynamically discover the URLs relevant for the OAuth protocol.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Attack Assumptions</span>

   The following assumptions relate to an attacker and resources
   available to an attacker.  It is assumed that:

   o  the attacker has full access to the network between the client and
      authorization servers and the client and the resource server,
      respectively.  The attacker may eavesdrop on any communications




<span class="grey">Lodderstedt, et al.           Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


      between those parties.  He is not assumed to have access to
      communication between the authorization server and resource
      server.

   o  an attacker has unlimited resources to mount an attack.

   o  two of the three parties involved in the OAuth protocol may
      collude to mount an attack against the 3rd party.  For example,
      the client and authorization server may be under control of an
      attacker and collude to trick a user to gain access to resources.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Architectural Assumptions</span>

   This section documents assumptions about the features, limitations,
   and design options of the different entities of an OAuth deployment
   along with the security-sensitive data elements managed by those
   entities.  These assumptions are the foundation of the threat
   analysis.

   The OAuth protocol leaves deployments with a certain degree of
   freedom regarding how to implement and apply the standard.  The core
   specification defines the core concepts of an authorization server
   and a resource server.  Both servers can be implemented in the same
   server entity, or they may also be different entities.  The latter is
   typically the case for multi-service providers with a single
   authentication and authorization system and is more typical in
   middleware architectures.

<span class="h4"><a class="selflink" id="section-2.3.1" href="#section-2.3.1">2.3.1</a>.  Authorization Servers</span>

   The following data elements are stored or accessible on the
   authorization server:

   o  usernames and passwords

   o  client ids and secrets

   o  client-specific refresh tokens

   o  client-specific access tokens (in the case of handle-based design;
      see <a href="#section-3.1">Section 3.1</a>)

   o  HTTPS certificate/key

   o  per-authorization process (in the case of handle-based design;
      <a href="#section-3.1">Section 3.1</a>): "redirect_uri", "client_id", authorization "code"





<span class="grey">Lodderstedt, et al.           Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h4"><a class="selflink" id="section-2.3.2" href="#section-2.3.2">2.3.2</a>.  Resource Server</span>

   The following data elements are stored or accessible on the resource
   server:

   o  user data (out of scope)

   o  HTTPS certificate/key

   o  either authorization server credentials (handle-based design; see
      <a href="#section-3.1">Section 3.1</a>) or authorization server shared secret/public key
      (assertion-based design; see <a href="#section-3.1">Section 3.1</a>)

   o  access tokens (per request)

   It is assumed that a resource server has no knowledge of refresh
   tokens, user passwords, or client secrets.

<span class="h4"><a class="selflink" id="section-2.3.3" href="#section-2.3.3">2.3.3</a>.  Client</span>

   In OAuth, a client is an application making protected resource
   requests on behalf of the resource owner and with its authorization.
   There are different types of clients with different implementation
   and security characteristics, such as web, user-agent-based, and
   native applications.  A full definition of the different client types
   and profiles is given in <a href="./rfc6749#section-2.1">[RFC6749], Section&nbsp;2.1</a>.

   The following data elements are stored or accessible on the client:

   o  client id (and client secret or corresponding client credential)

   o  one or more refresh tokens (persistent) and access tokens
      (transient) per end user or other security-context or delegation
      context

   o  trusted certification authority (CA) certificates (HTTPS)

   o  per-authorization process: "redirect_uri", authorization "code"

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Security Features</span>

   These are some of the security features that have been built into the
   OAuth 2.0 protocol to mitigate attacks and security issues.








<span class="grey">Lodderstedt, et al.           Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Tokens</span>

   OAuth makes extensive use of many kinds of tokens (access tokens,
   refresh tokens, authorization "codes").  The information content of a
   token can be represented in two ways, as follows:

   Handle (or artifact)  A 'handle' is a reference to some internal data
      structure within the authorization server; the internal data
      structure contains the attributes of the token, such as user id
      (UID), scope, etc.  Handles enable simple revocation and do not
      require cryptographic mechanisms to protect token content from
      being modified.  On the other hand, handles require communication
      between the issuing and consuming entity (e.g., the authorization
      server and resource server) in order to validate the token and
      obtain token-bound data.  This communication might have a negative
      impact on performance and scalability if both entities reside on
      different systems.  Handles are therefore typically used if the
      issuing and consuming entity are the same.  A 'handle' token is
      often referred to as an 'opaque' token because the resource server
      does not need to be able to interpret the token directly; it
      simply uses the token.

   Assertion (aka self-contained token)  An assertion is a parseable
      token.  An assertion typically has a duration, has an audience,
      and is digitally signed in order to ensure data integrity and
      origin authentication.  It contains information about the user and
      the client.  Examples of assertion formats are Security Assertion
      Markup Language (SAML) assertions [<a href="#ref-OASIS.saml-core-2.0-os">OASIS.saml-core-2.0-os</a>] and
      Kerberos tickets [<a href="./rfc4120" title="&quot;The Kerberos Network Authentication Service (V5)&quot;">RFC4120</a>].  Assertions can typically be directly
      validated and used by a resource server without interactions with
      the authorization server.  This results in better performance and
      scalability in deployments where the issuing and consuming
      entities reside on different systems.  Implementing token
      revocation is more difficult with assertions than with handles.

   Tokens can be used in two ways to invoke requests on resource
   servers, as follows:

   bearer token  A 'bearer token' is a token that can be used by any
      client who has received the token (e.g., [<a href="./rfc6750" title="&quot;The OAuth 2.0 Authorization Framework: Bearer Token Usage&quot;">RFC6750</a>]).  Because mere
      possession is enough to use the token, it is important that
      communication between endpoints be secured to ensure that only
      authorized endpoints may capture the token.  The bearer token is
      convenient for client applications, as it does not require them to
      do anything to use them (such as a proof of identity).  Bearer
      tokens have similar characteristics to web single-sign-on (SSO)
      cookies used in browsers.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   proof token  A 'proof token' is a token that can only be used by a
      specific client.  Each use of the token requires the client to
      perform some action that proves that it is the authorized user of
      the token.  Examples of this are MAC-type access tokens, which
      require the client to digitally sign the resource request with a
      secret corresponding to the particular token sent with the request
      (e.g., [<a href="#ref-OAuth-HTTP-MAC">OAuth-HTTP-MAC</a>]).

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Scope</span>

   A scope represents the access authorization associated with a
   particular token with respect to resource servers, resources, and
   methods on those resources.  Scopes are the OAuth way to explicitly
   manage the power associated with an access token.  A scope can be
   controlled by the authorization server and/or the end user in order
   to limit access to resources for OAuth clients that these parties
   deem less secure or trustworthy.  Optionally, the client can request
   the scope to apply to the token but only for a lesser scope than
   would otherwise be granted, e.g., to reduce the potential impact if
   this token is sent over non-secure channels.  A scope is typically
   complemented by a restriction on a token's lifetime.

<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>.  Limited Access Token Lifetime</span>

   The protocol parameter "expires_in" allows an authorization server
   (based on its policies or on behalf of the end user) to limit the
   lifetime of an access token and to pass this information to the
   client.  This mechanism can be used to issue short-lived tokens to
   OAuth clients that the authorization server deems less secure, or
   where sending tokens over non-secure channels.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Access Token</span>

   An access token is used by a client to access a resource.  Access
   tokens typically have short life spans (minutes or hours) that cover
   typical session lifetimes.  An access token may be refreshed through
   the use of a refresh token.  The short lifespan of an access token,
   in combination with the usage of refresh tokens, enables the
   possibility of passive revocation of access authorization on the
   expiry of the current access token.

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Refresh Token</span>

   A refresh token represents a long-lasting authorization of a certain
   client to access resources on behalf of a resource owner.  Such
   tokens are exchanged between the client and authorization server
   only.  Clients use this kind of token to obtain ("refresh") new
   access tokens used for resource server invocations.



<span class="grey">Lodderstedt, et al.           Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   A refresh token, coupled with a short access token lifetime, can be
   used to grant longer access to resources without involving end-user
   authorization.  This offers an advantage where resource servers and
   authorization servers are not the same entity, e.g., in a distributed
   environment, as the refresh token is always exchanged at the
   authorization server.  The authorization server can revoke the
   refresh token at any time, causing the granted access to be revoked
   once the current access token expires.  Because of this, a short
   access token lifetime is important if timely revocation is a high
   priority.

   The refresh token is also a secret bound to the client identifier and
   client instance that originally requested the authorization; the
   refresh token also represents the original resource owner grant.
   This is ensured by the authorization process as follows:

   1.  The resource owner and user agent safely deliver the
       authorization "code" to the client instance in the first place.

   2.  The client uses it immediately in secure transport-level
       communications to the authorization server and then securely
       stores the long-lived refresh token.

   3.  The client always uses the refresh token in secure transport-
       level communications to the authorization server to get an access
       token (and optionally roll over the refresh token).

   So, as long as the confidentiality of the particular token can be
   ensured by the client, a refresh token can also be used as an
   alternative means to authenticate the client instance itself.

<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Authorization "code"</span>

   An authorization "code" represents the intermediate result of a
   successful end-user authorization process and is used by the client
   to obtain access and refresh tokens.  Authorization "codes" are sent
   to the client's redirect URI instead of tokens for two purposes:

   1.  Browser-based flows expose protocol parameters to potential
       attackers via URI query parameters (HTTP referrer), the browser
       cache, or log file entries, and could be replayed.  In order to
       reduce this threat, short-lived authorization "codes" are passed
       instead of tokens and exchanged for tokens over a more secure
       direct connection between the client and the authorization
       server.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   2.  It is much simpler to authenticate clients during the direct
       request between the client and the authorization server than in
       the context of the indirect authorization request.  The latter
       would require digital signatures.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Redirect URI</span>

   A redirect URI helps to detect malicious clients and prevents
   phishing attacks from clients attempting to trick the user into
   believing the phisher is the client.  The value of the actual
   redirect URI used in the authorization request has to be presented
   and is verified when an authorization "code" is exchanged for tokens.
   This helps to prevent attacks where the authorization "code" is
   revealed through redirectors and counterfeit web application clients.
   The authorization server should require public clients and
   confidential clients using the implicit grant type to pre-register
   their redirect URIs and validate against the registered redirect URI
   in the authorization request.

<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>.  "state" Parameter</span>

   The "state" parameter is used to link requests and callbacks to
   prevent cross-site request forgery attacks (see <a href="#section-4.4.1.8">Section 4.4.1.8</a>)
   where an attacker authorizes access to his own resources and then
   tricks a user into following a redirect with the attacker's token.
   This parameter should bind to the authenticated state in a user agent
   and, as per the core OAuth spec, the user agent must be capable of
   keeping it in a location accessible only by the client and user
   agent, i.e., protected by same-origin policy.

<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>.  Client Identifier</span>

   Authentication protocols have typically not taken into account the
   identity of the software component acting on behalf of the end user.
   OAuth does this in order to increase the security level in delegated
   authorization scenarios and because the client will be able to act
   without the user being present.

   OAuth uses the client identifier to collate associated requests to
   the same originator, such as

   o  a particular end-user authorization process and the corresponding
      request on the token's endpoint to exchange the authorization
      "code" for tokens, or







<span class="grey">Lodderstedt, et al.           Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  the initial authorization and issuance of a token by an end user
      to a particular client, and subsequent requests by this client to
      obtain tokens without user consent (automatic processing of
      repeated authorizations)

   This identifier may also be used by the authorization server to
   display relevant registration information to a user when requesting
   consent for a scope requested by a particular client.  The client
   identifier may be used to limit the number of requests for a
   particular client or to charge the client per request.  It may
   furthermore be useful to differentiate access by different clients,
   e.g., in server log files.

   OAuth defines two client types, confidential and public, based on
   their ability to authenticate with the authorization server (i.e.,
   ability to maintain the confidentiality of their client credentials).
   Confidential clients are capable of maintaining the confidentiality
   of client credentials (i.e., a client secret associated with the
   client identifier) or capable of secure client authentication using
   other means, such as a client assertion (e.g., SAML) or key
   cryptography.  The latter is considered more secure.

   The authorization server should determine whether the client is
   capable of keeping its secret confidential or using secure
   authentication.  Alternatively, the end user can verify the identity
   of the client, e.g., by only installing trusted applications.  The
   redirect URI can be used to prevent the delivery of credentials to a
   counterfeit client after obtaining end-user authorization in some
   cases but can't be used to verify the client identifier.

   Clients can be categorized as follows based on the client type,
   profile (e.g., native vs. web application; see <a href="./rfc6749#section-9">[RFC6749], Section&nbsp;9</a>),
   and deployment model:

   Deployment-independent "client_id" with pre-registered "redirect_uri"
      and without "client_secret"  Such an identifier is used by
      multiple installations of the same software package.  The
      identifier of such a client can only be validated with the help of
      the end-user.  This is a viable option for native applications in
      order to identify the client for the purpose of displaying meta
      information about the client to the user and to differentiate
      clients in log files.  Revocation of the rights associated with
      such a client identifier will affect ALL deployments of the
      respective software.







<span class="grey">Lodderstedt, et al.           Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Deployment-independent "client_id" with pre-registered "redirect_uri"
      and with "client_secret"  This is an option for native
      applications only, since web applications would require different
      redirect URIs.  This category is not advisable because the client
      secret cannot be protected appropriately (see <a href="#section-4.1.1">Section 4.1.1</a>).  Due
      to its security weaknesses, such client identities have the same
      trust level as deployment-independent clients without secrets.
      Revocation will affect ALL deployments.

   Deployment-specific "client_id" with pre-registered "redirect_uri"
      and with "client_secret"  The client registration process ensures
      the validation of the client's properties, such as redirect URI,
      web site URL, web site name, and contacts.  Such a client
      identifier can be utilized for all relevant use cases cited above.
      This level can be achieved for web applications in combination
      with a manual or user-bound registration process.  Achieving this
      level for native applications is much more difficult.  Either the
      installation of the application is conducted by an administrator,
      who validates the client's authenticity, or the process from
      validating the application to the installation of the application
      on the device and the creation of the client credentials is
      controlled end-to-end by a single entity (e.g., application market
      provider).  Revocation will affect a single deployment only.

   Deployment-specific "client_id" with "client_secret" without
      validated properties  Such a client can be recognized by the
      authorization server in transactions with subsequent requests
      (e.g., authorization and token issuance, refresh token issuance,
      and access token refreshment).  The authorization server cannot
      assure any property of the client to end users.  Automatic
      processing of re-authorizations could be allowed as well.  Such
      client credentials can be generated automatically without any
      validation of client properties, which makes it another option,
      especially for native applications.  Revocation will affect a
      single deployment only.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Threat Model</span>

   This section gives a comprehensive threat model of OAuth 2.0.
   Threats are grouped first by attacks directed against an OAuth
   component, which are the client, authorization server, and resource
   server.  Subsequently, they are grouped by flow, e.g., obtain token
   or access protected resources.  Every countermeasure description
   refers to a detailed description in <a href="#section-5">Section 5</a>.







<span class="grey">Lodderstedt, et al.           Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Clients</span>

   This section describes possible threats directed to OAuth clients.

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Threat: Obtaining Client Secrets</span>

   The attacker could try to get access to the secret of a particular
   client in order to:

   o  replay its refresh tokens and authorization "codes", or

   o  obtain tokens on behalf of the attacked client with the privileges
      of that "client_id" acting as an instance of the client.

   The resulting impact would be the following:

   o  Client authentication of access to the authorization server can be
      bypassed.

   o  Stolen refresh tokens or authorization "codes" can be replayed.

   Depending on the client category, the following attacks could be
   utilized to obtain the client secret.

   Attack: Obtain Secret From Source Code or Binary:

   This applies for all client types.  For open source projects, secrets
   can be extracted directly from source code in their public
   repositories.  Secrets can be extracted from application binaries
   just as easily when the published source is not available to the
   attacker.  Even if an application takes significant measures to
   obfuscate secrets in their application distribution, one should
   consider that the secret can still be reverse-engineered by anyone
   with access to a complete functioning application bundle or binary.

   Countermeasures:

   o  Don't issue secrets to public clients or clients with
      inappropriate security policy (<a href="#section-5.2.3.1">Section 5.2.3.1</a>).

   o  Require user consent for public clients (<a href="#section-5.2.3.2">Section 5.2.3.2</a>).

   o  Use deployment-specific client secrets (<a href="#section-5.2.3.4">Section 5.2.3.4</a>).

   o  Revoke client secrets (<a href="#section-5.2.3.6">Section 5.2.3.6</a>).






<span class="grey">Lodderstedt, et al.           Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Attack: Obtain a Deployment-Specific Secret:

   An attacker may try to obtain the secret from a client installation,
   either from a web site (web server) or a particular device (native
   application).

   Countermeasures:

   o  Web server: Apply standard web server protection measures (for
      config files and databases) (see <a href="#section-5.3.2">Section 5.3.2</a>).

   o  Native applications: Store secrets in secure local storage
      (<a href="#section-5.3.3">Section 5.3.3</a>).

   o  Revoke client secrets (<a href="#section-5.2.3.6">Section 5.2.3.6</a>).

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  Threat: Obtaining Refresh Tokens</span>

   Depending on the client type, there are different ways that refresh
   tokens may be revealed to an attacker.  The following sub-sections
   give a more detailed description of the different attacks with
   respect to different client types and further specialized
   countermeasures.  Before detailing those threats, here are some
   generally applicable countermeasures:

   o  The authorization server should validate the client id associated
      with the particular refresh token with every refresh request
      (<a href="#section-5.2.2.2">Section 5.2.2.2</a>).

   o  Limit token scope (<a href="#section-5.1.5.1">Section 5.1.5.1</a>).

   o  Revoke refresh tokens (<a href="#section-5.2.2.4">Section 5.2.2.4</a>).

   o  Revoke client secrets (<a href="#section-5.2.3.6">Section 5.2.3.6</a>).

   o  Refresh tokens can automatically be replaced in order to detect
      unauthorized token usage by another party (see "Refresh Token
      Rotation", <a href="#section-5.2.2.3">Section 5.2.2.3</a>).


   Attack: Obtain Refresh Token from Web Application:

   An attacker may obtain the refresh tokens issued to a web application
   by way of overcoming the web server's security controls.

   Impact: Since a web application manages the user accounts of a
   certain site, such an attack would result in an exposure of all
   refresh tokens on that site to the attacker.



<span class="grey">Lodderstedt, et al.           Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  Standard web server protection measures (<a href="#section-5.3.2">Section 5.3.2</a>).

   o  Use strong client authentication (e.g., client_assertion/
      client_token) so the attacker cannot obtain the client secret
      required to exchange the tokens (<a href="#section-5.2.3.7">Section 5.2.3.7</a>).


   Attack: Obtain Refresh Token from Native Clients:

   On native clients, leakage of a refresh token typically affects a
   single user only.

   Read from local file system: The attacker could try to get file
   system access on the device and read the refresh tokens.  The
   attacker could utilize a malicious application for that purpose.

   Countermeasures:

   o  Store secrets in secure storage (<a href="#section-5.3.3">Section 5.3.3</a>).

   o  Utilize device lock to prevent unauthorized device access
      (<a href="#section-5.3.4">Section 5.3.4</a>).


   Attack: Steal Device:

   The host device (e.g., mobile phone) may be stolen.  In that case,
   the attacker gets access to all applications under the identity of
   the legitimate user.

   Countermeasures:

   o  Utilize device lock to prevent unauthorized device access
      (<a href="#section-5.3.4">Section 5.3.4</a>).

   o  Where a user knows the device has been stolen, they can revoke the
      affected tokens (<a href="#section-5.2.2.4">Section 5.2.2.4</a>).


   Attack: Clone Device:

   All device data and applications are copied to another device.
   Applications are used as-is on the target device.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  Utilize device lock to prevent unauthorized device access
      (<a href="#section-5.3.4">Section 5.3.4</a>).

   o  Combine refresh token request with device identification
      (<a href="#section-5.2.2.5">Section 5.2.2.5</a>).

   o  Refresh token rotation (<a href="#section-5.2.2.3">Section 5.2.2.3</a>).

   o  Where a user knows the device has been cloned, they can use
      refresh token revocation (<a href="#section-5.2.2.4">Section 5.2.2.4</a>).

<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>.  Threat: Obtaining Access Tokens</span>

   Depending on the client type, there are different ways that access
   tokens may be revealed to an attacker.  Access tokens could be stolen
   from the device if the application stores them in a storage device
   that is accessible to other applications.

   Impact: Where the token is a bearer token and no additional mechanism
   is used to identify the client, the attacker can access all resources
   associated with the token and its scope.

   Countermeasures:

   o  Keep access tokens in transient memory and limit grants
      (<a href="#section-5.1.6">Section 5.1.6</a>).

   o  Limit token scope (<a href="#section-5.1.5.1">Section 5.1.5.1</a>).

   o  Keep access tokens in private memory or apply same protection
      means as for refresh tokens (<a href="#section-5.2.2">Section 5.2.2</a>).

   o  Keep access token lifetime short (<a href="#section-5.1.5.3">Section 5.1.5.3</a>).

<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>.  Threat: End-User Credentials Phished Using Compromised or</span>
<span class="h4">        Embedded Browser</span>

   A malicious application could attempt to phish end-user passwords by
   misusing an embedded browser in the end-user authorization process,
   or by presenting its own user interface instead of allowing a trusted
   system browser to render the authorization user interface.  By doing
   so, the usual visual trust mechanisms may be bypassed (e.g.,
   Transport Layer Security (TLS) confirmation, web site mechanisms).
   By using an embedded or internal client application user interface,
   the client application has access to additional information to which
   it should not have access (e.g., UID/password).



<span class="grey">Lodderstedt, et al.           Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Impact: If the client application or the communication is
   compromised, the user would not be aware of this, and all information
   in the authorization exchange, such as username and password, could
   be captured.

   Countermeasures:

   o  The OAuth flow is designed so that client applications never need
      to know user passwords.  Client applications should avoid directly
      asking users for their credentials.  In addition, end users could
      be educated about phishing attacks and best practices, such as
      only accessing trusted clients, as OAuth does not provide any
      protection against malicious applications and the end user is
      solely responsible for the trustworthiness of any native
      application installed.

   o  Client applications could be validated prior to publication in an
      application market for users to access.  That validation is out of
      scope for OAuth but could include validating that the client
      application handles user authentication in an appropriate way.

   o  Client developers should not write client applications that
      collect authentication information directly from users and should
      instead delegate this task to a trusted system component, e.g.,
      the system browser.

<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>.  Threat: Open Redirectors on Client</span>

   An open redirector is an endpoint using a parameter to automatically
   redirect a user agent to the location specified by the parameter
   value without any validation.  If the authorization server allows the
   client to register only part of the redirect URI, an attacker can use
   an open redirector operated by the client to construct a redirect URI
   that will pass the authorization server validation but will send the
   authorization "code" or access token to an endpoint under the control
   of the attacker.

   Impact: An attacker could gain access to authorization "codes" or
   access tokens.

   Countermeasures:

   o  Require clients to register full redirect URI (<a href="#section-5.2.3.5">Section 5.2.3.5</a>).








<span class="grey">Lodderstedt, et al.           Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Authorization Endpoint</span>

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  Threat: Password Phishing by Counterfeit Authorization Server</span>

   OAuth makes no attempt to verify the authenticity of the
   authorization server.  A hostile party could take advantage of this
   by intercepting the client's requests and returning misleading or
   otherwise incorrect responses.  This could be achieved using DNS or
   Address Resolution Protocol (ARP) spoofing.  Wide deployment of OAuth
   and similar protocols may cause users to become inured to the
   practice of being redirected to web sites where they are asked to
   enter their passwords.  If users are not careful to verify the
   authenticity of these web sites before entering their credentials, it
   will be possible for attackers to exploit this practice to steal
   users' passwords.

   Countermeasures:

   o  Authorization servers should consider such attacks when developing
      services based on OAuth and should require the use of transport-
      layer security for any requests where the authenticity of the
      authorization server or of request responses is an issue (see
      <a href="#section-5.1.2">Section 5.1.2</a>).

   o  Authorization servers should attempt to educate users about the
      risks posed by phishing attacks and should provide mechanisms that
      make it easy for users to confirm the authenticity of their sites.

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  Threat: User Unintentionally Grants Too Much Access Scope</span>

   When obtaining end-user authorization, the end user may not
   understand the scope of the access being granted and to whom, or they
   may end up providing a client with access to resources that should
   not be permitted.

   Countermeasures:

   o  Explain the scope (resources and the permissions) the user is
      about to grant in an understandable way (<a href="#section-5.2.4.2">Section 5.2.4.2</a>).

   o  Narrow the scope, based on the client.  When obtaining end-user
      authorization and where the client requests scope, the
      authorization server may want to consider whether to honor that
      scope based on the client identifier.  That decision is between
      the client and authorization server and is outside the scope of
      this spec.  The authorization server may also want to consider
      what scope to grant based on the client type, e.g., providing
      lower scope to public clients (<a href="#section-5.1.5.1">Section 5.1.5.1</a>).



<span class="grey">Lodderstedt, et al.           Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h4"><a class="selflink" id="section-4.2.3" href="#section-4.2.3">4.2.3</a>.  Threat: Malicious Client Obtains Existing Authorization by Fraud</span>

   Authorization servers may wish to automatically process authorization
   requests from clients that have been previously authorized by the
   user.  When the user is redirected to the authorization server's end-
   user authorization endpoint to grant access, the authorization server
   detects that the user has already granted access to that particular
   client.  Instead of prompting the user for approval, the
   authorization server automatically redirects the user back to the
   client.

   A malicious client may exploit that feature and try to obtain such an
   authorization "code" instead of the legitimate client.

   Countermeasures:

   o  Authorization servers should not automatically process repeat
      authorizations to public clients unless the client is validated
      using a pre-registered redirect URI (<a href="#section-5.2.3.5">Section 5.2.3.5</a>).

   o  Authorization servers can mitigate the risks associated with
      automatic processing by limiting the scope of access tokens
      obtained through automated approvals (<a href="#section-5.1.5.1">Section 5.1.5.1</a>).

<span class="h4"><a class="selflink" id="section-4.2.4" href="#section-4.2.4">4.2.4</a>.  Threat: Open Redirector</span>

   An attacker could use the end-user authorization endpoint and the
   redirect URI parameter to abuse the authorization server as an open
   redirector.  An open redirector is an endpoint using a parameter to
   automatically redirect a user agent to the location specified by the
   parameter value without any validation.

   Impact: An attacker could utilize a user's trust in an authorization
   server to launch a phishing attack.

   Countermeasures:

   o  Require clients to register any full redirect URIs
      (<a href="#section-5.2.3.5">Section 5.2.3.5</a>).

   o  Don't redirect to a redirect URI if the client identifier or
      redirect URI can't be verified (<a href="#section-5.2.3.5">Section 5.2.3.5</a>).









<span class="grey">Lodderstedt, et al.           Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>.  Token Endpoint</span>

<span class="h4"><a class="selflink" id="section-4.3.1" href="#section-4.3.1">4.3.1</a>.  Threat: Eavesdropping Access Tokens</span>

   Attackers may attempt to eavesdrop access tokens in transit from the
   authorization server to the client.

   Impact: The attacker is able to access all resources with the
   permissions covered by the scope of the particular access token.

   Countermeasures:

   o  As per the core OAuth spec, the authorization servers must ensure
      that these transmissions are protected using transport-layer
      mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  If end-to-end confidentiality cannot be guaranteed, reducing scope
      (see <a href="#section-5.1.5.1">Section 5.1.5.1</a>) and expiry time (<a href="#section-5.1.5.3">Section 5.1.5.3</a>) for access
      tokens can be used to reduce the damage in case of leaks.

<span class="h4"><a class="selflink" id="section-4.3.2" href="#section-4.3.2">4.3.2</a>.  Threat: Obtaining Access Tokens from Authorization Server</span>
<span class="h4">        Database</span>

   This threat is applicable if the authorization server stores access
   tokens as handles in a database.  An attacker may obtain access
   tokens from the authorization server's database by gaining access to
   the database or launching a SQL injection attack.

   Impact: Disclosure of all access tokens.

   Countermeasures:

   o  Enforce system security measures (<a href="#section-5.1.4.1.1">Section 5.1.4.1.1</a>).

   o  Store access token hashes only (<a href="#section-5.1.4.1.3">Section 5.1.4.1.3</a>).

   o  Enforce standard SQL injection countermeasures
      (<a href="#section-5.1.4.1.2">Section 5.1.4.1.2</a>).

<span class="h4"><a class="selflink" id="section-4.3.3" href="#section-4.3.3">4.3.3</a>.  Threat: Disclosure of Client Credentials during Transmission</span>

   An attacker could attempt to eavesdrop the transmission of client
   credentials between the client and server during the client
   authentication process or during OAuth token requests.

   Impact: Revelation of a client credential enabling phishing or
   impersonation of a client service.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  The transmission of client credentials must be protected using
      transport-layer mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  Use alternative authentication means that do not require the
      sending of plaintext credentials over the wire (e.g., Hash-based
      Message Authentication Code).

<span class="h4"><a class="selflink" id="section-4.3.4" href="#section-4.3.4">4.3.4</a>.  Threat: Obtaining Client Secret from Authorization Server</span>
<span class="h4">        Database</span>

   An attacker may obtain valid "client_id"/secret combinations from the
   authorization server's database by gaining access to the database or
   launching a SQL injection attack.

   Impact: Disclosure of all "client_id"/secret combinations.  This
   allows the attacker to act on behalf of legitimate clients.

   Countermeasures:

   o  Enforce system security measures (<a href="#section-5.1.4.1.1">Section 5.1.4.1.1</a>).

   o  Enforce standard SQL injection countermeasures
      (<a href="#section-5.1.4.1.2">Section 5.1.4.1.2</a>).

   o  Ensure proper handling of credentials as per "Enforce Credential
      Storage Protection Best Practices" (<a href="#section-5.1.4.1">Section 5.1.4.1</a>).

<span class="h4"><a class="selflink" id="section-4.3.5" href="#section-4.3.5">4.3.5</a>.  Threat: Obtaining Client Secret by Online Guessing</span>

   An attacker may try to guess valid "client_id"/secret pairs.

   Impact: Disclosure of a single "client_id"/secret pair.

   Countermeasures:

   o  Use high entropy for secrets (<a href="#section-5.1.4.2.2">Section 5.1.4.2.2</a>).

   o  Lock accounts (<a href="#section-5.1.4.2.3">Section 5.1.4.2.3</a>).

   o  Use strong client authentication (<a href="#section-5.2.3.7">Section 5.2.3.7</a>).









<span class="grey">Lodderstedt, et al.           Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>.  Obtaining Authorization</span>

   This section covers threats that are specific to certain flows
   utilized to obtain access tokens.  Each flow is characterized by
   response types and/or grant types on the end-user authorization and
   token endpoint, respectively.

<span class="h4"><a class="selflink" id="section-4.4.1" href="#section-4.4.1">4.4.1</a>.  Authorization "code"</span>

<span class="h5"><a class="selflink" id="section-4.4.1.1" href="#section-4.4.1.1">4.4.1.1</a>.  Threat: Eavesdropping or Leaking Authorization "codes"</span>

   An attacker could try to eavesdrop transmission of the authorization
   "code" between the authorization server and client.  Furthermore,
   authorization "codes" are passed via the browser, which may
   unintentionally leak those codes to untrusted web sites and attackers
   in different ways:

   o  Referrer headers: Browsers frequently pass a "referer" header when
      a web page embeds content, or when a user travels from one web
      page to another web page.  These referrer headers may be sent even
      when the origin site does not trust the destination site.  The
      referrer header is commonly logged for traffic analysis purposes.

   o  Request logs: Web server request logs commonly include query
      parameters on requests.

   o  Open redirectors: Web sites sometimes need to send users to
      another destination via a redirector.  Open redirectors pose a
      particular risk to web-based delegation protocols because the
      redirector can leak verification codes to untrusted destination
      sites.

   o  Browser history: Web browsers commonly record visited URLs in the
      browser history.  Another user of the same web browser may be able
      to view URLs that were visited by previous users.

   Note: A description of similar attacks on the SAML protocol can be
   found at [<a href="#ref-OASIS.sstc-saml-bindings-1.1">OASIS.sstc-saml-bindings-1.1</a>], Section 4.1.1.9.1;
   [<a href="#ref-Sec-Analysis">Sec-Analysis</a>]; and [<a href="#ref-OASIS.sstc-sec-analysis-response-01">OASIS.sstc-sec-analysis-response-01</a>].












<span class="grey">Lodderstedt, et al.           Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  As per the core OAuth spec, the authorization server as well as
      the client must ensure that these transmissions are protected
      using transport-layer mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  The authorization server will require the client to authenticate
      wherever possible, so the binding of the authorization "code" to a
      certain client can be validated in a reliable way (see
      <a href="#section-5.2.4.4">Section 5.2.4.4</a>).

   o  Use short expiry time for authorization "codes" (<a href="#section-5.1.5.3">Section 5.1.5.3</a>).

   o  The authorization server should enforce a one-time usage
      restriction (see <a href="#section-5.1.5.4">Section 5.1.5.4</a>).

   o  If an authorization server observes multiple attempts to redeem an
      authorization "code", the authorization server may want to revoke
      all tokens granted based on the authorization "code" (see
      <a href="#section-5.2.1.1">Section 5.2.1.1</a>).

   o  In the absence of these countermeasures, reducing scope
      (<a href="#section-5.1.5.1">Section 5.1.5.1</a>) and expiry time (<a href="#section-5.1.5.3">Section 5.1.5.3</a>) for access
      tokens can be used to reduce the damage in case of leaks.

   o  The client server may reload the target page of the redirect URI
      in order to automatically clean up the browser cache.

<span class="h5"><a class="selflink" id="section-4.4.1.2" href="#section-4.4.1.2">4.4.1.2</a>.  Threat: Obtaining Authorization "codes" from Authorization</span>
<span class="h5">          Server Database</span>

   This threat is applicable if the authorization server stores
   authorization "codes" as handles in a database.  An attacker may
   obtain authorization "codes" from the authorization server's database
   by gaining access to the database or launching a SQL injection
   attack.

   Impact: Disclosure of all authorization "codes", most likely along
   with the respective "redirect_uri" and "client_id" values.

   Countermeasures:

   o  Best practices for credential storage protection should be
      employed (<a href="#section-5.1.4.1">Section 5.1.4.1</a>).

   o  Enforce system security measures (<a href="#section-5.1.4.1.1">Section 5.1.4.1.1</a>).





<span class="grey">Lodderstedt, et al.           Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Store access token hashes only (<a href="#section-5.1.4.1.3">Section 5.1.4.1.3</a>).

   o  Enforce standard SQL injection countermeasures
      (<a href="#section-5.1.4.1.2">Section 5.1.4.1.2</a>).

<span class="h5"><a class="selflink" id="section-4.4.1.3" href="#section-4.4.1.3">4.4.1.3</a>.  Threat: Online Guessing of Authorization "codes"</span>

   An attacker may try to guess valid authorization "code" values and
   send the guessed code value using the grant type "code" in order to
   obtain a valid access token.

   Impact: Disclosure of a single access token and probably also an
   associated refresh token.

   Countermeasures:

   o  Handle-based tokens must use high entropy (<a href="#section-5.1.4.2.2">Section 5.1.4.2.2</a>).

   o  Assertion-based tokens should be signed (<a href="#section-5.1.5.9">Section 5.1.5.9</a>).

   o  Authenticate the client; this adds another value that the attacker
      has to guess (<a href="#section-5.2.3.4">Section 5.2.3.4</a>).

   o  Bind the authorization "code" to the redirect URI; this adds
      another value that the attacker has to guess (<a href="#section-5.2.4.5">Section 5.2.4.5</a>).

   o  Use short expiry time for tokens (<a href="#section-5.1.5.3">Section 5.1.5.3</a>).

<span class="h5"><a class="selflink" id="section-4.4.1.4" href="#section-4.4.1.4">4.4.1.4</a>.  Threat: Malicious Client Obtains Authorization</span>

   A malicious client could pretend to be a valid client and obtain an
   access authorization in this way.  The malicious client could even
   utilize screen-scraping techniques in order to simulate a user's
   consent in the authorization flow.

   Assumption: It is not the task of the authorization server to protect
   the end-user's device from malicious software.  This is the
   responsibility of the platform running on the particular device,
   probably in cooperation with other components of the respective
   ecosystem (e.g., an application management infrastructure).  The sole
   responsibility of the authorization server is to control access to
   the end-user's resources maintained in resource servers and to
   prevent unauthorized access to them via the OAuth protocol.  Based on
   this assumption, the following countermeasures are available to cope
   with the threat.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  The authorization server should authenticate the client, if
      possible (see <a href="#section-5.2.3.4">Section 5.2.3.4</a>).  Note: The authentication takes
      place after the end user has authorized the access.

   o  The authorization server should validate the client's redirect URI
      against the pre-registered redirect URI, if one exists (see
      <a href="#section-5.2.3.5">Section 5.2.3.5</a>).  Note: An invalid redirect URI indicates an
      invalid client, whereas a valid redirect URI does not necessarily
      indicate a valid client.  The level of confidence depends on the
      client type.  For web applications, the level of confidence is
      high, since the redirect URI refers to the globally unique network
      endpoint of this application, whose fully qualified domain name
      (FQDN) is also validated using HTTPS server authentication by the
      user agent.  In contrast, for native clients, the redirect URI
      typically refers to device local resources, e.g., a custom scheme.
      So, a malicious client on a particular device can use the valid
      redirect URI the legitimate client uses on all other devices.

   o  After authenticating the end user, the authorization server should
      ask him/her for consent.  In this context, the authorization
      server should explain to the end user the purpose, scope, and
      duration of the authorization the client asked for.  Moreover, the
      authorization server should show the user any identity information
      it has for that client.  It is up to the user to validate the
      binding of this data to the particular application (e.g., Name)
      and to approve the authorization request (see <a href="#section-5.2.4.3">Section 5.2.4.3</a>).

   o  The authorization server should not perform automatic
      re-authorizations for clients it is unable to reliably
      authenticate or validate (see <a href="#section-5.2.4.1">Section 5.2.4.1</a>).

   o  If the authorization server automatically authenticates the end
      user, it may nevertheless require some user input in order to
      prevent screen scraping.  Examples are CAPTCHAs (Completely
      Automated Public Turing tests to tell Computers and Humans Apart)
      or other multi-factor authentication techniques such as random
      questions, token code generators, etc.

   o  The authorization server may also limit the scope of tokens it
      issues to clients it cannot reliably authenticate (see
      <a href="#section-5.1.5.1">Section 5.1.5.1</a>).








<span class="grey">Lodderstedt, et al.           Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-4.4.1.5" href="#section-4.4.1.5">4.4.1.5</a>.  Threat: Authorization "code" Phishing</span>

   A hostile party could impersonate the client site and get access to
   the authorization "code".  This could be achieved using DNS or ARP
   spoofing.  This applies to clients, which are web applications; thus,
   the redirect URI is not local to the host where the user's browser is
   running.

   Impact: This affects web applications and may lead to a disclosure of
   authorization "codes" and, potentially, the corresponding access and
   refresh tokens.

   Countermeasures:

   It is strongly recommended that one of the following countermeasures
   be utilized in order to prevent this attack:

   o  The redirect URI of the client should point to an HTTPS-protected
      endpoint, and the browser should be utilized to authenticate this
      redirect URI using server authentication (see <a href="#section-5.1.2">Section 5.1.2</a>).

   o  The authorization server should require that the client be
      authenticated, i.e., confidential client, so the binding of the
      authorization "code" to a certain client can be validated in a
      reliable way (see <a href="#section-5.2.4.4">Section 5.2.4.4</a>).

<span class="h5"><a class="selflink" id="section-4.4.1.6" href="#section-4.4.1.6">4.4.1.6</a>.  Threat: User Session Impersonation</span>

   A hostile party could impersonate the client site and impersonate the
   user's session on this client.  This could be achieved using DNS or
   ARP spoofing.  This applies to clients, which are web applications;
   thus, the redirect URI is not local to the host where the user's
   browser is running.

   Impact: An attacker who intercepts the authorization "code" as it is
   sent by the browser to the callback endpoint can gain access to
   protected resources by submitting the authorization "code" to the
   client.  The client will exchange the authorization "code" for an
   access token and use the access token to access protected resources
   for the benefit of the attacker, delivering protected resources to
   the attacker, or modifying protected resources as directed by the
   attacker.  If OAuth is used by the client to delegate authentication
   to a social site (e.g., as in the implementation of a "Login" button
   on a third-party social network site), the attacker can use the
   intercepted authorization "code" to log into the client as the user.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Note: Authenticating the client during authorization "code" exchange
   will not help to detect such an attack, as it is the legitimate
   client that obtains the tokens.

   Countermeasures:

   o  In order to prevent an attacker from impersonating the end-user's
      session, the redirect URI of the client should point to an HTTPS
      protected endpoint, and the browser should be utilized to
      authenticate this redirect URI using server authentication (see
      <a href="#section-5.1.2">Section 5.1.2</a>).

<span class="h5"><a class="selflink" id="section-4.4.1.7" href="#section-4.4.1.7">4.4.1.7</a>.  Threat: Authorization "code" Leakage through Counterfeit</span>
<span class="h5">          Client</span>

   The attacker leverages the authorization "code" grant type in an
   attempt to get another user (victim) to log in, authorize access to
   his/her resources, and subsequently obtain the authorization "code"
   and inject it into a client application using the attacker's account.
   The goal is to associate an access authorization for resources of the
   victim with the user account of the attacker on a client site.

   The attacker abuses an existing client application and combines it
   with his own counterfeit client web site.  The attacker depends on
   the victim expecting the client application to request access to a
   certain resource server.  The victim, seeing only a normal request
   from an expected application, approves the request.  The attacker
   then uses the victim's authorization to gain access to the
   information unknowingly authorized by the victim.

   The attacker conducts the following flow:

   1.  The attacker accesses the client web site (or application) and
       initiates data access to a particular resource server.  The
       client web site in turn initiates an authorization request to the
       resource server's authorization server.  Instead of proceeding
       with the authorization process, the attacker modifies the
       authorization server end-user authorization URL as constructed by
       the client to include a redirect URI parameter referring to a web
       site under his control (attacker's web site).

   2.  The attacker tricks another user (the victim) into opening that
       modified end-user authorization URI and authorizing access (e.g.,
       via an email link or blog link).  The way the attacker achieves
       this goal is out of scope.

   3.  Having clicked the link, the victim is requested to authenticate
       and authorize the client site to have access.



<span class="grey">Lodderstedt, et al.           Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   4.  After completion of the authorization process, the authorization
       server redirects the user agent to the attacker's web site
       instead of the original client web site.

   5.  The attacker obtains the authorization "code" from his web site
       by means that are out of scope of this document.

   6.  He then constructs a redirect URI to the target web site (or
       application) based on the original authorization request's
       redirect URI and the newly obtained authorization "code", and
       directs his user agent to this URL.  The authorization "code" is
       injected into the original client site (or application).

   7.  The client site uses the authorization "code" to fetch a token
       from the authorization server and associates this token with the
       attacker's user account on this site.

   8.  The attacker may now access the victim's resources using the
       client site.

   Impact: The attacker gains access to the victim's resources as
   associated with his account on the client site.

   Countermeasures:

   o  The attacker will need to use another redirect URI for its
      authorization process rather than the target web site because it
      needs to intercept the flow.  So, if the authorization server
      associates the authorization "code" with the redirect URI of a
      particular end-user authorization and validates this redirect URI
      with the redirect URI passed to the token's endpoint, such an
      attack is detected (see <a href="#section-5.2.4.5">Section 5.2.4.5</a>).

   o  The authorization server may also enforce the usage and validation
      of pre-registered redirect URIs (see <a href="#section-5.2.3.5">Section 5.2.3.5</a>).  This will
      allow for early recognition of authorization "code" disclosure to
      counterfeit clients.

   o  For native applications, one could also consider using deployment-
      specific client ids and secrets (see <a href="#section-5.2.3.4">Section 5.2.3.4</a>), along with
      the binding of authorization "codes" to "client_ids" (see
      <a href="#section-5.2.4.4">Section 5.2.4.4</a>) to detect such an attack because the attacker
      does not have access to the deployment-specific secret.  Thus, he
      will not be able to exchange the authorization "code".







<span class="grey">Lodderstedt, et al.           Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  The client may consider using other flows that are not vulnerable
      to this kind of attack, such as the implicit grant type (see
      <a href="#section-4.4.2">Section 4.4.2</a>) or resource owner password credentials (see
      <a href="#section-4.4.3">Section 4.4.3</a>).

<span class="h5"><a class="selflink" id="section-4.4.1.8" href="#section-4.4.1.8">4.4.1.8</a>.  Threat: CSRF Attack against redirect-uri</span>

   Cross-site request forgery (CSRF) is a web-based attack whereby HTTP
   requests are transmitted from a user that the web site trusts or has
   authenticated (e.g., via HTTP redirects or HTML forms).  CSRF attacks
   on OAuth approvals can allow an attacker to obtain authorization to
   OAuth protected resources without the consent of the user.

   This attack works against the redirect URI used in the authorization
   "code" flow.  An attacker could authorize an authorization "code" to
   their own protected resources on an authorization server.  He then
   aborts the redirect flow back to the client on his device and tricks
   the victim into executing the redirect back to the client.  The
   client receives the redirect, fetches the token(s) from the
   authorization server, and associates the victim's client session with
   the resources accessible using the token.

   Impact: The user accesses resources on behalf of the attacker.  The
   effective impact depends on the type of resource accessed.  For
   example, the user may upload private items to an attacker's
   resources.  Or, when using OAuth in 3rd-party login scenarios, the
   user may associate his client account with the attacker's identity at
   the external Identity Provider.  In this way, the attacker could
   easily access the victim's data at the client by logging in from
   another device with his credentials at the external Identity
   Provider.

   Countermeasures:

   o  The "state" parameter should be used to link the authorization
      request with the redirect URI used to deliver the access token
      (<a href="#section-5.3.5">Section 5.3.5</a>).

   o  Client developers and end users can be educated to not follow
      untrusted URLs.











<span class="grey">Lodderstedt, et al.           Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-4.4.1.9" href="#section-4.4.1.9">4.4.1.9</a>.  Threat: Clickjacking Attack against Authorization</span>

   With clickjacking, a malicious site loads the target site in a
   transparent iFrame (see [<a href="#ref-iFrame" title="&quot;Frames in HTML documents&quot;">iFrame</a>]) overlaid on top of a set of dummy
   buttons that are carefully constructed to be placed directly under
   important buttons on the target site.  When a user clicks a visible
   button, they are actually clicking a button (such as an "Authorize"
   button) on the hidden page.

   Impact: An attacker can steal a user's authentication credentials and
   access their resources.

   Countermeasures:

   o  For newer browsers, avoidance of iFrames during authorization can
      be enforced on the server side by using the X-FRAME-OPTIONS header
      (<a href="#section-5.2.2.6">Section 5.2.2.6</a>).

   o  For older browsers, JavaScript frame-busting (see [<a href="#ref-Framebusting">Framebusting</a>])
      techniques can be used but may not be effective in all browsers.

<span class="h5"><a class="selflink" id="section-4.4.1.10" href="#section-4.4.1.10">4.4.1.10</a>.  Threat: Resource Owner Impersonation</span>

   When a client requests access to protected resources, the
   authorization flow normally involves the resource owner's explicit
   response to the access request, either granting or denying access to
   the protected resources.  A malicious client can exploit knowledge of
   the structure of this flow in order to gain authorization without the
   resource owner's consent, by transmitting the necessary requests
   programmatically and simulating the flow against the authorization
   server.  That way, the client may gain access to the victim's
   resources without her approval.  An authorization server will be
   vulnerable to this threat if it uses non-interactive authentication
   mechanisms or splits the authorization flow across multiple pages.

   The malicious client might embed a hidden HTML user agent, interpret
   the HTML forms sent by the authorization server, and automatically
   send the corresponding form HTTP POST requests.  As a prerequisite,
   the attacker must be able to execute the authorization process in the
   context of an already-authenticated session of the resource owner
   with the authorization server.  There are different ways to achieve
   this:

   o  The malicious client could abuse an existing session in an
      external browser or cross-browser cookies on the particular
      device.





<span class="grey">Lodderstedt, et al.           Informational                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  The malicious client could also request authorization for an
      initial scope acceptable to the user and then silently abuse the
      resulting session in his browser instance to "silently" request
      another scope.

   o  Alternatively, the attacker might exploit an authorization
      server's ability to authenticate the resource owner automatically
      and without user interactions, e.g., based on certificates.

   In all cases, such an attack is limited to clients running on the
   victim's device, either within the user agent or as a native app.

   Please note: Such attacks cannot be prevented using CSRF
   countermeasures, since the attacker just "executes" the URLs as
   prepared by the authorization server including any nonce, etc.

   Countermeasures:

   Authorization servers should decide, based on an analysis of the risk
   associated with this threat, whether to detect and prevent this
   threat.

   In order to prevent such an attack, the authorization server may
   force a user interaction based on non-predictable input values as
   part of the user consent approval.  The authorization server could

   o  combine password authentication and user consent in a single form,

   o  make use of CAPTCHAs, or

   o  use one-time secrets sent out of band to the resource owner (e.g.,
      via text or instant message).

   Alternatively, in order to allow the resource owner to detect abuse,
   the authorization server could notify the resource owner of any
   approval by appropriate means, e.g., text or instant message, or
   email.

<span class="h5"><a class="selflink" id="section-4.4.1.11" href="#section-4.4.1.11">4.4.1.11</a>.  Threat: DoS Attacks That Exhaust Resources</span>

   If an authorization server includes a nontrivial amount of entropy in
   authorization "codes" or access tokens (limiting the number of
   possible codes/tokens) and automatically grants either without user
   intervention and has no limit on codes or access tokens per user, an
   attacker could exhaust the pool of authorization "codes" by
   repeatedly directing the user's browser to request authorization
   "codes" or access tokens.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  The authorization server should consider limiting the number of
      access tokens granted per user.

   o  The authorization server should include a nontrivial amount of
      entropy in authorization "codes".

<span class="h5"><a class="selflink" id="section-4.4.1.12" href="#section-4.4.1.12">4.4.1.12</a>.  Threat: DoS Using Manufactured Authorization "codes"</span>

   An attacker who owns a botnet can locate the redirect URIs of clients
   that listen on HTTP, access them with random authorization "codes",
   and cause a large number of HTTPS connections to be concentrated onto
   the authorization server.  This can result in a denial-of-service
   (DoS) attack on the authorization server.

   This attack can still be effective even when CSRF defense/the "state"
   parameter (see <a href="#section-4.4.1.8">Section 4.4.1.8</a>) is deployed on the client side.  With
   such a defense, the attacker might need to incur an additional HTTP
   request to obtain a valid CSRF code/"state" parameter.  This
   apparently cuts down the effectiveness of the attack by a factor of
   2.  However, if the HTTPS/HTTP cost ratio is higher than 2 (the cost
   factor is estimated to be around 3.5x at [<a href="#ref-SSL-Latency">SSL-Latency</a>]), the attacker
   still achieves a magnification of resource utilization at the expense
   of the authorization server.

   Impact: There are a few effects that the attacker can accomplish with
   this OAuth flow that they cannot easily achieve otherwise.

   1.  Connection laundering: With the clients as the relay between the
       attacker and the authorization server, the authorization server
       learns little or no information about the identity of the
       attacker.  Defenses such as rate-limiting on the offending
       attacker machines are less effective because it is difficult to
       identify the attacking machines.  Although an attacker could also
       launder its connections through an anonymizing system such as
       Tor, the effectiveness of that approach depends on the capacity
       of the anonymizing system.  On the other hand, a potentially
       large number of OAuth clients could be utilized for this attack.

   2.  Asymmetric resource utilization: The attacker incurs the cost of
       an HTTP connection and causes an HTTPS connection to be made on
       the authorization server; the attacker can coordinate the timing
       of such HTTPS connections across multiple clients relatively
       easily.  Although the attacker could achieve something similar,
       say, by including an iFrame pointing to the HTTPS URL of the
       authorization server in an HTTP web page and luring web users to
       visit that page, timing attacks using such a scheme may be more



<span class="grey">Lodderstedt, et al.           Informational                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


       difficult, as it seems nontrivial to synchronize a large number
       of users to simultaneously visit a particular site under the
       attacker's control.

   Countermeasures:

   o  Though not a complete countermeasure by themselves, CSRF defense
      and the "state" parameter created with secure random codes should
      be deployed on the client side.  The client should forward the
      authorization "code" to the authorization server only after both
      the CSRF token and the "state" parameter are validated.

   o  If the client authenticates the user, either through a single-
      sign-on protocol or through local authentication, the client
      should suspend the access by a user account if the number of
      invalid authorization "codes" submitted by this user exceeds a
      certain threshold.

   o  The authorization server should send an error response to the
      client reporting an invalid authorization "code" and rate-limit or
      disallow connections from clients whose number of invalid requests
      exceeds a threshold.

<span class="h5"><a class="selflink" id="section-4.4.1.13" href="#section-4.4.1.13">4.4.1.13</a>.  Threat: Code Substitution (OAuth Login)</span>

   An attacker could attempt to log into an application or web site
   using a victim's identity.  Applications relying on identity data
   provided by an OAuth protected service API to login users are
   vulnerable to this threat.  This pattern can be found in so-called
   "social login" scenarios.

   As a prerequisite, a resource server offers an API to obtain personal
   information about a user that could be interpreted as having obtained
   a user identity.  In this sense, the client is treating the resource
   server API as an "identity" API.  A client utilizes OAuth to obtain
   an access token for the identity API.  It then queries the identity
   API for an identifier and uses it to look up its internal user
   account data (login).  The client assumes that, because it was able
   to obtain information about the user, the user has been
   authenticated.

   If the client uses the grant type "code", the attacker needs to
   gather a valid authorization "code" of the respective victim from the
   same Identity Provider used by the target client application.  The
   attacker tricks the victim into logging into a malicious app (which
   may appear to be legitimate to the Identity Provider) using the same
   Identity Provider as the target application.  This results in the
   Identity Provider's authorization server issuing an authorization



<span class="grey">Lodderstedt, et al.           Informational                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   "code" for the respective identity API.  The malicious app then sends
   this code to the attacker, which in turn triggers a login process
   within the target application.  The attacker now manipulates the
   authorization response and substitutes their code (bound to their
   identity) for the victim's code.  This code is then exchanged by the
   client for an access token, which in turn is accepted by the identity
   API, since the audience, with respect to the resource server, is
   correct.  But since the identifier returned by the identity API is
   determined by the identity in the access token (issued based on the
   victim's code), the attacker is logged into the target application
   under the victim's identity.

   Impact: The attacker gains access to an application and user-specific
   data within the application.

   Countermeasures:

   o  All clients must indicate their client ids with every request to
      exchange an authorization "code" for an access token.  The
      authorization server must validate whether the particular
      authorization "code" has been issued to the particular client.  If
      possible, the client shall be authenticated beforehand.

   o  Clients should use an appropriate protocol, such as OpenID (cf.
      [<a href="#ref-OPENID" title="&quot;OpenID Foundation Home Page&quot;">OPENID</a>]) or SAML (cf. [<a href="#ref-OASIS.sstc-saml-bindings-1.1">OASIS.sstc-saml-bindings-1.1</a>]) to
      implement user login.  Both support audience restrictions on
      clients.

<span class="h4"><a class="selflink" id="section-4.4.2" href="#section-4.4.2">4.4.2</a>.  Implicit Grant</span>

   In the implicit grant type flow, the access token is directly
   returned to the client as a fragment part of the redirect URI.  It is
   assumed that the token is not sent to the redirect URI target, as
   HTTP user agents do not send the fragment part of URIs to HTTP
   servers.  Thus, an attacker cannot eavesdrop the access token on this
   communication path, and the token cannot leak through HTTP referrer
   headers.

<span class="h5"><a class="selflink" id="section-4.4.2.1" href="#section-4.4.2.1">4.4.2.1</a>.  Threat: Access Token Leak in Transport/Endpoints</span>

   This token might be eavesdropped by an attacker.  The token is sent
   from the server to the client via a URI fragment of the redirect URI.
   If the communication is not secured or the endpoint is not secured,
   the token could be leaked by parsing the returned URI.

   Impact: The attacker would be able to assume the same rights granted
   by the token.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  The authorization server should ensure confidentiality (e.g.,
      using TLS) of the response from the authorization server to the
      client (see <a href="#section-5.1.1">Section 5.1.1</a>).

<span class="h5"><a class="selflink" id="section-4.4.2.2" href="#section-4.4.2.2">4.4.2.2</a>.  Threat: Access Token Leak in Browser History</span>

   An attacker could obtain the token from the browser's history.  Note
   that this means the attacker needs access to the particular device.

   Countermeasures:

   o  Use short expiry time for tokens (see <a href="#section-5.1.5.3">Section 5.1.5.3</a>).  Reduced
      scope of the token may reduce the impact of that attack (see
      <a href="#section-5.1.5.1">Section 5.1.5.1</a>).

   o  Make responses non-cacheable.

<span class="h5"><a class="selflink" id="section-4.4.2.3" href="#section-4.4.2.3">4.4.2.3</a>.  Threat: Malicious Client Obtains Authorization</span>

   A malicious client could attempt to obtain a token by fraud.

   The same countermeasures as for <a href="#section-4.4.1.4">Section 4.4.1.4</a> are applicable,
   except client authentication.

<span class="h5"><a class="selflink" id="section-4.4.2.4" href="#section-4.4.2.4">4.4.2.4</a>.  Threat: Manipulation of Scripts</span>

   A hostile party could act as the client web server and replace or
   modify the actual implementation of the client (script).  This could
   be achieved using DNS or ARP spoofing.  This applies to clients
   implemented within the web browser in a scripting language.

   Impact: The attacker could obtain user credential information and
   assume the full identity of the user.

   Countermeasures:

   o  The authorization server should authenticate the server from which
      scripts are obtained (see <a href="#section-5.1.2">Section 5.1.2</a>).

   o  The client should ensure that scripts obtained have not been
      altered in transport (see <a href="#section-5.1.1">Section 5.1.1</a>).








<span class="grey">Lodderstedt, et al.           Informational                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Introduce one-time, per-use secrets (e.g., "client_secret") values
      that can only be used by scripts in a small time window once
      loaded from a server.  The intention would be to reduce the
      effectiveness of copying client-side scripts for re-use in an
      attacker's modified code.

<span class="h5"><a class="selflink" id="section-4.4.2.5" href="#section-4.4.2.5">4.4.2.5</a>.  Threat: CSRF Attack against redirect-uri</span>

   CSRF attacks (see <a href="#section-4.4.1.8">Section 4.4.1.8</a>) also work against the redirect URI
   used in the implicit grant flow.  An attacker could acquire an access
   token to their own protected resources.  He could then construct a
   redirect URI and embed their access token in that URI.  If he can
   trick the user into following the redirect URI and the client does
   not have protection against this attack, the user may have the
   attacker's access token authorized within their client.

   Impact: The user accesses resources on behalf of the attacker.  The
   effective impact depends on the type of resource accessed.  For
   example, the user may upload private items to an attacker's
   resources.  Or, when using OAuth in 3rd-party login scenarios, the
   user may associate his client account with the attacker's identity at
   the external Identity Provider.  In this way, the attacker could
   easily access the victim's data at the client by logging in from
   another device with his credentials at the external Identity
   Provider.

   Countermeasures:

   o  The "state" parameter should be used to link the authorization
      request with the redirect URI used to deliver the access token.
      This will ensure that the client is not tricked into completing
      any redirect callback unless it is linked to an authorization
      request initiated by the client.  The "state" parameter should not
      be guessable, and the client should be capable of keeping the
      "state" parameter secret.

   o  Client developers and end users can be educated to not follow
      untrusted URLs.

<span class="h5"><a class="selflink" id="section-4.4.2.6" href="#section-4.4.2.6">4.4.2.6</a>.  Threat: Token Substitution (OAuth Login)</span>

   An attacker could attempt to log into an application or web site
   using a victim's identity.  Applications relying on identity data
   provided by an OAuth protected service API to login users are
   vulnerable to this threat.  This pattern can be found in so-called
   "social login" scenarios.





<span class="grey">Lodderstedt, et al.           Informational                    [Page 39]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-40" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   As a prerequisite, a resource server offers an API to obtain personal
   information about a user that could be interpreted as having obtained
   a user identity.  In this sense, the client is treating the resource
   server API as an "identity" API.  A client utilizes OAuth to obtain
   an access token for the identity API.  It then queries the identity
   API for an identifier and uses it to look up its internal user
   account data (login).  The client assumes that, because it was able
   to obtain information about the user, the user has been
   authenticated.

   To succeed, the attacker needs to gather a valid access token of the
   respective victim from the same Identity Provider used by the target
   client application.  The attacker tricks the victim into logging into
   a malicious app (which may appear to be legitimate to the Identity
   Provider) using the same Identity Provider as the target application.
   This results in the Identity Provider's authorization server issuing
   an access token for the respective identity API.  The malicious app
   then sends this access token to the attacker, which in turn triggers
   a login process within the target application.  The attacker now
   manipulates the authorization response and substitutes their access
   token (bound to their identity) for the victim's access token.  This
   token is accepted by the identity API, since the audience, with
   respect to the resource server, is correct.  But since the identifier
   returned by the identity API is determined by the identity in the
   access token, the attacker is logged into the target application
   under the victim's identity.

   Impact: The attacker gains access to an application and user-specific
   data within the application.

   Countermeasures:

   o  Clients should use an appropriate protocol, such as OpenID (cf.
      [<a href="#ref-OPENID" title="&quot;OpenID Foundation Home Page&quot;">OPENID</a>]) or SAML (cf. [<a href="#ref-OASIS.sstc-saml-bindings-1.1">OASIS.sstc-saml-bindings-1.1</a>]) to
      implement user login.  Both support audience restrictions on
      clients.

<span class="h4"><a class="selflink" id="section-4.4.3" href="#section-4.4.3">4.4.3</a>.  Resource Owner Password Credentials</span>

   The resource owner password credentials grant type (see <a href="./rfc6749#section-4.3">[RFC6749],
   Section&nbsp;4.3</a>), often used for legacy/migration reasons, allows a
   client to request an access token using an end-user's user id and
   password along with its own credential.  This grant type has higher
   risk because it maintains the UID/password anti-pattern.
   Additionally, because the user does not have control over the
   authorization process, clients using this grant type are not limited





<span class="grey">Lodderstedt, et al.           Informational                    [Page 40]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-41" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   by scope but instead have potentially the same capabilities as the
   user themselves.  As there is no authorization step, the ability to
   offer token revocation is bypassed.

   Because passwords are often used for more than 1 service, this
   anti-pattern may also put at risk whatever else is accessible with
   the supplied credential.  Additionally, any easily derived equivalent
   (e.g., joe@example.com and joe@example.net) might easily allow
   someone to guess that the same password can be used elsewhere.

   Impact: The resource server can only differentiate scope based on the
   access token being associated with a particular client.  The client
   could also acquire long-lived tokens and pass them up to an
   attacker's web service for further abuse.  The client, eavesdroppers,
   or endpoints could eavesdrop the user id and password.

   Countermeasures:

   o  Except for migration reasons, minimize use of this grant type.

   o  The authorization server should validate the client id associated
      with the particular refresh token with every refresh request
      (<a href="#section-5.2.2.2">Section 5.2.2.2</a>).

   o  As per the core OAuth specification, the authorization server must
      ensure that these transmissions are protected using transport-
      layer mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  Rather than encouraging users to use a UID and password, service
      providers should instead encourage users not to use the same
      password for multiple services.

   o  Limit use of resource owner password credential grants to
      scenarios where the client application and the authorizing service
      are from the same organization.

<span class="h5"><a class="selflink" id="section-4.4.3.1" href="#section-4.4.3.1">4.4.3.1</a>.  Threat: Accidental Exposure of Passwords at Client Site</span>

   If the client does not provide enough protection, an attacker or
   disgruntled employee could retrieve the passwords for a user.

   Countermeasures:

   o  Use other flows that do not rely on the client's cooperation for
      secure resource owner credential handling.

   o  Use digest authentication instead of plaintext credential
      processing.



<span class="grey">Lodderstedt, et al.           Informational                    [Page 41]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-42" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Obfuscate passwords in logs.

<span class="h5"><a class="selflink" id="section-4.4.3.2" href="#section-4.4.3.2">4.4.3.2</a>.  Threat: Client Obtains Scopes without End-User Authorization</span>

   All interaction with the resource owner is performed by the client.
   Thus it might, intentionally or unintentionally, happen that the
   client obtains a token with scope unknown for, or unintended by, the
   resource owner.  For example, the resource owner might think the
   client needs and acquires read-only access to its media storage only
   but the client tries to acquire an access token with full access
   permissions.

   Countermeasures:

   o  Use other flows that do not rely on the client's cooperation for
      resource owner interaction.

   o  The authorization server may generally restrict the scope of
      access tokens (<a href="#section-5.1.5.1">Section 5.1.5.1</a>) issued by this flow.  If the
      particular client is trustworthy and can be authenticated in a
      reliable way, the authorization server could relax that
      restriction.  Resource owners may prescribe (e.g., in their
      preferences) what the maximum scope is for clients using this
      flow.

   o  The authorization server could notify the resource owner by an
      appropriate medium, e.g., email, of the grant issued (see
      <a href="#section-5.1.3">Section 5.1.3</a>).

<span class="h5"><a class="selflink" id="section-4.4.3.3" href="#section-4.4.3.3">4.4.3.3</a>.  Threat: Client Obtains Refresh Token through Automatic</span>
<span class="h5">          Authorization</span>

   All interaction with the resource owner is performed by the client.
   Thus it might, intentionally or unintentionally, happen that the
   client obtains a long-term authorization represented by a refresh
   token even if the resource owner did not intend so.

   Countermeasures:

   o  Use other flows that do not rely on the client's cooperation for
      resource owner interaction.

   o  The authorization server may generally refuse to issue refresh
      tokens in this flow (see <a href="#section-5.2.2.1">Section 5.2.2.1</a>).  If the particular
      client is trustworthy and can be authenticated in a reliable way
      (see client authentication), the authorization server could relax





<span class="grey">Lodderstedt, et al.           Informational                    [Page 42]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-43" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


      that restriction.  Resource owners may allow or deny (e.g., in
      their preferences) the issuing of refresh tokens using this flow
      as well.

   o  The authorization server could notify the resource owner by an
      appropriate medium, e.g., email, of the refresh token issued (see
      <a href="#section-5.1.3">Section 5.1.3</a>).

<span class="h5"><a class="selflink" id="section-4.4.3.4" href="#section-4.4.3.4">4.4.3.4</a>.  Threat: Obtaining User Passwords on Transport</span>

   An attacker could attempt to eavesdrop the transmission of end-user
   credentials with the grant type "password" between the client and
   server.

   Impact: Disclosure of a single end-user's password.

   Countermeasures:

   o  Ensure confidentiality of requests (<a href="#section-5.1.1">Section 5.1.1</a>).

   o  Use alternative authentication means that do not require the
      sending of plaintext credentials over the wire (e.g., Hash-based
      Message Authentication Code).

<span class="h5"><a class="selflink" id="section-4.4.3.5" href="#section-4.4.3.5">4.4.3.5</a>.  Threat: Obtaining User Passwords from Authorization Server</span>
<span class="h5">          Database</span>

   An attacker may obtain valid username/password combinations from the
   authorization server's database by gaining access to the database or
   launching a SQL injection attack.

   Impact: Disclosure of all username/password combinations.  The impact
   may exceed the domain of the authorization server, since many users
   tend to use the same credentials on different services.

   Countermeasures:

   o  Enforce credential storage protection best practices
      (<a href="#section-5.1.4.1">Section 5.1.4.1</a>).

<span class="h5"><a class="selflink" id="section-4.4.3.6" href="#section-4.4.3.6">4.4.3.6</a>.  Threat: Online Guessing</span>

   An attacker may try to guess valid username/password combinations
   using the grant type "password".

   Impact: Revelation of a single username/password combination.





<span class="grey">Lodderstedt, et al.           Informational                    [Page 43]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-44" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  Utilize secure password policy (<a href="#section-5.1.4.2.1">Section 5.1.4.2.1</a>).

   o  Lock accounts (<a href="#section-5.1.4.2.3">Section 5.1.4.2.3</a>).

   o  Use tar pit (<a href="#section-5.1.4.2.4">Section 5.1.4.2.4</a>).

   o  Use CAPTCHAs (<a href="#section-5.1.4.2.5">Section 5.1.4.2.5</a>).

   o  Consider not using the grant type "password".

   o  Client authentication (see <a href="#section-5.2.3">Section 5.2.3</a>) will provide another
      authentication factor and thus hinder the attack.

<span class="h4"><a class="selflink" id="section-4.4.4" href="#section-4.4.4">4.4.4</a>.  Client Credentials</span>

   Client credentials (see <a href="./rfc6749#section-3">[RFC6749], Section&nbsp;3</a>) consist of an
   identifier (not secret) combined with an additional means (such as a
   matching client secret) of authenticating a client.  The threats to
   this grant type are similar to those described in <a href="#section-4.4.3">Section 4.4.3</a>.

<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>.  Refreshing an Access Token</span>

<span class="h4"><a class="selflink" id="section-4.5.1" href="#section-4.5.1">4.5.1</a>.  Threat: Eavesdropping Refresh Tokens from Authorization Server</span>

   An attacker may eavesdrop refresh tokens when they are transmitted
   from the authorization server to the client.

   Countermeasures:

   o  As per the core OAuth spec, the authorization servers must ensure
      that these transmissions are protected using transport-layer
      mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  If end-to-end confidentiality cannot be guaranteed, reducing scope
      (see <a href="#section-5.1.5.1">Section 5.1.5.1</a>) and expiry time (see <a href="#section-5.1.5.3">Section 5.1.5.3</a>) for
      issued access tokens can be used to reduce the damage in case of
      leaks.

<span class="h4"><a class="selflink" id="section-4.5.2" href="#section-4.5.2">4.5.2</a>.  Threat: Obtaining Refresh Token from Authorization Server</span>
<span class="h4">        Database</span>

   This threat is applicable if the authorization server stores refresh
   tokens as handles in a database.  An attacker may obtain refresh
   tokens from the authorization server's database by gaining access to
   the database or launching a SQL injection attack.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 44]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-45" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Impact: Disclosure of all refresh tokens.

   Countermeasures:

   o  Enforce credential storage protection best practices
      (<a href="#section-5.1.4.1">Section 5.1.4.1</a>).

   o  Bind token to client id, if the attacker cannot obtain the
      required id and secret (<a href="#section-5.1.5.8">Section 5.1.5.8</a>).

<span class="h4"><a class="selflink" id="section-4.5.3" href="#section-4.5.3">4.5.3</a>.  Threat: Obtaining Refresh Token by Online Guessing</span>

   An attacker may try to guess valid refresh token values and send it
   using the grant type "refresh_token" in order to obtain a valid
   access token.

   Impact: Exposure of a single refresh token and derivable access
   tokens.

   Countermeasures:

   o  For handle-based designs (<a href="#section-5.1.4.2.2">Section 5.1.4.2.2</a>).

   o  For assertion-based designs (<a href="#section-5.1.5.9">Section 5.1.5.9</a>).

   o  Bind token to client id, because the attacker would guess the
      matching client id, too (see <a href="#section-5.1.5.8">Section 5.1.5.8</a>).

   o  Authenticate the client; this adds another element that the
      attacker has to guess (see <a href="#section-5.2.3.4">Section 5.2.3.4</a>).

<span class="h4"><a class="selflink" id="section-4.5.4" href="#section-4.5.4">4.5.4</a>.  Threat: Refresh Token Phishing by Counterfeit Authorization</span>
<span class="h4">        Server</span>

   An attacker could try to obtain valid refresh tokens by proxying
   requests to the authorization server.  Given the assumption that the
   authorization server URL is well-known at development time or can at
   least be obtained from a well-known resource server, the attacker
   must utilize some kind of spoofing in order to succeed.

   Countermeasures:

   o  Utilize server authentication (as described in <a href="#section-5.1.2">Section 5.1.2</a>).








<span class="grey">Lodderstedt, et al.           Informational                    [Page 45]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-46" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>.  Accessing Protected Resources</span>

<span class="h4"><a class="selflink" id="section-4.6.1" href="#section-4.6.1">4.6.1</a>.  Threat: Eavesdropping Access Tokens on Transport</span>

   An attacker could try to obtain a valid access token on transport
   between the client and resource server.  As access tokens are shared
   secrets between the authorization server and resource server, they
   should be treated with the same care as other credentials (e.g., end-
   user passwords).

   Countermeasures:

   o  Access tokens sent as bearer tokens should not be sent in the
      clear over an insecure channel.  As per the core OAuth spec,
      transmission of access tokens must be protected using transport-
      layer mechanisms such as TLS (see <a href="#section-5.1.1">Section 5.1.1</a>).

   o  A short lifetime reduces impact in case tokens are compromised
      (see <a href="#section-5.1.5.3">Section 5.1.5.3</a>).

   o  The access token can be bound to a client's identifier and require
      the client to prove legitimate ownership of the token to the
      resource server (see <a href="#section-5.4.2">Section 5.4.2</a>).

<span class="h4"><a class="selflink" id="section-4.6.2" href="#section-4.6.2">4.6.2</a>.  Threat: Replay of Authorized Resource Server Requests</span>

   An attacker could attempt to replay valid requests in order to obtain
   or to modify/destroy user data.

   Countermeasures:

   o  The resource server should utilize transport security measures
      (e.g., TLS) in order to prevent such attacks (see <a href="#section-5.1.1">Section 5.1.1</a>).
      This would prevent the attacker from capturing valid requests.

   o  Alternatively, the resource server could employ signed requests
      (see <a href="#section-5.4.3">Section 5.4.3</a>) along with nonces and timestamps in order to
      uniquely identify requests.  The resource server should detect and
      refuse every replayed request.

<span class="h4"><a class="selflink" id="section-4.6.3" href="#section-4.6.3">4.6.3</a>.  Threat: Guessing Access Tokens</span>

   Where the token is a handle, the attacker may attempt to guess the
   access token values based on knowledge they have from other access
   tokens.

   Impact: Access to a single user's data.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 46]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-47" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Countermeasures:

   o  Handle tokens should have a reasonable level of entropy (see
      <a href="#section-5.1.4.2.2">Section 5.1.4.2.2</a>) in order to make guessing a valid token value
      infeasible.

   o  Assertion (or self-contained token) token contents should be
      protected by a digital signature (see <a href="#section-5.1.5.9">Section 5.1.5.9</a>).

   o  Security can be further strengthened by using a short access token
      duration (see Sections <a href="#section-5.1.5.2">5.1.5.2</a> and <a href="#section-5.1.5.3">5.1.5.3</a>).

<span class="h4"><a class="selflink" id="section-4.6.4" href="#section-4.6.4">4.6.4</a>.  Threat: Access Token Phishing by Counterfeit Resource Server</span>

   An attacker may pretend to be a particular resource server and to
   accept tokens from a particular authorization server.  If the client
   sends a valid access token to this counterfeit resource server, the
   server in turn may use that token to access other services on behalf
   of the resource owner.

   Countermeasures:

   o  Clients should not make authenticated requests with an access
      token to unfamiliar resource servers, regardless of the presence
      of a secure channel.  If the resource server URL is well-known to
      the client, it may authenticate the resource servers (see
      <a href="#section-5.1.2">Section 5.1.2</a>).

   o  Associate the endpoint URL of the resource server the client
      talked to with the access token (e.g., in an audience field) and
      validate the association at a legitimate resource server.  The
      endpoint URL validation policy may be strict (exact match) or more
      relaxed (e.g., same host).  This would require telling the
      authorization server about the resource server endpoint URL in the
      authorization process.

   o  Associate an access token with a client and authenticate the
      client with resource server requests (typically via a signature,
      in order to not disclose a secret to a potential attacker).  This
      prevents the attack because the counterfeit server is assumed to
      lack the capability to correctly authenticate on behalf of the
      legitimate client to the resource server (<a href="#section-5.4.2">Section 5.4.2</a>).

   o  Restrict the token scope (see <a href="#section-5.1.5.1">Section 5.1.5.1</a>) and/or limit the
      token to a certain resource server (<a href="#section-5.1.5.5">Section 5.1.5.5</a>).






<span class="grey">Lodderstedt, et al.           Informational                    [Page 47]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-48" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h4"><a class="selflink" id="section-4.6.5" href="#section-4.6.5">4.6.5</a>.  Threat: Abuse of Token by Legitimate Resource Server or Client</span>

   A legitimate resource server could attempt to use an access token to
   access another resource server.  Similarly, a client could try to use
   a token obtained for one server on another resource server.

   Countermeasures:

   o  Tokens should be restricted to particular resource servers (see
      <a href="#section-5.1.5.5">Section 5.1.5.5</a>).

<span class="h4"><a class="selflink" id="section-4.6.6" href="#section-4.6.6">4.6.6</a>.  Threat: Leak of Confidential Data in HTTP Proxies</span>

   An OAuth HTTP authentication scheme as discussed in [<a href="./rfc6749" title="&quot;The OAuth 2.0 Authorization Framework&quot;">RFC6749</a>] is
   optional.  However, [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>] relies on the Authorization and
   WWW-Authenticate headers to distinguish authenticated content so that
   it can be protected.  Proxies and caches, in particular, may fail to
   adequately protect requests not using these headers.  For example,
   private authenticated content may be stored in (and thus be
   retrievable from) publicly accessible caches.

   Countermeasures:

   o  Clients and resource servers not using an OAuth HTTP
      authentication scheme (see <a href="#section-5.4.1">Section 5.4.1</a>) should take care to use
      Cache-Control headers to minimize the risk that authenticated
      content is not protected.  Such clients should send a
      Cache-Control header containing the "no-store" option [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>].
      Resource server success (2XX status) responses to these requests
      should contain a Cache-Control header with the "private" option
      [<a href="./rfc2616" title="&quot;Hypertext Transfer Protocol -- HTTP/1.1&quot;">RFC2616</a>].

   o  Reducing scope (see <a href="#section-5.1.5.1">Section 5.1.5.1</a>) and expiry time
      (<a href="#section-5.1.5.3">Section 5.1.5.3</a>) for access tokens can be used to reduce the
      damage in case of leaks.

<span class="h4"><a class="selflink" id="section-4.6.7" href="#section-4.6.7">4.6.7</a>.  Threat: Token Leakage via Log Files and HTTP Referrers</span>

   If access tokens are sent via URI query parameters, such tokens may
   leak to log files and the HTTP "referer".

   Countermeasures:

   o  Use Authorization headers or POST parameters instead of URI
      request parameters (see <a href="#section-5.4.1">Section 5.4.1</a>).

   o  Set logging configuration appropriately.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 48]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-49" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Prevent unauthorized persons from access to system log files (see
      <a href="#section-5.1.4.1.1">Section 5.1.4.1.1</a>).

   o  Abuse of leaked access tokens can be prevented by enforcing
      authenticated requests (see <a href="#section-5.4.2">Section 5.4.2</a>).

   o  The impact of token leakage may be reduced by limiting scope (see
      <a href="#section-5.1.5.1">Section 5.1.5.1</a>) and duration (see <a href="#section-5.1.5.3">Section 5.1.5.3</a>) and by
      enforcing one-time token usage (see <a href="#section-5.1.5.4">Section 5.1.5.4</a>).

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Security Considerations</span>

   This section describes the countermeasures as recommended to mitigate
   the threats described in <a href="#section-4">Section 4</a>.

<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>.  General</span>

   This section covers considerations that apply generally across all
   OAuth components (client, resource server, token server, and user
   agents).

<span class="h4"><a class="selflink" id="section-5.1.1" href="#section-5.1.1">5.1.1</a>.  Ensure Confidentiality of Requests</span>

   This is applicable to all requests sent from the client to the
   authorization server or resource server.  While OAuth provides a
   mechanism for verifying the integrity of requests, it provides no
   guarantee of request confidentiality.  Unless further precautions are
   taken, eavesdroppers will have full access to request content and may
   be able to mount interception or replay attacks by using the contents
   of requests, e.g., secrets or tokens.

   Attacks can be mitigated by using transport-layer mechanisms such as
   TLS [<a href="./rfc5246" title="&quot;The Transport Layer Security (TLS) Protocol Version 1.2&quot;">RFC5246</a>].  A virtual private network (VPN), e.g., based on IPsec
   VPNs [<a href="./rfc4301" title="&quot;Security Architecture for the Internet Protocol&quot;">RFC4301</a>], may be considered as well.

   Note: This document assumes end-to-end TLS protected connections
   between the respective protocol entities.  Deployments deviating from
   this assumption by offloading TLS in between (e.g., on the data
   center edge) must refine this threat model in order to account for
   the additional (mainly insider) threat this may cause.

   This is a countermeasure against the following threats:

   o  Replay of access tokens obtained on the token's endpoint or the
      resource server's endpoint

   o  Replay of refresh tokens obtained on the token's endpoint




<span class="grey">Lodderstedt, et al.           Informational                    [Page 49]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-50" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Replay of authorization "codes" obtained on the token's endpoint
      (redirect?)

   o  Replay of user passwords and client secrets

<span class="h4"><a class="selflink" id="section-5.1.2" href="#section-5.1.2">5.1.2</a>.  Utilize Server Authentication</span>

   HTTPS server authentication or similar means can be used to
   authenticate the identity of a server.  The goal is to reliably bind
   the fully qualified domain name of the server to the public key
   presented by the server during connection establishment (see
   [<a href="./rfc2818" title="&quot;HTTP Over TLS&quot;">RFC2818</a>]).

   The client should validate the binding of the server to its domain
   name.  If the server fails to prove that binding, the communication
   is considered a man-in-the-middle attack.  This security measure
   depends on the certification authorities the client trusts for that
   purpose.  Clients should carefully select those trusted CAs and
   protect the storage for trusted CA certificates from modifications.

   This is a countermeasure against the following threats:

   o  Spoofing

   o  Proxying

   o  Phishing by counterfeit servers

<span class="h4"><a class="selflink" id="section-5.1.3" href="#section-5.1.3">5.1.3</a>.  Always Keep the Resource Owner Informed</span>

   Transparency to the resource owner is a key element of the OAuth
   protocol.  The user should always be in control of the authorization
   processes and get the necessary information to make informed
   decisions.  Moreover, user involvement is a further security
   countermeasure.  The user can probably recognize certain kinds of
   attacks better than the authorization server.  Information can be
   presented/exchanged during the authorization process, after the
   authorization process, and every time the user wishes to get informed
   by using techniques such as:

   o  User consent forms.

   o  Notification messages (e.g., email, SMS, ...).  Note that
      notifications can be a phishing vector.  Messages should be such
      that look-alike phishing messages cannot be derived from them.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 50]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-51" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   o  Activity/event logs.

   o  User self-care applications or portals.

<span class="h4"><a class="selflink" id="section-5.1.4" href="#section-5.1.4">5.1.4</a>.  Credentials</span>

   This section describes countermeasures used to protect all kinds of
   credentials from unauthorized access and abuse.  Credentials are
   long-term secrets, such as client secrets and user passwords as well
   as all kinds of tokens (refresh and access tokens) or authorization
   "codes".

<span class="h5"><a class="selflink" id="section-5.1.4.1" href="#section-5.1.4.1">5.1.4.1</a>.  Enforce Credential Storage Protection Best Practices</span>

   Administrators should undertake industry best practices to protect
   the storage of credentials (for example, see [<a href="#ref-OWASP" title="&quot;Open Web Application Security Project Home Page&quot;">OWASP</a>]).  Such
   practices may include but are not limited to the following
   sub-sections.

<span class="h6"><a class="selflink" id="section-5.1.4.1.1" href="#section-5.1.4.1.1">5.1.4.1.1</a>.  Enforce Standard System Security Means</span>

   A server system may be locked down so that no attacker may get access
   to sensitive configuration files and databases.

<span class="h6"><a class="selflink" id="section-5.1.4.1.2" href="#section-5.1.4.1.2">5.1.4.1.2</a>.  Enforce Standard SQL Injection Countermeasures</span>

   If a client identifier or other authentication component is queried
   or compared against a SQL database, it may become possible for an
   injection attack to occur if parameters received are not validated
   before submission to the database.

   o  Ensure that server code is using the minimum database privileges
      possible to reduce the "surface" of possible attacks.

   o  Avoid dynamic SQL using concatenated input.  If possible, use
      static SQL.

   o  When using dynamic SQL, parameterize queries using bind arguments.
      Bind arguments eliminate the possibility of SQL injections.

   o  Filter and sanitize the input.  For example, if an identifier has
      a known format, ensure that the supplied value matches the
      identifier syntax rules.








<span class="grey">Lodderstedt, et al.           Informational                    [Page 51]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-52" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h6"><a class="selflink" id="section-5.1.4.1.3" href="#section-5.1.4.1.3">5.1.4.1.3</a>.  No Cleartext Storage of Credentials</span>

   The authorization server should not store credentials in clear text.
   Typical approaches are to store hashes instead or to encrypt
   credentials.  If the credential lacks a reasonable entropy level
   (because it is a user password), an additional salt will harden the
   storage to make offline dictionary attacks more difficult.

   Note: Some authentication protocols require the authorization server
   to have access to the secret in the clear.  Those protocols cannot be
   implemented if the server only has access to hashes.  Credentials
   should be strongly encrypted in those cases.

<span class="h6"><a class="selflink" id="section-5.1.4.1.4" href="#section-5.1.4.1.4">5.1.4.1.4</a>.  Encryption of Credentials</span>

   For client applications, insecurely persisted client credentials are
   easy targets for attackers to obtain.  Store client credentials using
   an encrypted persistence mechanism such as a keystore or database.
   Note that compiling client credentials directly into client code
   makes client applications vulnerable to scanning as well as difficult
   to administer should client credentials change over time.

<span class="h6"><a class="selflink" id="section-5.1.4.1.5" href="#section-5.1.4.1.5">5.1.4.1.5</a>.  Use of Asymmetric Cryptography</span>

   Usage of asymmetric cryptography will free the authorization server
   of the obligation to manage credentials.

<span class="h5"><a class="selflink" id="section-5.1.4.2" href="#section-5.1.4.2">5.1.4.2</a>.  Online Attacks on Secrets</span>

<span class="h6"><a class="selflink" id="section-5.1.4.2.1" href="#section-5.1.4.2.1">5.1.4.2.1</a>.  Utilize Secure Password Policy</span>

   The authorization server may decide to enforce a complex user
   password policy in order to increase the user passwords' entropy to
   hinder online password attacks.  Note that too much complexity can
   increase the likelihood that users re-use passwords or write them
   down, or otherwise store them insecurely.

<span class="h6"><a class="selflink" id="section-5.1.4.2.2" href="#section-5.1.4.2.2">5.1.4.2.2</a>.  Use High Entropy for Secrets</span>

   When creating secrets not intended for usage by human users (e.g.,
   client secrets or token handles), the authorization server should
   include a reasonable level of entropy in order to mitigate the risk
   of guessing attacks.  The token value should be &gt;=128 bits long and
   constructed from a cryptographically strong random or pseudo-random
   number sequence (see [<a href="./rfc4086" title="&quot;Randomness Requirements for Security&quot;">RFC4086</a>] for best current practice) generated
   by the authorization server.





<span class="grey">Lodderstedt, et al.           Informational                    [Page 52]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-53" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h6"><a class="selflink" id="section-5.1.4.2.3" href="#section-5.1.4.2.3">5.1.4.2.3</a>.  Lock Accounts</span>

   Online attacks on passwords can be mitigated by locking the
   respective accounts after a certain number of failed attempts.

   Note: This measure can be abused to lock down legitimate service
   users.

<span class="h6"><a class="selflink" id="section-5.1.4.2.4" href="#section-5.1.4.2.4">5.1.4.2.4</a>.  Use Tar Pit</span>

   The authorization server may react on failed attempts to authenticate
   by username/password by temporarily locking the respective account
   and delaying the response for a certain duration.  This duration may
   increase with the number of failed attempts.  The objective is to
   slow the attacker's attempts on a certain username down.

   Note: This may require a more complex and stateful design of the
   authorization server.

<span class="h6"><a class="selflink" id="section-5.1.4.2.5" href="#section-5.1.4.2.5">5.1.4.2.5</a>.  Use CAPTCHAs</span>

   The idea is to prevent programs from automatically checking a huge
   number of passwords, by requiring human interaction.

   Note: This has a negative impact on user experience.

<span class="h4"><a class="selflink" id="section-5.1.5" href="#section-5.1.5">5.1.5</a>.  Tokens (Access, Refresh, Code)</span>

<span class="h5"><a class="selflink" id="section-5.1.5.1" href="#section-5.1.5.1">5.1.5.1</a>.  Limit Token Scope</span>

   The authorization server may decide to reduce or limit the scope
   associated with a token.  The basis of this decision is out of scope;
   examples are:

   o  a client-specific policy, e.g., issue only less powerful tokens to
      public clients,

   o  a service-specific policy, e.g., it is a very sensitive service,

   o  a resource-owner-specific setting, or

   o  combinations of such policies and preferences.









<span class="grey">Lodderstedt, et al.           Informational                    [Page 53]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-54" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   The authorization server may allow different scopes dependent on the
   grant type.  For example, end-user authorization via direct
   interaction with the end user (authorization "code") might be
   considered more reliable than direct authorization via grant type
   "username"/"password".  This means will reduce the impact of the
   following threats:

   o  token leakage

   o  token issuance to malicious software

   o  unintended issuance of powerful tokens with resource owner
      credentials flow

<span class="h5"><a class="selflink" id="section-5.1.5.2" href="#section-5.1.5.2">5.1.5.2</a>.  Determine Expiration Time</span>

   Tokens should generally expire after a reasonable duration.  This
   complements and strengthens other security measures (such as
   signatures) and reduces the impact of all kinds of token leaks.
   Depending on the risk associated with token leakage, tokens may
   expire after a few minutes (e.g., for payment transactions) or stay
   valid for hours (e.g., read access to contacts).

   The expiration time is determined by several factors, including:

   o  risk associated with token leakage,

   o  duration of the underlying access grant,

   o  duration until the modification of an access grant should take
      effect, and

   o  time required for an attacker to guess or produce a valid token.

<span class="h5"><a class="selflink" id="section-5.1.5.3" href="#section-5.1.5.3">5.1.5.3</a>.  Use Short Expiration Time</span>

   A short expiration time for tokens is a means of protection against
   the following threats:

   o  replay

   o  token leak (a short expiration time will reduce impact)

   o  online guessing (a short expiration time will reduce the
      likelihood of success)






<span class="grey">Lodderstedt, et al.           Informational                    [Page 54]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-55" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Note: Short token duration requires more precise clock
   synchronization between the authorization server and resource server.
   Furthermore, shorter duration may require more token refreshes
   (access token) or repeated end-user authorization processes
   (authorization "code" and refresh token).

<span class="h5"><a class="selflink" id="section-5.1.5.4" href="#section-5.1.5.4">5.1.5.4</a>.  Limit Number of Usages or One-Time Usage</span>

   The authorization server may restrict the number of requests or
   operations that can be performed with a certain token.  This
   mechanism can be used to mitigate the following threats:

   o  replay of tokens

   o  guessing

   For example, if an authorization server observes more than one
   attempt to redeem an authorization "code", the authorization server
   may want to revoke all access tokens granted based on the
   authorization "code" as well as reject the current request.

   As with the authorization "code", access tokens may also have a
   limited number of operations.  This either forces client applications
   to re-authenticate and use a refresh token to obtain a fresh access
   token, or forces the client to re-authorize the access token by
   involving the user.

<span class="h5"><a class="selflink" id="section-5.1.5.5" href="#section-5.1.5.5">5.1.5.5</a>.  Bind Tokens to a Particular Resource Server (Audience)</span>

   Authorization servers in multi-service environments may consider
   issuing tokens with different content to different resource servers
   and to explicitly indicate in the token the target server to which a
   token is intended to be sent.  SAML assertions (see
   [<a href="#ref-OASIS.saml-core-2.0-os">OASIS.saml-core-2.0-os</a>]) use the Audience element for this purpose.
   This countermeasure can be used in the following situations:

   o  It reduces the impact of a successful replay attempt, since the
      token is applicable to a single resource server only.

   o  It prevents abuse of a token by a rogue resource server or client,
      since the token can only be used on that server.  It is rejected
      by other servers.

   o  It reduces the impact of leakage of a valid token to a counterfeit
      resource server.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 55]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-56" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.1.5.6" href="#section-5.1.5.6">5.1.5.6</a>.  Use Endpoint Address as Token Audience</span>

   This may be used to indicate to a resource server which endpoint URL
   has been used to obtain the token.  This measure will allow the
   detection of requests from a counterfeit resource server, since such
   a token will contain the endpoint URL of that server.

<span class="h5"><a class="selflink" id="section-5.1.5.7" href="#section-5.1.5.7">5.1.5.7</a>.  Use Explicitly Defined Scopes for Audience and Tokens</span>

   Deployments may consider only using tokens with explicitly defined
   scopes, where every scope is associated with a particular resource
   server.  This approach can be used to mitigate attacks where a
   resource server or client uses a token for a different purpose than
   the one intended.

<span class="h5"><a class="selflink" id="section-5.1.5.8" href="#section-5.1.5.8">5.1.5.8</a>.  Bind Token to Client id</span>

   An authorization server may bind a token to a certain client
   identifier.  This identifier should be validated for every request
   with that token.  This technique can be used to

   o  detect token leakage and

   o  prevent token abuse.

   Note: Validating the client identifier may require the target server
   to authenticate the client's identifier.  This authentication can be
   based on secrets managed independently of the token (e.g.,
   pre-registered client id/secret on authorization server) or sent with
   the token itself (e.g., as part of the encrypted token content).

<span class="h5"><a class="selflink" id="section-5.1.5.9" href="#section-5.1.5.9">5.1.5.9</a>.  Sign Self-Contained Tokens</span>

   Self-contained tokens should be signed in order to detect any attempt
   to modify or produce faked tokens (e.g., Hash-based Message
   Authentication Code or digital signatures).

<span class="h5"><a class="selflink" id="section-5.1.5.10" href="#section-5.1.5.10">5.1.5.10</a>.  Encrypt Token Content</span>

   Self-contained tokens may be encrypted for confidentiality reasons or
   to protect system internal data.  Depending on token format, keys
   (e.g., symmetric keys) may have to be distributed between server
   nodes.  The method of distribution should be defined by the token and
   the encryption used.







<span class="grey">Lodderstedt, et al.           Informational                    [Page 56]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-57" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.1.5.11" href="#section-5.1.5.11">5.1.5.11</a>.  Adopt a Standard Assertion Format</span>

   For service providers intending to implement an assertion-based token
   design, it is highly recommended to adopt a standard assertion format
   (such as SAML [<a href="#ref-OASIS.saml-core-2.0-os">OASIS.saml-core-2.0-os</a>] or the JavaScript Object
   Notation Web Token (JWT) [<a href="#ref-OAuth-JWT">OAuth-JWT</a>]).

<span class="h4"><a class="selflink" id="section-5.1.6" href="#section-5.1.6">5.1.6</a>.  Access Tokens</span>

   The following measures should be used to protect access tokens:

   o  Keep them in transient memory (accessible by the client
      application only).

   o  Pass tokens securely using secure transport (TLS).

   o  Ensure that client applications do not share tokens with 3rd
      parties.

<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>.  Authorization Server</span>

   This section describes considerations related to the OAuth
   authorization server endpoint.

<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>.  Authorization "codes"</span>

<span class="h5"><a class="selflink" id="section-5.2.1.1" href="#section-5.2.1.1">5.2.1.1</a>.  Automatic Revocation of Derived Tokens If Abuse Is Detected</span>

   If an authorization server observes multiple attempts to redeem an
   authorization grant (e.g., such as an authorization "code"), the
   authorization server may want to revoke all tokens granted based on
   the authorization grant.

<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>.  Refresh Tokens</span>

<span class="h5"><a class="selflink" id="section-5.2.2.1" href="#section-5.2.2.1">5.2.2.1</a>.  Restricted Issuance of Refresh Tokens</span>

   The authorization server may decide, based on an appropriate policy,
   not to issue refresh tokens.  Since refresh tokens are long-term
   credentials, they may be subject to theft.  For example, if the
   authorization server does not trust a client to securely store such
   tokens, it may refuse to issue such a client a refresh token.









<span class="grey">Lodderstedt, et al.           Informational                    [Page 57]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-58" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.2.2.2" href="#section-5.2.2.2">5.2.2.2</a>.  Binding of Refresh Token to "client_id"</span>

   The authorization server should match every refresh token to the
   identifier of the client to whom it was issued.  The authorization
   server should check that the same "client_id" is present for every
   request to refresh the access token.  If possible (e.g., confidential
   clients), the authorization server should authenticate the respective
   client.

   This is a countermeasure against refresh token theft or leakage.

   Note: This binding should be protected from unauthorized
   modifications.

<span class="h5"><a class="selflink" id="section-5.2.2.3" href="#section-5.2.2.3">5.2.2.3</a>.  Refresh Token Rotation</span>

   Refresh token rotation is intended to automatically detect and
   prevent attempts to use the same refresh token in parallel from
   different apps/devices.  This happens if a token gets stolen from the
   client and is subsequently used by both the attacker and the
   legitimate client.  The basic idea is to change the refresh token
   value with every refresh request in order to detect attempts to
   obtain access tokens using old refresh tokens.  Since the
   authorization server cannot determine whether the attacker or the
   legitimate client is trying to access, in case of such an access
   attempt the valid refresh token and the access authorization
   associated with it are both revoked.

   The OAuth specification supports this measure in that the token's
   response allows the authorization server to return a new refresh
   token even for requests with grant type "refresh_token".

   Note: This measure may cause problems in clustered environments,
   since usage of the currently valid refresh token must be ensured.  In
   such an environment, other measures might be more appropriate.

<span class="h5"><a class="selflink" id="section-5.2.2.4" href="#section-5.2.2.4">5.2.2.4</a>.  Revocation of Refresh Tokens</span>

   The authorization server may allow clients or end users to explicitly
   request the invalidation of refresh tokens.  A mechanism to revoke
   tokens is specified in [<a href="#ref-OAuth-REVOCATION">OAuth-REVOCATION</a>].










<span class="grey">Lodderstedt, et al.           Informational                    [Page 58]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-59" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   This is a countermeasure against:

   o  device theft,

   o  impersonation of a resource owner, or

   o  suspected compromised client applications.

<span class="h5"><a class="selflink" id="section-5.2.2.5" href="#section-5.2.2.5">5.2.2.5</a>.  Device Identification</span>

   The authorization server may require the binding of authentication
   credentials to a device identifier.  The International Mobile Station
   Equipment Identity [<a href="#ref-IMEI" title="&quot;International Mobile station Equipment Identities (IMEI)&quot;">IMEI</a>] is one example of such an identifier; there
   are also operating system-specific identifiers.  The authorization
   server could include such an identifier when authenticating user
   credentials in order to detect token theft from a particular device.

   Note: Any implementation should consider potential privacy
   implications of using device identifiers.

<span class="h5"><a class="selflink" id="section-5.2.2.6" href="#section-5.2.2.6">5.2.2.6</a>.  X-FRAME-OPTIONS Header</span>

   For newer browsers, avoidance of iFrames can be enforced on the
   server side by using the X-FRAME-OPTIONS header (see
   [<a href="#ref-X-Frame-Options">X-Frame-Options</a>]).  This header can have two values, "DENY" and
   "SAMEORIGIN", which will block any framing or any framing by sites
   with a different origin, respectively.  The value "ALLOW-FROM"
   specifies a list of trusted origins that iFrames may originate from.

   This is a countermeasure against the following threat:

   o  Clickjacking attacks

<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>.  Client Authentication and Authorization</span>

   As described in <a href="#section-3">Section 3</a> (Security Features), clients are
   identified, authenticated, and authorized for several purposes, such
   as to:

   o  Collate requests to the same client,

   o  Indicate to the user that the client is recognized by the
      authorization server,

   o  Authorize access of clients to certain features on the
      authorization server or resource server, and

   o  Log a client identifier to log files for analysis or statistics.



<span class="grey">Lodderstedt, et al.           Informational                    [Page 59]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-60" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   Due to the different capabilities and characteristics of the
   different client types, there are different ways to support these
   objectives, which will be described in this section.  Authorization
   server providers should be aware of the security policy and
   deployment of a particular client and adapt its treatment
   accordingly.  For example, one approach could be to treat all clients
   as less trustworthy and unsecure.  On the other extreme, a service
   provider could activate every client installation individually by an
   administrator and in that way gain confidence in the identity of the
   software package and the security of the environment in which the
   client is installed.  There are several approaches in between.

<span class="h5"><a class="selflink" id="section-5.2.3.1" href="#section-5.2.3.1">5.2.3.1</a>.  Don't Issue Secrets to Clients with Inappropriate Security</span>
<span class="h5">          Policy</span>

   Authorization servers should not issue secrets to clients that cannot
   protect secrets ("public" clients).  This reduces the probability of
   the server treating the client as strongly authenticated.

   For example, it is of limited benefit to create a single client id
   and secret that are shared by all installations of a native
   application.  Such a scenario requires that this secret must be
   transmitted from the developer via the respective distribution
   channel, e.g., an application market, to all installations of the
   application on end-user devices.  A secret, burned into the source
   code of the application or an associated resource bundle, is not
   protected from reverse engineering.  Secondly, such secrets cannot be
   revoked, since this would immediately put all installations out of
   work.  Moreover, since the authorization server cannot really trust
   the client's identifier, it would be dangerous to indicate to end
   users the trustworthiness of the client.

   There are other ways to achieve a reasonable security level, as
   described in the following sections.

<span class="h5"><a class="selflink" id="section-5.2.3.2" href="#section-5.2.3.2">5.2.3.2</a>.  Require User Consent for Public Clients without Secret</span>

   Authorization servers should not allow automatic authorization for
   public clients.  The authorization server may issue an individual
   client id but should require that all authorizations are approved by
   the end user.  For clients without secrets, this is a countermeasure
   against the following threat:

   o  Impersonation of public client applications.







<span class="grey">Lodderstedt, et al.           Informational                    [Page 60]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-61" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.2.3.3" href="#section-5.2.3.3">5.2.3.3</a>.  Issue a "client_id" Only in Combination with "redirect_uri"</span>

   The authorization server may issue a "client_id" and bind the
   "client_id" to a certain pre-configured "redirect_uri".  Any
   authorization request with another redirect URI is refused
   automatically.  Alternatively, the authorization server should not
   accept any dynamic redirect URI for such a "client_id" and instead
   should always redirect to the well-known pre-configured redirect URI.
   This is a countermeasure for clients without secrets against the
   following threats:

   o  Cross-site scripting attacks

   o  Impersonation of public client applications

<span class="h5"><a class="selflink" id="section-5.2.3.4" href="#section-5.2.3.4">5.2.3.4</a>.  Issue Installation-Specific Client Secrets</span>

   An authorization server may issue separate client identifiers and
   corresponding secrets to the different installations of a particular
   client (i.e., software package).  The effect of such an approach
   would be to turn otherwise "public" clients back into "confidential"
   clients.

   For web applications, this could mean creating one "client_id" and
   "client_secret" for each web site on which a software package is
   installed.  So, the provider of that particular site could request a
   client id and secret from the authorization server during the setup
   of the web site.  This would also allow the validation of some of the
   properties of that web site, such as redirect URI, web site URL, and
   whatever else proves useful.  The web site provider has to ensure the
   security of the client secret on the site.

   For native applications, things are more complicated because every
   copy of a particular application on any device is a different
   installation.  Installation-specific secrets in this scenario will
   require obtaining a "client_id" and "client_secret" either

   1.  during the download process from the application market, or

   2.  during installation on the device.

   Either approach will require an automated mechanism for issuing
   client ids and secrets, which is currently not defined by OAuth.

   The first approach would allow the achievement of a certain level of
   trust in the authenticity of the application, whereas the second
   option only allows the authentication of the installation but not the
   validation of properties of the client.  But this would at least help



<span class="grey">Lodderstedt, et al.           Informational                    [Page 61]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-62" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   to prevent several replay attacks.  Moreover, installation-specific
   "client_ids" and secrets allow the selective revocation of all
   refresh tokens of a specific installation at once.

<span class="h5"><a class="selflink" id="section-5.2.3.5" href="#section-5.2.3.5">5.2.3.5</a>.  Validate Pre-Registered "redirect_uri"</span>

   An authorization server should require all clients to register their
   "redirect_uri", and the "redirect_uri" should be the full URI as
   defined in [<a href="./rfc6749" title="&quot;The OAuth 2.0 Authorization Framework&quot;">RFC6749</a>].  The way that this registration is performed is
   out of scope of this document.  As per the core spec, every actual
   redirect URI sent with the respective "client_id" to the end-user
   authorization endpoint must match the registered redirect URI.  Where
   it does not match, the authorization server should assume that the
   inbound GET request has been sent by an attacker and refuse it.
   Note: The authorization server should not redirect the user agent
   back to the redirect URI of such an authorization request.
   Validating the pre-registered "redirect_uri" is a countermeasure
   against the following threats:

   o  Authorization "code" leakage through counterfeit web site: allows
      authorization servers to detect attack attempts after the first
      redirect to an end-user authorization endpoint (<a href="#section-4.4.1.7">Section 4.4.1.7</a>).

   o  Open redirector attack via a client redirection endpoint
      (<a href="#section-4.1.5">Section 4.1.5</a>).

   o  Open redirector phishing attack via an authorization server
      redirection endpoint (<a href="#section-4.2.4">Section 4.2.4</a>).

   The underlying assumption of this measure is that an attacker will
   need to use another redirect URI in order to get access to the
   authorization "code".  Deployments might consider the possibility of
   an attacker using spoofing attacks to a victim's device to circumvent
   this security measure.

   Note: Pre-registering clients might not scale in some deployments
   (manual process) or require dynamic client registration (not
   specified yet).  With the lack of dynamic client registration, a
   pre-registered "redirect_uri" only works for clients bound to certain
   deployments at development/configuration time.  As soon as dynamic
   resource server discovery is required, the pre-registered
   "redirect_uri" may no longer be feasible.









<span class="grey">Lodderstedt, et al.           Informational                    [Page 62]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-63" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.2.3.6" href="#section-5.2.3.6">5.2.3.6</a>.  Revoke Client Secrets</span>

   An authorization server may revoke a client's secret in order to
   prevent abuse of a revealed secret.

   Note: This measure will immediately invalidate any authorization
   "code" or refresh token issued to the respective client.  This might
   unintentionally impact client identifiers and secrets used across
   multiple deployments of a particular native or web application.

   This a countermeasure against:

   o  Abuse of revealed client secrets for private clients

<span class="h5"><a class="selflink" id="section-5.2.3.7" href="#section-5.2.3.7">5.2.3.7</a>.  Use Strong Client Authentication (e.g., client_assertion/</span>
<span class="h5">          client_token)</span>

   By using an alternative form of authentication such as client
   assertion [<a href="#ref-OAuth-ASSERTIONS">OAuth-ASSERTIONS</a>], the need to distribute a
   "client_secret" is eliminated.  This may require the use of a secure
   private key store or other supplemental authentication system as
   specified by the client assertion issuer in its authentication
   process.

<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>.  End-User Authorization</span>

   This section includes considerations for authorization flows
   involving the end user.

<span class="h5"><a class="selflink" id="section-5.2.4.1" href="#section-5.2.4.1">5.2.4.1</a>.  Automatic Processing of Repeated Authorizations Requires</span>
<span class="h5">          Client Validation</span>

   Authorization servers should NOT automatically process repeat
   authorizations where the client is not authenticated through a client
   secret or some other authentication mechanism such as a signed
   authentication assertion certificate (<a href="#section-5.2.3.7">Section 5.2.3.7</a>) or validation
   of a pre-registered redirect URI (<a href="#section-5.2.3.5">Section 5.2.3.5</a>).

<span class="h5"><a class="selflink" id="section-5.2.4.2" href="#section-5.2.4.2">5.2.4.2</a>.  Informed Decisions Based on Transparency</span>

   The authorization server should clearly explain to the end user what
   happens in the authorization process and what the consequences are.
   For example, the user should understand what access he is about to
   grant to which client for what duration.  It should also be obvious
   to the user whether the server is able to reliably certify certain
   client properties (web site URL, security policy).





<span class="grey">Lodderstedt, et al.           Informational                    [Page 63]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-64" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h5"><a class="selflink" id="section-5.2.4.3" href="#section-5.2.4.3">5.2.4.3</a>.  Validation of Client Properties by End User</span>

   In the authorization process, the user is typically asked to approve
   a client's request for authorization.  This is an important security
   mechanism by itself because the end user can be involved in the
   validation of client properties, such as whether the client name
   known to the authorization server fits the name of the web site or
   the application the end user is using.  This measure is especially
   helpful in situations where the authorization server is unable to
   authenticate the client.  It is a countermeasure against:

   o  A malicious application

   o  A client application masquerading as another client

<span class="h5"><a class="selflink" id="section-5.2.4.4" href="#section-5.2.4.4">5.2.4.4</a>.  Binding of Authorization "code" to "client_id"</span>

   The authorization server should bind every authorization "code" to
   the id of the respective client that initiated the end-user
   authorization process.  This measure is a countermeasure against:

   o  Replay of authorization "codes" with different client credentials,
      since an attacker cannot use another "client_id" to exchange an
      authorization "code" into a token

   o  Online guessing of authorization "codes"

   Note: This binding should be protected from unauthorized
   modifications (e.g., using protected memory and/or a secure
   database).

<span class="h5"><a class="selflink" id="section-5.2.4.5" href="#section-5.2.4.5">5.2.4.5</a>.  Binding of Authorization "code" to "redirect_uri"</span>

   The authorization server should be able to bind every authorization
   "code" to the actual redirect URI used as the redirect target of the
   client in the end-user authorization process.  This binding should be
   validated when the client attempts to exchange the respective
   authorization "code" for an access token.  This measure is a
   countermeasure against authorization "code" leakage through
   counterfeit web sites, since an attacker cannot use another redirect
   URI to exchange an authorization "code" into a token.










<span class="grey">Lodderstedt, et al.           Informational                    [Page 64]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-65" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>.  Client App Security</span>

   This section deals with considerations for client applications.

<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>.  Don't Store Credentials in Code or Resources Bundled with</span>
<span class="h4">        Software Packages</span>

   Because of the number of copies of client software, there is limited
   benefit in creating a single client id and secret that is shared by
   all installations of an application.  Such an application by itself
   would be considered a "public" client, as it cannot be presumed to be
   able to keep client secrets.  A secret, burned into the source code
   of the application or an associated resource bundle, cannot be
   protected from reverse engineering.  Secondly, such secrets cannot be
   revoked, since this would immediately put all installations out of
   work.  Moreover, since the authorization server cannot really trust
   the client's identifier, it would be dangerous to indicate to end
   users the trustworthiness of the client.

<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>.  Use Standard Web Server Protection Measures (for Config Files</span>
<span class="h4">        and Databases)</span>

   Use standard web server protection and configuration measures to
   protect the integrity of the server, databases, configuration files,
   and other operational components of the server.

<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>.  Store Secrets in Secure Storage</span>

   There are different ways to store secrets of all kinds (tokens,
   client secrets) securely on a device or server.

   Most multi-user operating systems segregate the personal storage of
   different system users.  Moreover, most modern smartphone operating
   systems even support the storage of application-specific data in
   separate areas of file systems and protect the data from access by
   other applications.  Additionally, applications can implement
   confidential data by using a user-supplied secret, such as a PIN or
   password.

   Another option is to swap refresh token storage to a trusted backend
   server.  This option in turn requires a resilient authentication
   mechanism between the client and backend server.  Note: Applications
   should ensure that confidential data is kept confidential even after
   reading from secure storage, which typically means keeping this data
   in the local memory of the application.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 65]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-66" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>.  Utilize Device Lock to Prevent Unauthorized Device Access</span>

   On a typical modern phone, there are many "device lock" options that
   can be utilized to provide additional protection when a device is
   stolen or misplaced.  These include PINs, passwords, and other
   biometric features such as "face recognition".  These are not equal
   in the level of security they provide.

<span class="h4"><a class="selflink" id="section-5.3.5" href="#section-5.3.5">5.3.5</a>.  Link the "state" Parameter to User Agent Session</span>

   The "state" parameter is used to link client requests and prevent
   CSRF attacks, for example, attacks against the redirect URI.  An
   attacker could inject their own authorization "code" or access token,
   which can result in the client using an access token associated with
   the attacker's protected resources rather than the victim's (e.g.,
   save the victim's bank account information to a protected resource
   controlled by the attacker).

   The client should utilize the "state" request parameter to send the
   authorization server a value that binds the request to the user
   agent's authenticated state (e.g., a hash of the session cookie used
   to authenticate the user agent) when making an authorization request.
   Once authorization has been obtained from the end user, the
   authorization server redirects the end-user's user agent back to the
   client with the required binding value contained in the "state"
   parameter.

   The binding value enables the client to verify the validity of the
   request by matching the binding value to the user agent's
   authenticated state.

<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>.  Resource Servers</span>

   The following section details security considerations for resource
   servers.

<span class="h4"><a class="selflink" id="section-5.4.1" href="#section-5.4.1">5.4.1</a>.  Authorization Headers</span>

   Authorization headers are recognized and specially treated by HTTP
   proxies and servers.  Thus, the usage of such headers for sending
   access tokens to resource servers reduces the likelihood of leakage
   or unintended storage of authenticated requests in general, and
   especially Authorization headers.








<span class="grey">Lodderstedt, et al.           Informational                    [Page 66]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-67" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h4"><a class="selflink" id="section-5.4.2" href="#section-5.4.2">5.4.2</a>.  Authenticated Requests</span>

   An authorization server may bind tokens to a certain client
   identifier and enable resource servers to validate that association
   on resource access.  This will require the resource server to
   authenticate the originator of a request as the legitimate owner of a
   particular token.  There are several options to implement this
   countermeasure:

   o  The authorization server may associate the client identifier with
      the token (either internally or in the payload of a self-contained
      token).  The client then uses client certificate-based HTTP
      authentication on the resource server's endpoint to authenticate
      its identity, and the resource server validates the name with the
      name referenced by the token.

   o  Same as the option above, but the client uses his private key to
      sign the request to the resource server (the public key is either
      contained in the token or sent along with the request).

   o  Alternatively, the authorization server may issue a token-bound
      key, which the client uses in a Holder-of-Key proof to
      authenticate the client's use of the token.  The resource server
      obtains the secret directly from the authorization server, or the
      secret is contained in an encrypted section of the token.  In that
      way, the resource server does not "know" the client but is able to
      validate whether the authorization server issued the token to that
      client.

   Authenticated requests are a countermeasure against abuse of tokens
   by counterfeit resource servers.

<span class="h4"><a class="selflink" id="section-5.4.3" href="#section-5.4.3">5.4.3</a>.  Signed Requests</span>

   A resource server may decide to accept signed requests only, either
   to replace transport-level security measures or to complement such
   measures.  Every signed request should be uniquely identifiable and
   should not be processed twice by the resource server.  This
   countermeasure helps to mitigate:

   o  modifications of the message and

   o  replay attempts








<span class="grey">Lodderstedt, et al.           Informational                    [Page 67]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-68" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>.  A Word on User Interaction and User-Installed Apps</span>

   OAuth, as a security protocol, is distinctive in that its flow
   usually involves significant user interaction, making the end user a
   part of the security model.  This creates some important difficulties
   in defending against some of the threats discussed above.  Some of
   these points have already been made, but it's worth repeating and
   highlighting them here.

   o  End users must understand what they are being asked to approve
      (see <a href="#section-5.2.4.2">Section 5.2.4.2</a>).  Users often do not have the expertise to
      understand the ramifications of saying "yes" to an authorization
      request and are likely not to be able to see subtle differences in
      the wording of requests.  Malicious software can confuse the user,
      tricking the user into approving almost anything.

   o  End-user devices are prone to software compromise.  This has been
      a long-standing problem, with frequent attacks on web browsers and
      other parts of the user's system.  But with the increasing
      popularity of user-installed "apps", the threat posed by
      compromised or malicious end-user software is very strong and is
      one that is very difficult to mitigate.

   o  Be aware that users will demand to install and run such apps, and
      that compromised or malicious ones can steal credentials at many
      points in the data flow.  They can intercept the very user login
      credentials that OAuth is designed to protect.  They can request
      authorization far beyond what they have led the user to understand
      and approve.  They can automate a response on behalf of the user,
      hiding the whole process.  No solution is offered here, because
      none is known; this remains in the space between better security
      and better usability.

   o  Addressing these issues by restricting the use of user-installed
      software may be practical in some limited environments and can be
      used as a countermeasure in those cases.  Such restrictions are
      not practical in the general case, and mechanisms for after-the-
      fact recovery should be in place.

   o  While end users are mostly incapable of properly vetting
      applications they load onto their devices, those who deploy
      authorization servers might have tools at their disposal to
      mitigate malicious clients.  For example, a well-run authorization
      server must only assert client properties to the end user it is
      effectively capable of validating, explicitly point out which
      properties it cannot validate, and indicate to the end user the
      risk associated with granting access to the particular client.




<span class="grey">Lodderstedt, et al.           Informational                    [Page 68]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-69" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Acknowledgements</span>

   We would like to thank Stephen Farrell, Barry Leiba, Hui-Lan Lu,
   Francisco Corella, Peifung E. Lam, Shane B. Weeden, Skylar Woodward,
   Niv Steingarten, Tim Bray, and James H. Manger for their comments and
   contributions.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  References</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Normative References</span>

   [<a id="ref-RFC6749">RFC6749</a>]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              <a href="./rfc6749">RFC 6749</a>, October 2012.

   [<a id="ref-RFC6750">RFC6750</a>]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", <a href="./rfc6750">RFC 6750</a>, October 2012.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Informative References</span>

   [<a id="ref-Framebusting">Framebusting</a>]
              Rydstedt, G., Bursztein, Boneh, D., and C. Jackson,
              "Busting Frame Busting: a Study of Clickjacking
              Vulnerabilities on Popular Sites", IEEE 3rd Web 2.0
              Security and Privacy Workshop, May 2010, &lt;<a href="http://elie.im/publication/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites">http://elie.im/</a>
              <a href="http://elie.im/publication/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites">publication/busting-frame-busting-a-study-of-</a>
              <a href="http://elie.im/publication/busting-frame-busting-a-study-of-clickjacking-vulnerabilities-on-popular-sites">clickjacking-vulnerabilities-on-popular-sites</a>&gt;.

   [<a id="ref-IMEI">IMEI</a>]     3GPP, "International Mobile station Equipment Identities
              (IMEI)", 3GPP TS 22.016 11.0.0, September 2012,
              &lt;<a href="http://www.3gpp.org/ftp/Specs/html-info/22016.htm">http://www.3gpp.org/ftp/Specs/html-info/22016.htm</a>&gt;.

   [<a id="ref-OASIS.saml-core-2.0-os">OASIS.saml-core-2.0-os</a>]
              Cantor, S., Ed., Kemp, J., Ed., Philpott, R., Ed., and E.
              Maler, Ed., "Assertions and Protocols for the OASIS
              Security Assertion Markup Language (SAML) V2.0", OASIS
              Standard saml-core-2.0-os, March 2005,
              &lt;<a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">http://docs.oasis-open.org/security/saml/</a>
              <a href="http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf">v2.0/saml-core-2.0-os.pdf</a>&gt;.

   [<a id="ref-OASIS.sstc-saml-bindings-1.1">OASIS.sstc-saml-bindings-1.1</a>]
              Maler, E., Ed., Mishra, P., Ed., and R. Philpott, Ed.,
              "Bindings and Profiles for the OASIS Security Assertion
              Markup Language (SAML) V1.1", September 2003,
              &lt;<a href="http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf">http://www.oasis-open.org/committees/download.php/3405/</a>
              <a href="http://www.oasis-open.org/committees/download.php/3405/oasis-sstc-saml-bindings-1.1.pdf">oasis-sstc-saml-bindings-1.1.pdf</a>&gt;.






<span class="grey">Lodderstedt, et al.           Informational                    [Page 69]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-70" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   [<a id="ref-OASIS.sstc-sec-analysis-response-01">OASIS.sstc-sec-analysis-response-01</a>]
              Linn, J., Ed., and P. Mishra, Ed., "SSTC Response to
              "Security Analysis of the SAML Single Sign-on Browser/
              Artifact Profile"", January 2005,
              &lt;<a href="http://www.oasis-open.org/committees/download.php/11191/sstc-gross-sec-analysis-response-01.pdf">http://www.oasis-open.org/committees/download.php/</a>
              <a href="http://www.oasis-open.org/committees/download.php/11191/sstc-gross-sec-analysis-response-01.pdf">11191/sstc-gross-sec-analysis-response-01.pdf</a>&gt;.

   [<a id="ref-OAuth-ASSERTIONS">OAuth-ASSERTIONS</a>]
              Campbell, B., Mortimore, C., Jones, M., and Y. Goland,
              "Assertion Framework for OAuth 2.0", Work in Progress,
              December 2012.

   [<a id="ref-OAuth-HTTP-MAC">OAuth-HTTP-MAC</a>]
              Richer, J., Ed., Mills, W., Ed., and H. Tschofenig, Ed.,
              "OAuth 2.0 Message Authentication Code (MAC) Tokens", Work
              in Progress, November 2012.

   [<a id="ref-OAuth-JWT">OAuth-JWT</a>]
              Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", Work in Progress, December 2012.

   [<a id="ref-OAuth-REVOCATION">OAuth-REVOCATION</a>]
              Lodderstedt, T., Ed., Dronia, S., and M. Scurtescu, "Token
              Revocation", Work in Progress, November 2012.

   [<a id="ref-OPENID">OPENID</a>]   "OpenID Foundation Home Page", &lt;<a href="http://openid.net/">http://openid.net/</a>&gt;.

   [<a id="ref-OWASP">OWASP</a>]    "Open Web Application Security Project Home Page",
              &lt;<a href="https://www.owasp.org/">https://www.owasp.org/</a>&gt;.

   [<a id="ref-Portable-Contacts">Portable-Contacts</a>]
              Smarr, J., "Portable Contacts 1.0 Draft C", August 2008,
              &lt;<a href="http://portablecontacts.net/">http://portablecontacts.net/</a>&gt;.

   [<a id="ref-RFC2616">RFC2616</a>]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", <a href="./rfc2616">RFC 2616</a>, June 1999.

   [<a id="ref-RFC2818">RFC2818</a>]  Rescorla, E., "HTTP Over TLS", <a href="./rfc2818">RFC 2818</a>, May 2000.

   [<a id="ref-RFC4086">RFC4086</a>]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", <a href="https://www.rfc-editor.org/bcp/bcp106">BCP 106</a>, <a href="./rfc4086">RFC 4086</a>, June 2005.

   [<a id="ref-RFC4120">RFC4120</a>]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", <a href="./rfc4120">RFC 4120</a>,
              July 2005.





<span class="grey">Lodderstedt, et al.           Informational                    [Page 70]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-71" ></span>
<span class="grey"><a href="./rfc6819">RFC 6819</a>                   OAuth 2.0 Security               January 2013</span>


   [<a id="ref-RFC4301">RFC4301</a>]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", <a href="./rfc4301">RFC 4301</a>, December 2005.

   [<a id="ref-RFC5246">RFC5246</a>]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", <a href="./rfc5246">RFC 5246</a>, August 2008.

   [<a id="ref-SSL-Latency">SSL-Latency</a>]
              Sissel, J., Ed., "SSL handshake latency and HTTPS
              optimizations", June 2010.

   [<a id="ref-Sec-Analysis">Sec-Analysis</a>]
              Gross, T., "Security Analysis of the SAML Single Sign-on
              Browser/Artifact Profile", 19th Annual Computer Security
              Applications Conference, Las Vegas, December 2003.

   [<a id="ref-X-Frame-Options">X-Frame-Options</a>]
              Ross, D. and T. Gondrom, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22HTTP+Header+X-Frame-Options%22'>"HTTP Header X-Frame-Options"</a>,
              Work in Progress, October 2012.

   [<a id="ref-iFrame">iFrame</a>]   World Wide Web Consortium, "Frames in HTML documents",
              W3C HTML 4.01, December 1999,
              &lt;<a href="http://www.w3.org/TR/html4/present/frames.html#h-16.5">http://www.w3.org/TR/html4/present/frames.html#h-16.5</a>&gt;.

Authors' Addresses

   Torsten Lodderstedt (editor)
   Deutsche Telekom AG

   EMail: torsten@lodderstedt.net


   Mark McGloin
   IBM

   EMail: mark.mcgloin@ie.ibm.com


   Phil Hunt
   Oracle Corporation

   EMail: phil.hunt@yahoo.com










Lodderstedt, et al.           Informational                    [Page 71]
</pre>