Rejection reason code to /warden/token/allowed

[nikolay-turpitko]

Currently /warden/token/allowed returns {"allowed": false} without any reason code. It requires additional /oauth2/introspect request (or database request) to distinguish between expired token and access forbidden due scope/policies. It would be nice to have some reason code to avoid these additional requests. Like {"allowed": false, "due": "expired token"} or {"allowed": false, "due": "access forbidden"}, etc.

I think, "expired token" and "invalid token" should be different reasons, because with expired token app can make attempt to refresh it, while it doesn't make sense in other cases.

[aeneasr]

I like this idea, because currently this is only possible if you real-time watch the logs, and then, only if you don't have a lot of requests. Unfortunately, the RFC 7662 Sepcification says the following on this topic:

Note that to avoid disclosing too
much of the authorization server's state to a third party, the
authorization server SHOULD NOT include any additional information
about an inactive token, including why the token is inactive.

I'm not sure how to deal with this right now.

[aeneasr]

Sorry, I closed this accidentally.

[nikolay-turpitko]

Well, RFC 7662, say "SHOULD NOT" not "MUST NOT" at this particular point. And https://tools.ietf.org/html/rfc2119 explains, that

SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that
there may exist valid reasons in particular circumstances when the
particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed
before implementing any behavior described with this label.

But, seriously, it probably not worth it. Fill free to close this issue.