Overall, I'm very happy with this draft. Excellent work, Eran!
A couple of comments though:
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“
section 1.4.3: "Unlike
the HTTP Basic authentication scheme defined in [RFC2617], this grant
type eliminates the need for the client to store the resource-owner
credentials for future use"
I would suggest to add "if used in combination with refresh tokens."
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?
"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“.
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?
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.
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.
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)
Moreover, client credentials can also be used to authenticate the client
as a resource owner (see client credentials grant type)
Requirements regarding the client security policy and the data
associated with the client identity may vary among the purposes.
"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."
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.
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.
section 4.1.3:
Why is the name of the response type „code“ whereas the name of the
grant type is „authorization_code“?
"redirect_uri" should only be required if it was an input parameter to
the corresponding authz request.
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)
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.
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.
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).
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."
Figure 5/ Step C) I suggest to add ", and optionally a refresh token."
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.
section 6:
"The authorization server MUST validate the client credentials, ..."
should be "The authorization server MUST validate the client credentials
(if present), ..."
regards,
Torsten.
Am 02.03.2011 08:32, schrieb Hannes Tschofenig:
This is a Last Call for comments on
http://www.ietf.org/id/draft-ietf-oauth-v2-13.txt
Please have your comments in no later than March 16.
Do remember to send a note in if you have read the document and have no
other comments other than "its ready to go" - we need those as much as we need "I
found a problem".
Thanks!
Hannes& Blaine
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oaut
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
