Learn how to use Web3Auth Server Side Verification inside a Next.js application.
Check out the guide here.
I am probably not understanding correctly. so far I see this:
- user logs in to w3Auth, and gets an answer back that includes the idToken and the wallet’s public key
- user sends a request containing the jwt token as header and the wallet’s public key as body
- server decodes the jwt token by using a public jwks endpoint, and compares the containing wallet public key with the body, and if it is correct then it’s secured…
Is that right? And if so, is it safe to assume that if an attacker finds out any jwt token they would win access to any user they have the wallet’s public key pretty simply?
- step one generate any jwt token with w3auth
- step two use jwt.io to find the information in the token
- step 3 send a request to the backend the with a token with any public wallet key in auth, and the same thing in the body…
Boom, that validates me as a the wallet user, and depending on the dapp I can do nasty things with that account now…
Isn’t this missing some kind of private_key in the server for verification purposes? Or am I missing osmething?
2 Likes
That is a really good question.
Please Web3Auth Team, could you reply to this and clarify?
I will not integrate a service that has such massive security question marks
Maybe the answer is, that only the private key can create the signature that contains and decrypt the public key? If this is the case, it should be fine.
As pointed by @kubisch
Web3Auth utilizes ES256 keys, which are based on the Elliptic Curve Digital Signature Algorithm (ECDSA) with the P-256 curve and SHA-256 hash function. This asymmetric algorithm depends on a pair of ECDSA private and public keys to generate and authenticate JWT signatures.
Generating a JWT requires access to the private key. In Web3Auth, the JWKS (JSON Web Key Set) endpoints expose the public key for verification purposes, ensuring that the private key remains confidential and undisclosed.