Wrong error code returned from protected resource

[jricher]

The protected resource is directed to return a 403 code when no token is presented, but this should be a 401 code as the client is immediately directed at what to do to gain access. However, see #163 for notes on handling other error codes.

[xmlgrrl]

For reference: This appears in Core Sec 3.1.1 (https://docs.kantarainitiative.org/uma/rec-uma-core.html#rfc.section.3.1.1): "It SHOULD respond with the HTTP 403 (Forbidden) status code, providing the authorization server's URI in an "as_uri" property in the header, along with the just-received permission ticket in the body in a JSON-encoded "ticket" property. Responses that use any code other than 403 are undefined by this specification; any common or best practices for returning other status codes will be documented in the [UMA-Impl]."

[xmlgrrl]

For background: A long time ago, we tried to align with OAuth 1, and then OAuth 2, as best we could. But our designs diverged significantly enough that we stepped back and went our own way. After using a mix of 401 and 403, ultimately we unified on 403.

And FWIW: I found the following thread potentially helpful:

http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses

[jricher]

From the stack overflow response linked above, this is very clearly a 401: it's a temporary condition that the RS is telling the client how to fix.

[xmlgrrl]

As discussed on UMA telecon 2015-08-27: The decision taken on #163 / #168 renders this issue moot, so it can be closed.