What kind of change does this PR introduce?

This is a feature implementation.

Description

Add a should_handle(headers, claims) method to JWTBearerClientAssertion that subclasses can override to filter JWT assertions by algorithm type. This enables registering separate handlers for client_secret_jwt (symmetric) and private_key_jwt (asymmetric) on the same authorization server.

When both auth methods use the same client_assertion_type (urn:ietf:params:oauth:client-assertion-type:jwt-bearer), the server must inspect the JWT alg header to route to the correct handler. Without this hook, the first registered handler may attempt verification with the wrong key type and raise InvalidClientError, preventing the correct handler from being tried.

Usage:

SYMMETRIC_ALGS = {"HS256", "HS384", "HS512"}

class ClientSecretJWTAuth(JWTBearerClientAssertion):
    CLIENT_AUTH_METHOD = "client_secret_jwt"

    def should_handle(self, headers, claims):
        return headers.get("alg") in SYMMETRIC_ALGS

class PrivateKeyJWTAuth(JWTBearerClientAssertion):
    CLIENT_AUTH_METHOD = "private_key_jwt"

    def should_handle(self, headers, claims):
        return headers.get("alg") not in SYMMETRIC_ALGS

The default should_handle() returns True, maintaining full backward compatibility.

Checklist

• The commits follow the conventional commits specification.
• You ran the linters with prek.
• You wrote unit test to demonstrate the bug you are fixing, or to stress the feature you are bringing.
• You reached 100% of code coverage on the code you edited, without abusive use of pragma: no cover
• If this PR is about a new feature, or a behavior change, you have updated the documentation accordingly.

• You consent that the copyright of your pull request source code belongs to Authlib's author.