> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Torsten Lodderstedt > Sent: Sunday, March 13, 2011 3:51 PM
> section 1.4: "An authorization grant is a general term used to describe the > intermediate credentials ..." > > Since passwords represent authorization grants as well, I would suggest to > adjust the wording to "intermediate or permanent" Intermediate refers to their use in OAuth, and does not apply to their external existence. > section 1.4.4: > > "The client credentials can be used as an authorization grant ..., or to > protected resources previously arranged with the authorization server." > > Does this mean, the client is not the resource owner but gets access because > of an existing authorization? How does this differ from an implicit grant? The authorization server can provide users with a control panel with a list of pre-selected clients. The users can chose to authorize these clients directly without going through the authorization flow. Later, the client can use this grant type to access the user's protected resources because they have been pre-approved. > "Client credentials are used as an > authorization grant typically when the client is acting on its own behalf (the > client is also the resource owner)." > > What are the alternatives? I would suggest to remove "typically". See above. > section 2.1: > > 4. paragraph: "If the response does not include an access token, the > authorization server SHOULD require TLS 1.2 and any additional transport- > layer mechanism meeting its security requirements." > > Why only "SHOULD" and not "MUST"? Otherwise, alternative means for > preventing abuse of the response parameters MUST be required, e.g. > client authentication for authorization code exchange. > > Moreover, this is about the redirect_uri, isn't it? What about the endpoint's > security itself, i.e. requests to this endpoint? This is only about the confidentiality of the response, if the response includes credentials (bearer token, MAC token secret, etc.). > section 2.1.1: > > 3. paragraph: "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." > > Pre-registered redirect_uri facilitate client authentication while tying a > client > to a certain deployment. Although this is typical practice nowdays I expect > this to change if OAuth really gains traction for standard client software, > such > as mail clients. > > Proposal: Should by MAY in my opinion + some explanation on the purpose > of redirect_uri registration. I think this should stay a SHOULD given it can improve security. > section 2.2: > > 4. paragraph: "The token endpoint requires client authentication as > described in Section 3." > > That's to restrictive, probably client identification but not authentication. > Otherwise, this endpoint cannot be used for most native apps. New text in section 3 clarifies this: 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. > section 3: > "Client credentials are used to identify and authenticate the client." > > I think it would be helpful for the reader to explain the purposes client > identitification and authentication serve in OAuth. I see the following use > cases (more text can be found in > http://tools.ietf.org/html/draft-lodderstedt-oauth-security-00#section-3.8): > > In the context of delegated authorization, client identity is used to: > - Establish trust to the client and display relevant registration information > to a > user when requesting consent for authorization > - Authorize clients for certain authorization server features > - Collate associated request to the same originator (e.g. a particular > end-user > authorization process and the corresponding request on the tokens endpoint > to exchange the authorization code for tokens) This goes beyond what the specification offers on other protocol elements. I added the following to section 3: The methods through which the client obtains its client credentials are beyond the scope of this specification. However, the client registration process typically includes gathering relevant information used to inform the resource owner about the client when requesting authorization. > "The authorization server SHOULD NOT issue client credentials to clients > incapable of keeping their secrets confidential." > > I would suggest to add some explanation here. Proposal "For example, the > same client credentials should not be used for multiple installations of the > same software, e.g. all instances of the same native app running on different > PCs or smartphones." I don't think this is necessary, but can be expanded in the security considerations section. > section 3.2: > "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." > > I would suggest to move this sentence after the BASIC authentication > example. Moved up to 3. > section 4.1: > > In my opinion, the introduction of this section over-emphasizes the aspect of > client secrets & authentication while neglecting the other properties of the > authorization code flow. Moreover, it encourages the impression this flow > can only be used by clients equipped with a secret. > This is wrong as this flow should be usable by clients w/o client secrets as > well > because it offers unique properties beside its aibility to support client > authentication. In my opinion these are: > > - user identity and credentials are not exposed to client (in contrast to > resource owner password grant) > - user authentication and consent controlled by authorization server (in > contrast to resource owner password grant) > - flow is especially suited for clients which are web applications (in > contrast to > implicit grant) > - refresh token issuance (in contrast to implicit grant) > - client credentials and tokens are sent over protected, direct communication > channels between client and authorization server (no browser caches and > HTTP referers involved) > - aibility to authenticate clients (for completeness) > > The introduction should explain all properties of the flow and offer some > guidance when and how to use the flow. I disagree. The code and implicit grants were explicitly designed to accommodate the two cases of clients with and without secrets. While the code grant can be used without a secret, it loses many of its properties. By narrowly defining the two profiles in such a way, we simplify the security considerations section, without restricting their applicability. Note that there is no MUST when it comes to client secrets. It is just an introduction. I expect others to define and publish profiles of how to apply these two grant types to various cases typical for native applications. But beside good intentions, this group has not produced such a comprehensive document and it is too late to delay this work. Also, as your list above shows, this is not a simple list but a feature matrix, comparing it to multiple grant types. I don't think an introduction will be helpful in selecting the right grant type, but a comprehensive analysis. If someone wants to try writing one, we can consider adding it, but it will have to be done in a matter of 2-3 weeks. Overall, I think a blog post will be as useful. > section 4.1.3: > Why is the name of the response type "code" whereas the name of the > grant type is "authorization_code"? Trying to be succinct on the wire. The prose is more descriptive. > "redirect_uri" should only be required if it was an input parameter to the > corresponding authz request. No. It should be set to wherever the callback was sent to since sometimes servers allow both pre-registered and override. > last paragraph: "Validate the client credentials and ensure they match the > authorization code." should be "Validate the client credentials (if > present) and ensure they match the > authorization code." (see also: > http://www.mail-archive.com/oauth@ietf.org/msg04540.html) See reply to your previous post. > section 4.1.4: > > "If the request failed due to failed client authentication or is invalid" - > Some > words missing here? > > example response: The JSON document contains a field > "example_parameter":"example-value". Some copy and paste remainings? - > The same holds true for other example JSON documents. Not sure what you mean. > section 4.2.: > > I'm struggeling with the name "implicit grant". Why not just stick with "User > Agent Flow"? It has been designed for that kind of app. The name should be descriptive of the grant characteristics, not its intended purpose (which would be incomplete and misleading). I'm open to other names, but not 'user agent'. > As already mentioned for section 4.1., also this introduction puts to much > emphasize on the client secret story. I don't think this was the original > driver > of its development. I would expect the intro to focus on the functional > properties of the flow: > > As I understand, it has been designed with JavaScript clients in mind, which > due to the same origin policy, are unable to send requests directly to an > authorization server outside of its origin. So instead of obtaining tokens > through a POST request (via authz code), the access token is delivered > directly via the redirect URI. In order to reduce the exposure of the token > (and because it is sufficient), the access token is sent via the fragment. As > a > consequence of the design this flow does not support client authentication > via secrets. The client's identity can nevertheless be validated using pre- > registered redirect_uri's. > > This flow cannot be used with web applications. And as long as the flow does > not support refresh tokens, the same holds true for native apps (see also > http://tools.ietf.org/html/draft-zeltsan-oauth-use-cases-01). > So please remove "or native applications" from the text (see > http://www.ietf.org/mail-archive/web/oauth/current/msg05551.html). The design accommodates a few features: 1. Use fragment to improve performance (caching) 2. Use fragment to prevent token from being sent to the server hosting the client script for the redirection 3. Limited functionality (no refresh token) because of lack of client secrets But again, If we want to provide a feature matrix to help developers choose the right grant type, that's one thing, but I am not going to change the simple introductions because it makes the rest of the protocol much simpler to explain and does not take sides in a debate (which profile to use when) which is far from settled. > section 4.3: > > 2. paragraph: I suggest to add "It is even possible to migrate from stored > credentials to stored refresh tokens. Leakage of the later would have less > impact." I think this is redundant. > Figure 5/ Step C) I suggest to add ", and optionally a refresh token." Diagram has it. I think keep repeating it makes the document less readable. > section 4.3.3 > > "If the access token request is valid and authorized, the authorization server > issues an access token and optional refresh token as described in Section > 5.1." > > How is determined and by whom whether a refresh token is being issued? > Since this is not an interactive flow, the authorization server cannot ask the > resource owner. Server policy. > section 6: > "The authorization server MUST validate the client credentials, ..." > should be "The authorization server MUST validate the client credentials (if > present), ..." See above. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
