On Mon, Nov 26, 2012 at 7:22 PM, Shane B Weeden swee...@au1.ibm.com wrote:
My understanding is that it is considered a best practice to rollover a
refresh token on each use - that is when a refresh token is used, both a
new access token and a new refresh token are issued, and the old refresh
On Fri, Nov 23, 2012 at 4:43 AM, Bob Gregory pathoge...@gmail.com wrote:
We've had OAuth2 running successfully for a while now, but we're finding
that mobile applications have frequent problems with the refresh flow where
a refresh request is made, but the network connection fails before the
On Tue, Jul 12, 2011 at 8:29 AM, William J. Mills wmi...@yahoo-inc.com wrote:
Why would you re-issue a refresh token every usage? What's the use case
where this makes sense?
It's key rotation built into the protocol. Even if a refresh token is
stolen, it's going to become useless to the
On Fri, Jul 8, 2011 at 11:39 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
How exactly? They are not confidential by nature, being received via
redirection in the URI query. I know what this sentence is trying to
accomplish but not sure how to do that with normative language. SHOULD
On Thu, Jul 7, 2011 at 10:49 AM, Anthony Nadalin tony...@microsoft.comwrote:
When we constructed the current structure in Prague we thought that
structure best fit the needs of a implementer, so my preference would be to
keep it as it is now but, Torsten / Mark / Phil also may have feedback.
On Thu, Jul 7, 2011 at 11:08 AM, Anthony Nadalin tony...@microsoft.comwrote:
I was responding to the structure question only. The token text is
questionable sine the tokens are opaque to the core, seems like the token
write-up better belongs in the threat model document. Developers of the
On Wed, Jul 6, 2011 at 1:31 PM, Justin Richer jric...@mitre.org wrote:
You can still use the access code (web server) flow within a JavaScript
application, just without a reliable client secret. The point of the
implicit flow was to save a roundtrip to the server for light clients
with
On Wed, Jun 15, 2011 at 6:19 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
Your comment was that having client authentication makes it easier to
recovery from an attack. I don’t understand how the comments below about
changing client secrets every 30 days are relevant. Are you suggesting to
On Thu, Jun 16, 2011 at 8:48 AM, Thomas Hardjono hardj...@mit.edu wrote:
Requiring client authentication doesn't defend against
attacks directly; it makes recovery after a successful
attack easier.
I presume you mean direct attacks on the authorization server.
Also attacks on the
On Wed, Jun 15, 2011 at 12:37 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
1. Why not require the registration of a redirection URI for implicit grant
requests, removing the redirect_uri parameter completely from the request
(the client can still use the state parameter)?
As others have
On Thu, Jun 16, 2011 at 10:51 AM, Eran Hammer-Lahav e...@hueniverse.comwrote:
This is nice on paper but doesn’t work.
I have to agree. It doesn't matter what the spec says on this point. No
one is going to take advice from the spec about what the text on their
approval page ought to say.
On Thu, Jun 16, 2011 at 12:42 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
-1 making client authentication required at the access token endpoint
Client authentication is useful in some situations to raise the security
level. But requiring it will either keep out native apps or
On Thu, Jun 16, 2011 at 12:56 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
Certainly not. Are we discussing to make client authentication required
just for syntactical purposes?
That is what I'd like to see.
From my perspective, no harm is done by making client authentication
On Thu, Jun 16, 2011 at 1:05 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
No, it's not simpler nor clearer. Such a client secret is useless, so the
security implications have to be explained anyway.
The issue really isn't the security implications being unclear; the issue is
On Thu, Jun 16, 2011 at 1:25 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
no I'm saying people will use real secrets and rely on them - just as with
OAuth 1.0
=)
People are going to ignore what the spec says on this. If you read through
the mailing list threads on this topic,
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
**
If those people have reasonable means in place to protect secrets on
deployment channels and in the local installation - fine. I would be eager
to learn more about those means because I would be willed to
On Thu, Jun 16, 2011 at 2:14 PM, Igor Faynberg
igor.faynb...@alcatel-lucent.com wrote:
**
On 6/16/2011 4:51 PM, Brian Eaton wrote:
On Thu, Jun 16, 2011 at 1:49 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
If those people have reasonable means in place to protect secrets
used to access protected
resources. Refresh
tokens are credentials used to obtain access tokens.
-bill
--
*From:* Brian Eaton bea...@google.com
*To:* Eran Hammer-Lahav e...@hueniverse.com
*Cc:* OAuth WG oauth@ietf.org
*Sent:* Wednesday, June 15, 2011 11:32 AM
On Wed, Jun 15, 2011 at 5:21 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
I suspect another choice of words would be useful there. Implicit grants
rely
on the browser's authentication of the receiving web site. When https is
used, that authentication is fairly strong.
authentication
On Wed, Jun 15, 2011 at 5:27 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
So basically, it is authentication on top of bearer credentials to achieve
another level of security. Are we just assuming that stealing the refresh
token will be harder than stealing the client credentials? Seems a
On Wed, Jun 15, 2011 at 3:50 PM, Shane B Weeden swee...@au1.ibm.com wrote:
Brain - can you elaborate on that a little? Are you suggesting that clients
that can't keep secrets use a dummy (notasecret) pwd anyway to satisfy
requiring client authentication?
Or use random secrets. Whatever
Agreed, it's nuts to return a refresh token for that flow.
Eran, why is this still in the spec? You agreed to remove it almost a
year ago. It's come up multiple times since then.
http://www.ietf.org/mail-archive/web/oauth/current/msg03651.html
Cheers,
Brian
On Fri, Jun 3, 2011 at 9:45 AM,
On Thu, Jun 2, 2011 at 11:40 AM, Thomas Hardjono hardj...@mit.edu wrote:
Well, not to belabor this point :) but in Kerberos it is the proof of
possession of the client secret key which _is_ the authentication mechanism.
There is also PKINIT (RFC4556) which can be used to pre-authenticate the
On Thu, Jun 2, 2011 at 12:17 PM, Thomas Hardjono hardj...@mit.edu wrote:
(a) Oauth2.0 today is designed for low-assurance environments. So I think
the WG is wasting a lot of time in trying to address whether the Client can
keep secrets. The WG should just assume that the problem of keeping
On Thu, Jun 2, 2011 at 2:31 PM, William J. Mills wmi...@yahoo-inc.comwrote:
In practice there are an extremely small number of cases where this is
actually done right, and legions of cases where it's done wrong. Industry
just doesn't get this right often enough to rely on it.
Well, rely is
On Thu, Jun 2, 2011 at 3:01 PM, Peter Saint-Andre stpe...@stpeter.imwrote:
I think I might have misunderstood that text -- I took it to be talking
about the client's authentication with the authorization server, not the
client's authentication with the resource server.
No, you understand
On Thu, Jun 2, 2011 at 5:08 PM, Peter Saint-Andre stpe...@stpeter.imwrote:
I think the SHOULD we had originally is probably fine -- with the
understanding that SHOULD means you really ought to do this unless
you have a good reason not to. I think one such really good reason
might be a
On Tue, May 31, 2011 at 10:39 PM, Kris Selden kris.sel...@gmail.com wrote:
Why can't you just revoke the refresh token for a client when you change the
client secret?
Is it not easier to revoke a token than it is to rotate the client secret
(which is usually configured or embedded in the
On Tue, May 31, 2011 at 11:41 PM, Chuck Mortimore
cmortim...@salesforce.com wrote:
It’s not entirely necessary; I’m just having a tough time figuring out any
practical difference between the implicit grant flow, and the webserver flow
with no credentials. In general I agree with your points,
On Wed, Jun 1, 2011 at 12:08 AM, Chuck Mortimore
cmortim...@salesforce.com wrote:
This is one reason we’ve favored implicit for native apps.
OK, so are you using the implicit grant for both web apps and native
apps...? I'm trying to figure out if you need two flows are three.
- web server flow
On Wed, Jun 1, 2011 at 12:15 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
I'm getting confused. This thread is about native apps. So why discuss
security considerations for web apps here?
They overlap because they both use refresh tokens. =/ When people
propose changes that impact
an admin controlled provisioning process. In this case we can also
escalate capabilities as we’re reasonably sure we’re talking to an instance
of the client.
For JS Apps we support the implicit grant with no refresh token
-cmort
On 6/1/11 12:16 AM, Brian Eaton bea...@google.com wrote
On Wed, Jun 1, 2011 at 12:47 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
- ignore the problem and leave the spec vague and insecure.
Could you please describe what you consider insecure?
As an example, optional client authentication in the authorization
code flow makes the web
On Wed, Jun 1, 2011 at 1:41 AM, Skylar Woodward sky...@kiva.org wrote:
Verifyable and Forgeable were the best terms we've come up with so far in
attempt to put a label on apps that can keep secrets and apps that can't
keep secrets, respectively.
You might be on to something there. There are
Hey Peter -
I haven't read all of your comments yet, but I wanted to clarify one point
about client impersonation and installed apps. The cuirrent text is
unrealistic, but your request would push it the wrong way. CC'ing Torsten
as well.
-
OLD:
The authorization server
On Tue, May 31, 2011 at 10:41 AM, Chuck Mortimore
cmortim...@salesforce.com wrote:
Updated in language I just sent out – thanks.
On that note, we currently return refresh_token using the implicit grant
type under certain controlled circumstances. Facebook in turn uses the
implicit grant
I just read over the whole of the draft for the first time in a while.
I looked it over mostly for
a) places where spec and reality were going to have trouble intersecting
and
b) places where security advice would be useful
and
c) grammer and speling, because I notices things like that
As I said in the other note, after reading through the security
considerations section a couple of times, I think it could benefit
from a different organization. Specifically
- keep the introduction, it’s awesome.
- write new sections for each of the following
1) Authorization Tokens
2)
Hey Andrew -
Two-legged OAuth is a very confusing term. I've tried to stop using it,
because it means so many different things to different people. I'm not 100%
sure what your use case is...
The current OAuth2 draft handles traditional client-server authentication
with the client credentials
On Mon, May 2, 2011 at 11:33 AM, Freeman, Tim tim.free...@hp.com wrote:
The issues around redirect_uri seem muddled to me.
Yeah. =/ It's unfortunate. I think the problem is that implementers
disagree on what type of redirect uri validation to do, so the spec has
papered over the
On Fri, Apr 29, 2011 at 11:21 AM, Doug Tangren d.tang...@gmail.com wrote:
Is this required or not? In the example
http://tools.ietf.org/html/draft-ietf-oauth-v2-15#section-3.1 it's listed
in the example but not itemized as optional or required. It's not in the
example for refreshing tokens
On Mon, Apr 4, 2011 at 1:06 PM, Phil Hunt phil.h...@oracle.com wrote:
Very quickly here is the attack...
1) Paul starts dance at good Client good AS, App requests authorization.
Note: outbound call is secure, but returned redirect is not.
For the record, we haven't had particular problems
...@mitre.orgmailto:jric...@mitre.org
To: William J. Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com
Cc: Brian Eaton bea...@google.commailto:bea...@google.com; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Tuesday, March 8, 2011 8:41 AM
Subject: Re: [OAUTH-WG] OAuth Bearer Token draft
I don't
On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
‘oauth_token’ is limited to bearer tokens only. It is not suitable for
anything else.
Except that OAuth 1.0 already went out using oauth_token for signed requests.
___
OAuth
I don't think the advice from the OAuth 1.0a spec is wrong:
http://oauth.net/core/1.0a/#anchor38
Cross-Site Request Forgery (CSRF) is a web-based attack whereby HTTP
requests are transmitted from a user that the website trusts or has
authenticated. CSRF attacks on OAuth approvals can allow an
On Sun, Feb 20, 2011 at 3:47 PM, Eran Hammer-Lahav e...@hueniverse.comwrote:
How do you envision this being incorporated into v2? Just section 5 or the
entire document?
My two cents: rather than dedicating a single section of the core doc to
security considerations, smaller sections should be
Has anyone stepped up to start writing security considerations yet?
Now that the organization is back to tracking different use cases
using different flows, I think it's feasible and would like to
contribute.
___
OAuth mailing list
OAuth@ietf.org
How do we reconcile Bearer with Negotiate, NTLM, Basic, and
GoogleLogin? All of those examples are widely deployed and use
bearer tokens in Authorization headers. Should all of those switch to
using the Bearer scheme as well?
Tokens issued via OAuth will require specific validation logic, for
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Can you share what the actual request looks on the wire? How are you passing
the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
On Wed, Jan 26, 2011 at 2:53 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Can you share what the actual request looks on the wire? How are you passing
the Kerberos authentication in the request? What do you set the grant type to?
Most of this pre-dates grant type and the OAuth2 brand. =)
Hey Torsten -
I'm trying to parse through these messages to figure out the flows
you're interested in.
I think you're aiming for rules like this one, right?
kerberos authentication - access token
or
digest authentication - access token
And furthermore your intended use cases are
it.
EHL
-Original Message-
From: Brian Eaton [mailto:bea...@google.com]
Sent: Wednesday, January 19, 2011 6:21 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Proposal to drop/relocate
response_type=code_and_token
On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav
e
On Tue, Jan 11, 2011 at 4:40 PM, Brian Eaton bea...@google.com wrote:
On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
But that's just an annoying implementation detail.
Yes. The user-agent flow is a set of annoying implementation details
that are very, very
On Wed, Jan 19, 2011 at 6:05 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Can I take this as an endorsement for dropping it? It feels very experimental
and should be easy to add as an extension.
I defer to the several other people who were interested in this
approach. From memory, that's
On Wed, Jan 19, 2011 at 6:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Will this HTML5 magic involve making a single authorization request
(redirection) or two?
It's not magic, it's window.postMessage().
It's an authenticated low-latency channel between windows or iframes.
There is
On Wed, Jan 19, 2011 at 6:14 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Since no one else (other than you) showed any interest in keeping this
section in for the past 9 days, I assume they don't care. I will remove this.
This is an unfortunate assumption, and I think it could do serious
On Tue, Jan 11, 2011 at 12:45 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
The exact same argument can be made that the hybrid flow meets all the use
cases of the web-server flow... which means we can keep the current single
flow specification as is... :-)
What am I missing? (I'm
On Tue, Jan 11, 2011 at 1:21 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
But that's just an annoying implementation detail.
Yes. The user-agent flow is a set of annoying implementation details
that are very, very useful if you want to make the protocol efficient.
If the only different
On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
Do you see any need to restrict the power of this token or is it as powerful
as the tokens obtained using the code? I'm asking because this token is sent
out without authenticating the client whereas exchange of
On Mon, Jan 10, 2011 at 2:17 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
In -12, I am moving back to the -05 specification structure of profiles
(flows).
Sweet!
This means this code_and_token hybrid needs to be explained beyond
just the definition of the extra parameter and response
On Mon, Jan 10, 2011 at 2:39 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
This explains why you want the code returned in the fragment, but not why you
need both code and token in the same response, as well as any differences in
the token attributes,
The token in the same response is a
On Mon, Jan 10, 2011 at 3:06 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
What about the difference between the two access tokens? The one issued
directly and the one via the code? Are those the same? Same scope? Same
duration?
Same.
I think this needs to be presented as a separate
On Mon, Jan 10, 2011 at 3:22 PM, Phil Hunt phil.h...@oracle.com wrote:
What about the idea that the code is only used as a hand-off mechanism
between service components (e.g. authorization manager vs, resource access
manager). In that case, the code would not be usable for anything except to
On Thu, Oct 14, 2010 at 12:06 AM, Mike Jones
michael.jo...@microsoft.com wrote:
I am willing to serve as editor for the bearer token specification and have my
management's approval to do so. Furthermore, I believe that I am qualified,
having successfully served as an editor for several
Hey Aaron -
Here's some more research and recommendations for you:
http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html.
I agree with the other recommendations on this thread, probably not a
good idea for you to invent a hashing scheme
On Tue, Aug 17, 2010 at 11:36 PM, Mark Nottingham m...@mnot.net wrote:
The other reason people get funny with these status codes has to do
with browser behavior. Sometimes browsers react in funny ways to
funny HTTP status codes. To be on the safe side, developers tend to
return an HTTP 200
On Tue, Aug 17, 2010 at 11:48 AM, David Recordon record...@gmail.com wrote:
Luke's point still holds true of the core spec needing to allow a 200 status
code on an error in this scenario. I'd also rather see this as part of the
core spec as it reduces the number of things that implementors will
is for third-party.com to access printing.com. That is
what the user wants to have happen, and the service provider wants to allow
it.
Cheers,
Brian
On Thu, Aug 12, 2010 at 8:26 AM, Oleg Gryb oleg_g...@yahoo.com wrote:
- Original Message
From: Brian Eaton bea...@google.com
To: Oleg
On Wed, Aug 4, 2010 at 10:04 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
So far no one has offered to work on the security consideration section
(Brian's draft is too far from the format I need to incorporate).
I could work on this topic, if Brian does not insist to do so.
@Brian:
On Mon, Aug 2, 2010 at 10:21 PM, Oleg Gryb oleg_g...@yahoo.com wrote:
Returning to our discussion about necessity of passing access_token in URL's
fragment, I've read both your proposal for changing v.9 and the current
v.10, but still don't understand why we need access_token in a fragment.
On Mon, Aug 2, 2010 at 6:15 PM, David Stanek dsta...@dstanek.com wrote:
I just verified that the Python urllib client does send the fragment to the
server. I've created a patch and will be created a bug on the Python
tracker.
Cool, but this doesn't seem relevant to the user-agent profile.
On Tue, Jul 27, 2010 at 11:56 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
There seem to be two potential arguments against it - the burden of
tracking the state and the potential that it's unnecessarily
restrictive. I don't personally see either as being a major issue but
would like
On Mon, Jul 26, 2010 at 2:08 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
I understand that in many assertions, the client identifier is established
internally, but this approach will completely prevent using the assertion
client authentication method with other flows that involve getting a
On Mon, Jul 26, 2010 at 4:11 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
How do you link the client_id using in the authorization endpoint with the
client assertion using in the token endpoint?
In theory:
any document that defines how to use an assertion of a particular
type with OAuth
the other grant types.
-- Justin
On Sat, 2010-07-17 at 15:51 -0400, Eran Hammer-Lahav wrote:
client_credentials worked fine before. I'll just replace none with that. No
one had an issue with the name in -05.
EHL
On Jul 17, 2010, at 15:49, Brian Eaton bea...@google.com wrote:
On Sat, Jul
On Sat, Jul 17, 2010 at 11:50 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
The use case is pretty simple: the user uses the server and approves a third
party site access to their data directly (i.e. They are not sent to the
server from the client, but just use the server). The third part
On Sat, Jul 17, 2010 at 8:52 AM, Luke Shepard lshep...@facebook.com wrote:
As far as consistency, it is just a little weird to call it client password
in one
part of the spec, when it's defined as client secret elsewhere.
Agreed, we could be more consistent. The value we're talking about is
+1.
How about calling it client password, or something along those
lines...? That's what Dick called it for WRAP.
http://tools.ietf.org/html/draft-hardt-oauth-01#page-13
Cheers,
Brian
On Fri, Jul 16, 2010 at 9:39 AM, Marius Scurtescu mscurte...@google.com wrote:
I agree that grant_type=none
On Fri, Jul 16, 2010 at 9:41 AM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
then we should put those use cases and requirements on the table and try to
find a solution fulfilling these different needs. That's what (from my point
of view) standard definition is all about.
What do you
On Fri, Jul 16, 2010 at 11:21 AM, Yaron Goland yar...@microsoft.com wrote:
That's my point. The spec says Words of *TEXT MAY contain characters from
character sets other than ISO- 8859-1 [22] only when encoded according to the
rules of RFC 2047 [14]. But since RFC 2047 is a dead letter as a
On Fri, Jul 16, 2010 at 2:25 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
External, out-of-band, implicit.
It cannot be client because that is not always the case.
Can you point to a use case where someone is going to use the client
password flow to authenticate something besides a client?
. =)
(David, no offense, I'm just trying to stick by my guns on the whole
stop screwing up the spec by merging separate use cases into single
flows thing...)
On Fri, Jul 16, 2010 at 2:23 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
And that matters how?
EHL
On Jul 16, 2010, at 16:57, Brian Eaton
On Fri, Jul 16, 2010 at 3:27 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
The client authentication can be used to retrieve a grant previously arranged.
Really?
Who is going to implement that?
I'm pretty sure that if the only inputs to the protocol are a client
name and a client password,
On Wed, Jul 14, 2010 at 11:02 PM, Torsten Lodderstedt
tors...@lodderstedt.net wrote:
why that? If there will be a signature proposal for resource server access,
the same (simplified?) model could be applied to the authz server's API.
Sure. Other folks have used signed URLs in this kind of
On Thu, Jul 15, 2010 at 7:22 AM, Brian Campbell
bcampb...@pingidentity.com wrote:
The Authorization Code value MUST be constructed from
a cryptographically strong random or pseudo-random number
sequence [RFC1750] generated by the Authorization Server.
The probability of any two
On Thu, Jul 15, 2010 at 2:16 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
I must admit to never having considered the authz code as anything but
a random string as a reference that must be resolved. Can you expand
on your thinking a bit, if only to enlighten me?
Are you thinking of
On Thu, Jul 15, 2010 at 4:04 PM, Brian Campbell
bcampb...@pingidentity.com wrote:
I'm guessing you don't want any language restricting the length of the
code? Though there is some practical limit due to the URL length in
the 302 (I think it has to be a redirect).
There are certain practical
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
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
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
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:
invalid_token
The access token provided is invalid. Resource servers
SHOULD
On Sun, Jul 11, 2010 at 7:37 AM, Eran Hammer-Lahav e...@hueniverse.com 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 of useful profiles. This will also
On Tue, Jul 13, 2010 at 9:42 AM, David Recordon record...@gmail.com 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
On Tue, Jul 13, 2010 at 11:53 AM, Blaine Cook rom...@gmail.com 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
On Tue, Jul 13, 2010 at 1:06 PM, Blaine Cook rom...@gmail.com 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
1 - 100 of 181 matches
Mail list logo
