Last week I completed a review of draft-ietf-oauth-v2-16. Here are some comments.
MAJOR ISSUES...
Throughout the document, the various parameters (e.g., client_secret and
client_id) are essentially undefined. There is no text about the length
of these parameters, the allowable characters (e.g., alpha and digits
only, all ASCII characters, full Unicode), internationalization
considerations, preparation and comparison of strings, etc. I don't see
how developers will build interoperable implementations without clear
guidance here.
Also, the scope parameter still strike me as extremly vague. Can we at
least define the word "scope" and provide a few examples of how the
parameter might be used?
No rules are provided for URI matching (e.g., in Section 4.1 the
redirection URI received needs to be checked against the URI used to
redirect the client, but not guidance is provided). Perhaps a reference
to RFC 3986 is in order here. Here also internationalization concerns
might need to be covered (e.g., are IRIs allowed?).
4.1.2. Authorization Response
OLD:
If an
authorization code is used more than once, the authorization
server MAY revoke all tokens previously issued based on that
authorization code.
NEW:
If an
authorization code is used more than once, the authorization
server SHOULD revoke all tokens previously issued based on that
authorization code.
RATIONALE: MAY seems weak here.
10.2. Client Impersonation
The authorization server SHOULD require the client to pre-register
its redirection URI and validate the value of the "redirect_uri"
against the pre-registered value.
How does this validation occur?
OLD:
The authorization server SHOULD issue access tokens with limited
scope and duration to clients incapable of authenticating.
NEW:
If the authorization server issues access tokens to clients
that are incapable of authenticating, the scope and duration of
such tokens SHOULD be limited.
RATIONALE: We're not actively RECOMMENDING authorization servers are to
issue such tokens, are we?
10.3. Access Token Credentials
The client SHOULD request access token credentials with the minimal
scope and duration necessary.
Is this enfoced by the authorization server?
10.6. Endpoints Authenticity
In order to prevent man-in-the-middle and phishing attacks, the
authorization server MUST implement and require TLS with server-side
authentication in all exchanges. The client MUST verify the
authorization server's TLS certificate, as well as the respective
certificate chain.
We need a reference to RFC 2818 here since it defines server
verification procedures for HTTP. (Same for Section 10.8.)
10.9. Authorization Codes
Authorization codes SHOULD be short lived and MUST be single use. If
the authorization server observes multiple attempts to exchange an
authorization code for an access token, the authorization server
SHOULD revoke all access tokens already granted based on the
compromised authorization code.
Is there a good reason why the authorization server would not revoke all
the access tokens? If not, change to MUST.
MINOR ISSUES...
1.4.1. Authorization Code
OLD:
Before directing the resource owner back to the client with the
authorization code, the authorization server authenticates the
resource owner and obtains authorization. Because the resource owner
only authenticates with the authorization server, the resource
owner's credentials are never shared with the client.
NEW:
Before directing the resource owner back to the client with the
authorization code, the authorization server authenticates the
resource owner and obtains authorization. Because the resource owner
only authenticates with the authorization server, the resource
owner's credentials at the resource server are never shared with the
client.
RATIONALE: could the resource owner have credentials at the
authorization server?
1.4.2. Implicit
OLD:
Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application)
since it reduces the number of round trips required to obtain an
access token.
NEW:
Implicit grants improve the responsiveness and efficiency of some
clients (such as a client implemented as an in-browser application)
since they reduce the number of round trips required to obtain an
access token. However, service providers need to weigh this
convenience against the security properties of implicit grants
(e.g., the fact that client authentication is not possible).
RATIONALE: I think it would be good to mention that there's a balance
here between convenience and security.
1.7 Notational Conventions
I think it would be good to add an informational reference to RFC 4949
here, and to check our usage of certain terms against the definitions in
that spec. Proposed text:
Certain security-related terms are to be understood in the sense
defined in [RFC4949]; such terms include, but are not limited to,
"attack", "authentication", "authorization", "certificate",
"confidentiality", "credential", "encryption", "identity",
"sign", "signature", "trust", "validate", and "verify".
2.1. Authorization Endpoint
OLD:
Request and response parameters MUST NOT repeat more than once,
unless noted otherwise.
NEW:
Request and response parameters MUST NOT be included more than once,
unless noted otherwise.
4.1.2.1. Error Response
OLD:
error_description
OPTIONAL. A human-readable text providing additional
information, used to assist in the understanding and resolution
of the error occurred. [[ add language and encoding information
]]
NEW:
error_description
OPTIONAL. Descriptive text providing additional information,
used to assist in the understanding and resolution of the
error that has occurred. If included, it MUST be used only
to provide descriptive or diagnostic information that
supplements the meaning of an existing HTTP error code. It
MUST NOT be interpreted programmatically by an application and
MUST NOT be used as the error message presented to a human
user, but MAY be used by application developers for debugging
purposes.
RATIONALE: If the error_description is not intended for humans and is to
be used only by developers for debugging purposes, then we don't need
language tags. (As explained in RFC 2277, "internationalization is for
humans"; yes, developers are people too...)
4.2. Implicit Grant
This section uses the term "web server"; I suggest "resource server" for
consistency.
7.1. Access Token Types
OLD:
The access token type provides the client with the information
required to successfully utilize the access token to make a protected
resource request (along with type-specific attributes). The client
MUST NOT use an access token if it does not understand the token
type.
NEW:
The access token type provides the client with the information
required to successfully utilize the access token to make a protected
resource request (along with type-specific attributes). The client
MUST NOT use an access token if it does not understand or does not
trust the token type.
RATIONALE: An application could understand a given token type but not
trust it (or not trust it from the sender).
8.1. Defining Access Token Types
8.2. Defining New Endpoint Parameters
Mention that the ALPHA and DIGIT rules come from RFC 5234.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
