Error occurred while verifying params verifier auth0-based-jwt-service-1 not found for account id: "..."

I am using the tkey library on react-native. I am trying to create a sms passwordless, bring-your-own-jwt provider integration where we use fully native code to query a JWT and then make use of the torus network to store and retrieve a share gated by that JWT.

I am getting the following error when calling triggerLogin on the TorusServiceProvider: “Error occurred while verifying params verifier auth0-based-jwt-service-1 not found for account id: 5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY.”

This is a rather undecipherable error that is arising when sending “GetShareOrKeyAssign” RPC messages to the endpoints, where X is 1 through 5.

I am curious if the Web3Auth engineering team could please provide some insight into why we are receiving this message. I have confirmed that I have the titular verifier set up on our web3Auth dashboard, and that we are passing in the appropriate client IDs for Auth0 and Web3Auth into the triggerLogin call.

One curious thing I noticed while inspecting the execution path is that our clientId which we pass into triggerLogin does not seem to factor in at all to the payload eventually sent to the torus RPC endpoints.

As the titular error seems to indicate a mismatch between a specific verifier and a specific account, and I am sure the verifier id is correct, I thought perhaps somehow the RPC call was unaware of our specific web3auth instance. So I tracked the pathway of clientId from the top-level call to triggerLogin all the way down to the eventual RPC calls. This is what I found:

  • Passed into triggerLogin call on TorusServiceProvider from @tkey/service-provider-torus
  • Passed into triggerLogin call on CustomAuth object.
  • Passed into createHandler call.
  • Passed into constructor for MockLoginHandler
    • Passed into constructor for parent of MockLoginHandler, AbstractLoginHandler, where it does nothing.
    • Used to set the finalURL param on the MockLoginHandler.

In our particular code pathway, finalURL is never utilized. In the call to handleLoginWindow, we execute the else clause, since we are looking to do a no-modal, no-webview integration. Hence we just directly return the id_token, and the only thing which was aware of the clientId – the finalURL – is thus never actually used.

Thus the eventual calls to the RPC endpoints seem to be totally unaware of our clientId. Is this possibly the source of the error?

For reference, this is what our version of the handleLoginWindow call looks like, after the react-native oriented patch:

  handleLoginWindow(params: { locationReplaceOnRedirect?: boolean; popupFeatures?: string }): Promise<LoginWindowResponse> {
    const { id_token: idToken, access_token: accessToken } = this.jwtParams;
    // const verifierWindow = new PopupHandler({ url: this.finalURL, features: params.popupFeatures });
    if (this.uxMode === UX_MODE.REDIRECT) {
       throw error ("Redirect mode not supported to avoid web view")
    } else {
      return Promise.resolve({
        state: {},
    return null;

Relevant code:

import ThresholdKey from "@tkey/default"
import TorusServiceProvider from "@tkey/service-provider-torus"
import Config from "react-native-config"

let tKey: ThresholdKey

export const initialize = async () => {
  console.log("creating tkey with customauthargs", {
    baseUrl: "mango://",
    network: "testnet",
    uxMode: "popup",
  tKey = new ThresholdKey({
    customAuthArgs: {
      baseUrl: "mango://",
      network: "testnet",
      uxMode: "popup",

  await (tKey.serviceProvider as TorusServiceProvider).init({
    skipSw: true,
    skipPrefetch: true,

export const tKeyLogin = async ({ id_token }) => {
  console.log("web3auth client id", Config.WEB3AUTH_CLIENT_ID)
  console.log("auth0 client id", Config.AUTH0_CLIENT_ID)
  const response = await (tKey.serviceProvider as TorusServiceProvider).triggerLogin({
    typeOfLogin: "jwt",
    verifier: "auth0-based-jwt-service-1",
    clientId: Config.WEB3AUTH_CLIENT_ID,
    jwtParams: {
      domain: "",
      client_id: Config.AUTH0_CLIENT_ID,
      verifierIdField: "sub",

  console.log("tkey login response", response)

Please also note that the above code as written does not run on react-native. As the TorusServiceProvider library seems to be written exclusively for web, I had to patch a few things in the underlying libraries to avoid references to window or document objects. The code path that runs on triggerLogin runs clean through up to the RPC calls, and the values which relied on window and document are irrelevant to the codepath, so I don’t think that’s the issue.

  • SDK Version: @tkey/default": "^8.0.0-alpha.0
  • Verifier Details:
    • Verifier Name: auth0-based-jwt-service-1
    • JWKS Endpoint:
    • Sample idToken(JWT): eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6IjVLUDVyOHcwYzRRYndBV1dOQzdXdiJ9.eyJuaWNrbmFtZSI6IiIsIm5hbWUiOiIiLCJwaWN0dXJlIjoiaHR0cHM6Ly9jZG4uYXV0aDAuY29tL2F2YXRhcnMvZGVmYXVsdC5wbmciLCJ1cGRhdGVkX2F0IjoiMjAyMy0wMy0xMFQxMToyMTo0Ni40OTZaIiwiaXNzIjoiaHR0cHM6Ly9kZXYtbTJmc25mMDYyZXljYndwaS51cy5hdXRoMC5jb20vIiwiYXVkIjoieTdCOFpNUUdyNXJHUFF2VlZad2Z1ZVlxcEx0RFVaZGYiLCJpYXQiOjE2Nzg0NDczMDYsImV4cCI6MTY3ODQ4MzMwNiwic3ViIjoic21zfDY0MDA5NTM2OWU2ZGMzOGFmNjc5NzY0ZiJ9.Iu42j69tS6cP6Q5Zy-SVsM7WugCLG7VqVm0QmYYUSK7J5s3ewasuTdNp0jc6iACGskwo1gBCe15aL8QLkCV5csj94caaRmDSqPUnD7jCV2UD_QQVKi9VCxdXIr18a0GBab160eCO3ZLfLPYznxIe99baNNZLSJbNs4XVxuUlJajBfBBkU8aAyrGHf7WdCZyRY6I7UiUO2cLQRv_O-DA8x6oV03e2-_DoZTnpO97GbMevP2smtzIobYA_dZWuhQNMACJuHOpg8aWjuSSNR_pYIZeO00HwaSUhtzYeHCPiAgPgKxCJXCIxYIb6qDIoWCCLcc95gA_gTvGVuCs7DKYnjw

Also running into this issue - did you figure out the issue here?

Unfortunately I haven’t been able to get past this yet @chris. Are you also doing a sms password less flow or are you using a different auth method? If you’re on a different auth method, it may be interesting to compare notes. Perhaps in the commonalities and differences in our code pathways we might be able to find a clue

Different auth method: We are using Auth0 for emial-based login and passing the JWT directly to web3auth via the triggerLogin() function. Relevant code is below. Interestingly, we are getting the same account id in our error (5GrwvaEF5zXb26Fz9rcQpDWS57CtERHpNehXCPcNoHGKutQY)

const oidcLogin = async () => {
    if (!tKey) {
      console.log('tKey not initialized yet');
    // Initialization of Service Provider
    try {
      await (tKey.serviceProvider as any).init({ skipSw: true });
    } catch (error) {
    try {
      // Triggering Login using Service Provider
      const claims = await getIdTokenClaims();
      const idToken = claims?.__raw;
      const jwtParams = {
        id_token: idToken,
        verifierIdField: 'sub',
      const loginResponse = await (tKey.serviceProvider as any).triggerLogin({
        typeOfLogin: 'jwt',
        verifier: 'mural-auth0-tkey',
        clientId: AUTH0_CLIENT_ID
        jwtParams: jwtParams,
    } catch (error) {
      console.error('got an error when calling triggerLogin: ', error);

That’s a clue then, that we are getting the same account ID in our error message.

I’m curious if the code for these RPC methods is open source. It’d be really useful if we could read the code that’s triggering this error.

I think I found that is triggering our error. I tried to paste the GitHub URL directly but for some reason this forum doesn’t allow me to do so. To find the relevant line:

Go to torusresearch/torus-node on GitHub. Then navigate to dkgnode/jrpc_handlers.go, line 177. That’s the line throwing this error.

Investigating further now. Will update here if I’m able to make any meaningful progress.

Hi @faiyam - did some more digging here and it looks like this is an issue with the sapphire network that is used for validation on the tkey SDK version 8.0.0.alpha. If you pin your tkey version to non-alpha version (7.2.0 is the latest before 8.0.0.alpha), things should work as expected (it is now working for us).

Full context in a separate ticket I started here: Error occurred while verifying params verifier mural-auth0-tkey not found for account id

Hi @chris thanks for sharing. I just gave this a go and it worked!

1 Like