Description
Today we generally equate public client to those which have their auth method set to "none", i.e. it they only provide a client_id in the request body to client-authenticated endpoints. All other clients are considered "confidential", i.e. they have credentials they prove the access to with the authenticated requests.
The following are measures that we apply to public clients wrt to a number of OAuth 2.0 extensions off the top of my head (i.e. this may not be a comprehensive list) that may or not be questionable when attest_jwt_client_auth is used.
TL;DR
is a client using attest_jwt_client_auth considered a confidential client with all the bells and whistles?
Refs: oauth-wg/oauth-v2-1#107
Refs: #79
Refs: https://www.ietf.org/archive/id/draft-ietf-oauth-v2-1-12.html#section-2.1
"confidential":
Clients that have credentials with the AS are designated as "confidential clients""public":
Clients without credentials are called "public clients"
#79 (unresolved at this time) puts the client type to which attest_jwt_client_auth clients fall to into question, so here's a couple more points for that discussion.
RFC 7662 - OAuth 2.0 Token Introspection, Security Considerations
https://www.rfc-editor.org/rfc/rfc7662.html#section-4
If left unprotected and un-throttled, the introspection endpoint
could present a means for an attacker to poll a series of possible
token values, fishing for a valid token. To prevent this, the
authorization server MUST require authentication of protected
resources that need to access the introspection endpoint and SHOULD
require protected resources to be specifically authorized to call the
introspection endpoint. The specifics of such authentication
credentials are out of scope of this specification, but commonly
these credentials could take the form of any valid client
authentication mechanism used with the token endpoint, an OAuth 2.0
access token, or other HTTP authorization or authentication
mechanism.
Assuming the chosen form authentication is one of the client authentication mechanisms, a public client (possibly a client made for the sole purpose of the RS retrieving token introspection responses) should not be able to get introspection responses for tokens that are not intended for it. In that same spirit, an actual public client should not be able to get introspection responses for tokens, e.g. refresh tokens, for tokens not issued for that client.
The first case (an RS registration) is most likely not going to be a public client and it would be using a method other than attest_jwt_client_auth, so no real problem there, I think.
The latter case tho, when a client is using attest_jwt_client_auth, should the AS keep track of the client instance a token was issued to and only provide introspection responses for the client instance a token was issued to? For refresh tokens this is already done, for other types of issued tokens it isn't.
BCP 240 / RFC 9700 Best Current Practice for OAuth 2.0 Security, specifically on use of PKCE
BCP 212 / RFC 8252 OAuth 2.0 for Native Apps, specifically on use of PKCE
Both BCPs require the use of PKCE for public clients.
https://www.rfc-editor.org/rfc/rfc9700.html#section-2.1.1-2.1
Public clients MUST use PKCE
https://www.rfc-editor.org/rfc/rfc8252.html#section-6
Public native app clients MUST implement the Proof Key for Code Exchange (PKCE)
Based on how these are written and how "public" is defined it would appear clients using attest_jwt_client_auth are technically no longer required to use PKCE. Should they still be required to?
BCP 240 / RFC 9700 Best Current Practice for OAuth 2.0 Security, specifically on Refresh Token Rotation
https://www.rfc-editor.org/rfc/rfc9700.html#section-2.2.2
Refresh tokens for public clients MUST be sender-constrained or use refresh token rotation as described in Section 4.14. [RFC6749] already mandates that refresh tokens for confidential clients can only be used by the client for which they were issued.
attest_jwt_client_auth (through https://www.ietf.org/archive/id/draft-ietf-oauth-attestation-based-client-auth-05.html#section-9.2) already handles this well.
No reference, on Refresh Token Sliding Expiration
Existing Authorization Servers may offer a scheme where dormant/unused refresh tokens are pruned but when an RT is used its expiration timestamp is pushed back, this can usually be done infinitely for non-public clients but maybe only to a certain total duration for public clients.
Does use of attest_jwt_client_auth make a difference here?
RFC 9126 - OAuth 2.0 Pushed Authorization Requests (PAR), specifically on use of unregistered redirect URIs
https://www.rfc-editor.org/rfc/rfc9126.html#section-2.4
The exact matching requirement MAY be relaxed when using PAR for clients that have established authentication credentials with the authorization server. This is possible since, in contrast to a conventional authorization request, the authorization server authenticates the client before the authorization process starts and thus ensures it is interacting with the legitimate client. The authorization server MAY allow such clients to specify redirect_uri values that were not previously registered with the authorization server.
Does use of attest_jwt_client_auth apply as "clients that have established authentication credentials with the authorization server" such that an AS may fall into this "MAY" clause?