Using Logintap Open ID (SSO)

LoginTap can work as an 0Auth2 based OpenID Connect Single Sign-On service provider.

It needs almost zero work on your side, IF - you have OpenID Connect already available in your system.
1. Steps to launch

1. Register with LoginTap.

2. Create a new Project in LoginTap

3. Enable OpenID for the project

4. Copy/paste tokens into your system's backend


2. Auth points to use Logintap OpenID (SSO)

These are various use examples, however, you might not have any control over how your CMS is using the OpenID Connect protocol. So you may just skip this section.

2.1 No Login, No Pass
2.2 No Password
Enter Login
Press for Mobile Auth
2.3 Second Factor Auth
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 application. No logins/passwords, all is done through mobile 2FA. The same works for business process auth type cases.

Best for maximum convenience for your users.
User enters login only, presses the Login button, and the rest is done via mobile 2FA.

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

Best for pure 2 factor auth with maximum security.
3. Important Notes

1. Logintap Service can be Anonymous!

Logintap works with or without the email from a user. So it can be 100% anonymous, where we have zero info on your users.

OpenID only substitutes login and password, so your OpenID integration must be done right to specifications - after it receives a new user it must enrich other required fields, such as phone numbers, names, etc.

2. Logintap's OpenID Works for Your Existing Users!

Logintap's anonymity provides not only security but also a great advantage - YOU CAN USE LOGINTAP OPENID AUTH FOR ALL EXISTING USERS, not just to register new ones. In this case, you keep all current user data like existing emails and names, as our system will not return this data from any user.

Your OpenID protocol integration MUST BE DONE RIGHT. Your system must use not only an "email" but also the user's "session ID" as one of the parameters when "gluing" a user data received by a standard OpenID response.

As an example - if your user is registered in your system as "", and then switches to Google's OpenID using this same email account, your system will "glue" the old registered user to the new authentication choice and update the old user's data fields. If the user chooses a new Google account, say "" your system MUST still be able to recognize the user and "glue" with new authentication credentials (with or without re-writting an email address)

4. Step-by step instruction

VERY IMPORTANT! The work of OpenID can differ between various CMS systems. Logintap only works just as the integration with this protocol is made by your developers. Please refer to your CMS for various setup ways.

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

1. Press "Create New Project" button:

2. The Settings form will appear. You can always access it later by clicking each of your projects:

1. Set the project to work as OpenID Connect Provider, note that is sometimes visible to your users, so name it properly.

2. Brand this project - the name and your logo (PNG of at least 512x512) are visible to your users in several places, so name it properly.

3. Select auth mode for this project - our standard choice on how to verify users identities

4. Click both buttons - this will generate OpenID tokens:

3. Copy these tokens and paste into your system:

Click icons at the marked block on you right to copy data into the buffer.

Note that you can RE-GENERATE or EDIT the API TOKEN field, which is sometimes needed for security reasons, or when your system requires generating this token by itself, as for example, AWS does.

4. Press Save:

5. Other options you see in OpenID's authentication mode:

The two check boxes marked above do the following:

- Display project's name during messaging hides or shows the name in text messages sent to user's mobiles with authentication requests. So if someone gets ahold of the user's phone they will not know where did this user authenticated to.

- Email confirmation is required for some systems that are not able to function without OpenID protocol returning the email address, not just authentication results. Refer to your system's docs or email us at if you are unsure how your system works and we will try to help.

That is it.
The rest of the setup depends on your CMS. Please refer to tech docs of your system for instructions.