ssage-
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: Re: [OAUTH-WG] single use authorization codes
On Wed, Jul 14, 2010 at 11:58 AM, William Mills
wrote:
If I can see things go by on the
On Wed, Jul 14, 2010 at 2:28 PM, William Mills wrote:
> We're trying to design around transport security with short expiration
> and single use tokens. SSL solves the problem.
No, we're not, and no, it doesn't.
The issue here is not that tokens are sent over unencrypted channels,
or unauthentic
ammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] single use authorization codes
On Wed, Jul 14, 2010 at 11:58 AM, William Mills
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 bes
mmer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] single use authorization codes
>
> On Wed, Jul 14, 2010 at 11:58 AM, William Mills
> 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.
>
&g
On Wed, Jul 14, 2010 at 11:58 AM, William Mills 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 that if we do nothi
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
https://www.ietf.org/
On Tue, Jul 13, 2010 at 9:40 PM, William Mills 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 want to revoke previ
mmer-Lahav
Sent: Tuesday, July 13, 2010 9:26 PM
To: Brian Eaton; OAuth WG
Subject: Re: [OAUTH-WG] single use authorization codes
How about:
Authorization codes SHOULD expire shortly after they are issued
to
minimize the risk of leaks
I'd suggest "authorization server MAY revoke all tokens".
Revoking an access token that was just issued is surprisingly tricky.
Fast to verify, easy to revoke, scalable: pick two.
On Tue, Jul 13, 2010 at 9:26 PM, Eran Hammer-Lahav wrote:
> How about:
>
> Authorization codes SHOULD expire shortly
How about:
Authorization codes SHOULD expire shortly after they are issued to
minimize the risk of leaks. Clients MUST NOT reuse authorization
codes. If an authorization code is used more than once, the authorization
server SHOULD revoke all tokens previously issued based on that authorization
c
Draft 10 currently requires that the authorization code issued for the
web-app profile is a single use token. That won't scale well.
This got added in draft 4, I'm not sure why. Anybody know...?
Here's the relevant section:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-3
"The autho
11 matches
Mail list logo
