Allow OAuth2 Authorization Server to provide JWT scope claim aligned with OAuth2 Spec (space delimited)

Expected Behavior

When setting the scopes in an OAuth2 JWT, Spring OAuth2 Authorization Service should provide the ability to set the scopes as a space separated string, in line with the OAuth2 standard, rather than how it currently provides it (as a set). It would be expected to look like so (decoded JWT):

{
  "sub": "my-client-id",
  "aud": "https://consumer.example.com",
  "nbf": 1443904077,
  "scope": "email profile",
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "iat": 1443904077,
  "jti": "43b5bb4a-2f7e-4c6b-b7b4-02a26432443a"
}

This will likely need to be optional configuration to maintain backward compatibility initially, but likely would be good to transition to this as the default in time as it aligns with the standard.

Current Behavior

The JWT currently outputs a set format, which while it appears to work fine by default within the Spring ecosystem does not follow the standard.

Example:

{
  "sub": "my-client-id",
  "aud": "https://consumer.example.com",
  "nbf": 1443904077,
  "scope": [
    "email",
    "profile"
  ],
  "iss": "https://issuer.example.com",
  "exp": 1443904177,
  "iat": 1443904077,
  "jti": "43b5bb4a-2f7e-4c6b-b7b4-02a26432443a"
}

This is achievable by requesting a list of scopes while using the token endpoint:
body.add("scope","group.key-type.server:manage group.key-type.client:manage")
Note: the endpoint for tokens supports the space delimited version (valid), unfortunately that has not made it down to the issued JWT.

Context

Relevant references:

• RFC 8693 section 4.2 detailing the format of the scope claim.
• RFC 6749 section 3.3 detailing further the expected scope format (as linked from the above)
• https://github.com/spring-projects/spring-boot/issues/15398 - Previous SB issue requesting support for space delimiated scopes
  • https://github.com/spring-projects/spring-security/issues/6256 - Underlying Spring Security issue which provided the implementation.

With this I would hope this would allow the authorization service to be more complient with different ecosystems resource servers.

A workaround that is currently possible is (in SB) writing an OAuth2TokenCustomizer<JwtEncodingContext> which contains a transformation step:

        context.getClaims().claim("scope", String.join(" ", scopes));

Start with the OAuth2TokenCustomizer workaround and trace how the authorization service builds the JWT scope claim after the token endpoint accepts space-delimited scopes. Review the referenced Spring Security issue and RFC 8693 section 4.2, then define optional behavior that preserves the current format while producing a space-delimited claim when enabled.