Here are my comments on this draft:
I repeat my proposal to name the URI parameter for passing the token
"bearer_token" instead of "oauth_token". The same applies to the
respective body parameter. This is more inline with the I-D's terminology.
section 2.4
"If the protected resource request does not include authentication
credentials, contains an invalid access token, or is malformed, the
resource server MUST include the HTTP "WWW-Authenticate" response
header field. "
If the request is malformed, I would expect the resource server to
respond with status code 400 (w/o WWW-Authenticate header).
What is the meaning of the component "( token "=" ( token /
quoted-string ) )" in the definiton of the rule "param"?
"The "scope" attribute MUST NOT appear more than once."
Is the scope optional?
section 2.4.1
I don't see the benefit of those error codes as they replicate the
meaning of HTTP status codes 400, 401, and 403.
section 3.1
"Token redirect" - does this also cover the threat of a counterfeit
server phishing and abusing tokens
(https://tools.ietf.org/html/draft-lodderstedt-oauth-security-01#section-4.6.4)?
"Second,
confidentiality protection of the exchanges between the client and
the authorization server and between the client and the resource
server MUST be applied"
I would suggest to add ", e.g. by using TLS".
I would furthermore suggest to add the following paragraph to this section:
Token abuse by counterfeit server: Clients SHOULD not make authenticated
requests with an access
token to unfamiliar resource servers, regardless of the presence
of a secure channel. If the resource server address is well-known
to the client, it MUST authenticate the resource servers by using
HTTPS server authentication prior sending the request.
section 3.3
"Don't store bearer tokens in cookies As cookies are generally sent in
the clear, implementations MUST NOT store bearer tokens within
them."
Every cookie can be declared to be send over encrypted channels only.
Moreover, it is subject to a same origin policy. So what is the threat
here? Is it about the storage in the clear?
"Instead, pass browser tokens in message bodies for which confidentiality
measures are taken."
I suggest to add "authorization headers or" before message bodies.
regards,
Torsten.
Am 02.03.2011 09:31, schrieb Hannes Tschofenig:
This is a Last Call for comments on
http://www.ietf.org/id/draft-ietf-oauth-v2-bearer-03.txt
Please have your comments in no later than March 25 (extended deadline because
of the ongoing OAuth base specification WGLC).
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/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
