You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, if I request a scope that is not granted, I do not get an error but simply a token that only contains the scopes that I was granted. This could be for example when requesting "star" actions (e.g. org:*:*) actions or when requesting multiple actions (e.g. org:*:read,update,delete).
I might get only org:*:read in response, or maybe even an empty list of granted scopes - but no error is returned.
It may make sense to return 403, so the client knows they are denied (some) of the permissions they requested.
I see a few approaches to this:
Make it mandatory - if there is any diff between requested and granted permissions, return 403
Make it optional based on config
Make it optional based on request parameter - allow the client to decide if they want to "get whatever permissions I can" or have the server tell them to bugger off. This shouldn't be a security risk as in any case the user is not granted permissions they are not supposed to get.
In the current mode, I fear many clients will not be able to "fail early" but will get a token with lacking permissions and try to use it, and only get a failure message from the consuming service.
The text was updated successfully, but these errors were encountered:
Currently, if I request a scope that is not granted, I do not get an error but simply a token that only contains the scopes that I was granted. This could be for example when requesting "star" actions (e.g.
org:*:*
) actions or when requesting multiple actions (e.g.org:*:read,update,delete
).I might get only
org:*:read
in response, or maybe even an empty list of granted scopes - but no error is returned.It may make sense to return 403, so the client knows they are denied (some) of the permissions they requested.
I see a few approaches to this:
In the current mode, I fear many clients will not be able to "fail early" but will get a token with lacking permissions and try to use it, and only get a failure message from the consuming service.
The text was updated successfully, but these errors were encountered: