Josh, I’m not sure this helps. It seems to me, a phishing link could tell your app to launch and pass in any RS value could it not?
Phil @independentid www.independentid.com phil.h...@oracle.com > On Mar 16, 2015, at 10:47 AM, Josh Mandel <jman...@gmail.com> wrote: > > Hi Torsten, > > You're absolutely correct. The implementation we're contemplating for SMART > Platforms does indeed derive the "aud" parameter from the actual URL that the > client used to communicate with the RS. Very briefly, the flow is: > > 1. Electronic Health Record system tells an app to launch, passing the app > its RS endpoint as an issuer (iss) URL parameter. > 2. App queries the RS's issuer URL to learn what AS to talk to > 3. App contacts AS's authorize endpoint, passing an "aud" param that was the > same as the issuer from step 1. > 4. After obtaining a token, app talks to the RS using that token. > > -Josh > > > On Mon, Mar 16, 2015 at 10:40 AM, Torsten Lodderstedt > <tors...@lodderstedt.net <mailto:tors...@lodderstedt.net>> 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 <dixie.ba...@martin-blanck.com > <mailto:dixie.ba...@martin-blanck.com>>: > >> 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 <tel:310-791-9671> >> Mobile: 310-279-2579 <tel:310-279-2579> >> On Mar 16, 2015, at 6:43 AM, Brian Campbell <bcampb...@pingidentity.com >> <mailto:bcampb...@pingidentity.com>> 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 <ve7...@ve7jtb.com >>> <mailto: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 >>> >>> <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 >>>> <mailto: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 >>>> <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 >>>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >>> >>> >> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org <mailto:OAuth@ietf.org> > https://www.ietf.org/mailman/listinfo/oauth > <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
