Closed TobiasAhnoff closed 1 month ago
@TobiasAhnoff or @randomstuff - please explain, what security problem it solves?
The client can make sure that the user does not tamper with the content of the authorization request such as:
Moreover this aligns with FAPI 2.0?
Yes, PAR closes a number of tampering issues (integrity protection for the auth request), see e g https://openid.bitbucket.io/fapi/fapi-2_0-security-profile.html#name-main-differences-to-fapi-10
Is this PR-ready proposal or is there something to add? (such as defining the reason to exists - what it mitigates)
Verify that grant type 'code' is always used together with PAR requiring client authentication.
for L1-L2 PAR is optional and could be used without client authentication
It does not make much sense to allow for PAR without client authentication if the client is confidential. Maybe something like:
Verify that grant type 'code' is always used together with PAR. requiring client authentication for confidential clients. (L3)
Which actually could be split in:
Verify that grant type 'code' is always used together with PAR (L3).
Verify that if PAR is used pushed authorization requests require client authentication for confidential clients (L1, L2, L3).
but the last one is really "Verify that confidential clients must use client authentication on backend endpoints (such as token endpoint, PAR endpoint".
Is the authentication part covered by https://github.com/OWASP/ASVS/issues/2038#issuecomment-2363718466?
Verify that all clients are confidential and configured to use strong client authentication methods, i. e. 'mTLS' or 'private-key-jwt'.
Or you need both of them?
Is the authentication part covered by https://github.com/OWASP/ASVS/issues/2038#issuecomment-2363718466?
Verify that all clients are confidential and configured to use strong client authentication methods, i. e. 'mTLS' or 'private-key-jwt'.
To be nitpicky, this one currently does not explicitly includes the verification that the authorization server actually enforces the usage of the strong authentication method. As an auditor, checking that the client actually sends the strong authentication it one thing but what we really ought to do is to check that the authorization servers actually checks that authentication.
I already happened to find cases (not in OAuth) where the client was authenticating allright but at some point I found (out of pure luck actually) that the server was actually not configured to require authentication at all :)
@randomstuff - please add your last comment to #2038.
My question in this issue is, is this requirement alone is enough (taking into account the outcome from #2038) or we need another separate requirement to ask for authentication?
Verify that grant type 'code' is always used together with PAR (L3).
We probably should not need to add a specific requirement here about client authentication. It should be already covered by what will result out of #2038.
At the moment it goes to the document as: | # | Description | L1 | L2 | L3 |
---|---|---|---|---|---|
51.2.8 | [ADDED] Verify that grant type 'code' is always used together with pushed authorization requests (PAR). | ✓ |
I agree with previous comments, "Verify that grant type 'code' is always used together with pushed authorization requests (PAR)" is enough, for reference, the PAR RFC simply states that
The authorization server MUST process the request as follows:
- Authenticate the client in the same way as at the token endpoint (Section 2.3 of [RFC6749]).
and that is addressed by #2109 "Verify that all confidential clients are authenticated for all token requests to the authorization server." and also the strong authentication method aspects in #2038
and that is addressed by "Verify that all confidential clients are authenticated for all token requests to the authorization server."
A request to the PAR endpoint is not a token request, it is a pushed authorization request. This is not even the same endpoint.
The request to the token endpoint should be authenticated using client credentials and the PAR request should also be authenticated using client credentials.
Is there anything that need to be improved in the requirement?
@elarlang, No, I think we can handle this point in #2109 instead.
PAR is part of FAPI 2 requirements and the following verification is suggested to address PAR:
V51.2 Authorization Server
Verify that grant type 'code' is always used together with PAR requiring client authentication (for L1-L2 PAR is optional and could be used without client authentication). (L3)