Just a few short months after Descope was founded, our product is in public beta and already has customers in production. The road to get here was filled with unexpected turns, and the road ahead looks markedly different than we thought it would look like (in a good way). All of this is because of the support provided by our design partners.
We are grateful to A-Team, Beluga Health, Cinch, Funda, FunnelStory, GradRight, and many other design partners for their constructive feedback and collaboration to help us take Descope from idea to implementation.
“Building in public” is one of our core guiding principles at Descope. Very early on, we decided as a team that:
We would prioritize customer learnings and feedback over all else, even if (especially if?) it challenged our existing assumptions.
We would document our product development thought process in public to the greatest extent possible.
In that spirit, this blog captures our learnings from over 100 customer interviews and several deployments of our authentication platform.
Every app is (slightly) different
Our mission is to help every developer add secure, frictionless authentication and user journeys for any application. While interviewing customers and selecting our early design partners, we wanted to cover the widest possible range of industries, use cases, and authentication requirements.
Our conversations ran the gamut from pre-launch startups to hyper growth companies. We spoke to builders from retail, FinTech, EdTech, HealthTech, freight management and shipping, cybersecurity, SaaS, hardware, and more. We sought out requirements that fell at different points of the complexity spectrum – from straightforward user login to multi-stakeholder authentication with different controls for different users.
We heard certain common themes from every app builder we spoke with:
They are eager to hand off at least some (if not all) of authentication and user management implementation to a trusted third party.
Their Holy Grail is to have authentication that is secure without negatively impacting the user experience.
Scalability and resilience of the authentication platform is critical – losing logins because of downtime or availability concerns is like losing business.
They do not like being constrained by limited implementation options (i.e. API-only or SDK-first).
However, we also learned that every application likes to do authentication slightly differently.
Cinch is a great example of having smart in-context authentication. Their freight spend management solution required authentication within an Outlook plugin, enabling their customers to seamlessly manage logistics workflows within their mail client.
Alon Cohen, Cinch CEO, said: "Descope is very customizable and easy to use. We seamlessly embedded authentication inside an Outlook plugin for our app, which was not possible with other authentication providers."
Uncovering B2B auth requirements
We have experience building authentication and user management in-house from our previous companies, so we thought we had a good initial idea of the requirements that B2B app developers would have. Our conversations took us in new directions pretty quickly!
We assumed that multi-tenancy was a foundational requirement for building a B2B app and our interviews confirmed this.
We did not envision Role-Based Access Control (RBAC) being as important for B2B apps at inception as it ended up being.
We had not planned for user provisioning (SCIM) in our initial product, but multiple B2B app builders disabused us of this notion.
A great example of a modern B2B organization is FunnelStory, a revenue intelligence offering for sales engineers. The FunnelStory team was building a SaaS product from the ground up and was aiming to have multi-tenancy and flexible RBAC from Day 1. They had implemented RBAC in the past and knew what a pain it could be. They are also a very design-conscious team and were seeking an authentication provider that offloaded implementation while still allowing them to retain control over the user experience.
Alok Shukla, Co-Founder and CEO of FunnelStory, said: “This is the fastest implementation of RBAC in a product I’ve ever seen. What took six months earlier to implement took just a month with Descope.”
System for Cross-domain Identity Management (SCIM) was the subject of many interesting customer conversations for us – conversations that went beyond just user provisioning. One design partner wanted to discover groups in their customers’ identity provider (IdP) so that they could set policies in their product. Implementing SCIM thoughtfully can be a real differentiator for B2B apps and give their customers a great in-product experience: for example, by auto-completing group names while setting policies.
In a nutshell, we learned that authentication and user management in the B2B world is very complicated. Builders either ignore some aspects of implementation (only to regret it later) or spend lots of time trying to figure out these stacks of protocols (delaying their core app development).
Our aim is to provide a third, better path.
Uncovering B2C auth requirements
For B2C apps, our initial set of requirements focused on providing app builders with a variety of authentication methods (e.g. social logins, OTP, biometrics, magic links) that they could in turn provide to their users. Several conversations later, we came away with valuable learnings around the benefits of going passwordless and the importance of device identities.
B2C apps feel the pain of passwords in the form of lost business, especially during checkout processes.
B2C apps feel the pain of passwords in the form of account takeover fraud and credential stuffing attacks.
B2C apps may also need role-based access control.
Speaking to retail and e-commerce companies bubbled up many interesting passwordless use cases. For instance, guest account creation during checkout is an effective way to increase conversions and revenue. If you just need a user’s email address or phone number (no password), it’s possible to create a guest account for them which provides them with a much better experience while also moving them down the app’s conversion funnel.
If we agree that passwords are a poor marker for a person’s identity, what’s a better alternative? Well, for B2C apps at least, the marker is the user’s device. We learned that device identity is important for B2C apps both from a security and a user journey perspective. Want to request a second factor if the user is signing in from a new device? Want to change the authentication method if a user is signing in from India vs the US? Want to enact step-up authentication if you find risky user signals? Tying user identity to their device goes a long way in making the aforementioned flows work.
Based on these learnings, we brought forward plenty of risk-based authentication capabilities in our roadmap (stay tuned for more details in the coming weeks).
Perhaps themost interesting thing we learned is the merging of worlds between B2C and B2B apps. Many apps serve a variety of stakeholders – some consumers and some businesses – and the authentication requirements change depending on the user.
Consider GradRight, a leading Ed-FinTech company based out of India that serves students, lenders, and university admins. Authentication can get tricky here as security needs and UX expectations are different across these personas. Having the ability to easily define (and later modify) user journeys for each type of user is vital.
Sasidhar Sista, Co-Founder of GradRight, said: “Descope has truly been ‘set it and forget it’ for authentication by making user journeys seamless and secure for all users that interact with our service.”
In a nutshell, going passwordless opens up a world of possibilities for B2C apps, enabling them to delight and convert more users while also implementing the right security controls at the right time.
Nothing sharpens ideas and breaks existing mental models like speaking with customers. Not everything we learned has found its way into the product yet. We also suspect that future conversations will lead to tweaks and evolutions that we haven’t even thought of yet. The only thing we know is that we’ll keep building in public.