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
Due to the large size of a Trust Chain, it may be necessary to use the HTTP POST method, request_uri, or a Pushed Authorization Request [RFC9126] for the request.
The request_uri asks the OP to fetch an external resource and this makes it easier to launch DoS attacks against Federation OPs. I propose to say request_uri MUST NOT or SHOULD NOT be used by RPs and accepted by OPs.
OIDC recognised this issue and because of that it has the OP request_uri_parameter_supported + require_request_uri_registration metadata and the RP request_uris metadata. So that the request_uri's can be screened before the RP can use them.
In automatic registration if a request_uri is used the OP needs to trust it blindly. If the downloaded JWT contains no Trust Chain what should the OP do then? Stop? Or resolve the client_id, fetching more resources?
It's good security policy to limit and minimise the number of resources at unverified URLs that need to be fetched. POSTing the request object or PAR is sufficient when dealing with large authentication requests (including requests that carry a trust_chain).
The text was updated successfully, but these errors were encountered:
I understand the security aspects of your proposal. I'd be curious to hear whether implementers believe that request objects will become too big in practice to pass as authorization request parameters.
Or I suppose that PAR is a possibility in that case, but the use of PAR actually requires the use of request_uri to pass the PAR response to the authorization endpoint. How would we allow the PAR usage of request_uri but not the normal usage of it?
Authorization server policy MAY dictate, either globally or on a per-client basis, that PAR be the only means for a client to pass authorization request data. In this case, the authorization server will refuse, using the invalid_request error code, to process any request to the authorization endpoint that does not have a request_uri parameter with a value obtained from the PAR endpoint.
The
request_uri
asks the OP to fetch an external resource and this makes it easier to launch DoS attacks against Federation OPs. I propose to sayrequest_uri
MUST NOT or SHOULD NOT be used by RPs and accepted by OPs.OIDC recognised this issue and because of that it has the OP
request_uri_parameter_supported
+require_request_uri_registration
metadata and the RPrequest_uris
metadata. So that therequest_uri
's can be screened before the RP can use them.In automatic registration if a
request_uri
is used the OP needs to trust it blindly. If the downloaded JWT contains no Trust Chain what should the OP do then? Stop? Or resolve theclient_id
, fetching more resources?It's good security policy to limit and minimise the number of resources at unverified URLs that need to be fetched. POSTing the
request
object or PAR is sufficient when dealing with large authentication requests (including requests that carry atrust_chain
).The text was updated successfully, but these errors were encountered: