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" <tors...@lodderstedt.net
> 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" <tors...@lodderstedt.net
> 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" <e...@hueniverse.com
> 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" <gffle...@aol.com> 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
<gffle...@aol.com> <mailto:gffle...@aol.com>  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
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
