[OAUTH-WG] OAuth2 security considerations for client_id

[Karim]

Hello,

When using User-agent flow with OAuth2 for mobile platform, there is no way
for Authorization server to authenticate the client_id of the application.

So, anyone can impersonate my app by copying the client_id (and so get all
access tokens on my behalf), and this is applicable to Facebook,
Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on the
server side, and the client is authenticated using secret key.

-- 
Karim 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[Torsten Lodderstedt]

Hi,

your observation is correct. OAuth security considerations recommend not to 
rely on secrets for authenticating mobile apps (aka native apps) but to manage 
them as so-called public clients. Please take a look onto section 10 of the 
core spec for further details.

regards,
Torsten.



Karim  schrieb:

Hello,


When using User-agent flow with OAuth2 for mobile platform, there is no way for 
Authorization server to authenticate the client_id of the application.


So, anyone can impersonate my app by copying the client_id (and so get all 
access tokens on my behalf), and this is applicable to Facebook, Foursquare,...


This is not managed by OAuth2 ? Or I missed something ?


For Web applications (Web server flow), access token is stored on the server 
side, and the client is authenticated using secret key.


-- 
Karim

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[William Mills]

Yeah, certainly for Mobile clients this is true.  There are classes of clients 
(server to server implementations notably) where clientID can be a proper 
secret and be usefule for client validation.




 From: Torsten Lodderstedt 
To: Karim ; oauth@ietf.org 
Sent: Friday, January 6, 2012 5:21 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
 

Hi,

your observation is correct. OAuth security considerations recommend not to 
rely on secrets for authenticating mobile apps (aka native apps) but to manage 
them as so-called public clients. Please take a look onto section 10 of the 
core spec for further details.

regards,
Torsten.




Karim  schrieb:
Hello,
>
>
>When using User-agent flow with OAuth2 for mobile platform, there is no way 
>for Authorization server to authenticate the client_id of the application.
>
>
>So, anyone can impersonate my app by copying the client_id (and so get all 
>access tokens on my behalf), and this is applicable to Facebook, Foursquare,...
>
>
>This is not managed by OAuth2 ? Or I missed something ?
>
>
>For Web applications (Web server flow), access token is stored on the server 
>side, and the client is authenticated using secret key.
>
>-- 
>Karim
>
>
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[Justin Richer]

The important thing to realize here is that just having the client_id 
doesn't get you access tokens, and it certainly doesn't give you access 
to all access tokens issued to that client_id in the past. It does allow 
for a phishing scenario in that it will let you try to impersonate a 
known-good client by copying the client_id, but each individual user 
will still have to authorize the fake client in order for it to get a 
new access token.


But keep in mind that this doesn't expose the user's actual credentials 
to the application (on mobile especially, assuming use of external 
browsers trusted by the platform -- as has been discussed on the list 
here, a bad application could always embed a browser and try to steal 
your credentials directly, but they can do that anyway without OAuth). 
The mitigation and cleanup of fake clients like this is also simpler, 
since you can revoke tokens without much cost to users and service 
providers.


These reasons are why it's suggested to use the authorization code flow 
with mobile apps, just without a client_secret. You can lessen the 
attack vector by using a trusted and preregistered callback_uri, and 
there's even been some discussion about how to do that with cloud 
services handling the callbacks for trusted applications on the platform.


 -- Justin

On 01/06/2012 12:34 PM, William Mills wrote:
Yeah, certainly for Mobile clients this is true.  There are classes of 
clients (server to server implementations notably) where clientID can 
be a proper secret and be usefule for client validation.



*From:* Torsten Lodderstedt 
*To:* Karim ; oauth@ietf.org
*Sent:* Friday, January 6, 2012 5:21 AM
*Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id

Hi,

your observation is correct. OAuth security considerations recommend 
not to rely on secrets for authenticating mobile apps (aka native 
apps) but to manage them as so-called public clients. Please take a 
look onto section 10 of the core spec for further details.


regards,
Torsten.



Karim  schrieb:

Hello,

When using User-agent flow with OAuth2 for mobile platform, there
is no way for Authorization server to authenticate the client_id
of the application.

So, anyone can impersonate my app by copying the client_id (and so
get all access tokens on my behalf), and this is applicable to
Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on
the server side, and the client is authenticated using secret key.

-- 
Karim



___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth


___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[Paul Madsen]

William, presumably you meant 'client_secret'?

And is it fair to say that this reflects the current reality (of app 
distribution channels & OS protections) more so than any inherent mobile 
client limitation?


paul

On 1/6/12 12:34 PM, William Mills wrote:
Yeah, certainly for Mobile clients this is true.  There are classes of 
clients (server to server implementations notably) where clientID can 
be a proper secret and be usefule for client validation.



*From:* Torsten Lodderstedt 
*To:* Karim ; oauth@ietf.org
*Sent:* Friday, January 6, 2012 5:21 AM
*Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id

Hi,

your observation is correct. OAuth security considerations recommend 
not to rely on secrets for authenticating mobile apps (aka native 
apps) but to manage them as so-called public clients. Please take a 
look onto section 10 of the core spec for further details.


regards,
Torsten.



Karim  schrieb:

Hello,

When using User-agent flow with OAuth2 for mobile platform, there
is no way for Authorization server to authenticate the client_id
of the application.

So, anyone can impersonate my app by copying the client_id (and so
get all access tokens on my behalf), and this is applicable to
Facebook, Foursquare,...

This is not managed by OAuth2 ? Or I missed something ?

For Web applications (Web server flow), access token is stored on
the server side, and the client is authenticated using secret key.

-- 
Karim



___
OAuth mailing list
OAuth@ietf.org 
https://www.ietf.org/mailman/listinfo/oauth




___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[William Mills]

Yeah, I sure did.  Client ID being the moral equivalent of user agent string in 
a browser.




 From: Paul Madsen 
To: William Mills  
Cc: Torsten Lodderstedt ; Karim 
; "oauth@ietf.org"  
Sent: Friday, January 6, 2012 9:48 AM
Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
 

William, presumably you meant 'client_secret'?

And is it fair to say that this reflects the current reality (of app
distribution channels & OS protections) more so than any
inherent mobile client limitation?

paul

On 1/6/12 12:34 PM, William Mills wrote: 
Yeah, certainly for Mobile clients this is true.  There are classes of clients 
(server to server implementations notably) where clientID can be a proper 
secret and be usefule for client validation.
>
>
>
>
>
> From: Torsten Lodderstedt 
>To: Karim ; oauth@ietf.org 
>Sent: Friday, January 6, 2012 5:21 AM
>Subject: Re: [OAUTH-WG] OAuth2 security considerations for client_id
> 
>
>Hi,
>
>your observation is correct. OAuth security considerations
  recommend not to rely on secrets for authenticating mobile
  apps (aka native apps) but to manage them as so-called
  public clients. Please take a look onto section 10 of the
  core spec for further details.
>
>regards,
>Torsten.
>
>
>
>
>Karim  schrieb: 
>Hello,
>>
>>
>>When using User-agent flow with OAuth2 for mobile platform, there is no way 
>>for Authorization server to authenticate the client_id of the application.
>>
>>
>>So, anyone can impersonate my app by copying the client_id (and so get all 
>>access tokens on my behalf), and this is applicable to Facebook, 
>>Foursquare,...
>>
>>
>>This is not managed by OAuth2 ? Or I missed something ?
>>
>>
>>For Web applications (Web server flow), access token is stored on the server 
>>side, and the client is authenticated using secret key.
>>
>>
-- 
>>Karim
>>
>>
>___
>OAuth mailing list
>OAuth@ietf.org
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
>
>___
OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth ___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] OAuth2 security considerations for client_id

[Karim]

The term "trusted client" is not applicable to mobile devices as they
cannot keep secret.
I agree that the "attacker" actions are limited even if he "discovered" the
client_id, actually he can do nothing as you pointed :
He needs approval from end user's to access their data, but how to alert
them (educate them) about the risks of phishing attacks
We have no choice but to trust authorization servers to detect (this is
possible ?) any malicious use of client_id and to prevent end-user's each
time they are going to approve sharing data.


On 6 January 2012 18:44, Justin Richer  wrote:

>  The important thing to realize here is that just having the client_id
> doesn't get you access tokens, and it certainly doesn't give you access to
> all access tokens issued to that client_id in the past. It does allow for a
> phishing scenario in that it will let you try to impersonate a known-good
> client by copying the client_id, but each individual user will still have
> to authorize the fake client in order for it to get a new access token.
>
> But keep in mind that this doesn't expose the user's actual credentials to
> the application (on mobile especially, assuming use of external browsers
> trusted by the platform -- as has been discussed on the list here, a bad
> application could always embed a browser and try to steal your credentials
> directly, but they can do that anyway without OAuth). The mitigation and
> cleanup of fake clients like this is also simpler, since you can revoke
> tokens without much cost to users and service providers.
>
> These reasons are why it's suggested to use the authorization code flow
> with mobile apps, just without a client_secret. You can lessen the attack
> vector by using a trusted and preregistered callback_uri, and there's even
> been some discussion about how to do that with cloud services handling the
> callbacks for trusted applications on the platform.
>
>  -- Justin
>
>
> On 01/06/2012 12:34 PM, William Mills wrote:
>
>  Yeah, certainly for Mobile clients this is true.  There are classes of
> clients (server to server implementations notably) where clientID can be a
> proper secret and be usefule for client validation.
>
>   --
> *From:* Torsten Lodderstedt 
> *To:* Karim  ;
> oauth@ietf.org
> *Sent:* Friday, January 6, 2012 5:21 AM
> *Subject:* Re: [OAUTH-WG] OAuth2 security considerations for client_id
>
>  Hi,
>
> your observation is correct. OAuth security considerations recommend not
> to rely on secrets for authenticating mobile apps (aka native apps) but to
> manage them as so-called public clients. Please take a look onto section 10
> of the core spec for further details.
>
> regards,
> Torsten.
>
>
>
> Karim  schrieb:
>
> Hello,
>
>  When using User-agent flow with OAuth2 for mobile platform, there is no
> way for Authorization server to authenticate the client_id of the
> application.
>
>  So, anyone can impersonate my app by copying the client_id (and so get
> all access tokens on my behalf), and this is applicable to Facebook,
> Foursquare,...
>
>  This is not managed by OAuth2 ? Or I missed something ?
>
>  For Web applications (Web server flow), access token is stored on the
> server side, and the client is authenticated using secret key.
>
>  --
> Karim
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
>
> ___
> OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth
>
>
>
> ___
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Karim 
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2

[Eran Hammer-Lahav]

Simply added to the first paragraph:

   The authorization server MUST support the HTTP Basic authentication 
scheme
   for authenticating clients which were issued a client password.

EHL

> -Original Message-
> From: André DeMarre [mailto:andredema...@gmail.com]
> Sent: Tuesday, September 20, 2011 7:12 PM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
>
> > If the server issues clients with password credentials it MUST support HTTP
> Basic (this is the flip side of 'the client MAY use HTTP Basic') and should 
> only
> support the client_secret parameter if it has clients incapable of using HTTP
> Basic.
>
> Very well. Without changing the meaning, I think the community would be
> well served by appending paragraph 2 of Section 2.3 as follows:
> 
>Confidential clients are typically issued (or establish) a set of
>client credentials used for authenticating with the authorization
>server (e.g. password, public/private key pair).  If clients are
>issued passwords, the authorization server MUST support the HTTP
>Basic authentication scheme as defined in [RFC2617] and described
>by Section 2.3.1.
> 
> This helps to communicate that authorization servers are only required to
> support HTTP Basic if they issue client passwords.
>
> Andre
>
> On Tue, Sep 20, 2011 at 3:20 PM, Eran Hammer-Lahav
>  wrote:
> > If the server issues clients with password credentials it MUST support HTTP
> Basic (this is the flip side of 'the client MAY use HTTP Basic') and should 
> only
> support the client_secret parameter if it has clients incapable of using HTTP
> Basic.
> >
> > This language has been tweaked to reach a delicate balance. I'm not
> inclined to touch it.
> >
> > EHL
> >
> >> -Original Message-
> >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
> >> Behalf Of André DeMarre
> >> Sent: Wednesday, September 14, 2011 5:25 PM
> >> To: OAuth WG
> >> Subject: Re: [OAUTH-WG] Fwd: secdir review of draft-ietf-oauth-v2
> >>
> >> I agree that stating "Clients in possession of a client password MAY
> >> use the HTTP Basic authentication scheme" [Section 2.3.1 paragraph 1]
> >> implies that authorization servers MUST support HTTP basic
> >> authentication, but such is never asserted. Instead, it says "The
> >> authorization server MAY accept any form of client authentication
> >> meeting its security requirements." [Section 2.3 paragraph 1] This is
> somewhat contradictory.
> >>
> >> I can understand that requiring a specific method of client
> >> authentication is desirable for maximum interoperability, but this
> >> would be problematic for authorization server implementations that
> >> wish to enforce stronger security than HTTP Basic. Such
> >> implementations would be forced to deviate from the specification. In
> >> particular, implementations which choose MAC access tokens instead of
> >> Bearer tokens may wish to add a layer of security to defend against
> >> improperly configured TLS connections, or to protect clients who connect
> to the wrong server.
> >> [http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-ide
> >> a/] Such implementations will also find HTTP Basic undesirable for
> >> client authentication. To require a form of client authentication
> >> that isn't universally sufficient could become a source of criticism
> >> and deter adoption of OAuth 2.0.
> >>
> >> I think the best solution is to clarify section 2.3.1 as follows:
> >> ---
> >> Clients in possession of client credentials MAY use any form of
> >> authentication scheme supported by the authorization server.
> >> ---
> >> And then follow with the existing example that demonstrates HTTP Basic.
> >>
> >> Regards,
> >> Andre DeMarre
> >>
> >> On Tue, Sep 13, 2011 at 4:52 PM, Greg Brail  wrote:
> >> > I would like to add my support to the comments below on section
> >> > 2.3, specifically 2.3.1.
> >> >
> >> > It is clear to me from reading section 2.3 that clients MAY use
> >> > HTTP basic, or they MAY include client_id and client_secret in the
> >> > request body -- however, the latter is not recommended.
> >> >
> >> > It is not clear what the authorization server MUST support. IMHO,
> >> > that leads us to a situation in which there is no
> >> > universally-agreed set of authentication technology that all
> >> > programmers can assume is going to work, which means that
> >> > interoperability will be difficult as some authorization servers
> >> > will support Basic, others will support the request body, and others will
> do neither in favor of something else.
> >> >
> >> > I would prefer that we make both HTTP basic AND the request body
> >> > mechanisms in this section both required on the server side, thus
> >> > giving the client the option of choosing one or the other. That
> >> > would mean re-writing the beginning of section 2.3.1 as shown below.
> >> >
> >> > If I have missed other discussion on this

Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2

[Eran Hammer-Lahav]

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, September 20, 2011 3:13 PM

> > 3.1.1 Response Type
> >
> > The response_type parameter is REQURED but its absence SHOULD result
> > in an error. Why not MUST?

Changes to MUST.

> > 3.1.2.4 Invalid Endpoint
> >
> > "The authorization server SHOULD NOT redirect...". Why isn't this a
> > MUST NOT?
> 
> I'm ok with MUST NOT - any objections?

This one is actually tricky. I don't like the current text (mine) because 
untrusted is a useless qualifier here. The point is that redirecting to 
unregistered endpoints can lead to the abuse of the endpoint as an open 
redirector. Because we actually support unregistered callbacks, we can't say 
MUST NOT. I am removing the 'untrusted' part but leaving the SHOULD NOT as is.

EHL

___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2

[Eran Hammer-Lahav]

I have not seen any follow up to the open issues and will be closing them on my 
editor's list. This doesn't mean they are closed, just that I will not be 
addressing them without someone raising them again on the list. Since none of 
them are in the tracker, this email is the only record I know of listing them 
(and their status/response).

EHL

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, September 20, 2011 3:13 PM
> To: Leif Johansson; OAuth WG
> Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
>
> (+OAuth WG, -everyone else)
>
> Thanks Leif.
>
> See comments inline. Whatever issues are still open will be addressed along
> with the rest of the IETF LC feedback.
>
> EHL
>
>
> > -Original Message-
> > From: Leif Johansson [mailto:le...@sunet.se]
> > Sent: Monday, September 12, 2011 11:31 AM
>
> > ** General observations:
> >
> > POST and/or GET
> >
> > Examples are sometimes POST and sometimes GET. In many cases it is not
> > clear to me from the surrounding text if both POST and GET are allowed
> > or if only one is mandated. Illustrating with both a GET _and_ POST
> > example in the cases where both are supported would help or make the
> > method explicit in the text before the example.
> >
> > The P-word
> >
> > The term 'password' is sprinkled throughout the document, sometimes as
> > in "client password" or "resource owner password credentials" and I
> > suspect that sometimes it is password as in 'an example of a
> > credential type' and in other cases it is password as in 'plain old
> > password'. This needs to be cleared up throughout (I've included some
> examples below).
> >
> > Normative Language
> >
> > I've often found myself wanting more normative language often to
> > replace existing but less precise text. I've called out some important cases
> below.
> >
> > Unknown parameters
> >
> > The sentence "The client SHOULD ignore unrecognized response
> > parameters"
> > occurs in several places. First of all I would argue that this has to
> > be a MUST if you want to be able to guarantee extensibility. Secondly
> > there are some error responses that are triggered by unsupported
> > request parameters. This seems like an inconsistency.
> >
> > ** Specifics
> >
> > 1.1 Roles
> >
> > Forward references to the sections where the roles are defined would
> > improve readability.
>
> What sections? That's the only place these roles are defined.
>
> > As an illustration of an alternative model for the authorization
> > server maybe an informative reference to UMA would be illustrative here.
>
> A reference to UMA would be confusing in this document.
>
> > 1.2 Protocol Flow
> >
> > (A) talks about 'an intermediary such as an authorization server.' it
> > isn't clear it me if this refers to a separate authorization server or
> > if it is the same authorization server that is referenced in (B).
>
> Changed to:
>
>   (A) The client requests authorization from the resource owner. 
> The
> authorization request
>   can be made directly to the resource owner (as shown), or 
> preferably
> indirectly via
>   the authorization server as an intermediary.
>
> > 1.3.3 Resource Owner Password Credentials
> >
> > When I first read this I thought - why not talk about Resource Owner
> > Credentials - in fact there is a parenthesis there "(e.g a username
> > and password)" that seems to indicate that other credentials could be
> supported.
> >
> > This needs to be cleared up. Either its username and password and
> > nothing else or there is a way to support things like Negotiate or
> > X.509-based credentials in which case it should really be Resource
> > Owner Credentials with no reference to passwords other than as as an
> > example of one possible credential type.
>
> Changed to:
>
> (i.e. username and password)
>
> This is explicitly just for username and password. Other types require an
> extension.
>
> > 1.4 Access Token
> >
> > first paragraph: "The string is usually opaque". This should be
> > reformulated as normative language. In fact I would have liked
> > guidance on generating those tokens (which has been brought up on the
> > list) possibly as part of an implementation-guide.
>
> There is not requirement for the string to be opaque, but the general
> architecture assumes it is. Otherwise, please suggest language.
>
> > 1.5 Refresh Token
> >
> > Why is the refresh token not simply treated as an access token for the
> > access token resource in the authorization server? This would seem to
> > simplify the model a bit by removing a type of token whose semantic
> > (at least to this
> > reviewer) is a duplication of a normal access token for a particular
> > type of resource.
>
> Simpler architecture but probably more confusing to many developers.
>
> > Also in the first paragraph: "(access tokens may have a shorter
> > lifetime and fewer permissions

[OAUTH-WG] FW: draft-ietf-oauth-v2: Doubt about chapter 4.2

[Eran Hammer-Lahav]

Sending to the right place.

EHL


From: DIEGO GONZALEZ MARTINEZ [mailto:die...@tid.es]
Sent: Friday, October 07, 2011 1:35 AM
To: draft-ietf-oauth...@tools.ietf.org
Subject: draft-ietf-oauth-v2: Doubt about chapter 4.2

Hello,
My name is Diego González, I work in Telefónica R&D and I'm following OAuth 2.0 
works as we're using OAuth in Telefónica's APIs exposure programs (e.g.: 
BlueVia). I as well participate in OMA activities for using OAuth to access OMA 
standard APIs.
I'm Reading through OAuth 2.0 draft and I have a doubt.

In chapter 4.2.1 for Implicit Grant I can see the following example:
GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Then in chapter 4.2.2 I see the following example:

HTTP/1.1 302 Found

 Location: http://example.com/rd#access_token=2YotnFZFEjr1zCsicMWpAA

   &state=xyz&token_type=example&expires_in=3600


The first I thought is that this is just a misalignment within examples and 
second example should look like https://client.example.com/cb. Is it?

But then I got the following doubt. Would it make sense for every Client to be 
redirected to a known web hosted by the resource provider? I mean a set of 
clients trying to gain access to a Resource, and being always redirected to the 
same web-hosted resource offered by resource provider, not to the web-client 
hosted resource.
E.g.: redirect every client using Implicit Grant to 
https://server.com/accessTokenScriptisHereforEveryOne, no matter what the 
redirect_uri was.
Do you think this make sense? Or there are some security problems I am not 
taking into account.

Kind regards,
Diego



Diego González Martínez
Telefónica Investigación y Desarrollo
Iniciativa NeoSDP
e-mail: die...@tid.es
Phone: +34 983 36 75 97



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2

[William Mills]

I think the only thing there I'd say might still want to get done is:

> > 10.10 Credentials Guessing Attack
> >
> > I found myself wanting implementation advice for how to generate good
> > tokens at this point. This has been raised on the list too. The same
> > goes for how to generate good CSRF cookies where the "(eg a hash of
> > the session cookie..." feels like it is implementation advice yearning
> > to come out of the closet.
>
> Need someone to suggest text.

Didn't we get CSRF text in there?




 From: Eran Hammer-Lahav 
To: "e...@sled.com" ; Leif Johansson ; OAuth WG 
 
Sent: Friday, January 6, 2012 10:57 PM
Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
 
I have not seen any follow up to the open issues and will be closing them on my 
editor's list. This doesn't mean they are closed, just that I will not be 
addressing them without someone raising them again on the list. Since none of 
them are in the tracker, this email is the only record I know of listing them 
(and their status/response).

EHL

> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of Eran Hammer-Lahav
> Sent: Tuesday, September 20, 2011 3:13 PM
> To: Leif Johansson; OAuth WG
> Subject: Re: [OAUTH-WG] secdir review of draft-ietf-oauth-v2
>
> (+OAuth WG, -everyone else)
>
> Thanks Leif.
>
> See comments inline. Whatever issues are still open will be addressed along
> with the rest of the IETF LC feedback.
>
> EHL
>
>
> > -Original Message-
> > From: Leif Johansson [mailto:le...@sunet.se]
> > Sent: Monday, September 12, 2011 11:31 AM
>
> > ** General observations:
> >
> > POST and/or GET
> >
> > Examples are sometimes POST and sometimes GET. In many cases it is not
> > clear to me from the surrounding text if both POST and GET are allowed
> > or if only one is mandated. Illustrating with both a GET _and_ POST
> > example in the cases where both are supported would help or make the
> > method explicit in the text before the example.
> >
> > The P-word
> >
> > The term 'password' is sprinkled throughout the document, sometimes as
> > in "client password" or "resource owner password credentials" and I
> > suspect that sometimes it is password as in 'an example of a
> > credential type' and in other cases it is password as in 'plain old
> > password'. This needs to be cleared up throughout (I've included some
> examples below).
> >
> > Normative Language
> >
> > I've often found myself wanting more normative language often to
> > replace existing but less precise text. I've called out some important cases
> below.
> >
> > Unknown parameters
> >
> > The sentence "The client SHOULD ignore unrecognized response
> > parameters"
> > occurs in several places. First of all I would argue that this has to
> > be a MUST if you want to be able to guarantee extensibility. Secondly
> > there are some error responses that are triggered by unsupported
> > request parameters. This seems like an inconsistency.
> >
> > ** Specifics
> >
> > 1.1 Roles
> >
> > Forward references to the sections where the roles are defined would
> > improve readability.
>
> What sections? That's the only place these roles are defined.
>
> > As an illustration of an alternative model for the authorization
> > server maybe an informative reference to UMA would be illustrative here.
>
> A reference to UMA would be confusing in this document.
>
> > 1.2 Protocol Flow
> >
> > (A) talks about 'an intermediary such as an authorization server.' it
> > isn't clear it me if this refers to a separate authorization server or
> > if it is the same authorization server that is referenced in (B).
>
> Changed to:
>
>               (A) The client requests authorization from the resource owner. 
>The
> authorization request
>               can be made directly to the resource owner (as shown), or 
>preferably
> indirectly via
>               the authorization server as an intermediary.
>
> > 1.3.3 Resource Owner Password Credentials
> >
> > When I first read this I thought - why not talk about Resource Owner
> > Credentials - in fact there is a parenthesis there "(e.g a username
> > and password)" that seems to indicate that other credentials could be
> supported.
> >
> > This needs to be cleared up. Either its username and password and
> > nothing else or there is a way to support things like Negotiate or
> > X.509-based credentials in which case it should really be Resource
> > Owner Credentials with no reference to passwords other than as as an
> > example of one possible credential type.
>
> Changed to:
>
>         (i.e. username and password)
>
> This is explicitly just for username and password. Other types require an
> extension.
>
> > 1.4 Access Token
> >
> > first paragraph: "The string is usually opaque". This should be
> > reformulated as normative language. In fact I would have liked
> > guidance on generating those tokens (which has been brought up on the
> > list) possibly