Our modern identity services are exposed through developer-friendly APIs, SDKs and Low-Code services to deliver the scale and performance required for any and all customer use cases.
Featured Blog Post:
It’s notoriously difficult to implement an account recovery process that prevents fraud without creating more friction for customers who are already locked out and frustrated. In a US consumer...
If your company is like most customer-facing businesses, you already have an identity provider (IdP) and an authentication process in place. Because of these incumbent identity assets, it’s easy to assume that integrating with BindID’s passwordless service won’t work for you.
Your IdP might even boast a “passwordless” option that’s supposedly quick and easy to set up. With an identity management framework like this already at work in your organization, BindID might appear to be redundant, costly and difficult (if not impossible) to integrate.
However, this couldn’t be farther from the truth. In this article, we’ll demonstrate how BindID can fit into any authentication environment to deliver 100% passwordless customer authentication, no matter what your current configuration may be. Let’s start by tackling the elephant in the room: the so-called “passwordless” offering from your incumbent IdP.
The harsh reality is that your existing IdP doesn’t have a totally passwordless architecture. In fact, virtually no service besides BindID does. To advertise a “passwordless” feature, most IdPs simply bolt a biometric UI onto their existing code. Instead of actually eliminating passwords, they use password “proxies” that are still connected to hidden knowledge-based authentication operating in the background.
With this bolt-on version of passwordless, the accounts in these systems can retain historical passwords. These passwords are often used as fallback measures, and they can easily be leaked and exploited. That means that data can still be hacked, stolen and abused — just like using passwords alone. All it achieves is fooling you (and your customers) into a false sense of security. We call this “convenience biometrics.” While it may allow you to skip typing in your password, that’s all you’re getting.
Here’s a challenge: if you want to test just how “passwordless” your incumbent IdP’s offering is, ask them what is required to recover an account. If a password rears its head at any part of the process, you know it’s not the genuine article. They may even try to hide this vulnerability. After all, easy and secure passwordless is in high demand. If legacy IdPs can’t convince you that they can keep up by offering it, they might lose your business.
More importantly, you should question how much it costs to turn this supposedly passwordless feature on. Most vendors charge by the feature, so it’s unlikely your organization will get it for free. The real question here is whether you’re willing to pay more for a feature that doesn’t actually deliver a passwordless result.
Lastly, turning a feature on isn’t always a simple process. Some IdPs may advertise passwordless options but neglect to tell you that there will be a lot of effort on your team’s part. Comparatively, BindID has been built from scratch with no passwords anywhere. It’s not a legacy, password based system with passwordless extension. BindID is also simpler to work with, especially when you’re tackling multiple integration points across a complex authentication pipeline. Why would you pay more, put in extra work and leave yourself vulnerable to password-based attacks just to tell your customers that you have a vague imitation of passwordless?
BindID never uses passwords. Period. Unlike most “passwordless” solutions, passwords simply don’t exist anywhere in BindID’s architecture — not during registration, not on the back end and not even during device recovery. Instead of passwords, BindID achieves one-step MFA using dedicated hardware already built into your customers’ devices. You get the maximum level of authentication security while adding minimal friction to the user journey.
Here’s the good news: you don’t have to kick your IdP to the curb to get started with BindID. We can work with any IdP with minimal configuration. BindID plugs into your authentication system wherever it’s most convenient for you.
BindID provides a range of integration options for every configuration. By using the OpenID Connect (OIDC) standard, we’ve made it easy to adapt BindID to plug passwordless into your existing authentication pipeline. With BindID, you can easily and seamlessly integrate by:
You don’t have to reinvent the wheel to get BindID up and running regardless of your existing framework or choice of IdP. BindID was built with a clear awareness of how authentication works in the real world, and we know it’s rarely a simple scenario. We understand that you’re not starting from scratch, which is why BindID adapts to your current authentication environment — not the other way around.
The reality is that many organizations use multiple IdPs already. This is a common structure that our developers are used to working with — in fact, they specialize in it. When we break siloed authentication components out and start using federated authentication services, it’s known as “decoupled authentication.”
BindID is designed to work within this decoupled environment. It can interoperate and coexist with many different IdPs. In short, it’s a System of Engagement — not a total replacement for your existing methodology. BindID does not build on your old stack, it augments it. It contains fewer moving parts, which means there is much less to configure and maintain. Of course, BindID doesn’t require an existing framework to build upon. If your organization wants to build everything from scratch with BindID, it’s just as streamlined and secure.
There’s only one solution that gives you total freedom from passwords: BindID. BindID gives you the most secure customer authentication possible. Customers crave its seamless logins and simplicity. Achieve inherent MFA in just one click or tap — no more passwords resets, frustrating lockouts or lengthy calls to a support center.
