==============================================================================
docs/output/05-strict-validation.txt
The same tokens against JwtValidators.createAtJwtValidator().issuer(..).audience(..),
with the authorization server emitting RFC 9068 tokens (typ: at+jwt, client_id claim).
STRICT=true ./scripts/run.sh
==============================================================================

# the wrong-audience token that was accepted in 03:
HTTP/1.1 401 
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: The aud claim is not valid", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://127.0.0.1:8082/.well-known/oauth-protected-resource"

# a token minted for this service:
{
    "service": "downstream:8082",
    "strictValidation": true,
    "sub": "edge-service",
    "aud": [
        "downstream-api"
    ],
    "iss": "http://127.0.0.1:9000",
    "scope": "[orders.read]",
    "client_id": "edge-service",
    "authorities": [
        "FactorGrantedAuthority [authority=FACTOR_BEARER, issuedAt=<timestamp>]",
        "SCOPE_orders.read"
    ],
    "cnf": null,
    "orders": [
        {
            "id": 1,
            "total": "42.00"
        }
    ]
}

# and the edge service, which was NOT updated - it still uses Boot's
# auto-configured decoder:
HTTP/1.1 401 
WWW-Authenticate: Bearer error="invalid_token", error_description="An error occurred while attempting to decode the Jwt: the given typ value needs to be one of [JWT]", error_uri="https://tools.ietf.org/html/rfc6750#section-3.1", resource_metadata="http://127.0.0.1:8081/.well-known/oauth-protected-resource"

# Turning on RFC 9068 at the authorization server broke every resource server that
# still has NimbusJwtDecoder's default JOSE type verifier, and the error message
# mentions neither RFC 9068 nor the authorization server.