I definitely like the idea of an Errors section that normatively defines
error responses.
Thanks,
George
On 1/11/13 1:04 PM, Richer, Justin P. wrote:
It should follow the 6749 Token Endpoint error responses for bad
client credentials. That's what this text at the end of 2.3 is
supposed to mean:
If the client credentials are invalid or there is another error, the
Authorization Server responds with the appropriate error response
from the OAuth2 Core.
Looking at it now, it's completely non-normative and stuffed into the
examples section, which is probably not the best way to describe it.
There was some confusion about the {valid: false} response as well, so
now I'm thinking that should be pulled into an "Errors" section, perhaps?
-- Justin
On Jan 11, 2013, at 12:38 PM, George Fletcher <gffle...@aol.com
<mailto:gffle...@aol.com>>
wrote:
Additional feedback on the introspection endpoint.
What is the expected error response if the introspection endpoint is
using client credentials as recommended in section 2.1
The endpoint SHOULD also require some form of authentication to
access this endpoint, such as the Client Authentication as described
in OAuth 2 Core Specification [RFC6749
<http://tools.ietf.org/html/rfc6749>] or a separate OAuth2 Access
Token.
and the client credentials are invalid. It doesn't seem correct to
return an HTTP 200 with a body of { "valid: false } as the endpoint
probably never even tried to validate the token parameter.
I can see a couple of options...
1. Follow the RFC 6749 /token endpoint and return an HTTP 40X
response with the error described in JSON in the body of the response.
2. Follow RFC 6750 and return a WWW-Authenticate Response header that
contains the error and optionally error_description.
Thanks,
George
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
