Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

There is nothing wrong with telling people that they should prevent CSRF attacks :-) But there is no explicit state parameter in OAuth 1.0a.  Do you think that implementors of 1.0a, just by reading section 11.14, are aware of the danger of Login CSRF and can figure out how to prevent it, using

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

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 at

Re: [OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03

Hi Mike, In section 3.2 you say: > To deal with token redirect, it is important for the > authorization server to include the identity of the intended > recipients, namely a single resource server (or a list of > resource servers). You should add that each resource server must verify that it is

Re: [OAUTH-WG] OAuth Bearer Token draft

2.0 does not use this parameter. Only the bearer token draft uses it. If you have an issue with that, feel free to change that parameter name for bearer token requests. The MAC draft does not support protected resources requests via the query or post parameters, only the header. EHL > -Ori

Re: [OAUTH-WG] Indicating origin of OAuth credentials to combat login CSRF

Hi James, You raise an interesting point.  I hadn't thought about the threat of Login CSRF. > Q. Should an OAuth client app list the authorization server > in the Origin header of requests to resource servers? > > In OAuth (delegation) flows a server dynamically issues > credentials (such as a b

Re: [OAUTH-WG] OAuth Bearer Token draft

On Fri, Feb 25, 2011 at 3:03 PM, Eran Hammer-Lahav 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 mailing list OAut

Re: [OAUTH-WG] OAuth Bearer Token draft

'oauth_token' is limited to bearer tokens only. It is not suitable for anything else. It is a hack and should be treated as such. The right (extensible) solution is to use the HTTP Authorization header, which comes with its own extensibility model. EHL From: oauth-boun...@ietf.org [mailto:oaut

Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry

OAuth 2.0 defines two endpoint, each with a set of error codes. These codes are not extensible and therefore do not require a registry. If you want to allow error code extensibility, you need to make the case for that with requirements and use cases. I have not seen any. My API uses the 'positi

Re: [OAUTH-WG] OAuth Bearer Token draft

Mike, Thanks, I just noticed you addressed the change to "BEARER" in draft 03 (just published). I could live with the parameter name oauth_token, provided we can sub-type (rather then be generic). E.g. GET /resource?oauth_token=BEARER+vF9dft4qmT Either way, I suspect this is a breaking chang

Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry

I see a problem with collision of error codes. I believe that the working group will likely concur. I agree that it is odd for the bearer token specification to impose requirements upon the framework specification. Hence my editorial request for you to incorporate these registry additions int

Re: [OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry

I don't see a point in an error registry (and I find it odd for the Bearer token specification to impose any requirements of the protocol specification). Registries are created to prevent namespace collision. I don't see real problem with collision of error codes, especially not for a while. Th

Re: [OAUTH-WG] OAuth Bearer Token draft

Hi Phil, Yes, per the working group vote, we decided on the name "Bearer". This name is used in the just-published draft -03. This draft did not change the oauth_token parameter name; as editor, I am not introducing breaking changes at this point unless directed to do so by a vote of the work

[OAUTH-WG] OAuth Errors Registry and OAuth Parameters Registry

I wanted to explicitly call out that draft -03 of the Bearer Token Specification establishes the OAuth Errors registry to increase interoperability among the related OAuth specifications. Eran, when you produce draft -14 of the framework specification, please register the errors in the specifi

[OAUTH-WG] OAuth 2.0 Bearer Token Specification draft -03

I've published draft 03 of the OAuth Bearer Token Specification. It contains one breaking change relative to draft 02

[OAUTH-WG] I-D Action:draft-ietf-oauth-v2-bearer-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Authentication Protocol Working Group of the IETF. Title : The OAuth 2.0 Protocol: Bearer Tokens Author(s) : M. Jones, et al. Filename

Re: [OAUTH-WG] OAuth Bearer Token draft

My two cents: We've already taken three user visible outages because the OAuth2 spec reused the "oauth_token" parameter in a way that was not compatible with the OAuth1 spec. Luckily they were all caught before they caused serious damage. Generic parameter names are not useful. They lead to con

[OAUTH-WG] OAuth Bearer Token draft

There was some discussion on the type for the authorization header being OAUTH / MAC / BEARER etc. Did we have a resolution? As for section 2.2 and 2.3, should we not have a more neutral solution as well and use "authorization_token" instead of oauth_token. The idea is that the parameter corres