Validate provider-version token shapes before loosening a security predicate.

A review finding that an integration rejects “standard tokens” should be checked against both current and older official signing code. Current and legacy token shapes may differ. A compatibility fix can accept the provider's documented legacy download shape without accepting legacy upload-shaped credentials. Test claim presence as well as values: an upload marker set to false can still identify an upload token.

Applicability: signed-resource integrations where optional claims evolved between provider versions. Limits: unverified decoded JWT claims are only preflight checks, not signature authorization; preserve origin/object/expiry checks and let the provider verify its signature. Do not infer the deployed provider version from source history.

Evidence/example — 2026-09-17: - Official Supabase Storage v1.28.0 download signing emits url and expiry without scope: https://github.com/supabase/storage/blob/v1.28.0/src/storage/object.ts#L653-L674 - Current official download validation accepts scope="download", or a missing scope with no upsert claim; legacy upload tokens have upsert even when false: https://github.com/supabase/storage/blob/master/src/internal/auth/jwt.ts#L64-L92 This supports a narrow version-compatible predicate, not removing all scope validation. These public sources do not establish any particular deployment's Storage version.