feat: add support for JWT from AWS Cognito by allowing bearer_jwt_all…

[vmignot]

Description

This PR introduces support for M2M (Machine-to-Machine) access tokens generated by AWS Cognito, which natively omit the aud (audience) claim and use the client_id claim instead.
https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/cognito-validation.html

The Issue

When using the client_credentials flow with AWS Cognito, the returned access_token does not contain an aud claim. Because of this, the plugin currently blocks these valid tokens:

1. verifyIDTokenCommon strictly expects len(idToken.Audience) == 1 and fails immediately on Cognito tokens (which have 0 audience).
2. authBearerToken only checks the aud claim against BearerJWTAllowedAuds, causing a 401 Unauthorized even if the client_id is authorized.

The Fix

To support these tokens without compromising existing security, this PR introduces the following changes:

1. Relaxed Audience Check: Updated verifyIDTokenCommon to allow 0 or 1 audience, rejecting only tokens with multiple audiences. This prevents aggressively blocking Cognito M2M tokens.
2. Fallback to client_id: In authBearerToken, claims are now extracted earlier. If the audience check fails, it falls back to checking the client_id claim against the BearerJWTAllowedAuds list.
3. Wildcard Support: Added support for the "*" wildcard in BearerJWTAllowedAuds to allow any valid token cryptographically signed by the IdP. This is particularly useful when AuthZ routing is delegated to other Kong plugins (e.g., Kong ACL plugin) based on scopes.
4. Space-separated Scopes Parsing: When the configured groups_claim (e.g., scope) is returned as a single space-separated string (standard OAuth2 behavior for scopes), setServiceDataGroups now splits the string by space instead of evaluating the entire string as a single group. This prevents the regex validator from improperly rejecting standard scope strings containing spaces.

Testing

• Added TestBearerJWTWildcardAudience in main_test.go to ensure the wildcard and relaxed audience checks work as intended.

[sonarqubecloud]

Quality Gate failed

Failed conditions
45.0% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

[hanlaur]

Hello and thanks for the proposal. The current Bearer JWT validation logic is targeted towards ID tokens (although access tokens of some IDPs may work as well if they are JWTs and contain ID token claims). At least currently my thinking is that I do not want to extend scope of this plugin towards more general purpose JWT/access token processing.