Hi Jon, Purely from a process perspective, the same goes with convincing that this use case is core to the protocol. There is already a list of things the core spec does not support (language preference, re-delegation, body signatures, asymmetric secrets, discovery, UI features) which people want it to support. I think part of the discussion should include whether this is *possible* to accomplish with an extension.
For example, a way to encode the entire Authorization header into the oauth_token parameter (or a different parameter): GET /resource?oauth_token=vF9dft4qmT;nonce;timestamp;algorithm;signature HTTP/1.1 Host: server.example.com Alternatively, the extension can require that any oauth_ parameters be added at the end of the query and removed by the server to recreate the header before calculating signatures. It would be helpful to hear from others if they have more use cases which require signed requests with parameters outside the header. Also, this will be a bit more practice to discuss once we have a proposal for signatures that is simpler than 1.0a (so we can decide whether that simplification helps and worth the limitation in core). EHL On 4/11/10 4:54 PM, "Jonathan Moore" <[email protected]> wrote: > Actually, in this case, I'm imagining a base page that is heavily cached (and > non-personalized), perhaps delivered by CDN, non-SSL. The rendered page then > wants to make an authorized cross-domain call to the Service Provider, > personalized to the currently logged-in user. > > I don't think one-time bearer tokens are appropriate here, because I would > need to send the user through a refresh or reacquisition flow for every call, > which kind of defeats the point. > > I am ok with this generating a non-HTTP AJAX origin request to obtain a > tokenized or signed URL; this can likely be served without significant I/O if > I have the appropriate tokens and secrets cached in memory. However, the > resulting URL must be redeemable without access to the Authorization header, > as I'm going to need to include it in a <script> tag (equivalently, make the > JSONP call with a script insert against the origin that redirects to the > authorized resource -- again, no access to the Authorization header). > > For scale reasons, I don't want to proxy the call through my origin; that > holds the origin request open while I am waiting for the Service Provider to > return. > > Cookies don't work here, because I as the origin can't set cookies for the > SP's domain. > > As I think about it here, I don't think bearer tokens are appropriate, as they > require SSL for this sequence to work. > > While I can appreciate that the spec is much simpler without the query > parameter signatures, I think I'm back to needing to be convinced that my use > case can be addressed without them and with similar operational and scaling > characteristics to what is available in OAuth 1.0a. > > "As simple as possible, but no simpler." > > Jon > ........ > Jon Moore > > > On Apr 11, 2010, at 3:06 PM, "Torsten Lodderstedt" <[email protected]> > wrote: > >> I don't know if we are really done. Does the current draft already consider >> one-time tokens? How does a client acquire one-time tokens? >> >> Moreover, I would prefer the signature solution because of the increase in >> load caused by the acquisition of multiple one-time tokens. >> >> Apart from that, another possible solution occured to me. Would it be >> possible to use a cookie containg a token instead of constructing URLs >> carrying different tokens? >> >> The origin server could acquire an ordinary bearer token and store it within >> a cookie. If the JavaScript code sends HTTP requests and the target domain >> matches the browser should automatically add the cookie to every call thus >> sending the token with every request. The origin server would need to refresh >> the token periodically in order to prevent abuse of the token. >> >> Would this work? >> >> regards, >> Torsten. >> >> Am 10.04.2010 15:13, schrieb Moore, Jonathan: >>> >>> Ok, thanks - I was missing the possibility that bearer tokens could be >>> single use. I agree this covers my use case adequately, so I am now >>> definitely +1 for simplifying the spec in this way. >>> >>> >>> >>> >>> Thanks for bearing (pun intended) with me. >>> >>> >>> >>> >>> Jon >>> >>> ........ >>> Jon Moore >>> >>> >>> >>> >>> >>> >>> On Apr 10, 2010, at 3:30 AM, "Torsten Lodderstedt" <[email protected] >>> <mailto:[email protected]> > wrote: >>> >>> >>> >>>> >>>> From my point of view, your use case can be implemented in two ways >>>> >>>> 1) tokenized & signed URLs provided by your origin server >>>> 2) URLs with one-time usage bearer tokens as parameter acquired by your >>>> origin server >>>> >>>> I see the following pros/cons: >>>> >>>> Load: (2) requires the origin server to acquire one token per link on your >>>> page from the auth server, which may cause a lot of load on the authz >>>> server :-(. (1) only needs to obtain a single token since the signature is >>>> calculated by the origin server locally. This might be much better from a >>>> load perspective. >>>> >>>> Security: As a further downside (2) either requires HTTPS communication for >>>> the whole page or you acquire the URL with one-time usage bearer token over >>>> HTTP. Acquisition from authz server can still be performed over HTTPS. If >>>> this acceptable depends on your security considerations. >>>> >>>> Comments? >>>> >>>> regards, >>>> Torsten. >>>> >>>> Am 10.04.2010 03:34, schrieb Moore, Jonathan: >>>>> >>>>> However, this doesn't address my earlier use case of a signed, >>>>> cross-domain JSONP call, especially if it's sitting on a non-HTTPS page; I >>>>> need to make a non-HTTP XHR request to obtain a (signed or tokenized) URL >>>>> to include in my <script> include, so requiring a bearer token and SSL >>>>> basically forces me to have the whole page delivered over HTTPS, which may >>>>> be overkill for my application. >>>>> >>>>> >>>>> >>>>> >>>>> While I can understand that token and secret acquisition might need SSL, >>>>> always requiring it on authorized requests too seems too much. >>>>> >>>>> >>>>> >>>>> >>>>> Can someone explain/re-explain why query parameter signatures need to be >>>>> eliminated? The Authorization header is great when you can manipulate it, >>>>> but you can't always. Why is it problematic for the signatures to be able >>>>> to appear in either place? >>>>> >>>>> >>>>> >>>>> >>>>> Jon >>>>> >>>>> >>>>> ........ >>>>> Jon Moore >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Apr 9, 2010, at 1:39 PM, "Eran Hammer-Lahav" <[email protected] >>>>> <mailto:[email protected]> > wrote: >>>>> >>>>> >>>>> >>>>>> >>>>>> In practice this is the same as logging in which I expect to require SSL >>>>>> anyway. Signed or not, attackers should not be able to login to your >>>>>> email account simply by using a MITM attack when you click on your IM >>>>>> client. So SSL is required already. >>>>>> >>>>>> EHL >>>>>> >>>>>> >>>>>> On 4/9/10 7:30 AM, "George Fletcher" <[email protected] >>>>>> <mailto:[email protected]> > wrote: >>>>>> >>>>>> >>>>>>> Yes, this is possible, though to be secure it should really happen over >>>>>>> SSL which is less of a requirement for a signed request. >>>>>>> >>>>>>> I guess the main question is whether we really need to remove the >>>>>>> signature related parameters from URL and only allow them in the >>>>>>> Authorization header. For signed requests, these use cases pretty much >>>>>>> require that the signature parameters be allowed in the URL. >>>>>>> >>>>>>> Obviously, if we change our model to not use signed URLs then this issue >>>>>>> goes away:) >>>>>>> >>>>>>> Thanks, >>>>>>> George >>>>>>> >>>>>>> On 4/9/10 12:58 AM, Brian Eaton wrote: >>>>>>> >>>>>>>> >>>>>>>> On Thu, Apr 8, 2010 at 7:08 AM, George Fletcher <[email protected] >>>>>>>> <mailto:[email protected]> > <mailto:[email protected] >>>>>>>> <mailto:[email protected]> >  wrote: >>>>>>>>   >>>>>>>>  >>>>>>>> >>>>>>>> >>>>>>>> I realize that these sorts of use cases are trivial if establishment of >>>>>>>> the >>>>>>>> SSO session switches from a signed mechanism to the OAuth WRAP bearer >>>>>>>> token >>>>>>>> model. The one nice feature of the signed URL is that it is one time >>>>>>>> use >>>>>>>> where the bearer token can be replayed multiple times. >>>>>>>>     >>>>>>>>  >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Yep, Google does this kind of thing too. >>>>>>>> >>>>>>>> Is there something that stops you from declaring that a particular >>>>>>>> token is single use? >>>>>>>> >>>>>>>> 1) Client makes call to Authorization server, passing in either the >>>>>>>> refresh token or an access token (depending on the security model you >>>>>>>> want.) >>>>>>>> 2) AS returns a token. >>>>>>>> 3) Client uses the token to pop open a web browser. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Brian >>>>>>>> >>>>>>>>   >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OAuth mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>>> >>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> OAuth mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://www.ietf.org/mailman/listinfo/oauth >>>>> <https://www.ietf.org/mailman/listinfo/oauth> >>>>> >>>>> >>>> >>>> >>>> >> > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
