We have an aggregate verifier that is recognized in the dashboard but returns 403 Forbidden at runtime from the signer-service feature-access endpoint. Our standalone custom verifier on the same project works fine, so this looks like a project-level provisioning gap specific to the aggregate verifier path.
Apple Service ID `com.boithebear.web3auth.apple`: added `auth.web3auth.io` domain and `https://auth.web3auth.io/auth\` Return URL, while retaining legacy values
OAuth flow reaches the provider / callback, but wallet derivation fails on return
WalletLoginError: Failed to connect with wallet. Invalid auth connection.
bt: invalid argument 0: hex string has length 0,
want 40 for common.Address
```
Dashboard state:
`boi-aggregate-v3` is listed as Active
Its sub-verifiers are Active
The group shows 2 connections: google + custom
I do not see a self-serve “publish to project”, “link to client_id”, or “enable for sapphire_mainnet” control
Can you please confirm:
Does `boi-aggregate-v3` need a project-level provisioning step that we cannot self-serve from the dashboard?
If yes, can you provision it for this client ID?
If no, what configuration is missing?
Important safety note:
Please do NOT modify `boi-x-verifier` or any existing standalone verifier configuration. It is production-critical and wallet-derivation-sensitive. Any change there would shift MPC wallet addresses for ~1,300 active users. We only need help provisioning / diagnosing the new aggregate verifier path for `boi-aggregate-v3`.
Happy to provide screenshots or a recorded reproduction.
Thanks — I reviewed everything. This is an error report (not a feature exploration). Short answers:
Likely cause: Yes — a 403 from /signer-service/api/feature-access with flags (is_wallet_service, enable_gating, is_whitelabel) strongly indicates project-level feature gating. Aggregate/grouped verifiers often require backend provisioning even if they appear “Active” in the dashboard.
Provisioning: I can escalate this to our backend team to request enabling aggregate verifier support for your project. I will not touch boi-x-verifier (I understand it’s production-critical). If you want me to proceed, confirm and I’ll open the internal request to enable aggregate/grouped auth for Client ID: BM5YfL_9viY2F_4sX3a8uezX7Ky6Is_LdGR9osemzhGZcEZpNtkqX-8kNOuMl9lFGh3LQZ7kwQZdt6iULLCjJeE on network sapphire_mainnet.
Quick config checks to validate while I escalate (no action if you prefer we just provision):
All sub-verifiers use verifierIdField = email (especially Apple — email must be returned or decoded from ID token).
Apple JWT: aud, iss, JWKS and email extraction are correct.
SDK uses exact aggregate verifier name (boi-aggregate-v3) and web3authNetwork = sapphire_mainnet.
What I’ll include in the escalation: your client_id, network, product, domains, the console 403, and your note that standalone verifier boi-x-verifier must not be changed. If you want me to attach screenshots/logs or any additional wording, paste them now; otherwise confirm and I’ll open the provisioning request and loop in the backend. Someone from the team will follow up once they act.
Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.
Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours
Please do not modify boi-x-verifier or any existing standalone verifier configuration.
We will keep production rolled back to X-only until your backend team confirms provisioning is complete. After that, we can run a controlled smoke test and report results.
Hi, you can ignore the 403 error if you don’t use Wallet services.
As GET https://api.web3auth.io/signer-service/api/feature-access only checks if you have access to Wallet services or not.
I tested boithebear.com and still could login to your dapp which means the 403 error is not blocking users.
Important clarification: production is currently rolled back to X-only, so a successful login on boithebear.com only proves that the standalone X verifier still works. That path uses boi-x-verifier and is not the failing path.
The failing path only appears when NEXT_PUBLIC_MULTI_PROVIDER_LOGIN_ENABLED=true and the app calls the aggregate verifier boi-aggregate-v3 for Google/Apple.
When that path is enabled, after OAuth returns we get:
WalletLoginError: Invalid auth connection
empty wallet address
EthereumController updateAccount fails because address length is 0
So the issue is not just the visible 403 by itself. The aggregate login path fails to return a usable wallet/account.
Could you please test or inspect boi-aggregate-v3 specifically, not the production X-only login path?
When it failed to login with the new aggregate verifier boi-aggregate-v3, which login method did you use? google or apple? Does Auth0 returns email for apple login?
Yes, we will re-check our implementation against the Group Connections guide.
To clarify our setup:
We are not using Auth0 for this flow.
boi-aggregate-v3 is a Web3Auth Group Connection on sapphire_mainnet.
It contains only:
boi-google-social-v1
boi-apple-v3
boi-x-verifier is not part of the aggregate and must remain untouched.
The failure was reproduced on the Google path first. Google OAuth completes, returns to the app, then Web3Auth fails with:
WalletLoginError: Invalid auth connection
empty wallet address
EthereumController updateAccount fails because address length is 0
Apple was also configured, but our primary reproducible case is Google.
For Apple, the Service ID is com.boithebear.web3auth.apple and the Apple verifier is configured with Apple JWKS and email as the identifier. We are not relying on Auth0 to return the email.
Could you please confirm whether boi-aggregate-v3 is valid/provisioned for our client_id on sapphire_mainnet, or if there is a required dashboard/config field missing for aggregate group connections?
Important: please do not modify boi-x-verifier or any existing standalone verifier.
So the Google path appears to follow the documented group connection pattern, but it still returns Invalid auth connection / empty wallet address after OAuth returns.
Separately, we noticed Apple may need a different implementation if boi-apple-v3 is treated as a Custom JWT verifier rather than a built-in Apple social connection. We can adjust Apple separately if needed, but the primary blocker we need help with first is Google + boi-aggregate-v3.
Could you please verify whether this exact pair is valid and provisioned on sapphire_mainnet for our client_id?
Group: boi-aggregate-v3
Sub connection: boi-google-social-v1
Network: sapphire_mainnet
Important: please do not modify boi-x-verifier or any existing standalone verifier.
Just checking in on this because the Google + aggregate path is still blocking our rollout.
Could you please confirm whether this exact pair is valid and provisioned on sapphire_mainnet for our client_id?
Group: boi-aggregate-v3
Sub connection: boi-google-social-v1
Network: sapphire_mainnet
Our implementation matches the Group Connections guide for Google:
authConnection: google
authConnectionId: boi-google-social-v1
groupedAuthConnectionId: boi-aggregate-v3
The failure still happens after Google OAuth returns: Invalid auth connection / empty wallet address.
Important: please do not modify boi-x-verifier or any existing standalone verifier. We only need confirmation/provisioning guidance for boi-aggregate-v3 + boi-google-social-v1.
Hi,
I checked your verifier “boi-aggregate-v3” and it was deployed
Can you share screenshots or videos of the error?
Does your app have a testing env so that I can debug?
Can you try creating an aggregate verifier on sapphire_devnet first with Google sub verifier only and test if it works fine?
I’m not sure if Apple sub verifiers will return email of end users or not?
No X verifier is included. Production boi-x-verifier remains untouched.
Please confirm whether this devnet aggregate is provisioned correctly and whether we should test it with the same SDK params that fail on sapphire_mainnet.
Important safety note:
Please do not modify boi-x-verifier or any existing production standalone verifier configuration. boi-x-verifier is production-critical and wallet-derivation-sensitive for existing users.
Same SDK pattern:
authConnection = google
authConnectionId = boi-google-social-v1
groupedAuthConnectionId = boi-aggregate-v3
Could you please compare the working devnet setup against the mainnet setup and confirm what is missing or needs to be changed/provisioned on sapphire_mainnet?
Important: please do not modify boi-x-verifier or any existing standalone production verifier.
Hi,
I think the issue may come from the fact that you tried to aggregate apple login with google login. As the aggregated verifier on sapphire_devnet only has google login method and it works fine.