Frequently Asked Questions

LogonLabs is an identity broker service exposed via REST API that standardizes how your website or application integrates with IDPs. Traditionally, writing custom code to support each identity provider could get messy because of the differences between them.

No. LogonLabs will direct your users to the selected identity provider and then direct the login result back to your application. LogonLabs never has access to your user’s credentials.

LogonLabs will simplify your ongoing maintenance, improve security, and give you access to more auditing tools. Adding the code to your registration and login screen only takes a few minutes. When you wish to allow your users to register and log in with more than the traditional email address and password, you will be able to turn on any IDP (identity provider), such as Google, Microsoft, and a host of others, with a single click.

Great! You have already made the visual adjustments to your login screen to include Google as an option to register and log in. Replacing this custom implementation with LogonLabs will only take a few minutes and your users won’t notice a thing. As the SAML and OAuth protocols evolve, LogonLabs will automatically handle changes in the IDP protocols and workflows without requiring code changes on your part. You also gain access to a dashboard where you can audit the number and locations of logins and control access with filters of your choosing.

No. LogonLabs is a universal API that is designed to integrate directly into your existing registration and login workflows.

No. LogonLabs is not an Identity Provider like Google or Okta. Your users will register and log in with the identity providers (IDPs) you make available to them, under your own brand name. While LogonLabs helps with the wiring and security, it is not a universal ID. Instead, we help you wire up the connection to your third party SSO provider, also referred to as an IDP, and allow you to quickly deploy and maintain them within your apps and websites.

Okta deployments are specific to each of your customers. It is typically configured per enterprise and vary from one deployment to the next. Using LogonLabs’ predictive user login workflow, you can configure certain domains to automatically redirect to your specific customer’s Okta login pages. To accomplish this, you must design your login screen to first ask for the user’s email address. LogonLabs will then check the rules associated with this domain, and presents the proper IDP, in this case, Okta, or others.

No. You will continue to manage your existing database of users. If a user selects to register with an IDP (such as Google), the LogonLabs API will return Google’s unique identifier for that user, as well as the user’s email address, first name, and last name. You can save this information in your database, just as if the user had used the traditional registration screen.

LogonLabs is a universal API that works with any programming language. We provide a list of examples in JavaScript, PHP, Java, Python, NodeJS, and .NET, just to name a few, to help you integrate into your apps, however, the API is not limited to these languages.

It’s up to you. While some features require we know about your user’s activity, you can elect to opt-out of these features.

LogonLabs can be deployed on Azure, Amazon or Google platforms, in different jurisdictions. Please select the appropriate platform and jurisdiction when you first set up your LogonLabs app. Self-hosting is available for enterprise customers; please contact us for more details.

If a user selects to register with an IDP, like Google, you can still have other fields in your registration form to ask additional information, such as the desired product, package, referral code, etc. The LogonLabs API will return with the first name and last name of the user as returned by the IDP. In the same post back, you can also register the user in your database, and record all additional fields in your database.

No. The LogonLabs API will never return a user’s password from an IDP, it does not have access to it. Instead, it will return a unique identifier for the user in the IDP (ie: Google, Microsoft, etc.), along with the user’s first and last name and email address. The password field in your database will remain empty. This increases your security by not handling users passwords.