I have put together some comments/suggestions regarding the current draft.
3.2.1. Response Format
The authorization server MUST include the HTTP "Cache-Control"
response header field with a value of "no-store" in any response
containing tokens, secrets, or other sensitive information.
Would'nt it make sense to require "no-cache", too?
3.2.1.1. Access Token Response
expires_in
OPTIONAL. The duration in seconds of the access token
lifetime.
refresh_token
OPTIONAL. The refresh token used to obtain new access tokens
using the same end-user access grant as described in Section 6.
What is the exact meaning/idea of OPTIONAL response parameters?
Who actually decides to use them? The client or the authorization server
or both?
Is it optional to implement this feature or is it envisioned the server
dynamically decides to use those parameters based on its policy?
expires_in
Why is there information passed back about the access tokens duration
but not about the refresh tokens duration?
3.2.1.2. Error Response
If the token request is invalid or unauthorized, the authorization
server constructs a JSON-formatted response which includes the common
parameters set as well as additional flow-specific parameters. The
formatted parameters are sent to the client in the entity body of the
HTTP response with a 400 status code (Bad Request).
To use status code 400 for all kinds of errors is very generic from my
point of view. How shall the client implement a
dedicated error handling if it cannot distinguish different errors. I
would suggest either to define error codes (not only
messages) in the spec or to use appropriate HTTP status codes for
different error conditions, e.g. 401 for unauthorized calls.
3.4. Client Credentials
The client credentials include a client identifier and
an OPTIONAL symmetric shared secret.
What is meant by "symmetric shared secret"? I'm familiar with the term
"symmetric" in the context of cryptographical algorithms only. I think
"shared secret" is sufficient.
3.5. User-Agent Flow
These clients
cannot keep client secrets confidential and the authentication of the
client is based on the user-agent's same-origin policy.
Does this still hold in the context of "HTTP Origin Headers"
(http://www.petefreitag.com/item/702.cfm)?
BTW: Will Brian's security considerations document be updated to be in
sync with the draft?
3.5.1. Client Requests Authorization
If the client has previously registered a redirection URI with the
authorization server, the authorization server MUST verify that the
redirection URI received matches the registered URI associated with
the client identifier.
Does this mean equality? Or just the same base string?
3.5.1.1. End-user Grants Authorization
I would suggest to use JSON encoding here, since the URI fragment is
handled by a client more or less like a response result.
3.6.1.1. End-user Grants Authorization
Why not call the "code" Parameter "verification_code"? It's called
verification code in the text.
3.6.2. Client Requests Access Token
client_secret
REQUIRED if the client identifier has a matching secret. The
client secret as described in Section 3.4.
1) I'm having trouble to understand the meaning of "if the client
identifier has a matching secret". Is the
assumption underneath that authorization servers require this secrets
from all clients they have issued a secret to?
What about client w/o a secret? Are they also allowed to use this flow?
Or is there envisioned a dependency
between the client type, clients credentials and the flows a particular
client is authorized to use?
I would have expected a clear policy which flows require authentication
and which not.
2) I would suggest to replace the request parameter by an Authorization
header. First of all because that's the
way credential transmission is handled in HTTP. Moreover, it better fits
with error handling. If the secret
is missing or wrong, the authorization server can answer with status
code 401 and a WWW-Authenticate header(s)
specifiying mechanism and realms to be used by the client in order to
authenticate to the server.
In the long run it gives deployments more freedom to use other
mechanisms than sending shared secrets as plain text over the wire.
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{"error"="incorrect_client_credentials"}
From my point of view, "redirect_uri_mismatch" and
"bad_verification_code" call for status code 403, whereas
"incorrect_client_credentials" is the 401 candidate.
3.7.1. Client Requests Authorization
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store
{"code":"74tq5miHKB","user_code":"94248","user_uri":"http%3A%2F%2
Fwww%2Eexample%2Ecom%2Fdevice","interval"=5}
Why is the user_uri URL-encoded?
3.7.2. Client Requests Access Token
"authorization_declined"
Why does the spec interpret a request as bad request if the user just
has declined the authorization? According to rfc2616 the semantics of
400 is: "The request could not be understood by the server due to
malformed syntax".
The calling client did not sent a malformed request, it cannot foresee
or influence this outcome. I would suggest to either use status 403 or
to return status code 200 for all syntactically correct and authorized
request and to use another return codes in the response body to detail
the requests outcome.
4. Username and Password Flow
4.1. Client Requests Access Token
As statet in this section's introduction, this flow is intended to
migrate existing clients from BASIC/DIGEST to OAuth. I therefore would
suggest to use excactly these HTTP authentication schemes to transfer
user credentials. This would mean to remove the parameters "username"
and "password" and to use Authorization headers instead. At Deutsche
Telekom, we have to deal with that class of clients. Such clients have
already implemented their credential handling including header
manipulation. The proposed change would further simplify their migration.
6. Assertion Flow
This flow is suitable when the client is acting autonomously or on behalf of
the end-user (based on the content of the assertion used).
Let's assume the assertion attests an end-user's identity. How shall the
authorization server determine the clients identity in this case? I
would suggest to add optional client_id/client_secret parameters (or an
Authorization header) for that case.
7. Refreshing an Access Token
I would suggest to add an optional "scope" parameter to this request.
This could be used to downgrade the scope associated with a token.
8.1. The Authorization Request Header
I consider the name "Token" of the authentication schema much to
generic. That was also the feedback of all colleagues I talked to about
the upcoming standard. Why not call it "OAuth2"?
8.2.2. Form-Encoded Body Parameter
I would suggest to drop this section/feature.
General note: Would it make sense to add explicit format handling to the
OAuth API? If we envision authorization servers supporting more than one
token format (e.g. SAML, SWT, ...), the client should given the option
to request a certain format and responses returning access tokens should
indicate the format of this token. The OAuth authorization header could
also have an optional format attribute for the same purpose.
regards,
Torsten.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
