🤖 I have created a release *beep* *boop*
---


##
[2.71.0](v2.70.0...v2.71.0)
(2025-07-10)


### Features

* fallback to `getUser()` if the `kid` of the JWT is not found
([#1080](#1080))
([9721f60](9721f60))
* introduce experimental split user and session storage
([#1023](#1023))
([e7b2f21](e7b2f21))
* make `getClaims()` non experimental, add global cache
([#1078](#1078))
([ffe13d7](ffe13d7))
* remove solana dependency by inlining types
([#1079](#1079))
([7665f94](7665f94))


### Bug Fixes

* handle null current session with split session storage
([#1071](#1071))
([bc6192a](bc6192a))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

🤖 I have created a release *beep* *boop*
---


##
[2.71.0](supabase/auth-js@v2.70.0...v2.71.0)
(2025-07-10)


### Features

* fallback to `getUser()` if the `kid` of the JWT is not found
([#1080](supabase/auth-js#1080))
([9867cd1](supabase/auth-js@9867cd1))
* introduce experimental split user and session storage
([#1023](supabase/auth-js#1023))
([b3ea493](supabase/auth-js@b3ea493))
* make `getClaims()` non experimental, add global cache
([#1078](supabase/auth-js#1078))
([ce77cbf](supabase/auth-js@ce77cbf))
* remove solana dependency by inlining types
([#1079](supabase/auth-js#1079))
([9824c9b](supabase/auth-js@9824c9b))


### Bug Fixes

* handle null current session with split session storage
([#1071](supabase/auth-js#1071))
([69aca6f](supabase/auth-js@69aca6f))

---
This PR was generated with [Release
Please](https://github.com/googleapis/release-please). See
[documentation](https://github.com/googleapis/release-please#release-please).

Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Updates getClaims() documentation and comments to clarify that the
method always uses server-side verification via getUser(). This approach
gracefully handles edge cases such as:

- Key rotation scenarios where JWKS cache might not have the new signing key
- Symmetric JWTs (HS256) that require server-side verification
- Revoked or invalidated tokens that are still unexpired

This aligns the implementation intent with the auth-js behavior where
getClaims() falls back to getUser() when the signing key is not found
in JWKS or when client-side verification is not available.

The Flutter implementation uses this server-side verification approach
for all JWT types, providing robust and consistent validation regardless
of the signing algorithm.

Related: supabase/auth-js#1080

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>