What kind of change does this PR introduce?

Feature implementation.

What is the current behavior?

When fetching or refreshing an OAuth2 access token, the TLS verify setting uses the same value as regular resource requests (session-level verify). There is no way to specify a different CA certificate bundle specifically for the token endpoint.

This is problematic when the token endpoint uses a different certificate chain (e.g., an internal CA) than the resource endpoints.

What is the new behavior?

A new token_endpoint_verify parameter is available on both OAuth2Session (via OAuth2Client) and AssertionSession (via AssertionClient). When set, it is used as the verify value for token endpoint requests (fetch_token and refresh_token), while regular resource requests remain unaffected.

Before

# No way to use a different CA for the token endpoint
sess = OAuth2Session(client_id="foo", client_secret="bar", ...)
sess.verify = "/path/to/resource-ca.pem"  # Applies to ALL requests

After

sess = OAuth2Session(
    client_id="foo",
    client_secret="bar",
    token_endpoint="https://idp.internal/token",
    grant_type="client_credentials",
    token_endpoint_verify="/path/to/idp-ca.pem",  # Only for token requests
)
sess.verify = "/path/to/resource-ca.pem"  # For resource requests

The same works for AssertionSession:

sess = AssertionSession(
    "https://idp.internal/token",
    issuer="my-app",
    subject="my-app",
    audience="https://idp.internal/token",
    header={"alg": "RS256"},
    key=private_key,
    token_endpoint_verify="/path/to/idp-ca.pem",
)

If an explicit verify kwarg is passed to fetch_token(), it takes precedence over token_endpoint_verify.

Notes

• This feature is primarily useful for the requests integration where verify is a per-request parameter.
• For the httpx integration, verify is a client-level setting (not per-request), so token_endpoint_verify is accepted but has no effect for httpx clients. A future enhancement could address this with a custom transport.

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.