Have you ever heard a developer say, “I’m so excited to build registration into my app, I can’t wait to create the user table and set up account recovery flows”?

Neither have I. Identity services aren’t core competencies of developers, and they aren’t something that developers get excited about—but they are necessary.

Convenience and ease of use are paramount for customers. In customer-facing applications, an inconvenient registration, login or password reset experience can cause them to abandon your app and never return. Even simple things like password policies can cause immensely frustrating experiences for customers.

As an example from my personal experience, I’m in an endless account recovery cycle with my airline. My normally very strong and acceptable password doesn't work with this airline due to strange nuances in their password policy. So each time I go to log in, which isn’t often, I have to reset my account and pick a different, even more obscure password that I’ve not used before. Every time I try to login from a new device—where my password isn’t saved—I get frustrated and consider abandoning my many mileage points to go elsewhere. This is one of the numerous simple oversights that can frustrate customers, many of whom are less forgiving and less savvy at password reset flows than I am.

When building an application, you want to make the process of embedding registration, login, account management and other identity functions into your app as simple as possible. Building them yourself is not the way to achieve that simplicity. Your developers need to be able to create customized login and registration screens, set up password reset flows, and set up other identity services without slowing down your application’s launch. At the same time, they can’t overlook a detail that could result in a frustrating user experience, or worse, result in a data breach.

Leveraging existing identity services can help you avoid all the pitfalls and forgo the countless hours it would take to build identity into your application from scratch.

API-driven IDaaS
API-driven identity-as-a-service (IDaaS) solutions allow developers to easily leverage identity services and let someone else take care of security and best practices behind the scenes. That means you don’t have to worry about your team having to build things like encryption for passwords and user data, registration and account recovery flows, a secure user repository and other identity-related capabilities.

In addition to ensuring better customer experiences, leveraging existing identity services can help you on the security front. If you choose to do identity yourself and store user data in a relational database, and then it gets hacked or goes down and disables logins during a peak load event, that could bring unwanted blame on your team. There are decades of best practices and lessons learned in every aspect of identity, and we highly recommend that your developers leave those nuances to the identity experts. Identity solutions are architected by those identity experts for scale, they have built-in registration and account recovery flows that are convenient for users, they enforce consent to comply with privacy regulations, and they can securely store user data. If these things aren’t your core competency, it’s a risk—and a very time-consuming one at that—for your developers to try and build them.

So what? There are plenty of identity solutions out there. Can’t you just pick one and be on your way?

Not quite. Several pitfalls can get you in trouble. If you’re developing a consumer-facing application for a large enterprise, you’ll have a lot to consider. If your app falls short of IT’s expectations, future initiatives that require integration into the rest of your application portfolio could end up making you have to unexpectedly re-architect your application’s identity services. If there aren’t consumer-friendly features, it could end up taking a toll on your customer experience and costing you users. If the APIs aren’t robust and easy to use, it could end up being difficult to get your identity services up and running, and slowing down your launch.

Your IDaaS Solution Checklist
The good news is IDaaS solutions are out there that are easy for developers to use, are agile enough for enterprise IT teams, and have all the features your consumers expect. Confirming that an IDaaS solution has all the capabilities below before you implement it can help ensure you check all the boxes:

Are there APIs, customizable UIs and developer self-service?
These capabilities are a must for developers. To make it easy to embed identity services, there have to be developer self-service capabilities. These ensure developers can get the IDaaS connected to their app themselves, without relying on other IT resources. Once your app is connected, the APIs have to be easy to use and intuitive, and provide robust functionality.

There may be situations where you don’t need to build custom views that leverage identity APIs. If that’s the case, you may prefer to leverage out-of-the-box UIs that can be customized to match your brand. This even more streamlined option should be available to your developers as well. In either case, APIs and UIs that leverage pre-built identity services such as registration, authentication, password reset flows and others are key to speeding your time to launch for new applications.




Is there social login and preference and profile management?
Consumers have become very picky about their interactions with brands. A simple oversight like not offering them the ability to login with Facebook, or their preferred social media provider, can cause them to abandon your app. Additionally, consumers expect, and are often required by privacy regulations, to be able to access and manage their own account data and preferences. Your team can also leverage these preferences to personalize the user experiences within your app. If you pick the right IDaaS solution, embedding these capabilities shouldn’t slow your developers down.



Can we avoid building our own user repository?
Building a user table, encrypting passwords, and ensuring it’s scalable and secure isn’t something you want to do. Not only is it time consuming, but it’s risky. A simple oversight can end up having your application be the cause of a customer data breach that costs your enterprise millions. But the main benefit you’ll likely recognize by not building your own user database is getting a user repository up and running faster, and making your developers’ lives easier. Once a cloud user repository is in place, it’s also important to be able to access, update and modify user data through developer-friendly APIs.



Does it have MFA built for consumers?
All the trendiest apps out there today are using multi-factor authentication (MFA). It’s often expected by security experts and consumers alike. If you want to put your best foot forward, you’ll need to leverage MFA in your app.

However, not all MFA is created equal. Many organizations are finding out the hard way that SMS and email for MFA aren’t secure. Unfortunately, Reddit learned this too late, and specifically mentioned it as a reason for their recent breach.

“We learned that SMS-based authentication is not nearly as secure as we would hope, and the main attack was via SMS intercept.”
~ u/KeyserSosa

If you’re building a mobile application, it’s much more secure for users if you embed MFA directly into your own application. It’s also more convenient. Think of the difference between the multi-step process of opening a separate app or email, copying a one-time password and pasting it back into a browser, versus just putting a thumbprint on a smartphone.

While it’s ideal to provide MFA through push notifications, it may not be possible for all consumers. Users should be able to choose the MFA method they prefer, even if some end up choosing SMS or email. An IDaaS solution should also offer consumer-specific MFA features, such as the ability approve high-value transactions, and include specific details about what the customer is approving in the SMS, email or push notification.



Can I host multiple environments under a single account?
You may also have the need to set up various environments for your applications. These could be dev, staging and production environments, or different sets of environments for different applications. Surprisingly, many IDaaS solutions for developers don’t allow this and require a different account for each new environment.

The ability to have multiple environments is obviously convenient for your developers, but it’s also important to IT. Once your app is integrated, it will allow IT to set up delegate administration with oversight limited to specific environments. That means you can control your environment and don’t have to worry about others, even if they’re leveraging the same identity solution across the enterprise.



Will it pass “the IT test”?
Building identity into your applications may have ramifications beyond your current application launch. At some point, an enterprise architect, identity and access management professional, or CISO will come knocking with an initiative to “unify identity profiles” or undergo “digital transformation.” These initiatives may mean plugging your app into a centralized identity infrastructure. If you picked the right IDaaS solution, the integration process will be easy and you won’t have to re-implement identity for your app. These initiatives also have benefits for developers, such as being able to leverage preferences and personalization data collected from any other application in your enterprise to build better user experiences in your application.

IT might have other specific requirements that you didn’t initially consider. They may need your IDaaS solution to act as an authentication authority and be able to handle any number of single sign-on (SSO) use cases across your enterprise. Or it might mean the identity solution needs to coexist in a hybrid IT environment and expand the unified profile to include on-premises apps.

If the identity solution you choose doesn’t check these boxes, it could mean security holes, poor user experiences or a tedious implementation into your app. Or it could just mean that you’ll be rebuilding it at a later date with a solution that IT chooses for you. In that case, how easy a solution is for developers to use may not be high on their priority list.

Evaluating these items before choosing an identity solution to implement into your application can ensure that you’ll get your app up and running quickly. It also means that you’ll get IT’s long-term buy-in and not have to re-implement an identity solution when it comes time to integrate your app in the larger enterprise application portfolio. But most importantly, it’ll make your application better, and the lives of your developers much easier.