Expected social ID-token issuer/JWKS on Sapphire Devnet (@web3auth/auth 11.8.2)

Embedded Wallets (Web3Auth)
1

We need version- and environment-specific clarification for validating an Embedded Wallet ID token.

Environment:

  • Sapphire Devnet
  • Auth connector invoked through a custom Google social connection
  • Default CONNECT_AND_SIGN mode
  • @web3auth/modal@11.4.0
  • @web3auth/no-modal@11.4.0
  • @web3auth/auth@11.8.2
  • @web3auth/ws-embed@6.1.0
  • @toruslabs/session-manager@5.6.0

After a new, owner-initiated Google redirect path returned to the app, getAuthTokenInfo() returned a non-empty compact JWS. A one-shot DEV-only structural check (not JWT signature verification) completed payload parsing and protected-header shape checks, then failed strict equality between payload.iss and the documented social issuer https://api-auth.web3auth.io.

We intentionally did not inspect or retain the token, claims, actual iss, kid, keys, raw errors, screenshots, logs, or network traces. Audience, time, key, and binding checks were not reached. The selected redirect path is owner-intent evidence only and does not independently prove the provider-reported login method.

Could you please confirm:

  1. What exact iss must a server require for this social profile on Sapphire Devnet with the package versions above?
  2. Does the documented social contract—issuer https://api-auth.web3auth.io, JWKS https://api-auth.web3auth.io/jwks, and aud equal to the Project Client ID—apply unchanged to ID tokens returned by getAuthTokenInfo() with @web3auth/auth@11.8.2?
  3. Can an AUTH/social session ever return the external-wallet/AuthJS token family here, or would an issuer mismatch indicate a backend/SDK issue?
  4. Is there a versioned server-side contract or release artifact for this tuple/environment, and what minimum non-sensitive diagnostics should be collected in a future controlled reproduction?
2

Hello,

For v11 social/AUTH tokens, don’t assume iss = https://api-auth.web3auth.io. A June 2026 MetaMask report reproduced v11 Google tokens with iss = "web3auth.io" and found their signing key at https://api.web3auth.io/citadel-service/.well-known/jwks.json. MetaMask acknowledged the issue, but the public thread does not provide a formal versioned contract. (https://www.google.com/s2/favicons?domain=https%3A%2F%2Fbuilder.metamask.io&sz=128)

  • Therefore, your iss mismatch does not by itself indicate an external-wallet/AuthJS token or an SDK failure. It is consistent with the known v11 social-token behavior.
    aud = Project Client ID remains the expected check. Continue enforcing signature, issuer, audience, expiry/iat, and application/session binding.
  • I would not accept both old and new issuers blindly. For your exact 11.8.2 + Sapphire Devnet tuple, treat web3auth.io + Citadel JWKS as the current observed v11 behavior, pending explicit MetaMask confirmation.
  • There does not appear to be a public, version-pinned server-verification artifact for exactly your package tuple/environment
    For a controlled reproduction, the minimum useful non-sensitive diagnostics are: package versions, network, connector/config, JWS alg + kid, iss, whether kid exists in the candidate JWKS, signature-verification result, aud pass/fail, and connectorName/auth connection. No token, PII, or wallet keys need to be retained

The strongest public evidence is the MetaMask Builder Hub v11 incident. V11 identity-token verification issue: V11 Identity Token (getAuthTokenInfo) is unverifiable — iss and JWKS don't match the docs

1 Like