compare pkce code verifier and client secret hash in constant time

[dxbjavid]

Two token-endpoint checks still compare a client-supplied secret against a server-held value with String.equals. compareCodeVerifierWithChallenge matches the stored PKCE code_challenge against the transformed code_verifier, and with the plain transformer the challenge is the verifier itself, so the secret leaks byte by byte through timing. validateClientSecret in ClientSecretHashVerifier compares the secret hashes the same way. Route both through MessageDigest.isEqual, as the default client-secret check in AbstractTokenService and the OAuth2 token comparisons already do.

[coheigea]

Why not use OAuthUtils.compareTokens instead?

[dxbjavid]

Good call, that's cleaner. Switched both sites to OAuthUtils.compareTokens so it's consistent with the other token checks. Dropped the now-unused MessageDigest/StandardCharsets imports.