Docs: Web Apple Sign-In Example Uses Raw Nonce With AppleID.Auth.Init And SignInWithIdToken Causing Nonce Mismatch

The documentation example does not hash the nonce before passing it to AppleID.auth.init(). It passes the raw nonce to both Apple JS and Supabase. Apple JS embeds the nonce verbatim in the id_token, whereas GoTrue takes the nonce argument, hashes it with SHA-256, and compares that hash against the id_token nonce claim. Consequently the comparison becomes sha256(raw) === raw, which can never succeed.

1. Configure an Apple provider in Supabase with a Services ID and no OAuth secret for the JS SDK path. 2. Use the documented web JS example: generate a raw nonce with crypto.randomUUID(), pass it as the nonce to AppleID.auth.init(), then call supabase.auth.signInWithIdToken() with the same raw nonce. 3. Complete Apple sign-in. 4. Observe GoTrue returns an error with 'invalid nonce' and 'Nonces mismatch'.

This fix relies on window.crypto.subtle, which is available only in secure contexts (HTTPS or localhost). On insecure origins, use a fallback SHA-256 implementation such as js-sha256. Always generate a fresh nonce per sign-in attempt and do not reuse a hashed nonce. If a nonce has already been hashed for Apple, do not hash it again when passing to Supabase. This is a documentation-only fix; rolling back the docs code to the original raw-nonce example will reintroduce the nonce mismatch. The earlier web example that omits an init nonce may still work because GoTrue skips the nonce check when absent, but passing nonce there is misleading and should be aligned.