Hi All,
In section 4.6.4 ("Threat: Access Token Phishing by Counterfeit Resource
Server"), RFC6819 describes a threat where a counterfeit resource server
tricks a client into obtaining and sharing an access token from a
legitimate authorization server. One of the proposed mitigations involves:
"telling the authorization server about the resource server endpoint URL in
the authorization process."
In other words, this mitigation would ask the client to pass an additional
parameter when redirecting to the Authorization server's "authorize" URL,
effectively something like:
https://auth-server/authorize?
response_type=code&
client_id=123&
state=456&
scope=read-all&
redirect_uri=https://app-server/after-auth&;
*resource_server_that_told_me_to_authorize_here=https://attacker.com
<https://attacker.com>*
(And if the authorization server saw a value it didn't like in the final
parameter, it would reject the request.)
This is obviously not appropriate in every authorization scenario, but it
is useful anytime there's a discovery process by which apps learn about
authorization servers from resource servers. Since it's something of a
common need, I wanted to see if there was any common practice in how to
name this parameter, or whether it's worth registering a standard extension
at http://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml
. (I don't see one there now -- possibly I'm just missing it.)
If so, what should it be called? The name I used in the example above is a
bit verbose :-)
Best,
Josh
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
