V51 - OAuth - confidential client

[elarlang]

Spin-off from #2040 (comment)

Verify that confidential clients must use client authentication in refresh token requests. (L1, L2, L3)

Isn't it the point for confidential client to use client authentication?

If we require it from Level 1 from confidential client but allow public clients without any restrictions, I would say there is a conflict.

Is it required only for refresh token request or to any request to token endpoint?

[randomstuff]

I believe the idea here is that that some authorization server implementations could assume that presenting the refresh token is enough for refreshing the token (as presenting the access token is enough for using the service). This is requirement is indeed valid for all requests to the token endpoint.

A more precise wording of this requirement could be something like: ”Verify that, for using refresh tokens emitted to a confidential client, the authorization server requires authentication of this client.“

[elarlang]

Isn't it the point for confidential client to use client authentication?

My point is - can you use confidential client without authentication for the token endpoint?

... for using refresh tokens emitted

but asking the refresh token with token request?

[TobiasAhnoff]

My point is - can you use confidential client without authentication for the token endpoint?

It should not be possible, but not all AS implementations follows the RFC which states that confidential clients must be authenticated, both when using refresh-tokens, authorization codes or client-credentials.
See in example https://www.rfc-editor.org/rfc/rfc6749.html#section-4.1.3

This is important for a secure OAuth implementation, but perhaps not a widespread issue, except if using a custom built AS or flow (not "well-known industry standard"). Still, I think it is a good level 1 requirement for ASVS.

It could also me written to not just focus on refresh-tokens, like this

Verify that all confidential clients are authenticated for all token requests. (L1, L2, L3)

There is no conflict with public clients, since the requirement only applies to confidential clients.

[elarlang]

Ok, the definition says "capable of", not doing so https://datatracker.ietf.org/doc/html/rfc6749#section-2.1

confidential - Clients capable of maintaining the confidentiality of their credentials (e.g., client implemented on a secure server with restricted access to the client credentials), or capable of secure client authentication using other means.

So from that perspective it makes sense.

Should we add "authorization server" in the requirement?

Verify that all confidential clients are authenticated for all token requests to the authorization server.

[elarlang]

At the moment it goes to the document as:

#	Description	L1	L2	L3
51.2.7	[ADDED] Verify that all confidential clients are authenticated for all token requests to the authorization server.	✓	✓	✓

[randomstuff]

Coming from #2042, should we extend this to include other backend requests (such as PAR, token revocation, token introspection). Something in the line:

Verify that all confidential clients are authenticated for client-to-authorized server backchannel request such as token requests, PAR requests, token revocation requests and token introspection requests.

[elarlang]

Update - from "all confidential clients" to "confidential client"

#	Description	L1	L2	L3
51.2.7	[ADDED] Verify that confidential client is authenticated for client-to-authorized server backchannel requests such as token requests, PAR requests, token revocation requests, and token introspection requests.	✓	✓	✓