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.
Vo
>> 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 previo
>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
+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
>> 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,
Authoriz
: 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 counte
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: Loddersted
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 "authorizatio
Ok, thanks
> -Ursprüngliche Nachricht-
> Von: Barry Leiba [mailto:barryle...@computer.org]
> Gesendet: Freitag, 22. Juli 2011 16:51
> An: Lodderstedt, Torsten
> Cc: Eran Hammer-Lahav; OAuth WG
> Betreff: Re: [OAUTH-WG] Request to close issues
>
> > What abou
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 [mailto:barryle...@comp
uthorization shows up in his service providers account 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; o
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
limit
> -Ursprüngliche Nachricht-
> Von: Marcus Better [mailto:mar...@better.se]
> Gesendet: Mittwoch, 29. Juni 2011 11:58
> An: oauth@ietf.org
> Betreff: Re: [OAUTH-WG] Resource Owner Password Credentials
> question/feedback
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2011-06-28
+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 c
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 was
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
clie
+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
mailto:e...@hueniverse.com>> wrote:
I would like to add a quick discussion of acces
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
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
>
> Through registration and redirect URI validation. A native app does
> not have to impersonate, they can just register a user-agent client.
> Everything boils down to the user trusting the app. As Breno mentions,
> nothing the spec can do to help with that.
It could recommend the authorization
che 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, Lodde
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 auth
Hi Eric,
>- when a client requests an access token, with grant type "password" for
>>example, can the authorization server resend the same refresh token from >the
>last time the same client/resource owner combination requested an >access
>token ? That would prevent the auth database from being
23 matches
Mail list logo
