RFC 6750 Sec 2.3. I wish clients used the header, the reality is that the majority of client developers use a query paramater because it is easy.
Form encoding is also allowed. If the RS has user hosted content the web server may helpfully make the headder available anyway to the web page. Query is the worst. In those cases the token will leak if someone gets at the HTTP logs. This is one of the reasons a specific audiance in the token is important to limit the loss if a RS is compromised. John B. On Mar 17, 2016 11:56 PM, "Nat Sakimura" <sakim...@gmail.com> wrote: > 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
