Add support for PAR #1424
Add support for PAR #1424
Conversation
This makes the reference value case-insensitive, preventing theoretical collation issues in data stores that are.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
To conform with https://datatracker.ietf.org/doc/html/rfc9126#name-request: > the authorization server MUST accept its ... pushed authorization > request endpoint URL ... as an intended audience.
|
Hey Joe -- mark this as ready again once you want one final review. Thx. |
We now call the IAuthorizeRequestValidator from the default PAR validator. This simplifies the endpoint, and also allows for a customization of the par validator to control validation of the pushed parameters.
| @@ -165,8 +165,9 @@ private static NameValueCollection ToOptimizedRawValues(this ValidatedAuthorizeR | |||
| { | |||
| // https://openid.net/specs/openid-connect-core-1_0.html#JWTRequests | |||
| // requires client id and response type to always be in URL | |||
| // REVIEW - Does this apply to pushed requests? | |||
There was a problem hiding this comment.
OIDC requires that when request objects are used, the client pass the client id and response type, in order to make the request a valid oauth request. With PAR, I don't think we need to worry about that, since PAR is an OAuth specification, and the requests we're making are valid PAR requests. In fact, an example in RFC 9126 pushes a request object containing a response_type claim without duplicating the response type outside the request object.
Since OIDC is asking for this duplication in other circumstances in order to be a valid oauth request, and the relevant oauth specification doesn't require it in this circumstance, I'm leaving it out.
OIDC requires that when request objects are used, the client pass the client id and response type, in order to make the request a valid oauth request. With PAR, we don't need to worry about that, since PAR is an OAuth specification, and the requests we're making are valid PAR requests. And in fact, an example in RFC 9126 pushes a request object containing a response_type claim without duplicating the response type outside the request object. Since OIDC is asking for this duplication in other circumstances in order to be a valid oauth request, and the relevant oauth specification doesn't require it in this circumstance, I'm leaving it out.
|
@brockallen, I've created new issues to track the follow up work on otel (#1445), and to consider cleaning up the Also, I'm convinced now that we don't need to duplicate the response_type parameter outside the request parameter when we use PAR with JAR. I don't think the special case in |
This compiles with the guidance of the FAPI 2.0 security profile.
|
grats! @josephdecock |
No description provided.