[steffenbusch]

Summary

Fix meta_claims population for JWT claims that are decoded as []string, most notably the registered aud claim.

caddy-jwt currently stringifies array-like metadata only when the claim value is []interface{}. This works for many private claims, but it does not work for registered claims such as aud, because the underlying JWT library decodes them as []string.

As a result, configurations such as:

jwtauth {
    audience_whitelist "aud1"
    meta_claims "aud"
}

successfully validate the audience, but {http.auth.user.aud} remains empty.

Root Cause

The JWT library treats aud as a standard claim and decodes it into a dedicated string-list type, which is exposed to caddy-jwt as []string.

caddy-jwt currently supports:

• string
• bool
• json.Number
• time.Time
• []interface{}
• fmt.Stringer

but not []string.

This causes meta_claims "aud" to resolve to an empty string instead of a comma-separated value.

Changes

• Add []string support to stringify()
• Add a regression test proving that meta_claims "aud" is populated correctly
• Extend the existing stringify() unit test to cover []string

Example

Given a token containing:

{
  "aud": ["aud1", "aud2", "aud3"]
}

and this config:

jwtauth {
    meta_claims "aud"
}

the placeholder {http.auth.user.aud} now resolves to aud1,aud2,aud3.

Backward Compatibility

This is backward-compatible. It only adds support for an additional value type that was previously dropped during stringification.

[ggicci]

Thank you @steffenbusch for the contribution!