Proposal: add requirements to verify correct implementation of OAuth PAR and JAR

[mirokarv]

Currently, ASVS v5.0 recommends the use of Pushed Authorization Requests (PAR) or JWT-Secured Authorization Requests (JAR) in two Level 3 requirements:

10.4.12 and 10.4.15

But, there are no verification requirements to ensure these are implemented correctly.

I think these requirements might be good to add:

1. Verify that when PAR is used, the authorization server binds each request_uri to the client_id of the client that created it. A request_uri issued for one client must be rejected when presented by a different client.

RFC 9126 says: "The request_uri value MUST be bound to the client that posted the authorization request."

2. Verify that when PAR is used, the authorization server treats request_uri values as one-time use and rejects expired request_uri values. The lifetime of the request_uri (expires_in) must be short, typically ≤ 90 seconds and must not exceed 600 seconds.

RFC 9126 says "An attacker could replay a request URI captured from a legitimate authorization request. In order to cope with such attacks, the authorization server SHOULD make the request URIs one-time use."

3. Verify that when JAR is used, the authorization server requires a unique jti claim in the request object and enforces replay protection by rejecting previously used jti values within the object's validity period. Verify that the request object contains an exp claim with a short lifetime.

No direct RFC or OIDC FAPI requirements, but replay protection and short lifetime is critical whenever the request object contains security-sensitive or dynamic parameters that should not be reusable. like authorization_details param, or custom parameters that carry session context or change the effective authentication/authorization level of an already-authenticated user.

4. Verify that when JAR is used (standalone or inside PAR), the client_id value in the authorization request query parameter exactly matches the client_id claim inside the signed request object.

RFC 9101 says "The client ID values in the client_id request parameter and in the Request Object client_id claim MUST be identical."

5. Verify that when PAR or JAR is used, the authorization server does not allow query string parameters on the /authorize endpoint to override values contained in the pushed request or request object. The server must only use parameters from the request object / pushed data.

RFC 9101 says for JAR "The authorization server MUST extract the set of authorization request parameters from the Request Object value. The authorization server MUST only use the parameters in the Request Object, even if the same parameter is provided in the query parameter." IMO, same applies to PAR too. Or does 15.3.7 already cover this? I think this is still specific enough to warrant its own requirement.

Thoughts?

[narfbg]

Where upstream RFCs use the MUST keyword, that's already part of the protocol and therefore non-compliant implementations aren't really using JAR/PAR. It seems redundant to repeat such requirements without further restrictions or addressing ambiguities.

[mirokarv]

I can see the point, but a problem is that when I identify an issue defined in an RFC that has not been implemented correctly. In such cases, it is unclear where this should be reported within the ASVS audit report.

Could one possible solution be to introduce a documentation requirement that specifically lists RFCs that have been explicitly implemented by the development team within the application? While excluding standards that are handled by underlying libraries or frameworks (such as HTTP), and only focus on RFCs with custom or application-level implementations. This might even help dev teams, where everyone understands that "bob" just didn't make it up.

But that then would require a requirement, to check that those have been implemented correctly....

This is a bit of problem, since companies do make their own OAuth client and server implementations time to time.

[narfbg]

Yeah, I know the pain ... Not limited to OAuth, in my experience deviation from standards is among the top conditions leading to vulnerabilities, yet almost never black-and-white enough to classify as security failures, very frustrating.

I'm very much in favor of compliance with applicable RFCs as a security requirement, but that can also be a double-edged sword and very tricky to define. That's just me though, and my ideas often aren't very mainstream. 😄

[elarlang]

Moi, @mirokarv, thank you for your detailed input and proposals.

I don't comment on proposals from the technical side, but more from a ASVS requirement buildup side.

If we have a requirement for something already (e.g., PAR must be used), it is good to have technical conditions in the same requirement. As PAR is mentioned in 3 requirements, it is a bit more complicated task.

Proposals are detailed (as there are many aspects to cover) and lead to the implementation guide area. An ASVS requirement should be more focused on the security weakness to cover - an ideal requirement is self-explanatory, what security problem it addresses. It may get lengthy to cover many situations, 10.4.5 can be example for such requirement.

I'm not a big fan of the idea of pointing to external resources in a requirement text, such as an RFC, but we have done it for some requirements (5.4.2), and it may work in this situation. As rules for PAR and JAR are written in separate specifications, we may point to those specifications.

ping @randomstuff @TobiasAhnoff

[randomstuff]

Where upstream RFCs use the MUST keyword, that's already part of the protocol and therefore non-compliant implementations aren't really using JAR/PAR.

I think that many requirements in the documents are checks of requirements of the related protocol standards. An auditor would still need to check that these requirements are actually (and properly) implemented. Moreover many requirements from existing protocol standards do not have a direct security impact and are not relevant here.

---

Verify that when PAR is used, the authorization server binds each request_uri to the client_id of the client that created it. A request_uri issued for one client must be rejected when presented by a different client.

I would say that this is not really specific to PAR.

A related topic is:

10.4.10 Verify that confidential client is authenticated for client‑to‑authorized server backchannel requests such as token requests, pushed authorization requests (PAR), and token revocation requests.

What may be lacking in the context of PAR is the requirement that the client_id in the PAR body maps to the authenticated client (eg. if using a client assertion, basic authentication, TLS authentication, etc.).

---

Verify that when PAR is used, the authorization server treats request_uri values as one-time use and rejects expired request_uri values. The lifetime of the request_uri (expires_in) must be short, typically ≤ 90 seconds and must not exceed 600 seconds.

Yes, this might be needed. I am wondering if it would make sense to include it into a more general requirement about short-lived AS state in general in order to avoid creating too many requirements.

---

Verify that when JAR is used, the authorization server requires a unique jti claim in the request object and enforces replay protection by rejecting previously used jti values within the object's validity period. Verify that the request object contains an exp claim with a short lifetime.

For me, using jti is implementation detail and if a requirement is needed, it should be more general about implementing replay protection. For example, an implementation could use a cryptographic hash of the token to more reliably identify the token for replay protection purpose. → EDIT: that's actually a bad idea.

Another issue, is that the example from RFC 9101 does not even include the jti claim.

I believe that a more critical requirement would be to verify that that the client actually includes an (short-lived) expiration in the JAR JWT (as well as nbf and iat claims).. I do not believe this requirement is already covered anywhere else. (And a replay protection would face important scalability issues if the token does not include expiration.)

---

Verify that when JAR is used (standalone or inside PAR), the client_id value in the authorization request query parameter exactly matches the client_id claim inside the signed request object.

This might better be part of a more general requirement about protecting against cross-client / client confusion attacks:

• when client authentication is used (eg. PAR), the authenticated client must match with the client on the request (if any).

This should arguably part of a more general requirement about authorization in general which would be an argument against having an explicit requirement about this.

---

Verify that when PAR or JAR is used, the authorization server does not allow query string parameters on the /authorize endpoint to override values contained in the pushed request or request object. The server must only use parameters from the request object / pushed data.

Same thing here. I agree this is important but on the other hand this could be seen as a general requirement about request confusion ambiguity.

I would formulate something like:

Verify that when the authorization request is secured (such as with PAR or JAR), the authorization server does not accept unverified request parameters or override existing request parameters (eg. by adding them in the query string).

Nitpick: when using OIDC, the request parameter could be passed in the request body, not only in the request parameter.

[mirokarv]

Verify that when JAR is used (standalone or inside PAR), the client_id value in the authorization request query parameter exactly matches the client_id claim inside the signed request object.

This might better be part of a more general requirement about protecting against cross-client / client confusion attacks:

• when client authentication is used (eg. PAR), the authenticated client must match with the client on the request (if any).

I agree, now that i think more about this, the first PAR suggestions and this can be combined. And authorization code also needs to be bound to the client who requested it and verified in /token endpoint. Is there any more these types of objects than code, PAR, and JAR?

Maybe something like this:

• Verify that the authorization server enforces strict client binding for every authorization artifact (e.g. code, PAR, JAR) it issues or accepts.

[randomstuff]

⚠️ I have edited my previous comment to delete an invalid statement I made about using hash of the token for revocation instead of jti. That is not secure in general because the JWT itself is malleable (as I realized recently).