[OAUTH-WG] access/refresh token scope ambiguity
I was looking at the scenario of using a refresh token to obtain a new access token, and noticed that in draft 16, Section 5.1 Successful Response describes the scope parameter in a confusing way that suggests a copy and paste error. Included below, with [[emphasis added]]. scope OPTIONAL. The scope of the [[access request]] expressed as a list of space-delimited, case sensitive strings. The value is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server SHOULD include the parameter [[if the requested scope is different from the one requested by the client.]] Why would the scope parameter in a response includes the scope of the [[request]]? Particularly in light of what comes [[later]]. Also, how could the requested scope be different from the one requested from the client. The client is the one making the request in the first place. I'm also wondering if while using a refresh_token to obtain a new access token, when the auth server has the opportunity to issue a new refresh_token at the same time that the scope of the refresh token might change. I would hope not, but perhaps it may. Considering the scenario where a client has a powerful refresh token and wishes to obtain a limited access token (smaller scope), would the scope parameter in the section 5.1 response match the scope of the newly issued refresh token or the newly issued access token? I'm hoping the spec can be beefed up to remove any ambiguity here. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] access/refresh token scope ambiguity
presumably should be if the *returned* scope is different from the one requested by the client. On 6/27/11 11:47 AM, Andrew Arnott wrote: I was looking at the scenario of using a refresh token to obtain a new access token, and noticed that in draft 16, Section 5.1 Successful Response describes the scope parameter in a confusing way that suggests a copy and paste error. Included below, with [[emphasis added]]. scope OPTIONAL. The scope of the [[access request]] expressed as a list of space-delimited, case sensitive strings. The value is defined by the authorization server. If the value contains multiple space-delimited strings, their order does not matter, and each string adds an additional access range to the requested scope. The authorization server SHOULD include the parameter [[if the requested scope is different from the one requested by the client.]] Why would the scope parameter in a response includes the scope of the [[request]]? Particularly in light of what comes [[later]]. Also, how could the requested scope be different from the one requested from the client. The client is the one making the request in the first place. I'm also wondering if while using a refresh_token to obtain a new access token, when the auth server has the opportunity to issue a new refresh_token at the same time that the scope of the refresh token might change. I would hope not, but perhaps it may. Considering the scenario where a client has a powerful refresh token and wishes to obtain a limited access token (smaller scope), would the scope parameter in the section 5.1 response match the scope of the newly issued refresh token or the newly issued access token? I'm hoping the spec can be beefed up to remove any ambiguity here. -- Andrew Arnott I [may] not agree with what you have to say, but I'll defend to the death your right to say it. - S. G. Tallentyre ___ 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] state parameter and XSRF detection
Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] state parameter and XSRF detection
On Mon, Jun 27, 2011 at 2:22 PM, Torsten Lodderstedt tors...@lodderstedt.net wrote: Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? It all depends on the authorization server. For example, currently Google does strict matching on the redirect URI, so you must use state. I think state is the only safe, portable option. Unless the OAuth 2 spec dictates how URI matching should be done. Marius regards, Torsten. ___ 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] OAuth 2.0 Threat Model and Security Considerations
The subject document, draft-lodderstedt-oauth-security, is now on our charter, with the rechartering. The authors have a new version ready, and would like to post it this week. The chairs have approved the name draft-ietf-oauth-v2-threatmodel-00 for this document, and if there are no objections the authors will post the new version on Friday. Keep in mind that the first priority is still the OAuth 2.0 main spec, so let's wrap that up. We're aiming for working-group last call on that within the month. Barry, as chair ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] state parameter and XSRF detection
Sounds reasonable - subject to the content of the validation rules for a registered redirect URI (section 10.11 TBD). The security considerations doc (or section 10.13 of the spec itself which is TBD) should make it clear that the state parameter must be provided by the client to prevent CSRF against the redirect_uri unless the client is already using another dynamically parameter in the redirect_uri for that purpose. Text should also include some recommendation on state parameter entropy, along with describing how it should be validated when the redirect_uri is accessed. Regards, Shane. From: Torsten Lodderstedt tors...@lodderstedt.net To: OAuth WG oauth@ietf.org Date: 28-06-11 07:26 AM Subject:[OAUTH-WG] state parameter and XSRF detection Sent by:oauth-boun...@ietf.org Hi all, while working on a new revision of the OAuth security document, a question arose I would like to clarify on the list. The state parameter is supposed to be used to link a certain authorization request and response. Therefore, the client stores a value in this parameter that is somehow bound to a value retained on the device (the user agent) originating the authorization request. The question now is: Would it be compliant with the core spec to use any other URI query parameter encoded in the redirect_uri, instead of the state parameter, to achieve the same goal? Probably the client already has a working legacy implementation it does not want to change just for OAuth2 compliance. According to section 2.2.1, the redirection uri could contain a dynamic portion: The authorization server SHOULD require the client to pre-register their redirection URI or at least certain components such as the scheme, host, port and path So this should be fine. Any comments? regards, Torsten. ___ 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] OAuth 2.0 Threat Model and Security Considerations
On 6/27/11 4:18 PM, Barry Leiba wrote: The subject document, draft-lodderstedt-oauth-security, is now on our charter, with the rechartering. The authors have a new version ready, and would like to post it this week. The chairs have approved the name draft-ietf-oauth-v2-threatmodel-00 for this document, and if there are no objections the authors will post the new version on Friday. Seems reasonable. Keep in mind that the first priority is still the OAuth 2.0 main spec, so let's wrap that up. We're aiming for working-group last call on that within the month. Does within the month mean by the end of June? :) Peter -- Peter Saint-Andre https://stpeter.im/ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
