Skip to main content

There is a shortcut

If you don't want to implement the tables and session management yourself in your own project but rather let a global relay server handle the heavy lifting for you, then integrating this fast authentication system is even easier (click here to learn how to do that).

How to onboard users?

In case you do want to handle the user management on your end, you do have that flexibilty as well! Onboarding users to ByteFast Auth is very straightforward and similar to setting up 2FA. Just easier:

Step 1​

Either add a public address or pubkey field to your user database table or create a new table that stores bytewallet user profiles. For example:

create_bf_fast_auth.sql
CREATE TABLE `bf_fast_auth` (
    `id` INT(10) NOT NULL AUTO_INCREMENT,
    `email` VARCHAR(150) NULL DEFAULT NULL ,
    `domain` VARCHAR(150) NULL DEFAULT NULL ,
    `pubkey` VARCHAR(150) NULL DEFAULT NULL ,
    `phone` VARCHAR(50) NULL DEFAULT NULL,
    PRIMARY KEY (`id`) USING BTREE,
    UNIQUE INDEX `email_domain_address` (`email`, `domain`, `pubkey`) USING BTREE,
    INDEX `phone` (`phone`) USING BTREE
)
ENGINE=InnoDB
AUTO_INCREMENT=1
;

Step 2​

On a user's account page offer a "ByteWallet Setup" section. In this section simply generate a QR code for a webhook that will receive the user's public key. ByteWallet will send you a fully digitally signed message that allows you to verify the sender's public address is indeed belonging to a private key the user owns. Create an authentication string/token on the spot and attach it to this QR code as in the previous webhook examples.

Step 3​

Once the user scan's this QR code on his account page, your webhook will receive a request, verify the signature checks out (to verify its not someone else's public key) and then take the authentication token and look it up in your user database. When you find the authentication token, replace it with the user's public address.

And that's it - you are all set!

At this point your user's original account is linked to his ByteWallet.

note

For bonus points, think of a sign up process in which you do not require a user's username and password or phone number - simply present a QR code, let the user scan it and capture the incoming webhook to store that very public key as the "username". From now on, your user will be identified by this public address which was deterministically derived from your DOMAIN name and the user's PRIVATE key - a clear way to identify the user on your service henceforth in a secure, futuristic and decentralized fashion.