Multi-factor authentication: to confirm a user by a second factor at log-on - usually a mobile app, but it can also be a confirmation email, a text message, etc. The problem with this is that it can often be the same factor, and invariably involves identifying information, such as an email address or a mobile number.
Mituyu works differently: it's based on randomly-generated data, and so doesn't contain any personal information. Mituyu itself has no way of knowing the user's identity. Further to that, the host site using Mituyu refers to the user by their own data, and so never sees the randomly-generated data mentioned above.
When you deal with Mituyu, you'll refer to your user as either a 32-character hexadecimal string (an un-formatted GUID, for instance, or the result of an MD5 hash), or a decimal value (which Mituyu will immediately perform an MD5 hash on). It's best if you obfuscate that information, either by sending a database id or, if you must send an email address, salt that hash!
Mituyu is based on challenges: to on-board a user, you'll call the API (server-side) with the user's key to generate a challenge id, that you'll then send to the Mituyu site plug-in. The plug-in will handle the rest, and steer your user through the process. The plug-in will return a boolean true/false to tell you whether the attempt was successful.
Authentication is an identical process - you'll call a different API endpoint (server-side) for a challenge id, which again you'll pass to the plug-in, which will handle the rest and return a boolean.
We of course shouldn't trust the browser, as it can be spoofed by bad actors - there's an API endpoint for actually validating whether the boolean result was actually true - ie whether the challenge was properly met.