OWASP / ASVS

Application Security Verification Standard
Creative Commons Attribution Share Alike 4.0 International
2.74k stars 668 forks source link

V51 OAuth: Add verification for PAR #2042

Closed TobiasAhnoff closed 1 month ago

TobiasAhnoff commented 2 months ago

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)

elarlang commented 1 month ago

@TobiasAhnoff or @randomstuff - please explain, what security problem it solves?

randomstuff commented 1 month ago

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?

TobiasAhnoff commented 1 month ago

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

elarlang commented 1 month ago

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.

randomstuff commented 1 month ago

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

elarlang commented 1 month ago

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?

randomstuff commented 1 month ago

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

elarlang commented 1 month ago

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

randomstuff commented 1 month ago

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.

elarlang commented 1 month ago
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).
TobiasAhnoff commented 1 month ago

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:

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

randomstuff commented 1 month ago

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.

elarlang commented 1 month ago

Is there anything that need to be improved in the requirement?

randomstuff commented 1 month ago

@elarlang, No, I think we can handle this point in #2109 instead.