+1
This is not too complicated for the client but improves security.
regards
Sebastian Ebling
> -Original Message-
> From: Stefanie Dronia [mailto:sdro...@gmx.de]
> Sent: Friday, September 03, 2010 9:24 AM
> To: oauth@ietf.org
> Subject: Re: [OAUTH-WG] issuing new
[OAUTH-WG] issuing new refresh tokens
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
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 yo
ensus as I was able to extract.
EHL
-Original Message-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 14, 2010 2:33 PM
To: Brian Eaton
Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] issuing new refresh tokens
On Tue, Jul 13, 2010
-
From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
Sent: Wednesday, July 14, 2010 2:33 PM
To: Brian Eaton
Cc: Kris Selden; Eran Hammer-Lahav; OAuth WG
Subject: Re: [OAUTH-WG] issuing new refresh tokens
>
> On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
> wrote:
Am 15.07.2010 07:14, schrieb Brian Eaton:
...
My use cases for this are a little different.
1) I'm interested in the two-legged flows as well as three-legged flows.
For example, imagine an autonomous client that is registered once,
and then after that maintains its own key material. Regu
On Wed, Jul 14, 2010 at 2:32 PM, Torsten Lodderstedt
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 potential
> misuse because
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
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 expand on the c
On Tue, Jul 13, 2010 at 9:58 PM, Torsten Lodderstedt
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 expand on the curren
On Wed, Jul 14, 2010 at 8:25 AM, Andrew Arnott 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 confidential part
> of the sy
On Tue, Jul 13, 2010 at 2:59 PM, Brian Eaton wrote:
> the question is what happens if both the
> signing key and the token database get compromised.
>
> Now that I think of it, you may have issues if the signing key alone
> is compromised. It depends how much other entropy you've added to the
>
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.
Regards,
Torsten.
Am 14.07.2010 um 03:07 schrieb Brian Eaton :
> Kris -
>
> Thanks for pointing back to where this
Kris -
Thanks for pointing back to where this started!
I more or less agree with what Allen said in response to Torsten's
proposal: http://www.ietf.org/mail-archive/web/oauth/current/msg02295.html.
The devil is in the details.
I'd be interested in tackling client secret rotation at the same tim
Torsten Lodderstedt
[OAUTH-WG] Refresh tokens security enhancement
http://www.ietf.org/mail-archive/web/oauth/current/msg02292.html
Eran Hammer-Lahav
Re: [OAUTH-WG] Refresh tokens security enhancement
http://www.ietf.org/mail-archive/web/oauth/current/msg02390.html
On Jul 13, 2010, at 7:04 AM, Er
On Tue, Jul 13, 2010 at 2:05 PM, Andrew Arnott wrote:
> I'm not storing tokens at all. And a compromise of the database wouldn't
> expose any tokens or their hashes. I'm only storing that
> user/client/scope/issued_date tuple -- not the token itself.
And a signing key. So the question is what
On Tue, Jul 13, 2010 at 1:56 PM, Brian Eaton wrote:
> On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott
> wrote:
> > Ah, got it. Yes, we're on the same page.
> > I happen to store the authorization tuple (mentioned in another thread)
> > rather than the refresh token itself. That way I can issue
On Tue, Jul 13, 2010 at 1:46 PM, Andrew Arnott wrote:
> Ah, got it. Yes, we're on the same page.
> I happen to store the authorization tuple (mentioned in another thread)
> rather than the refresh token itself. That way I can issue an arbitrary
> number of refresh tokens for the same client/user
On Tue, Jul 13, 2010 at 1:37 PM, Brian Eaton wrote:
> On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott
> wrote:
> >> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy,
> >> these pretty much have to be backed by server-side state or there is
> >> no way to run your system.
> >
>
On Tue, Jul 13, 2010 at 1:10 PM, Andrew Arnott wrote:
>> I'm pretty sure anyone issuing cryptographic refresh tokens is crazy,
>> these pretty much have to be backed by server-side state or there is
>> no way to run your system.
>
> Brian, can you tell me what you mean by cryptographically impleme
On Mon, Jul 12, 2010 at 10:36 PM, Brian Eaton wrote:
> Draft 10 has the following sentence in section 4.1.4:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
>
> "The authorization server MAY issue a new refresh token."
>
> That carries a surprising amount of baggage. I suggest
On 7/12/10 10:36 PM, "Brian Eaton" wrote:
> Draft 10 has the following sentence in section 4.1.4:
> http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
>
> "The authorization server MAY issue a new refresh token."
The capability was there since -02.
-04 added the following text
Draft 10 has the following sentence in section 4.1.4:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-4.1.4
"The authorization server MAY issue a new refresh token."
That carries a surprising amount of baggage. I suggest removing the
sentence, or changing it to MUST NOT, pending a disc
21 matches
Mail list logo
