Lost your Logintap Account?
Just enter your email.
Sign up
First Name
Last Name
Company website
Business e-mail
Press this link to login into existing account or recover your password.

By submitting this form you agree to legal Terms and Privacy rules. Links for these could be found in footer of this website.

LoginTap is set up much like any other 0Auth service.

It needs some front and backend work on your site. Our goal is to make your life easy, so we provide ready made code for your front and back, not just API docs.

Note, that the code we provide for your side is open source and you are free to study it, or adjust any part of logic to better fit your needs.

1. Quick overview of steps to launch

1. Register with LoginTap.

2. Create a new website in LoginTap (4.1 below).

3. Create a call back URL on your website.

4. Create 2 new tables on your website and update your existing user table with 4 new fields (4.2 below)

5. Download & add our PHP library to your backend (PHP5, PHP7 or WordPress plugin - 4.2 below).

6. Add our JS widget to your frontend (1 line - 4.3.1 below).

7. Update your application's current "auth points" and logic, depending on your use case (next section - 2 ).

2. Ways to use Logintap (auth points)

You can choose various auth starting points to initiate the mobile 2FA, depending on your use case:

2.1 Cookie
2.2 Login & Button
Enter Login
Press for Mobile Auth
2.3 Full Auth, then 2FA
You Login
& Pass are Correct
Waiting for your Mobile Confirmation
Waiting for your Mobile Confirmation
User is recognised via cookie (or alike), when opening the website. No logins/passwords, all is done through mobile 2FA.

It is for maximum speed and convenience for your users.
User enters login/email, presses the Login button, and the rest is done via mobile 2FA.

As a sub case - user forgot a password, gets instant access from just the login.
User first passes full standard auth with login and password, then the mobile 2FA auto starts.

This way is about maximum security.
3. Standard use schemas
7. Browser opens the link
Mobile User
1. Let users login with your standard auth (login/pass or SSO)
3.1 Create & connect a new user to LoginTap
8. User taps a mobile messenger/channel
9. Confirms tie in a mobile messenger/channel
6. Call on JS Widget
to render QR for UUID
2. Check if your user has LoginTap's UUID
3. Request & receive a new user Logtinap UUID & messengers links
5. Check if "LoginTap channel is set" for user
11. Update user's record to "LoginTap channel is set"
4. Create new user Logintap UUID and messenger links for every request
10. Pair user with the selected mobile channel
Mobile User
1. Let users login with your standard auth (login/pass or SSO)
3.2 Using LoginTap as the MAIN factor for user auth
3. Check if user's "LoginTap channel is set"
10. Record confirmation or denial
6. Check user's channel and Push auth request to user's mobile
9. Receive auth response from a user's channel
1. A user opens your web site
7. Follow Push & unlock the phone
8. Confirm or deny entry in previously selected mobile messenger/channel
2. Recognise user via cookie, etc...
11. Allow or deny Entry
4. Notify user that mobile AUTH is in progress with a loader gif image
5. Request auth
3.3 Using LoginTap as the mobile 2nd factor
Just as 3.2 schema above, BUT you start the auth on Step-3, right after user's correct login action:

1. Let user pass any auth procedures you find important, for example ask for login/password (auth point 2.2 above), or just ask for an email for more convenience (auth point 2.3 above).

2. Initialize mobile auth request from Step-3 above. You can do it on a button press or automatically.
no -> "step 1 of new user"
4. Full step-by step instruction

The purpose of this instruction is to show an example of how to integrate mobile 2FA into your work flow. In fact you only have to fully comply with API calls and widget initiation. The rest - designs, DB tables, notifications and other can be done the way you need to.

This instruction assumes that you have already registered with Logintap. If not - press Sign Up and check your email.

4.1 Create a new website in Logintap

Press "Add New Site" button.

The Settings form will appear. In case you don't have all the needed data now, you can always access it later from a Menu button of each of your sites.

1. "Project/site name" is a name that is sometimes visible to your users, so name it properly.

2. Create a "call back url" on your website and enter it's address, for example - https://your-site.com/logintap/callback

3. "Display site name in messenger" means that Logintap will show user this "Site's name" during auth process. If you want to hide this information from whoever accidentally sees user's push notifications - uncheck it.

4. "Limit" on requests per minute is necessary to prevent spam, in case only email is used to start mobile auth and somebody gets a hold of that email and just tries to login again and again.

5. Application UUID ( appUUID) is an auto generated connector, which you will need at a latter step.

4.2 Prepare your backend

1. Download suitable library here - (PHP5, PHP7 or WordPress plugin) or from inside your Logintap account. It is open source and has just 4 API methods.

2. Deploy the library at your back and connect it to your CMS.

3. Add 2 new tables to your website's data base - lt_auth_sessions to store all user auth requests through Logintap and lt_settings to store connections to your Account.

Add Table 1 - lt_auth_sessions (start table name with LT for your convenience):
Note - ID and Login fields are your own internal fields, which you can use to identify record and user, who is using Logintap. You can name it anything you want.

Note- the "lt_" addition is only used to make it easy to identify fields working with API requests to LoginTap.

Add Table 2 - lt_settings (for your convenience start name with LT):

4. Fill in the above "lt_settings" table with the following Logintap account data, which will be used to receive API tokens through "getUserTokens" call:

- login is your email

- password is your account's password

- tenant is your alphanumeric 3rd level domain name, for example, a123abc-admin.logintap.com, where a123abc is your tenant name

- appuuid is located in Menu -> Settings of each one of your sites:

In case your access tokens expire or were not initially received, API calls will not work. You would need to run "getUserTokens" call from the PHP library to get new ones. The standard tokens expiration is set for 1 week, so please make sure to renew more often. Contact us if your case needs any other expiration time.

Add 4 new fields into your users table in your database:

Two of the fields above are filled by running "createObject" method from the PHP library. Response of it are two fields "objectuuid" and "shortlinks" for each of you users. Record the following response into corresponding fields of your user's table above:
            "type": "objects",
            "id": "1",
            "attributes": {
                "uuid": "dlb01ce9-d13a-4f5b-8k71-e3c1ffb58030",
                "shortlinks": {
                    "viber": "https://auth.logintap.com/5AnlT",
                    "facebook": "https://auth.logintap.com/9z3Ka",
                    "telegram": "https://auth.logintap.com/17LWo",
                    "vk": "https://auth.logintap.com/1kY07"
                } } 

Object's "UUID" is your user's ID within Logintap, it is alphanumeric, record it to "lt-objectuuid". We call it "object" to be different from your "user", to avoid confusion, which ID is used and when. The "shortlinks" field contains JSON array for mobile messenger connections, record it in full to "lt_shortlinks".

IMPORTANT: Two different strategies for "createObject" method:

(1) pre-create all objects for your users in advance, one by one, and allow any time period between object creation and user opt in to use mobile 2FA;
(2) create objects for you users, only when a user opts in for mobile 2FA.

First strategy cuts a bit of time for each user during 2FA setup process. Second is a simpler and continuous flow process. We don't charge for just storing idle objects, so the choice is yours.

The other two lines of the above table you fill when user actually connects a messenger. Place a listener/handler at the CallBack URL address you have chosen in setting for the website. It must recieve POST requests. It will recieve two kinds of POST messages from Logintap:

First, a POST response when your new user actually connects a messenger for Logintap auth. Identify for which user/object you just got a call back and add that into "lt_channel" and "lt_channelstate" fields of your user table:

ObjectUUID is for ID purposes, you already have it from "createObject" method. ChannelState as "1" indicates that a messenger is set and valid. "Channel" itself is just a name for your own stats, to see who is using which messenger.

Also use this data to show users reminders about a need to connect their second factor auth to improve safety or ease or both. For example, if "channel" is not 1, show a pop up offering a security of 2FA.

Second, a POST response to callback URL after each of "loginRequest" API calls. You make these calls to auth every login of every user to your website. Record data from this POST to your "lt_auth_sessions" table:

IMPORTANT - ONLY "LOGIN STATE" NEEDS RECORDING from this callback. Because at the moment when you receive this callback, you should have already recorded sessionUUID, objectUUID and tokenUUID from "loginRequest" method (see 4.3.3 below) and be just waiting for "loginState" response (1 = user confirms the login, 0 = does not).

So, when you get this call back - COMPARE all 3 pre-recorded UUIDs with the ones in this callback, to make sure the request has not been tampered with. If all matches, record the received 1 (yes) or 0 (no) "loginState" into "lt_logintstate" of the "lt_auth_sessions" table. An example of how to make a comparison:
$id = $pdb->exist([
                'lt_sessionuuid' => $_POST['sessionUUID'],
                'lt_objectuuid' => $_POST['objectUUID'],
                'lt_tokenuuid' => $_POST['tokenUUID'],
            ], $table)['id'];

All UUIDs matching and a "1" for loginState means auth is good and you can allow the user to enter.

4.3 Prepare your frontend

1. Place the following JS code into <head> sections of pages on which users will be offered to connect the mobile 2FA.
<script src="https://docs.logintap.com/mbst-qrw.js"></script>

2. Create a mechanism by which you will NOTIFY & ASK users to connect a mobile second factor auth. You can use a timer with a pop up, or it can be a button. For example, this is how it is done in your own Logintap account:

In this case a button press uses the following to call upon a JS widget:
var {meta: {shortlinks}} = await http.get('/logintap', {});
const messengers = shortlinks;
const QRW = window.MBST.qrw;

Pass here the "shortlink" and "uuid", which you got with "createObject" API method and saved to your users table into fields "lt_shortlink" and "lt_objectuuid".

AGAIN NOTE (as in 4.2.5) - when to run "createObject" API method is entirely up to you. You can sync all of your users upon launching Logintap, or you can quickly run it when a user starts connecting the 2FA procedure.

3. Customize your standard login form according to how you want to Logintap (refer to section 2 - Auth Points above, with examples 2.1, 2.2 and 2.3). Below is an example of how Logintap uses it's own auth:

In this case when a user presses "Logintap" button, we perform "loginRequest" API call. It is up to you to decide how you recognise your users, we do it with email (again refer to section 2 - Auth Points).

Logitap service responds to "loginRequest" with new "sessionUUID" and "tokenUUID". You create a new record in your "lt_auth_sessions" table with it and ADD the current objectUUID, as well.

4. Inform user with text and Logintap's loader graphic element that mobile auth is in progress. Wait till user reacts in a messenger with YES or NO. You will get a POST to your call back described in 4.2 Prepare you backend, paragraph 6, point 2.

Awaiting mobile auth

5. Now, COMPARE these records, as described here, with the data you get on the call back url, to make sure it has not been compromised. If all is identical and the "loginState" came back as 1 - let the user in, otherwise show any kind of "no entry" message.