Grant Management API error responses

Torsten Lodderstedt

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.

Isn’t that contradicting interoperability? BTW: I think 404 is better suited here.

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.

The spec states

grant_management_query: scope value the client uses to request an access token to query the status of its grants.

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.

With an error code invalid_token i assume?

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?

2021-02-23T12:39:24+00:00

Filip Skokan 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-authenticate scope attribute for communicating the missing scope.

2021-02-23T13:40:35+00:00

Stuart Low

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.

‌