Hi Bart,
I think this would be a truly RESTful approach. The group discussed this topic
several months ago and consensus was to use another endpoint for token
revocation (== deletion). Pls. take a look onto
http://tools.ietf.org/html/draft-lodderstedt-oauth-revocation-02.
regards,
Torsten.
The security document designates it as Authorization code leakage through
counterfeit client
http://tools.ietf.org/html/draft-ietf-oauth-v2-threatmodel-00#section-4.4.1.7
Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 08:06
An: Lodderstedt, Torsten
: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 18. August 2011 09:17
An: Lodderstedt, Torsten; OAuth WG
Betreff: RE: Authorization Code Leakage feedback (Yaron Goland)
But it's not really a counterfeit client but a real client with modified
redirection uri. It is a counterfeit
1.3/1.4/1.5: Consider switching order to Authorization Grant, Access Token,
Refresh Token
Not sure. What do others think? I put access token first because it is a more
important term to get out of the way.
I would rather consider to change order to Access Token, Refresh Token,
Authorization
+1
-Ursprüngliche Nachricht-
Von: Barry Leiba [mailto:barryle...@computer.org]
Gesendet: Mittwoch, 17. August 2011 22:35
An: oauth@ietf.org
Betreff: Re: [OAUTH-WG] OMA Liaison Has Arrived!
I'm sorry for the delay in getting this written. Because of the
delay, the working group has just
I've read the thread leading to this, and the proposed text and I do not
understand the attack. Can you provide a step-by-step scenario of how an
attacker gains access?
I'm honestly surprised you do not understand the attack. The client simply uses
screen scraping on the authorization flow and
1.4.3. Resource Owner Password Credentials: Comment on (when
combined with a refresh token): This is the first time that refresh tokens
are mentioned in the spec. And yet there is no explanation of what they are.
I suspect they should anyway be introduced in section 1.4.1 (as previously
Text sounds very good.
wrt title: this threat is about phishing another user's authorization code.
Because of the design of the protocol this requires the attacker to use another
redirect URI than used by the legitimate client. To make this the title sound
bit weird to me. Why not
What about my comments?
http://www.ietf.org/mail-archive/web/oauth/current/msg07030.html
http://www.ietf.org/mail-archive/web/oauth/current/msg07031.html
http://www.ietf.org/mail-archive/web/oauth/current/msg07032.html
-Ursprüngliche Nachricht-
Von: Barry Leiba
No exactly the topic but also related to this grant type
There is currently no parameter the client could use to explicitly request a
refresh token. So server-policies based on user, client and scope are the only
mean to decide whether a refresh token is issued or not. I consider this to
management
screen for a certain client he never explicitly authorized for long-term access?
regards,
Torsten.
Von: Eran Hammer-Lahav [mailto:e...@hueniverse.com]
Gesendet: Donnerstag, 30. Juni 2011 10:48
An: Lodderstedt, Torsten; George Fletcher; oauth@ietf.org
Betreff: RE: [OAUTH-WG] Resource
+1 for (1)
As pointed out in another posting
(http://www.ietf.org/mail-archive/web/oauth/current/msg06723.html), I think we
have consensus on the patterns for native app implementation. So in my opinion,
we need to adjust the client authentication part to fit.
In my opinion, the authz server
The reason why I suggested the name bearer_token was to achieve a consistent
naming convention across different ways to uses those tokens (URI query, HTTP
authn scheme). Now the discussion centers around achieving a consistent naming
between token acquisition and usage. I'm basically fine with
+1
Von: Brian Eaton [mailto:bea...@google.com]
Gesendet: Mittwoch, 15. Juni 2011 20:33
An: Eran Hammer-Lahav
Cc: OAuth WG
Betreff: Re: [OAUTH-WG] Refresh tokens
On Wed, Jun 15, 2011 at 10:30 AM, Eran Hammer-Lahav
e...@hueniverse.commailto:e...@hueniverse.com wrote:
I would like to add a quick
The ability to describe a client to the user does not depend on the
authentication but on the identification of the client and the meta data
available to the authz server. The only difference between identified and
authenticated clients is the trust level the authz server has regarding the
In my perception, the main concern raised at the F2F was the absent of the
implicit grant in the text. That's what Chuck added including a discussion of
the pros and cons.
Most of the discussion in the thread you referred to was about refresh tokens
support in the implicit grant type, which
Nachricht-
Von: Marius Scurtescu [mailto:mscurte...@google.com]
Gesendet: Mittwoch, 11. Mai 2011 20:28
An: Lodderstedt, Torsten
Cc: oauth@ietf.org; Doug Tangren
Betreff: Re: [OAUTH-WG] oauth2 implicit flow user experience
On Tue, May 10, 2011 at 4:43 PM, Lodderstedt, Torsten
t.lodderst
Hi Breno,
thanks for the feedback. Please find my comments inline.
Now higher level comments:
On Native Apps protection of refresh token:
On section Definitions, there is a sentence in the Native Apps It is
assumed that such applications can protect dynamically issued
secrets,
Hi Marius,
wrt auto-approval: how is the authorization server supposed to validated the
client's identity in a reliable way? Otherwise another application (using the
id of the legitimate client) could abuse the authorization previously approved
by the user as long as the session with the
19 matches
Mail list logo
