The problem is similar to the one with redirect_uri, if you allow user hosted content on the domain they will be able to get the token if it is sent as a query parameter, and might be able to if it is sent as a header.
Unfortunately many OAuth clients are badly behaved and make use of the query parameter not considering the security issues. Anything other than the AS or the client doing an exact URI match is going to leave some hole. This is why we are working on POP that is the correct way to solve this for AS. I think anything other than the client giving the AS the whole URI and the AS including that as a audience/destination and letting the RS figure out if it is correct is largely hopeless, as it will be to fragile or the client won’t do it. In the case of Phil’s proposal the discovery happens once at client setup so the AS has no idea if the client checked before issuing the token. I honestly think there are two viable options: 1 PoP tokens 2 Including the destination URI / RS URI (pick name) in the token in full and letting the RS decide if it has been man in the middled. Everything else will be an endless game of wack-a-mole that increases complexity but gets little real security. John B. > On Mar 17, 2016, at 11:43 AM, George Fletcher <gffle...@aol.com> wrote: > > If one of the APIs has an open-redirect problem, won't that cause the token > to leak to the attacker? That's why we went to exact match in OpenID Connect. > Does it not apply in this case? > > Thanks, > George > > On 3/17/16 2:42 AM, Nat Sakimura wrote: >> IMHO, list of URIs that represent the partial paths under the same authority >> would not be too onerous. <> >> >> e.g., if you have >> >> https://example.com/apis/v1/userinfo <https://example.com/apis/v1/userinfo> >> https://example.com/apis/v2/userinfo <https://example.com/apis/v2/userinfo> >> https://example.org/some/api/endpoint <https://example.org/some/api/endpoint> >> >> etc., then the AS may provide >> >> https://example.com/apis/ <https://example.com/apis/> >> https://example.org/ <https://example.org/> >> >> or something like that in the audiences. >> >> A completely new domain should not be trusted blindly. >> The resource should at least make sure to provide the domain as being under >> the same authority. >> >> Bearer Token is a Password. It should not be shared among different >> authorities. >> >> Best, >> >> Nat >> >> From: OAuth [mailto:oauth-boun...@ietf.org <mailto:oauth-boun...@ietf.org>] >> On Behalf Of George Fletcher >> Sent: Wednesday, March 16, 2016 3:15 AM >> To: John Bradley <ve7...@ve7jtb.com> <mailto:ve7...@ve7jtb.com>; Brian >> Campbell <bcampb...@pingidentity.com> <mailto:bcampb...@pingidentity.com> >> Cc: <oauth@ietf.org> <mailto:oauth@ietf.org> <oauth@ietf.org> >> <mailto:oauth@ietf.org> >> Subject: Re: [OAUTH-WG] New Version Notification for >> draft-hunt-oauth-bound-config-00.txt >> >> (..snip..) >> >> I'm not sure passing the full endpoint to the AS will help with my >> concerns... The AS could potentially do a webfinger on the resource URI and >> determine if it's an RS that it supports... though that requires all RS's to >> support webfinger. What I really want to avoid is the AS having this list of >> URIs to RS that is almost assuredly to get out of sync. >> >> >> (..snip..) >> >> -- >> PLEASE READ :This e-mail is confidential and intended for the >> named recipient only. If you are not an intended recipient, >> please notify the sender and delete this e-mail. >> > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
