Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disallow request_uri in OpenID authentication requests with automatic registration #114

Open
vdzhuvinov opened this issue Oct 24, 2024 · 2 comments · May be fixed by #119
Open

Disallow request_uri in OpenID authentication requests with automatic registration #114

vdzhuvinov opened this issue Oct 24, 2024 · 2 comments · May be fixed by #119

Comments

@vdzhuvinov
Copy link
Collaborator

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).

@selfissued
Copy link
Member

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?

@vdzhuvinov
Copy link
Collaborator Author

PAR (RFC 9126) says this:

https://datatracker.ietf.org/doc/html/rfc9126#section-4-5

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.

@selfissued selfissued linked a pull request Oct 26, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants