Re: [OAUTH-WG] xAuth use in OAuth2.0?

Perfect ! Thanks Aaron From: Aaron Parecki [mailto:aa...@parecki.com] Sent: Wednesday, January 12, 2011 5:09 PM To: OAuth@ietf.org Cc: Jitesh Bhate Subject: Re: [OAUTH-WG] xAuth use in OAuth2.0? Jitesh, See section 5.1.2 of the D

Re: [OAUTH-WG] xAuth use in OAuth2.0?

Jitesh, See section 5.1.2of the Draft 11 spec which provides a way to exchange the resource owner's username and password for an access token. This is probably what you're looking for. Aaron On Wed, Jan 12, 2011 at 1:22 PM, Jite

Re: [OAUTH-WG] Re-Chartering: What Items to work on?

Am 12.01.2011 22:19, schrieb Richer, Justin P.: Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the cli

Re: [OAUTH-WG] Re-Chartering: What Items to work on?

Yes, let the server do the work. In practice, it's going to be looking up the token based on the token value anyway (for bearer tokens, at least). All the client really cares about is asking to "revoke this token that I am sending you". If the client credentials and token are correct and verifia

[OAUTH-WG] xAuth use in OAuth2.0?

Is there any provision in OAuth2.0 specs. to use xAuth to exchange a username and password for an OAuth access token? Something twitter does using OAuth 1.0 http://dev.twitter.com/pages/xauth Regards Jitesh ___ OAuth mailing list OAuth@ietf.org https:

Re: [OAUTH-WG] OAuth MAC token type draft

Ok, understood, I had a proxying server with another address in mind. You assume an attack on unencrypted channels, which could by prevented using HTTPS (as Eran described). regards, Torsten. Am 12.01.2011 22:12, schrieb Zeltsan, Zachary (Zachary): It should not fail because the intercepte

Re: [OAUTH-WG] OAuth MAC token type draft

It should not fail because the intercepted signed request included the hostname and port of the real resource server. Zachary From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net] Sent: Wednesday, January 12, 2011 3:40 PM To: Eran Hammer-Lahav Cc: Zeltsan,

Re: [OAUTH-WG] Re-Chartering: What Items to work on?

thank you for your feedback. So you would suggest to let the authorization server auto-detect the correct type? regards, Torsten. Am 12.01.2011 15:43, schrieb Richer, Justin P.: I don't quite understand the need for "token_type" in the request. The token being presented is going to have a t

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

+1 for option 2 because it will facilitates security analysis of the protocol. From a security analysis perspective, I think we need two views: 1) A structural view, describing the OAuth architecture (entities, interfaces, communication paths) and 2) a flow-oriented view, which is built based o

Re: [OAUTH-WG] OAuth MAC token type draft

Shouldn't signature verification fail on the real server because of different hostnames/ports? regards, Torsten. Am 12.01.2011 20:57, schrieb Eran Hammer-Lahav: Yes, its still open to a limited MITM attack, but the real issue is of confidentiality of the request (addressed in 6.2) or blocking

Re: [OAUTH-WG] Proposal to drop/relocate response_type=code_and_token

Am 12.01.2011 01:43, schrieb Brian Eaton: On Tue, Jan 11, 2011 at 2:44 PM, Torsten Lodderstedt 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

Re: [OAUTH-WG] OAuth MAC token type draft

Yes, its still open to a limited MITM attack, but the real issue is of confidentiality of the request (addressed in 6.2) or blocking the request. The client request will either: 1. read data 2. write/delete data If the attacker executes the #1, they get to see the result (6.2). If they ex

Re: [OAUTH-WG] OAuth MAC token type draft

Eran, I still don't understand, sorry. Here is the scenario: When a principal that impersonates the resource server gets a token (already signed and ready to go, of course) it can present it to the real resource server and get access to resources. This is what I thought Torsten meant by "tok

Re: [OAUTH-WG] OAuth MAC token type draft

Eran, >> - 6.3. Spoofing by Counterfeit Servers >> The protocol does not support server authentication but it should prevent >> token abuse by the Counterfeit server, shouldn't it? > It does because the token secret is never sent. According to section 6.3 a counterfeit server may intercept clien

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

+1 for option 2. Implementing and testing against draft 5 was wonderful. On Tue, Jan 11, 2011 at 11:19 PM, Eran Hammer-Lahav wrote: > (Vote at the end, please read) > > > > Background > > > > Between draft -00 and -05 the document used a flow-based organization. This > was changed to an endpoint

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

+1 for flow based option (#2) -- it prioritizes the security implications, and then readability for a much larger audience (client developer) On 2011-01-11, at 11:19 PM, Eran Hammer-Lahav wrote: > (Vote at the end, please read) > > Background > > Between draft -00 and -05 the document used a

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

Marius makes a good point -- we probably want to avoid using language like that for part descriptions. I don't think "code" and "token" quite get it, but I don't have a better suggestion at the moment though... -- Justin From: Marius Scurtescu [mscurte..

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

+1 for option 2 as well Not convinced that naming the main flows Authenticated and Unauthenticated makes sense, I think it will only increase confusion. For example, native apps are not authenticated and they would be using the "Authenticated" flow. I think we should stick with something along the

Re: [OAUTH-WG] Specification organization (Endpoints vs. Flows) - Vote by 1/17

+1 for option 2 I see, and have always seen, the target audience as server and client developers who are likely to be working against one flow and use case at a time. Also, I disagree that the primary role of the server developer is the security considerations. In theory, you may be right, but

Re: [OAUTH-WG] Re-Chartering: What Items to work on?

I don't quite understand the need for "token_type" in the request. The token being presented is going to have a type associated with it on the server -- that is, that text blob is going to have been issued by the server as an access token or a refresh token, no matter what the client claims in t