Use String equality, not URL equality, for JWT issuer validation

Summary

URL equality is not consistent becuse it attempts DNS resolution and host comparison, which can cause both false positives and false negatives.

RFC 7519 describes “iss” claim as being a StringOrURI value, and restricts StringOrURI validation to string equality:

StringOrURI values are compared as case-sensitive strings with no transformations or canonicalizations applied.

JwtIssuerValidator should replace URL equality with plain case-sensitive string equality.

Actual Behavior

In a load balanced environment (GCP AppEngine Flexible) issuer verification behavior is inconsistent; it fails some of the time with exception below, even though the string issuer matches the required issuer perfectly.

BearerTokenAuthenticationFilter : Authentication request for failed: org.springframework.security.oauth2.core.OAuth2AuthenticationException: An error occurred while attempting to decode the Jwt: This iss claim is not equal to the configured issuer

Expected Behavior

Issuer check should succeed if and only if JWT string issuer matches expected string issuer.

Version

spring-security-oauth2-resource-server:jar:5.1.1.RELEASE

Sample

I can reproduce the problem consistently when deploying the following sample to GCP AppEngine Flexible. The first 30 or so times the application is accessed, OAuth2-based IAP authentication works great, but after that the load balancer kicks traffic over to a different subnet, and issuer verification starts failing consistently. https://github.com/spring-cloud/spring-cloud-gcp/tree/master/spring-cloud-gcp-samples/spring-cloud-gcp-security-iap-sample

[elefeint]

Jinx timing! And yes, 5.1.2.BUILD-SNAPSHOT fixes the issue completely.

When are you planning to release spring-security 5.1.2?

[ejazazim]

I was facing the same issue on AWS while using Cognito as Authentication provider and custom user info endpoint in my own OAuth2 Resource Server.

Updating to Boot 2.1.1 release fixed the issue.