Creating a way to mandate Request Object (by value or by reference)
Issue #1171
resolved
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_algpresent as a signal the client must always use a request object. -
I don’t think that the presence of the
request_object_signing_algis 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_algas 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_objectclient metadata boolean, where, i believe JAR is the right place for it. - add
require_request_objectserver metadata boolean, where, i believe JAR is the right place for it too. - implementations already use the presence of
request_object_signing_algto 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_algshould 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_objectsrequest_object_signing_alglocks the JWS alg for request objects, but it doesn’t prevent regular OAuth requests from being made.request_object_signing_alg
OPTIONAL. JWS [JWS]
algalgorithm [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_objectand that the metadata description should say thatnonecan't be used to satisfy this. -
-
assigned issue to
Nat Sakimura
-
assigned issue to
-
reporter
What would be the behaviour of the server when the value of
require_request_objectis 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” ]