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]> Â 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
_______________________________________________
OAuth mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
