Re: [OAUTH-WG] Draft 16 comment
Section 3: In addition, the authorization server MAY allow unauthenticated access token requests when the client identity does not matter (e.g. anonymous client) or when the client identity is established via other means. For readability purposes only, this specification is written under the assumption that the authorization server requires some form of client authentication. However, such language does not affect the authorization server's discretion in allowing unauthenticated client requests. From: Shane Weeden mailto:swee...@au1.ibm.com>> Date: Sun, 22 May 2011 21:40:22 -0700 To: "oauth@ietf.org<mailto:oauth@ietf.org>" mailto:oauth@ietf.org>> Subject: [OAUTH-WG] Draft 16 comment First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling "instance secret" for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ OAuth mailing list OAuth@ietf.org<mailto: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] Draft 16 comment
I know I have harped on that too many times previously, but just for the purpose of counting "votes," I think that option 2) is NOT an option. (Vote: -2 for 2) That leaves option 1) as a must as far as I am concerned. Igor On 6/28/2011 6:26 AM, Mark Mcgloin wrote: The question below remains unanswered in relation to native apps being able to use grant type auth code to utilize refresh tokens. Which of these is the best option 1) Change oauth spec so client credentials are optional when requesting access token for grant type 'authorization_code' and for refresh token requests 2) Edit section 9 on security considerations to remove any references to native apps using auth code The difficulty with option 1 is how do you then prevent attackers using a legitimate client identifier. If we change the spec to say the client SHOULD pre-register it's redirect-uri, would that suffice? Regards Mark oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22: From: Shane B Weeden To: oauth@ietf.org Date: 23/05/2011 06:26 Subject: [OAUTH-WG] Draft 16 comment Sent by: oauth-boun...@ietf.org First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling "instance secret" for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ 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] Draft 16 comment
+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 cannot prevent a client from using another clients id, even pre-registering a redirect_uri won't help. But this only means, the authz server cannot provide the user with trustworthy data regarding the app. In this case it is the task of the user and the platform the app is running on to detect malicious clients (maleware, viruses). regards, Torsten. > -Ursprüngliche Nachricht- > Von: Mark Mcgloin [mailto:mark.mcgl...@ie.ibm.com] > Gesendet: Dienstag, 28. Juni 2011 12:26 > An: Shane B Weeden > Cc: oauth@ietf.org; oauth-boun...@ietf.org > Betreff: Re: [OAUTH-WG] Draft 16 comment > > The question below remains unanswered in relation to native apps being > able > to use grant type auth code to utilize refresh tokens. Which of these > is > the best option > > 1) Change oauth spec so client credentials are optional when requesting > access token for grant type 'authorization_code' and for refresh token > requests > 2) Edit section 9 on security considerations to remove any references > to > native apps using auth code > > The difficulty with option 1 is how do you then prevent attackers using > a > legitimate client identifier. If we change the spec to say the client > SHOULD pre-register it's redirect-uri, would that suffice? > > > Regards > Mark > > oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22: > > > From: > > > > Shane B Weeden > > > > To: > > > > oauth@ietf.org > > > > Date: > > > > 23/05/2011 06:26 > > > > Subject: > > > > [OAUTH-WG] Draft 16 comment > > > > Sent by: > > > > oauth-boun...@ietf.org > > > > > > First, I'd like to add my support for Brian Eaton's comments on Draft > 16. > > They actually helped clarify the comment I have below > > > > > > I found section 9 to be in contradiction to a part of section 6. In > > particular in section 9: > > > > Native applications SHOULD use the authorization code grant type > flow > > without client password credentials (due to their inability to keep > > the credentials confidential) to obtain short-lived access tokens, > > and use refresh tokens to maintain access. > > > > In section 6 the specification is quite clear that client > authentication > is > > REQUIRED for the use of refresh tokens: > > > >The authorization server MUST validate the client credentials, > ensure > >that the refresh token was issued to the authenticated client, > >validate the refresh token, and verify that the resource owner's > >authorization is still valid. > > > > > > My understanding is that refresh tokens are being used as a kind of > > long-lived, rolling "instance secret" for the native application and > > represent the grant authorized by the end user during initial > establishment > > of the authorization code which is used to get the first refresh > token. > > > > It seems to me this use case needs to be allowed for in the wording > of > > section 6. > > > > Regards, > > Shane. > > > > ___ > > 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] Draft 16 comment
The question below remains unanswered in relation to native apps being able to use grant type auth code to utilize refresh tokens. Which of these is the best option 1) Change oauth spec so client credentials are optional when requesting access token for grant type 'authorization_code' and for refresh token requests 2) Edit section 9 on security considerations to remove any references to native apps using auth code The difficulty with option 1 is how do you then prevent attackers using a legitimate client identifier. If we change the spec to say the client SHOULD pre-register it's redirect-uri, would that suffice? Regards Mark oauth-boun...@ietf.org wrote on 23/05/2011 05:40:22: > From: > > Shane B Weeden > > To: > > oauth@ietf.org > > Date: > > 23/05/2011 06:26 > > Subject: > > [OAUTH-WG] Draft 16 comment > > Sent by: > > oauth-boun...@ietf.org > > > First, I'd like to add my support for Brian Eaton's comments on Draft 16. > They actually helped clarify the comment I have below > > > I found section 9 to be in contradiction to a part of section 6. In > particular in section 9: > > Native applications SHOULD use the authorization code grant type flow > without client password credentials (due to their inability to keep > the credentials confidential) to obtain short-lived access tokens, > and use refresh tokens to maintain access. > > In section 6 the specification is quite clear that client authentication is > REQUIRED for the use of refresh tokens: > >The authorization server MUST validate the client credentials, ensure >that the refresh token was issued to the authenticated client, >validate the refresh token, and verify that the resource owner's >authorization is still valid. > > > My understanding is that refresh tokens are being used as a kind of > long-lived, rolling "instance secret" for the native application and > represent the grant authorized by the end user during initial establishment > of the authorization code which is used to get the first refresh token. > > It seems to me this use case needs to be allowed for in the wording of > section 6. > > Regards, > Shane. > > ___ > 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-WG] Draft 16 comment
First, I'd like to add my support for Brian Eaton's comments on Draft 16. They actually helped clarify the comment I have below I found section 9 to be in contradiction to a part of section 6. In particular in section 9: Native applications SHOULD use the authorization code grant type flow without client password credentials (due to their inability to keep the credentials confidential) to obtain short-lived access tokens, and use refresh tokens to maintain access. In section 6 the specification is quite clear that client authentication is REQUIRED for the use of refresh tokens: The authorization server MUST validate the client credentials, ensure that the refresh token was issued to the authenticated client, validate the refresh token, and verify that the resource owner's authorization is still valid. My understanding is that refresh tokens are being used as a kind of long-lived, rolling "instance secret" for the native application and represent the grant authorized by the end user during initial establishment of the authorization code which is used to get the first refresh token. It seems to me this use case needs to be allowed for in the wording of section 6. Regards, Shane. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
