Hi, I’ve run into an issue trying to use Flutter and Firebase together for Solana. I am getting the error "Error occurred while verifying params idtoken incorrect from sub params. The error can be reproduced using the flutter-firebase example in the web3auth-pnp-examples, and making the code changes shown here in this commit: Modifications to example to reproduce error · TadaimaTanuki/web3auth-pnp-examples@dd0c868 · GitHub
The only things I’ve changed is adding in the details from my verifier, and specifying the chain namespace as solana. Was hoping someone could take a look into why this error is occurring.
The problem was with the fact that when you switch to an aggregate provider from a single provider the web3auth instance needs to be instantiated with ‘subVeriferIdentifier’ which you think would throw an error at initialization, but instead was throwing the weird error that we got when calling login. We did not have such specified in our code and as to why the issue, and was resolved once added.
That’s good to hear @joe1. There are few tips I would like to share out which I found today while checking the codebase, and your setup. You are using the firebase setup of our firebase example, and your iss and aud are added for your firebase project which can cause issue in verifying the id token you are passing in the login function.
We usually use aggregate verifier when we want to use two different login verifiers, and still get the same address. For instance, if you are login with GitHub and Google login, both will have different addresses generated ideally. If you set up a aggregate verifier, you can use email, and get same addresses for both verifiers. If you are using sub as JWT verifier ID, it won’t be same for any verifier, hence aggregate verifier won’t generate same address.
If you are only planning to use Firebase email password authenticate, it would be ideal to setup Custom Provider instead Aggregate Multiple Providers. Hope this helps.
Well actually the intent was to use an aggregate provider moreso for future proofing. I intend to switch the JWT verifier ID back to email. But continue only using Firebase for now. If in the future our app scales or we need to change services, let’s say to AWS Cognito, then later on down the road we can add Cognito as a sub-verifier, migrate our users over to Cognito, and continue to use email verifier and at this future point, whether the user authenticates via Firebase or Cognito, they’ll still have their same wallet, even if the backend we start migrating users over.
So it was more for future proofing purposes, and that if we ever needed to port users to a different directory. Does that make sense and is that a valid use of web3auth aggregate provider?
Yes, that completely makes sense. If you are planning to add more verifiers and intent to get the same key, it’s best to go with aggregate verifier even if currently you are using Firebase.
