It is not just redirects that are a threat. Any user hosted content could potentially extract an access token from a query parameter.
John B. > On Mar 17, 2016, at 1:34 PM, Phil Hunt <phil.h...@oracle.com> wrote: > > +1 for Nat's last few emails (avoiding generating too much traffic :-). > > Re: below, this is where I was thinking of masking/filter in bound config. > The main thing that needs to be checked at > configuration time is whether the client has a valid set of server host names > to prevent a malicious proxy. > > So all the examples you mention below do boil down to https://example.org > <https://example.org/> or https://example.com <https://example.com/> > > It’s not that the AS needs to return them. It simply needs to match them. If > one of them matches, then the oauth config can be returned. > > I do agree re-directs (of the ESPN scenario) can become an issue if a > discovery system matches on *.example.com <http://example.com/>. It presumes > there are no open redirect servers in the example.com <http://example.com/> > domain. As I mention in another email, we should discuss what happens when > any oauth connection is redirected. Should the client re-validate the > configuration? > > Phil > > @independentid > www.independentid.com <http://www.independentid.com/>phil.h...@oracle.com > <mailto:phil.h...@oracle.com> > > > > > >> On Mar 16, 2016, at 11:42 PM, Nat Sakimura <n-sakim...@nri.co.jp >> <mailto:n-sakim...@nri.co.jp>> 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. >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <https://www.ietf.org/mailman/listinfo/oauth> >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
