As I see the ask here is to get the metrics of each user on when they tried to login, what was their recent login and when the first login happened.
Unfortunately, we don’t store such information in our databases. Such information, ideally is not of any use to us since we just authenticate the id token to relay the information back to the frontend. The metadata can give you information about the share, like on which device it was created and when, however the information about the user interaction is not saved.
@yashovardhan I see - To clarify, in the question I asked about a stronger information than we actually needed . We don’t really need any granular metrics about our users (timestamp of first/last login), what we essentialy need is a reliable way to detect whether the key stored on the web3auth network for the given verifier has ever been by the user or not.
There is a legacyKeyLookup call to retrieve the public for given user, if it was ever initialized, which at first sight seems to be exactly what we need but the catch is that a key can in theory be initialized by anybody as no authentication is required for the GetPubKeyOrKeyAssign web3auth node RPC call.
A way out from this issue for us could be, if there was a way to get the information whether the user ever successfully authenticated against the web3auth network, which would allow us to weed out such “spam” keys which could have been initialized by anybody and could in theory be abused to break our app’s logic.
I guess the web3auth network already has to somehow track used idTokens for the user (to prevent replay attacks) so I guess there could indeed be a way to at least tell if given user ever provided a valid idToken to the network, or is there some limitation making even this (exposing a did_authenticate
true/false flag, or something similar) inherently impossible?
You can manually log those information in your database, since all the login triggers are directly going via your frontend.
We know, and of course, our problem is that we weren’t logging such data on our side so far (web3auth user identifiers/emails) and even if we started, we sadly didn’t find any reliable way to backfill this data for our existing users.