Thanks! That sounds great.
On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav wrote:
> This is clearly a third flow - hybrid (of user-agent and web-server) - and
> not just a variant of the user-agent flow. It should be presented with its
> own flow diagram and description. I also think the user-
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
That's even worse I think, it's a harder problem. Why do we want to
revoke previously issued tokens here? It closes one door but opens a
DOS attack.
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent
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
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
I agree with the below.
To be clear, the case where we had a problem with this is a 3 legged flow,
where we as the 3rd party direct a user through an auth flow to be redir3ected
back to us. In this case it's nto the browser specifying, it's the
partner/integrator with a service.
_
I'm only using 2828 definition of capability, not password.
EHL
On 7/13/10 3:20 PM, "Zachary Zeltsan"
wrote:
According to the RFC 2828 an access token is rather a capability than a
password. The passwords are usually associated with the matching identifiers,
but an access token of OAuth 2.0
On Tue, Jul 13, 2010 at 9:46 AM, Yaron Goland wrote:
> As defined in section 4.2 of RFC 2616 the only characters legally allowed in
> a HTTP header are a fairly small subset of ASCII.
I don't think that is correct. The definition of the TEXT rule in
section 2.2 allows most octets. It also refere
According to the RFC 2828 an access token is rather a capability than a
password. The passwords are usually associated with the matching identifiers,
but an access token of OAuth 2.0 is used as a single credential that allows
access to a protected resource.
>From RFC 2828:
$ password
On Tue, Jul 13, 2010 at 3:00 PM, Eran Hammer-Lahav wrote:
> In an attempt to accommodate Brian's request for more concentrated flow
> descriptions, I am working on coming up with come middle ground between -05
> and -10.
Thank you!
___
OAuth mailing lis
This is clearly a third flow - hybrid (of user-agent and web-server) - and
not just a variant of the user-agent flow. It should be presented with its
own flow diagram and description. I also think the user-agent and web-server
flow names are misleading. They need to be replaced with more descriptiv
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
This is how OAuth works: The client wants to access a protected resource. The
resource requires authentication (that's the definition of protected). The
client presents the access token to authenticate (using an HTTP authentication
header). The access token has all the security characteristics o
On Tue, Jul 13, 2010 at 2:06 PM, Eran Hammer-Lahav wrote:
> This looks reasonable, however, I am no longer see the value in the
> hybrid mode of token and code. If the code is passed in the fragment, the
> client has to pass it to the server. If that is the case, why can’t the
> server reply back
This looks reasonable, however, I am no longer see the value in the hybrid mode
of token and code. If the code is passed in the fragment, the client has to
pass it to the server. If that is the case, why can't the server reply back
with the access token? Is the entire purpose just a performance
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
YES!!!
Brian, could you please add this?
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
wrote:
In this case, the term "capability" MUST be defined up front. The word
"capability" seems to carry a much broader meaning than password...
It has a standard defini
On Jul 13, 2010, at 4:06 PM, Blaine Cook wrote:
> On 13 July 2010 20:31, John Kemp wrote:
>> Where is that specified? Is that required for all implementations?
>
> It's not specified - I was referring to your earlier comments:
>
>> In the "bearer token" case (and even over SSL unless client ce
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.
> >
>
I'll work with this text.
EHL
On 7/13/10 1:35 PM, "Brian Eaton" wrote:
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that the
> "capability" actually meant something like "pas
On Tue, Jul 13, 2010 at 1:40 PM, Igor Faynberg
wrote:
> In this case, the term "capability" MUST be defined up front. The word
> "capability" seems to carry a much broader meaning than password...
It has a standard definition we can reference. From
http://www.ietf.org/rfc/rfc2828.txt
$ capab
In this case, the term "capability" MUST be defined up front. The word
"capability" seems to carry a much broader meaning than password...
Igor
Brian Eaton wrote:
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
Don't leak it, and treat it as though it were a
password", then we avoid h
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 Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook wrote:
> Don't leak it, and treat it as though it were a
> password", then we avoid having to explain (embarrassingly) that the
> "capability" actually meant something like "password".
For the initiated, that's what "capability" means.
How about this
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 13 July 2010 20:31, John Kemp wrote:
> Where is that specified? Is that required for all implementations?
It's not specified - I was referring to your earlier comments:
> In the "bearer token" case (and even over SSL unless client certs are used),
> the
> token clearly SHOULD NOT be used as
On Tue, Jul 13, 2010 at 11:17 AM, Brian Eaton wrote:
> On Tue, Jul 13, 2010 at 9:42 AM, David Recordon
> wrote:
> >> That strikes me as very odd - returning some params in the query, and
> >> others in the fragment is just weird.
> >
> > I actually think that you want this – albiet odd – combina
On Jul 13, 2010, at 3:03 PM, Blaine Cook wrote:
> +1 on "like a password", or something similar-and-meaningful because
> that's exactly how it's being used here. Pre-shared key, shared
> secret, etc, would be fine. Keep in mind that authentication *will be
> done* using the bearer token, and the b
I think the spec should address this. I don't think it needs to go back to -06
format. There is a middle ground.
Also, keep in mind that the current format is much easier for those
implementing multiple flows or servers.
The important part is to make the spec instructive, not to optimize line
Brian's brought up the point that the new organization would cause an
implementor to have to jump all around the spec to find all the parts needed. I
propose that the working group work on a set of "implementor guides" that
detail exactly what parts one needs to deal with all of the major use ca
+1 on "like a password", or something similar-and-meaningful because
that's exactly how it's being used here. Pre-shared key, shared
secret, etc, would be fine. Keep in mind that authentication *will be
done* using the bearer token, and the bearer token alone.
An OAuth token is unlike capabilities
On Tue, Jul 13, 2010 at 11:53 AM, Blaine Cook wrote:
> I don't claim to fully grok what the current state of the various
> proposals are regarding the user agent flow, but fundamentally,
> shouldn't we be aiming to replicate what Twitter and Facebook are
> already doing?
Yes. They are passing al
On Jul 13, 2010, at 2:46 PM, Richer, Justin P. wrote:
>>> I would be very unhappy if we equated access tokens with passwords.
>>>
>>> I agree with Dirk that "capability" is a more expressive phrase than either
>>> "shared secret" or "password".
>
>> Expressive to you and people well-versed in se
I don't claim to fully grok what the current state of the various
proposals are regarding the user agent flow, but fundamentally,
shouldn't we be aiming to replicate what Twitter and Facebook are
already doing?
We've already moved towards JSON as a standard format, why not go all
the way and manda
>> I would be very unhappy if we equated access tokens with passwords.
>>
>> I agree with Dirk that "capability" is a more expressive phrase than either
>> "shared secret" or "password".
> Expressive to you and people well-versed in security theory. It means
> nothing to a casual reader. The token
Hi Eran,
On Jul 13, 2010, at 1:40 PM, Eran Hammer-Lahav wrote:
>
> On 7/13/10 10:25 AM, "John Kemp" wrote:
>
>> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>>
>>> I am ok replacing it with Oacts as a password¹.
>>
>> An access token is something used by the server to decide whethe
Isn't that better overall than requiring the browser to make another HTTP
request to pass the code over?
EHL
On 7/13/10 11:17 AM, "Brian Eaton" wrote:
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon wrote:
>> That strikes me as very odd - returning some params in the query, and
>> others in
The only other thing I could think of to suggest would be to change
the spec to state that an authorization server MUST NOT rely on Cookie
or Authorization headers from the user-agent during the end-user
redirect phase as being safe for use in authentication.
To me, at least, it seems obvious
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon wrote:
>> That strikes me as very odd - returning some params in the query, and
>> others in the fragment is just weird.
>
> I actually think that you want this – albiet odd – combination when
> requesting both a code and token. The code and state pa
On 7/13/10 10:25 AM, "John Kemp" wrote:
> On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
>
>> I am ok replacing it with Oacts as a password¹.
>
> An access token is something used by the server to decide whether a request is
> authorized. Although it may also be used for authenticating
I can live with SHOULD.
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org]
> On Behalf Of Eran Hammer-Lahav
> Sent: Tuesday, July 13, 2010 10:30 AM
> To: Colin Snover; David Recordon
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] ' force_auth' request parameter
On 7/13/10 10:24 AM, "Colin Snover" wrote:
> The problem I see with pushing this up into an identity layer is that
> providers that choose to implement their own identity layer (or no identity
> layer) may still end up doing this implicit authorization thing. We¹re neither
> providing a sp
User authentication and approval interaction has always been the sole domain of
the authorization server. This proposal shifts the decision towards the client.
It is unclear to me why is the client better suited to make this decision? In
the context of identity, if a client relies on the server
On Jul 13, 2010, at 12:02 PM, Eran Hammer-Lahav wrote:
> I am ok replacing it with ‘acts as a password’.
An access token is something used by the server to decide whether a request is
authorized. Although it may also be used for authenticating the request(er),
it's purpose is to authorize the r
The problem I see with pushing this up into an identity layer is that
providers that choose to implement their own identity layer (or no
identity layer) may still end up doing this implicit authorization
thing. We’re neither providing a specific identity to connect nor are we
requesting ident
I agree it changes the boundaries. I think this one needs moving. As I said
we hit a significant problem with this, which we solved by virtue of the fact
that the target we were working with has an un-crumbed logout, so we could XSRF
the logout.
It's something people get wrong and we should
The question is if we have consensus to force providers to support it.
It seems to overstep the boundaries we set over the years and it makes
assumptions about how services authenticate users and obtain approvals.
EHL
On Jul 13, 2010, at 13:05, William Mills
mailto:wmi...@yahoo-inc.com>> wrot
I think it's a mistake not to have force_auth in the core.
From: David Recordon [mailto:record...@gmail.com]
Sent: Tuesday, July 13, 2010 9:58 AM
To: William Mills
Cc: Colin Snover; Eran Hammer-Lahav; OAuth WG
Subject: Re:
+1, though I would like to see it to be a little more specific. Essentially
there are four states. 'accept' (allow all cookies and consent as present in
browser - for example how Facebook currently works), 'consent' (accept login,
but still prompt for the allow/deny consent - for example, how
I support immediate and a form of forced auth (ala OpenID's PAPE) but not in
the core spec. They both should be part of an identity extension.
On Tue, Jul 13, 2010 at 9:51 AM, William Mills wrote:
> I agree with Colin that some form of force_auth is needed. I haven't
> read enough on the "imm
+1
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Eran Hammer-Lahav
Sent: Tuesday, July 13, 2010 7:21 AM
To: Brian Eaton; OAuth WG; b...@google.com
Subject: Re: [OAUTH-WG] expired_token error code
I agree with Colin that some form of force_auth is needed. I haven't read
enough on the "immediate" proposal, but I know that we have run into the
problem of trusting currently set cookies in the browser (even when we're
actually sending a username/password and really do want to have an
authen
As defined in section 4.2 of RFC 2616 the only characters legally allowed in a
HTTP header are a fairly small subset of ASCII. So if we want to shove in
Unicode characters they will have to be encoded in a form that only uses
characters that are legal in the subset of ASCII supported by HTTP.
>
On Tue, Jul 13, 2010 at 1:06 AM, Luke Shepard wrote:
> I just read this bit:
>
>If the response type is "code_and_token", the authorization server
>adds the "code" and "state" parameters to the redirection URI query
>component and the "access_token", "scope", and "expires_in" to the
>
Building consensus around new ideas is tough. The only advice I can give you is
to identify the people most likely to support this idea and ping them off-list
to try and get their support. I don't think it belongs in core because core
currently represents pretty solid consensus on the feature se
On 22/07/28164 13:59, Eran Hammer-Lahav wrote:
The following was submitted via the shared-copy page but does not
belong with editorial feedback. This needs to be discussed and
supported on the list before added the specification. I think it
belongs where 'immediate' is specified.
EHL
--
New text:
Clients access protected resources by presenting an access token to the
resource server.
Access tokens are bearer tokens, where the token string acts as a
password. This requires
treating the access token with the same care as other passwords. Access
tokens SHO
I am ok replacing it with 'acts as a password'.
EHL
On 7/13/10 8:55 AM, "Dirk Balfanz" wrote:
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote:
>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The
On Tue, Jul 13, 2010 at 7:18 AM, Eran Hammer-Lahav wrote:
> From the client's perspective, they are 'shared symmetric secrets' because
> the client has to store them as-is and present them as-is. The act exactly
> like passwords. I added that text to make that stand out.
>
> When using passwords,
I tend to agree with Eran, although it should be qualified that a token
is BASED on a shared secret, rather than is a shared secret itself. (By
the way, I think the word "symmetric" is redundant here.).
I also think that the text in the Security Considerations must contain
the last paragraph o
On 7/13/10 1:06 AM, "Luke Shepard" wrote:
>
> On Jul 11, 2010, at 6:37 AM, Eran Hammer-Lahav wrote:
>
>> The server can¹t trust what the client is asking unless the client is
>> authenticated *and* the server can trust that authentication (i.e. Client
>> secret not used in a user-agent). For
+1
On Sun, Jul 11, 2010 at 12:15 AM, Brian Eaton wrote:
> I think it would be a good idea to return to the draft 6 organization.
>
> Draft 6: normative language for each flow was called out separately,
> and was described from start to finish, in chronological order, with
> no interruption. Eac
I think the profiles section is mostly useless in helping developers pick the
right profile unless they are clearly a JS browser client or a client running
on a well-protected web server. We have blurred the lines so much in when each
profile should/could be used, that a new reader will be lost.
On 7/12/10 11:22 PM, "Brian Eaton" wrote:
> On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav
> wrote:
>> I think the way to solve it is to make them more detailed and normative.
>> This will retain the general framework as current specified, but will
>> provide a reference-able description
I'm fine with this. Any objections?
EHL
On 7/12/10 11:01 PM, "Brian Eaton" wrote:
http://tools.ietf.org/html/draft-ietf-oauth-v2-10#section-5.2.1
The "expired_token" error code doesn't scale well and won't be
implemented reliably. It should be merged with "invalid_token".
Suggested language
>From the client's perspective, they are 'shared symmetric secrets' because
the client has to store them as-is and present them as-is. The act exactly
like passwords. I added that text to make that stand out.
When using passwords, the server doesn't need to store them in plain-text
either (e.g. us
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
I'd like to propose the addition of two more optional parameters to this
extension:
instance_name
Short, human-readable name that the server SHOULD display to
the end-user along with the client name. This name is designed
to reflect a per-instance identifier for cases where a single us
On Jul 11, 2010, at 6:37 AM, Eran Hammer-Lahav wrote:
The server can’t trust what the client is asking unless the client is
authenticated *and* the server can trust that authentication (i.e. Client
secret not used in a user-agent). For that, you need to establish some form of
trust with the cl
Minor language change request. We have seen much more demand for use of the
user-agent flow in mobile apps than in desktop apps in the past month. I think
that the spec should address that.
Instead of this:
1.4.3. Native Application
Native application are clients running as native code o
74 matches
Mail list logo
