Stricter-then-standard parameter checking
Description
Environment
Activity
Scott Cantor May 31, 2022 at 1:24 PM
I’ll close out then, just file a support ticket it you need further advice on doing it. But you should be cognizant of the fact that like with the signature stuff, it’s likely not going to be fully API stable to do this because we’re currently very dependent on Nimbus' message classes but the plan is to get off them eventually.
Simone Avogadro May 31, 2022 at 12:59 PM
I fully understand your feedback and agree: refusing RP requests that should be accepted under the standard means making the the OP non fully standard compliant.
This was more a request-for-advice then a request-for-feature and the advice to use the inbound interceptor is a good response here, thanks
Scott Cantor May 31, 2022 at 12:39 PM
I think we should strictly follow the spec here, not add other rules that simply aren’t part of it. I assume the behavior here is just that it overrides the query parameters, as I believe that’s how it’s specified (request object takes precedence).
It’s actually wrong to require scope be identical. We require it, by default, to be a subset of what was already validated on the front-channel though, but we don’t (and should not) require that it be identical, the spec allows narrowing on subsequent token requests.
If you want to implement other checks, I’d probably just do it in an inbound interceptor.
We’ve a use-case where during the authorization phase (Auth code with PKCE using private_key_jwt authentication) we’d want to enforce that the following three parameters:
response_type
client_id
scope
to be present and have identical values both as:
request parameters
JWT claims inside the RP-signed jar parameter
we could reasonabily check for that by adding in tercepting ServletFilter but maybe the OP offers a more elegant approach to enforce that so we’re asking your opinion here