-
assigned issue to
Possible oddity in token endpoint http status code for 'access_denied' error
https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html#token_error_response defined the additional ‘access_denied’ error, which basically says use the definition from device flow, i.e. https://tools.ietf.org/html/draft-ietf-oauth-device-flow-13#section-3.5
Both defer back to https://tools.ietf.org/html/rfc6749#section-5.2 :
The authorization server responds with an HTTP 400 (Bad Request)
status code (unless specified otherwise) and includes the following
parameters with the response: <…>
so my reading (and Authlete’s) is that an access_denied error should be returned with a 400 result from the token endpoint, as there’s nothing anywhere that obviously says otherwise.
This is odd in comparison to the backchannel authentication endpoint, https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0-02.html#rfc.section.13 which explicitly calls out that in that case a 403:
HTTP 403 Forbidden
access_denied
It seems weird to have an access denied error return 400 from the token endpoint but 403 from the back channel authentication endpoint.
I’d probably veer towards explicitly making it a 403 in both cases (as long as the device flow folks agree).
Comments (8)
-
-
Discussion on today’s call seem to settle around the feeling that this wasn’t particularly important, generally all clients will treat all 4xx (or non-200) status codes the same.
The suggestion was hence to close without any action.
A further question arose about how strict the conformance tests should be in testing the behaviour and a similar consensus that any 4xx result is okay seem to be reached. It’d be good to try and formalise that as a WG decision somehow.
-
reporter WG agreed on 23rd July that strict checking of 4xx codes isn’t helpful, so certification test shouldn’t be that picky.
We should add a sentence to the spec encouraging client authors to look at the json body rather than the http code.
-
Suggested text
NOTE: Implementers should always check the body of the response as well as the HTTP status code when determining the next action to take.
-
if you receive a 4xx response and it contains JSON, use that.
-
-
-
assigned issue to
-
assigned issue to
-
- changed status to resolved
Merged in i156 (pull request
#72) to fix issue#156Add note instructing clients to look error bodies
Approved-by: Brian Campbell Approved-by: Bjorn Hjelm
→ <<cset ca88c8dbd8e7>>
- Log in to comment