We've used "aud" (optionally) with OAuth 2 and bearer tokens to help identify the RS to whom the AT should be issued. It is useful but it's mostly about getting format/content/etc of the AT correct for the RS rather than it is about preventing possible AT leaks.
I do think an "aud(iance)" parameter at both token and authorization endpoints would have utility beyond the POP work. So defining it independently might make sense. On Sun, Mar 15, 2015 at 11:34 AM, John Bradley <ve7...@ve7jtb.com> wrote: > In POP key distribution we do introduce a "audiance" parameter to the > token_endpoint. > https://tools.ietf.org/html/draft-ietf-oauth-pop-key-distribution-01#section-3.1 > > It would be possible to have a small spec to define using "aud" with > bearer tokens, however that would be undefined behaviour at this point. > > I don't know of any clients that would try to access a RS server and then > besed on the error response try and get a access token from the AS > specified in the error. > > In POP we are trying to both protect agains that attack and more common > ones like doing a MiM to intercept the AT or the RS being hacked and > leaking the token. > > Using "aud" with bearer tokens would be useful, but probably won't stop > the majority of possible AT leaks. > > John B. > > > On Mar 15, 2015, at 2:18 PM, Torsten Lodderstedt <tors...@lodderstedt.net> > wrote: > > Hi Josh, > > I'm not aware of a common practice to use such a parameter. The WG is > instead heading towards authenticated requests to the resource server (see > https://tools.ietf.org/html/rfc6819#section-5.4.2). > > Please take a look onto > http://tools.ietf.org/html/draft-ietf-oauth-pop-architecture and further > drafts on this topic. > > kind regards, > Torsten. > > Am 03.03.2015 um 18:27 schrieb Josh Mandel: > > 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 listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
