Creating a way to mandate Request Object (by value or by reference)
This has also come up in OAuth WG.
Downgrade attack to the protocol that will force the AS to accept plain request instead of request object seems to be possible.
It was suggested there by Torsten:
I suggest to add a server metadata parameter “require_request_objects” so the AS can indicate its policy to clients.
Please discuss.
Comments (16)
-
-
Never the less, Server metadata like ‘require_request_objects’ seems to make sense.
To me as well.
As far as client downgrade, we have agreed in https://bitbucket.org/openid/connect/issues/1045/signalling-that-a-request-object-must to use the
request_object_signing_alg
present as a signal the client must always use a request object. -
I don’t think that the presence of the
request_object_signing_alg
is sufficient to imply that the AS will only support request objects. From a rollout perspective, existing clients in the field need to continue to be supported while new clients may be required to use request objects. I think from an AS perspective, I’d deploy this where the “require request object” is performed on a client_id basis and not globally.If the AS must only support request objects, then I think we need a new metadata field to communicate that.
-
The name should be
require_request_object
-
From a client registration perspective, it may be sufficient to use the presence of
request_object_signing_alg
as implying that for this client only, the client will only use request objects and not use other methods. If we take this approach, then we need to make it very clear that this is the behavior we are expecting and that Authorization Servers need to implement. -
Note that here’s the first email on the mailinglist about it, you can navigate the thread down to
#1045being created. At the moment it sounds like #1045 and this converge to do the following
- add
require_request_object
client metadata boolean, where, i believe JAR is the right place for it. - add
require_request_object
server metadata boolean, where, i believe JAR is the right place for it too. - implementations already use the presence of
request_object_signing_alg
to instruct the AS to require request object use to prevent the unexpected use of plain request objects, since the downgrade was simply unacceptable. Unfortunately my original issue is now ~2 years old and there was already an agreement on it.
- add
-
My 2 cents;
request_object_signing_alg
should be sufficient to stop the use of none. However the presence of the value should not indicate that the AS/OP will only accept singed requests so a new property should be included. Personally i’d see this value being more frequently used as part of client registration metadata rather than as a global AS/OP property mainly because the majority of RS’s that also act as OIDC/OAuth RP’s to protect web resources don’t support signed requests, most only support client_secret_basic authentication! let alone anything signed. -
the require_request_object metadata parameters allows the AS to signal it only allows signed request objects. I think this is very useful to clearly signal AS/deployment specifics constraints, such as can be found in open banking. A per client way to require signed request objects is required in deployments supporting plain and signed requests (only). So there are reasonable use cases for both settings.
-
+1 for a
require_request_objects
request_object_signing_alg
locks the JWS alg for request objects, but it doesn’t prevent regular OAuth requests from being made.request_object_signing_alg
OPTIONAL. JWS [JWS]
alg
algorithm [JWA] that MUST be used for signing Request Objects sent to the OP. All Request Objects from this Client MUST be rejected, if not signed with this algorithm … The default, if omitted, is that any algorithm supported by the OP and the RP MAY be used.
-
We agreed on the 8-Jun-20 Connect call that the metadata name should be
require_signed_request_object
and that the metadata description should say thatnone
can't be used to satisfy this. -
-
assigned issue to
-
assigned issue to
-
reporter What would be the behaviour of the server when the value of
require_request_object
is anything buttrue
?
-
reporter Falks, please review https://bitbucket.org/Nat/oauth-jwsreq/pull-requests/
-
reporter So, this result was not recorded in the ticket so I added require_request_objects.
According to the Meeting Note of 18-Jun-20, it should be
require_signed_request_object
` instead. -
reporter - changed status to open
Mike to put a reference to the relevant section in OAuth JAR draft and close this issue.
-
- changed status to resolved
This is addressed in OAuth JAR athttps://datatracker.ietf.org/doc/html/draft-ietf-oauth-jwsreq-34#section-10.5 .
- Log in to comment
If I understand correctly, it’s really a downgrade attack on the client?
If the AS is insisting on signed request objects, I can’t see how you can trick the AS into accepting plain request.
Never the less, Server metadata like ‘require_request_objects’ seems to make sense.
It might be reasonable to assume that in some cases an AS might only require request objects for higher risk access, in which case the metadata doesn’t help. To start to record that in metadata you’d need something more like
”supported_request_types”: [ “plain”, “request_object” ]