Using Auth0 with Web3Auth

Learn how to use Web3Auth Plug and Play Core SDK with Auth0.

Check out the guide here.

1 Like

How did you like this post? Please share with us your comments or feedback on this thread!

The guide is well but web3auth does not provide the refresh token and expiry time. It is not possible to implement token rotation.

Hey @rafael.rodriguez

Did you check Refresh Tokens docs by Auth0?

The refresh token is encouraged with the back channel and is not returned in the browser context. The following steps can be taken to get refresh_token to get id_token.

  1. Create a new API or, in your existing API, enable offline access.

  2. Authenticate your user with oidc and offline_access in scope

    https://{auth0_tenant}.auth0.com/authorize?
        audience={api_audience}&
        scope=openid%20offline_access&
        response_type=code&
        client_id={applicatin_client_id}&
        redirect_uri={redirect_uri}&
        state={unique_text}
    
  3. The above code will return an access_code. Use that to make another call in your backend(back channel).

    curl --request POST \
      --url 'https://{auth0_tenant}.auth0.com/oauth/token' \
      --header 'content-type: application/x-www-form-urlencoded' \
      --data grant_type=authorization_code \
      --data 'client_id={application_client_id}' \
      --data 'client_secret={application_client_secret}' \
      --data 'code={acccess_code}' \
      --data 'redirect_uri={redirect_uri}'
    
  4. It will return,

    {
    "access_token":"bgivxiG...1Q",
    "refresh_token":"CRi......hQII",
    "id_token":"eyJhsInNpZCI...qXp_zp8Q",
    "scope":"openid offline_access",
    "expires_in":86400,
    "token_type":"Bearer"
    }
    
  5. Use this refresh_token to get id_token. (Back channel)

    curl --request POST \
      --url 'https://{auth0_tenant}.auth0.com/oauth/token' \
      --header 'content-type: application/x-www-form-urlencoded' \
      --data grant_type=refresh_token \
      --data 'client_id={application_client_id}' \
      --data 'client_secret={application_client_secret}' \
      --data 'refresh_token={refresh_token}' \
      --data 'redirect_uri={redirect_uri}'
    

Also, one other approach is Use Refresh Token Rotation, but it is only available with Auth0 SPA SDK.

My context is a react-native application, not a website. Flows are similar. I can get a refresh token in my auth0 /authorize call when I do it from an app, but if I use web3auth, the UserInfo object lacks this important part of the authorization information. In order to get the refresh token I have two options currently:

  • Either I do the auth0 /authorize call first, and use the idtoken to issue a web3auth call, or
  • I do the web3auth call first and then another /authorize call to auth0

Both options entail that the user has to go out of the app twice and be redirected again later, it is a double authentication that can pop up warning dialogs about being redirected to another site, a very bothersome UX.

I have two options currently:

  • Either I do the auth0 /authorize call first, and use the idtoken to issue a web3auth call, or
  • I do the web3auth call first and then another /authorize call to auth0

Option 1 will work, but option 2 will not. This is because Web3Auth is inherently calling the auth0 sdk for authorization and returning you the authorization token as well. Now if you’re making a new login with auth0 and getting a new authorization token, it will be conflicting for the state. It might work, but it is not ideal as the user has to go through two logins. However, with option 1, there will be two popups, but user interaction is needed only for the first login via auth0. Web3Auth popup will only be there for reconstructing key and no interaction will be needed.

with option 1, there will be two popups, but user interaction is needed only for the first login via auth0

Not in all cases. In iOS, the user must tap on a dialog for the app to be able to branch out and open the browser, so it requires one user interaction for auth0, and another one for web3auth. In Android, it depends on the device policy.

@rafael.rodriguez Makes sense. However, on your request, we have talked to the product team to additionally expose the OAuthRefreshToken. This will be done in the subsequent releases, very soon.

1 Like

Hey @shahbaz it looks like the oAuthAccessToken returned from a call to web3auth.getUserInfo() is malformed.

I’ve tested the returned value on jwt.io as well as on other decoders. For example, here is a returned value for oAuthAccessToken issued by Auth0.

eyJhbGciOiJkaXIiLCJlbmMiOiJBMjU2R0NNIiwiaXNzIjoiaHR0cHM6Ly9kZXYtMzd5dGd5dWYyaHY1YjByci51ay5hdXRoMC5jb20vIn0..ZcU-sW4PqMPmONsN.8XESikw-I0YU21EuFoN66mY6a-h0gb0UOJChqj7by-fY6K_avk-qlkS9rEvARVtfOsvV00kHn1vNk-kk-UBnG4bVViXWlqK416ZO_CmmhupCO3bkPuWnLgZNE6Fh9-20oBl06CviXODZZwRgrLVG7UL1Mx3WSNKbCDiwXKrgJEU2sb7lBmwkqtJjGdEkMb6m-DTWxazxGQ2hKpRAToYBvy3zgi0QEYIouCKUEnvZt99IEenjtlVu6YQ62ixZR-mOX0idEr_5hwKVC787dDmPXUSMQPgxQyBFU_qtlpIzBjMtoVA-qeXCFRgY4v5FcCqEeI8RMO9N3_5r5kgn5fg9gO98-f7_uiI.nqXvGoRae-KvAHPfZmCLdg

You can check and confirm that it is malformed. Pretty sure Auth0 is not issuing a malformed Access token. So I think there is something weird going on within the web3Auth platform that is truncating the Access token (see the two dots … in the middle of the token)

We need the Auth0 issued access token for auth related stuff on our app.

Could you please let us know if there could be a resolution? Thanks!

Hi @secureas,

the oAuthAccessToken isn’t in JWT format, which is expected. You can try decoding the oAuthIdToken instead.

Test it out with this example app: https://w3a.link/auth0-react-example

Sure I can, but oAuthIdToken is not meant to be used for authentication to APIs.

The oAuthAccessToken is the one that should be used for auth.

Is there a reason why oAuthAccessToken isn’t in JWT format?

Discussion moved to