Spring25: Proposal to RECOMMEND the use of Signed Request Object for the /authorize endpoint to prevent abuse

[mhfoo]

Problem description
The simplest version of the OIDC /authorize endpoint is an unprotected endpoint with no means to authenticate the direct and indirect API Consumer. Anybody can monitor the existing traffic interaction with the /authorize endpoint (using a frontend application), and then perform a brute force attack on the /authorize endpoint to generate unnecessary auth codes.
The PKCE and nonce does not prevent the above scenarios.

In a federated scenario, the simplest version of the OIDC /authorize endpoint will allow chaining of unnecessary calls to downstream OIDC /authorize endpoints.

This is reopening issue #128 for Spring25 consideration.

Possible evolution
For the Spring25 CAMARA meta-release:

Recommend Signed Request Object for /authorize endpoint to be implemented, as per OIDC, Chapter 6, Passing Request Parameters as JWTs. The application backend will prepare and sign the request object using a private key, with the corresponding public key being published on well-know jwks endpoint. The application backend will then pass the signed request object to the application front using a 302 redirect response, where the application frontend will follow the redirect URL to invoke the intended /authorize endpoint. The /authorize endpoint will validate the signature of the signed request object with the corresponding jwks endpoint (which was registered as part of the onboarding process), identified using the client_id.

Alternative solution

Additional context
Related to Number Verification PR 94

[jpengar]

@mhfoo Why did you open a new issue on this topic? Why not just use your previous issue (#204) for the same purpose? Or better yet, when #204 was opened, it was mentioned that #194 already covered the discussion of mandating the use of signed requests for CIBA (as the original issue proposal), and Auth code was also covered in the discussion.

Did you manage to take a look at #194 comments?

[mhfoo]

@jpengar
yes, I took a look at #194 and the comments. The requestor explicitly mentioned the proposal is for CIBA, not for Auth Code, for the Spring25 meta-release.

#204 is my request for clarification on the current Fall24 meta-release documentation. I am ok to close this issue when it is answered by the ICM working group or community. I am able to infer the answer, but my intended stakeholders/audience need an explicit answer to this question.

Hence, I see all 3 issues are related but the purpose and the requested outcomes are different. I hope this clarifies.

[jpengar]

@jpengar yes, I took a look at #194 and the comments. The requestor explicitly mentioned the proposal is for CIBA, not for Auth Code, for the Spring25 meta-release.

#204 is my request for clarification on the current Fall24 meta-release documentation. I am ok to close this issue when it is answered by the ICM working group or community. I am able to infer the answer, but my intended stakeholders/audience need an explicit answer to this question.

Hence, I see all 3 issues are related but the purpose and the requested outcomes are different. I hope this clarifies.

@mhfoo Fair enough 😜, I hope we really manage to keep these discussions isolated rather than having similar parallel discussions in different places. 🤞

[mhfoo]

In view of interoperability between operators (in terms of securing the customer data, CAMARA certification), the proposal is to make signed request object for AuthCode flow to be mandatory between operators.

[jpengar]

@eric-murray's PR #217 recommends using signed requests for CIBA, but still allows the use of unsigned requests. It fixes #194. Should we extend this PR to recommend signed requests for both CIBA and Auth code flow to also address #205?
@mhfoo @AxelNennker @sebdewet

[mhfoo]

@eric-murray's PR #217 recommends using signed requests for CIBA, but still allows the use of unsigned requests. It fixes #194. Should we extend this PR to recommend signed requests for both CIBA and Auth code flow to also address #205? @mhfoo @AxelNennker @sebdewet

Agree to recommend signed requests for both CIBA and Auth Code flows. Signed requests can be used as an idempotency key in both scenarios.

If majority of operators agree, the proposal is to make it mandatory between operators.

[mhfoo]

@trehman-gsma 👆🏻

[AxelNennker]

To move forward with this issue I created a PR that recommends using signed requests in OIDC authorization code flow.
Please review #226