Apple provider: nonce verification always fails ("Nonces mismatch") — hex vs base64url encoding

[qocotomi]

Summary

When using the id_token grant for Sign in with Apple (native iOS) with signInWithIdToken({ provider: 'apple', token, nonce }), GoTrue returns "Nonces mismatch" even when the client sends the correct raw nonce. The cause is an encoding mismatch in nonce verification: GoTrue compares a hex-encoded hash to Apple's base64url-encoded hash.

Environment

• Flow: Native Sign in with Apple → Apple returns ID token (JWT) → client sends id_token + raw nonce to POST /token?grant_type=id_token.
• Provider: Apple.
• GoTrue: Hosted Supabase Auth (and/or self-hosted from supabase/auth).
• Error: invalid nonce / Nonces mismatch from the id_token grant.

Root cause

In internal/api/token_oidc.go, nonce verification does:

hash := fmt.Sprintf("%x", sha256.Sum256([]byte(params.Nonce)))
if hash != idToken.Nonce {
  return apierrors.NewOAuthError("invalid nonce", "Nonces mismatch")
}

• GoTrue: hash is the SHA-256 of the request nonce, encoded as lowercase hex (64 characters).
• Apple ID token: The nonce claim is the SHA-256 of the nonce, encoded as base64url without padding (43 characters), per Apple OIDC and common OIDC practice.

So the comparison is hex string vs base64url string and can never succeed.

Expected behavior

For the Apple provider, nonce verification should compare like-for-like:

1. Compute nonce_hash = SHA-256(params.Nonce).
2. Encode nonce_hash as base64url (no padding) to match Apple’s nonce claim.
3. Compare base64url(nonce_hash) to idToken.Nonce.

Proposed fix (conceptual)

Use base64url for the computed hash when the provider is Apple, and keep existing behavior for other providers:

// In token_oidc.go, where nonce is verified:
sum := sha256.Sum256([]byte(params.Nonce))
var computedNonce string
if providerType == "apple" {
  // Apple's ID token nonce claim is base64url (no padding) per OIDC
  computedNonce = base64.RawURLEncoding.EncodeToString(sum[:])
} else {
  computedNonce = fmt.Sprintf("%x", sum)
}
if computedNonce != idToken.Nonce {
  return apierrors.NewOAuthError("invalid nonce", "Nonces mismatch")
}

(Exact branch and provider detection to match your codebase; other providers may need to stay hex or be normalized per their spec.)

Minimal repro

1. Native iOS app: Sign in with Apple → obtain id_token (JWT) and the raw nonce that was hashed and sent to Apple.
2. POST /auth/v1/token with grant_type=id_token, provider=apple, id_token=<jwt>, nonce=<raw_nonce>.
3. Result: 400 with "Nonces mismatch" even though the raw nonce is correct and the token’s nonce claim is base64url(SHA256(raw_nonce)).

References

• Apple: Sign in with Apple REST API — identity token includes nonce as hashed value.
• OIDC / JWT: nonce in ID token is typically base64url-encoded hash when sent as hash to the provider.
• Existing issue about nonce/encoding: e.g. #1829 (Google); same class of issue for Apple.

---

Suggested next steps: Implement provider-specific nonce encoding (base64url for Apple) in the id_token grant so native Sign in with Apple works without disabling nonce verification.

[nathanschram]

I think you've traced this correctly - line 302 in token_oidc.go looks like the culprit:

hash := fmt.Sprintf("%x", sha256.Sum256([]byte(params.Nonce)))

This always produces a hex-encoded SHA256 hash (64 chars) and compares it directly against idToken.Nonce with no provider-specific handling at all.

This looks like a broader issue than just Apple too. I found two other open issues hitting the same line:

• Incorrect nonce check for google - sign in with id token #1829 - Google passes the raw nonce through unhashed, so the hex comparison always fails
• I get Nonces mismatch error for Azure provider when using supabase.auth.signInWithIdToken() #1926 - Azure does the same thing

From what I can tell, GoTrue assumes every provider puts hex(SHA256(nonce)) in the nonce claim, but the OIDC spec (section 3.1.2.1) says the nonce value is passed through unmodified from the auth request to the ID token. What actually ends up in the claim depends on what the client sends to the provider and how the provider handles it.

For now, there's a workaround via PR #1264 - you can set GOTRUE_APPLE_SKIP_NONCE_CHECK=true to bypass the check entirely. Not ideal since it removes replay protection, but it unblocks the flow.

I think your proposed fix is in the right direction - it might be worth considering that Google (#1829) and Azure (#1926) seem to have the same issue, so ideally the comparison would try multiple encodings (hex, base64url, raw) rather than branching per provider.

Let me know if the skip flag gets you unblocked in the meantime.

[nathanschram]

Hey, just checking if the SKIP_NONCE_CHECK workaround got Apple Sign-In working for you? Happy to dig deeper if you're still hitting the nonce mismatch.