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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
