Grant Management API error responses
The section only speaks of status codes, not the whole responses (i.e. actual error codes suited for the different scenarios)
Furthermore:
If the resource URL is unknown, the authorization server responds with HTTP status code 400.
We should not dictate authorization server’s behaviour when non-existent endpoints (resource URLs) are accessed. If that is what this line intends to target that is.
If the client is not authorized to perform a call, the authorization server responds with HTTP status code 403.
I can’t see a scenario where this would happen. Given that access to this API is gated by an access token it’s in the step that issues that access token that a client would get a rejection to that access token request.
If the request lacks a valid access token, the authorization server responds with HTTP status code 401.
With an error code invalid_token
i assume?
Comments (7)
-
-
reporter Isn’t that contradicting interoperability? BTW: I think 404 is better suited here.
Of course it is better suited, which is also what triggered my creating this issue. Nevertheless, if I do not support a given endpoint, i cannot ensure it will be responded to it in a protocol-defined way, regardless of what the definition is (404 or 400). That would mean me having to define it. We can’t dictate invalid route behaviours for all authorization servers here.
meaning a given access token represents the authorization to access the grants of a certain client. If the client tries to access grants of other clients, the AS would refuse access with HTTP status code 403.
Fair enough, i’d rather dictate an error code (e.g. in the sense of RFC6750 use and error response handling). It could re-use
insufficient_scope
which also states 403 SHOULD be used and also defines a www-authenticatescope
attribute for communicating the missing scope. -
Of course it is better suited, which is also what triggered my creating this issue. Nevertheless, if I do not support a given endpoint, i cannot ensure it will be responded to it in a protocol-defined way, regardless of what the definition is (404 or 400). That would mean me having to define it. We can’t dictate invalid route behaviours for all authorization servers here.
Which code aside, for information disclosure reasons, the behaviour of
GET /grant/xx
should be the same for both non existent grants and ones for which the client does not have access.
-
-
Also covered by PR https://bitbucket.org/openid/fapi/pull-requests/272
@Filip Skokan , could you please check if we addressed all your comments?
-
reporter PR #272 resolves this issue.
-
- changed status to resolved
Thanks Filip
- Log in to comment
Isn’t that contradicting interoperability? BTW: I think 404 is better suited here.
The spec states
meaning a given access token represents the authorization to access the grants of a certain client. If the client tries to access grants of other clients, the AS would refuse access with HTTP status code 403.
good point. I checked RFC 6750 and was surprised to see this error code. So basically: yes. Out of curiosity: How many APIs use that error code?