On Tue, Jul 13, 2010 at 9:40 PM, William Mills wmi...@yahoo-inc.com wrote:
That's even worse I think, it's a harder problem.
Revoking previously issued refresh tokens is pretty easy.
Revoking the corresponding access tokens is hard in general, but in
some environments is feasible.
Why do we
On Wed, Jul 14, 2010 at 8:25 AM, Andrew Arnott andrewarn...@gmail.com wrote:
Um, if the signing key is lost, you're sunk. Forget about the database,
with the signing key you can forge your own tokens till doomsday (which will
come much more quickly). The keys are definitely the most
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
We plan to issue new refresh tokens for certain clients only (mobile,
desktop),
it's part of the client-related policy. So the behavior for a particular
client is predictable.
Nice.
Would you be willing to
I can't parse this diagam, but here's my take:
- web server flow should always return just a code.
parameter always goes in the query string
it would be sort of reasonable to have the code exchange return
just an access token, instead of a refresh token and an access token.
Or a refresh
2 and 3 are practically most interesting imho.
(b) is interesting in that if a client application does have SSL, then it's
the simplest flow of all.
-Naitik
On Wed, Jul 14, 2010 at 5:10 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Please answer this based on actual use cases. When
If I can see things go by on the fly I can submit the token late and
mess with the user by revoking their session.
It closes one door but opens a DOS attack.
What's the DOS attack?
___
OAuth mailing list
OAuth@ietf.org
On Wed, Jul 14, 2010 at 11:58 AM, William Mills wmi...@yahoo-inc.com wrote:
If I can see things go by on the fly I can submit the token late and
mess with the user by revoking their session.
Meh.
If the best the attacker can do in those circumstances is DOS, we're
in good shape.
Bear in mind
We're trying to design around transport security with short expiration
and single use tokens. SSL solves the problem
-Original Message-
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, July 14, 2010 1:35 PM
To: William Mills
Cc: Eran Hammer-Lahav; OAuth WG
Subject:
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
We plan to issue new refresh tokens for certain clients only (mobile, desktop),
it's part of the client-related policy. So the behavior for a particular client
is predictable.
Nice.
Would you be
On Wed, Jul 14, 2010 at 2:36 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I would also like to see support for b. In this case, additional means for
client authentication should be considered.
b is token on query string?
What's the use case for that?
Yepp. That's an
Already in -10.
EHL
On Jul 14, 2010, at 14:46, Rob Richards rricha...@cdatazone.org wrote:
Finally getting a chance to catchup and respond to this thread.
Marius Scurtescu wrote:
See comments bellow...
On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia sdro...@gmx.de wrote:
Hallo
I have a question concerning the OAuth philosophy: How many resource
servers may be managed by a single OAuth authorization server? (a) A
single resource server or (b) several of them exposing different
resource types?
If the answer is (b) then how is a particular resource server identified
On Wed, Jul 14, 2010 at 11:46 AM, Rob Richards rricha...@cdatazone.org wrote:
Finally getting a chance to catchup and respond to this thread.
Marius Scurtescu wrote:
See comments bellow...
On Fri, Jul 9, 2010 at 4:27 AM, Stefanie Dronia sdro...@gmx.de wrote:
Hallo Marius,
thanks for
a - code in fragment
b - token in query
c - code and token in query
d - code and token split -10
EHL
On Jul 14, 2010, at 8:10, Eran Hammer-Lahav e...@hueniverse.com wrote:
Please answer this based on actual use cases. When returning parameters
using the redirection URI call, which of these
If your deployment is that complicated, even my discovery proposal is not going
to help you...
EHL
On Jul 14, 2010, at 18:37, Marius Scurtescu mscurte...@google.com wrote:
On Wed, Jul 14, 2010 at 3:22 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I have a question concerning the
On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
The second request (as you pointed out in your original mail) is
currently used to verify the client identity. Do you have a
suggestion for an alternate mechanism?
A digital signature over the authz request?
On Wed, Jul 14, 2010 at 2:32 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
We expected the clients to discard the old refresh token and to use the
newly issued refresh token instead. The old refresh tokens is revoked
instantly. Any attempt to use it afterwards is interpreted as a
Draft 10 switched from Token scheme in the authorization header to
OAuth. I'd rather we didn't reuse OAuth. 'OAuth2' would be great.
Token is ugly as sin, but is better than OAuth.
Spec section: http://tools.ietf.org/html/draft-ietf-oauth-v2-10#page-30
The problem with reusing OAuth is that
Did I get you right? Your answer is: Oauth is not suited for deployments with
different resource servers which rely in a single authz server?
I don't know why you categorize this as complex. Is it so unusual to have
let's say mail, webstorage, telephony, and payment services?
At Deutsche
On Wed, Jul 14, 2010 at 10:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Did I get you right? Your answer is: Oauth is not suited for deployments
with different resource servers which rely in a single authz server?
I don't know why you categorize this as complex. Is it so
Token makes sense in the context of provisioning a more general token
auth header which we overload on. That said I'm glad we're getting
simpler.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
On Behalf Of Brian Eaton
Sent: Wednesday, July 14,
We implement the second option in our SSO protocol.
Am 15.07.2010 um 01:02 schrieb Brian Eaton bea...@google.com:
On Wed, Jul 14, 2010 at 2:59 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
The second request (as you pointed out in your original mail) is
currently used to verify
Yeah ... seems like OAuth is definitely suited for different resource services
- as written, scope takes care of that. For instance Facebook offers messages,
photos, and a bunch of other services, across two different APIs (the Graph and
REST) and we distinguish permissions using scope.
As
23 matches
Mail list logo
