We are talking about resource accesses here, right? There's no query parameter from the point of view of OAuth: the access token is sent as Authorize header over TLS, so I am a bit puzzled by your comment...
Nat 2016年3月18日(金) 2:49 John Bradley <ve7...@ve7jtb.com>: > 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 > or 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. It presumes there are no open > redirect servers in the 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 > phil.h...@oracle.com > > > > > > On Mar 16, 2016, at 11:42 PM, Nat Sakimura <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/v2/userinfo > https://example.org/some/api/endpoint > > etc., then the AS may provide > > https://example.com/apis/ > 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 <oauth-boun...@ietf.org>] *On > Behalf Of *George Fletcher > *Sent:* Wednesday, March 16, 2016 3:15 AM > *To:* John Bradley <ve7...@ve7jtb.com>; Brian Campbell < > bcampb...@pingidentity.com> > *Cc:* <oauth@ietf.org> <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 > 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
