mirror of
https://github.com/supabase/supabase.git
synced 2026-05-07 09:20:21 -04:00
Chris Chinchilla
ed123799ca
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified API key changes (new publishable/secret scheme, where to obtain each, legacy keys valid through end of 2026) and updated many getting-started tutorials with clearer setup, flow, and auth guidance. * **New Features** * Added/expanded profile photo/avatar upload and account integration steps across multiple tutorials. * **Guides** * Added guidance on auth helper methods and when to use them. * **Examples** * Example app updated to use token claims for auth state. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Katerina Skroumpelou <mandarini@users.noreply.github.com> Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
10 lines
1.7 KiB
Plaintext
10 lines
1.7 KiB
Plaintext
The Supabase Auth SDK contains three different functions for authenticating user access to applications:
|
|
|
|
### Summary of the methods
|
|
|
|
- Use [`getClaims`](/docs/reference/javascript/auth-getclaims) to protect pages and user data. It reads the access token from storage and verifies it. Locally via the [WebCrypto API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API) and a cached JWKS endpoint when the project uses asymmetric signing keys (the default for new projects), or by calling `getUser` solely to validate when symmetric keys are in use. The returned claims always come from decoding the JWT, not from a user lookup.
|
|
- [`getUser`](/docs/reference/javascript/auth-getuser) makes a network call to the project's Auth instance to get the user record, which includes the most up-to-date information about the user at the cost of a network call.
|
|
- [`getSession`](/docs/reference/javascript/auth-getsession) when you need the raw session (the access token, refresh token, and expiry). For example to forward the access token to another service. The session is loaded directly from local storage and isn't re-validated against the Auth server, so the embedded user object shouldn't be trusted on its own when storage is shared with the client (cookies, request headers). To verify identity, validate the access token with `getClaims`, or call `getUser` for a fresh, server-confirmed user record.
|
|
|
|
**In summary**: use `getClaims` to verify identity (typically for protecting pages and data), `getUser` when you need an up-to-date user record from the Auth server, and `getSession` when you need the access or refresh token directly, but don't rely on the user object it returns for authorization decisions.
|