Client Authentication error

[Jorge Oliva]

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.

[Filip Skokan]

My $.02, as given in our previous conversation.

‌

• when the format of the assertion is invalid (e.g. JWT can’t be parsed, client_assertion_type is not provided or invalid value), give a 400 invalid_request. The format is public knowledge and invalid_request usually includes clear descriptions that will help developers fix their issue.
• when the content of the assertion is invalid (signature is invalid, jwt is expired, algorithm mismatches from the pre-registered one, audience mismatches) its an invalid_client error with a generic message as to not expose unnecessary details.

‌

[Joseph Heenan]

‌

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:

1. The server does reject the request
2. 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.)

[Michael Jones]

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.

[gffletch]

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

[Michael Jones]

Is there any proposed spec change or clarification or should this issue be closed with no action?

[Filip Skokan]

@Michael Jones no action required.