Client Authentication error
Hi, and implementation question
Reading Section 9 of openid and also the reference OAuth Assertion Framework I'm not sure about what error should an OP return when there are a fail in the credential that has been sent to the OP, for example, an RP sent a request to the /token endpoint using as authentication method ‘private_key_jwt' and the jwt that is sent don't contain the mandatory field 'sub’ in the payload (as described in Section 9 of openid) what error should the OP return in this case?
Option 1: following the OAuth Assertion Framework i would say:
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_client"
"error_description":"assertion format incorrect"
}
Option 2: following oAuth i would say
HTTP/1.1 400 Bad Request
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_request"
"error_description":"assertion format incorrect"
}
Option 3: And in my opinion should be a
HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store
{
"error":"invalid_client"
"error_description":"assertion format incorrect"
}
Best Regards.
Comments (8)
-
-
For invalid_client, RFC6749 allows both http 400 and 401 to be returned, so if ‘1' is fine then so is '3’ and vice versa.
The FAPI conformance suite (which also tests much of the openid connect / underlying OAuth2 specs as part of those tests) currently takes the view that all 3 are permitted for the similar case of an assertion with an invalid aud.
In general it’s not too important to worry about the exact form an error takes; in these cases the most important things are:
- The server does reject the request
- That it is clear to the developer of the client/relying party why the request was rejected (i.e. that a useful ‘error_description’ is provided); though this is not required by the specs
(I’m a member of the OpenID Foundation certification team, so this response is mostly written from that view point.)
-
I agree with @Joseph Heenan 's analysis about what errors are permitted and appropriate. I also agree with @Filip Skokan that one should consider the privacy implications of the errors returned.
-
I agree with Filip’s analysis separating ‘invalid_request’ from ‘invalid_client’. In regards to whether to return 400 or 401, I agree with Joseph, both are probably ok. In general there is little industry best practice around which error codes should be returned in these kinds of situations and so it is likely that different implementations will do things slightly differently.
So, with that said, if the ‘sub’ claim is missing and it is required, I’d return a 400 ‘invalid_request’ request error and possibly set the error_description to “missing sub claim”. If there is concern that providing that detail will enable an attacker to more quickly resolve issues then you can be less precise
-
-
assigned issue to
-
assigned issue to
-
- changed status to open
Is there any proposed spec change or clarification or should this issue be closed with no action?
-
@Michael Jones no action required.
-
- changed status to resolved
Closing on the basis that no action is required, per the discussion in the issue.
- Log in to comment
My $.02, as given in our previous conversation.