Subject: [OAUTH-WG] Additional security consideration.

From: John Bradley <[email-masked]>
Date: Mon, 2 Jul 2012 17:08:20 -0400

I sent some text to the list on public clients using the code flow.

If that gets accepted then I think this should be the additional security consideration to address the issues eased by the MS security researchers and myself.

Alternate title suggestion #1 "Resource owner Impersonation" 
Alternate title suggestion #2 "Delegator/Delegated Confusion by the Client"
Alternate title suggestion #3 "Misuse of Access Token to impersonate a Resource Owner at a public client"

<section title='Misuse of Access Token to impersonate a Resource Owner at a public client'>
       <t>
         For public clients using implicit flows this specification does not provide any
         method for the client to determine what client an access token was issued to.
         </t>
         <t>
         A Resource Owner may willingly delegate access to a resource by granting an access_token
          to an attacker's malicious client.  This may be due to Phishing or some other pretext.
         An attacker may also steal a token via some other mechanism.   
         An attacker may then attempt to impersonate the resource owner by providing the 
         access_token to a legitimate public client.  
       </t>
         <t>
         In the implicit flow (response_type=token) the attacker can easily switch the token in the response from the authorization server.
         Replacing the real access_token with the one previously issued to the attacker.
         </t>
         <t>
         Servers communicating with native apps that rely on being passed an access_token in the back channel to identify the user of the client may 
         be similarly compromised by an attacker creating a compromised app that can inject arbitrary stolen access_tokens.
         </t>
        <t>
         Any public client that makes the assumption that only the resource owner
         can present them with a valid access_token for the resource is vulnerable to this attack.
        </t>
       <t>
         This attack may expose information about the resource owner at the legitimate client to the attacker (malicious client).
         This will also allow the attacker to perform operations at the legitimate client with the same permissions as 
         the resource owner who originally granted the access_token or authorization code.
       </t>
       <t>
         Authenticating Resource Owners to clients is out of scope for this specification.
        Any specification that uses the authorization process as a form of delegated end-user authentication
        to the client (e.g. third-party sign-in service) MUST NOT use the implicit flow without additional security mechanisms
        that enable the client to determine if the access token was issued for it's use .
       </t>
     </section>

John B.