Yes but it is custom. People are inventing structured scopes like "aud:https://foo.com";, and that potentially doesn't solve the security issue if a client just passes on the scopes it receives in the error response, the bad RS just adds a scope for the good RS.
The client then potentially needs to understand the custom structures scopes of every AS it might deal with. I think that would lead to lots of problems trying to make that a pattern long term. At teh moment yes you can do it with a scope as long as the client and AS both understand what is going on. We added "aud" as a separate parameter for PoP as the token format for different RS might be different as well as the symmetric pop keys needing to be encrypted with different keys. Yes we could have invented a special scope to carry the audience but a separate parameter was much cleaner. I know some people have started using "aud" as a way to communicate the resource when a scope applies to multiple RS but they may take different token formats JWT vs opaque etc. Brian commented that the "aud" parameter may be useful beyond PoP so we might want to think about documenting it in it's own mini spec, if I understood him correctly. I think that may not be a bad idea as we are also planning on using it in NAPPS. John B. > On Mar 17, 2015, at 5:39 PM, Bill Mills <[email protected]> wrote: > > I don't think it's "overloading scope names" to use them that way. The aud > value(s) could as easily be carried in scope as anywhere. Nothing says a > scope can't be "https://foo.com";, and that Foo.com requires that scope to be > present for a token to be accepted. I would not make it foo.com-read-mail > for example. > > If it's more convenient to put it in aud I can accept that, but it's the same > functionality and can be implemented in scopes now. > > > > On Tuesday, March 17, 2015 12:41 PM, John Bradley <[email protected]> wrote: > > > People have been overloading scope names to create implicit audience. > > The problem is that clients need to know via some magic method that you need > to ask for scope "purple" to get write access to RS 2. > > Having an explicit "aud" parameter gives clients a way to communicate to the > AS what RS they are asking for a token for. > > the security issue is that if a client discovers a API out via some out of > band mechanism the OAuth error code can tell the client go to AS X and ask > for Scope Y. > > Unfortunately without POP tokens or at-least passing the URI of the RS to the > AS via "aud", a bad RS could get a legitimate client to give it a token that > can be replayed at a legitimate RS. > > This was one of the issues that Eran Hammer-Lahav was particularly concerned > about. > > I think I proposed a "aud" parameter to the token endpoint back then as a > alternative to requiring HMAC tokens, but that got lost in the confusion at > the time. > > At that time though people were not yet thinking about interoperable OAuth > API, only relatively tightly bound clients that were preconfigured for the > API endpoints they were using. > > In Health and other places we are starting to see standard clients that > discover API endpoints and configure themselves based on a users Identity to > use a arbitrary OAuth AS, moving into federation of AT. > > That is one of the reasons POP will be important, as it prevents RS from > misusing federated tokens by presenting them at other RS. > > The simplest thing to do is have the client say what RS it is trying to > access explicitly (The "aud" parameter), and including an audience in the AT. > to protect against malicious RS. > > PoP is the step up that also protects against tokens being intercepted and > replayed by another client. > > John B. > >> On Mar 17, 2015, at 4:10 PM, Bill Mills <[email protected] >> <mailto:[email protected]>> wrote: >> >> This may have been hashed out already and I missed it, but "aud" just >> becomes another kind of scope, correct? >> >> >> >> >> On Tuesday, March 17, 2015 8:50 AM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> You could do that, but it is probably safer for the AS to know what RS it >> can issue tokens for and refuse to issue a token for RS A to a client asking >> for a token with RS X as the aud. >> >> John B. >>> On Mar 16, 2015, at 8:27 PM, Dixie Baker <[email protected] >>> <mailto:[email protected]>> wrote: >>> >> >> The threat that RFC6819 4.6.4 describes is when a client obtains an AT and >> then sends it to a counterfeit RS, which then uses the AT to access >> resources from a legitimate RS, on the end-user's behalf. >> >> The suggested countermeasure is a bit difficult to interpret: "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." >> >> As I read this, the suggestion is to have the client pass the URL of the bad >> RS in the request to the AS (using the audience field). The AS then would >> include that RS URL in the AT. Then, when the client passes the AT to the >> bad RS, and it passes it on to the good RS, the good RS will check the >> audience field, compare that URL with its own, and refuse the request. >> >> -Dixie >> >> >> >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >> >> On Mar 16, 2015, at 11:39 AM, John Bradley <[email protected] >> <mailto:[email protected]>> wrote: >> >> >> Brian and I were talking about "aud" used as a parameter to the token >> endpoint when using a code or refresh token to indicate what RS the >> resulting AT will be used at. >> >> Sending a audience in the AT wouldn't help prevent the attack being >> discussed, though it may stop other sorts of attacks if the RS can tell if >> a AT was issued for it or another RS. >> >> In PoP having the AS check that you are sending the AT to the correct RS is >> less important as the AT if stolen can't be used to replay against the real >> AS. >> >> Though depending on the app the bogus RS feeding the app the wrong info may >> well be a problem as well. >> >> John B. >> >>> On Mar 16, 2015, at 2:40 PM, Torsten Lodderstedt <[email protected] >>> <mailto:[email protected]>> wrote: >>> >> >> I don't think putting an aud into an AT will help to prevent counterfeit RSs >> (as long as the aud is nit directly derived from the original URL used by >> the client to invoke the counterfeit RS. as long as the aud is a symbolic >> name of any kind, the counterfeit RS will accept ATs for the legitimate RS >> and just (ab)use it. >> >> POP on the contrary helps since the counterfeit RS, in order to send a >> message to the legitimate RS, needs to produce a new digitally signed >> message using the correct secret, which it doesn't know. >> >> kind regards, >> Torsten. >> >> >> >> Am 16.03.2015 um 17:40 schrieb Dixie Baker <[email protected] >> <mailto:[email protected]>>: >> >> >> Using the "aud" parameter makes sense to me. Good suggestion. >> >> Authenticating the client to the RS would not address the counterfeit RS >> threat. >> >> -Dixie >> >> >> Dixie B. Baker, Ph.D. >> Senior Partner >> Martin, Blanck and Associates >> Office (Redondo Beach, CA): 310-791-9671 >> Mobile: 310-279-2579 >> >> On Mar 16, 2015, at 6:43 AM, Brian Campbell <[email protected] >> <mailto:[email protected]>> wrote: >> >>> 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 <[email protected] >>> <mailto:[email protected]>> 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 >>> >>> <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 <[email protected] >>>> <mailto:[email protected]>> 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 >>>> <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 >>>> <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 <https://auth-server/authorize>? >>>>> response_type=code& >>>>> client_id=123& >>>>> state=456& >>>>> scope=read-all& >>>>> redirect_uri=https://app-server/after-auth&; >>>>> <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 >>>>> <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 >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> [email protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >> >> >> >> >> >> _______________________________________________ >> OAuth mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >> >> > > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
