back arrowBack to Blog

Company Updates

How Descope Uses Descope for Customer Authentication

How Descope Uses Descope thumbnail

We at Descope are avid believers in the “drink your own champagne” approach. This used to be called “Dogfooding”, but since we love our product so much and think it’s awesome, calling it “dog food” felt wrong. So here we are - drinking our own champagne,  using Descope everywhere we need authentication, and providing our end users a seamless and secure experience in the process. 

A big priority for us is making the sign-up and sign-in experiences as simple and frictionless as possible. You will never have to fill in 20-question forms or think of complex passwords to sign up for our service. I wrote about this in my previous blog on self-service onboarding, but we took it to the next level recently. In this blog, I want to share how we…

  • Prevented bot sign-up attempts

  • Verified user emails for OAuth sign-ups

  • Added adaptive MFA

  • Enforced SSO for enabled domains

…all without writing a single line of code. Let’s get started!

Bots… they are everywhere

Bots everywhere

We noticed many sign-up attempts were dropping during the OTP validation process in our Flow Analytics visualization. To put some perspective behind this - we saw that about 80% of sign-up attempts with OTP over email never even try to validate the OTP itself. To identify whether we had a problem or if those were just bots, we added the built-in bot detection mechanism to our Flow so we could classify whether the drop-off was due to end-user friction or bot sign-up prevention.

Descope Segment bot tracking
Fig: Tracking Flow visit analytics to determine routes that require optimizations

We need your email address!

Email validation meme

During the sign-up process, we also noticed that a few Descopers did not have an email on file. This can happen when you use some OAuth providers (Social Login) or even SAML / SSO

Since we used both the aforementioned auth methods, it created a situation where we could not connect with a customer that needed our help because we didn’t have their email. For example, when we saw high error rates on their projects or when we wanted to provide some guidance on configuration improvements.

Changing the Flow to include email verification took maybe 10 minutes, but it saved hours on a cross-system manual search to understand who the customer was and how to tell them they should fix some issues on their end. 

We simply added a condition to check if we had a verified email, and if not - asked for it and verified it. 

Descope email validation
Fig: If the email is not there (or not verified) - ask and use OTP to verify

MFA for the masses

Next, we turned our attention to our console sign-in experience. We have tens of thousands of developers signed up, and we are starting to see some pretty big companies building their authentication experiences with Descope. As bigger companies are regularly accessing our console, we wanted to increase the security and put some advanced controls to protect their data. 

Multi-factor authentication (MFA) is a good security control to add, but we didn’t want to impact the login experience every time the user logs in. We wanted to trigger an MFA only when we detected some kind of security anomaly - new IP address, new device, etc. We also knew that not every company wanted or needed this MFA implementation.

MFA too secure
We didn’t want this MFA…
...or this MFA

So, we implemented the adaptive MFA in our sign-in Flow, but only for those companies who asked for it. We added a custom attribute at the tenant level so companies could ask to opt-in to Adaptive MFA, and have the Flow active only for those that did. 

Changing the Flow was very cool - we added a check to see if adaptive MFA was on for the company of that user (tenant on our app); if it was, we checked if the user had a preferred MFA set up. 

Selecting the preferred MFA was implemented as a simple Flow Screen with a custom attribute at the user’s level. We gave three options - passkeys, TOTP, or SMS OTP, so every user could select what they were most comfortable with. Then, when we detected a new device or a sign-in attempt with increased risk- we triggered the MFA process to the preferred method. 

It’s THAT easy!

Descope Adaptive MFA
Fig: Adaptive MFA Flow implementation

If you want to enforce MFA in your Decope company - just drop us a note at and we’ll set you up in no time!

Enforcing SSO for companies

But wait theres more

The last piece was actually allowing companies to decide to lock their Descope account behind their SSO. This is a very common practice that allows the company to control which users can access their Descope environment. 

Setting up SSO in Descope is easy and can be done in a self-service manner. Once configured, we wanted to allow these companies to block other means of authentication to their users (social logins or Enchanted Links). 

With another tenant-level custom attribute, we enforced SSO as part of the sign-in Flow. If users tried to log in with Enchanted Link, but their tenant was configured with SSO, the Flow will enforce SSO and the user will be asked to sign in that way.

We wrote another blog on enforcing SSO for enabled domains that should be helpful.

Descope enforcing SSO
Fig: Enforcing SSO in the sign-in Flow


Flows are easy. Flows are fun. And as presented – Flows allowed us to improve the sign-up and sign-in experiences on our console without making any changes to our code base.

Drinking our own champagne
Drinking our own champagne

Sign up for a Free Forever Descope account to get started with your own Flow journey. Have other questions about our CIAM platform? Book time with our auth experts.