# Announcing our seed round
Source: https://stytch.com/blog/announcing-our-seed-round/

Announcing our seed round, a $6 million seed round led by Benchmark in the summer of 2020. 

We started Stytch to build the future of user infrastructure, starting with authentication, and we’re thrilled to share a milestone on that journey.

We raised a $6 million seed round led by Benchmark in the summer of 2020. We’re excited to be working with Chetan Puttagunta, who’s joined our Board of Directors. Index Ventures participated in the round, along with angels including William Hockey, Dylan Field, Mahmoud Abdelkader, Elad Gil, Amber Feng, Lenny Rachitsky, and Jeff Morris Jr.

Authentication is a frustrating experience for both developers and users, and we're changing that. While working together at Plaid, we witnessed the security and user experience shortcomings of password-based authentication. To solve this, Stytch is building the developer platform for authentication to enable teams to easily build experiences that delight their users.

We’re thankful for our team, early adopters, and investors for the help and support on the journey so far. There’s much more to come, and if you’re interested in being a part of it, we’re hiring! If you’re interested in building on Stytch, join the many developers and enterprises that are part of our early access program and sign up here.

Julianna and Reed

---


# The rise of cool APIs
Source: https://stytch.com/blog/the-rise-of-cool-apis/

The surge of recent startups in the space, it’s clear that tomorrow’s tech companies will be powered by external APIs.

API startups are hot. With the rise of Twilio, the near-acquisition of Plaid, and the surge of recent startups in the space, it’s clear that tomorrow’s tech companies will be powered by external APIs, each responsible for outsourcing a different piece of infrastructure.

In this piece, Gil Feig (Co-Founder atMerge) and Julianna Lamb (Co-Founder atStytch) discuss some of the most important trends seen across rising players in the API space.

Innovation is rampant as API startups emerge at growing rates. Quality has soared across documentation, implementation, design, visibility, insights, and more. But APIs, like web applications, have a frontend. This may come in the form of JSON or XML, but it’s a view that is consumed by a paying customer. It wasn’t until recently that trailblazers like Stripe took this front-end seriously, and made APIs cool. But what exactly is a cool API?

A cool API is built with the user in mind. Data structures, endpoints, and documentation are all designed with the same rigorous attention typically directed towards the slick-looking landing page that first draws in customers. The cool API knows it's not just selling to product managers who desire time and cost savings, but also to engineers who are increasingly responsible for vendor decisions and, obviously, implementation. And while companies may rise and fall, both PMs and engineers have the option of introducing your product to their future employers— or not. We believe a critical factor in an APIs longevity is, then, its coolness. Think of it like making that all important first-impression at a party.

Merge is a leading provider of Human Resource (HRIS), Payroll and Recruiting (ATS) integrations for B2B companies. Companies that integrate once with Merge’s API automatically offer integrations with 30+ platforms to their customers. Stytch makes it simple to seamlessly onboard, authenticate, and engage your users with passwordless authentication and user management APIs and SDKs.

Despite evolving separately and solving different problems, we found that both companies developed similarities in company culture, product, and implementation.

API First

Early on, Merge and Stytch recognized that we weren’t just building products and then exposing them with APIs. The APIs were our products. To us, this represents a radical shift in how API start-ups operate.

What differentiates this new wave of API startups is the freedom to build APIs the way we want. Systems born in the on-prem and early-cloud era lacked, up until a few years ago, the plasticity to create a modern API. These APIs were built from the backend up, and so are often limited by the implementation details of the systems they expose.

We have the privilege of starting companies in an era where the API is first documented and implemented before the underlying systems are created. This ordering is crucial to provide design flexibility for our core product: the API. Our APIs are built to power experiences and flows within other products, and this design flexibility allows the use cases of our customers to be thoroughly accounted for. Through iterative customer collaboration, we’ve achieved easy to add, fully native experiences. We’ve aspired to make our APIs cool.

API = A Pretty Interface

Design holds a double meaning for Merge and Stytch. Our products are APIs, and so we scrutinize every field, endpoint, and available action to cater towards a robust user-developer experience. At the same time, we recognize the value of and invest heavily in “traditional” product design. Whether it’s landing pages, documentation, embeddable UI components, or dashboards we constantly ask how to better craft pages that express complex topics within a simple UI.

There has been a recent wave of fantastic startups that help to design API documentation, however at both Merge and Stytch there was a clear decision to build our own. We needed flexibility to express concepts, create guides, and provide interactive experiences for our users. Though we each followed a different path to accomplish this, we couldn’t be more thrilled with the other’s result.

At Stytch, we designed and built our documentation in-house. All documentation lives in a Github repo like the rest of our code, so it’s become a natural part of the development process to include documentation changes when new code is shipped. In our early days we initially tested documentation through OpenAPI. However, we became continually frustrated with the time it took to implement OpenAPI's auto-generation with our own product. We realized that not only would it be more efficient to build our own client libraries, but by doing so we would gain a far deeper understanding of how our documentation actually worked. We found that making documentation changes as a standalone changeset, separate from the implementation of API endpoints, allowed for more detailed and flexible documentation. The downside of this DIY method is that some work required to make sure that the API, client libraries, and documentation are in-sync.

Merge chose to generate documentation using OpenAPI. Acknowledging that the ecosystem is young, we saw it as an opportunity to provide feedback and take part in an audacious open-source initiative. While the specification’s imperfections imposed a burden, we ultimately realized time-saving automation: changing an API endpoint automatically regenerates documentation, deploys the frontend, regenerates SDKs, and merges the code. When the backend receives new API functionality, we create generic methods that automatically generate pixel-perfect interactive experiences for the frontend.

Companies who use API products are able to build their core product faster. In our expanding API-economy we’ll continue to see more and more capabilities packaged in APIs. The difference, we believe, between losers and winners lies in who creates an API that’s cool— not just functional. Merge and Stytch are inspired to help craft new standards for the next generation of API companies.

Check out Merge here: https://merge.dev

Check out Stytch here: https://stytch.com/







---


# Announcing our SOC 2 Type II
Source: https://stytch.com/blog/announcing-our-soc-2-type-ii/

Today, we’re excited to announce that Stytch has officially received our SOC 2 Type II certification.

Today, we’re excited to announce that Stytch has officially received our SOC 2 Type II certification.

Our SOC 2 Type II report outlines the extensive security and availability controls that Stytch has implemented and continually operates in order to offer our customers an exceptional experience.

We learned a lot going through the process for the first time and wanted to share our findings in case they’re valuable to others preparing for their first SOC 2 process. When done right, SOC 2 can be extremely valuable for establishing best practices and communicating your commitment to security to customers, but it can also be intimidating to get started..

When to start

Stytch builds critical infrastructure for our customers, and so security and availability of our platform is of the utmost importance. We knew at some point we’d need to formalize our commitment to this with SOC 2, but how early is too early?

We started laying the groundwork for SOC 2 before we hired our first employees because we wanted to build a culture around security from the beginning and implementing policies only gets harder with more people.

We then spent a couple months trying to figure out when was the right time to actually schedule the audit period. Ultimately, we decided to wait until our product had reached some level of maturity because we wanted the report to be representative of our systems. We iterated a lot on the product and infrastructure during our early alpha period and decided to wait to graduate from that before kicking off the audit period.

SOC 2 Type II vs Type I

A decision you’ll have to make is whether to jump straight to a Type II, like we did, or start with a Type I. We didn’t have immediate time pressure to complete SOC 2 and so, if we were going to spend the time on SOC 2, we wanted to do it right with a Type II.

A Type I certification is much faster because it is a one-time snapshot of your internal practices rather than an ongoing, multi-month audit involved in the Type II certification process. However, its value is relatively minor for SaaS companies because your customers want to know that you consistently and reliably follow best practices.

Preparing for a smooth audit

We use Vanta to help automate some of the SOC 2 process, their integrations and monitoring make it easy to keep an eye on things and ensure that you’re living up to your policies. While they do a lot of the heavy lifting, there are still many things that you’ll need to figure out if they’re relevant or not given your systems and the specific criteria in scope for your audit.

Making sure you’re on the same page as the auditors is key and building a good relationship with them early on makes the audit process much smoother. Asking your auditor lots of questions early on ensures that you’re not just doing the right things but also documenting them appropriately.

Want to learn more?

If you’re interested in using Stytch, you can get started today by creating an account here. And if you’d like to contact us directly, you can email us at hello@stytch.com.







---


# Building the future of authentication
Source: https://stytch.com/blog/building-the-future-of-authentication/

At Stytch, we’re on a mission to eliminate friction on the internet while improving security.

In the world of modern applications, the methods currently used to onboard, authenticate, and engage users are broken. They cause needless friction, leading to frustrated users, lower conversion rates, and stunted growth.

At Stytch, we’re on a mission to eliminate friction on the internet while improving security. We’re building solutions that reimagine user infrastructure, starting with out-of-the-box and customizable passwordless authentication products that are easy for engineering teams to integrate. With our flexible APIs and SDKs, Stytch customers can improve user conversion, retention, and security, all while saving valuable time.

Out with the old: the problem with passwords

By the end of this decade, online passwords will be a thing of the past. They’ll go the way of the fax machine—a quaint technology that’s long outlived its innovative purpose. Ultimately, this will be a welcome shift, improving developer and user experience and bolstering companies’ bottom lines by removing obstacles to conversion.

We aren’t waiting on a breakthrough to bring this prediction to life. Simple developer tooling built on existing technologies will make passwordless authentication ubiquitous, with Stytch leading the way. But before we lay out where we’re going, let’s take a look at where we’ve been.

In with the new: the evolution of passwordless auth

Since the internet exploded in the 1990s, major authentication shifts have marked each decade.







For instance:

In the 1990s, as the internet went mainstream, passwords were the dominant form of authentication.

In the 2000s, as users opened more and more accounts, password managers—which encrypt and store online login information—were introduced to help them handle this increasingly complex landscape.

In the 2010s, as online technologies advanced, alternative auth methods—often referred to as “two-factor authentication”—embedded low-friction, secure hardware (like biometrics and YubiKey) and software (like APIs for programmatic text and email) into the user experience.

In the 2020s, as we begin to embrace passwordless authentication, resourceful companies like Slack, Medium, and Square Cash are leading the charge. Stytch is making it easy for every company to build and integrate a delightful, passwordless user experience in hours rather than months.

Even with these developments, password overload is a ballooning issue. Surveys have found that the number of password-protected accounts per user has increased exponentially in recent years, in response to an explosion of new apps and online services.

One study found that between 2019 and 2020 alone—with people likely spending more time online due to the COVID-19 pandemic—the number of passwords per user jumped 25%, from an average of 70-80 to 100.



A recent poll also showed that most users don’t take advantage of existing password managers. As a result, 37% forget a password at least once a week, increasing the likelihood they’ll abandon a commercial account or leave a purchase incomplete.







The good news? Best-in-class teams are now pushing their companies to go fully passwordless.

This shift won’t be dominated by a single authentication method (like biometrics) but will consider the trade-offs between different options.

For many companies—especially sensitive fintech apps like Square Cash, Revolut, or Monzo— requiring multiple passwordless verification methods for increased security is becoming the norm.

Needless friction

Considering this progress, the shift to passwordless authentication feels inevitable. Still, skeptical companies may be reluctant to abandon authentication solutions they’re familiar with. A common mistake in recent years has been treating alternative auth methods as second-factor, rather than primary-factor, candidates.

Most companies are unaware that they already have passwordless flows in place, and they’ve needlessly complicated these processes for users. Whenever a customer passes through a site’s password reset protocol, they’re essentially experiencing passwordless authentication.

But instead of a seamless email login link (or a “magic link”), they’re seeing something like this:



Step 1: User forgets password.
Step 2: User clicks “Forgot password?” link.
Step 3: User enters email and requests password reset flow.
Step 4: User opens inbox and clicks the password reset link.
Step 5: User creates a new password with a set of 10 complicated rules.
Step 6: User confirms new password with 10 complicated rules.
Step 7: User is redirected to the original login page.
Step 8: User enters username and new, complicated password.

In this case, for a simple email verification, a user must navigate eight increasingly complex steps—all to set up a new, convoluted password they will likely forget in a couple of days.

Updating tiresome login flows to newer methods like email magic links or SMS logins is just one glimpse into passwordless possibilities that will significantly boost user experience and conversion.

A better path forward

Password-dependent authentication methods are problematic for stakeholders across the board.

For developers building out these flows, it’s a time-consuming and error-filled process that can involve multiple engineers and many months of maintenance annually.

For consumers using these flows, login information piles up as they open new accounts, yielding more and more passwords they’ll forget.

For businesses relying on these flows, unnecessary friction increases customer acquisition costs and reduces users’ lifetime value.

Passwordless authentication platforms—like those being offered by Stytch—solve these issues with flexible APIs and SDKs that save valuable engineering time and improve an end user’s experience.

By making it simple and affordable for developers to integrate best-in-class authentication options, these solutions transform the above challenges into key benefits.

For developers, going passwordless saves significant resources and removes the burden of dealing with app security.

For consumers, going passwordless makes logging in easier, faster, and more secure while erasing the headache of memorizing or tracking passwords across accounts.

For businesses, going passwordless improves both user onboarding conversion and user retention over time.

What can Stytch do for you?

Keep up to date with Stytch’s new products and features through our Changelog. Jump into our Docs to learn more about our flexible, frictionless authentication solutions—or sign up for a free account to try them out for yourself. Click here to get started.





---


# Announcing our $30 Million Series A to make passwords a thing of the past
Source: https://stytch.com/blog/announcing-our-30-million-series-a/

We are thrilled to announce Stytch has raised $30 million in Series A funding led by Thrive.

We are thrilled to announce Stytch has raised $30 million in Series A funding led by Thrive, with participation from Coatue and existing investors, Benchmark and Index. We’re also proud to welcome Thrive’s Gaurav Ahuja to our board of directors, who is joining alongside Benchmark’s Chetan Puttagunta. Additionally, we're bringing onboard new angel investors including Matthew Prince, Cassidy Williams, Neha Narkhede, and Joshua Browder.

When we were at Plaid, we witnessed the shortcomings of passwords first-hand, both from a security and usability perspective. We saw how often users gave up when the authentication process was too hard and, for all the friction passwords introduce, they still leave users vulnerable to account takeover attacks.

User experience and security have both evolved over the past few decades, but authentication is stuck in the 1990s despite underpinning all of our online interactions.

That’s why Stytch was born - to make the next generation of authentication passwordless.

We believe in building tools and infrastructure that make it easier, faster, and safer to build authentication into apps and websites. We’re making it easy to modernize your authentication flows and build great user experiences by adopting passwordless technologies.

The traditional approach to authentication ignores the significant downsides of passwords. 65 percent of users reuse passwords across different accounts, posing a significant security threat and creating larger breach liabilities. At the same time, we're constantly forgetting and resetting them. When users forget their password, about 75 percent give up and don’t complete the reset process. Similarly concerning, 45 percent of users report password authentication “frequently” or “very frequently” prevents them from completing an online transaction, costing businesses money and users.

Over the past several years, there has been a rise in alternative authentication methods, using advances in both hardware (e.g. biometrics, YubiKey) and software (e.g. APIs for programmatic text + email), which have paved the way for a passwordless future. But building a robust new system for authentication is no small undertaking – companies would need to dedicate entire teams to solving this problem themselves. We see this as a massive opportunity to help developers move to a new era of authentication where they can embed passwordless authentication methods through simple APIs and SDKs

At Stytch, we’re building the platform that we wish we had in past roles and making it available to anyone.

Today, we have more than 350 developers building on the Stytch platform adding email magic links, SMS and WhatsApp passcodes, and one-click user invitations into their user onboarding and login flows. In addition to these core passwordless features, we’ve seen companies of all sizes drawn to the simple developer experience and the flexibility offered by our API-first approach, including a handful of fortune 500 companies that are using the product.

But we’re just getting started. With the new funding, we’re working on adding numerous new authentication options like mobile biometrics, WebAuthn, OAuth logins, QR codes, and push notification login to the platform. We’re also expanding the user infrastructure features that make Stytch the simplest and lowest friction way to onboard and engage users, building out session management, account recovery, and more advanced fraud detection.

The future of authentication is here, and you can get up and running with Stytch today. Sound like something you want to also get behind? We’re looking for more great people, so check out our open positions.

Julianna and Reed

---


# Forget the password reset flow as you know it
Source: https://stytch.com/blog/forget-the-password-reset-flow-as-you-know-it/

For those still using password-based authentication, implementing a password reset flow can be a frustrating step.

For those still using password-based authentication, implementing a password reset flow can be a frustrating step. Not only is it a headache to build, but it introduces unnecessary friction to the user experience and frequently results in users abandoning the interaction.

A password reset flow is essentially a passwordless login with many additional steps tacked on. By leaning into this and using passwordless solutions as an alternative to password resets, you can delight your users and increase conversion and engagement.

To illustrate this point, we’ve identified three ways a password reset flow can undermine your app’s performance—and a glimpse at how passwordless solutions can help.

1. Users forget their passwords, and they forget them faster than you think

The password reset flow is often an afterthought. If you’ve spent multiple sprints building a secure password login, it feels reasonable to wait on the password reset process and focus on your core product.

After all, how many people will really forget their password in the first months after launch?

The truth is, users are creating exponentially more passwords each year as they discover new apps and open new accounts. And the more passwords they accumulate, the likelier they are to forget them.

According to a recent study, over 20% of users report forgetting a newly created password within two weeks. That number climbs to over 70% after just a few months.

Joint study from Mastercard and the University of Oxford

So, when’s the right time to build a password reset flow? If you’re choosing to rely on password-based authentication, it’s right away—before that first forgetful user reaches out for help.

(Of course, we’d say never. If you go fully passwordless, you’ll avoid this problem altogether.)



2. The password reset flow is just an overly complicated email verification

It’s easy to forget that the password reset flow is really just a multistep email verification process.

When a user goes through a password reset, they’re essentially experiencing passwordless authentication.

But instead of receiving a quick email login link—otherwise known as a “magic link”—they’re seeing something like this:



Step 1: User forgets password.
Step 2: User clicks “Forgot password?” link.
Step 3: User enters email and requests password reset flow.
Step 4: User opens inbox and clicks the password reset link.
Step 5: User creates a new password with a set of 10 elaborate security requirements.
Step 6: User confirms new password.
Step 7: User is redirected to the original login page.
Step 8: User enters username and new, complicated password.

In this case, for a simple email verification, a user must navigate eight increasingly convoluted tasks—all to set up a complex new password they’ll likely forget again in a couple of days.

3. A high-friction password reset flow can lower conversion rates and put users at risk

Once a password reset flow has been built, engineers tend to forget about it. But by not tending to it on a regular basis, you might miss out on key opportunities to boost user experience.

Studies have shown that a weak or outdated reset flow can have a significant impact on your business and even make users vulnerable to cyber attacks.

Common blunders—like sending plaintext password reminders, asking for information that is easily findable online, or using error messages that disclose if a specific email address is registered—can pose huge security threats. And demanding too many (or the wrong kind of) verification tasks can frustrate users and lead them to abandon the reset flow altogether.

On average, about 10% of your active users will pass through the password reset flow each month. Of those, 75% will drop out partway through the multistep process.

To put that another way: with a high-friction password reset flow, you’re losing 7.5% of high-intent users before they’ve even had a chance to engage with your application.

Passwordless magic

With all the problems a password reset flow can cause for an app, it’s worth considering how passwordless tools can improve the process.

Forward-thinking companies like Instagram are choosing to optimize user experience and retention by replacing the password reset flow with passwordless options like email magic links.



Using an email magic link cuts the tiresome eight-step password reset flow down to two simple steps. When a user clicks the “Forgot password?” link, they are prompted to enter their email address. If registered with the app, they’ll receive a magic link in their inbox which, when clicked, automatically signs them back into their account.

That’s it. No fuss, no complicated new password, no compromised security. Once a magic link is used, it becomes invalid, so there are no loose threads that could put an account at risk.

Integrating passwordless solutions like email magic links and SMS logins into your app’s password reset flow is a great way to quickly improve the user experience.

Key takeaways

A poorly executed password reset flow can have big consequences for your users and your business.

Why not avoid the issue altogether by going passwordless? Secure, efficient passwordless options are available and can go a long way towards removing burdensome flows, improving the developer and user experience, and boosting conversion rates. Even if you're not ready to fully eliminate passwords from your application, you can follow our simple guide for using the Stytch API to replace your password reset flow with a one-click email magic link.

Interested in ditching passwords?

Stytch helps you go passwordless by providing easy-to-integrate API and SDK authentication solutions. Let us build the infrastructure, while you focus on your core product.

Sign up for free to start using the API.

A path forward with Stytch

Stytch is on a mission to eliminate friction on the internet. Learn more about our modern, passwordless approach to authentication.







---


# A founder's guide to hiring engineers
Source: https://stytch.com/blog/a-founders-guide-to-hiring/

People are everything when it comes to building a company; here's how we think about hiring great people.

People are everything when it comes to building a company; here's how we think about hiring great people.

One of your most important tasks as a founder is to hire and retain great people who are excited to be part of the journey—especially when you’re just starting out.

While recruiting is always a challenge, your first few engineering hires are critical as you begin to build your product. These team members will help establish your company culture and set the tone for future candidates. We'll focus here on hiring engineers but most of it is broadly applicable.

As a founder, you may be involved in interviewing every candidate for some time. But your first team members are special because they become the ones who attract, interview, and hire the next cohort.

You’re asking your earliest hires to take a chance on you and on a product and team that are just beginning to take shape. In this guide, we lay out our best hiring practices in three key areas: identifying top talent, mutually evaluating whether they’re a good fit for the team, and selling them on joining. While some of these tips are geared toward the early stages of team building, most are relevant to all stages of growth.

Finding great talent

Start with your network

It’s hard to know where to begin when you’re building a team from scratch. The good news is, you probably already have an established network you can turn to. Better still, your close contacts are familiar with you and your accomplishments, so you’re likelier to find a receptive audience.

Start by texting friends who are engineers themselves or who have many engineers in their circle. That’s how Stytch snagged one of our very first hires.

This text can be informal, something like: “I recently started a company building a platform for user authentication. We’re hiring a couple of engineers, and I’m wondering if there’s anyone you know who might be interested!”

Keep it open enough for that person to then send it around to their contacts.

That said, hiring from your immediate network can come with drawbacks like over-indexing on people with similar backgrounds—but it’s a valuable place to start. We include some pointers below on how to ensure you keep your pipeline diverse.

Leverage LinkedIn

Next, start looking through your Linkedin connections to find people you don’t know well enough for a text but who could be a good fit.

It goes a long way to spend a bit of time crafting a personalized message. It will show you care about them and what their strengths are. It's also an opportunity to share more about what you're building.

For example, here’s a message we was sent to one of our first engineers:

Hi [X],



Not sure if you remember, but we grabbed coffee back when I was at Plaid. I'm now the co-founder—along with Reed, also from Plaid—of a new company building infrastructure for user auth. Stytch makes it simple for developers to build passwordless authentication flows that delight users. There's some info on our website, but we're still building that out, so I can share more details on a call. We just finished raising a seed round and are now focusing on hiring engineers in anticipation of launching to our beta customers later this year.



A platform engineer is an important hire for us. Our product will be in the critical path of customers’ applications, so our infrastructure is at the core of what we do. I remembered our conversation about the work you were doing with Kubernetes—that type of experience is exactly what we're looking for, so I had to reach out. I’d love to share more if you're interested!


While you should keep your message brief, be as specific as you can. Highlighting particular technologies or problems they've worked on in the past shows that you understand the type of work they do and how it would fit with your team.

Be proactive with cold sourcing and outreach

Sourcing talent and engaging in cold outreach will be part of your role as founder for a long time to come, so it’s worth your while to work this muscle early on.

We use Ashby for our ATS and sourcing. It lets you build email campaigns, save LinkedIn profiles, find a candidate’s email address, and create an email in your drafts to send. This is incredibly helpful for running a sourcing process, and it allows you to customize a message using a Chrome plug-in while viewing a candidate’s profile.

Customization goes a long way toward demonstrating your excitement about a candidate and differentiating your message from the many recruiting emails they’re getting each week.

We primarily use LinkedIn for sourcing but occasionally check AngelList, as well. The benefit of AngelList is that you can tell if someone is passively looking for a new job, but generally the signal-to-noise ratio makes it a challenging tool to use effectively.

It helps to tailor your searches to a specific goal. If you’re hiring across the stack, you can view a wide range of candidates by using “software engineer” as your only filter. If filling limited roles, you should search narrower terms like “platform engineer” or “product engineer,” depending on your needs.

While you can conduct language-specific queries, many people don’t add that level of detail to their profiles. One approach that works well is to search through companies you know use the language or technologies in which you’re looking for expertise.

As you’re sourcing, keep in mind that you’ll be limited to the talent pool that’s already part of your filters. For example, sourcing only from large tech companies will give you a pool of candidates that’s only as diverse as their teams.

You can be intentional in building your pipeline by specifically targeting people from different backgrounds and environments, including from colleges and coding bootcamps.

Build a great interview process

Always be closing

During an interview, you’re evaluating a prospective employee’s skill set and character, but you’re also selling them on joining your team.

We design our interview questions to be as collaborative and representative of real work as possible so that the candidate gets a sense of what joining the team will be like.

Our engineering interview loop consists of a mix of questions that cover coding, systems design, product ideation, and collaboration and communication skills.

For coding interviews, a candidate can use their own environment and language of choice so it feels as natural as possible. We also encourage liberal use of Google to match their day-to-day practices. The interview should be about how well a candidate solves the problem—not what they’ve memorized around a language’s built-ins.

Aim to make the experience productive, regardless of the outcome. It’s important that a candidate leaves the interview feeling like they answered your questions and you answered theirs.

For instance, you can structure interviews so more challenging questions and tasks arise as candidates do well, with their ultimate “score” resting on how far they got and how much assistance they required.

You should also set some time aside—about 10 minutes for an hour-long interview—for a candidate to ask their own questions and settle any concerns.

Dive into references

As a small team, every hire has a huge impact. It’s critical to understand not only how a candidate performs during a quick interview, but how they’ve worked with teams in the past. To get a better picture of that, we lean heavily on references.

To understand the context behind a reference, you should ask the following questions:

What was/is your relationship to this candidate?
Ask for information around their respective roles, any shared projects, how long they worked together, and their most recent interactions.

What was/is the organizational culture like at your workplace?
This helps to understand any quirks of the culture and to place the reference within that culture.

To get a good sense of your candidate’s abilities in their prior role, you can ask:

What stood out about their character or job performance? Can you offer an example?

Can you describe an instance where this candidate took initiative?

On a scale of 1-10, how would you rate this candidate’s performance? More importantly, what would it have taken for them to move up one point?

Would you want to work with this candidate again?

What advice would you give this candidate to help them excel in a new role?

Build in enough questions that you get a well-rounded idea of how your candidate fit into their last workplace personally and professionally—but try to keep the conversation concise and to the point.

Move swiftly

It’s a competitive market out there, and one advantage you have as a startup is speed.

This is likely also a reason the candidate is interested in joining you. They want to work somewhere where things move quickly, so it’s important you meet that expectation throughout the hiring process.

If you’re moving forward on a candidate, reach out to ask for references within 24 hours of the final interview round. At this point, we share our enthusiasm about potentially having them join our team, but we also make it clear that we take references seriously.

We aim to timebox our references to three days. Letting them drag on too long risks losing the candidate.

Get them excited

We surprise candidates on offer calls with a Zoom bomb. Everyone from the interview panel joins and shares a bit about why they’re excited for the candidate to join the team. This makes candidates feel appreciated and helps them envision the impact they would have at Stytch.

We then walk the candidate through the offer details and a spreadsheet that brings clarity to valuing startup equity.

Evaluating early-stage startup offers can be incredibly challenging. There are many factors—like funding raised, investors, and team size—that influence what a compensation package (and particularly the equity component) might look like.

At the early stage, equity is more about the potential, rather than the present value of a company. To help candidates visualize this, we share a comprehensive spreadsheet that allows them to forecast different exit scenarios.

Close the deal

Closing candidates is about understanding their hesitations and what it would take to overcome them. For some, they’re already sold on joining, and it just comes down to the numbers.

Many times, we find that when candidates push for more equity, there’s an outstanding question in their mind around valuing the equity and the potential upside. To address this, we offer to introduce them to investors who can contextualize the offer within the current market and speak to the company’s potential.

More than anything else, joining an early-stage company is about the team. To help candidates picture themselves as a part of our work environment, we facilitate conversations with team members they haven’t yet met. When the team was just the founders, we offered up conversations with angel investors who had worked with us in prior roles.

Ultimately, they’ll be joining your community, so lean into building those relationships early.

Create a flywheel

Building an open, engaging, and responsive work culture will create the best possible feedback loop. Not only will you attract incredibly talented people, they’ll be your greatest ambassadors moving forward and bring even more talent to the table.

What’s next?

You’ve hired a great engineer—now what? One of the best investments you can make is taking the time to onboard new hires so they thrive in your organization right off the bat. A team that's excited about the company and culture will be your best asset in both building a great product and hiring more people to help in that mission.

Why Stytch?

Stytch is leading the way on modern, passwordless authentication and user infrastructure. Learn more about our vision, our values, and our amazing team here. Want to join us? We're hiring!

---


# How just-in-time authentication boosts security and conversion
Source: https://stytch.com/blog/how-just-in-time-authentication-boosts-security-and-conversion/

How just-in-time authentication boosts security and conversion

Securing your app shouldn’t come at the cost of usability.

Front-loaded, application-based authentication methods have long dominated the security landscape. But these high-friction flows are tedious for users and can negatively impact their experience and your conversion rates.

Now, route-based models are making it easier for apps to verify users without compromising engagement.

Let’s take a closer look at the user access journeys across each of these authentication methods, identify their key differences, and compare their respective levels of friction and convenience.

Upfront friction: application-based authentication

Traditionally, apps have front loaded their authentication requirements. Once users pass a number of steps—typically involving a username and password, security question, and two-factor verification process through SMS or Google Authenticator—they are granted full access to the app and can carry out any action they like, regardless of its sensitivity.

For example, if a stock trading app uses this model, it doesn’t matter whether a user is pursuing a relatively minor, “read-access” task (like checking a stock price or their account balance) or a riskier, “write-access” task (like withdrawing funds). Once they’re in, they’re good to go.

This front-loaded approach is called application-based authentication, because it treats the entire app as a monolith.

The problem with application-based authentication is that it requires users to complete the same high-friction, burdensome flow each time they engage, regardless of the risk level of the actions they wish to take.

Application-based authentication is a relic of the early days of online security, when there was really only one form of verification: the password.

In a password-based world, this front-loaded approach made sense because the password was the only authentication factor. Either you’d successfully enter it and access your account, or you’d be shut out. But with the advent of new methods like SMS, email, and biometrics—which are added to existing password flows—sticking to an app-based approach overcomplicates the sign-in process without offering additional security when it’s needed most.

Security when it matters: route-based (aka just-in-time) authentication

Today, application-based authentication is no longer sensible. In recent years, new methods have emerged, enabling us to verify users more intelligently through a process known as route-based authentication.

In route-based flows, applications only introduce friction when it’s needed, using incremental security for higher-risk actions within an app.

Tasks like moving money, changing credit card information, and accessing personal data all justify this increased security and added friction. At the same time, users pursuing low-risk tasks aren’t burdened with undue verification measures.

Because the process is triggered by a specific, sensitive task and the resulting access is temporary, this approach is also referred to as just-in-time authentication.

So, what does it look like in practice?

Consider an app like DoorDash. Users enter a username and password to access the platform. From there, they can browse local restaurants and even place an order whenever they want without signing back in. But if they try to do something riskier—like change their delivery address—they trigger a two-step, SMS verification process.





By introducing friction only when it’s necessary for extra security, an app greatly improves user experience—and, in turn, boosts customer conversion and satisfaction.

Breaking it down

Think of these two different authentication methods like security on a house.

With app-based authentication, you’re essentially putting a deadbolt or two (or five) on your front door. To be safe, you have to lock and unlock all of those bolts every time you go in and out. And once someone gets in, they can help themselves to anything in your home.

With route-based authentication, you may have a lock on your front door, but you reserve the extra bolt (or alarm, guard dog, or Home Alone-type setup) for the safe inside holding your valuables. Even if you leave the front door unlocked every now and then to let your friends in, an intruder will still have a hard time getting to what matters most. It’s more secure (and less demanding) because the components are more strategically and conveniently arranged. It’s also friendlier and more welcoming for those who mean your home no harm.

Key takeaways

The days of heavy, up-front app security are behind us, and the future promises more seamless and organic access flows. Integrating route-based authentication methods into your app will help you safeguard what’s most important—while delighting, engaging, and converting your users.

A path forward with Stytch

Stytch is on a mission to eliminate friction on the internet, and our platform supports and facilitates route-based authentication flows across use cases.

Want to learn more about how we do it? Read up on our easy-to-integrate user infrastructure solutions in our API docs.

Interested in trying our platform?

Sign up for free to test out our API.

Helpful terms

Let’s clear up some of the jargon:

Application-based authentication is a front-loaded security method, where users must pass through a single, heavy-handed verification flow every time they access an app and are then permitted to all its internal tools and services.

Route-based authentication is an incremental security method, where a user must only undergo extra checks—like two-step, SMS verification—to carry out more sensitive tasks within an app.

Just-in-time (JIT) authentication is another, less technical term for route-based authentication.

Step-up challenges are additional steps users are asked to take in order to verify their identity.







---


# Grace Baelen-King
Source: https://stytch.com/blog/grace-baelen-king/

Today is a special day, a year ago Stytch became a real team when Grace joined as our first hire!

Today is a special day, a year ago Stytch became a real team when Grace joined as our first hire! To celebrate, we’re kicking off a new series where we’ll highlight different team members. In this first installment, learn more about Grace and her experience as employee #1 at Stytch!



What’s your role at Stytch?

I’m a software engineer on our backend team.

What do you love most about working at Stytch?

Getting to build the foundation of a product that is very useful.

Which Stytch value resonates most with you and why?

Design for the future, build for the present. That for sure; it’s exactly what I’ve been doing for the past year. I think one of the things I said a lot early on and still say is “if we’re rebuilding this in two years, that’s a success” that means it worked for that long and we’re around to do it. It’s about making sure we're not technically backing ourselves into any corners.

Describe your journey into engineering. How did you choose that career?

I took a computer science course because I needed a math credit and I wasn’t allowed to take any other math classes at my college because I didn’t have the proper prerequisites. So I took computer science and I was like, “oh, this is kinda cool” and my dad who is also a software engineer was like, “yeah, that’s what I’ve been trying to tell you your entire life”. I later did an internship in HR but it looked like the engineers were having more fun and my boss was like, “you could be a great HR person but you should just go be an engineer”. So here I am!

What do you remember most from the early days?

There were so many slack channels already when I joined, Reed and Julianna had been having conversations with each other in various channels to start to build slack culture and context. It was very satisfying to get 2 reactions on something because that meant the whole company reacted. A week later more team members joined and I remember a lot of zoom calls with Danny, our platform engineer. Danny and I would spend like 3 hours on a zoom call working on something. We wrote a lot of code really quickly and it was really exciting, like how do we set up a code base, these foundational things and some of them have been thrown away but many are still there today. It’s been fun to see what was not a great decision or was a good decision at the time and didn’t scale vs what things we did that have continued to scale with us.

What have you learned starting as the first hire at a company and growing to ~25 in a year?

Time is wild. I guess it doesn’t feel like it’s been a year. I still find it hard to believe that we’re that many people and really it’s just every step we take it’s like “we’re a real company” and we keep becoming more of a real company with every step. I’ve been surprised by how quickly we felt like a real company. I think that first week when it was me, Reed and Julianna, some things, it was like this is silly. For example, I think we had about the same number of slack channels that we have now. Very quickly it was like oh that’s because we’re a real company and we’re doing things. I was surprised by how quickly that feeling came. But also then other things happen now and I’m like ok now we’re a real company. It’s like being an adult. When are you a real adult? Who really knows?

What’s the most interesting project you’ve worked on at Stytch?

I think the most interesting project I've worked on is setting up the foundations of Stytch. Building our first product, email magic links, was really more about building the foundation of our backend codebase and that was by far the most daunting and fun project I've ever worked on.

When’s the last time you did something for the first time and what was it?

I recently played Animal Crossing for the first time, it was very relaxing.

What’s your ideal weekend?

A mix of dinner with friends, hiking in the redwoods, reading a good book in the sunshine, baking something delicious and ending with dinner at my parents house on Sunday evening.

What’s the best piece of advice you've received?

Work hard, get smart, get help. One of my favorite CS teachers used to say that.

---


# Danny Thomson
Source: https://stytch.com/blog/danny-thomson/

Today we continue our celebration of our Stytch-iversaries with two of the engineers who helped round out our first Stytch team, Danny and Mary.

Today we continue our celebration of our Stytch-iversaries with two of the engineers who helped round out our first Stytch team, Danny and Mary. We’re excited to celebrate this milestone with them and share more about their journey at Stytch! Danny joined us as our first platform engineer, learn more about his experience here.





What do you love most about working at Stytch?

I'm constantly learning how to build and run an API-first company from an engineering and business perspective.

What does a typical day at Stytch look like for you?

As a platform engineer, my day to day tends to vary since I get various platform requests through the week. I aim to have a couple hours of deep focus time where I can solve my current task, and then fill the rest of my days helping troubleshoot any platform issues that pop up, reviewing PRs, and chatting with my teammates over a Zoom. I usually start working around 8:30 to 9:30 and wrap up sometime between 5 to 6.

What’s been the most surprising thing about Stytch?

This is obvious in hindsight, but I didn't realize how many different decisions go into building a product and a company. When I worked at larger companies, a lot of those decisions were abstracted away from me, and allowed me to focus on a narrow problem. Meanwhile, Stytch has me more touching problems across the entire company. This has made me appreciate the amount of work it takes to start a company.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

I'm constantly shocked by how fast this past year has flown by, and I've realized that startups make it easy to lose track of time since there's always more work to do. A good piece of advice I got was to occasionally slow down for a minute and appreciate all the hard work everyone has done and enjoy the exciting time of building a company from scratch.

From a more technical perspective, I've learned to lean into making quick decisions for easy-to-change problems and take more time for more permanent decisions. As an example, changing a variable name in the file is a quick PR and not worth discussing, Meanwhile changing a database is usually a months-long trip project and requires significant planning.

Which Stytch value resonates most with you and why?

I resonate with Stytch's Think Exceptionally value. I love throwing out novel (and sometimes unfeasible) approaches to a problem and then working with my teammates to find a way to make them possible.

What’s the most interesting project you’ve worked on at Stytch?

My most interesting project is researching and building out Stytch's OAuth product. I've enjoyed exploring the problem space more and incorporating those learnings into building a richer user experience

How did you end up becoming a software engineer?

Going into college, I knew that I wanted to do some kind of engineering, and I decided to take the intro CS course in the spring quarter of my freshman year. I immediately knew that CS was the right major for me, and I built an Android app the summer after the class. After graduation, it was an easy transition to become a software engineer.

When’s the last time you did something for the first time and what was it?

I went rollerblading for the first time as an adult and I had a blast! I'm now getting rollerblades so I can skate along the Embarcadero.

What song, hobby, or recipe got you through COVID?

I love repeating cooking recipes and trying to improve the dish each time I make it. I made the same apple strudel recipe five times until I ran out of flour during the flour shortage last year.

What’s your ideal weekend?

A mix of hanging out with friends at a park in SF, getting some delicious food at a new restaurant, and ending the weekend with a good movie.

What’s something you’re passionate about that’s not on your resume?

Food! I love buying, eating, and cooking new foods that I haven't tried before.

---


# Mary Gruen
Source: https://stytch.com/blog/mary-gruen/

Today we continue our celebration of Stytch-iversaries with two of the engineers who helped round out our first Stytch team, Danny and Mary.

Today we continue our celebration of Stytch-iversaries with two of the engineers who helped round out our first Stytch team, Danny and Mary. We’re excited to celebrate this milestone with them and share more about their journey at Stytch! Mary joined us as our first product engineer and now is the engineering manager for that team, learn more about her here.



What do you love most about working at Stytch?

One thing I love about working at Stytch is the collaborative culture. Everyone has their specific job duties but is primarily focused on the success of the company. If you need help debugging something or want to brainstorm new ideas, they are willing to spend time helping you out. It also means decisions aren't made in silo.

What does a typical day at Stytch look like for you?

Most days are different! I am primarily focused on helping my team, which includes 1:1s, product specs, PR reviews, hiring, and coordinating with other teams. I also contribute code when I have time!

What’s been the most surprising thing about Stytch?

I'm surprised at how fast we have been able to grow. We're able to get a lot more done with 25+ than we were with 6!

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

There's a lot of pressure to get things right from the start when building things from scratch. In order to move quickly, we can't spend weeks on every decision. Our founders introduced a framework where everyone is empowered to make decisions that are highly reversible and low impact (such as copy) without waiting for sign-off from a group while spending more time on more important decisions, like those impacting architecture or security. It's a helpful framework when prioritizing what you spend your time on.

What’s your favorite part of the Stytch culture?

I love Stytch's focus on feedback. We've been really intentional about creating multiple feedback channels, including formal reviews, monthly peer feedback, and 1:1s. It's great that we are constantly flexing the feedback muscle rather than waiting for yearly reviews.

Which Stytch value resonates most with you and why?

I love our core value around trust (Trust like it's Christmas 1914). I think it's really important when working with both coworkers and customers to assume they have the best intentions. This is a great framework when approaching a disagreement or miscommunication. I think it also embodies the idea that folks know what the best working environment and hours are for them. We don't track how long folks are online/in the office - we just care that they are getting their best work done.

What’s the most interesting project you’ve worked on at Stytch?

Building our docs from scratch was a fun project. We decided to build in-house rather than use a 3rd party to create a better developer experience. Users can copy code snippets with their API keys pre-filled and update their settings straight from the docs.

How did you end up becoming a software engineer?

I was introduced to CS in high school and ended up taking a few classes in college. I really enjoyed web development, especially focusing on user experience, where I could tangibly see what I was building.

When’s the last time you did something for the first time and what was it?

I learned to golf during quarantine. It was a great way to spend time outside.

What song, hobby, or recipe got you through COVID?

TBH I watched a lot of reality TV during COVID. And I continued to golf!

What’s your ideal weekend?

My ideal weekend would consist of a trip to the farmers market, wine tasting, and/or a day trip to the beach.

---


# Nathan Chiu
Source: https://stytch.com/blog/nathan-chiu/

We're celebrating another Stytchiversary; Nathan joined us a year ago as a product engineer.

We're celebrating another Stytchiversary; Nathan joined us a year ago as a product engineer. He's spent the past year focusing on our stytch.js sdk. Learn more about his experience as one of the first engineers at Stytch and his love of food.



What do you love most about working at Stytch?

I'm going to give a super unique answer here, the people here at Stytch make it such an amazing place to work. I've learned so much from the smartest people I've had the opportunity to work with.

What does a typical day at Stytch look like for you?

I would sum it up in some form of code + planning + learning!

What’s been the most surprising thing about Stytch?

How fast we've hired an amazing team! It's clear we have that appealing of a vision for Stytch.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

You gotta be on your toes and don't be afraid to stretch yourself. Wearing many hats is a great opportunity and you get to own a product that you get to push forward!

What’s your favorite part of the Stytch culture?

Collaboration. Stytch has the biggest emphasis on team culture I've seen. I've never been afraid to ask for feedback or help.

Which Stytch value resonates most with you and why?

Trust like it's Christmas 1914 - has the coolest name and is why we have such a great team. It feels everyone I work with has really bought into this and is willing to trust each other on technical decisions.

What’s the most interesting project you’ve worked on at Stytch?

As a product engineer, learning about AWS Cloudfront and web + browser caching was fascinating. The web is such a crazy place. And we're still learning about it today!

How did you end up becoming a software engineer?

I studied math and econ, but dabbled a little in programming in college. Once I started building web products as side projects, I was hooked! I also heard Silicon Valley had a lot of places with free food so that was added motivation.

When’s the last time you did something for the first time and what was it?

I made my own cold brew during the pandemic

What song, hobby, or recipe got you through COVID?

This is a very hard question. But Can I Call You Tonight by Dayglow was one of my COVID bops.

What’s your ideal weekend?

Relaxing at a coffee shop either reading or working or very likely doing nothing significant.

What’s something you’re passionate about that’s not on your resume?

All things food. I love to eat to the point where it changes my mood when I'm in a bad one. And if I could solve food insecurity I would!

---


# Stytch's guide to passwordless authentication
Source: https://stytch.com/blog/stytch-guide-to-passwordless-authentication/

Thanks to new tools and technologies, passwords are finally being replaced with more secure and convenient passwordless authentication flows like email magic links, SMS passcodes, OAuth logins, push notifications, and biometrics. 

Thanks to new tools and technologies, passwords are finally being replaced with more secure and convenient passwordless authentication flows like email magic links, SMS passcodes, OAuth logins, push notifications, and biometrics. These modern strategies enable developers to choose the most appropriate authentication options for their use case and user base.

One recent survey found that 75% of users feel overwhelmed trying to keep track of their proliferating passwords. A separate survey found that the majority of respondents would prefer authentication methods for their personal and professional accounts that don't involve a password—users are increasingly interested in going passwordless, but as a developer, it can be hard to know what passwordless authentication flow is right for your application.

The old refrain is that there’s a tradeoff between security and usability, but that no longer applies to authentication -- removing passwords can boost both security and the user experience. 81% of all internet breaches involve weak or stolen passwords, which is why the Open Web Application Security Standard (OWASP) now recommends that all passwords should be considered to be “pre-breached”.

As you begin designing your authentication flow, there are a myriad of passwordless options to consider due to recent innovations in authentication technology. In this guide, we examine many of the common passwordless methods to help you choose the right solution for your application. With each option, we’ll consider how the user experience, security, ease of implementation, and accessibility measure up, with the aim of striking the ideal balance between protection and ease of use.

The (r)evolution of authentication

While passwords have historically been the most common way to authenticate users, innovations over the past 15 years have yielded new authentication types that improve security and usability.

Historically, the dominant choice for authenticating users has been to have them demonstrate possession of secret knowledge (think passwords and PINs). This is the something-you-know authentication factor, and it presents many security and UX challenges.

Over the last decade, however, the rise of programmatic SMS/email, hardware keys, biometrics, and other authentication factors has created two new authentication categories:

Something you have—authenticating by proving possession of something (e.g. a mobile phone, email inbox, or hardware key)

Something you are—authenticating by proving a biological trait (e.g. a fingerprint or FaceID)

As a result of these innovations, we’re seeing major shifts in how companies choose to onboard and log in users.







In the 1990s, as the internet went mainstream, passwords were the dominant form of authentication.

In the 2000s, as users opened more and more accounts, password managers—which encrypt and store online login information—were introduced to help them handle this something-you-have authentication methods increasingly complex landscape.

In the 2010s, as online technologies advanced, alternative auth methods—often referred to as “two-factor authentication”—embedded low-friction, secure hardware (like biometrics and YubiKey) and software (like APIs for programmatic text and email) into the user experience.

In the 2020s, as we begin to embrace passwordless authentication, resourceful companies like Revolut, Medium, and Square Cash are leading the charge. Others like Slack, Instagram, and Craigslist have also started incorporating passwordless options, even if they haven’t fully discarded passwords yet.

Authentication types and tradeoffs

These new factors open up new UX possibilities, but they can also be a challenge for teams as they consider how best to tailor each to users’ individual, situational needs without compromising on protection or usability.

Each factor presents different tradeoffs. Let’s consider the relative advantages of each method of passwordless authentication, starting with those under the something-you-have umbrella.

Something-you-have authentication methods

SMS one-time passcodes

Designed with mobile phone/device owners in mind, short-messaging service (SMS) passcodes allow users to log in to applications using their phone numbers.

When a user requests access to an application or website, an authentication flow texts a one-time, numeric code to their device, which they can then enter—instead of a password—to log in. Thanks to the prepopulating, “autofill” feature on Android and iOS, users do not even need to enter the string manually.

SMS passcodes:

Help balance security and usability, because logins that tie users to a specific phone number are more secure than password-based authentication options. In fact, SMS messages are the most used second factor to access financial and personal websites.

Feature built-in redundancy, meaning that if programmatic SMS provider fails in the delivery process, we dynamically fail over to back-ups that can pick up the slack and quickly get the job done.

Allow flexible integration options, since Stytch’s flexible APIs make it simple to use this method as a primary factor or as a two-factor authentication choice to strengthen security.

While SMS passcodes are a great fit for many applications, they do carry their own unique risks. For certain high value accounts such as cryptocurrency wallets, fraudsters will go to extensive lengths to try to convince cellular networks to allow them to steal a legitimate user’s phone number. While this is a real risk, the effort and cost involved for fraudsters to mount this attack is significant, involving careful curation of an individual’s sensitive personal information and sometimes even outright bribery -- the difficulty involved in this attack is why it’s primarily been targeted at very high-value accounts like Coinbase wallets.

The response to this small risk should not be to discard SMS passcodes entirely. Instead, you should consider the value of the account you’re protecting and choose your passwordless options and any multi-factor authentication requirements accordingly. Large fintechs like Square Cash and Revolut effectively use SMS passcodes to protect even high value accounts by layering other 2FA methods alongside it such as biometrics or PINs.

Email magic links

Put simply, magic links let users log in to an application or website by entering a registered email address, clicking once on a submit button, and receiving a “magic” URL in their inbox, by clicking on the link they can instantly authenticate and log in. This action establishes that they have access to the email inbox. One click is all it takes to log in.

Email magic links can:

Reduce user friction by removing the hassle of remembering and storing passwords. It’s a simple, one-and-done login or authentication process, making it more likely that users will follow through with whatever they aim to do—whether that’s paying a bill, buying a product, or submitting a document.

Protect your application and users by eliminating credential stuffing attacks on your login flow and preventing account takeovers.

Authenticator app time-based passcodes

By requiring users to prove they actually have the device they are using to access a website, applications like Google Authenticator provide an extra level of security for critical and highly sensitive services. Differing from SMS passcodes, this type of passwordless authentication asks users to confirm control of their device within a certain time frame rather than requesting a phone number to gain access, which avoids the sim swapping vulnerabilities present with SMS.

Authenticator app passcodes:

Help facilitate secure transactions by requiring users to demonstrate control of their devices to execute sensitive transactions.

Offer the security features power users want -- if your application handles sensitive data, many sophisticated users will require authenticator apps in order to feel comfortable using your service.

Push authentication

Push authentication is a passwordless method that asks users to authenticate through notifications sent to an app on their mobile device. The one-tap feature enables users to quickly approve a notification, thereby gaining instant access to an application or website. They can just as easily reject a notification they do not recognize or one they did not initiate, which prevents unwanted parties from accessing secure content.

Push authentications:

Increase user retention by eliminating the need for users to remember or store passwords to access secure websites or applications.

Facilitate secure transactions in a manner similar to authenticator apps.

WhatsApp one-time passcodes

Another authentication solution that lets users avoid the traditional password, WhatsApp passcodes enable users of the popular messaging app to log in to secure applications from anywhere, at anytime. By integrating your authentication flow with WhatsApp, you can leverage a network of more than three billion existing users.

WhatsApp passcodes:

Increase the difficulty and cost of attacks like account takeovers.

Provide your users with a viable, alternative authentication option if regular text-message delivery is delayed or otherwise affected by a service outage.

OAuth logins

OAuth logins—which leverage industry standards like OAuth 2.0 and OpenID—help engineers easily integrate single sign-on options from popular social platforms and other third-party providers (e.g. Apple sign-in).

OAuth logins:

Help increase user sign-ups. In fact, most apps report a 20%+ conversion rise in sign-ups when popular OAuth options like Google, Facebook, Apple, Microsoft, and others are introduced. Newer OAuth features like Google’s One-Tap functionality offer even more eye-popping conversion boosts (Pinterest reported a ~50% improvement in web sign-ups and a ~125% improvement in mobile sign-ups when they incorporated this feature).

Balance security and usability by preventing users from creating a new password for your site that they might reuse and repeat across many services—this minimizes your risk of account takeover and credential stuffing attacks.

Flexible integration options -- Stytch allows you to integrate these options through either our front end SDK or our direct API if you’d like to fully own the UX.

Something-you-are authentication methods

The something-you-are category of authentication includes biometrics, including voice and facial recognition, and fingerprint scans.

Native app biometrics

You were likely first introduced to the concept of biometric authentication on your mobile devices when iOS and Android introduced the concept of fingerprint and facial recognition for native applications built on top of their operating systems. This method has become a popular way for banks, brokerages, and other sensitive applications to layer low-friction step-up authentication into user workflows.

WebAuthn

In the something-you-are category of authentication are biometrics, including voice and facial recognition, fingerprint impressions, and iris scans. WebAuthn (aka “Web Authentication”) falls partially under this umbrella, though it also supports something-you-have authentication methods like hardware keys as well. This passwordless authentication solution allows desktop and mobile browsers to verify users with built-in device biometrics as well as distinct, specialized hardware keys like YubiKey.

WebAuthn:

Can use biometrics to ensure a user demonstrates both possession of an original device and a unique biometric trait through face or fingerprint ID.

Offers your users best-in-class security by doubling down on verification while also minimizing user friction.

Allows you to easily integrate strong hardware authentication like YubiKey to protect sensitive applications and use cases.

What happens after authentication?

The above authentication methods detail how you can prove who a user is -- however, once a user has been successfully authenticated, you’ll likely want do a few things:

Keep the user logged in as they navigate different parts of the app

Occasionally escalate them up for additional verification (and friction) if they try to take a particularly sensitive action (like withdrawing funds or altering their account information)

Continually check throughout the user’s interactions whether they have sufficient permissions to take the action they’re attempting

Most of the above boils down to session management and how you manage your user’s logged-in experience. Session management regulates interactions between web-based applications and individual users. Stytch Sessions allow your users to easily implement sessions in a way that provides fine-grained control.

Stytch Sessions:

Offer countless advantages over JSON web tokens (JWTs) in terms of security and control.

Make performing route-based authentication simple, allowing you to precisely control the level of authentication that any sensitive action requires

Provide improved session security by allowing you to easily revoke sessions and protect against unauthorized access.

What authentication is right for your project?

Designing an authentication flow can seem overwhelming given the UX and security issues involved. When we help developers think through what's right for their authentication flow, there are three main questions we ask (you can always join our Slack community for more guidance):

1. What type of account data does your application protect?

There's a big difference in the level of authentication you need if you're a fintech/healthtech app, for instance, versus a news digest app.

For more sensitive applications like fintech + healthtech, we frequently recommend multi-factor passwordless authentication, which allows you to both balance UX and security. Square Cash, Monzo Bank, and Revolut are great examples of companies that weave together multiple passwordless options in order to protect their users.

2. Do users primarily engage your application via mobile, desktop, or both?

Conversion rates vary across these channels. For instance, SMS one-time passcodes perform extremely well on mobile due to their autofill capabilities but create slightly more friction on desktop than email verification. Companies that Square Cash and Hippo Insurance provide users with the option to choose what’s most convenient for them.

3. What's your current reset password flow, if any?

Some teams are hesitant about moving to passwordless authentication until we ask this question. Then they realize that they already allow users to log in without a password. The majority of reset password flows only require a user to demonstrate ownership of an email address or phone number—making them essentially passwordless. If you require a user to supply additional information during a password reset (e.g. some banks require the last 4 of your SSN), this can help in determining what level of user authentication you deem sufficient in allowing users to access your application.

Interested in learning more?







At Stytch, we worry about authentication so that you don't have to. If you want to discuss your specific authentication needs, sign up for a free account and chat with our team.

If you’d like to dive deeper into the topic of authentication, you can join the Stytch Slack community here.

---


# Engaging users with embedded authentication
Source: https://stytch.com/blog/engaging-users-with-embedded-authentication/

Today, we’re launching a new product, Embeddable Magic Links, to give you the option to own even more of your login and user engagement experiences.

Providing developers with the flexibility to build their own unique user experiences is fundamental to how we think about building products. Today, we’re launching a new product, Embeddable Magic Links, to give you the option to own even more of your login and user engagement experiences.

Over the past year, we’ve introduced numerous features that make it easier to onboard and authenticate users, including SMS, email, and WhatsApp one-time passcodes as well as email magic links and OAuth logins.

Embeddable Magic Links are a massive step forward in helping us achieve our mission of eliminating friction on the internet. This feature moves beyond the templated sign-up, login, and invitation magic link emails that we currently power for customers. Those existing templates allow us to abstract away a lot of complexity for customers when it comes to email deliverability, latency, and inbox placement. However, it also limits customers’ ability to craft new and inventive ways to take advantage of all magic links have to offer, including the ability to embed them into product experiences such as email and text communications with their users.

What are magic links and what’s the value in making them embeddable?

First, it’s helpful to align on what magic links are and what makes them special. At their core, magic links are high-entropy tokens that are appended to URLs to enable new authentication experiences. To use these tokens to power logged-in experiences, you generate a unique, temporary token for an individual user (e.g. exampleuser1@gmail.com) whenever they’re trying to access their account. The ingenuity of magic links comes from the fact that they offer significant security while also enabling “magical” user interactions where the end-user doesn’t need to take additional actions beyond clicking a link (or button).

By embedding magic link authentication into existing user workflows, such as when a user casually navigates the messages within their email or SMS inbox, we have an opportunity to significantly improve the way we engage with users on the web.



The value of embeddable magic links is best illustrated by considering the user experience that their absence creates today -- think about the many different emails your apps and accounts send you on a daily basis, including things like:

A promotional email from your favorite clothing brand offering 10% off

An email with a link to view your bank or credit card statement

An email from an e-commerce store about your recently abandoned cart

A reminder from a grocery delivery app to repeat your weekly purchase

Today, if you click through the various examples like the above in your inbox, the vast majority of the time you’re likely to encounter a logged-out experience. You’ll be asked to sign in with a password you’ve likely forgotten, often forced to choose between abandoning completely or enduring a frustrating password reset process. This interaction similarly frustrates businesses because it leads to a high-intent user abandoning their funnel.

We don’t have to live like this anymore. Today, we’re underutilizing the fact that whenever you click on one of these emails or texts, you’re entering the application from an authenticated inbox (e.g. your email or phone). Embeddable magic links offer a way to associate a user clicking a call-to-action button with an existing account -- with this context, you could either directly log the user into their account or simply use that information to determine the marketing persona of the user engaged within your application to power customized recommendations. Here's how this flow works with Stytch:



Stitching it all together

Embeddable magic links become even more powerful when used in conjunction with other Stytch products because it allows you to right-size the amount of authentication security depending on the level of access you’re providing to the user that has clicked through the embedded magic link. (Check out the guide in our docs to see how you can augment this product with our other features)

In many cases, an embedded magic link alone should suffice for your use case. If the user is coming from a recognized device, you could provide them with full account access. Alternatively, regardless of where they’re coming from, you could instead choose to treat the user as a persona used for marketing purposes and customize general recommendations rather than directly grant account access.

While embeddable magic links are great tools, they’re not invincible. Scenarios where you’ll want to be more careful involve situations where a user clicks an embeddable magic link from an unrecognized device. In these cases, there’s additional risk you’ll want to consider when determining the adequate account protection. It’s possible the user has forwarded their unique embedded magic link to a friend (or an attacker trying to phish them). To safeguard against these instances, you can consider the following options:

Ask the user to complete another low-friction authentication method such as a SMS one-time passcode (on mobile, this is especially low-friction due to iOS and Android auto-fill capabilities)

You can take a route-based approach to authentication where you distinguish insensitive read-access from more sensitive write-access capabilities. You could withhold two-factor authentication until the user attempts to take a more privileged action. For example, with Stytch’s sessions product, you can set a session when the user clicks the embedded magic link and then escalate them later in the session whenever you want to upgrade their session (for example, if the user tries to change their saved shipping address when checking out or view sensitive information).

How to use it

You can check out the new product here. When you’re ready to start testing it out, you can reach out to us at support@stytch.com to enable the feature. We’re always willing to provide guidance and input on best practices for implementing embedded authentication like magic links.







---


# The ultimate guide to building user authentication into your Next.js application
Source: https://stytch.com/blog/the-ultimate-guide-to-building-user-authentication-into-your-next-js-application/

Next.js is a popular React framework and we’re in the process of migrating our main stytch.com website to Next.js because of the developer experience and performance wins.

Next.js is a popular React framework and we’re in the process of migrating our main stytch.com website to Next.js because of the developer experience and performance wins. We’re thankful to benefit from the Next.js ecosystem for our own product and wanted to open source that work.

Building user signup and login can be a frustrating task, especially when you just want to focus on building your core product. Stytch makes it easy to build user authentication, we offer flexible SDKs and APIs so that you can own your UX and let us do the heavy lifting.

In this tutorial, we’ll walk through building a Next.js app with Stytch for user authentication. We’ll be using this example app to show you how you can use our API integration to build user sign up and log in with SMS one-time passcodes.

Create your Next.js app

It’s simple to get an app up and running using create-next-app. You’ll need to have the Next.js cli installed if you don’t already, instructions on that here. Then you’ll want to run:



Now you’ll want to run the following command to install all of your dependencies:



Your app is now ready for you to get started. Follow the instructions printed in your terminal to cd into your app and then start it in development mode with:



Setting up Stytch

To start, you’ll need to have a Stytch account, you can sign up here. Next, you’ll need a .env.local file. You can copy our template here. For the purpose of this guide, you only need to fill out the STYTCH_PROJECT_ID and STYTCH_SECRET env variables, which you can find in the Stytch Dashboard API keys tab.

Sending and authenticating SMS One-time Passcodes(OTP)

One benefit of Next.js is that it supports creating backend API routes under the pages/api/ folder. These routes are made accessible at <your domain>/api/<route name>.

In this guide we will leverage Next.js API routes and the Stytch API by using the Stytch Node client library. Start by installing the client with:



In order to use the Stytch Node client library, your app needs to instantiate a Stytch client. In our example project, we created a utility function to do this for you under lib/loadStytch.ts, as long as you created your .env.local file above, you don’t need to do anything else here.



Next, we created an API route called send_otp under pages/api/. This endpoint will be available at <your domain>/api/send_otp (e.g. http://localhost:3000/api/send_otp) and will take a phone number in +1XXXXXXXXXX format in the request body. Using the Stytch client, call the otps.sms.loginOrCreate method. This will send a text to the provided phone number with a OTP. The otps.sms.loginOrCreate method also returns a methodId; return and keep track of this methodId as it will be required for the authentication endpoint later. You can take a look at how we built our send_otp endpoint here.



Finally, we created an authentication endpoint called authenticate_otp under pages/api/. This endpoint will be available at <your domain>/api/authenticate_otp and takes the methodId from the prior send_otp response and the user supplied otpInput(the six digit OTP sent to the user’s phone). Using the Stytch client, call the otps.authenticate method, if the response status is 200, the user has successfully authenticated! You can take a look at how we built out our authenticate endpoint here.



Now that you’ve set up your authentication API routes, it’s time to build a UI!

Building your login page

In addition to API routes, Next.js also automatically converts all remaining files under the /pages directory into page routes in your application. To add your login page, directly edit the pages/index.tsx file.

For your login UI, you will want to create two separate forms. One for the user to enter their phone number (which will send them an OTP), and the other for the user to enter and verify their OTP. You can take a look at the examples we’ve built for both at SendOTPForm.tsx and VerifyOTPForm.tsx. Here’s an example of how you can tie these two forms together for your log in flow, see LoginWithSMS.tsx:



Finally, you will want to create a logged-in page that the VerifyOTPForm can push to once a user has been successfully authenticated. You can see our logged-in view here and what it looks like below:



Once you’ve created the login UI and your logged-in page, you are now ready to hook up your components to your API routes. Below is a diagram of what the user authentication flow should look like:



Congratulations! You’ve successfully used the Stytch API in Next.js to build user sign up and log in with SMS OTP.

What's next?

Stytch is a platform for user infrastructure, we offer many more options when it comes to your user authentication. Explore more ways to authenticate, including email or embeddable magic links, email or WhatsApp OTP, and OAuth in our Docs!









---


# Alex Zaldastani
Source: https://stytch.com/blog/alex-zaldastani/

We’re so excited to celebrate another Stytch-iversary with our very own, chess-loving, Switch playing, book-club leading engineer, Alex Zaldastani! 

We’re so excited to celebrate another Stytch-iversary with our very own, chess-loving, Switch playing, book-club leading engineer, Alex Zaldastani! As our team continues to grow, we look forward to sharing more glimpses into our culture at Stytch through the eyes of the folks who help build it and know it best. Meet Alex!



What do you love most about working at Stytch?

My coworkers! Everyone is intelligent, considerate, and excited to shape Stytch's culture. They make it easy to collaborate and get unblocked. A close second – we have great lunch food.

What does a typical day at Stytch look like for you?

It really depends what stage of a project I'm working on. I've spent the last year building a lot of features from zero to one. So one day could be spent specing a solution by having lots of conversations with other engineers and getting feedback. Or it could be spent doing lots of heads down coding, bugbashing, and shipping.

What’s been the most surprising thing about Stytch?

Our growth! I've always felt confident about it, but didn't think it would be this fast. It's been rewarding recruiting and growing the company with hires who care about our work and social culture.

What’s your favorite part of the Stytch culture?

My favorite part of work culture is our communication. The team is great at speaking up or giving feedback. Our focus on communication has definitely helped us scale.

Which Stytch value resonates most with you and why?

Design for the future; build for the present. It's been at the forefront of my decision making while building out our MVPs the last year.

How did you end up becoming a software engineer?

I really like math and logic. Software Engineering seemed like a field where I can scratch my logical problem solving itch while working at cool, new, impactful companies.

When’s the last time you did something for the first time and what was it?

Rocked a middle part at a costume party. I went as Nick Dean from Jimmy Neutron.

What song, hobby, or recipe got you through COVID?

Definitely chess. I knew I liked turn based games and I'm surprised it took me so long to start playing chess. I love playing the Legal's Mate and the Fried Liver Attack. Also – I got into chess before Queen's Gambit, I promise.

What’s your ideal weekend?

A mix of dancing, games (board, video, or other), tennis, and food. Saturday mornings almost always include a breakfast sandwich from either Bandit or Devils Teeth.

What’s something you’re passionate about that’s not on your resume?

I really enjoy reading. My favorite authors include Haruki Murakami, Brandon Sanderson, and Cixin Liu (author of the Three Body Problem trilogy, a must).

---


# Designing for dark mode
Source: https://stytch.com/blog/designing-for-dark-mode/

How I designed the Stytch website with developer experience in mind.

How I designed the Stytch website with developer experience in mind

In November 2020, Stytch hired me to redesign their website and create a visual identity for the brand. It was crucial to the team that the website and the brand experience appeal to Stytch’s target audience of developers—which is how my journey into dark mode began.

Simply put, designing for dark mode involves creating a dark background with light text and images (like white on black) rather than a light background with dark text and images (like black on white).



For developers constantly viewing minuscule code, dark mode is not only easier on the eyes, it helps them concentrate for longer periods of time. That’s why some surveys have found that a majority of developers—about 70%—prefer dark themes to light ones. As an added benefit, dark mode drains less battery power over time, ultimately reducing a device’s energy consumption.

As I revamped the Stytch website for dark mode, I worked closely with our lead product designer Bingrui Tang to ensure my designs worked equally well across Stytch’s products, so there would be a seamless transition from one platform to another.

Here are a few things I learned—and a few tips I picked up—along the way.

Designing in dark mode is less common than you might think (or hope).

As I began my research, I couldn’t find any examples of other companies that cater to both light and dark mode on their website. While it’s common to encounter a dark mode setting among a company’s products, it’s rarely seen in their branding or on their homepage.

I quickly pivoted to reading articles on dark mode instead. I found Google Design’s “How to design a dark theme using Material'' and Chethan KVS’s “The ultimate guide on designing a dark theme for your Android app” to be helpful entry points in understanding the basics of dark mode and learning to design within it effectively.

Designing in dark mode first—and then in light—streamlines the process.



It’s hard for designers to think about the same UI in different configurations, and designing in light and dark modes at the same time can be confusing. On the other hand, when an entire website is already set in light mode, reversing it to dark can take a lot of work—especially as a company grows and its pages and content proliferate.

I found that it was easier to complete one mock-up at a time and that transitioning to light mode was much simpler and more intuitive than transitioning to dark. So I tackled each component—for example, the Stytch homepage—in dark mode and then translated it to light, ironing out the process as I went and saving myself a lot of time and effort.

Drop shadows that work in light mode don’t necessarily work in dark mode—and vice versa.



Because it’s difficult to discern shadows against dark backgrounds (as opposed to light), I had to create custom drop shadows as I designed for dark mode—and to add semi-transparent overlays on top of the images and behind the text.

This layering added contrast between surfaces and their shadows, which resulted in more readable elements and allowed the UI to stand out.

Exploring how your brand colors transition between light and dark mode helps create a cohesive and impactful design.











Maintaining a distinctive, consistent color scheme is key to communicating your brand’s identity across UIs and mediums. That may mean tweaking your design standards to include one or two of your brand colors—instead of the whole palette—as you transition from light to dark mode.

Keep in mind that traditional black and grey backgrounds can feel dark and heavy—but they’re not the only option.

For Stytch, I chose a cool, deep blue for our dark mode theme to mix it up and try something a bit different. It’s worth experimenting with a variety of alternative background colors and configurations while staying true to your brand flavor to see which has the crispest definition and best showcases your content in dark mode.

If designing for web, do an early accessibility and responsiveness test so you don’t have to rework your dark mode system before development.



When selecting a dark mode color scheme, I was initially drawn toward white on black as an easy and accessible option. When I transitioned to blue, that meant going in and testing lighter shades of type to make sure they stood out—and occasionally picking darker or lighter hues on either side to ensure maximum readability.

When it comes to dark mode, it’s also important to build out mocks in both desktop and mobile (known as responsive design) to see how dark your colors become at a smaller scale. Keep in mind, a color scheme can change dramatically depending on the amount of space it fills. Generally, the smaller the space, the darker the appearance. I found this tool to be very useful as I mastered these proportions.

Key takeaways

Designing in dark mode is a great way not only to delight developers but to communicate that you care about your users’ experience.

I hope the lessons I took away from setting up Stytch’s website for dark mode can be a helpful resource for other designers in the field and set them up for success.

Check out the website in both modes



Mac users: System Preferences > General > Appearance
PC users: Settings > Personalization > Colors

Our design team is growing!

Interested in bringing your skills to Stytch? Check out our open product design position.

---


# Building an app with Stytch and PlanetScale
Source: https://stytch.com/blog/stytch-planetscale-integration/

Building an app with Stytch and PlanetScale

PlanetScale

PlanetScale is a serverless database platform. PlanetScale was founded in 2018 by the co-creators of Vitess, the same database that has enabled products like Youtube to reach planet-scale. PlanetScale removes the complexities of manually scaling a database by providing a serverless DBaaS. The PlanetScale platform allows developers to branch their database, similar to what you would do with Git. Database branching enables developers to perform non-blocking schema changes, among other things.

Stytch

Building user signup and login can be a frustrating task, especially when you just want to focus on building your core product. Stytch makes it easy to create user authentication; we offer flexible SDKs and APIs so that you can own your UX and let us do the heavy lifting.

What we’ll do in this post

This tutorial will walk you through how to create a lightweight user dashboard that utilizes Stytch and PlanetScale for authentication. All of the code for this example app is hosted and maintained in our public GitHub.

Getting started - Mise en place

Building an app is easier when you’ve got everything you need already laid out and ready, so let’s get all of the requirements out of the way! We’ll walk through the following in this section:

Gathering your PlanetScale and Stytch API keys

Installing PlanetScale’s CLI

This guide assumes you have Node.js and NPM installed on your system. You can find instructions on how to do so here.

Retrieve API key from the respective dashboards

Stytch API keys

Create PlanetScale service token



Installing PlanetScale’s CLI

Check out the instructions here to install PlanetScale’s CLI, pscale, for your operating system.

The pscale shell is an interactive shell for your database. Think of it as a MySQL shell that lets you directly operate on your PlanetScale database.

Creating and configuring your PlanetScale database

Create your PlanetScale database



Create your first branch



Think of your branch as an isolated copy of your database created with the current production schema. Branches can be used to develop features and test changes without impacting your production database.

Connect to your branch and create your table





This query will create your users table where you’ll store a record for each user that is created.

Create a deploy request, deploy and merge



Deploy requests enable teams to collaborate and review changes before deploying them.

Create your backend

If you’re not familiar with Next.js, this is a good companion blog post covering some of its features and benefits. Before getting started, make sure that you’ve set your environment variables inside your .env.local file.

Setup the APIs to connect to PlanetScale

Establish a connection to the PlanetScale main branch using the planetscale-node library, then inside of pages/api/ create the functions to add, remove, and get users from the DB.



Setup Stytch Email Magic Links

Instantiate the Stytch client via our stytch-node client library; you’ll use this client to make any calls to the Stytch API.



We would like to be able to invite and add new users to our dashboard, we'll leverage our stytch-node client library to send Email Magic Links to users to do that.



Next you’ll want a way to authenticate the magic links that are being sent by the Stytch SDK.



Setup user sessions

Now that we’ve got authentication in place, what happens when a user leaves and then comes back? We want that returning user to come back to an authenticated experience, so we will use Stytch’s Session Management API to make that happen.

We will start by creating a session helper that will validate the tokens exchanged through the cookies.



Add this session helper to each DB handler so we can prevent unauthenticated API calls.



Now we’ll want to add logic to clear the client state once a session has expired. Doing so will allow us to gracefully re-prompt the user to log in when their session expires; when we initiated the session, we chose a session_duration_minutes of 10080 minutes, 7 days, so that users won’t be prompted to re-login if they return within that 7 day period.



Backend complete

You just finished all the critical backend components in our example. With the backend complete, your app can now login with Stytch Email Magic Links, manage sessions via Sessions Management, and maintain your user database via PlanetScale.

Give our Stytch + Planetcale example app a try to see what the frontend experience is like as a user!

We can’t wait to see what you build with Stytch! Get in touch with us and tell us what you’re building in our Slack community or via support@stytch.com.





---


# A guide to passwordless authentication solutions by business vertical
Source: https://stytch.com/blog/guide-to-passwordless-authentication-solutions-by-vertical/

You’ve just decided to go passwordless (an excellent choice), and now it’s time to figure out which passwordless authentication solution is right for your business.

You’ve just decided to go passwordless (an excellent choice), and now it’s time to figure out which passwordless authentication solution is right for your business. There are many options on the table, including email magic links, SMS one-time passcodes, WebAuthn, OAuth, and multifactor flows using a combination of these methods.

To help you navigate options, we’ve compiled years of experience and expertise building passwordless authentication solutions (at both Stytch and Plaid) into a simple guide.

Essentially, which method you should choose comes down to two basic questions:

What are the security requirements for your app given the sensitivity of the user data you work with? And,

Who is your target audience, and how do they engage with your product?

Below, we break these points down one by one and explore how they play out in different business scenarios and use cases.

Keep in mind, while we use specific verticals we’ve worked with as examples—including e-commerce, fintech, healthcare, B2B SaaS, and B2C tech—our recommendations apply across industries and for a much wider swath of businesses.

User data sensitivity and security requirements

First, consider the following questions:

Are you involved with storing or handling sensitive customer data?

Are you in a heavily regulated industry?

Do you consider your industry to be vulnerable when it comes to fraud and cybersecurity attacks?

If you answered “yes” to any of the above, then you’re among companies like fintech, healthcare providers and government agencies that access sensitive user data such as bank account information and medical records.

Industries like yours tend to be highly regulated and allow customers a wide range of activities, from facilitating mobile transfers and cryptocurrency trades to scheduling and accepting payments for medical procedures. Security is likely a top priority for your business, and you should opt for higher-friction methods of authentication (we’ll get into what that means later in the guide).

If you answered “no” across the board, you’re likely operating in a highly competitive, crowded B2C market like e-commerce, media, entertainment, or edtech.

You might face challenges related to rising customer acquisition costs, high cart abandonment rates, and low account creation and user engagement. But overall, you access less sensitive data, and—while security is still a priority—your primary focus is on maximizing customer conversion. You’re better off building a low-friction yet secure passwordless authentication experience, which can help move the needle when it comes to succeeding in competitive B2C markets.

How your target audience engages with your product

There are hundreds of ways you can segment your audience, but when it comes to authentication, there are two key factors to consider:

Audience demographics (namely age) and

Behavior related to mobile and desktop device usage

These two data points are strong indicators of how your audience will interact with your application. They’re also often correlated. For example, research has shown that people below the age of 25 use their phones more frequently and are likely to have them in close proximity at all times.

Depending on whether you offer a desktop- or mobile-first product—and whether your customers are likely to have their phones nearby while going through your onboarding flow—your path to building a great user experience and maximizing conversion can vary significantly.

Toward that end, we’ve put together a helpful graph that plots common verticals along axes related to data sensitivity and audience reach. While this simplistic view won’t capture all edge cases, it’s a helpful starting point when evaluating your authentication needs:





Taking this a step further, we’ve also plotted the most popular passwordless authentication methods using similar criteria:





While passwordless authentication options are unquestionably more secure than password-based authentication (and thereby suitable for businesses that have access to all types of sensitive data), you can further distinguish them into remotely accessible (e.g. SMS, email) and device-tied factors (e.g. mobile biometrics). Remotely accessible passwordless factors are typically used for primary authentication, while device-tied factors are considered even more secure and are typically used for 2FA.

Another thing to keep in mind when choosing one or several passwordless authentication solutions is that methods are often designed with specific users in mind. For example, as you can see in the above matrix, SMS and authenticator app passcodes are designed for mobile-friendly applications, while email magic links and WebAuthn make for great user experiences via desktop.

You can read about each passwordless authentication option in detail in our comprehensive guide to authentication.

Now that you have a sense of how both your business and popular passwordless auth methods measure up when it comes to security and audience, let’s explore our cheat sheet on the best passwordless authentication solutions for each vertical:





We developed this data over more than two years of research and conversations with customers and leads, and we’re excited to share it publicly to help make your authentication journey easier.

Before we dive into our specific recommendations, it’s worth reviewing a couple general tips that apply across verticals:

While MFA is your friend, we recommend introducing friction only when truly necessary using just-in-time authentication.

Don’t be afraid to let your audience choose how they want to be authenticated. Take Square’s Cash App as an example -- they let their users decide whether they want to sign-up/login with their email or phone number.

In the following sections, we’ll go vertical by vertical and take a closer look at how we arrived at each recommendation.

Fintech and digital healthcare

Objective: Maximize security while maintaining higher conversion rates compared to password-based authentication

For mobile-first, consumer-facing applications in fintech and healthcare, we recommend a low-friction yet secure authentication method as a primary factor and a much higher friction authentication method in an optimized 2FA flow.

Specifically, we recommend SMS one-time passcodes as a primary authentication method—or WhatsApp passcodes if your target audience is outside North America. Using SMS/WhatsApp one-time passcodes for primary authentication will help you achieve a 50%+ increase in conversion versus password-based methods (due to the auto-fill capabilities of iOS and Android) while still offering the security benefits of preventing password re-use and the associated account takeover risk. OAuth login options like Sign in with Google + Apple can also be great primary authentication options given their ease of use and the ways users frequently secure those core accounts.

For your secondary authentication method, we recommend using mobile biometrics or an authenticator app like Google Authenticator.

For desktop-first applications in fintech and healthcare, we recommend a combination of low-friction yet secure passwordless sign-up or login flows. These could include email magic links or OAuth for primary authentication and authenticator apps or WebAuthn for 2FA.





Note: The brands in the above and below tables use passwordless authentication methods for either primary authentication or 2FA.

E-commerce and B2C tech

Objective: Maximize customer conversion through a low-friction yet secure passwordless authentication experience

Similar to fintech and healthcare, for mobile-first e-commerce and B2C tech applications, we recommend a low-friction yet secure authentication method such as SMS or WhatsApp one-time passcodes. Again, OAuth login options like Sign in with Google + Apple can also be great primary authentication options given their ease of use. If it’s necessary to add 2FA for your use case, use mobile biometrics or a relatively low-friction PIN verification method.

For desktop-first applications, we recommend introducing a combination of low-friction, high-security passwordless user sign-up or login flows. These could include email magic links or OAuth for primary authentication and SMS or WhatsApp passcodes for 2FA.





B2B SaaS

Objective: Strike the perfect balance between protection and ease of use for B2B customers

For desktop-first B2B SaaS applications—which comprise the majority of this industry—we recommend a combination of low-friction, high-security passwordless sign-up or login flows. This could include email magic links or OAuth for primary authentication and either authenticator apps or SMS passcodes plus WebAuthn for 2FA, depending on how much friction you want to introduce to your user onboarding flows.





Continuing your authentication journey

Once you’ve built your user onboarding flow, that doesn’t mean your authentication journey is over. In fact, authentication will underpin and impact all user interactions with your application moving forward—so why not get creative with your solutions?

With embedded authentication methods, you can create smooth user experiences by weaving authentication solutions seamlessly into all interactions with your app. Stytch offers several options, including:

Embeddable magic links which embed authentication into any customer communication channel—including SMS, email, and WhatsApp—to always provide a logged-in experience to your users

Embeddable OAuth solutions which embed authentication methods like Google Sign-In directly into customer communications

Learn more about our passwordless authentication solutions

Looking for more information on the passwordless methods mentioned in this guide?

Jump into Stytch’s API docs to get a closer look at our industry-leading products—or join our Slack community to chat with fellow engineers.







---


# Announcing Stytch's $90M Series B at a $1B Valuation
Source: https://stytch.com/blog/announcing-series-b/

Announcing Stytch's $90M Series B at a $1B Valuation

We are thrilled to announce Stytch has raised a Series B valuing the company at $1 billion. The funding was led by Coatue, with participation from existing investors Benchmark, Thrive, and Index.

When we were at Plaid, we witnessed the shortcomings of passwords first-hand, both from a security and usability perspective. We saw how often users gave up when the authentication process was too hard, and for all the friction passwords introduce, they still leave users vulnerable to account takeover attacks.

User experience and security have both evolved over the past few decades, but authentication is stuck in the 1990s despite underpinning all of our online interactions.

That’s why Stytch was born - to make the next generation of authentication passwordless.

We believe in building tools and infrastructure that make it easier, faster, and safer to embed authentication into apps and websites. We’re making it easy to modernize your authentication flows and build great user experiences by adopting passwordless technologies.

The traditional approach to authentication ignores the significant downsides of passwords. 66 percent of users reuse passwords across different accounts, posing a significant security threat and creating larger breach liabilities. It’s no surprise that 81 percent of all internet breaches stem from weak or stolen passwords. At the same time, we're constantly forgetting and resetting them. When users forget their password, about 75 percent give up and don’t complete the reset process. Similarly concerning, 46 percent of users report password authentication “frequently” or “very frequently” prevents them from completing an online transaction, costing businesses money and users.

Passwords are a headache for companies and users alike, but it doesn’t need to be this way. As the web continues to evolve, there’s a future in sight where authentication is blended into product experiences in a way that introduces the right amount of friction at the right point in time. The future of authentication will be more consumer-friendly, providing users with the ability to seamlessly move their data and credentials across the web while choosing the privacy settings that fit their needs. The evolution of the wallet in Web3 presents a compelling initial concept here, but there’s still significant work to be done to make this usable en masse for both developers and users alike. Stytch is building the future of authentication, whether that be for traditional Web 2 applications or a new generation of Web 3 applications.

Today, we have more than 3,500 developers building on the Stytch platform adding email magic links, SMS and WhatsApp passcodes, OAuth connections, one-click user invitations, and embeddable magic links into their user onboarding and login flows. In addition to these core passwordless features, we’ve seen companies of all sizes drawn to the simple developer experience and the flexibility offered by our API-first approach, including a few Fortune 500 companies that are using the product.

It’s still early days for Stytch and passwordless authentication; with the new funding, we’re going to focus on growing our product suite to accelerate the transition to a passwordless future We’re creating new possibilities when it comes to user engagement by enabling companies to weave authentication into their product experiences with new products like Embeddable Magic Links.

We are also excited to announce today our acquisition of Cotter, a leading no-code passwordless authentication platform backed by YC. We believe this combination can bring our vision of a passwordless world faster by making it even easier for developers to adopt passwordless technologies.

The future of authentication is here, and you can get up and running with Stytch today. Sound like something you want to also get behind and want to build with us? Check out our open positions.

Julianna and Reed

---


# Improving conversion with Google One Tap
Source: https://stytch.com/blog/improving-conversion-with-google-one-tap/

Today, we’re excited to launch support for Google One Tap, a passwordless technology that can significantly improve sign-up and login conversion for applications.

Today, we’re excited to launch support for Google One Tap, a passwordless technology that can significantly improve sign-up and login conversion for applications.

Google One Tap is a particularly powerful way to improve onboarding and login flows, and companies that have done the heavy lifting to integrate it have observed impressive results:

Pinterest saw a 47% conversion increase in sign-ups on desktop and a 126% conversion increase in sign ups on Android

Reddit was able to roughly double their new user sign-up and returning user conversion rates

Combined with other improvements to their onboarding flow, Zapier was able to increase conversion by ~20% in a B2B context

Tapping into better conversion rates

With countless eye-popping conversion results, what is Google One Tap and how does it actually improve conversion?

Google One Tap is a technology from Google that improves upon their traditional OAuth option for “Sign up with Google” -- instead of a user choosing to sign up with Google to initiate an OAuth login flow, Google One Tap is able to detect a user’s logged-in Chrome or Gmail session and present the option to continue with one of their recognized accounts.



Google One Tap introduces two fundamental changes to the user experience:

It actively primes the user to sign up, nudging them into the onboarding funnel by indicating how easy it is to get started.

Often when a user lands on a website, they are still in the decision-making process of whether they want to use this product. If they’re convinced of the value of the product, they may choose to “sign up”, being redirected to an onboarding form.

Google One Tap provides you with the ability to present a powerful nudge to the recognized user anywhere on the site and at any point. For example, you could display the One Tap option at a certain point in the scroll, on a time delay, or immediately upon the user landing on the site.

In addition to making it more likely that a user chooses to initiate the onboarding process, the expedited One Tap process also cuts out an entire step in the sign-up process for the user. In this flow, the user won’t receive the traditional Google Sign In pop-up asking them to choose which Google account they want to connect.

Zapier does a great job of illustrating the UX differences between regular “Sign In with Google” and Google One Tap in their blog post on the subject:



How does Google One Tap work?

Google One Tap is powered through an iframe that Google provides compared to the traditional OAuth flow of redirecting the user to a separate Google page. As a result, the available accounts are displayed within a developer’s application, and the user clicks their desired account to login or create an account. Hence, a “One Tap” experience.

The Google iframe detects the available accounts by reading the Google sessions from cookies stored in the user’s browser. These sessions are set by Google when a user signs into Google or a Google service (i.e. Gmail or YouTube). Since Google allows users to sign into multiple accounts, each account gets its own session, and Google One Tap shows up to two as options. If a user has more than two accounts, Google One Tap hides the rest behind a dropdown button.

When a user clicks their desired account, Google starts the authentication process. If the user is signing up for the first time, the One Tap iframe gets the consent of the user, otherwise signing them in immediately. Google returns a JWT representing that user, and the developer is responsible for verifying that the JWT is signed and valid. If the JWT is sent to a backend server, the developer is responsible for preventing CSRF attacks.

Stytch offers Google One Tap through a streamlined integration with the JS SDK. This allows developers to focus on creating a delightful experience instead of worrying about authentication and security. The JS SDK allows developers to either embed the Google One Tap Iframe into the SDK like Zapier or have it as a floating window like Redfin (Make sure you aren’t logged in!). The JS SDK captures the login event and forwards the user to the Stytch API to verify the response. The API handles the CSRF protection and JWT verification for the developers as a part of the verification process before redirecting the user back to the login or sign-up redirect URL for that application. At that point, the developer verifies the Stytch request and can request a Stytch session.

All of this work can be enabled through a single line of additional code and minimal configuration in the Stytch dashboard. Google One Tap is supported across all major browsers except Safari.

Going Passwordless with Stytch



Stytch is a platform for passwordless authentication that supports high security and low-friction authentication methods like Google One Tap. If you’re interested in integrating One Tap or other Stytch products like biometric authentication, email magic links, OAuth logins, or SMS passcodes, you can sign up for a developer account here to get started or reach out to support@stytch.com.






---


# An introduction to WebAuthn
Source: https://stytch.com/blog/an-introduction-to-webauthn/

“WebAuthn” is one of the most exciting passwordless technologies available to developers and users.

An example of the WebAuthn user flow on mobile or desktop. WebAuthn makes it easy for users to authenticate with device biometrics (e.g. FaceID/TouchID) or a hardware key like a YubiKey.

“WebAuthn” is one of the most exciting passwordless technologies available to developers and users. With WebAuthn, experiences like the below are now possible, allowing applications to authenticate users with the biometric capabilities built into the devices they use every day:

Historically, integrating WebAuthn has been a complex and time-consuming activity for developers. Stytch now supports the WebAuthn protocol, so that developers can embed this feature in minutes rather than months.

So, what is WebAuthn?

Technically speaking, WebAuthn is a web standard that allows web-based applications to leverage public-key cryptography to authenticate users online.

That’s a mouthful, so let’s break that down. In layman's terms, WebAuthn provides users with two highly secure yet low-friction options for authenticating themselves with mobile and desktop web applications -- when applications integrate WebAuthn, they can give users the option of using either of the following authentication methods for accessing their account:

Built-in device biometrics such as TouchID or FaceID

When using this authentication method, you’re both verifying possession of the user’s original device and biometric proof in the user’s facial ID or fingerprint. This is also referred to as a “platform authenticator” because it’s tied to the device.

Hardware keys such as YubiKey

This is referred to as a “cross-platform authenticator” because, unlike platform authenticators that are tied to a particular device, the hardware key can be moved from one device to another and retain your authentication method.

What are WebAuthn’s advantages over existing authentication methods?

Historically, when signing up for or logging into online accounts, users are asked to set up a username and password as their primary authentication method for accessing their account (of course, we’d contend there are much better primary authentication factors than passwords).

Due to the prevalence of password re-use and how it contributes to stolen accounts, most applications will now also ask users to go through a two-factor authentication flow. Often, users get one or multiple of the following options for two-factor authentication:

Security questions (e.g. what is your mom’s maiden name?)

This is considered to be a low security form of 2FA because the information used to authenticate the user is often public information.

SMS verification (e.g. receive a 6-digit one-time passcode over SMS)

This is a medium security form of 2FA. A motivated attacker may try to steal a user’s phone number or trick the user into passing along their passcode to the attacker. While it’s much better than password-based authentication or security questions, it’s by no means invincible.

Time-based one-time passcodes aka TOTP (e.g. enrolling with an app like Google Authenticator or Authy)

This is a higher security form of 2FA. TOTP eliminates the risk of someone stealing your phone number because the authentication method is tied to a user’s device. However, a user could still be tricked into accidentally sharing their passcode with a bad actor.

While TOTP is the safest 2FA method on the above list, many applications do not offer it as an option because of the friction it can create for users. Every user with a phone number can receive a SMS one-time passcode, but TOTP requires the user to download a dedicated app like Google Authenticator to enroll and use this 2FA method. As a result, many applications don’t support TOTP, and when they do support it, a large portion of users will still opt to use SMS passcodes for two-factor authentication.

WebAuthn is an extremely compelling authentication method because it is both more secure and lower friction than the 2FA options listed above, encouraging users to adopt it over less secure methods. And unlike TOTP, users do not need to download anything or potentially use multiple devices to complete one login to use WebAuthn. They can simply use the TouchID on their computer or the FaceID on their mobile phone like they already do multiple times per day to log into their device. An additional benefit of WebAuthn is that it prevents the “phishing” of users because there are no passcodes for the user to expose to an attacker. This is why some refer to WebAuthn as “unphishable multi-factor authentication (MFA)”.

Why aren’t we all using WebAuthn?

So, if WebAuthn is so groundbreaking, why isn’t every website already using it? We expect a large number of apps will begin to integrate WebAuthn in 2022, but there are a couple contributing factors that explain why adoption has lagged so far:

First, WebAuthn device support has only recently reached a critical mass, with ~90% of global users’ devices now supporting this authentication technology.



Second, it’s historically been very difficult to integrate WebAuthn, so developers have reasonably chosen to focus on more product-related work rather than trying to integrate an opaque and complex web authentication standard. There are also certain poorly documented edge cases to consider when using WebAuthn, which can significantly complicate implementations if you’re not familiar with WebAuthn.

In 2022, Stytch is focused on helping bring WebAuthn mainstream.

Using WebAuthn with Stytch

Seeing the immense benefits of WebAuthn but also the frustrations that developers had with integrating with it, we’ve built our product to be the simplest way for developers to support WebAuthn. We’ve also made it simple to offer other authentication methods alongside WebAuthn to easily support cross-device access and account recovery such as email magic links, OAuth logins, and more.

If you’re interested in integrating our WebAuthn product, check out the API documentation here or sign up for a Stytch account here.







---


# What is credential stuffing? How to prevent credential stuffing attacks
Source: https://stytch.com/blog/what-is-credential-stuffing/

As more aspects of daily life go digital, we are increasingly grappling with threats to our cybersecurity and personal information. 

As more aspects of daily life go digital, the importance of defending against threats to our personal information continues to grow. And though you might be familiar with common ones like brute force attacks—also known as credential cracking—credential stuffing differs in a few key ways.

This article will cover the basics of credential stuffing, its threat to businesses and individuals, and practical ways to deploy modern solutions against this particular attack vector.

Forceful fraud: Brute force attacks, credential stuffing and password spraying

It's important to distinguish between the methods behind traditional brute force attacks and their closely-related cousins, credential stuffing and password spraying, to know what to look for and how to defend against them.

Brute force vs. credential stuffing

While both brute force and credential stuffing attacks share a common goal of acquiring sensitive user information, the manner in which that information is obtained is fundamentally different.

Credential stuffing uses previously stolen credentials, often obtained from large-scale data breaches, to gain unauthorized access to user accounts. Attackers automate the process of testing these credentials across multiple sites, banking on the unfortunate likelihood that users have reused passwords. This method can be highly targeted, focusing on specific user accounts or services, and is difficult to recognize because it involves valid login attempts that can easily trick security systems.

Brute force attacks attempt to guess passwords indiscriminately by systematically trying different combinations of characters, numbers, and symbols until the correct password is found. Attackers use automated tools to generate and test thousands or even millions of potential passwords, often employing prescribed patterns or commonly used base password phrases. This method is less sophisticated than credential stuffing but can be equally effective against weak or poorly chosen passwords.

Password spraying

Password spraying is similarly indiscriminate: attackers will 'spray' stolen passwords from a database until they gain unauthorized access. Instead of targeting individual accounts with many password attempts, they attempt a small number of common passwords against a large number of accounts, thereby evading traditional lockout mechanisms and increasing the chances of compromising multiple accounts. This method often exploits weak password policies and user tendencies to use simple or common passwords across different platforms.

How does credential stuffing work?

As mentioned, credential stuffing is a type of cyberattack that takes advantage of compromised credentials such as usernames, email addresses, and passwords to access secure or sensitive information.

Here's how fraudsters make a credential stuffing attack work:

Attackers leverage stolen or breached credentials to set up automated attempts to log into multiple accounts, potentially gaining access to personal and financial information.

They then use automation tools to simultaneously log into multiple accounts and check for access to secondary services or accounts. This highlights the potential consequences and the difficulty of detecting such activity.

As noted, a credential stuffing attack differs from a brute force attack in that it doesn’t rely on random attempts to decode a password or username combination, instead relying on lists of username/password combinations acquired from data breaches. Lists can contain millions of these combinations, which hackers then attempt to “stuff” across different sites on a trial and error basis.

Each successful combination can then be used to access lucrative information such as bank accounts, payment applications, credit card numbers, etc., leading to a cascade of fraudulent activity.



How big of a threat is credential stuffing?

Credential stuffing might seem laborious, cumbersome, or not very effective due to its indiscriminate approach. But the perpetrators behind these types of attacks employ sophisticated programs and applications to optimize their efforts.

Unfortunately, AI and machine learning technologies have elevated the humble bots of the Eliza era to a superpower status never before witnessed in the realm of fraud. Now, using bots—which are software programs that specialize in performing repetitive, predefined tasks—malicious actors can try a multitude of password and username combinations against different services in rapid succession.

The resulting large data breaches often yield millions of credentials. Attackers often use these stolen credentials on multiple sites, leveraging botnets to automate the process and increase their chances of success. So, while the success rate for the above tactics is fairly low, the sheer amount of compromised data means that thousands of users can be affected. For example, the Android Users Data Breach in May 2021 compromised the personal data of over 100 million users spanning 23 app databases.

At the end of the day, digital account fraud is a numbers game that increasingly favors the hacker, with the majority of people reusing the same password and username combination across multiple services—up to 65 percent, in fact. Combine this with the reality that data breaches are becoming more common, and the threat of users’ personal data being compromised increases exponentially.

Bots: Stuffing's secret weapon

So what to do about it? To defend against potential credential stuffing attacks, users and developers alike first need to understand more about the bots that are essential to the process.

If you’ve ever been “timed out” or briefly locked out of a website or service after a series of incorrect logins, you’ll have some idea of the basic security in place to safeguard user data. These measures are designed to prevent excessive failed login attempts by identifying suspicious login attempts. This helps differentiate between types of attacks like brute force and credential stuffing.

However, bots can easily get around these countermeasures. They are capable of making multiple login attempts simultaneously and can mask these attempts so that they appear to come from different devices. In short, the system doesn’t flag the behavior as suspicious, and the bots are free to continue trying for viable username and password combinations.

The humble IP address is a common tool used by bots that deploy fake IP addresses to mask their login attempts, making it harder for security systems to detect malicious activity. Blocking or sandboxing these IP addresses can be an effective defense.

How to prevent credential stuffing attacks with Stytch

Because bots can target multiple accounts swiftly, it's crucial to implement robust security measures that span a business' application ecosystem. To work towards this, many services are now implementing more complex cybersecurity measures, such as those outlined below.

Breach-resistant passwords

As hackers develop more sophisticated social engineering techniques, breach-resistant passwords offer a crucial defense. Breach-resistant passwords are strong and secure, making them difficult for bots and attackers to guess. Stytch's solution incorporates the zxcvbn strength assessment tool, which ensures that passwords created adhere to NIST password guidelines, focusing on both length and complexity to enhance security.

Additionally, Stytch integrates with HaveIBeenPwned to monitor for compromised credentials, automatically prompting users to reset their passwords if a breach is detected. This ensures that user passwords remain resilient and up-to-date, significantly reducing the risk of account takeovers.

CAPTCHAs

CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart. These tests, like identifying buses or crosswalks in images, are simple for humans but challenging for bots, which struggle with image interpretation and human-like responses. Developing bots to solve CAPTCHAs is time-consuming and expensive, and since CAPTCHAs can't be reused, bots must solve them repeatedly, slowing down credential stuffing attacks. Stytch Strong CAPTCHA offers a modern take on traditional CAPTCHA that thwarts bots and CAPTCHA farms by using proprietary device intelligence to proxy and encrypt the CAPTCHA. Visit our product page or contact an auth expert to learn more.

Two-factor and multi-factor authentication

Often abbreviated as 2FA, two-factor authentication is becoming an increasingly popular cybersecurity measure. A subset of multi-factor authentication (MFA), 2FA gets its name because it uses two factors to verify a user’s identity. This can be any combination of single factors such as password and username, answering a security question, or entering a one-time code delivered via text message to the user’s personal device to verify a user’s identity. More complex methods like biometric authentication (fingerprint scanning) can also be incorporated and stacked, providing two or more layers of extra security in the event that a user’s credentials are compromised. This makes multi factor authentication (MFA) a more effective countermeasure against credential stuffing attacks and a go-to for industries that deal with sensitive data, like finance and government.

Device fingerprinting

Stytch Device Fingerprinting analyzes and identifies unique device attributes such as browser configurations, IP addresses, and hardware characteristics to detect and block suspicious activities from non-human actors like bots. This precise identification method ensures that only legitimate users gain access while thwarting bots attempting to exploit stolen credentials. To strengthen your security and protect against credential stuffing, explore Stytch's advanced device fingerprinting solution.

Going passwordless

It's essential to distinguish between legitimate users and attackers to ensure that security measures do not hinder the user experience for genuine users. While there are a plethora of password generators out there that provide users with usernames and passwords specifically designed to be hard to crack, many users still rely on simple passwords reused across multiple apps and services for their user accounts. This is an inherent flaw of password authentication, one that is difficult to correct because of how ingrained and widespread it is, and it's one of the leading causes of stolen login credentials. To get around this issue, many developers are choosing to go passwordless using methods like biometric authentication and multi-factor authentication (MFA)

Stytch Passwordless Authentication uses a suite of modern authentication methods designed for seamless, secure user logins, such as email magic links, SMS passcodes, WebAuthn, OAuth, and biometric authentication. This approach effectively prevents credential stuffing attacks delivered by bots, as there are no passwords to steal or reuse in a login attempt.

To explore how Stytch can enhance your security strategy to prevent a credential stuffing attack and related bot attacks, get in touch with an auth expert orget started today.

---


# Managing your users at Stytch
Source: https://stytch.com/blog/managing-your-users-at-stytch/

Managing your users at Stytch





So you integrated with Stytch, you have a buttery smooth onboarding experience for new users, and best of all…you had a ton of users sign up for your app! Awesome, you’re done! Wait, exactly how many users signed up for your app? Were they using your SMS passcode flow on mobile or using Email magic links on desktop?

Good news! We just released User management in the Stytch Dashboard and our Search users endpoint in our API to help give you complete visibility into all of your users at Stytch so you can answer questions like the above.

User management in the Dashboard

With User management in the Dashboard we wanted to give our developers an out of the box way to view all of their users at Stytch and filter or search across them. We allow filtering your users based on their status, i.e. active or pending, and you can search across your users on name, user_id, email address, and phone number.

You can also click on any user's row and see detailed information about that specific user.

Search users endpoint



A lot of customers have reached out to us asking for an API endpoint that would let them search and filter their users for a variety of use cases; huge thanks to those developers, we love hearing your feedback!

Our Search users endpoint allows you to leverage seventeen different filters to pinpoint any slice of your users in Stytch. Check out our Docs to see all of the available filters and multiple example requests. We also released this endpoint in our Node and Go client libraries, both have helper functions to make pagination super easy!

We'd love feedback

Both of these features were born out of direct feedback from developers using Stytch, we love hearing about what you want and how you use our API. If you have any feedback or feature requests (or spy any bugs ???? ), please reach out to us on our community Slack, Discord, or support@stytch.com!

---


# What is MFA (Multi-Factor Authentication) and how does it work?
Source: https://stytch.com/blog/what-is-mfa/

In this article, we'll cover what multi-factor authentication is, how it works, and some of the most common ways it's used today to protect online accounts.

Today, there is scarcely an area of life that is not touched by or managed online. From our bank accounts to our health records, to our family photo albums, everything we do depends on an online account of some kind. This means the stakes for protecting those online accounts has never been higher.

One of the most important protections companies can leverage to protect their company and their customers is multi-factor authentication. In this article, we'll cover what multi-factor authentication is, how it works, and some of the most common ways it's used today to protect online accounts. Let's dive in!

So, what is multi-factor authentication?

MFA stands for multi-factor authentication. It's a layered approach to confirming a user's identity to ensure they have permission to access a protected website, application, network, or other digital system or perform a protected task within a digital system. As its name suggests, MFA requires users to successfully present relies on multiple authentication factors, instead of just one. This often (but not always) occurs at initial login; sometimes, the authentication factor prompts are dispersed throughout a digital experience.

Why is multi-factor authentication important?

As time passes, hackers only grow more sophisticated. They now have at their disposal advanced tools that allow them to generate and test username and password combinations until they arrive at the correct permutation and gain access to the system they are trying to breach. Compounding the issue is the fact that users often select weak, obvious passwords and repeat them across multiple accounts, making it possible for hackers to breach multiple systems with one set of credentials. As a result, passwords alone have been rendered insufficient as a means of protecting sensitive online data. In fact, 81% of all data breaches can be traced to weak or stolen passwords, and the Open Web Application Security Standard (OWASP) now encourages all authentication flows to treat passwords as “pre-breached.” MFA makes online systems more secure in light of this threat. By requiring users to verify their identity through multiple factors—not just a single password or password alternative—MFA makes unauthorized logins and fraudulent transactions less likely to occur. In turn, it has become a pillar of cybersecurity.

How does multi-factor authentication work?



MFA works according to a principle of layered security. By asking users to provide additional forms of identification, it increases the likelihood that the user is who they claim to be, reducing overall risk. Often, a user is prompted to present all of their credentials at initial login. A typical security protocol might have them submit their username and password (factor 1) and answer a security question (factor 2) before asking them to enter a one-time passcode sent to them by text or email (factor 3). Once the user completes all steps, they have access to the entire application.

The advantage of MFA isn't just that it asks for more than one piece of identification; it's that it also asks for identification of different types. The most common types of authentication factors employed by MFA are:

Knowledge-based (things a user knows)

Possession-based (things a user has)

Inherence-based (things a user is)

Knowledge-based factors

Knowledge-based factors include information that ideally only the user will know. These include factors like:

Passwords are the de-facto authentication factor most people think of. Unfortunately, while passwords are designed to be information that only the user knows, hackers have a lot of ways of learning this information.

Usernames are also knowledge-based factors. While we sometimes think of passwords as the main authentication factor, it's really the combination of the username with the password that identifies them exclusively as a factor.

Pins are very similar to passwords, except they typically draw from a smaller character-base (like numbers only) and are typically a shorter string.

Security question answers like “What street did you grow up on?” or “What was the name of your first pet?” are also knowledge-based authentication factors. Unlike pins, usernames and passwords, though, these are usually a second factor and not a primary.

Of the categories of authentication factors, knowledge-based authentication factors are generally the least secure, particularly when not paired with second or tertiary factors.

Possession-based factors

Possession-based factors refer to something the user has or has access to instead of knows. These include factors like:

Magic links

Also called email magic links, this type of authentication method lets users instantly log in via a URL sent to a pre-registered email address.

One-time passcodes

SMS one-time passcodes (OTPs), which ask users to enter a unique numeric or alphanumeric sequence sent by text to a recognized mobile phone number

Time-based one-time passcodes

Time-based one-time passcodes (TOTPs), which ask users to confirm control of their device within a certain time frame via a passcode generated by a smartphone app like Google Authenticator.

Push authentication

Push authentication, which sends notifications to an app on users' devices, asking them to approve or reject a login attempt

WebAuthn

WebAuthn can take a few different forms, but generally combines public key cryptography with on-device biometrics or external security-key hardware – often referred to as a physical key, a hard token or physical token. Most people are familiar with these keys as a USB key called a YubiKey.

Inherence-based factors

Inherence-based factors rely on biological traits unique to the user. You may also hear these referred to as biometrics or factors based on what you are. Examples of biometric factors include fingerprints, hand geometry, iris or retina recognition, voice recognition, and facial recognition.

Biometrics

Biometric authentication is typically built into a device and is designed to scan, analyze, and recognize distinctive, measurable features — like a user’s fingerprint, facial contours, iris/retina patterns, and voice qualities. Many biometric solutions are also equipped with liveness detection tools, so they can distinguish between a legitimate user and a reproduction (like a photograph or voice recording) in order to prevent fraud.

WebAuthn

Wait WebAuthn is both an inherence and possession-based factor? Yes! Because WebAuthn often combines biometrics with public-key cryptography, the biometrics portion of the WebAuthn flow both confirms the user's identity (inherence) along with ownership of their device (possession).

Passkeys

Passkeys are a new evolution built on WebAuthn, with some key improvements. While WebAuthn pioneered the concept of a single-device passkey (i.e. a single hardware key or a biometric validation tied to your mobile device or laptop), “passkeys” as we’re discussing here refer to multi-device passkeys that can be synced to the cloud and used across devices – even across operating systems! This makes them a drop-in replacement for passwords as well as an excellent additional authentication factor for MFA flows. In customer-facing authentication, biometrics are typically paired with additional cryptographic technology. Good examples of these include WebAuthn, passkeys, and other technological standards that have come out of the FIDO alliance.

What are the benefits and drawbacks of multi-factor authentication?

Benefits of MFA

The main benefit of MFA is security – multi-factor authentication process makes it considerably more difficult for hackers to breach a system than single-factor authentication. That's a huge advantage, especially when you consider the exorbitant costs incurred by organizations and individuals affected by security violations.

Drawbacks of MFA

One of the biggest drawbacks to MFA is in its effects on the user experience: in the process of making systems more secure, MFA can add some amount of friction to the system's user experience. The good news is that can be mitigated by smart authentication design.

Improving MFA user experience

One way to avoid undue hassle and frustration is to employ a route-based approach, in which MFA is only introduced for certain actions or transactions online. Another is to eliminate passwords as a verification factor entirely, since remembering and entering passwords are their own source of friction. Passwordless authentication methods are simpler and faster than passwords, making user retention more likely. And because they can easily be layered in a multi-factor approach and avoid the security risks posed by weak and compromised passwords, they are inherently more secure.

Multi-factor authentication FAQs

What's the difference between multi-factor authentication and two-factor authentication (2FA)

MFA and 2FA are not fundamentally different. Two-factor authentication is just a subset of multi-factor authentication, which is an umbrella term for any authentication process that uses more than one verification factor. In other words, all 2FA is MFA, but not all MFA is 2FA, because some applications of MFA use three or more factors.

What is adaptive multi-factor authentication?

This is a great question. But to understand adaptive MFA, it can be helpful to understand a few different types of auth that often get mixed up:

Route-based authentication refers to any incremental security method, where a user must only undergo extra checks—like a second or multi-factor authentication—to carry out more sensitive tasks within an app.

Just-in-time (JIT) authentication or risk-based authentication is another, less technical term for route-based authentication, deriving its name from the fact that users are only asked to authenticate with additional factors at the moment the more sensitive tasks are being attempted. This is also sometimes referred to risk-based authentication, because users are only prompted with additional authentication factors when their behavior is flagged as suspicious or potentially fraudulent.

Step-up or adaptive authentication refer to a specific type of just-in-time authentication that requires an additional authentication level specifically when trying to perform high-risk operations on an IT system. Unlike JIT, adaptive authentication is invoked based on the type of transaction, not based on user behavior or flags.

All three of these terms are important because they offer ways for companies to remove friction from MFA flows without compromising security – a key to driving conversion, adoption, and user engagement for any business model.

Does MFA make accounts un-hackable or unphishable?

In short, no. There is virtually no authentication method or combination of methods that can guarantee 100% impenetrability from outside attacks. Just as authentication companies like Stytch are constantly innovating to improve our product, hackers are also constantly innovating to find new ways to compromise cybersecurity. MFA is no exception: while more secure than single-factor authentication processes, secondary factors like one-time passcodes and email magic links can be phished or stolen by attackers who are willing to put in the time. If phishing is a big concern for your product, it might be good to consider integrating “unphishable” authentication methods into your MFA flow – biometrics, Yubikeys, and passkeys are all much more difficult to phish or steal because they rely on inherence factors, rather than possession or knowledge. To learn more, you can check our our article about unphishable MFA.

Is MFA the same thing as “zero trust”?

Not exactly, though they are often mentioned together:

Zero trust refers to an approach to cybersecurity in which no user nor device is trusted until their identity and access is verified. Every single device or user must be authenticated to gain access to a given network application, or server.

Multi-factor authentication has become a popular approach to zero trust because it adds a few additional layers of verification to the zero trust model.

Put another way, zero trust is a guideline or model for how often or in what cases you authenticate, while multi-factor authentication refers to how that authentication is performed.

Which MFA is right for my business?

At Stytch, we highly advocate for designing your authentication flows around what introduces the least amount of friction to your users, while still keeping them secure. Determining that usually varies from business to business. While we provide a more in-depth rundown how to choose the right MFA flow in another article, any company can start by considering three main decisions:

Will you make MFA optional or require it for all users?

Will you offer multiple MFA options so that users can choose what best fits their needs? How many and which options will you provide?

Will you layer on?

Remember, when answering these, think about what kind of information is most at-risk or valuable that hackers might want to access, how much friction your users will tolerate, and at which junctures in their signup or login flow they're most likely to tolerate that friction.

Explore Stytch's multi-factor authentication solutions

Looking for additional information on implementing secure, user-friendly, multi-factor authentication methods? Stytch has you covered. Sign up for a free account to get started, or talk to an auth expert today to discuss what MFA looks like for your product.





---


# Bingrui Tang
Source: https://stytch.com/blog/bingrui-tang/

Bing joined us one year ago and we couldn't be more excited to celebrate her and her contributions to building Stytch's product and culture. 

Today is the one year anniversary of the official creation of our Design team! Bing joined us one year ago and we couldn't be more excited to celebrate her and her contributions to building Stytch's product and culture. Meet Bing!

What do you love most about working at Stytch?

Autonomy, growth, and working with great people.

What does a typical day at Stytch look like for you?

A "typical" day has evolved a lot since I started managing the [design] team. I usually structure my time on a weekly basis: Mondays and Wednesdays are for independent work; Tuesday 1:1s; Thursday team review and cross-functional collaborations; Friday following-ups and relationship-building.

What’s been the most surprising thing about Stytch?

We have surprising numbers of pet owners! Other than that, the speed of growth is still much faster than what I imagined.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

There are so many! And I am still very inspired by the people I work with everyday. To list a few: establishing scalable structures even as a team of 1; asking for help before feeling the pinch; and, as we're still often communicating virtually, a little extra kindness and curiosity goes a long way.

What’s your favorite part of the Stytch culture?

I really enjoy how the team built a direct and kind communication style. I feel like I could rely on everyone for constructive feedback, while also trusting us move through challenging situations with space and grace.

Which Stytch value resonates most with you and why?

"Think exceptionally", which, in Stytch context means "avoiding the assumption that existing norms are the right path." We've heard great feedback on our website design, for example, and it is a "look and feel" that we deliberately established that feels right and true to us, v.s. something we rushed through following the trend.

What’s the most interesting project you’ve worked on at Stytch?

Designing the Design team! I enjoy puzzle games, but this is certainly far more challenging than the box of Frank Stella geometric painting puzzles I've been procrastinating on.

How did you end up becoming a product designer?

I worked in film prior to Product Design, and the idea of working on something forward, challenging, creative, yet still being able to go home at a reasonable time seemed more than perfect to me.

When’s the last time you did something for the first time and what was it?

I went ice-skating for the first time when visiting Seattle this past December, and it was so much fun! Also fascinating to watch young kids learn: some of them didn't even finish crying before they started all over again!

What song, hobby, or recipe got you through COVID?

I've been taking boxing and ballet classes. Also got quite into sewing and cooking everything at home in the past few months.

What’s your ideal weekend?

A night by the Oregon Coast, and an evening with homemade dinner, books, and tea.

What’s something you’re passionate about that’s not on your resume?

Writing, dance choreography, and apparel design. Maybe one day!



Interested in joining the design team at Stytch? Learn more about open roles, here!

---


# 10 common cyber attacks
Source: https://stytch.com/blog/10-common-cyber-attacks/

Learn which types of cyber attacks are most likely to target your platform — and what you can do to prevent them.

Learn which types of cyber attacks are most likely to target your platform — and what you can do to prevent them.

Cybersecurity can often seem like a game of cat and mouse. No sooner do security experts get wise to the latest threats than attackers modify their tactics, discover fresh vulnerabilities, and develop new lines of offense.

Still, most cyber attacks fall into a known set of categories and follow a predictable pattern.

In this post, we review ten of the most frequently carried out cyber attacks, how they work, and what developers and users can do to protect their sensitive data.

What is a cyber attack?

A cyber attack is any attempt by malicious actors (often called cyber criminals or hackers) to breach a computer system, network, or database. A cyber attack can be launched against a single user or device or against a larger group — like a corporation or a governmental organization.

In recent years, there have been several instances of successful, high-profile cyber attacks against major global companies like Uber, Twilio, Okta, Microsoft, Samsung, and Cisco, to name just a few. And, alarmingly, some studies suggest that the overall number of cyber attacks is on the rise.

What's at risk in a cyber attack? What do hackers want?

Generally, hackers carrying out a cyber attack want to intercept, destroy, or otherwise tamper with online assets.

They may be out to steal sensitive data like account credentials, personal or financial information, or valuable intellectual property, or to install malicious software into a computer program to disrupt its operations. They may be doing this for monetary gain, for an ideological or political cause, or even just for fun.

All in all, it's a highly lucrative (and highly damaging) business, with each cyber attack carrying an average price tag of $4.35 million for the impacted company.

What are the most common types of cyber attacks?

There are ten popular types of cyber attacks that show up time and again in security circles. Below, we share what they entail, how to spot them, and which of the latest security methods can help keep them at bay.

1. MALWARE ATTACKS

Malware, short for malicious software, is an umbrella term for any invasive file, program, or malicious code introduced to a computer through a corrupt email attachment, malicious link, or fraudulent ad. In a malware attack, an unsuspecting user loads one of these programs when visiting a website, leading them to unknowingly install malware on their system.

There are many different types of cyber attacks that use malware, including:

Viruses that attach themselves to legitimate files or programs a user employs, then replicate and spread across different platforms, software, and devices

Ransomware attacks that encrypt data or files on a device and block a user's access until they pay a certain price (ransom) or meet a specified condition

Spyware that secretly monitors a user's online activity, gathers data, and then relays it to a malicious third party

Trojans that (like a Trojan horse) are disguised as harmless or desirable programs and trick a user into downloading a corrupt file

Bots (short for robots) that are programmed to quickly and automatically carry out attacks, with the potential to infect and control many different computers at once

A classic example of a malware attack (in trojan form) is pop-up advertising for fake antivirus software. This corrupt "software" promises to rid a computer of viruses but actually introduces one to the system, as it gets a user to unwittingly install malware instead.

Recently, there's also been a growing trend of malware as a service (MaaS) products. In the MaaS market, cybercriminals can buy or lease pre-made software or hardware that they can use right away, increasing the efficiency and frequency with which they can carry out their malware attacks.

2. PHISHING ATTACKS

Phishing attacks are a form of social engineering. In a typical phishing attack, a hacker sends a message via email, SMS, social media, or another online channel, hoping to trick the recipient into disclosing restricted or sensitive data.

Phishing attempts are often carried out en masse and at random to ensnare the largest possible number of victims. But they can also be part of a more targeted campaign, in what's known as a spear phishing attack. Spear phishing attacks are tailored to a particular individual or organization to make the message and desired action seem more intimate and trustworthy. When this technique targets high-ranking executives, specifically, it's called a whale phishing attack.

One of the most well-known tropes used in phishing attacks involves an email scam where the author poses as foreign royalty, offering the recipient a share in a vast fortune if they help move the funds out of another country. As the story goes, the recipient must provide their bank account information, so the money can be transferred to them for safekeeping. Of course, an obliging reader will quickly find their account balance drained.

Many protective measures have emerged in recent years to prevent phishing attacks and spear phishing attacks, including unphishable multi-factor authentication (MFA) flows, which avoid commonly intercepted credentials like passwords and email or SMS one-time passcodes.

3. MAN IN THE MIDDLE (MITM) ATTACKS

In man-in-the-middle (MitM) attacks, a hacker eavesdrops on or otherwise gets hold of sensitive communications between a user/application and another platform. Think of it like a hidden, silent third party listening in on a confidential phone conversation.

MitM attacks can occur as either active or passive eavesdropping attacks:

Active eavesdropping attacks could take the form of session hijacking, where a hacker observes the web traffic occurring over a given network, locates an active session ID, and then uses the related session token to gain unauthorized access to a user's account.

In a passive eavesdropping attack, a hacker might create a free, public WiFi hotspot — like at a park or cafe — and get a full view of all the activities and data exchanges an unsuspecting user is participating in over that wireless network.

4. DENIAL OF SERVICE (DoS) ATTACKS AND DISTRIBUTED DENIAL OF SERVICE (DDoS) ATTACKS

A denial of service attack (DoS attack) occurs when a hacker floods a website or network with pointless or unnecessary requests — often from fraudulent accounts — overloading the system until it crashes or is shut down. This disruption means that legitimate users and user requests cannot access the site or service, thus thwarting its regular operations or business.

Think of a D0S attack like a prank caller continuously phoning a pizza shop during peak hours, tying up the line so real customers can't dial in with actual orders.

In a conventional DoS attack, this congestion is caused by a single source. In a distributed denial of service (DDoS) attack, however, it comes from many different sources at once.

In the pizza shop analogy, a DDoS attack would look like this: Imagine the prank caller has help from a dozen of his closest friends, each calling from a different phone. It would be next to impossible to trace and block each of these numbers to free up the pizza shop's line — which is why DDoS attacks can be more difficult to stop.

Given the bandwidth necessary to execute them, DDoS attacks are almost always carried out by programmed botnets, so taking bot-preventing measures like monitoring web traffic and rerouting or blocking malicious bot activity can help protect your system from a DDoS attack.

5. CROSS-SITE SCRIPTING (XSS) ATTACKS

Cross-site scripting attacks (XSS attacks) rely on code injections, where hackers insert malicious code — typically client-side, malicious JavaScript code — into a trusted app or website. In other words, an attacker targets a user by hiding harmful code behind seemingly harmless content, which they load into their browser.

Cross-site scripting attacks can occur when the data a user submits — like entering their name into a contact form — is not properly validated or escaped, allowing hackers to substitute the user's input with malicious JavaScript code that the browser executes automatically.

Alternatively, an XSS attack can take the form of shortened or disguised URLs in a phishing email — like a fake message from a user's bank that asks them to “click here” to resolve a problem — with the included link really just running a malicious script.

Following a successful XSS attack, a hacker can gain access to a user's credentials or hijack their account, control their browser remotely, or even spread worms and other malware across their entire system.

6. SQL INJECTION ATTACKS

Similar to an XSS attack, an SQL injection attack occurs when a hacker inserts structured query language (SQL) code into a standard request in order to breach or manipulate a vulnerable database.

One example of an SQL injection attack is when an app or website provides a form for users to enter their login information (like a username and password), which is then checked against the app's database to verify the user's credentials and grant them access. A hacker might use that form to insert SQL code instead — a programming language that allows them to communicate directly with the app's database and thus carry out their own requests.

The best way to prevent SQL injection attacks is to use input validation and parameterized queries, rather than inserting user inputs directly into SQL statements, but different cybersecurity experts will have different approaches to this issue.

7. DOMAIN NAME SYSTEM (DNS) SPOOFING

Domain name system (DNS) spoofing attacks are sometimes referred to by the names of their constituent parts — DNS cache poisoning and DNS tunneling attacks.

A hacker first impersonates a DNS server, which is responsible for translating the domain name a user enters (like google.com) into an IP address that a computer can understand and route to. Having intercepted a user's request, the hacker instead alters (or poisons) the information in the cache of the DNS server and reroutes (or tunnels) the user to their own fake IP address, which hosts a forged version of the desired website.

For example, a user may think they're heading to the Facebook login page — via facebook.com — but be redirected to a different domain hosting the hacker's fraudulent Facebook page. Any username and password the user enters there can, of course, be seen and stolen by the hacker and leveraged to breach the user's actual Facebook account.

8. BIRTHDAY ATTACKS

Birthday attacks are named after the birthday paradox in mathematics — which states that, for there to be a 50% chance someone at a party shares your birthday, you need 253 people at the event. But for a 50% chance that any two people there share a birthday, you only need 23 at the event, because you're not already tying one end of the pair to a specific date.

In cryptography, a birthday attack follows this same principle. It's much more challenging to find a collision or match with a specific hash function — a one-way algorithm responsible for encrypting, converting, and validating data like passwords — than it is with randomized attempts.

When successful, these more dispersed attacks can then be used to crack encrypted values like digital signatures.

9. DRIVE-BY ATTACKS

In a drive-by attack, the user doesn't actually have to download, open, or click on anything at all to install a hacker's program on their device.

Instead, drive-by malware can piggyback on a legitimate, authorized download and deliver a hidden, harmful payload along with it. In other cases, it can exploit security flaws on a legitimate website to transfer a malicious program onto a user's device.

Essentially, as the name implies, all a user has to do is visit or “drive by” a certain website to be affected.

10. PASSWORD ATTACKS

A password attack is really any attack that attempts to steal a user's password, and the term encompasses many of the above strategies. Still, there are a few unique terms and techniques that are used when hackers target traditional passwords specifically, including:

BRUTE FORCE ATTACKS

In a brute force attack, a hacker attempts to gain access to a secure account through trial and error, repeatedly entering random credentials like username and password pairs until one works.

CREDENTIAL STUFFING ATTACKS

In a credential stuffing attack, a hacker uses the correct credentials — which they've intercepted or stolen using one of the above attack vectors — to sign into a legitimate user's account and break into a secure system.

PASSWORD SPRAYING

Password spraying is a type of brute force password attack where hackers use the same common password across numerous user accounts before moving on and trying another, allowing them to bypass simple protections like login lockouts.

The good news is that it's relatively easy to prevent password attacks. It's as simple as not using traditional passwords in your sign up and log in flows — and instead relying on any of the secure, passwordless authentication options on the market to safeguard your app.

AND ON AND ON…

Unfortunately, this list is by no means comprehensive. Hackers are always adapting and refining their methods to bypass the newest security software, circumvent the latest cryptographic techniques, and come up with new cyber attack vectors that keep cybersecurity experts (and all internet users) on their toes.

That means there's a constantly growing arsenal of cyber threats, with others including zero-day exploits, internet of things (IoT) attacks, rootkits, and cryptojacking.

How to protect against cyber attacks

While we could write a whole post on the best ways to guard your business or personal data against cyber attacks — and, in fact, we did — there are a few simple measures you can take right off the bat:

Know your sources.

This may seem basic, but verify that each file you download is coming from a known and trustworthy source, avoiding exposure to malware.

Keep your software up to date.

You may be annoyed by pesky update reminders, or you may not have time to install the latest version of a program or app, but not following through can leave your device open to a cyber attack that the software company or operating system has already worked hard to solve.

Implement multi-factor authentication (MFA).

By taking a layered approach to authentication, requiring two or more credentials to verify a user's identity, multi-factor authentication (or MFA) is one of the best and simplest ways to secure your app or website against many different types of cyber attacks.

Better still, implement unphishable MFA, which uses end-to-end cryptography and key-based authentication to combat more sophisticated cyber attack methods like SIM swapping, which can compromise secure SMS-based one-time passcodes.

Get rid of traditional passwords.

As a company specializing in passwordless solutions, we'd be remiss if we didn't remind you that traditional passwords are the weakest link in the authentication game — whether they're easily forgotten, repeated across multiple accounts, or just downright easy to guess — and removing them from your auth equation is the only foolproof way to prevent a costly password attack.

Remember: The vast majority of data breaches (81% or more) can be traced to compromised credentials, which is why industry experts at the Open Worldwide Application Security Project (OWASP) advise that all traditional passwords should now be considered "pre-breached."

It's just not worth putting your data at risk when there are plenty of secure, alternative auth solutions at your fingertips. And if you must use passwords, use a next-level, modern version that eliminates conventional UX flaws and vulnerabilities.

What Stytch is doing to prevent cyber attacks

In the fight against cyber attacks, we're equipping developers with the latest, strongest passwordless products, from email magic links to SMS one-time passcodes to WebAuthn built-in biometrics and specialized hardware keys.

To get started, sign up for a free account, and try our solutions out in a sandbox environment to see what they can do for you.





---


# Introducing TOTP Authentication for Next-Level Security
Source: https://stytch.com/blog/introducing-totp-authentication/

Today, we’re excited to introduce TOTP (time-based one-time passcodes), an important passwordless two-factor authentication option that can be used in situations where you need high security assurance.

Today, we’re excited to introduce TOTP (time-based one-time passcodes), an important passwordless two-factor authentication option that can be used in situations where you need high security assurance. TOTP authentication solutions are ideal for particularly sensitive use cases that are also highly attractive to attackers in terms of the potential payoff they offer–think money movement in fintech or cryptocurrency spaces or access to a company’s HR or payroll information. With Stytch, developers can now embed TOTP into their authentication flows in minutes rather than months.

How TOTP authentication works

When integrated as a second authentication factor, TOTP serves as an additional safeguard by requiring users to prove possession of their device. It works by generating a one-time passcode that’s based on the current time and a shared secret between an authenticator app like Google Authenticator and the server (in this case, Stytch).

Users, who must have an authenticator app downloaded on their device, are asked to input the unique passcode within a certain period of time, usually 30 seconds, as evidence of their identity. Once the user supplies the TOTP code, developers can use Stytch’s /totps/authenticate endpoint to verify that passcodes are valid and, ultimately, grant users access.

TOTP vs. SMS passcodes

If you’re familiar with SMS one-time passcodes (another great passwordless solution for most use cases), you may be wondering why you would opt for TOTP instead.

It’s true that SMS passcodes are very convenient, and many users are familiar with them. Anyone who has placed an online order with a business that uses Square as its point of sale system, for example, has interacted with SMS passcodes. In this instance, users receive a text with a unique code that unlocks access to the payment information associated with their Square account, allowing them to complete a purchase. iOS and Android devices even auto-fill passcodes with a simple permissioning click. There’s nothing for users to remember, and friction is minimal; they just need to be in possession of a device linked to their phone number.

While it’s possible that a hacker could steal a user’s phone number (called “SIM swapping” or “porting”), the significant effort and resources required to successfully pull off such an attack usually makes it a nonstarter. In other words, for low-to-moderate risk use cases, the cost generally outweighs the relatively modest potential reward.

When elevated risk requires elevated security

If, however, there’s a potential for a lucrative payoff, such as use cases involving large volumes of money movement or sensitive HR records, a hacker’s cost-benefit analysis may tip in the other direction. In 2021, for example, hackers carried out sophisticated phishing attacks against Coinbase users. By tricking them into sharing their phone numbers and other personal credentials, hackers were able to intercept SMS passcodes and access users’ accounts.

TOTP evades the threat of SIM swapping by removing users’ phone numbers from the equation, tying authentication to an app on their local devices instead. By welding the one-time passcodes being generated to your local device, it no longer matters whether a phone number is stolen as the device remains with the user. This is why cryptocurrency custodians like Gemini and other applications with high-risk interests leverage the TOTP standard.

As an added benefit of this design, TOTP can function offline, which may be important for users in areas of poor or no connectivity like airplanes. Meanwhile, SMS passcodes remain a great authentication option for low- to moderate-risk use cases given how convenient they are for users.

Time for Stytch

Stytch makes building a TOTP authentication flow fast and easy, so you can focus on your core competencies. Our product works out-of-the-box with any authenticator app that follows the TOTP protocol (e.g., Google Authenticator, Authy, Microsoft Authenticator, etc.), giving your users the freedom of choice without any additional development on your part. If you’re interested in integrating TOTPs into your apps, you can sign up for a developer account here to get started or contact support@stytch.com.







---


# SDK vs. API: What's the difference?
Source: https://stytch.com/blog/what-is-an-api-what-is-an-sdk-and-whats-the-difference/

Modern software development kits (SDKs) and application programming interfaces (APIs) make it easier for developers to integrate key features and functionalities into their apps.

Modern software development kits (SDKs) and application programming interfaces (APIs) make it easier for developers to integrate key features and functionalities into their apps. Instead of requiring teams to build all software components in-house from scratch, SDKs and APIs allow them to connect to other platforms and leverage existing services and technologies, providing them with all the tools and resources they need to get up and running quickly.

These two building blocks are often discussed interchangeably and comparatively — as in, SDK vs. API — but they can actually work together or separately to serve a variety of use cases.

In this post, we explain what SDKs and APIs are, the key differences between them, and how their respective benefits can help accelerate app development.

Let's start with APIs.

What are application programming interfaces (APIs)?

API stands for "application programming interface," with the key word being “interface.” That's because APIs essentially work as messengers or mediators that allow different apps and platforms to communicate with each other.

More specifically, APIs are responsible for relaying an app user's request to a separate operating system and, once the information is processed, relaying the system's response back to the app and user.

How APIs work

APIs are often explained through customer service analogies. For instance, if you're working with a travel agent to plan a trip, the agent is tasked with taking your information (travel dates, passport information, etc.), reaching out to airlines, and booking you a suitable flight. But the travel agent and the airline — say, Delta — are two different entities. The agent isn't supplying the plane or flying it, but you trust them to interpret your needs and book you the ticket you want through the Delta system.

In this scenario, the travel agent is the API. They're saving you the time and hassle of researching and booking a reservation yourself by coordinating with an outside service, and they're probably getting you a better deal to boot.

API examples and use cases

In our growing world of “headless” CMS development — where backend content is increasingly decoupled from a front-end UI that changes from channel to channel — APIs are what connect the two and maintain a seamless, consistent user experience.

Most modern apps use some form of API to allow users to accomplish specific tasks without ever leaving a given platform. For example, APIs are working behind the scenes whenever users:

Reserve a flight through a booking website

To expand on the analogy above, online booking sites like Expedia and Travelocity use airline APIs to aggregate flight data (like schedules and pricing) and present all available options.

Make an online payment

When someone makes a purchase online, they're prompted to select a payment method at checkout. Whether they choose a credit card or PayPal, the e-commerce app uses that processor's payment APIs to send order information and complete the transaction.

Log in to an app through a third party

Many websites offer OAuth logins, where users can enter existing credentials from a Google, Facebook, Twitter, or other social media account and be authenticated through that platform's API.

Add a newly scheduled appointment to a calendar app

If a user books a dentist appointment online, the dentist's website might use an API to add the appointment to the user's iCal or Google Calendar.

Search for the nearest storefront

Many retail sites use APIs to connect to platforms like Google Maps and embed location services into their app, so users can find and get directions to the nearest shop.

The benefits of APIs

By facilitating interactions between different systems, APIs make it quicker and easier for developers to integrate and innovate on critical services — and for users to access them.

In the above examples, for instance, the online transactions are optimized for everyone involved:



App developers can provide advanced, specialized features without having to spend extra time and effort on programming.



Users gain access to new services within the apps they're already using, without being bounced around to third-party platforms and presented with extra friction.



API providers are able to tap into new use cases and find new sources of revenue for their products and services.

It's a win-win-win, and it means everyone enjoys a more seamless digital experience.

APIs and security

Because APIs play such an important role in digital transformation, and because they transmit sensitive user data like payment and account information between different apps, they've become a key target for common cyber attacks, which are growing more sophisticated by the day.

When integrating with APIs, it's important for developers to make security a top priority. That means keeping up with best practices and following the proper protocols — like encrypting traffic to prevent man-in-the-middle (MitM) attacks, using multi-factor authentication (MFA) to protect against credential stuffing attacks, and using just-in-time (JiT) authentication to monitor what data users can access and when.

By ensuring their security practices are up to snuff, developers allow users not only to harness the connective power of APIs, but to do so safely.



What are software development kits (SDKs)?

SDK stands for "software development kit." As the name suggests, SDKs work as a sort of “kit” or preassembled package that gives developers all the tools and programs they'll need during the software development process. This often includes at least one API with pre-built integrations, simplifying (or even eliminating) the implementation steps involved.

To continue our analogy, if an API is like a travel agent — a mediator that identifies and interfaces with other providers, but one that requires a set of instructions to operate — then an SDK is like an all-inclusive cruise. In other words, everything from the itinerary to the menu to the activities is already arranged, and all a traveler has to do is show up.

For that reason, SDKs can be valuable development tools for teams that want to expend minimal effort when planning and developing software.

What does an SDK include?

As part of the “kit,” an SDK will typically include a compiler for translating code, a debugger to test and locate errors within the program, and the API itself. It may also include elements such as:

Code samples and/or code libraries to teach developers how to create basic programs

Documentation on how to use and integrate the API

Guides and/or tutorials to walk them through the process

Licensing by the provider that regulates the use of the SDK material

Navigating SDK terminology

Developers use a number of different terms and concepts throughout the development process to refer to SDKs working on the front and back end.

Some, for instance, refer to client libraries (for backend code) as “admin” SDKs, and some call frontend SDKs “browser-side” or “client-side” SDKs to specify their positioning and function.

SDK examples and use cases

There are many ways app developers might use pre-built, ready-to-go SDKs. These include:

Developing for a specific platform

When teams want to develop applications for a specific platform, they must use that platform's SDK. One prominent example is the iOS SDK developers use to build targeted apps for the iPhone and iPad.

Developing for a specific programming language

When developers need to standardize a build around a given programming language, they might require a specific tool like a Python, Ruby, or Java development kit.

running Mobile advertising

Apps may need to connect to publishers and/or ad networks via an SDK to adapt ads to a specific platform and generate revenue.

Running analytics tools

Developers can integrate useful tools like the Google Analytics SDK with their app to collect data about users, usage, and behavioral patterns.

The SDK vs. API debate

Comparing APIs and SDKs as development tools is not as straightforward as it may seem. The two cover similar ground and overlap in significant ways, especially since APIs often form part of the SDK toolkit.

Still, there are key differences between them, and there may be times when a developer must choose one over the other.

While both APIs and SDKs can be used to build innovative features into an app, APIs are a bit more complex than out-of-the-box SDKs, and they require a bit more time, knowledge, and effort to implement correctly. That said, the right set of docs can guide any developer through the process — and, at the other end, they'll find a bit more room for creativity and customization.

Going back to our travel analogy, the API of setting your own itinerary means you can choose which sights you see, but you may miscalculate the travel time, pricing, or opening hours. On the other hand, with an all-inclusive cruise, the choices are out of your hands.

Keep in mind, SDKs aren't just for beginners, and they definitely don't limit what a developer can build. Rather, SDKs are useful whenever a team needs to launch a program or feature efficiently and effortlessly — especially if it's for a non-core, add-on service — so they can focus on mission-critical tasks.

What's more, the best SDKs on the market today are flexible and allow for extensive customizations, so developers can enjoy the same range they'd get with an API but with significantly fewer headaches.

In short: it's not SDK vs. API, but both

Instead of SDK vs. API, it's really SDK and API. Together, these tools make it easier for software developers to innovate on products quickly and confidently — while leaning on expert third-party platforms to abstract away the details.

Learn more about Stytch's SDKs and APIs

Stytch offers both easy-to-integrate APIs and fully customizable SDKs to build your authentication flows the way you want.

You can jump into our docs for a full tour of our product suite — or sign up for a free account to try it out for yourself.

---


# What is the purpose of a refresh token?
Source: https://stytch.com/blog/what-are-refresh-tokens/

A look at refresh tokens in authentication flows – when to use them, security risks to look out for, and best practices for implementation.

When it comes to authorization, developers must carefully-balance security with user experience. On the one hand, if protocols are too stringent, a user can become frustrated. On the other, if authorization is too lax, a security breach is all but inevitable. Fortunately, there’s a solution that fulfills both needs—refresh tokens.

In this post, we’ll explain how refresh tokens work, the benefits they offer for session management, and advanced security measures to consider as you implement them.

What are refresh tokens? How do you use them?

Used within the OAuth 2.0 authorization framework, refresh tokens are a sophisticated method for controlling the length of user sessions within native, web-based, or single-page applications.

Essentially, refresh tokens allow a user to stay logged in for a longer period of time without having to repeat the authentication process, such as by entering their password. This creates a better user experience and provides an extra security layer for sensitive information.

Understanding different types of tokens

A token is a data artifact that can be used to verify a user’s identity. You can think of tokens as digital signatures. There are two main types of tokens that developers can use for authorization:

ID tokens

ID tokens are especially relevant in OAuth 2.0 and its close relative Open ID Connect (OIDC) (common in single sign on authentication flows). We won't go into those in-depth here, but in these transactions the ID token is issued whenever a user logs in. It contains information like a user's name, email, or other factors that may be important. In SSO authentication processes, the ID token confirms the user’s identity is genuine.

Access tokens

Access tokens are credentials for the user to access protected resources such as secured APIs. These tokens are issued by an authorization server and typically have a short lifespan (minutes or hours). Once the access token expires, the user will need to re-authenticate to receive a new access token.

Refresh tokens

Refresh tokens have a longer lifespan (weeks, months, years, even infinite) and are used to automatically request a new access token from the authorization server when the current access token expires. It’s important to note that refresh tokens on their own do not provide the user with any access.

Benefits of refresh tokens

Incorporating refresh tokens can help developers strike the optimal balance between a seamless UX and stepped-up security measures to protect sensitive data. The three main benefits of refresh tokens include:

Uninterrupted user experience

Refresh tokens extend session duration to prevent unnecessary reauthentication. For example, if an access token is only valid for 10 minutes, but the user is on the application for 15 minutes, the session may abruptly terminate. Clearly, this is not ideal and can lead to poor customer retention. A better approach is to use a refresh token, which enables new access tokens to be issued without a delay or additional user effort.

Seamless background activity

Refresh tokens can also be used to make API calls on behalf of the user. The app can receive access tokens in the background without the user intervening or even being present.

Improved security

The use of refresh tokens makes it feasible to shorten the lifespan of access tokens. Since an access token is a bearer token, any user (legitimate or malicious) that possesses it is considered authenticated without any additional identification. The longer the access token remains valid, the higher the risk of it becoming compromised or stolen. Pairing long-duration refresh tokens with short-duration access tokens enhances security without compromising the user experience.

How is a refresh token generated and used?

Refresh tokens are generated by the authorization server at the same time that access tokens are issued. When a user logs in to the application, the following sequence is initiated between the user, authorization serve, and resource server:

The user successfully completes the authorization process.

The authorization server gives an access token and refresh token to the user.

The user provides the access token to the resource server.

The resource server validates the access token, then provides the user with access to the protected resource.

When the access token expires, the user presents the refresh token to the authorization server.

The authorization server validates the refresh token, then provides the user with a new access token.

The user provides the resource server with the new access token to maintain access without restarting the authorization process.



This process of replacing asset tokens continues until one of the following occurs:

The refresh token expires

The user logs out to end the session

The refresh token is revoked or invalidated by the authorization server

The developer institutes a new authentication policy

Improving security with refresh token rotation and automatic reuse detection

Since refresh tokens are intended for long-time use, it’s imperative that they don’t fall into the wrong hands. When a hacker possesses an active refresh token, they have free reign to issue access token requests until the refresh token expires or is revoked. Allowing illegitimate access to your environment can have devastating consequences. Fortunately, developers can add two additional security measures to their refresh tokens:

Refresh token rotation (RTR)

Also called RTR, refresh token rotation turns a refresh token into a one-time-use token. When a refresh token is used, the authentication server provides a new access token as well as a new refresh token. For the duration of the session, refresh tokens are continually exchanged instead of the same token being used repeatedly.

Automatic reuse detection

With RTR, automatic reuse detection is designed to cut off access when a refresh token is deemed compromised. If a hacker gains possession of a refresh token, there’s a good chance the genuine user will use it before the hacker attempts to get a new access token. When the authentication server recognizes that a refresh token was returned for a second time, that token is flagged. In response, the unauthorized user is denied access, and the entire refresh token family is invalidated.



Alternative methods for session management (besides refresh tokens)

Refresh tokens aren’t the only option that developers have for extending user sessions. However, each alternative comes with a concerning drawback:

Silent authenticating (also called continuous authentication) retrieves a new access token if the user still has a valid session, but requires an embedded iframe, which are largely considered an outdated approach.

Cookies can be blocked by modern browser privacy settings such as Intelligent Tracking Prevention (ITP).

Sender constrained tokens require the user to answer a secret security question, interrupting the UX.

Considerations for building and using refresh tokens

When building refresh tokens for your application, several factors can impact their utility and security:

When does the access token expire?

As previously mentioned, the inclusion of a refresh token allows you to shorten the life of an access token without impacting the user experience. The sooner the access token expires, the more refresh flows you may need—but that is often a small price to pay for additional security.

Does the refresh token expire?

A refresh token can remain active indefinitely, or you can set expiry terms based on when the token is issued or the level of inactivity (when it was last used to obtain a new access token).

What safeguards are in place for XSS attacks?

Refresh tokens can be vulnerable to cross-site scripting (XSS). Be sure to follow best practices for testing and preventing these types of cyber attacks.

Where is the token being stored?

Storing refresh tokens in the backend provides the highest level of security. Using the browser’s local storage offers the added benefit of maintaining sessions after a page refresh or a closed browser tab—however, this approach is more vulnerable to XSS and should only be considered when RTR and automatic reuse detection are implemented.

A refreshing approach to refresh tokens and session management

With Stytch’s session management, you can use refresh tokens to provide a seamless and secure user experience.

To get started, sign up for a free account or reach out to support@stytch.com.







---


# Derek St. Onge
Source: https://stytch.com/blog/derek-st-onge/

We're celebrating the one year anniversary of the creation of our recruiting team with the hiring of Derek St. Onge! 

We're celebrating the one year anniversary of the creation of our recruiting team with the hiring of Derek St. Onge! Building a highly ambitious and empathetic team has been one of our top goals from the start (and we knew we couldn't do that alone). Derek has been instrumental in helping us build out today's team of talented constytchuents! Meet Derek!

What do you love most about working at Stytch?

I love my coworkers!

What does a typical day at Stytch look like for you?

Email and applicant review in the morning, meetings and sourcing in the afternoon

What’s been the most surprising thing about Stytch?

How excited candidates are about our mission

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

The constant challenge and open-ended nature of the work requires much more rapid personal and professional growth than a larger company.

What’s your favorite part of the Stytch culture?

Everyone who works here is eager to help each other, and theres a strong sense of empathy in every interaction.

Which Stytch value resonates most with you and why?

"Constytchuents make each other and Stytch better" Recruiting has been a highly collaborative operation since I've joined, and everyone has done a great job pitching in to help grow the team.

What’s the most interesting project you’ve worked on at Stytch?

Migrating from Lever to Ashby. Ashby is a powerful ATS that requires a lot of configuration to maximize its effectiveness. It's been a fun challenge getting it set up to maximize efficiency and data tracking.

How did you end up becoming a recruiter?

I fell into it - followed a college friend into an entry level recruiting position at Google.

When’s the last time you did something for the first time and what was it?

I stuffed a turkey for the first time this past Thanksgiving.

What song, hobby, or recipe got you through COVID?

NY style homemade pizza!

What’s your ideal weekend?

12 hours of sleep a night, a scenic hike in Marin, a Little Star deep dish pepperoni pizza.

What’s something you’re passionate about that’s not on your resume?

Playing basketball

---


# We've moved!
Source: https://stytch.com/blog/weve-moved/

Today, the Stytch team in SF officially moves into its new home at 555 Montgomery Street. 

A new hire chats with Stytch's Head of People Operations about the making of the office move.

Today, the Stytch team in SF officially moves into its new home at 555 Montgomery Street. It’s an exciting moment for Stytch, as a company born during the pandemic and experiencing rapid growth. As a new hire, I sat down and across the screen with our very own Cass Roulund, Head of People Operations, to learn more about the making of the move, what went into finding a new space and what she’s most excited about now that the doors are opening. Please, come on in…

ALI: Ok Cass, let’s warm up. Introduce yourself and tell us what you do at Stytch.

CASS: Sounds good. So I joined Stytch in May 2021, as the first people hire. Back then, there were only 15 of us and since then, we’ve grown like crazy. I manage everything people-related, from HR software, perks and benefits, to happy hours, performance reviews and office moves.

ALI: Nice. You clearly wear many hats here…when did you put on the office move hat?

CASS: The topic of a move started out as a joke between me, Julianna and Reed [Co-founders of Stytch] because there was only ever 5 people in the office at any given time. It quickly turned into a real thing when we hosted Stytch’s first hackathon (in July 2021). There was close to 20 people in the office and we realized that we’re quite big and growing, and that we might need to seriously think about finding more space. It was a weird “should we or shouldn’t we?” moment, what with Covid. We wanted people to feel comfortable enough to come in, but it was also during the Delta wave and pre-booster shots. We weren’t sure if it was silly to go bigger when we didn’t know what was going to come next. We started thinking through the timeline and realized we were hiring at such a fast pace, given our size, that it’s going to need to happen and we should get moving now.

ALI: Where was Stytch located back then?

CASS: In the South Park neighborhood. We moved into an office there in March 2021. Julianna and Reed wanted an office with enough space to mitigate Covid concerns, something accessible without an elevator, away from FiDi (because it was so empty), with great light. It served us really well as a first office place but we definitely outgrew it quickly.

ALI: What were some of the key things you were looking for in a new office?

CASS: Logistically, we were looking for a central location, close to public transportation, with space for calls, conference rooms, something that was move-in ready and had lots of light. We wanted an all hands space to gather. And we wanted a place that we’d be excited and proud to share with our employees and customers and that would let us really invest in community building. That ties back to our perks and benefits philosophy, which is anchored in three pillars: community, productivity and growth. Having a nice office helps you build for those things. We want people to feel good being at Stytch. We want them to be able to do their best work. Physical environments are so important and having a nice place to work from can make you happier and more productive.

ALI: So true. Now that a lot of companies have gone fully remote, do you think about having an in-person office as being a competitive advantage?

CASS: Having an office is a huge recruiting advantage. We are hearing from a lot of our candidates that that’s something they’re looking for––work-life (physical) separation and socializing. A lot of younger people and new grads who I’ve spoken to are looking to build their community and build new connections and that often happens through work. You spend so much of your time there. And having a fully virtual company can really stifle that. But just because we have an office doesn't mean that we're a 5-days-in-the-office kind of place. We're definitely hybrid and office-centric but we want to do it in a way that allows for flexibility. In a post-Covid world, working remotely might not be the right choice or fit for some people. We don't want to exclude those folks, but in line with our "community building" perks philosophy we do want to encourage and provide resources for in-person gatherings and an office (we think) is an important part of that.

ALI: I totally agree. I’m a remote hire and I really appreciated that when I was interviewing, Reed and Julianna made it clear that I could travel to SF as much or as little as I wanted to. It really made an impact on me. I also love that they made office accommodations for those of us in and around the NYC area. It is so nice to have as an option. But enough about me, back to the office move–– tell us more about your journey to find 555 Montgomery.

CASS: We were really specific about what we wanted. We worked with JLL Reality and sent in our specs, so everything was in line with what we wanted. We saw 15-20 spaces over 2-3 big days of viewing, over the course of a few weeks. It was exhausting but also really fun. We saw a range of startup spaces and more commercial spaces (think popcorn ceilings, fluorescent lights, more corporate). We looked at a lot of historic buildings in SF, so it was cool to get that fresh perspective. One thing that we knew for sure, was that we wanted the space to feel good when the lights were off–like you could still do work.

ALI: Ok, so how did you know 555 Montgomery was “the one?” Did balloons come down from the ceiling?

CASS: Hah–no, but we did feel like the elevator doors opened and all of our eyes kind of lit up. 555 Montgomery just felt move-in ready.

ALI: Tell me more.

CASS: It’s 14,500 square feet–pretty big–on the 17th floor. It’s fully furnished. It has room for 150 desks. There are 12 conference rooms plus phone booths. A big all hands space. Windows all around. Picturesque views of Chinatown and North Beach. You can see the bay.

ALI: What are you most excited about?

CASS: The views! It just feels like a place I want to be. I could see myself staying here all night (not that that would be healthy). I’m excited for everyone else to see it today. I think they’ll be blown away. It’s surreal to look for a space as a 20 person company and imagine we’d have that many people. And now––we’re already at 40. I’m excited for it to fill up.

ALI: Shifting to the practical, any venders you’d recommend? Might be helpful to share.

CASS: We’re still in the process of settling into the new office, but totally. Here are the top vendors that come to mind:

JLL: our broker - they helped us streamline the process, made helpful recommendations, and walked us through the entire process, from start to move-in day

Zoom: we upgraded to the biz plan which allowed us to better manage our zoom network and gave our employees more capabilities

InGenius Solutions: partnered with us and Zoom to figure out hardware needed and will help us set everything up in the space for video conferencing and all-hands space

Meter: it’s a startup in SF that we worked with to manage our Wifi networks. Meter covers installation and scheduling. They handled the entire ISP install and will now manage our network.

Office Libations: for snacks and drinks. They have an online portal and you can order what you want. They come in to clean up the kitchen, and do refreshes.

Tinkering monkey: they’re doing our signage. They have cool designs on their website (neon signs, etc.) and might do some mural-like wall work.

Poppin: we didn’t have to do furniture but I’ve used Poppin in the past to do furniture.

Nor-Cal Movers: they were recommended to us by our building and efficiently helped us move across the city while dealing with the specific needs of each of our buildings.

Phin Bar: to help us celebrate the new office move today. I love Phin Bar! They come to your office and make Vietnamese Iced coffees for everyone. The coffee is delicious and strong (beware) and the staff is beyond friendly.

ALI: What’s next?

Cass: I hope to make it feel more like our space. I want to loop in the design team and add our own touch, look and feel. Make it feel like Stytch. Other than that, while growing, I hope to not have to do another office move again for at least another couple of years! Maybe just an expansion to another floor…

Like what you hear? Good news––we’re hiring!

---


# Spotlight on Dennis Huang
Source: https://stytch.com/blog/spotlight-dennis-huang/

Spotlight on Dennis Huang

What do you love most about working at Stytch?

The people! And the sheer variety of things I get to work on.

What does a typical day at Stytch look like for you?

I feel like my days can be all over the place sometimes, but if I had to summarize, it would be a mix of meetings, ideally a few hours of focus time to work on some of my longer-term projects, and handling any one-off requests that come up during the day. I would say my work is a 50/50 split between dashboards/reporting and special projects.

What’s been the most surprising thing about Stytch?

Our culture, and I mean this in the best way possible! I think it's extremely rare to find the blend of kindness and competence we have, and it's really a testament to the whole team that our culture has continued to scale alongside our headcount. Working here is a lot of fun!

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

This may sound obvious, but just how quickly things move at an early stage startup. We're such a different company now from where we were when I first joined, and I have no doubt that we'll be a completely different company in just a few months, if not sooner.

Working at an early stage company definitely requires a level of personal and professional agility/flexibility, but it's also so exciting to see how the company evolves and grows.

What’s your favorite part of the Stytch culture?

I hope I'm not beating a dead horse here, but our team! My co-workers are such wonderful people, and I oftentimes find myself taking a longer than expected lunch break because I'm enjoying the conversations we're having so much.

Which Stytch value resonates most with you and why?

“Own it”

I feel like working in BizOps means supporting the team, and I'm only successful when I can help others be successful. This value resonates with me the most because I'm always trying to find ways to help and unblock others and doing things behind the scenes to reduce friction for everyone else.

What’s the most interesting project you’ve worked on at Stytch?

Building out our internal dashboards. There's nothing quite like that "aha!" moment when you're able to surface and visualize data. It puts everything into focus, and gives everyone else the necessary context to make the next strategic decision.

There's a saying that goes, "if you can't measure it, you can't improve it", and it's been very rewarding to play a part in unlocking some insights for the team.

How did you end up working in Business Operations?

¯\_(ツ)_/¯

In all seriousness, I don't have a great answer here. I started my career in I-banking, and then was a VC for a while. I knew I wanted to transition from finance to be an operator, but I really wasn't sure what functional role would make the most sense for me. Fortunately, BizOps at Stytch is more of a generalist role, and that's given me the opportunity to touch on a really broad range of things.

When’s the last time you did something for the first time and what was it?

I traveled to Africa (South Africa and Mozambique) for the first time for my honeymoon a few weeks ago! I'm still dreaming about that trip.

What song, hobby, or recipe got you through COVID?

I'm not sure if getting a dog counts as a "hobby", but we adopted Dumpling right before lockdowns and she's been a godsend. She gave us an excuse to go for long walks and explore the city, which definitely helped keep us sane! Plus she is very cute :)

What’s your ideal weekend?

A nice hike with the dog, getting some delicious food with friends, and watching an unhealthy amount of football

What’s something you’re passionate about that’s not on your resume?

Fashion. I have way too many pairs of sneakers

---


# 5 Lessons for founding designers: what I’ve learned in my first year at Stytch
Source: https://stytch.com/blog/5-lessons-for-founding-designers/

I lead a seven-member design team that’s split across product design, brand design, and research and partners with just about every other department.

When I joined Stytch as the founding designer in January 2021, the entire company consisted of less than 10 people. One year later, it’s grown to over 40, and I lead a seven-member design team that’s split across product design, brand design, and research and partners with just about every other department.

Looking back, I’ve learned so much. As I chat with others on a similar career path, a few familiar questions keep popping up. Here, I share the five greatest lessons I’ve taken away from this first year and offer some helpful tips for designers facing similar challenges.

1. Defining your role: be honest about your strengths and weaknesses

The best and hardest thing about being a founding designer is that the sky is your only limit. It’s great, because there are so many ways and directions in which to grow. But it’s difficult, too, because there are only 24 hours in a day. If your company is doing well and moving fast, you may feel like you’re constantly playing catch-up in order to make any ground.

I was able to define my role more clearly by creating an organizational structure through which to make key decisions. To begin, I carefully evaluated my skills as a designer, identified my core strengths and weaknesses, and determined where I would have the most impact.

I decided to position myself as the design lead on developer-facing products, as a consultant on consumer-facing products, and as the creative director on branding work. This has given me a good sense of my priorities and greater clarity whenever a project needs additional support.

For the design team, having a transparent understanding of what I’m good at and not so good at also makes conversations about hiring and recruiting a lot easier as we grow our team.

My tip: conduct a thorough self-assessment of your skills as a designer, and don’t pull any punches. You can create your own rubric based on your specific needs or use an existing resource—like this tool from thoughtbot.



My skills assessment

2. Preparing for growth: set up processes ahead of team growth

When your team is small, it’s easy to say, “just ping me on Slack if you need anything.” But as your organization grows, the number of notifications and requests can quickly become unmanageable.

It helped to establish design processes and communication channels as if we were already a larger team, which allowed everyone to develop muscle memory around submitting tickets for requests, leaving feedback before a review, and so on.

In the past year, we’ve set up Linear ticket templates, status pad templates in Figma, formal standards for creating and providing feedback, and a one-pager for aligning on the scope of each project. We also encourage people to ask #team-design whenever they don’t know where to start as a way of spotting gaps in our current structure. This gives us a chance to reinforce our points of contact and quickly iterate on our processes so that they’re scaling along with the company.



At Stytch, we created notepad templates in Figma to collect stakeholder feedback and keep track of status.

Additionally, when we first started documenting visual components in Figma, we began with a rough outline and let it sit untouched for a few months. As more designers joined the team, we decided to use a components audit as the standard onboarding project for every new hire—encouraging them to go in, nit-pick the missing pieces and inconsistencies, and take liberties to improve them. It’s been great seeing the motivation and enlightenment that comes from doing such foundational work with little guidance—and it’s enabled the further expansion of our team.

My tip: let go of perfectionism, and embrace change. As your team scales, be proactive about making necessary updates to your processes, and motivate everyone to step in and help.

3. Expanding your team: start early, and be prepared to pivot

Your team may have breathed a sigh of relief after bringing you onboard as the first designer, but the second hire can be even trickier.

My first phone screening with a potential product design hire was in March, two months after I joined Stytch, and our actual second hire signed in October—half a year later. In between, we adjusted our strategy several times, tweaking everything from our ideal candidate profile to how we structured the hiring process.

We replaced the take-home project with a working session—sharing live prompts and having a two-way conversation around what to do next—to ensure we’re giving the candidate and our team a collaborative experience that’s true to life. With some practice, we were able to get a candidate through the entire hiring process from screening to offer letter within two weeks, which put us in a much better position in this competitive market.

My tip: reduce friction before and during the interview stage. You can use your founders’ and investors’ influence and networks to build credibility while your company is still new and small to offload some of your hard-selling work as the hiring manager. You should also be mindful of potential biases in your hiring process—like take-home projects that assess candidates based on how much free time they can carve out around other jobs and responsibilities.

As Stytch scales, we want to be extra judicious around our recruiting efforts, thinking through how our team is orchestrated instead of remaining in hyper-hiring mode. We want to take time for new hires to settle in and give the existing team a chance to define the next areas of growth before ramping up to the next round of hiring. This will set us up for success in the long run.

4. Optimizing for impact: establish viable work rhythms, priorities, and expectations

I’m often asked, “how do you manage your time?” But I like to rephrase the question and ask myself, “how can I land the most impact within a set amount of time?”

By focusing on impact instead of time, I get a more fluid framework to check in with myself and my team. That way, I can evaluate the goals, timeline, and expectations for my work and feel empowered to make the necessary call—whether it’s investing more in an initiative or letting go.

My tip: define the specific role you’ll play and outcome you expect for every project. A design role can have very different implications depending on the scope or situation. By identifying your ideal contribution to each task, you’ll be able to quickly and clearly lay out priorities, so you can get things done without burning yourself out.



Before we had dedicated support from other departments (e.g. Product), I broke down my role and expectations according to the impact I wanted to have on each project.

5. Managing energy: practice mindful scheduling and self-care as a favor to yourself and others

Working at a startup is a marathon with frequent sprints, and your performance is evaluated at each stretch and across the race as a whole. Over the past year, I’ve learned how to pace myself with appropriate cross-training so that I’m constantly gaining strength without overexerting myself.

For instance, I began managing my energy by auditing and updating my calendar, so the variety of my work can motivate me throughout the week. Kicking off relatively quietly on Monday gives me the bandwidth I need to wrap my head around all that’s been going on, and builds up excitement to connect with my team through one-on-ones on Tuesday.

After a long Tuesday of meetings, spending Wednesday diving into meaty topics often feels refreshing and fulfilling. On Thursday, I often schedule updates and demos across the team, which is energizing. And I set aside a chunk of time each Friday to review the pain points and opportunities that emerge situationally as the company grows. Taking some moments to look through the haze can turn that chaos into an afternoon of fun, adventure, and fresh ideas.



I rearranged my calendar to better balance my energy and keep a sustainable work rhythm across each week.

My tip: arrange your schedule intentionally with a rhythm that works for you, set strict boundaries around your off-hours, and actively plan vacations. In addition, allow yourself small breaks like short walks between tasks. A breather usually only takes 15 to 30 minutes, but making a decision in the wrong headspace can cause hours or even days of damage.

Key takeaways

Here are the steps I found most helpful as I learned the ropes as a founding designer:

Capacity: complete an honest self-evaluation of your design skills and shortcomings so you can better define the role you’ll play in each type of project.

Organization: set up working processes early, even if that means they’re initially unpolished. There will always be room and time for improvements later.

Hiring: make the process easy on your candidates and your team by keeping interviews and assessments collaborative and true-to-life.

Productivity: identify the impact you want to have on every project rather than the time you want to spend, so you can easily map out and manage your priorities.

Self-care: schedule your time and tasks in a way that balances your energy and gives you space to take breaks and restore your focus.

Reflecting on this past year, I’m fascinated by how my time at Stytch has helped me to evolve both personally and professionally. I’ve not only become a better leader and collaborator but also, I’ve defined critical areas where I can continue to grow. I’m very excited to see where this journey will lead us next.

---


# Build vs. buy: what to consider when setting up an auth flow
Source: https://stytch.com/blog/build-vs-buy/

Deciding whether to build new software and features in-house or buy an API or SDK solution from a third-party vendor is a question engineers face on a regular basis. 

Deciding whether to build new software and features in-house or buy an API or SDK solution from a third-party vendor is a question engineers face on a regular basis. When it comes to your authentication flow, that choice can have major implications for security—not to mention your user and developer experience and the resources you’ll dedicate to implementation and maintenance.

Below, we review the criteria product and engineering teams should keep in mind when putting an authentication flow in place—and examine why turnkey solutions are becoming a popular way to boost efficiency, enhance security, and optimize user engagement and conversion.

The pros and cons of build vs. buy

There are many factors your engineering team might consider when weighing whether to build an authentication flow in house or turn to third-party specialists, but here are the top four:

Opportunity Cost

Rolling your own auth means you control the process and can custom-build to your app’s needs. But you’re also going to spend a lot of time and effort doing it. While buying a readymade solution may seem like a high upfront cost, creating that same solution in-house—along with a robust sandbox environment to support and secure it—is more expensive than you might think.

In addition to the initial build, you’ll have to factor in engineering costs around maintenance and upgrades as bugs emerge and industry trends evolve.

On top of that, engineering projects often go over time and budget. An early study found the average overrun to be 27%, with one in six companies overshooting estimates by 200% or more. That is valuable time that could be spent focusing on building your roadmap.

Complexity

Any authentication solution introduces unique challenges and takes significant effort to architect and implement, which can take focus away from building your core product. This is especially true of novel solutions such as session management, biometrics like WebAuthn, and high-converting flows like Google One Tap.

In other posts, we lay out the many steps that go into building auth solutions like SMS one-time passcodes and email magic links—and that’s if you only implement one. You’ll need to repeat the process if you want to leverage the significant security benefits of multi-factor authentication (MFA).

Authentication providers can save you time, resources and headaches by ensuring you get a secure solution right out of the box. Edge cases with provider integrations can be costly over time. But some providers, like Stytch, also wrap in access to particularly tricky (but valuable) options like route-based (or just-in-time) authentication, which lets you stagger verification factors according to the sensitivity of a user’s actions, introducing extra friction only when it matters most.

Security

Dealing with app security can be a burden for engineers and open your site to potential risks and threats. To assess your appetite for taking on this risk and security management in house, ask yourself:

How sensitive is the user data your app handles?

What are the possible consequences of a data breach?

Does your team have the time and capacity to respond in real time and troubleshoot as security vulnerabilities arise?

Depending on your answers, you may want to partner with a company dedicated to handling these very issues. Top authentication providers—who are used to managing high-stakes flows, including for large-scale financial institutions—are SOC 2 Type II certified, run frequent security audits, and take proactive steps to keep up with the latest threats.

Auth expertise

Tech moves fast—really fast. Building innovative user experiences and authentication flows often requires inside knowledge across a variety of verticals, each with its own endpoints and edge cases. It also takes staying current to new innovations and technologies in the auth space.

You can designate a member of your team to keep up with shifting industry best practices and continually update your auth. Or, you can turn to a third-party provider that’s steeped in these details and navigates the ins and outs of key edge cases for you.

How a turnkey auth solution can boost your business

In recent years, and with rising numbers of reliable, easy-to-integrate APIs and SDKs on the market, many engineering teams have decided to buy auth solutions instead of build them from scratch. Some of the reasons your company might choose to partner with a third-party authentication partner include:

Efficiency

Opting for a pre-built solution takes the heavy lifting off your engineering team, gets your auth up and running quickly, and allows you to focus on optimizing your core product.

Savings

Authentication providers are often able to consolidate their resources and offer solid solutions at lower cost due to increasing economies of scale.

Simplicity

With an auth provider, your team gets a quality solution right out of the box. You can even choose between APIs and SDKs depending on how far in the weeds you want to get with integration and customizations.

Security

Partnering with experts means your team can offload the anxiety of safeguarding your data and let your authentication partner worry about the details.

Support

Auth providers are tuned in to the latest industry best practices and keep their products up to date to drive better performance and conversion rates for partnering apps.

Stytch tops the list

Once you’ve decided to go with a third-party solution, the question then becomes, what is the best authentication provider for your app?

There are a few reasons Stytch stands out and offers the best auth solutions on the market:

Flexibility

Because of the way we’ve structured our direct APIs and customizable SDKs, Stytch works entirely in the background to secure your app. Your team owns everything with the UI and UX, so users get an experience that’s 100% on-brand.

Easy integration

We don’t need to tell you that clear, accurate docs can make or break an integration. Stytch is built by developers for developers. We get our partners fully integrated in a matter of days, and our team is always available to jump on a call or chat.

Built-in redundancy

With service-based auth flows via email and SMS, communication providers can be a point of failure, effectively shutting down your login flows and user acquisition with any downtime. Stytch monitors uptime and latency, routing to multiple providers to ensure your users always have a high quality experience.

Better UX and conversion

As a passwordless solution, Stytch doesn’t sacrifice user experience for security. We keep friction low and track performance metrics with our SDKs, so we can identify where users might be falling off your auth flow and work with you to boost conversion.

Scalability

As your app expands, more users will demand more flexible authentication options. Stytch takes a one-stop approach to auth, with a variety of solutions wrapped into a single cost.

Key takeaways

While the buy or build debate is never simple, some careful consideration can easily tip the scale when it comes to authentication.

Ultimately, you may decide that it’s worth letting a third-party auth provider own the costs and hassles of managing your flow, so you can focus your time and resources on your business.

Learn more

Our passwordless solutions make authentication simple, with easy-to-integrate APIs and SDKs that are fully customizable to your brand.

Get started for free today.









---


# Password reuse is a cybersecurity threat
Source: https://stytch.com/blog/password-reuse-is-a-cybersecurity-threat/

Good password hygiene has always been the top security measure to avoid data breaches. However, with so many websites, e-stores, and social media sites each requiring strong but unique passwords, it becomes hard to remember them.

A CyberNews interview with Stytch co-founder Reed McGinley-Stempel

Good password hygiene has always been the top security measure to avoid data breaches. However, with so many websites, e-stores, and social media sites each requiring strong but unique passwords, it becomes hard to remember them.

Having to continuously make up long and difficult-to-guess passwords results in users compromising security for sanity––they are resorting to password reuse, which can lead to countless breaches.

While there are known and convenient solutions that users can adopt, such as password management tools, organizations implementing measures such as passwordless authentication on their platforms could dramatically improve security.

For this reason, we invited Reed McGinley-Stempel, the CEO and Co-Founder of Stytch, a company that specializes in passwordless authentication, to discuss the relevance of authentication methods and cybersecurity issues.

How did Stytch come about? What has the journey been like so far?

Authentication is a frustrating experience for both developers and users. Julianna Lamb and I recognized the problem and set out to solve it. While working together at Plaid, we witnessed the security and user experience shortcomings of password-based authentication and founded Stytch to create the developer platform for passwordless authentication that enables software teams to easily build experiences that delight their users.

It’s been an incredible journey so far. We believed passwordless adoption was inevitable, but it has accelerated much faster than we honestly expected, with even major organizations like Microsoft moving to a passwordless framework last year. The trend is growing even faster in 2022, and we’re excited to be building the tools that make it easy for developers to quickly and safely adopt passwordless authentication in a way that works for their users.

Can you tell us a little bit about what you do? What challenges do you help navigate?

As the internet has matured, it’s removed numerous points of friction, but authentication continues to pose significant security, privacy, and usability challenges. For many reasons, the old standard of a password and username simply doesn’t cut it anymore. But requiring users to create complex password and username combinations for each service they want to access can be cumbersome and inefficient. It increases user drop-off rates at both sign-up and login, directly contributing to higher customer acquisition costs (CACs) and lower lifetime values of users (LTVs). Our platform enables developers – who normally face tremendous time and effort hurdles in building authentication workflows – to build great applications that provide both safe, secure authentication and great user experiences.

How do you manage to ensure secure authentication without compromising the user experience?

A great user experience and secure authentication are not mutually exclusive. In fact, just the opposite. Friction on the Internet can be eliminated while improving security. 81% of all data breaches online stem from insecure passwords. And the friction of passwords primarily contributes to these security issues – when users are asked to create countless, complex passwords every day, it’s no surprise that users instead choose to reuse the same password that they use on many different sites. This creates a chain of risk when one of those services is breached.

Our customers experience major conversion increases and fewer security risks simultaneously every day. How we do it is by providing a wide variety of passwordless authentication solutions for different business needs. There are many options on the table, including email magic links, SMS one-time passcodes, WebAuthn (TouchID/FaceID and YubiKey support), OAuth, and multifactor flows using a combination of these methods.

We’re building solutions that reimagine user infrastructure, starting with out-of-the-box and customizable passwordless authentication products that are easy for engineering teams to integrate. With our flexible APIs and SDKs, our customers can improve user conversion, retention, and security – all while saving valuable time.

Have you noticed any new cyberthreats arise during the pandemic?

Cybersecurity can seem like a game of whack-a-mole. No sooner do security experts get wise to the latest threats than attackers modify their tactics, discover fresh vulnerabilities, and develop new lines of offense. We’re seeing a rise in all forms of cyberattacks, from malware to phishing and denial of service (DoS) attacks. There’s also a constantly growing arsenal of cybersecurity threats, with others including zero-day exploits, Internet of Things (IoT) attacks, rootkits, and cryptojacking. In the fight against cyberattacks, we’re equipping developers with the latest, strongest passwordless products, from email magic links and SMS one-time passcodes to WebAuthn built-in biometrics and specialized hardware keys.

What are the main issues associated with password-based authentication?

Password overload is a ballooning issue. Surveys have found that the number of password-protected accounts per user has increased exponentially in recent years, in response to an explosion of new apps and online services. One study found that between 2019 and 2020 alone – with people likely spending more time online due to the COVID-19 pandemic – the number of passwords per user jumped 25%, from an average of 70-80 to 100.

​​A recent poll also showed that most users don’t take advantage of existing password managers. As a result, 37% forget a password at least once a week, increasing the likelihood they’ll abandon a commercial account or leave a purchase incomplete.

A seemingly logical solution to password vulnerability – mandating more complex and therefore more secure passwords – is not viable. The variety of password requirements proliferating across platforms poses major usability challenges, as Internet users confront byzantine protocols to set and reset convoluted passwords that prompt many to abandon the desired task in the first place.

Moreover, experts argue that despite the oft-noted trade-off between security and usability, other efforts to improve password security are self-defeating. Requiring frequent password changes or preventing paste functionality simply leads people to adopt weaker passwords and repeat them across accounts, threatening a cascade of breaches.

In your opinion, why do certain organizations fail to recognize the need for quality authentication solutions?

Given the shortcomings of passwords, the shift to passwordless authentication feels inevitable. Still, skeptical companies may be reluctant to abandon authentication solutions they’re familiar with. A common mistake in recent years has been treating alternative authentication methods as second-factor, rather than primary-factor, candidates.

Most companies are unaware that they already have passwordless flows in place, and they’ve needlessly complicated these processes for users. Whenever a customer passes through a site’s password reset protocol, they’re essentially experiencing passwordless authentication.

One of the main problems in moving to passwordless authentication: for developers building out authentication flows, it’s a time-consuming and error-filled process that can involve multiple engineers and many months of maintenance annually. That’s what Stytch’s platform helps them overcome.

Besides quality authentication methods, what other cybersecurity measures do you think companies should have in place to protect both their workload and customer data?

Strong encryption for sensitive data at rest and data in motion is always recommended. Additionally, taking advantage of modern vulnerability scanning tools like Snyk is understandably a popular defense mechanism. Overall, embedding security engineering training into all engineering functions regardless of whether they are on the security engineering team is critical to building a culture of security.

Talking about the future, do you think biometric authentication is going to surpass other authentication methods any time soon?

We think biometric authentication is poised to see a huge uptick of adoption in the next couple of years. Historically, we’ve only been able to use biometrics with native iOS and Android applications. They haven’t been available in web-based experiences – however, with the introduction of the WebAuthn protocol, that’s finally becoming possible. This provides biometrics their best chance to become ubiquitous. While WebAuthn is really promising, it’s also complex to integrate, which is why we offer it through simple API integration with Stytch.

Would you like to share what’s next for Stytch?

We have more biometric authentication products coming out soon, and we’re also releasing a number of products in the Web3 authentication space. Web3 authentication has some definite UX shortcomings today, but if those are overcome, there are some really compelling fundamental shifts to how users authenticate in Web3 that we’re quite excited about.

READ THE FULL ORIGINAL ARTICLE>>

by Kristina Jarusevičiūtė, Cybernews







---


# It's a Stytchiversary! Meet Nikhil Dilip, software engineer
Source: https://stytch.com/blog/stytch-spotlight-nikhil-dilip/

It's a Stytchiversary! Meet Nikhil Dilip, software engineer

What do you love most about working at Stytch?

We're working on a problem that affects both developers and end users in every aspect of their daily lives. Struggles with passwords, login experiences, and breaches are frustrating and ubiquitous -- solving a problem space that large is very motivating. Our new SF office is pretty sweet too.

What does a typical day at Stytch look like for you?

It depends! Tuesdays and Thursdays tend to be more meeting-heavy, meaning that I'll spend time syncing with my teammates about their projects, pairing on more complicated tasks, interviewing candidates, or meeting new coworkers. The other days I'll have more deep focus time; depending on what phase of a project I'm in, that'll either be working on a design doc, writing code, or reviewing my teammates' docs/code.

What’s been the most surprising thing about Stytch?

Stytch is the first early-stage startup I've worked at, and I expected it to be chaotic. I learned that wasn't the case on the very first day. From a streamlined onboarding experience to a very intentional and methodical quarterly planning process, I've found Stytch to be the perfect blend of fast-moving excitement and focused execution.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

Communication is really important! The decisions we make now set the foundation for our future -- this is true for building both a product and a culture. Clear communication, especially at our remote-friendly company, is paramount at the early stages.

What’s your favorite part of the Stytch culture?

My coworkers! Working with a group that is both intelligent and empathetic is rare and enjoyable. I learn something new from my teammates every day and have a great time building new products with them. At such an early stage, I'm able to interact with every employee, which has taught me so much about building a business and a brand beyond just the technical aspects of our product.

Which Stytch value resonates most with you and why?

“Constytchuents make each other and Stytch better.”

It's amazing to work at a company where everyone is focused on improving themselves and those around them. Everyone is motivated by solving the same set of problems and is willing to jump in to help when you need it. This also means that we're all entrusted to do what we can to improve the company. Our culture gives every employee the freedom and responsibility to construct a positive work environment.

What’s the most interesting project you’ve worked on at Stytch?

I really enjoyed building our TOTP Authenticator App product for two reasons. First, security and flexibility are very important to us at Stytch, so it was fun to work on a product that allows developers to easily integrate a secure mode of authentication. Second, it demonstrates the value of our API-first approach. TOTPs are a perfect example of a just-in-time authentication use case that gives end users a secure yet simple user experience.

How did you end up working in software engineering?

I grew up in the Bay Area, where it's hard to not hear about tech! I was able to learn enough computer science in high school to know that I wanted to major in it in college, and I've been a software engineer ever since.

When’s the last time you did something for the first time and what was it?

I went snorkeling with manta rays last week when I was in Hawaii! Highly recommend it, they're much larger than I thought but still very gentle.

What song, hobby, or recipe got you through COVID?

I picked up both running and cycling during the pandemic, which really helped me stay sane. SF has so many trails and roads I'm still exploring.

What’s your ideal weekend?

Usually meeting up with friends at fun restaurants, bars, or parks around the city. I watch too much sports, particularly Bay Area teams: Warriors, 49ers, Cal. I like to to squeeze in a long run through Golden Gate Park and/or a bike ride in Marin as well.

What’s something you’re passionate about that’s not on your resume?

I love doing most kinds of puzzles. Crossword puzzles, trivia nights around the city, watching Jeopardy, all of that.

---


# What is WebAuthn?
Source: https://stytch.com/blog/what-is-webauthn/

In our latest post, we go a level deeper on WebAuthn to share what it is, why it’s so exciting, and what are considerations for implementing it.

We’ve said it before and we’ll say it again, WebAuthn is one of the most exciting passwordless technologies available for both engineers and for users. In our latest post, we go a level deeper on WebAuthn to share what it is, why it’s so exciting, and what are considerations for implementing it.

WebAuthn, MFA, and U2F

The Web Authentication API (WebAuthn) is a specification that allows web applications on supported browsers to authenticate a user via authenticator types such as built-in device biometrics (e.g. facial recognition on mobile and fingerprint readers on desktop) or secure hardware keys (e.g. YubiKeys).

To understand WebAuthn, we need to understand its relationship with MFA and U2F.

Multi-factor authentication (MFA) is quickly becoming standard practice for security-minded organizations and individuals. It consists of multiple layers of security that range from one-time passcodes to voice authentication.

Universal second-factor authentication (U2F) ties two-factor authentication to a physical component, verifying a user’s identity by leveraging a USB or NFC (near-field communication)-based piece of hardware that sends a unique private key to the server.

WebAuthn allows MFA and U2F protocols to be easily integrated into web-based services or applications. By streamlining the integration process and creating an open standard for engineers to build on, WebAuthn makes secure passwordless authentication accessible and compatible with a variety of authentication factors.

How WebAuthn works

WebAuthn uses public-key cryptography to authenticate users and protect against even the most serious cyber attacks. Public key cryptography is an encryption scheme built around the relationship between two unique keys—a public key and a private key. These keys play an important role in securing data, with the public key being used to encrypt the data and the private key being used to decrypt it. This is why public-key cryptography is sometimes referred to as asymmetric cryptography—as opposed to symmetric cryptography, which uses one key for both decryption and encryption.

The public key is stored on the server, while the private key can be stored either on the local operating system or on a hardware security module like a USB or biometric scanner. When a user authenticates, the private key sends a message with a unique signature to the public key, which then decrypts access to the server.

Using this scheme as its foundation, WebAuthn establishes a uniform interface for implementing passwordless authentication across web-based services. First published in 2016 by the World Wide Web Consortium (W3C), it has quickly become one of the fastest growing new standards for passwordless authentication.

The benefits of WebAuthn

The benefits of using WebAuthn for passwordless authentication are as follows:

Reduced friction: integrating WebAuthn into your application means reduced friction for your users. It’s a seamless experience to authenticate with your registered device or hardware key.

Enhanced security: based on public-key cryptography, WebAuthn’s reliance on hardware security modules or biometrics for passwordless authentication provides unparalleled security. With cyber attacks becoming more complex and data breaches becoming more frequent, WebAuthn is a trustworthy choice as an "unphishable” authentication factor.



WebAuthn-supported authentication factors

WebAuthn enables you to support a multitude of hardware-based authentication factors to verify a user’s identity:

Biometrics: biometric authenticators are devices that use fingerprints or facial, voice, or retinal scans to authenticate users. These authenticators can be connected to a variety of devices via USB port, Bluetooth, or NFC technology. Connecting a biometric authenticator to a specific device ties it to that device's physical location or domain. To authenticate, a user needs to verify not only their biometrics but also their location, effectively preventing phishing scams.

Device-based biometrics: many devices today, including most Macs, iPhones and Androids, support device-based biometrics such as FaceID, TouchID, or similar.

Security keys: similar to biometric scanners, security keys can be connected either via USB port, Bluetooth, or NFC. Where biometric devices ascribe to the principle of “something you are,” security keys work off the “something you have” principle. Similarly, being tied to a physical location or device makes them an effective way to prevent phishing. They are also more widely supported than biometric scanners when it comes to U2F/WebAuthn-enabled applications.

YubiKeys: while similar in functionality to a security key, a YubiKey comes with the added security measure of being able to store time-sensitive one-time passwords (OTPs). This means that on top of WebAuthn-powered U2F, YubiKeys have their own proprietary authentication method. When a YubiKey connects to a device, it generates an OTP with an individual timestamp to authenticate access.

Pros and cons of WebAuthn

While WebAuthn has reduced friction when it comes to implementing passwordless authentication, it is not without its challenges. Browser support is a factor that should be taken into consideration when developing a WebAuthn app. Though WebAuthn supports Chrome, Windows 10, and Safari, support is not yet uniform in regard to feature parity.

While it’s early in adoption, WebAuthn continues to evolve. As it does, the number of supported browsers and devices that support it will continue to grow, providing companies and end users alike with unparalleled security and versatility.

While WebAuthn has many benefits, engineers and product teams need to understand the API to implement it securely. Stytch's WebAuthn product simplifies the process by abstracting the implementation details of WebAuthn so that integration is as quick and secure as possible.

Find the right WebAuthn solutions with Stytch

At Stytch, we know how important it is to find the right fit. That’s why our flexible APIs make it simple to use WebAuthn as a standalone authentication option or second factor to strengthen security.





---


# Auth0 pricing (and four other reasons to choose Stytch)
Source: https://stytch.com/blog/why-stytch-over-auth0/

One of the most common questions we're asked by developers is: "Why should we choose Stytch vs. Auth0?"

One of the most common questions we're asked by developers is: "Why should we choose Stytch vs. Auth0?"

It's a fair question. Auth0 has been around for nearly a decade, while Stytch is relatively new to the authentication space (founded in 2020). That said, age isn't everything, and it may even be holding Auth0 back. More on that below.

So, if this is the first time you're learning about Stytch (a special shoutout to readers who got here by searching "Auth0 alternative") we've prepared a list of the key ways in which we outperform the competition — starting with Auth0 pricing and working our way through the flexibility, reliability, and usability of our respective platforms.

Looking for a point-by-point comparison of Stytch vs. Auth0? Check out our complete buyer's guide here.

Let's summarize our five key advantages before diving into the details and exploring why many Auth0 customers are switching to Stytch.

Cost: Auth0 pricing jumps when you need auth and access management tools beyond the bare minimum, while Stytch offers pay-as-you-go rates that decrease as you scale.

Flexibility: Stytch solutions can be fully tailored to the look, feel, and flow of your app and brand, while Auth0 limits edits to widget-based customizations.

Reliability: Stytch offers built-in redundancy and failover logic to mitigate vendor downtime, but Auth0 requires you to BYO integrations with no redundancy allowances.

Integration: Stytch's docs are easy to read and implement for a quick integration. Meanwhile, Auth0's docs are extremely complex.

Innovation: Stytch offers a range of frictionless auth solutions through a single platform in addition to breach-resistant passwords, while Auth0 continues to focus on a more traditional password approach.


Now, let's take a closer look.

1. COST

Simply put, Auth0 pricing models and calculators hide the true cost of their services. The more volume you handle and the more features you need, the more you pay, which can make it difficult to forecast costs at scale.

Typically, Auth0 pricing works out to be two to three times higher per user than Stytch. Their free plan offers only limited features, and you're forced to upgrade to enterprise pricing to add even basic passwordless solutions — like OAuth, multi-factor authentication (MFA), one-time passcodes (OTPs), and WebAuthn — or to turn on advanced user role management options like admin roles and consolidated user stores. With Auth0, higher user tiers mean more expensive paid plans, which may require contracts with external marketplace vendors at an additional cost.

Stytch, on the other hand, offers simple, flexible pricing through our partnership model.

With Stytch, pricing starts at a transparent 5 cents per active user with unlimited logins, and it quickly decreases as you scale. That means no monthly commitment and no enterprise plan. Our pricing model aligns with your business model, and we only make money when you authenticate users — so you never pay for anything other than usage.

Don't just take our word for it. You can see our full pricing structure here, including the details of our free plan.

2. FLEXIBILITY

Whether you're a startup or an enterprise, you shouldn't have to compromise the look and feel of your product (or your brand's unique personality and style) for any vendor — even for a service as important as authentication.

In most cases, your first "write" interaction is the user signup flow, which means it's the first chance a user has to form an opinion about your app and how it works. Most drop-off occurs at this stage, so it's critical for the experience to leave users with a positive impression. That's why flexible solutions are core to Stytch's offerings.

Stytch offers both a direct API, which allows you to own your UI and UX from end to end, and highly customizable SDKs for Javascript, React, iOS and Android. Unlike most SDKs, Stytch gives you complete control and enables you to call the Stytch API directly from your browser.

The result is a wide range of sign up and log in options, enabling organizations to build on-brand auth and access management flows.

In fact, Stytch's customizable frontend components work seamlessly within custom domains with no hosted redirect page required. This delivers an auth experience that's fine-tuned to your brand and to your users' expectations. Our adaptability to different auth and access management scenarios is why Gather chose us over the competition.

"When we started thinking about building our auth, I looked at three solutions: Auth0, Magic Link, and Stytch. It became clear playing with each that Stytch was going to be the most flexible."

— Ryan Rosztocy, Founding Engineer, Gather

In comparison, Auth0 stymies their customers' creativity because they prioritize passwords. This requires them to maintain strict control over forms and domains and limits their flexibility to widget-based customizations.



3. RELIABILITY

When it comes to authentication, it's important to provide end users with a seamless experience not just the first time, but every time. That's why Stytch strives to build passwordless authentication solutions you can rely on and simpler yet more secure password-based flows. Our customers depend on us for critical infrastructure, so we invest heavily in ensuring we can maintain exceptional uptime percentages. You can see the results for yourself on our status page.

Stytch builds redundancy into every communication-based auth product, monitoring uptime and using dynamic failover logic to route across multiple providers.

This ensures vendor downtime doesn't impact your platform and that your users can enjoy a high-quality, uninterrupted experience with no single point of failure.

In contrast, Auth0 compels you to provide your own integration for communication APIs, which are required for service-based auth via email and SMS. What's more, the Auth0 platform doesn't allow for any redundancy. While this isn't always front-of-mind for developers choosing an auth provider, we've learned through experience that it's vitally important.

Case in point: at a previous company, our service provider experienced two days of downtime, during which we couldn't authenticate any user visiting our platform. This was extremely painful. It felt like we'd just poured our heart and soul into opening a new restaurant and then had to turn customers away at the door due to a broken stove. It took us over two months to solve the issue by building out a backup provider. Ultimately, our poor decision not to plan for redundancy negatively impacted not only our business but our productivity, since development teams had to be pulled away from core projects they were working on.

Take it from us: Users won't be able to access your services (or give you their money) if you can't reliably authenticate them. And if they detect a dip in service, they're much more likely to churn. It's important to maintain gold-standard uptimes, avoid interruptions, and offer timely service and enterprise support to resolve any issues.

“We experimented with several auth providers, but Stytch was the easiest to use by far. We also saw that Stytch had a number of handy features in the works, and we’d get access to a whole system of integrated, innovative products through one simple integration.”

– Omar Torres, Co-Founder, Chessly

4. EASE OF INTEGRATION

Your time is valuable. Developer to developer, we know that you don't want to spend it implementing auth. You'd rather focus on your core product.

That's why Stytch is designed to get you up and running in minutes, whether you're building an auth solution from scratch or migrating from another platform. It all starts with our clear, easy-to-implement documentation.

"Our product team was blown away by Stytch's ease of use. The integration was effortless compared to other tools, because we had so much support. Partnering with Stytch really eliminated the pain of having to manage and maintain an immense authentication system."

– Paul Bergamo, Product Lead, Bitcoin.com

Auth0's documentation, on the other hand, is incredibly difficult and time-consuming to decipher, adding unnecessary complexity to the integration process. This is largely a byproduct of their various builds and migrations — and the issue is only amplified when you attempt to level up and go passwordless.



Auth0 doesn’t make it easy for you as a customer–with docs that are overly complex and don’t include copy/paste examples for their client libraries.

Authentication is a crucial part of your app, but you shouldn't have to spend days reviewing docs or weeks implementing them. Standard Metrics (formerly Quaestor), chose Stytch for our intuitive docs and our laser focus on the developer experience. Full implementation took their one engineer less than a day — and, within a few months, around 35% of their monthly active users were logging in passwordlessly through Stytch.

5. INNOVATION

The most fundamental difference between Stytch and Auth0 is also the most important. In addition to conventional auth methods like passwords, Stytch offers many more modern options like passwordless authentication, while Auth0's architecture is primarily password-based. That means Stytch is keeping up with the most innovative and forward-thinking auth solutions to provide secure access.

When Auth0 first started out, password-based auth was the norm. Unfortunately, while they've since started exploring passwordless solutions, they've largely maintained the status quo and their passwordless offerings are relatively shallow.

In stark contrast, Stytch was founded on the belief that passwordless authentication is the way of the future.

Passwords are a dated auth method that causes needless friction, frustrated users, and lower conversion rates. They're also much less secure. As internet use has exploded, password reuse has become a ballooning issue. In fact,81% of recent online data breaches involve a weak or stolen password, and the latest industry standards consider all traditional passwords to be "pre-breached."

Luckily, auth technology has evolved to meet this challenge, and passwordless-native platforms like Stytch are leading the way.

With Stytch, you can boost both security and UX with intuitive, low-friction solutions like OAuth and OpenID. They're part of an integrated, all-in-one platform, with an evolving product suite that includes the newest, highest-converting passwordless auth methods, like Google One Tap and embeddable magic links. Google One Tap is a particularly powerful way to improve onboarding and login transactions, and companies that have implemented it have seen impressive results. For example, Pinterest achieved a 47% increase in signups on desktop and a 126% increase in signups on Android.

Great user experiences translate to real business impact. Consider our partners at Lighthouse, an innovative rental platform. Lighthouse originally partnered with Auth0, but they felt hemmed in by the platform's rigidity. After switching to Stytch, they were able to offer more flexible auth and access management experiences to their users — and saw a 62% jump in conversions after they did.

The bottom line

Stytch not only offers more affordable authentication solutions than Auth0, but more flexible, reliable, and frictionless experiences for app developers and their customers.



Discover a modern approach to authentication

So, what does migrating to Stytch entail? Glad you asked. It's actually pretty easy to switch your users to Stytch by following the steps and tips in our handy migration guide.

If you want to learn more about the differences between Stytch and Auth0, visit our Stytch vs. Auth0 comparison page — or reach out to our team to get your questions answered.

---


# Making research an integral part of your product strategy
Source: https://stytch.com/blog/leading-with-user-centered-design-at-stytch/

Making research an integral part of your product strategy

When you’re developing a product or service, step one is understanding the needs of the people who will use it. Still, many startups wait to hire research roles, because the benefits seem soft and tenuous when compared with the instant payoffs of launching something quickly.

Everyone knows the story of the three little pigs, but not enough startups take its message to heart. While building something quickly has its place, the company that best understands its purpose tends to win out in the end.

To put that in tangible terms, the 1-10-100 “cost of quality” rule states that it costs 10x as much to correct a product’s design and 100x as much to fix its development than it does to prevent an issue in the first place through proper research. And it holds up. One Forrester report shows that, on average, every $1 businesses invest in user-centered research yields $100 in returns.

I joined the Stytch design team as the first research hire in the summer of 2021, after a decade at other startups. Across that experience, I’d noticed a common trend. When product teams embraced research as part of the development process, they felt more confident in their focus, more aligned on their use cases, and more efficient in meeting their goals.

I brought those lessons with me to Stytch, used them to establish research as a pivotal aspect of our product design, and saw immediate results.

Below, I share some ways you can take advantage of research to help your team gain foundational knowledge, use time and resources effectively, and expose blind spots in the discovery and onboarding process, so you can optimize both your product and your productivity.

Lean on evidence, not guesswork

When you’re at an early-stage startup, there’s no shortage of ideas. Between brainstorms and feature requests, thoughts are always coming your way. It can be tough to cut through the noise and identify the actions your business needs to take to thrive.

But if you base key business decisions on your immediate assumptions or reactions, they’ll reflect the biases of your team, not the desires of your users. This is known as the false consensus effect, or the tendency to overestimate the extent to which your preferences are shared by others.

Conducting a bit of customer research upfront can help you avoid wasting efforts on a product that doesn’t actually solve your users’ problems.

At Stytch, I ask my team to list their assumptions about how our users behave, make decisions, and think about a certain product early in the design process. That helps us build studies, validate or disprove theories using objective data, and learn more about our customer base.

For instance, we initially assumed engineers were the ones choosing an authentication platform based on what they thought were the best security features on the market. Instead, we found decisioning power varied from C-level executives to product managers to entire development teams and often rested on unique end-user needs. A health startup, that is, may require certain levels of HIPAA compliance baked into their authentication.

This sort of insight only comes from posing the right questions—and then answering them through the right level of research.

Uncover your blind spots

As you develop or update a product, you’ll find yourself in situations you never saw coming—often due to factors that weren’t considered at the outset but emerge as major takeaways from research. I call these blind spots, and it’s critical to bring them into focus before starting a project, so you can make effective use of your time and resources.

For example, at Stytch, we realized we hadn’t considered how long it might take developers to evaluate and select an authentication provider. Through research, we found they tend to rely heavily on their familiarity with a given tool and then make a quick choice. Trust is incredibly powerful when implementing a critical service like authentication, and establishing a sense of familiarity can go a long way toward building it.

With that in mind, we were able to redirect design and marketing efforts to make our products more familiar and accessible to developers before they even needed an authentication solution, ultimately giving Stytch a leg up during the decision making process.

Now, we keep a diagram of the “decision sandwich” on hand to remind our team how important familiarity and customer needs are to our product development.



The “decision sandwich” helps the Stytch team keep customer needs and
product familiarity front of mind.

Understand your use cases

For startups, it can be hard to zero in on the right user experience. There are many competing factors to consider, from what competitors are doing to how industry trends are evolving to what reviewers are saying. It’s easy to forget that the only experience that matters is the one that helps your customers and your business meet their primary goals.

Prioritizing research at the outset of a project helps you set a benchmark for success. You can always come back to your roadmap later to ensure you’re still on the right track and addressing the right problems (and adjust your approach if you’re not).

After working to understand our customers’ decision-making process, the next logical step at Stytch was to make sure our onboarding was up to scratch. So, we did some foundational research to learn what happened after developers chose us as their authentication provider.

We found that they often dove immediately into our docs and explored the possibilities before selecting and setting up a specific product like email magic links. That helped our product designers focus their efforts, make swift and practical decisions, and put together a revamped onboarding experience that would truly delight our users.

Empower your team

It’s common for small startup teams to lean on sales or partner conversations as informal user interviews. This can be an easy way to gather feedback and quickly assess your next steps—but it’s no substitute for formal research.

I’ve found teams are less likely to pursue research if they think they’ll run into a bottleneck that will hold up their project. That’s why I empower my team with a self-service guide that helps them implement research early and often.

Before, team members would have to wait anywhere from two to four weeks to book time with me and discuss their research process. With the self-service guide, they can lean on quick templates to get started and consult best practices to ensure they’re talking to the right people and asking the right questions. Now, they can create solid research plans on their own within one to two days.



Key takeaways

Making research an early and integral part of a user-centered design process can help your team build confidence and clarity around the customer needs you’re looking to meet.

It’s an upfront investment, but one that—if made carefully and intentionally—will yield countless results for your users and your business.

Our team is growing

Interested in bringing your research and design skills to Stytch? Check out our available positions, and get a feel for some of the projects we’re working on. Learn more.

---


# Introducing Log in with Ethereum
Source: https://stytch.com/blog/introducing-log-in-with-ethereum/

Unlock Web3 via Stytch without having to touch a blockchain.

Unlock Web3 via Stytch without having to touch a blockchain.

Stytch is on a mission to eliminate friction from the internet and we’re thrilled to launch our first passwordless authentication solution for Web3—Log in with Ethereum. Log in with Ethereum makes crypto wallet authentication seamless, for both engineers and end users, and supports passwordless authentication for all Ethereum-based wallets (Metamask, Coinbase Wallet, etc.).

What we’re solving for

One of the major developments that has occurred over the past two years has been the meteoric rise of cryptocurrencies, such as Ethereum (ETH), and decentralized Web3 applications. To use price as a proxy for this growth, in March 2020, the price of 1 ETH was worth roughly $112.35. Two years later, the price of 1 ETH is now worth $2,574.75, a staggering increase of nearly 23x. And that’s with ETH’s drop from its all-time high of nearly $5K back in November 2021.



In March 2020, the price of 1 ETH was worth roughly $112.35. Two years later, the price of 1 ETH is now worth $2,574.75, a staggering increase of nearly 23x.

Ethereum today remains the market leader in Web3 and has the greatest share in the fast-growing non-fungible token (NFT) and decentralized finance (DeFi) markets. But despite the rapid growth of cryptocurrencies and decentralized applications, crypto wallets—the tools that house digital assets such as cryptocurrencies and NFTs—remain inaccessible and complicated for end users and developers alike.

For end users, just figuring out how to create and fund a crypto wallet is daunting, and can feel as confusing and punishing as trying to decipher poorly thought out street parking signs. There are too many steps involved in sign up and it is common for people to lose access to their credentials when using private keys to determine wallet ownership.



For developers, the proliferation of different wallets has led to generic and bloated user authentication experiences. And once a user logs in, developers are still faced with challenges like managing sessions for their users. Connecting a wallet is just the beginning of managing your users in Web3 applications.

Our solution: Log in with Ethereum

We’re introducing Log in with Ethereum to help solve for this friction. With just two calls to our API, you can allow users to log in to your app via any Ethereum-based crypto wallet. MetaMask, Coinbase, Rainbow, and any other Ethereum-based wallet can now be linked via our API in a single, smooth authentication flow alongside your existing Web2-based options. Email magic links and crypto wallets? You got it. Crypto with SMS based OTP as a second factor? No problem.

Our documentation shows you, step-by-step, how to build a Log in with Ethereum flow and how to deal with the authentication logic. Via our direct API, we clearly outline what steps are necessary on the client side. Our integration guide is a one-stop shop for how to get the Log in with Ethereum flow working, end-to-end.

Using Log in with Ethereum

Although Log in with Ethereum can be used in a standalone fashion for connecting crypto wallets, it becomes much more powerful when you combine it with the other features and ergonomics of the Stytch platform:

For session management: when you authenticate a crypto wallet, you can start a session to securely keep the user logged in. Both session tokens and JWTs are fully supported for session management.

For user management: similarly, you can use the Stytch API to easily manage your users.

With additional authentication factors: beyond crypto wallet auth, Stytch offers a full suite of authentication methods such as email magic links, OAuth, biometrics, SMS passcodes, and WhatsApp passcodes.

With Stytch, you can build secure, low-friction authentication flows for both Web2 and Web3 users with a single authentication provider. Whether a user wants to log in with Apple, Google, their FaceID, or a MetaMask account, you can fully support all users with a single integration.

What’s coming next

Log in with Ethereum marks Stytch’s first foray into the Web3 space, and there is plenty more to come. Web3 is increasingly going multi-chain, with compelling new projects being built on blockchains outside of Ethereum, and so are we. We’re excited to continue to build out support for other popular blockchains like Solana so that more Web3 use cases can use Stytch for their authentication needs.

At Stytch, we pride ourselves on both providing great developer experiences but also great end user experiences. We’ll be launching SDK support for our crypto wallet log in products so that we can continue to do more of the heavy lifting when it comes to building delightful user experiences, and you can focus on building your core product.

Web3 user authentication is a multifaceted issue, and we’re also excited to unveil something for end consumers in the near future. Stay tuned!

Getting Started

Are you building a Web3 application, or are interested in enabling your users to authenticate via their Ethereum wallets? You can check out our documentation and sign up for a developer account here to get started! If you have any questions, please feel free to contact us at support@stytch.com.







---


# Build a custom client portal on Airtable using Sequin, Stytch and Next.js
Source: https://stytch.com/blog/build-custom-client-portal-on-airtable-using-sequin-with-next-js/

Build a custom client portal on Airtable using Sequin, Stytch and Next.js



Sequin syncs APIs like Airtable to your database in real time. Stytch makes authentication easy. We’re thrilled to join forces and host one of Sequin's most popular tutorials on our blog. Read on to learn how to build a custom client portal on Airtable that uses Stytch for user authentication...

In this tutorial, you’ll see how to build a scalable, secure, and flexible client portal on Airtable using Sequin, Stytch, and Next.js.

You’ll set up a custom application that allows your clients to log in securely and access only the data you want them to access. Finally, you’ll see how to make this application interactive so that your clients can sign off on projects directly from the portal.



Each step will be outlined in this tutorial, but if you’d like to get a working copy of the final code, you can find it on GitHub.

Setting up the Airtable base

This demo project will start with the Airtable Project Tracker template. Copy this template to your Airtable account and open up the base.



This base includes three tables: Design projects, Tasks, and Clients. Tasks are for internal use only, so in this tutorial, you’ll focus on the projects and clients.

You’ll use Stytch to authenticate users by their email address, but this template doesn’t come with a client email field. So, you need to add a new column to the Clients table called Email.



Add some dummy data to each of the fields, but use your own email address for one of them. This will be your test client account so you can verify that the web app works.

Connecting Sequin to Airtable

While you could build a client portal that queries the Airtable API directly, this has some major drawbacks, including the following:

Airtable’s API limits you to just five requests per second, so it won’t scale well.

Querying related records using the Airtable API is cumbersome and often involves multiple API calls. This can significantly reduce your app’s performance, especially when coupled with the API limit mentioned above.

Finding, sorting and filtering via Airtable’s API isn't easy.

If you haven’t already, sign up for a Sequin account.

Once you’re logged in, click the Add Base button in the top right corner. Add your Airtable API key, select the base you want to replicate (it’s called Project tracker by default), select Sync all tables in this base, and make the destination for the replica New Sequin database.



When you’re done, hit Create, and within a few seconds you’ll have a Postgres replica of your Airtable data.



Be sure to save the Postgres connection string shown, as you’ll need it for your web application.

Creating a new Next.js application

Next.js is a React-based web development framework designed to run seamlessly on Vercel. While you could set up a new React application with a backend, Next.js makes the setup and configuration process much simpler, so it’s a great starting point for building simple frontend applications like this one.

Assuming you’ve got a recent version of Node.js installed (version 10+ is recommended), use `npx` to create a new application from your terminal:



Enter a name when prompted (project-tracker in this example), and the required base packages will be installed.



This project includes several API endpoints and one frontend route, which you’ll modify later in this tutorial. For now, navigate into the new project folder:



And open the project in your text editor or IDE of choice.

Setting up Stytch for authentication

To allow clients secure access to your portal, you need a way to authenticate them via their email address. While you could build this feature yourself, you can also use Stytch to set this up with very little custom code.

Setting up Stytch is pretty straightforward, but here is a tutorial for setting up Stytch authentication if you'd like to see how it works. This tutorial makes use of Stytch's Email Magic Links product.

First, sign up for Stytch and get your project ID, secret, and public token from the Dashboard. Next, from your terminal, you need to install Stytch and a few other required dependencies. In this demo application, Stytch is being coupled with the next-iron-session utility to help with managing user sessions and data.



Next, create a `.env.local` file in the root directory of your project. This will allow you to securely store your environment variables without checking them into version control.



Replace each `...` with the corresponding environment variable from each of the services used in this tutorial. As a reminder, `PG_CONNECTION_STRING` is the Postgres connection string for your project from your Sequin account.

Note that the Stytch public token must be prefixed with `NEXT_PUBLIC_`. This signals to Next.js that the variable should be made available in the browser, while the other environment variables will be kept securely on the server only.

Now, add in the necessary elements to implement Stytch authentication, starting with a library folder containing two components: one that allows you to load the Stytch client, and another that will be used in managing session data.

To do so, create a new `lib` directory containing a file: `loadStytch.js`.



Here, you are initializing the Stytch client by retrieving the project_id, secret, and environment variables from your `.env.local` file.

Now, add another file to the `lib` directory called `withSession.js`. This file will contain a helper function to create a session stored in your browser's cookies via a signed and encrypted seal.



Next, you will create a Stytch login component in `pages/components/LoginWithMagicLinks.js`, which includes all the UI to send users a Magic Link for login.



Now you can build the two Stytch API endpoints to be used for user authentication - you'll need one for authenticating Magic Links sent to users, and a second for handling logging out of the app.

Conveniently, Next.js API routes allow you to build these server-side API routes in the same repository as your frontend application by adding serverless functions to your `./pages/api` folder.

Create your first API endpoint by adding a file called `authenticate_magic_link.js` to the `api` directory. Then add the code below to authenticate the user from a magic link and create a long-living session:



Once that's done, you'll add `api/logout.js` to delete the user session and effectively log the user out:



Note that both of the `handler` functions in these authentication endpoints are wrapped in the `withSession()` helper function to help secure and manage the user's sessions.

Finally, update the `pages/index.js` file to display the Stytch login form when a user is not logged in.



If you’d like to test the login functionality at this point, you can run your Next.js application from your terminal.



Now, visit localhost:3000. Because you did not arrive at the page through a Magic Link, you don't have an active authenticated session and should instead see a Login / Sign Up form like this:



After entering your email address on the form, you will receive an email with the Magic Link. Clicking the link from the email will send you to your authentication endpoint, where you undergo Stytch's authentication process based on the data passed through from your environment file, including the Stytch token.

Upon verification, a session is established and you are routed back to your app's home page. The session data is passed from the backend to the frontend using Props and the `withSession` helper function, and you are now successfully logged in!

You’re now ready to integrate the frontend with Sequin to retrieve data for each client.

Querying data stored by Sequin

Now that your clients are authenticated with Stytch, you can use the email address of each authenticated user to make a PostgreSQL query that retrieves only the projects belonging to that client. In order to accomplish this, you’ll create another API endpoint that queries your Sequin database.

First, install the node-postgres package using NPM.



Since you don’t want to expose your Postgres connection string in the browser, you need to connect to Postgres from a server-side application. Create a new file at `pages/api/projects/index.js`, import the Stytch client for authorization, and connect to your Postgres database:



Next, you need to export a function that Next.js will call when the `/api/projects` route is called.



To check whether the the current user is authorized, you can use Stytch session authentication and make a call to the Stytch authentication endpoint using the Stytch client, wrapped in a 'try/catch' block. Add the following to your exported function:



Once the user is authenticated, you can access their email from the request body. If the user doesn’t have an email or the token is invalid, this code will throw an error, so wrap it in another try/catch block.



Finally, you can use the following code to get all this client’s projects. Because Airtable (and therefore, Sequin) stores the relationship between clients and projects as an array of IDs, you can use Postgres’ `ANY` clause to join clients and projects.



This endpoint is now able to query directly from Sequin, so you can avoid Airtable’s rate limits. Having your data in Postgres also allows you to create more dynamic and efficient queries to get your data from Airtable.

Calling the project’s endpoint

Now that you’ve got an endpoint set up, you need to call it from your frontend, but only after a user logs in. You'll need to include the user's email and Stytch session token in the request body for authentication. In the `Home` class you created in `pages/index.js`, add the following:



If you restart your Next.js application and log in again with your browser’s inspector open, you can see that a call is being made to `/api/projects`.



In the next step, you’ll use the results from that API call to populate your client portal.

Displaying projects in the portal

Now that you’re able to authenticate a user and retrieve their projects from Sequin’s Postgres replica, you’re ready to display the results in the UI. Next.js already includes some basic styling, but don’t feel limited by it. One of the big advantages of building a custom portal like this is that you have complete control over the user interface and experience.

Open your `pages/index.js` file again and add the following within the code that checks whether a user is logged in:



Start the app again and log in, making sure to use your email address that you attached to one of the client accounts in Airtable. You should see a list of all this client’s projects like this:



You now have a working client portal that will allow your clients to securely access limited data about their projects only. But what if you want to allow clients to interact with the projects in the portal? In the last section of this tutorial, you’ll see how to allow clients to save data to Airtable using Sequin’s documentation on writes.

Writing data with Sequin

Your clients will probably need to sign off on each project as it’s completed. To let them do this in your new portal, you can add a checkbox on each project that lets clients mark projects as complete.



Sequin gives you a read-only Postgres replica of your Airtable base. This ensures that you have a single source of truth for your data, but it means that you can’t use typical Postgres `UPDATE` queries to make changes in Airtable.

Fortunately, Sequin has a solution to this limitation. By using their proxy server instead of the standard Airtable API server, your updates will be instantly saved to both Airtable and your Postgres database.

To use the Sequin proxy in JavaScript, install the Airtable NPM package:



Next, create a new endpoint in your Next.js application that will handle update requests. Make a new file at `pages/api/projects/[projectId].js` and add the following:



Similar to when you pulled the user's projects, this endpoint validates the user’s authentication using Stytch to ensure that unauthenticated users cannot access this endpoint, and then uses the Airtable API library to update the Complete field to true. Also notice that at the top, the Sequin proxy URL was specified as the API’s `endpointUrl`. This routes requests through Sequin to keep your Postgres database up-to-date at the same time as the Airtable base.

Next, you need a checkbox in your template and a method to call the new endpoint from the frontend. Add this method to your `Home` component before the `return` statement:



Finally, add this paragraph just below your due date inside the loop that displays all your clients’ projects in the same file:



Start your Next.js application again and log in at localhost:3000. This time you’ll see a checkbox next to each project. Check one of the records, and you’ll see that the checkbox will be disabled. This prevents clients from approving the same project multiple times, but of course, you can modify this behavior to fit your use case.



To make sure the synchronization works, go to your Airtable base to see if the record has been synced yet. If you’re fast, you can see Airtable marking the project complete in the base.



Next steps

In this tutorial, you’ve seen how to build a flexible, scalable client portal on top of Airtable. You used Sequin to replicate your data to Postgres, Stytch to authenticate users via email, and Next.js to build a frontend with two serverless endpoints.

As you adapt this demo to your use case, you might consider adding pages for each project so that clients can see more details about each of them. Or you might connect multiple emails to each client to allow different stakeholders to get access to their portal. You could even integrate Stripe to allow clients to make payments directly in your custom portal.



Any questions?

Please contact Stytch at support@stytch.com, or visit sequin.io for any questions related to Sequin.









---


# Log in with username
Source: https://stytch.com/blog/log-in-with-username/

Log in with username

Introducing Log in with username

Today, we’re excited to introduce an important passwordless single-factor authentication (SFA) option that can be used in multiple verticals.

Log in with username authentication solutions are ideal for use cases where your customers want to quickly log in without a password. Logins can’t get any easier than this, making this the most desired product to date – surpassing even account recovery by NFT.

With Stytch, developers can implement Log in with username into their authentication flows in seconds rather than minutes.



How Log in with username works

When integrated, a user proves knowledge of their username granting access to their account.

It works by proving ownership of a username because the user knows their username.

Once the user supplies a username as evidence of their identity, they are either logged into an existing account or given a new one.



Log in with username vs. log in with Password



At Stytch, we’re committed to killing the password. We’ve released products to combat this dangerous concept before, but this is our passwordless take on an old classic.

We’ve determined that a secret, complicated password isn’t needed. Why use password when username do trick? Exactly.

How to integrate

To log in a user with their username, integrate with these easy steps:

Ask the user for their username.

Hit /v1/users/authenticate with the username.

Log the user in.

If you have an existing project, migrate with these easy steps:

Delete the password column from your users table.

Security concerns

Here we’ll cover several recommendations for how to deal with your users’ usernames.

First, we recommend complicated, hard-to-read usernames. A common pattern we’ve been seeing is to require the following:

1 uppercase letter

1 lowercase letter

1 symbol

1 emoji (we recommend the ???? emoji because it counts toward the symbol requirement)

3 numbers that mean a lot to you



If your users are struggling to come up with good usernames, consider adding a username strength check. Even better, create usernames for them, e.g., using a secure random string generator. Remember to run the username strength check after randomizing to prevent usernames like “username”, “root”, “MyspaceTom”, or “DozensOfOvals.”

Second, we’ve seen success requiring users to rotate their usernames periodically, maybe thrice a year. We’re not sure if this is a proven method.

Third, remind your users to not share their usernames with anyone they don’t trust online.

Closing remarks

As you’ve seen, the Log in with username product creates a quick and painless way to get access to a username’s account.

If this product doesn’t seem safe enough for you, remember that half of your users are already sharing their passwords across many of their different online accounts, with loved ones, people who ask nicely, or their ex-co-worker Hunter the 2nd. If you still require stronger security, consider upgrading to multi-factor authentication (MFA) with one of our future products such as Log in with your Favorite Digit.





---


# Stytch’s new Javascript SDK
Source: https://stytch.com/blog/stytchs-new-javascript-sdk/

Today, we’re launching our updated JavaScript SDK, a flexible and friendly way to get up and running with Stytch that dramatically reduces the amount of backend code you need to write.

At Stytch, we’ve been working a lot to build the “what”: low-friction, passwordless authentication that seamlessly connects your users to your product. But any good “what” needs an equally strong “how”: straightforward and helpful ways to implement Stytch. Today, we’re launching our updated JavaScript SDK, a flexible and friendly way to get up and running with Stytch that dramatically reduces the amount of backend code you need to write.

The release includes the vanilla JavaScript library, stytch.js, as well as the stytch-react package for React-built applications.

Whether you’re looking for a product to handle the entire user auth journey, or simply give some programmatic assists along the way, the Stytch SDK is there to be your partner for a smooth setup experience.

Two halves to the whole

You can think of the JavaScript SDK as two distinct pieces:

Customizable UI flows for Stytch’s various auth products that you can embed directly in your product, as opposed to directing users to a new window or widget.

SDK methods to call the core Stytch API directly from the browser so you can use Stytch without needing to build your own internal API that routes authentication requests from your client to your servers, and still maintain full control over the UI.



A flexibility-first Stytch

In talking to our customers, one thing is clear: everyone’s authentication needs are different. Where some teams appreciate all-in-one experiences that “just work”, others may feel stifled by that loss of control. In designing our new SDK we put your feedback front and center by decoupling drop-in UIs from helper functions, which is why there are two distinct ways you can utilize the library:

SDK with UI components: configure and place Stytch’s UI components as you see fit in your product. Whether it’s users selecting an SMS country code or authenticating the resulting one-time passcode, Stytch takes care of the auth flow.

Headless SDK methods: design your own authentication flows, and attach SDK method calls to your own components. Use Stytch to power your authentication and session management while bringing a user experience unique to your product.

Our customers’ authentication needs can also vary within their product, which is why the SDK can be used in tandem with the core Stytch API based on what’s needed at a given moment. For example, you may opt to dynamically generate embedded Magic links via the API, while providing Google OAuth and Google One-Tap as a sign-in option to your users via the SDK.



Client-side Stytch and session automation

In addition to the availability of customizable UI flows for your product, loading the SDK on your front-end also unlocks the ability to automatically connect Stytch’s sessions product to the browser cookie. By inserting user session data directly into the cookie, we reduce the effort required for your team to not only authenticate users, but also verify on return visits that your application can persist the same session your user had prior.

This client-side interaction pairs naturally with familiar front-end practices like event listening and React hooks, letting you respond easily to updates as users authenticate and provide additional factors:



Reference the Stytch session object alongside other state data to keep your app renders responsive to user updates, whether that’s the change from anonymous to signed-in or something more dynamic like conditional links or feature access. You can also use these hooks and handlers to perform actions like syncing session updates across multiple browser tabs.

With the recent addition of JWTs to our sessions product, developers can seamlessly route a variety of minted tokens into browser storage and process user sessions as they see fit.

Getting started

The Stytch docs contain the full SDK reference and associated guides on how to get up and running with this new implementation route. If you’re looking for a low-friction way to get up and running with password-free auth, you can register a developer account here or contact support@stytch.com.







---


# Introducing Log in with Solana
Source: https://stytch.com/blog/introducing-log-in-with-solana/

Today, we’re excited to announce our second Web3 product: Log in with Solana, allowing seamless, secure authentication across any Solana crypto wallet (Phantom, Glow Wallet, etc.).

A few weeks ago, we launched our first passwordless authentication product for Web3: Log in with Ethereum. Today, we’re excited to announce our second Web3 product: Log in with Solana, allowing seamless, secure authentication across any Solana crypto wallet (Phantom, Glow Wallet, etc.). Log in with Solana works for both Web2 and Web3 applications that want to offer Web3 wallet authentication, as well as with all of the rest of the ergonomics of the Stytch authentication platform (session management, magic links, reCAPTCHA, biometrics, 2FA, etc.).

Overview: what is Solana?

Solana is a Layer 1 blockchain, similar to Ethereum. And like Ethereum, Solana is a major player in the burgeoning Web3 ecosystem. Web3 is defined by having applications that are built on an open and decentralized database and compute layer. In contrast to Web2 companies and their infrastructure (Google, Meta, etc.) where all user data lives on a centralized server, with Web3 applications that data is recorded on a shared, decentralized, and publicly accessible ledger.

Although there’s no denying Ethereum’s continued and dominant popularity among Web3 developers, Solana has been rapidly gaining market share. The main driver of that growth, and what makes Solana stand apart from other popular blockchains, is its speed and cost.

Solana’s innovation is Proof of History (PoH). PoH is a consensus mechanism that allows transactions to be logged as they enter the network at a specific moment in time, as opposed to being batched by block. Although Solana still technically uses Proof of Stake (PoS) as their consensus mechanism, PoH balances the speed vs. centralization tradeoff by instantly timestamping each transaction as it comes through. By having this agreed upon timeline, Solana can have a vast amount of validators to ensure decentralization without sacrificing speed. In practice, this means that Solana’s transactions per second (TPS) and cost per transaction are much more favorable to rival blockchains.



Smart contract platforms comparison. Source: Solwealth [Cointelegraph.com]

Rapid growth, growing friction

Solana saw incredible growth in 2021.

The Solana team put together some highlights in their Solana Solstice 2021 report that are truly staggering. From January to December 2021:

360 global validators -> 1,331 global validators

70 projects in the Solana ecosystem -> 5,145 projects

0 Solana NFTs -> 5 million NFTs

$100 million in Total Value Locked (TVL, sum value of crypto assets deposited in a decentralized finance (DeFi) protocol) -> $11.4 billion TVL

10 billion total transactions -> Over 45.5 billion total transactions

Perhaps nothing sums up Solana’s banner year better than this chart from Phantom, the leading Solana wallet.



There is clearly rabid interest in the Web3 ecosystem Solana is powering, and developers and users alike are flocking to it. However, similar to the Ethereum ecosystem, all of this growth has come in spite of the fact that the user experience for both end users and developers is convoluted at best.

For end users, not only does Web3 introduce a completely new paradigm for user accounts and authentication, they now have to juggle multiple wallets, one for each blockchain they want to interact with.

For developers, not only are there now multiple wallets for each blockchain, there are now multiple blockchains they need to consider as well. And once a user logs in, developers still have to deal with standard user challenges like managing their users’ sessions.

Stytch’s solution

User authentication in Web3 is multidimensional, and Stytch is addressing another wrinkle with our second Web3 product, Log in with Solana. Log in with Solana supports seamless, passwordless authentication for all Solana-based wallets (Phantom, Solflare, Sollet, etc.)

There are two primary benefits in working with Stytch:

Ease of use

Our documentation will show you, step by step, how to build a Log in with Solana flow and how to navigate the authentication logic. Via our API docs and integration guides, we clearly outline how to get the Log in with Solana flow working, end-to-end.

Stytch ecosystem

With Stytch, you can build secure, low-friction authentication flows for both Web2 and Web3 users with a single authentication provider. Whether a user wants to log in with Apple, Google, their FaceID, or a Phantom account, you can fully support all users with a single integration. So while our crypto wallet authentication products can be used in a standalone fashion, they become much more powerful when you combine them with the other features and ergonomics of the Stytch ecosystem and platform:

Additional authentication factors: Beyond crypto wallet auth, Stytch offers a full suite of authentication methods such as email magic links, OAuth, biometrics, SMS passcodes, and WhatsApp passcodes.

Multi-chain support: With Stytch, you can now support both Ethereum and Solana wallets in the same user authentication flow.

Session management: When you authenticate a crypto wallet, you can start a session to securely keep the user logged in. Both session tokens and JWTs are fully supported for session management.

User management: Similarly, you can use the Stytch API to easily manage your users.

Announcing javascript SDK support for log in with crypto

We’re excited to also be launching support for both log in with Ethereum and log in with Solana in our javascript SDK. Explore our docs to quickly get up and running to enable your users to log in with their wallets. The SDK seamlessly integrates with additional Stytch features like session management, to save you more time so that you can focus on building your core product.

What’s coming next

The Web3 ecosystem is constantly evolving, with new protocols and projects constantly being announced. We are excited to continue building out support for other blockchains so any Web3 developer can use Stytch for their authentication needs.

We’ll be launching SDK support for our sign in with crypto wallet products so that we can do more of the heavy lifting when it comes to building delightful user experiences, and you can focus on building your core product.

Finally, we’re excited to be announcing something for end consumers in the coming weeks. The lines between our different worlds are getting blurry, with Web3 going increasingly multi-chain and Web2 companies continuing to explore what is possible for them in Web3. End users are caught in the middle of these currents, and we hope we can provide them a vessel to better navigate these changing waters.

Getting started

Are you building a Web3 application, or are interested in enabling your users to authenticate via their Solana wallets? You can check out our documentation and sign up for a developer account here to get started! If you have any questions, please feel free to contact us at support@stytch.com.









---


# It's a Stytchiversary with Jeremy Kaplan!
Source: https://stytch.com/blog/its-a-stytchiversary-with-jeremy-kaplan/

It's a Stytchiversary with Jeremy Kaplan!

What do you love most about working at Stytch?

I learn so much all the time! I'm constantly trying new things to see how they'll work, and that's always fun. Sometimes the things are even useful!

What does a typical day at Stytch look like for you?

I try to consolidate meetings onto Tuesday and Thursday, so I do lots of focused work on the other days. That could be solving bugs, building out a new feature, or writing a spec for a future feature. Collaboration is mostly async, so I do a lot of writing and reading.

What’s been the most surprising thing about Stytch?

We've done so much with such a small team!

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

When doing something truly new, the best way to refine a good idea really is to just ship it and see where it goes. I knew this in theory because I've heard it tons of times, but it's different to feel it myself.

What’s your favorite part of the Stytch culture?

I like our emphasis on open, async, written communication by default. I've learned so much by passively consuming conversations that other people are having, and it's really easy to look back and learn why a particular decision was made.

Which Stytch hiring value resonates most with you and why?

Both of them! But I really like "be ambitious" because I believe that we can have (and make!) nice things if we try hard enough.

What’s the most interesting project you’ve worked on at Stytch?

You probably won't get to see it (unless you join us ????), but I had a lot of fun building out our `apitest` library to make it easier to read and write end-to-end tests for the API.

How did you end up working in engineering?

My first year in college (when I thought I would go into bioengineering), a friend of mine challenged me to learn Python and compete with him in [Project Euler]. I ended up spending more time exploring Python than doing my organic chemistry homework, so I changed tracks and followed that through into software engineering.

When’s the last time you did something for the first time and what was it?

Biked to a wetlands preserve to watch birds through binoculars. I saw a heron pluck a fish out of a stream!

What’s your ideal weekend?

Video games, good food, and trying to build something in a programming language I've never used before.

What’s something you’re passionate about that’s not on your resume?

Linguistics! I'm fascinated by the way language evolves over time. Ask me how I feel about emoji reactions!

---


# Save time, save the planet–go passwordless!
Source: https://stytch.com/blog/save-time-save-the-planet/

In honor of Earth Day, Stytch conducted a thought experiment to determine how much time (and energy!) you can save by eliminating passwords.

In honor of Earth Day, Stytch conducted a thought experiment to determine how much time (and energy!) you can save by eliminating passwords.

Think about it. How often do you find yourself stuck on the login page, trying to remember which iteration of your go-to password did you use? Or have you given up and reset your password for the umpteenth time? Or even worse, gotten stuck in a reCAPTCHA loop, desperately trying to prove you’re not a robot?

Ever think about how much screen time you’re wasting on passwords? Ever wonder the environmental impact of all this screen-time wasted on passwords? Let's break it down...

How much time are you wasting?

Starting with some assumptions:



Under these assumptions, we can conclude that the average human spends about 1.5 hours typing in their passwords and 10 hours resetting their passwords, each year. This does not even include the time spent setting up their accounts and a new password!

A study has shown that the average human has about 100 passwords (and therefore 100 different accounts or so). In recent years, the number of passwords is also increasing rapidly due to the spike in online shopping and entertainment from the pandemic. Assuming these accounts do not use OAuth logins, embeddable magic links, or any other passwordless solution, setting up all these accounts may take as long as 30 minutes.

This means, in a lifetime, the average human can spend up to 27.5 days on passwords. (That’s practically the whole month of February!)

And since it's Earth Day, let’s consider the carbon footprint of 27.5 days of screen time.

How much energy are you wasting?

Assuming all password usage is on the laptop, a single person’s password usage results in 0.01-0.03 metric tons of CO2, the equivalent of 3.2 gallons of gasoline consumed. This may not seem like much, but this is just for one human.

If we step back a bit and just consider the carbon impact across all adult Americans, this number increases to 4.1M metric tons of CO2! This is the equivalent of the greenhouse gas emissions from 877,415 gasoline-powered passenger cars in one year and would take 4.8 million acres of US forests to sequester the carbon for one year. For context, that’s all the forests within the state of New Hampshire. (We have references! See below.)

Turns out, we spend a lot of screen-time on passwords and as a by-product, produce a non-negligible amount of CO2. What would you do with a whole month saved?

Life doesn’t have to be this way - learn how Stytch can help lead us to a passwordless future!

Get started with Stytch

Whether you’re looking to save more time, to ship more features, plant a tree, or have more quality time, learn how to go passwordless with Stytch. See here for all of our product offerings and to find the best solution for you and subscribe to our Changelog to keep up with all the things we’re shipping! You can register for a developer account here or contact support@stytch.com.

Notes & References:

*This is a thought exercise; assumptions were made based off research and the following resources:

Average length of passwords: 9.6 characters. Source: Infosec.

Average typing speed: 190 - 200 characters per minute (assumes upper end). Source: Livechat.

Average log-in times: assume 5x a day based on user research.

Included in assumptions: health advisors recommend taking a 5 min break, every hour working at a laptop, and social media trends. Source: Quora.

Password resets: at least 5x a month, at least 10min each time. Source: Study Finds, The National News.

Digital lifespan:

Current life expectancy (2022): 72.98 years. Source: Macrotrends.

First email usage: 10 - 15 years old (assumes upper end) Source: MarketingCharts.

Average person has 100 passwords. Source: Tech.co.

Setting up an account: 

Average full name: 13.6 characters. Source: Researchgate.

Assumes username is an email. Average email length: 25 characters. Source: Baymard.

Assumes process consists of typing in a full name, an username, a password twice.

American adults who own a laptop: ~190M.

256.6 million adults (2020). Source: Datacenter.

74% adults own laptops (2019). Source: Statistica.

Carbon Emissions: 

Laptop uses between 50 - 100W/hour (assumes average to high end). Source: Energuide.

Greenhouse gas equivalencies calculator. Source: EPA.

New Hampshire has 4.8 million acres of forest. Source: Stacker.





---


# FinanceNow demo app - powered by Argyle, Unit, and Stytch
Source: https://stytch.com/blog/financenow-app-powered-by-argyle-unit-and-stytch/

When Argyle, a startup building amazing tooling for developers around employment and income data, reached out to Stytch with some login flow questions for a new demo app they were working on, we knew we had to partner with them.

When Argyle, a startup building amazing tooling for developers around employment and income data, reached out to Stytch with some login flow questions for a new demo app they were working on, we knew we had to partner with them.

FinanceNow just launched today, it is now available in Argyle’s pre-built template library, check it out here! In the demo app you can see a super smooth login flow powered by our SMS passcodes product, incredible banking features powered by Unit, all wrapped together by Argyle’s powerful product.



FinanceNow offers an amazing foundation on which you can build better, stronger financial solutions; we’re super excited to see what y’all build.

Check out Argyle’s full blog post here!

About Argyle

Argyle is building the leading user-consent-based platform for employment data, helping people avoid situations where their personal information is sold or used without their consent or knowledge. With Argyle, any business can process income and work verifications, gain real-time transparency into earnings, as well as view and update worker profile details. By removing the barriers between a worker, the companies they make money from, and the business they buy services and products from, Argyle has reimagined how employment data can be leveraged to benefit both institutions and individuals.

About Unit

Unit is the leading banking-as-a-service platform that empowers companies to embed financial services into their product. Unit's platform accelerates time to market and enables companies to build and launch bank accounts, cards, payment, and lending products. Unit is headquartered in New York and Tel Aviv and is backed by Accel, Better Tomorrow Ventures, Aleph, Flourish Ventures, TLV Partners, Operator Partners, and more.







---


# Web3 and the future of data portability: rethinking user experiences and incentives on the internet
Source: https://stytch.com/blog/web3-and-the-future-of-data-portability/

Web3’s fundamental improvements to data portability and user authentication enable new, exciting experiences, but solvable shortcomings remain.

Web3’s fundamental improvements to data portability and user authentication enable new, exciting experiences, but solvable shortcomings remain.

Tech conversations are now peppered with a new, contentious buzzword: Web3, and we’re all likely to hear a lot more of it in the coming years. It's an umbrella term for disparate ideas all pointing in the direction of making the internet more decentralized using blockchain-based applications.

If Web3 fully materializes, which we believe will happen once a few acute shortcomings are addressed, it is going to have profound implications. Web3 optimists point to decentralized technology’s ability to challenge the power of big internet middlemen like Facebook, Google, and Twitter, while Web3 skeptics understandably struggle to connect the dots on how the current state of Web3 applications could ever truly rival the user experiences and network effects that Web2’s most successful tech companies have built.

Given the current state of Web3 applications (nascent but improving quickly), you won’t need to squint much longer to see the potential of this technological paradigm shift. Web3 means many things to people, but our team finds the most important characteristics of the shift from Web2 to Web3 to be the following:

Data portability was an afterthought in Web2, but it’s a first-class citizen in Web3.

There’s nearly no end-user friction involved in porting your data from one service to another in Web3. We shouldn’t underestimate the impact of improved data portability—users’ aversion to friction influences most of our online actions today, so changing the friction involved in switching services or trying new apps is powerful.

Web3 is rewiring incentive structures on the web, unleashing user behaviors that directly challenge the advantages incumbents have long enjoyed in Web2

When the friction of porting user data from one service to another service approaches zero, companies will need to radically rethink how much value they extract from users without offering comparable incentives to that user. By making data portability virtually frictionless, Web3 has provided the technological foundation to chip away at the moats many large internet businesses rely on today to fend off upstarts.

While Web3 has the potential to reimagine how we use the internet, it also raises thorny issues around privacy, user experience, and how much control users truly want. We believe many of the underpinnings of Web3 are here to stay, but we’re likely to see major shifts in the user experience of Web3 as it goes mainstream.

An Open Sea of opportunities

Web3’s technological merits are best understood when using tangible examples of how it is already reinventing what’s possible in our digital lives.

On December 25, 2021, many participants in the crypto economy woke up to an unexpected gift. The cryptocurrency market’s blistering performance in the past year owed part of its success to the growth of non-fungible tokens, or “NFTs." (NFTs are unique, digital items that are represented on a blockchain, which have recently found popularity in use cases such as giving ownership rights to digital art and video game items.) As the NFT craze took off, a marketplace enabling peer-to-peer NFT sales called OpenSea became one of the most popular Web3 applications. For hundreds of thousands of users exploring NFTs for the first time, OpenSea became the gateway into this new asset class.

When users buy or sell NFTs through the OpenSea platform, they are actually interacting with OpenSea’s smart contracts. These smart contracts run on the Ethereum blockchain, which introduces a notable difference in how most of our digital interactions in Web2 occur. In Web2, unless we’re publishing something to a public newsfeed (e.g. Twitter), data about our interactions is known only to the specific application we’re interacting with. When I buy tickets to a concert, only TicketMaster knows of that transaction.

However, when interacting with a Web3 application (e.g. OpenSea), the smart contracts fueling the application live on a public ledger (e.g. Ethereum) and our interactions are captured as publicly-available data tied to our pseudonymous blockchain accounts. This poses real privacy concerns (which need to be addressed for Web3 to truly flourish), but it also introduces significant opportunities.

OpenSea users have been lobbying the company to perform an “airdrop” for years, asking the company to issue their own token to reward loyal users of the platform. Many OpenSea users feel that their usage of the platform (and the fees they have paid) have helped the marketplace to reach its current market position, and they want to share in that upside. In a situation like this, Web3’s technical architecture becomes very interesting. One of the unique traits of tracking interaction data on a public ledger is that OpenSea’s user base and activity is publicly available on the blockchain by their wallet addresses. If you have a bit of know-how, you have the ability to pull a list of every pseudonymous user of OpenSea and can calculate their usage (and the associated fees) on the platform. In Web2, achieving this level of competitive intelligence is likely impossible without committing a crime to leak that information from a private ledger like a centralized database.

Which brings us to Christmas Day 2021 when an organization named The OpenDAO emerged with a savvy use case built on top of this public user intelligence. The OpenDAO issued a new token with the ticker $SOS to proportionally divide across OpenSea’s users based on their usage of the marketplace. This practice of issuing a new token and allocating it to users based on certain criteria is called an “airdrop” in the crypto world—it’s a fairly frequent occurrence, but the $SOS airdrop is the first successful, large-scale example of an organization choosing to airdrop a token to users based on their interaction with a third-party product that it doesn't have a formal relationship with.



We can only begin to imagine how this ability to invent new incentive structures based on third-party application usage might reshape modern competitive dynamics. However, rather than using this airdrop as an incentive to convince users to jump ship from OpenSea to a competitive platform, The OpenDAO's initial focus has instead been to provide valuable features to OpenSea’s user base that are not available from OpenSea today. For example, a proportion of the new tokens created are allocated towards compensating scam victims on OpenSea (like elsewhere in the crypto ecosystem, scams remain common):



Nearly 200,000 OpenSea users claimed the $SOS token by connecting their crypto wallet to prove they own the blockchain address that had used the OpenSea product, allowing them to claim these tokens. The OpenDAO airdrop of the $SOS token exemplifies many magical pieces of Web3 technology:

Recording data on a public ledger means that this data can be used in inventive ways by companies that aren’t the first-party application where the user generates that data.

When incentivized, users can verify their ownership over this data with virtually zero friction. All you need to do is click a button to connect your crypto wallet.

With these building blocks, Web3 makes it easy to rewrite user incentives on the web. The OpenDAO project provides insights into what’s possible when users own their data and can easily port it to other services.

In the future, this could allow users to control how they share their own data and bounce around, say, from social media to a finance app to shopping using a single personalized account, creating a public record on the blockchain of the core parts of that app’s activity. This level of data portability that Web3 enables will challenge many of the expectations we have of how applications work on the internet. Historically, most applications have built either closed or tightly permissioned gardens, which limit users’ data portability. As a result, we’ve ended up with companies that have built mammoth network effects that are nearly impossible for a truly competitive market to unseat.

The 1-2-3 of the Web

One thing is certain: in a Web3 world, users will navigate the Internet and gain access to its services in very different ways. First, it helps to understand how the Web has evolved.

The early days of the Internet in the 1990s were Web 1.0. The web then was composed mostly of static sites that you could read, but there wasn’t much interaction. It was a little disorganized and difficult to navigate. In a world of static sites, there’s not much need for authenticated user accounts. As an example, a static site serving blog posts would serve the same content regardless of whom the reader was.

Then came Web 2.0 in the mid-2000s. Sites became dynamic, and there was an explosion of apps that allowed users to do more than simply read data. Platforms like Google, Amazon, Facebook, and Twitter made it possible to connect and transact online. These applications required the ability to store user data on their servers and then reproduce it in the future.



As Web 2.0 proliferated, users collected hundreds of different accounts siloed across different applications. The common authentication method that proliferated (the password) has become one of the shortcomings of navigating the web, due to user difficulties and security shortcomings.



Web 3.0 (Web3), based on blockchain technology that already underpins things like Bitcoin and Ethereum, uses an open, decentralized database and compute layer rather than each application reproducing the database and compute layers on their own siloed application. As users cruise the internet and use applications, the data from those interactions no longer solely lives on that single application’s server. It’s recorded on a shared and publicly accessible ledger.

Authentication doesn’t live on the application’s server either. Rather than storing a memorized secret like a password, users can apply public key cryptography to sign up, access sites, and take sensitive actions by using private keys to deterministically prove ownership of a represented account on a shared ledger. It may sound like voodoo to the average person, but it is a bit like electricity. Flip a switch, and it comes on—without the need to understand what’s happening behind the scenes.





Pros and cons of Web3

Web3 offers many advantages. Namely, data flows freely and is publicly verifiable. Companies no longer need to build user authentication using things like passwords into their applications. Instead, users can have a single account for the internet in their Web3 wallet: think of this as a “bring-your-own-account” architecture where the user verifies their account as they browse different websites, without the need to create a unique username and password for every site.

Because authentication is based on public-key cryptography, certain security gaps with the Web2 approach to authentication (e.g. weak passwords and password reuse) are nonexistent. Users don’t have to remember passwords or fill out multiple screens when they sign up for an application.

As with everything in tech, there are disadvantages too. Web3 eliminates the password, but it introduces other weaknesses. Anybody who has tried to set up a Web3 wallet like MetaMask knows that the user experience (UX) can be foreign and unfriendly. It requires introducing users to a completely novel concept of secret “seed” phrases, which are 12-to-24 words long and required for users to be able to recover their account when they switch devices. The UX burden for users that are new to Web3 can be overwhelming. A new user is introduced to this strange concept of seed phrases and told that failing to properly store their seed phrase will result in the irreversible loss of everything in their Web3 wallet.

Additionally, wallets like MetaMask ask users to also create a password for their wallet, and users’ confusion only compounds when they learn that this password cannot be used in any way to recover or access their account from another device. Instead, the password only works to unlock the “local” copy of the wallet on their device, which runs counter to everything users have been taught about the portability of passwords since the web’s early days.

The UX burden of seed phrases and non-portable passwords presents a number of risks for users. These confusing and foreign authentication concepts can lead to users being more easily scammed. Unwittingly, users might provide their seed phrase to a phishing site because they want to take a shortcut when confronted with a clunky, mentally taxing UX flow.

Users might also lose or misplace a seed phrase and therefore forgo any chance of recovering an account. Traditional account recovery (“reset your password”) does not exist in Web3 wallets. There’s also no 2-factor authentication today for users to retain additional control over authentication. Whether the transaction is $1 or $1 billion, wallets by default only require private key signing.

Data is transparent. That also means it’s public. While accounts are pseudonymous, users may take actions that accidentally leak their identities when they don’t intend to. Adding to the challenge, transactions are irreversible, which puts even more burden on the user to not make mistakes. In the Web3 world, users can’t call their credit card company to reverse a fraudulent charge.

Making Web3 the best it can be

To make Web3 work, users will need to reorient their thinking, from creating a new account for every app to a “bring-you-own-account” structure with one wallet, or passport, for navigating the web. It will be a big positive change, because Web3 accounts can be authenticated with cryptography, without the dreaded password, and with a lot less friction.

Companies will need to build Web3 experiences that passively detect identities and accounts. If a user provides consent, then authentication and data provisioning can happen in one click. This is one way companies can reduce friction and drop off in their funnels. Another way to reduce friction is to blend identity and payments—something that’s relatively easy to do with Web3—and seamlessly prove and provide both to applications that users trust.

There are still unknowns with where Web3 will go, but its momentum is undeniable and its advantages outweigh the disadvantages. The best thing to do is to build the best possible version of Web3, one that’s safe and easier to navigate for internet travelers. For that, everyone is going to need a passport to the internet, and companies will need to make it safe, secure, and easy for everyone to navigate.











---


# It's a Stytchiversary with Cass Roulund!
Source: https://stytch.com/blog/its-a-stytchiversary-with-cass-roulund/

It's a Stytchiversary with Cass Roulund!

What do you love most about working at Stytch?

The people! (duh!) Stytch is a group of uniquely empathetic and ambitious folks. We all really enjoy working together and working hard to make Stytch not only a successful product but a really great place to work, too.

What does a typical day at Stytch look like for you?

Depends on the day! I'm usually in the middle of a cycle for something People-related. For example, we're currently in the middle of our 360 reviews, so I'm preparing a presentation for a manager meeting on how to write reviews and how to avoid bias, also putting together calibration sheets for our managers (to review performance and compensation), and pulling benchmarking comp data to make sure our bands are up to date. I also just got back from a recruiting event in New York, we're throwing a launch party for some exciting Stytch web3 developments this Thursday (DM for details), and planning for our company offsite in July! (Never a dull moment on the People team.)

On the Recruiting side of the house, we're hiring for a lot of roles (come join us!). Usually we start the week with a sourcing sync to ensure our priorities are aligned and that we're allocating our time in the right ways. We have an end of the week sync with some hiring managers to review pipelines and the rest of the week is spent looking for and chatting with potential Constytchuents to join the team.

But regardless of what I'm doing, the day is usually sprinkled with coffee chats with coworkers, lunch together (or trying to snag a lunch from someone who actually remembered to order before the deadline), and trying not to snack too much.

What’s been the most surprising thing about Stytch?

How much we love hot sauce here... (sort of kidding).

In reality, I was super surprised to receive a recruiting email from a 15-person company looking for a People hire. I thought it was extremely rare (and cool!) that a company of that size was seriously interested in building out People processes and foundations from such an early stage. Reed and Julianna have since continually proven that our Constytchuents are a priority and I could not be more thrilled to work for such empathetic founders.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

Not everything needs to be a process, sometimes you just need to get things done. Coming from a slightly larger company, I often felt like there needed to be a process or a policy in place for every ask, when more often than not, I was dealing with a one off issue or something that could be solved by just getting something done. Process is good (and often needed) but usually done is better than perfect.

What’s your favorite part of the Stytch culture?

The people and empathy :)

Which Stytch value resonates most with you and why?

Own it. My favorite thing about working at a startup is how many "hats" you get to wear and how many areas you get to flex into. At this size, every person has a significant impact on the company and "owning it" isn't just an exciting part of the job but an essential part.

What’s the most interesting project you’ve worked on at Stytch?

So many things (like rolling out levels and comp bands and recruiting metrics) but we’re currently planning our full company offsite (which is a first for me) and I’m both excited and nervous to see how it turns out! (But most of this is being handled by our amazing OM & People Ops person (Zack) who is an absolute gem and born to plan great events.)

How did you end up working in People and Talent?

I serendipitously fell into it. I started my career in TV production and decided to move to SF on a whim (a room opened up in my best friends' house). I texted everyone I knew asking for a job and one of my friend's from college was hiring a recruiter.

I loved that my job involved interacting with people all day and I loved learning more about the tech world via the recruiting role. I eventually moved into a hybrid People Ops role and then fully into an HRBP role and now I'm back doing a little bit of everything I love.

In the People world you face a lot of hard, ambiguous problems in a space where metrics are harder to come by (but finally emerging!!) but you get so much value in helping people and enabling them to be a tiny bit better at their job or a tiny bit happier in their role (which compounds!). Whereas on the recruiting side, success is a little bit more obvious and metrics are easier to come by (and act on) but the thing that often differentiates a great recruiting team from an average one is the candidate experience and people skills.

When’s the last time you did something for the first time and what was it?

I went to Washington DC and ran a 5k all in one trip! Be careful who you date, it might be a Turkey Trot kind of family.

What hobby got you through COVID?

Rollerskating and water coloring. I learned how to spin on my skates and how to paint poppies and jellyfish.

What’s your ideal weekend?

Coffee, yoga, more coffee, then spending the day eating my way through SF with friends. (Or a hike in North Bay!)

What’s something you’re passionate about that’s not on your resume?

Balkan history! I studied a bit in Croatia and then worked a bit in Bosnia and absolutely fell in love with the people and countries of former Yugoslavia. If you're thinking about visiting, reach out! I might have some good recs :) I definitely have enough enthusiasm to at least convince you to go!

---


# Introducing Vessel, powered by Stytch
Source: https://stytch.com/blog/introducing-vessel-powered-by-stytch/

Today we’re proud to launch our first consumer-facing authentication solution: Vessel, powered by Stytch.

Imagine never having to create another user login again. Never having to reset another password. If the frustration of private keys and seed phrases went away.

Since Stych’s founding, our core mission has been to eliminate friction from the internet, and authentication remains one of the biggest points of friction on the modern web. Over the past two years, Stytch has been building out the authentication platform for developers, making it easy and seamless to integrate passwordless authentication into websites and applications.

Today we’re proud to launch our first consumer-facing authentication solution: Vessel, powered by Stytch.

Your passport for the internet

Forget about remembering hundreds of passwords, seed phrases and creating siloed, disparate accounts as you travel Web2 and Web3. Vessel allows you to create a singular account and wallet that travels with you and gives you 1-click entry to connected sites.



Technically speaking, Vessel is a fully non-custodial, multi-chain crypto wallet and identity vault. In plainer terms, you can think of Vessel as your digital wallet and your digital identity rolled into one. It’s a single, portable identity and account that travels with you online and opens access to Web2 and Web3. A tool that allows you to manage your online identity in one place, have control over what data you share, and the power to revoke access to it at any time and from one central location. That’s the vision behind Vessel.

To create Vessel, we combined the best of Web2 authentication innovations to simplify account creation and data provisioning with the power of Web3 wallet architectures to condense authentication, identity (e.g. NFTs), and payments into a single secure browser extension. In doing so, we’ve built much more than a Web3 wallet—we’ve built a passport for the internet.

Connect safely and seamlessly

For Web2 user experiences, Vessel removes the need to create passwords for every site you visit or verify your email + phone number for every account you sign up for. Vessel helps you explore the internet through connected sites (sites that are enabled to detect the Vessel browser extension). You always have control over what sites you add to your connected site list and you can always add or remove sites.

Once you download the Vessel browser extension, a private Web3 ID is created that allows you to be anonymously authenticated as you land on connected sites. With your anonymous Web3 ID, you have the ability to manage both your Web2 digital identity (today, that’s your verified email and phone number) and your crypto wallets. You’re also in complete control of your data and can choose to share it, or not, with sites you trust that require this data.





Crypto made accessible

Creating a crypto wallet requires you to create a private key. The typical way this private key is derived today is that a wallet presents users with a seed phrase, a collection of 12-24 words, that you must remember or else your account is lost forever, adding stress to an already new and confusing authentication experience.

To enable a simpler onboarding to Web3, Vessel is a fully non-custodial wallet (meaning a wallet controlled by you rather than a third party) that eliminates the need for seed phrases. Vessel currently supports both Ethereum and Solana, allowing you to explore and use apps in both of these rich Web3 ecosystems.

Vessel uses common Web2 patterns (a password & a PIN), in lieu of seed phrases, to generate a non-custodial private key, so you can manage your crypto assets without headache. Under the hood, Vessel introduces new security approaches to make this type of Web2 simplicity possible––incorporating data from public data breaches and running the Vessel account credentials through 3 million rounds of computationally expensive PBKDF2 cryptographic hashing, we provide significant security while simplifying the Web3 wallet onboarding experience.







Get started with Vessel

We’re proud to release Vessel as a first of its kind innovation that will help to eliminate friction and help to make Web3 accessible to more people online. Learn more about Vessel here and if you’d like to dive right in, download the extension for free at the Chrome web store. To enable your site and become part of the Vessel connected network, check out the Vessel GitHub repositories to quickly add support. It’s simple. So is sharing feedback—we can’t wait to hear what you think of Vessel.







---


# Behind the scenes with Vessel: designing a brand for the first-ever passport for the internet
Source: https://stytch.com/blog/designing-the-vessel-brand/

Vessel is a secure browser extension that works as a digital identity and multi-chain wallet rolled into one.

Vessel is a secure browser extension that works as a digital identity and multi-chain wallet rolled into one.

In simpler terms, that means instead of users having to set up and enter credentials (like a username and password) for each app or website they open, they’re logged in once through Vessel and can then “bring their own account” as they surf the web. That’s why we refer to it as a passport for the internet.

As an exciting new entry into Web3, we knew we needed to differentiate Vessel from Stytch’s core brand and platform of passwordless authentication solutions for developers. And that presented new challenges for our design team.

For one thing, Web3 is a complex space. Many new users find the concept of decentralized auth difficult to understand, and it’s a design team’s job to make the process look and feel as welcoming as possible. For another, designing for Stytch means designing for businesses—usually a specialized team of engineers. Vessel, on the other hand, is a consumer product intended for a broad audience.

In this post, we share how we navigated this new terrain to develop an approachable, accessible brand in a particularly intimidating space—and introduce the dynamic brand assets we created.

Picking the perfect name

Stytch’s founders, Reed and Julianna, picked the name Vessel from hundreds of possibilities brainstormed by a cross-functional team of product managers, designers, engineers, and marketing specialists.



Snapshot of names brainstormed

As a word, “vessel” evokes something that transports passengers across different environments and—like a passport—provides them with secure access to new experiences.

Having a powerful name in place at the outset of our branding initiative gave us a clear sense of direction and helped us organize our efforts around a cohesive theme that could guide the rest of our designs.

Setting the mood

As with most branding projects, the story behind Vessel’s visual style begins with a mood board—a collage of the different images, typefaces, and other design elements that shape a brand’s color palette, logo, and wordmark.

As a tech-forward market, Web3 products tend to use developer-friendly “dark mode” tones, 3D illustrations, and ultramodern imagery. But we wanted Vessel to appeal to seasoned Web3 users and newcomers alike. That meant balancing innovative, futuristic elements with more recognizable, everyday aesthetics.

Accordingly, we put together three visual spreads, which we titled Professional Futurism, Vaporwave Chic, and Bold Brutalism. In each batch, we worked to set fun, sci-fi inspired images against the professionalism, reliability, and security expected of an authentication platform.



From left to right: Professional Futurism, Vaporwave Chic, Bold Brutalism



Final mood board

Finally, we combined these collections into a final, multidimensional mood board that would serve as a north star to guide the rest of Vessel’s branding. When it comes to a final mood board, our philosophy is that it's okay to deviate a bit and let the brand’s look and feel come together organically. To us, mood boards are a jumping off point—helpful guidelines, rather than strict rules.

Adding a touch of color

A color palette is one of the primary ways a brand sets a visual tone, elicits emotional responses, and engages its audience.

The three initial palettes we came up with for Vessel took inspiration from our mood board, each pulling in unique color combinations to test their compatibility. We also applied these colors to a number of assets so we could see how they would look and feel in practice.



Exploring color palettes

Actually seeing the colors in true-to-life examples helped us to zero in on the middle option for Vessel’s palette. In a Web3 landscape typically dominated by darker blues, blacks, and purples, these colors felt fresh and playful—happy tones that remind viewers of a sunrise or sunset while staying true to the cool, modern tech foundations of the brand.

Landing on a logo

The name Vessel can have many different interpretations and lead in many different directions, from nautical voyages to aerospace exploration to circuitry and circulation.

We wanted the logo to convey both travel and communication, speaking to an industry and audience that are between two worlds—that is, between Web2 and Web3, the known and the unknown—while staying firmly grounded in familiar, comfortable graphics.

We played with many possible logos, including a space helmet, rocketship, and satellite, before ultimately deciding on a curvy sketch of a submarine using echolocation. We liked the idea of using deep sea navigation as a metaphor for discovery in the strange new realm of Web3—with the sonar helping explorers (like internet users) easily find their way.

For Vessel’s wordmark, we paired this logo with a strong, crisp font that adds a bit of gravity and a sharp, contemporary edge to the playfulness of the submarine.



Exploring logos and wordmarks



Three final directions

Putting it all together

With these design elements in place, the entire Stytch team could align around a vision for Vessel and begin building out the wireframes, user flows and experiences, and brand assets that would truly bring our product to life.



Final brand look and feel



Applying the brand look and feel to the product

Working in the uncharted, unconventional space of Web3 and tackling new creative challenges allowed us as designers to think outside the box and develop a pioneering, tech-forward brand that’s still simple and accessible for beginners to grasp.

Get onboard with Vessel

We’re proud to release Vessel as a first-of-its-kind solution that will help eliminate friction on the internet and make Web3 accessible to more people online.

You can learn more about Vessel here. Or, if you’re ready to dive right in, you can download the extension for free at the Chrome web store and check out Vessel’s GitHub repositories to get quick support, enable your site, and become part of the Vessel connected network.

Don’t forget to share your feedback through our Vessel research survey—we’re excited to hear what you think and keep building toward a better, stronger online experience.

Get started for free today.







---


# Vessel + Ratio: making crypto accessible
Source: https://stytch.com/blog/vessel-ratio-making-crypto-accessible/

Ratio is on a mission to make crypto as accessible as possible, by making adding money to your crypto wallet as easy as adding money to Venmo or Cash App. 

Ratio is on a mission to make crypto as accessible as possible, by making adding money to your crypto wallet as easy as adding money to Venmo or Cash App. That means giving crypto wallet users familiar “add money” options, like payroll direct deposit and instant transfers from a bank account. All without the funding fees, processing fees, and wait times associated with traditional crypto exchanges.

This mission was something that really resonated with us, as crypto accessibility is one of the core reasons why we embarked on our journey to build Vessel, our reimagined take on what a more approachable and inclusive crypto wallet could look like. Vessel eschews confusing seed phrases, and instead, uses known Web2 patterns (a password & a PIN) to generate a non-custodial private key. This lowers the barrier to entry for many users, without sacrificing the security and data portability that Web3 offers.

Starting today, you can use Vessel to sign up and sign in to Ratio.



When you sign up for Ratio using Vessel, your Vessel wallet addresses become the default for both Ethereum and Solana payouts. Because Vessel is multi-chain by design, you don’t have to juggle separate wallets for Ethereum and Solana.





We’re so excited to be partnering with Ratio on their mission to make crypto more accessible for everyone, and we’re incredibly proud to see them officially launch and take the covers off of their product!

You can sign up for Ratio today here to start saving crypto, fee-free, or learn more about Ratio at their blog.

You can also download the Vessel Chrome extension here.







---


# Introducing JWTs for session management
Source: https://stytch.com/blog/introducing-jwts-for-session-management/

We’re excited to launch support for JSON web tokens (JWTs) as part of our session management product! Now, developers can choose between JWTs, session tokens, or a hybrid approach.

We’re excited to launch support for JSON web tokens (JWTs) as part of our session management product! Now, developers can choose between JWTs, session tokens, or a hybrid approach.

Stytch’s JWT support allows you to mint JWTs that can be verified without needing to hit Stytch’s API. This allows for highly performant authorization for your product when you need it, while also providing the control to revoke access when and where you want it.

JWTs vs session tokens

To authenticate a user, developers can either implement a JWT or session token-based solution.

A JSON Web Token (or JWT) is an open standard that allows clients and servers to communicate and share critical information. It’s a form of stateless authentication as all user data is stored client-side within the token itself. This makes JWTs a popular session management solution among developers looking to reduce their server load and improve latency — it makes managing sessions faster and scaling architecture easier. JWTs offer numerous benefits, but one downside is that session revocation can be more difficult because the validation happens client-side rather than server-side.

Conversely, session tokens are a session management solution that stores the token on the server-side, along with user data. Session tokens are verified against the server’s database with every user request, and a single token can be easily revoked at any time. This results in higher latency than JWTs. However, when control over session revocation is critical, this solution can be beneficial since it guarantees instant session revocation when needed.

Get the best of both worlds

Developers often have to decide which session management solution is best to implement and make the tradeoff between security and latency. Here at Stytch, we provide flexibility to strike the right balance for your application. With Stytch session JWTs, the JWT can be validated locally within your app or remotely with the Stytch API. The JWT will expire every 5 minutes in order to ensure that any session revocations are honored in a reasonable time frame, but you will be able to retrieve a new JWT through the Stytch API so long as the underlying session is still valid. You can also customize how frequently you check in with the Stytch servers by setting a lower max_token_age threshold in our client libraries or by triggering a refresh request before allowing particularly sensitive actions.

JWTs for session management are a great solution if:

Your performance needs require that your app needs to be able to validate sessions without an external network request on every call.

You’re using Stytch session management to authorize actions outside of your app and that authorization works via JWTs.

How Stytch session JWTs works

Utilize session JWTs exactly the same way as opaque session tokens, by substituting session_token with session_jwt. Every response in our sessions product that contains a session_id and session_token will now also contain a session_jwt. The session_jwt value can be used to attach new factors to existing sessions to enable step up authentication, extend the lifetime of an existing session as well as authenticate and revoke sessions.



A session JWT is a signed snapshot of the session at the time it was issued, and that signature is valid even after the session is revoked in the Stytch API. This means that the JWT is still locally valid even after the session is revoked. In order to ensure that there is a limit to how long a stale JWT could continue to be locally valid despite the underlying session being revoked, the JWT has a 5 minute expiry that is distinct from the configurable session expiry. The Stytch API will return a 404 error if the JWT passed is associated with an invalid session. To authenticate locally, use your client library’s version of authenticate_jwt.

Stytch signs all JWTs for your project with project-specific signing keys. The verification keys for those signatures are available at a project-specific URL. The URL is publicly accessible, so any other JWT consumers outside of your app can also use it to verify JWTs from your project. We also offer support for custom claims in JWTs and allow you to store custom user data.

Subscribe to our Changelog to find out about new products we ship and be alerted when we add additional features to existing products.

Getting started

If you’re interested in using JWTs, check out our Docs and sign up for a developer account here to get started! If you have any questions, please feel free to contact us at support@stytch.com.





---


# Painting the town Stytch: the making of an OOH campaign
Source: https://stytch.com/blog/the-making-of-an-ooh-campaign/

We decided to take our passwordless revolution to the streets and billboards of San Francisco.

We built Stytch on a single, fundamental truth: passwords should become a thing of the past. They’re hard to remember, easy to hack, and all too tempting to reuse across internet accounts. That’s why we make it simple for developers to add passwordless authentication to their apps and websites — unlocking better security, a better user experience, and ultimately better conversion.

It’s also why we decided to take our passwordless revolution to the streets of San Francisco.

After seeing great early feedback from customers in 2021, heading into 2022 we were ready to raise brand awareness and celebrate Stytch as a solution to the password problem. Why not launch an epic out-of-home ad campaign spanning our native city?

Below, we share how we put it all together with some amazing partners by our side — along with thousands upon thousands of handwritten sticky notes.

Go big or go home

Stytch’s OOH campaign wouldn’t have gotten off the ground without our partners at Brex. Brex’s core focus is on corporate cards and cash management, but their greater mission is to help growing companies achieve their full potential. That means offering value-added services — like their Billboard Rewards program — that help ambitious young startups amplify their message.

With Brex’s Billboard Rewards program, we put the points we earned through regular spending toward this valuable media placement and one-on-one consultations around it.

Among other perks, that included the expertise of Brex’s dedicated out-of-home media strategist, Kasper Koczab. Having launched a striking, city-wide OOH campaign for Brex, Koczab knew how to push the envelope and truly capture the public’s attention.

“We adopted a philosophy of, hey, we want to be noticed by everybody — not just decision makers, but the people they talk to,” he said.

“We look at it almost as performance art. We’re out to buy a spectacle. We’re out to buy the city. Out-of-home is a channel where, if you do it right, you can make a splash that’s impossible to miss. With this campaign, it wasn’t just about billboards — it was about, let’s paint San Francisco Stytch.”



Koczab put together a bold, sweeping plan that included dozens of billboards, five transit shelter takeovers with first-in-market custom shadow boxes to accommodate our 3D sticky notes creative, 150 standard transit shelters, and buses that travel deep into residential areas. He advised on how to negotiate with city officials, make profitable investments, maximize the impact of every unit, and create visuals that work for pedestrians and highway drivers — in short, practices that can make or break an OOH campaign.

Best of all, Kasper connected us with a dynamic, creative agency that instantly plugged into our vision and delivered just what we were looking for.

It’s all in the design

To develop the ad content, we turned to Division of Labor, an award-winning San Francisco agency with plenty of OOH experience and a firm grasp of the local market. It didn’t take them long to land on a compelling direction for our campaign.

“Chemistry is everything, and it felt like our working styles were very much aligned,” said Rebecca Reid, account director at Division of Labor. “When that happens, it’s like magic. Stytch’s founders have such conviction and clarity on what Stytch is as a brand and what they want to communicate, and it made our work together fly.”

“Stytch sent over a blog post titled Kill the Password — and that was really all we needed to see,” said Josh Denberg, Division of Labor’s founder and creative director. “No matter who you are or what you do for a living, you experience the same frustration with passwords. With other clients, we may have to search for a common enemy. But with passwords, it’s universal.”

Denberg and his team got right to work. With many units to play with, they weren’t afraid to push the limits, try new approaches, and strike a balance between playful and pragmatic messaging.

“There was a lot of collaborative back-and-forth,” said Denberg. “Stytch was really open to humor, so there’s a line about how the average person resets a password more often than they have sex. But then, there’s another that speaks to how passwordless auth can increase conversions by 60%.”

Overall, we wanted to explore a mix of creative copy that would speak to the pain of the password in different ways and resonate with different audiences.







All told, Division of Labor came up with four dynamic themes to fit distinct media types. Billboards featured memorable statements and statistics, while buses had long, cryptic password strings — like d0nTUh8pA55w0rD5L1kETh15? — stretched along their backs for drivers to puzzle over.





Most impressively, they covered a handful of bus shelters with tiny, handwritten sticky notes — the kind people use to write down and remember their proliferating passwords.

Brand messaging that sticks

Needless to say, the sticky note project took a huge effort, involving custom glass cases for each shelter, loads of note pads and work hours to fill them, and multiple tests to get it all right.

Division of Labor estimated they’d need a thousand sticky notes across five shelters, amounting to a grand total of 5,000 individual notes.

“No problem, right? We brought in 15 people for an afternoon session and had them design each sticky note as a little canvas,” said Denberg. “At the end, we weren't even close. So we did it again, then again, and we were still a thousand short.”

Finally, they held a Friday evening charity session, where friends could donate $400 per finished sticky note pad to the relief efforts in Ukraine, and Stytch sent a goodie basket of food and drinks to cheer them on and fuel their creativity. By the end of the night, Division of Labor had the last batch of sticky notes they needed — and had raised over $5,000 to boot.

Koczab happened to know artist and metal worker Ron Lester from Iron Maverick, who took on the monumental task of assembling the shelter boards, layering note over note into an aesthetic, 3D sticky note sculpture. And the rest is advertising history.





Approximately 1,000 hand-written sticky notes cover each of five transit shelter installations.

Keeping the campaign rolling

Through the OOH ads, we established a fun, unique presence in San Francisco and beyond — and we have an incredible story behind us to propel the Stytch brand forward.

“This is a team that cares about the work they’re doing, and that was clear on day one,” said Denberg. “You don’t get that very often. After the campaign launched, everyone at Stytch embraced it and took photos with their dogs in front of it. It’s been great to see that organic push.”







As the ads were unveiled, we hired videographer Michael Shainblum to document the experience, as well as the context and culture of the surrounding neighborhoods.

With a three-man crew, he shot 10 hours of footage in just three days, including using a drone to capture the Stytch team in our offices, with sticky notes spelling “Stytch” across the windows. He edited it all down into the lively, minute-long sizzle reel featured earlier — you can also check it out here. (In case you’re wondering, the super catchy song is Sonny Cleveland’s “Don’t Stop.” You’re welcome.)

While he filmed in slow motion, Shainblum sped up his footage for the final reel, giving a sense of the fast-moving pace of the city and the sheer scale of our campaign.

“We see so much signage day after day, and frankly most people don’t pay any attention. But this was something different, something intriguing,” he said.

“When so many people work on a project — not just the people devising and designing the campaign, but also the people actually putting up the signs — it’s incredible to have a visual record that brings it all together and spreads the word far and wide.”

Measuring the impact

So far, we’ve seen incredible feedback, and we’re excited to see interest in our campaign and our company grow with each passing day.







The ad campaign’s success — and the greater public awareness of Stytch’s solutions — has resulted not only in an organic increase to our web traffic, branded searches, and recruiting efforts, but in a palpable boost to our team’s morale and enthusiasm.

In the end, it’s not just the dislike of passwords that connects us, but the power and promise of a passwordless future.

Go passwordless

Want to see for yourself what all the hype’s about?

Jump into our Docs to check out Stytch’s flexible, frictionless, and fully passwordless authentication solutions — or open a free account, and try them out for yourself. Get started for free today.







---


# Launching Drop-in UI support for Web3 Logins with Ethereum and Solana in the Stytch SDK
Source: https://stytch.com/blog/drop-in-ui-support-for-web3-logins-in-the-stytch-sdk/

Launching Drop-in UI support for Web3 Logins with Ethereum and Solana in the Stytch SDK



Today, the Stytch JavaScript SDK is launching UI support for Web3 authentication for all wallets built on the Ethereum or Solana blockchains. As the future of online identity and experiences take shape, our goal is to equip your product with straightforward tools to interact with these new means of authentication. Web3 login support in the Stytch SDK is the simplest way to build crypto wallet authentication into any Web2 or Web3 application.

This product update includes headless SDK methods you can attach to your auth flows for crypto wallet auth as well as customizable UX flows we’ve designed to easily guide your end users through the process.

Supporting crypto wallet auth could mean you aim to incorporate blockchain elements into your core product or simply want to provide login routes for early technology adopters — whatever your Web3 appetite, the JavaScript SDK can help assist.

Building for user-owned identity

A focal point of Web3 is shifting the ownership of data that defines our online selves from companies back to the individual, as opposed to the many accounts and credentials that we hand off to sites and apps. Digital wallets running on protocols like Ethereum and Solana have paved a path to moving around the internet in a new way. For products supporting these Web3 logins, one’s wallet acts as the single touchpoint they need to provide for various authentication, identity, and payment actions required throughout your UX.



By the numbers, popular wallets like Coinbase, Metamask, and Phantom account for over 13 million users on Chrome browsers alone, with an even broader base of wallet extensions and mobile apps beyond that. As consumers develop more opinions on who has access to their data and when, supplying a wallet auth option can help users log in on their own terms.

Designing wallet detection for Web3 logins

Connecting to apps via a wallet also presents a new frontier in auth UX, as users might own one of any number of the crypto wallets in circulation. With lightweight, high-converting experiences as our design focus at Stytch, we’ve built automatic wallet detection that will present only Web3 logins that are relevant to each individual user, rather than imposing an exhaustive wallet catalog.

https://youtu.be/dFqidd6LAcg

Knowing that your end users will vary widely in terms of what wallets they carry — and whether they’re yet involved enough with Web3 to have a wallet at all — we’ve designed flows that account for a diverse set of scenarios while preventing clutter.

Putting it all together

Let’s look at an example of combining crypto wallet logins with the SDK’s user management functions to determine whether we render a login experience or present the logged in user’s wallet address:



Use the all-in-one Stytch component for a UX flow you can modify and insert directly into your application, or attach the SDK methods to UI elements you’ve designed to create your own experience.

Getting Started

The Stytch docs contain the full SDK reference and associated guides on how to get up and running with this new implementation route. If you’re looking for a low-friction way to get up and running with password-free auth, you can register a developer account here or contact support@stytch.com.

---


# It’s a Stytchiversary! Meet Allison Chuang!
Source: https://stytch.com/blog/meet-allison-chuang/

It’s a Stytchiversary! Meet Allison Chuang!

What do you love most about working at Stytch?

Most definitely the people! I’ve had so much fun working at Stytch because of the people I work with. I also love that at this size of a company you have the opportunity to get to know everyone and are constantly meeting new people as they join. Grateful to have been able to make so many friends here.

What does a typical day at Stytch look like for you?

It really depends on what I'm working on for the month. I like to be around people, so I go into the office most days. I would say I generally spend around 65% of my time doing technical work and my remaining time syncing with teammates, interviewing, etc.

What’s been the most surprising thing about Stytch?

Just how many features / products I’ve had the opportunity to collaborate on and build out this year!

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

I knew that early stage companies evolve quickly, but I didn’t realize how fast things would change. Every 3 months I feel like I am at a totally different company from the previous 3 and I’ve really enjoyed seeing the team grow. It’s so important to be able to adapt to all the changes that come with a startup and I’ve learned a ton along the way.

What’s your favorite part of the Stytch culture?

I love how collaborative everyone here is at Stytch. I feel like I can go to anyone to get more context on something and they’ll happily take time out of their day to get me up to speed. At this point I’ve worked on projects that spanned across both eng and non-eng and it’s always been a really rewarding experience being able to collaborate together.

Which Stytch value resonates most with you and why?

“Own it”

It's exciting to own a full product from start to end and to see the amount of impact it creates. It also promotes a level of accountability within the company in a way that I know everyone I work with is putting in their best effort.

What’s the most interesting project you’ve worked on at Stytch?

I was part of the core team that launched Vessel a few weeks back. It was definitely a wild ride jumping into a consumer product for the first time, but I had a ton of fun building out the UI from scratch and thinking through all the different user interactions for the extension.

How did you end up working in Software Engineering?

I actually went into college thinking I would major in English or Psychology. I took an introductory CS course to fulfill an education requirement and realized how much I enjoyed the logic of it / the ability to create something out of nothing. And I was also pretty good at it!

When’s the last time you did something for the first time and what was it?

I started taking long walks around the city not too long ago. It’s been a nice way to reset my brain and to appreciate everything around me. And not to mention SF has some incredible views.

What song, hobby, or recipe got you through COVID?

I got really into pickleball during COVID and have been playing around 1-2 times a week since. If you’re looking to get into the sport — hit me up. It’s super fun, I promise!

What’s your ideal weekend?

Friends, authentic Chinese food in Outer Sunset, a long walk through Golden Gate Park.

What’s something you’re passionate about that’s not on your resume?

Human behavior and organizational psychology. One of my favorite newsletters is Psyche, which covers topics on psychology and philosophy. Give it a try if you’re interested!

---


# 4 Ways to use Stytch's Embeddable Magic Links
Source: https://stytch.com/blog/4-ways-to-use-stytchs-embeddable-magic-links/

An Embedded Magic Link contains a piece of information attached to the link that can execute an additional action. 

Online authentication is continually evolving. Initially, authentication required only a username and password. Today, measures like two-factor authentication via SMS or authenticator applications have become standard practice.

While these methods enhance security, they can be inconvenient due to the number of steps required. Installing an application, accessing a mobile phone to copy and paste a code, and remembering passwords turn what was once a single action into an unnecessarily frustrating user experience.

Fortunately, another means of authentication is gaining popularity: magic links.

Magic links provide frictionless and passwordless authentication to end users without compromising account security. Magic links are typically single-use and expire quickly. Each magic link contains a token that’s used to verify the user. These tokens are embedded in communications sent to a user’s email or phone number, requiring the user to prove they have access to the email or phone account to access the application.

Stytch’s Embeddable Magic Links add even greater function and flexibility. An Embedded Magic Link contains a piece of information attached to the link that can execute an additional action. For example, an email offering a 10 percent discount can embed a magic link that opens the website, logs in the user, and automatically applies the coupon code.

Previously, a secure promotional email would entail providing a general website link and a copyable discount code. The user would then need to log in and manually paste the code. However, an Embeddable Magic Link already contains the secure authentication token and the instructions to apply the coupon code. The customer only needs to click the link. This user experience is frictionless and offers unparalleled ease.

In this article, we’ll explore several uses for Stytch's Embeddable Magic Links and how they can help your organization meet its business needs in new and creative ways.

Marketing emails and SMS messages



A primary example of the power of Embeddable Magic Links is the ability to send “smart” marketing emails and text messages that greatly improve user experience and eliminate friction.

Consider the example mentioned earlier: emailing customers links that automatically log them in and apply a coupon code. A marketing email can feature several product links, each an embedded magic link that brings the customer directly to the product page and automatically applies the discount. Alternatively, SMS messages can contain the same types of links.

Both of these options ease the user experience. A user doesn’t need to remember — or even provide — a username and password to access their account. This makes for one less barrier between a customer and the targeted website. As well, pre-applying the discount code reminds the customer of possible savings and speeds up the checkout process.

By allowing users to make purchases with fewer clicks, the business can boost conversion rates and improve overall user experience.

Account updates



Currently, the digital banking sector is transforming at a rapid pace. Most customers who use online banking can view their statements, transaction updates, e-transfer notifications, and history using their bank’s website or smartphone app. However, accessing these items typically involves logging in and providing additional security credentials. Moreover, increasingly stringent password requirements make them harder to remember, resulting in countless modes of insecure password storage.

In these scenarios, an Embeddable Magic Link can be instrumental in altering the user experience. With embedded authentication, the user can then log in with magic links sent to the associated email or phone number. The token serves as proof of user authentication without the need for entering complex passwords that have been stored with suboptimal security.

Text reminders



Despite arguments to the contrary, email isn’t yet an obsolete technology. However, the accessibility and flexibility of text messages provide a considerable opportunity for sending timely reminders and notification updates. As you’ve likely experienced, many retail companies and couriers like Amazon, FedEx, and UPS already use text-based services to keep users updated on their items’ delivery status.

However, these SMS messages typically contain basic links. Personalized updates often require users to log in to their accounts before viewing the linked content. More frustrating still is the fact that the login process doesn’t always redirect to where the original link intended. This leaves the user manually navigating through an account or returning to the SMS notification to retry the link.

Embeddable Magic Links can eliminate this hassle. They can immediately bring the customer to the target web page and automatically log them in.

Last leg signup

Cart abandonment rates today are over 69%, with mobile abandonment over 85%. An estimated 26% of users will respond to retargeted ads following an abandoned signup flow. But too often these targeted follow-ups will require users to begin the sign up process from the very beginning.

Fortunately, Embeddable Magic Links removes friction from this process by returning users where they left off in the sign up flow, rather than requiring them to start all over. No re-entering of basic fields like name, email, etc. Embeddable Magic Links help customers skip the line, cut through the red tape, and get back to their cart or complete their sign up registration as quickly as possible. This helps you maximize conversions without minimizing security.

Combining Embeddable Magic Links with multi-factor authentication

Using Embeddable Magic Links doesn’t completely remove multi-factor authentication (MFA) from the security picture. For delicate or sensitive information, you can combine these technologies by first providing the securely authenticated magic links and then using an MFA or one-time password (OTP) solution.

This extra authentication step is especially beneficial when there’s a chance that an email account or cell phone may be compromised. During such scenarios, the extra layer of security is both functional and reinforces to the user that the safety of their personal information is a priority.

Conclusion

As our information security demands evolve to address more sophisticated threats, magic links can provide an intelligent solution for secure authentication without the hassle of multiple login steps. Furthermore, Embeddable Magic Links can elevate your organization’s security protocol to a level of enhancing the user experience and generating more profitable web traffic.

One of the greatest parts of using Embeddable Magic Links is that they don’t have to be a drain on your internal resources. Stytch provides simple and secure passwordless authentication solutions, so that you can stay focused on your core product. To learn more about Stytch’s solutions, check out our documentation and experience Embeddable Magic Links for yourself.







---


# It's a Stytchiversary! Meet Spyri Karasavva!
Source: https://stytch.com/blog/its-a-stytchiversary-meet-spyri-karasavva/

It's a Stytchiversary! Meet Spyri Karasavva!

What do you love most about working at Stytch?

The people! But because everyone says that, here's my second favorite thing about Stytch: the opportunity to have direct impact on the company's trajectory, user experience, and culture.

What does a typical day at Stytch look like for you?

It changes a ton — I feel like I've switched three jobs since I joined Stytch. At the moment, I spend a lot of time thinking about user acquisition and activation strategies.

What’s been the most surprising thing about Stytch?

How open everyone is to learning from each other, as well as giving and receiving feedback.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

What got you to 1 won't get you to 100, and at an early stage company every single person can have an outsized impact.

What’s your favorite part of the Stytch culture?

The openness and transparency when it comes to decision making.

Which Stytch value resonates most with you and why?

Are we thinking big enough yet?

I love pushing each to do better for our customers and end-users, while having a ton of fun in the process.

What’s the most interesting project you’ve worked on at Stytch?

Starting and scaling our startup partnerships! I found it extremely rewarding to lead this initiative from ideation, to scale and optimization.

How did you end up working in growth marketing?

I like working on complex problems, making data-driven decisions and being able to measure the impact of my work. Growth marketing felt like a no-brainer!

When’s the last time you did something for the first time and what was it?

I went bowling a few weeks ago, and discovered that I actually have a decent aim. Growing up in Greece, bowling was definitely not something we did for fun!

What song, hobby, or recipe got you through COVID?

I roadtripped across the US for a year. Favorite stop: Sedona, AZ

What’s your ideal weekend?

Looking for the perfect chocolate croissant (The Mill is still my #1), movie night at the Roxie, and park hangouts with friends.

What’s something you’re passionate about that’s not on your resume?

See above ^

---


# Landing Email Magic Links in your user's inbox
Source: https://stytch.com/blog/landing-email-magic-links/

Stytch Email Magic Links (EMLs) enable one-click email login to sites and applications. As one of Stytch’s most popular products, much of what makes EMLs “magic” for users is the seamless authentication experience of a simple click-through from their inbox.

Stytch Email Magic Links (EMLs) enable one-click email login to sites and applications. As one of Stytch’s most popular products, much of what makes EMLs “magic” for users is the seamless authentication experience of a simple click-through from their inbox.

Behind the scenes, we’ve put a lot of thought and effort into the whole packaging of Email Magic Links and how we send them out to your users. In creating that truly streamlined user flow, we ensure that EMLs always land in your user’s inbox — and the ‘Primary’ tab, too. Email clients and inbox providers like Gmail and Apple Mail all have different rules for how they classify emails as spam, what fonts they support, how they render dark mode, etc. Here at Stytch, we design and test our emails specifically to address all of the complex and changing rules, preventing emails from landing in users’ promotions tab or their spam folder.

In this post, we’ll take a deeper dive into three ways that Stytch works in the background to ensure email deliverability for your users:

1. Reliability and domain reputation

Stytch uses multiple email delivery services to achieve the highest deliverability success rate for your end-users. Knowing that even the most reliable services can experience outages, our built-in logic will automatically failover to another service provider if one service is down.

We keep our email address and domain (login@stytch.com) reputation in tip-top shape, which ensures they won’t be marked as spam in your user’s inbox. The domain and address we use is kept separate from the one you send out changelogs and promotional emails from. We intentionally keep a separate domain for sending out Stytch changelogs and product announcements, so that the “login@stytch.com” address remains reserved for EMLs.

We also have published SPF and DMARC records for our domain that authenticate all of our messages, which prevents email spoofing.

2. Design and copy

Our emails are designed with your end user’s experience in mind, from the raw HTML formatting to the text copy itself. The simplistic layout is intentional in making it as easy as possible for users to authenticate with their Email Magic Link, unlocking that frictionless experience. In addition, being selective about the number and placement of graphics in our HTML helps minimize the chance of the email landing in a ‘Promotions’ tab.

When it comes to the copy, even seemingly harmless words can land your email in the ‘Promotions’ tab of your user’s email client. For example, we discovered that omitting just one word can make a world of difference. In a recent round of testing, we ran over 20 permutations on an email's subject line and found a huge variation in email delivery. For instance, “You’re invited to Stytch” had a much lower success rate of landing in a user’s primary inbox than“You’re invited to join Stytch.”





3. Email customization

Stytch provides you with the flexibility to create emails that align with your branding on your Stytch Dashboard without impacting your email deliverability: upload your logo, select your preferred font, customize your button colors, etc. We’ve researched and tested our list of font offerings across the top email clients and platforms (desktop, mobile, WebMail) to make sure that they’re supported and will render correctly for your users.

Stytch holds accessibility as a core design principle and offers guidance on best accessibility practices in our Dashboard, automatically detecting and showing you the contrast ratios of the colors you choose, and displaying previews of dark mode so you can easily optimize for your users’ preferences. Though accessibility doesn’t always directly impact email deliverability, it is crucial for creating a frictionless EML experience that includes all of your users.





Your Stytch Dashboard allows you to test and preview different customizations on your emails.



At Stytch, we’re on a mission to eliminate friction from the internet. Though the complex rules from email clients add friction to email deliverability, Stytch helps take that load off, so you can focus on your core product. We’re always looking for ways to go beyond the status quo, and elevate authentication by making turnkey and human-centric experiences for developers and end-users. Try customizing your emails on our Dashboard, and read our Docs to see how easy it is to get started with Email Magic Links. With our out-of-the-box EML product, Stytch is able to fully handle the frustrating and complex pieces of email deliverability, latency, and inbox placement. If you’re looking for a more flexible way to use Magic Links such as sending them from your own domain, check out our Embeddable Magic Links here.





---


# It's a Stytchiversary! Meet Shane O'Neill!
Source: https://stytch.com/blog/its-a-stytchiversary-meet-shane-oneill/

It's a Stytchiversary! Meet Shane O'Neill!

What do you love most about working at Stytch?

Our customers. I’ve had the opportunity to work with many of our earliest customers, and everyone we’ve partnered with has been an absolute joy to work with — and they are solving exciting problems across a myriad of verticals.

What does a typical day at Stytch look like for you?

Next question? Every day is something new — which makes working at Stytch so enjoyable.

What’s been the most surprising thing about Stytch?

The most surprising thing about Stytch is the speed at which we ship. Our product and engineering teams move very fast, and I’m always blown away by how many updates are included in the changelog each week. It takes a lot of focus (I enjoy it) to ensure I'm up-to-speed on our products!

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

Cherish the small wins and commit to the journey. There are ups and downs in every early-stage company. So celebrate the small wins throughout your early-stage voyage, and enjoy it! Too often I hear of people wanting a result without the requisite effort. Most of the fun at an early-stage company is rolling up your sleeves and committing. And long as you progress (albeit gradual at times) towards your north star, everything else will work itself out.

What’s your favorite part of the Stytch culture?

We don't take ourselves too seriously, yet at the same time, we are seriously ambitious. It's a tricky balance to strike, and we've nailed it.

Which Stytch value resonates most with you and why?

Fail Fast.

It encourages us to explore while also quickly identifying something that might fail so that we can make it a success.

What’s the most interesting project you’ve worked on at Stytch?

No one project comes to mind but working with our earliest customers was was very interesting and fun.

How did you end up working in Sales?

I went to school and studied Political Science, thinking I wanted to become a diplomat. But I was always interested in technology so I decided to make the leap after a stint in Financial Services. And I haven't looked back.

What song, hobby, or recipe got you through COVID?

I was living in a small flat in London when COVID hit. And Maison Bleue, a shop right around the corner, got me through COVID. They have delicious coffee, food, and provisions. Check out their Insta! https://www.instagram.com/maisonbleue19/?hl=en

What’s your ideal weekend?

Sipping a coffee while reading the Financial Times weekend. Then off into the outdoors.

What’s something you’re passionate about that’s not on your resume?

Sunday Roasts. I fell in love with Sunday Roasts after spending two years in the UK. If you know of any pubs/restaurants in the Bay Area with a proper Sunday Roast, hit me up!

---


# How Apple’s passkeys just brought us one step closer to a passwordless internet
Source: https://stytch.com/blog/what-apple-passkeys-mean-for-passwordless/

Apple announced their new passkeys feature, a next-gen approach to authentication that’s set to launch with iOS 16 and macOS Ventura this fall.

Stytch was founded with the mission of eliminating friction on the internet. The first major source of friction we’ve tackled? Password-based authentication.

We’ve consistently highlighted the many ways passwords contribute to database hacks and account breaches — not to mention the friction and frustration they cause for users, who are forced to memorize dozens (if not hundreds) of passwords and often end up abandoning login flows because of forgotten or mistaken credentials.

Now, we’ve picked up a major ally in our push for a passwordless, frictionless internet. Last month, Apple announced their new passkeys feature, a next-gen approach to authentication that’s set to launch with iOS 16 and macOS Ventura this fall.

Apple’s passkeys log users in via biometric factors like Touch ID and Face ID rather than through conventional passwords, and they’re a major leap forward when it comes to making fully biometrics-based (that is to say, fully passwordless) auth not only familiar but mainstream.

In this post, we explain where passkeys fit in Apple’s wider trajectory of innovation, how they work, and why they’re a big deal for the future of authentication.

A brief history of Apple’s innovations in authentication

Over the past decade or so, Apple has consistently been at the vanguard of passwordless authentication across web and mobile devices. Among other groundbreaking moves:

In 2013, Apple released the first widely available biometric login with Touch ID, allowing users to authenticate into the iPhone 5 via fingerprint.

In 2016, Apple expanded biometric auth options from mobile devices to laptops, building Touch ID logins into the MacBook Pro.

In 2017, Apple introduced Face ID, a biometric auth factor allowing users to scan their facial features to log in to iPhones and iOS applications.

In 2022, it’s all about passkeys, building biometrics like Touch ID and Face ID into every online interaction and across every device.

What’s new?

From the above timeline, it’s clear biometrics have been around for a while — so you may be wondering why they haven’t already become the default for authentication.

The main reason has to do with UX shortcomings of current solutions on the market. Historically, biometric solutions like Touch ID and Face ID have been stored locally on a mobile device or laptop, making it impossible to transfer their login data across platforms.

For example, if a user signed up for an app on their iPhone but then wanted to log in to the same app on a different phone — or on their MacBook — they’d need to undergo a separate verification method (like a username and password or an email magic link) to gain access.

That’s why, even though biometrics are instant, easy, and totally secure, they’ve typically been relegated to serving as a secondary factor in a two-factor authentication flow (2FA).

In an ideal auth world, biometrics would be transferable across devices. A user would be able to sign up for an app on their phone using Face ID, log in on their laptop using Touch ID, and have each system recognize them as the same user. Well, that’s where passkeys come in.

How passkeys work

Passkeys back up the cryptographic key containing a user’s biometric data to their iCloud account, which is already logged in on each connected device.

It may feel like the biometric readers inspecting a user’s fingerprints or facial features have been magically replicated on their phone, tablet, and computer — but really, their iCloud account is simply syncing the cryptographic keys that power those device-level biometric attestations. Part of the magic of this approach to leveraging synced cryptographic keys is that biometric data is never actually stored in iCloud. So, users can verify their identity and log in without having to worry about who has access to their biometric data.

In short, passkeys make biometrics more practical and portable by rendering them interoperable.

That is, passkeys still rely on a “something you are” authentication factor — but they recognize that you’re still you no matter where you go or what device you pick up.

Where does Stytch come in?

We’re thrilled Apple is adding an original, sophisticated passwordless auth method to the market, and we’re excited to offer passkeys through our platform as an integral part of our product suite.

Stytch is all about giving developers and end users (great) options and making them quick and easy to integrate. Apple passkeys are a huge step forward for our mission of eliminating friction on the internet — and doing it in a way that’s intuitive, effortless, and secure.

While passkeys will have a significant impact on how users authenticate online — similar to how Apple Pay impacted online payments — they alone won’t solve all of our authentication needs.

For instance, even though Apple Pay improved the user experience for online payments, businesses still need to provide multiple payment options at checkout to allow users to choose their preferred method. Passkeys’ impact on authentication will be similar — it will improve the authentication experience for most users, but other methods (like email verification, OAuth logins, and passwords) and tooling (like session and user management and 2FA) will persist.

That’s where Stytch comes in. Stytch helps companies support compelling new technologies like passkeys — while also meeting the rest of your users where they are through our full suite of authentication solutions.

Learn more

Stytch’s auth experts are always on hand to walk you through our modern, passwordless solutions and help you embed them seamlessly into your product.

If you’re ready to get up and running, sign up for a free account today to explore our product suite and get in touch with a member of our team. Get started.





---


# Stytch introduces a modern upgrade to Passwords
Source: https://stytch.com/blog/introducing-passwords/

Today, we’re introducing a password-based authentication solution, rebooted for the modern era.

Today, we’re introducing a password-based authentication solution, rebooted for the modern era.

Stytch was founded with the mission of eliminating friction on the internet. Authentication today is a frustrating experience for both developers and users and we set out to fix that. We’ve reimagined what password-based authentication can look like and believe that introducing Passwords will bring us closer to a passwordless future. In this post, we share more on why we’re launching support for Passwords and how we’ve innovated from the ground up to uplevel security and user experience.

Bridging to a passwordless future

The first major source of friction we've attacked at Stytch is password-based authentication, given the UX hurdles involved as well as the security issues it can create.

Over the past two years, we’ve created a suite of passwordless authentication solutions to serve as the infrastructure layer for a passwordless future. Passwordless authentication is more secure, more seamless, and it drives better conversion. We strongly believe that building an all-in-one authentication platform that is passwordless-first is the best path towards our vision of a frictionless internet for both developers and end users.

At the same time, we’ve also spoken with hundreds of companies of varying sizes and at different stages of growth — we’ve come to realize that not every company and customer base is ready to flip the switch and go 100% passwordless today. The username/password paradigm is still heavily entrenched in the way many end users currently engage with applications.

Research shows that while a full 92% of businesses believe going passwordless is the future for their organization, many are not ready to make the leap to a fully-passwordless authentication flow. A full 85% of IT and security professionals don’t think passwords are going away completely.

As a leader in authentication, Stytch’s job isn’t just to point the way forward but to acknowledge barriers to entry and help resolve them. That’s why we’re launching a password-based solution to meet more customers and end users where they are now and help ease them into a passwordless future.



Instead of ignoring the present state, Stytch believes that the best path forward is to meet companies and people where they are and guide them along the adoption curve towards passwordless.

Modernizing passwords

The design of password authentication really hasn’t changed much over the past few decades. We knew that if Stytch was going to take the plunge into passwords, we’d need to design a fresh and modern solution to elevate both security and user experience.

To support our customers and ensure users are given a low-friction yet secure experience, we've completely reimagined password-based authentication from the ground up.

Stytch has built four key innovations into our Passwords solution:

Breach detection: password reuse opens the possibility of credential stuffing attacks. Stytch integrates with HaveIBeenPwnd and prevents users from setting passwords that are present in their dataset of nearly 12 billion compromised credentials. Every time someone logs in with a password, Stytch checks HaveIBeenPwnd to see if those credentials have been compromised since last authentication and triggers a password reset if a breach is detected.

Strength assessment: in the face of password overload, users default to using easy-to-guess passwords. Stytch uses Dropbox’s zxcvbn password strength estimator, which provides a flexible strength assessment based on how resistant a password is to modern password guessing techniques. This feature is designed to make picking a strong password easy for humans to generate and hard for robots to guess.

Safe account de-duplicating: Stytch de-duplicates accounts by email regardless of the authentication method. This allows users to change which authentication option they are using to log in to an app without accidentally creating a new account (e.g. a password user can switch to sign in via Google OAuth) or being forced to re-authenticate with the same method originally used.



More human-centric password reset: when an end user triggers a password reset, most of the time they really just want to access their account, not change their password. With Stytch, customers have the option to integrate a traditional password-reset email OR integrate a password reset powered by Email Magic Links for a more seamless experience. We’re building our password-reset email template to be more human-centric, focusing more on UX and conversions than traditional password-reset flows.





Get started with Stytch

Stytch is committed to helping your company on its journey to passwordless authentication, no matter what stage of the adoption curve you’re in today. Our platform is modularly designed, which means it's easy to get started with low-effort, high-impact products that layer on to password-based flows and build holistically and sequentially from there.

You can learn more about our Passwords solution and discover our full suite of authentication products at Stytch.com. You can also read more about why passwordless authentication matters — or sign up for a free account and jump straight into our docs.









---


# Protect against password spraying
Source: https://stytch.com/blog/protect-against-password-spraying/

Password spraying is one of the most effective, threatening approaches. While sometimes confused with credential stuffing, password spraying represents a different attack vector targeted at passwords’ weaknesses.

Businesses operating in cloud-native environments can be especially susceptible to certain types of attacks, with both their company’s and their customers’ sensitive data at risk. Password spraying, also known as a password spray attack, has proven to be one of the most effective attack methods in the digital era. While sometimes confused with credential stuffing, password spraying represents a different attack vector targeted at the weaknesses of the traditional password.

In this article, we’ll explain how to prevent password spraying attacks and how they're different from credential stuffing, with recommendations on how you can protect against them.

What is a password spraying attack?

Password spraying is a type of brute force attack: A cyberattack where a hacker tries to access a secure account of verified account users through trial and error by repeatedly entering random credentials like passwords with 'brute force' until one works. With password spraying, instead of trying a large number of passwords against a targeted account, the same password is used, or 'sprayed,' at many accounts simultaneously.

The vulnerability of passwords and account lockouts

Most authentication systems are programmed to both prevent password spraying and brute force attacks by locking out the account after entering the wrong password three times, known as account lockouts. Many organizations set a default password for new users, which can be easily exploited in password spraying attacks. Password spraying tries to bypass this defense technique by only using common passwords and spraying them across a wide range of different user accounts, avoiding account lockouts and minimizing failed login attempts.

Plenty of password data exists in the public realm for attackers to glean from. For example, Nordpass publishes an annual list of the 200 most commonly used passwords for educational purposes that can be used by attackers in their password spraying attempts. Other common targets of password spraying attacks are passwords based on easy-to-guess personal information, such as birthdays or names. Weak passwords, combined with a lack of account lockout policies and password complexity requirements, make it harder for organizations to detect password spraying attacks and render them more vulnerable.

How do attackers choose their targets?

Password spraying attacks typically target cloud-based services such as Microsoft Office 365 or other popular email providers. Attackers usually look for login pages where the username/email field is publicly visible, as this simplifies the process of finding valid usernames and complex passwords to spray against. They may also look for login portals that do not have multi-factor authentication (MFA) enabled, making it easier to gain access using just a password. As a result, organizations using cloud-based services are particularly vulnerable to password spraying attacks if they do not have adequate security measures like MFA in place.

Password spraying vs. credential stuffing

While password spraying is often used interchangeably with credential stuffing, there’s a key difference. In a credential stuffing attack, attackers use known compromised usernames and passwords (often exposed in large data leaks), to gain access to a user's password accounts by testing these known credentials on different services to see if passwords have been re-used. This enables attackers to access multiple accounts belonging to the same user.

Password spraying, on the other hand, does not assume to know a particular users’ compromised credentials. Instead, it targets the fact that humans are predictable, commonly using passwords like “Password123” or “P@assword1” or “Qwerty123.” The goal of password spraying is not to gain access to a specific account, but rather any account with a weak password. This is why it’s important for users to have strong passwords and unique passwords for each of their accounts - and why it's equally important for businesses to implement additional security for when this is not the case.

Aside: Both credential stuffing and brute force attacks seek to gain access to sensitive information by compromising a user’s login credentials. While organizations can prevent traditional brute force attacks by configuring authentication systems to limit the number of password attempts, the best method for preventing password spraying and credential stuffing is to move to more modern password solutions or passwordless solutions. Stytch passwordless authentication employs alternative methods such as biometrics, SMS one-time passcodes, or email magic links to verify a user’s identity, eliminating the need for credentials to be stored in a database that can be breached. Learn more.

The ripple effects of a password spraying attack

As mentioned, in a password spray attack, attackers typically start by obtaining a list of usernames and then use common passwords to attempt access. Once the hackers have identified a valid username and password combination, they can gain unauthorized access to the account without immediately alerting security systems.

With access to even a single account, attackers can escalate their privileges by exploiting security vulnerabilities or by using social engineering techniques to gather more sensitive information from compromised accounts (otherwise known as ‘phishing’).

Aside: Stytch's "unphishable" Multi-Factor Authentication (MFA) leverages advanced public-key cryptography along with security keys and biometric login features to provide robust protection against phishing. Unlike traditional MFA methods, Stytch uses a two-key mechanism: a public key stored on the server and a private key only the user can access. This setup ensures that capturing public data doesn’t compromise security. Learn more.

Far-reaching consequences

The damage of password spraying attacks can have ripple effects, going far beyond the point of access to the account. For example, if an attacker obtains access to one password for an email account, they can reset passwords for other linked services, further compromising the user's digital security. Advanced attackers may use this foothold to spread laterally within a network, targeting higher-privilege accounts and extracting or encrypting valuable data for ransom. As a result, the initial stages of a password spraying attack, although seemingly benign, can have far-reaching and devastating consequences for individuals and organizations alike.

Practical prevention measures

Historically, the most effective prevention measure against password spraying attacks has been to ensure that strong, unique passwords are used (no easy feat). This makes it harder for attackers to guess or spray passwords across multiple accounts.

But given that many humans will always opt for memorable (read: vulnerable) passwords, a strong fraud prevention and authentication protocol is now table stakes for any modern organization's security roadmap, including measures like multi-factor authentication (MFA).

Additionally, organizations can implement security tools like intrusion detection systems (IDS) and intrusion prevention systems (IPS) to detect and prevent suspicious patterns of activity on their network. These systems use advanced algorithms to analyze network traffic and identify potential attacks, including password spraying attempts.

How Stytch can prevent password spraying attacks

Stytch offers cutting-edge authentication solutions to help modern organizations combat password spraying attacks.

By anticipating our human tendency towards password reuse, Stytch offers a breach-resistant Password solution that protects users against using weak and compromised credentials to avoid data breaches.

Stytch Device Fingerprinting identifies unique characteristics of a user's device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP address, helping distinguish between human and machine to safeguard against brute force attacks like password spraying. This reduces the likelihood of unauthorized access, as suspicious devices can be flagged and blocked.

Stytch ‘unphishable’ Multi-Factor Authentication (MFA) adds an extra step in the authentication process, requiring users to provide a one-time code or use biometric authentication before gaining access. This ensures that even if passwords are compromised through password spraying attacks, there is an additional layer of protection in place.

In addition to these features, Stytch also offers secure and easy-to-use single sign-on (SSO) solutions. With SSO, users can log in once and gain access to multiple applications without having to remember multiple passwords, reducing the risk of password spraying attacks but also improving user experience by simplifying the login process.

By working with Stytch, developers and businesses can greatly reduce the risk of password spraying attacks and other common forms of cyber threats. Learn more about our flexible, modular authentication solutions and get started with Stytch today.





---


# What is password hashing?
Source: https://stytch.com/blog/what-is-password-hashing/

Password hashing is a strategy to ensure that passwords are stored securely. In this blog post, we’ll explain what password hashing is, why it’s important, and how Stytch's hashing process helps make our Passwords product as modern and secure as possible.

Building a product that requires passwords for user authentication means that you need to implement a method to verify your users’ passwords. However, storing plaintext passwords in your database comes with significant security risks.

Holding this data opens your app up to risk if your database gets breached. Hackers — who can be rogue employees that have access to the database — benefit from these attacks because of the prevalence of users re-using the same password across different websites. Even if your application isn’t particularly security sensitive, attackers hope your users have used those passwords at higher value accounts like their bank accounts. Securely storing passwords is essential to mitigate these risks.

Password hashing is a strategy to ensure that passwords are stored securely. In this blog post, we’ll explain what password hashing is, why it’s important, and how Stytch's hashing process helps make our Passwords product as modern and secure as possible.

The basics of password hashing

Password hashing is the practice of algorithmically turning a password into ciphertext, or an irreversibly obfuscated version of itself, as a means of blocking against the threat of password breaches. Essentially, one string of characters in a password is transformed into a completely different string using a mathematical hashing function. Once a string (password) has been hashed, there’s no way to reverse the process and each time a user logs in, their hashed password is compared with a recorded hashed value.

That might sound a bit technical, so let’s put hashing into human terms — say you have two users, Alice and Bob, who create an account on your website or platform. When they finish registering with a username/email and password, you store their passwords in a database.

When you’re storing these passwords, the worst thing you could do is store them in plain text. Storing in plain text means you’re directly tying your user’s identity to their password in a readable data format, as seen in the image below:



Even if the database is itself secured by authentication, this password storage mechanism remains highly vulnerable. If a hacker is able to break into the server, they’ll have access to all of the application’s password credentials without clearing any additional hurdles. This endangers both the hacked application and any applications where that user has re-used the password.



With this information in tow, bad actors can take these login credentials and use them across websites other than your own. Although it’s a poor practice to use the same password for multiple accounts and across multiple platforms, over half of us still do. And if user passwords are exposed and continuously exploited from a data breach stemming from your website or platform, your users could ultimately hold your organization responsible, which can have reputational, financial, and legal consequences.

It would be a mistake to believe that the remedy to storing passwords in plain text is to simply use encryption. There’s no doubt that compared to plain text, encrypting the passwords is an improvement. If a hacker gets access to the encrypted passwords, they won’t be able to use them immediately, as the encrypted passwords are harder to crack and represent a randomized alphanumeric string, as in the image below.



You might be safe from hackers for a while using encryption, but there’s a caveat: encryption is a two-way street, meaning that the encryption key can be used to decrypt the passwords back to plain text.



If hackers infiltrate your database, they could potentially break into other parts of your network and discover your encryption keys. Storing encrypted passwords also makes them vulnerable to any malicious employee with privileged access to the keys.

How is hashing different from encryption?

Unlike encryption, hashing is a one-way street. When you run a user’s passwords against a one-way hashing algorithm, the result is a random string of text that cannot be reverse engineered or traced back to the original plain text password value.

How does it work? When a user creates a password, the application runs it through a hashing algorithm and stores that random string value in their database (vs. storing a plain text password or an encrypted value). Any time a user logs in, the application runs the same hash function against the user’s submitted plain text value to check if the resulting random string is the same random string stored in its database.

The irreversibility of this hashing function is what makes it such a powerful way to securely store secrets like passwords. It removes the most susceptible attack vectors.



Consequently, even if your hacker discovers the keys used to generate the hash, they won’t be able to convert the hashed values back into the original passwords.



However, this doesn’t mean it’s impossible to crack hashed passwords. Some cyber attacks, such as brute force attacks, dictionary attacks, and rainbow tables can help malicious individuals steal passwords.

In a brute force attack, a huge number of character combinations are used in the password guesses. In the dictionary attack, only words from a long dictionary are tested. Dictionary and brute force attacks have low memory requirements but are computationally expensive because they have to hash the entire list every time.

Rainbow tables are a more computationally efficient (but also more space intensive) way that hashed passwords can be cracked. In this approach, a rainbow table is created that stores a series of chained hashes for common passwords. The hacker can then use the table as a lookup, to see if the compromised database password hash exists in the table and then trace that hash chain backwards to identify the original plaintext password.



Adding salt to hashing

As you can see, hashing alone isn’t secure enough. To better protect passwords from attacks, you add something called a salt. A salt is a sequence of additional characters that we combine with the original password. This combination goes through the hash algorithm to create the password key, as demonstrated below:



While salting is a helpful step in securing hashed passwords, it has limitations. For instance, this salt is often placed in front of each password, creating a trend that’s easy for hackers to identify. Moreover, some organizations will use the same salt for every password, which inherently undercuts the security that password salting offers.

The fast hashing problem

While being “fast” is almost always a desired quality in technology, fast execution is a big problem in hashing algorithms because hackers can use speed to their advantage.

Some hash algorithms, including MD5 and SHA1, are quite fast. And while those algorithms have been used for hashing passwords and can be helpful for some everyday tasks, like database partitioning or computing checksums, security advisors now strongly disapprove of them — especially for password hashing. Modern hardware, such as GPUs, have hundreds of cores that enable massively parallel computing and allow hackers to compute billions of hashes per second when attacking fast hashes.

You need slower hash algorithms to protect users from hackers using ultra-fast GPUs. Examples of these include Argon2, bcrypt and Scrypt. In the next sections we’ll dive deeper into the latter two, which we explored for Stytch’s Passwords solution.

bcrypt

bcrypt is a round-based, adaptive hash algorithm to store a one-way hash of the password. It improves on regular salting by generating a random salt for each password.

With powerful hardware, a hacker can create an attack dictionary against fast hashing algorithms like md5 in a few seconds. But since bcrypt is a slow algorithm, creating this dictionary will take a long time. Additionally, you can increase the iteration count to make it even slower, which helps protect you against brute force attacks.

This is a typical bcrypt hash:





The default cost (rounds) of bcrypt is 10. When this algorithm was conceived, the cost of 10 was secure enough. However, depending on the hardware, this now can take milliseconds. So, you can increase the cost of rounds to 15 or more to make the hashing process take several seconds instead.



Scrypt

Scrypt, also known as Scrypt PBKDF2, was initially developed for Tarsnap, an online backup service with Amazon as one of its clients. Scrypt is a password-based key derivation function (PBKDF) — a memory-intensive algorithm that makes it costly to perform large-scale hardware attacks.

Unlike other PBKDFs, Scrypt’s parallelization factor enables you to finetune the relative CPU cost. The desired key length (dkLen) allows you to define the output size and the CPU and memory cost, further bolstering its security profile.

The first step when using Scrypt is to create a hashed message authentication code (HMAC). Then, Scrypt performs the PBKDF2 function. A memory-hard function called SMIX is executed in a loop, and finally, a PBKDF2 function is executed again. The SMIX function depends on three functions: ROMix, BlockMix, and Salsa20.



Scrypt follows the steps outlined below to hash passwords:

First, Scrypt generates an expensive salt using the block size factor (the r parameter in Nrp) to create “blocks.”

PBKDF2 generates a large array whose size depends on the block size factor (r) and parallelization (p).

Scrypt uses the cost factor (N) as the number of times that each block is mixed using a function called ROMix.

Scrypt then generates a new expensive salt by concatenating all mixed blocks.

Finally, PBKDF2 uses the password and the calculated salt, trimming the output to the desired number of bytes (dkLen).

Stytch’s Passwords solution

There are some security considerations to think through whenever you’re storing a secret value like a password. Although a hashed value can’t be directly translated into a password, its formatting is susceptible to different forms of security breaches, like brute force attacks, where bad actors can continuously generate hashes from random passwords until they find one that matches.

One approach to avoid these headaches altogether is to pursue a passwordless-first approach, but we understand that not everyone is ready to drop passwords entirely. For some user demographics, passwords remain the preferred way to authenticate. That’s why in addition to our suite of passwordless authentication methods, Stytch offers customers a modern approach to securely allowing users to authenticate with Passwords.

Stytch salts and hashes all passwords using Scrypt, before storing in an encrypted database that we manage. We wanted to ensure our Passwords solution is secure and built for performance — we decided on Scrypt in order to strike that balance.

Stytch’s Passwords also introduces novel security features like breach detection (powered by tools like HaveIBeenPwned) and a better strength assessment called zxcvbn (pronounced lower qwerty), which makes it easy for humans to generate passwords but hard for robots to crack them. We’re committed to making secure authentication that’s as frictionless as possible, so we leverage our Email Magic Link technology to reduce the steps from a traditional password reset.

Get started with Stytch

Not all companies are ready to go passwordless, but when ready, they can easily migrate from password-based to passwordless with Stytch. In the meantime, they can rely on our solutions to enjoy the best of both worlds.

Learn more about our Passwords solution and check out our hashing.dev microsite to easily generate or validate your own password hashes, and learn more about how this cool process works!







---


# Stytch vs. Amazon Cognito
Source: https://stytch.com/blog/stytch-vs-amazon-cognito/

But unlike Stytch, Amazon Cognito is limited in its flexibility, reliability and customization — critical factors when it comes to user experience and conversion rates — not to mention its pricing models and tech support.

As a GTM lead at Stytch, I see many customers migrating to our platform from AWS Amazon Cognito — and many more potential customers thinking about making the switch.

It’s not hard to see why.

Much like Stytch, Amazon Cognito provides authentication, authorization, and user management solutions for web and mobile applications. But unlike Stytch, Amazon Cognito is limited in its flexibility, reliability and customization — critical factors when it comes to user experience and conversion rates — not to mention its pricing models and tech support.

In this post, I break down each of these categories one by one to demonstrate why companies consistently choose Stytch over Amazon Cognito.

How Stytch tops Amazon Cognito when it comes to flexibility, reliability, pricing, and support

Customers choose Stytch over Amazon Cognito due to:

Greater flexibility: Amazon Cognito imposes rigid authentication flows and limited options for customization, while Stytch lets customers choose from a range of auth solutions and tailor flows to their brand.

Reliability: Amazon Cognito defaults to a single messaging service — Amazon SNS — that doesn’t support failover redundancy and impacts deliverability for email and SMS. Stytch builds redundancy into every communication-based auth product.

Hands-on support: simply put, Amazon Cognito is a behemoth, and customers might spend hours on hold before they talk to an actual human and get their problems solved. Stytch’s responsive team jumps in quickly to handle any issues via support ticket or Slack.

Practical pricing: Amazon Cognito charges customers per click — even for failed or duplicated requests — while Stytch extends customers a per-user pricing model that scales along with their business.

Rigidity vs. flexibility

The main difference between Stytch and Amazon Cognito has to do with each platform’s flexibility (or lack thereof).

Amazon Cognito’s rigidity is all-encompassing, making it difficult for users to have a smooth sign-up and log in experience. Here are some of the ways that rigidity manifests across features and functions — and how Stytch offers comparatively agile, versatile solutions.

Customization:

Amazon Cognito can host a sign-in screen, but it doesn’t offer much in the way of front-end customization. If a developer wants anything other than the generic UI that comes out of the box, they have to build the entire flow with few resources to guide them.

Take our partners at Bitcoin.com, a multi-chain crypto wallet, marketplace, and news outlet. They needed a flexible auth flow that could support a wide variety of products and services across their platform and show off their brand’s unique personality — something Amazon Cognito couldn’t do.

“With a bigger company like Auth0 or Cognito, you’re one of many clients. You can’t really ask for additional or customized features — you just have to use what they give you. When we reached out to Stytch, it was a totally different experience” –Andrei Terentiev, Head of Engineering at Bitcoin.com

With Stytch, Bitcoin.com gets a suite of auth products that are both secure and highly modular for end-to-end customization. Stytch also offers speedy integration options, from direct API to fully customizable SDKs that adapt to the look, feel, and flow of their platform.



Amazon Cognito offers limited opportunity for branding and customization of your user login flow. In contrast, Stytch’s solutions are designed for you to be able to make them your own. Note that you can choose to use “Powered by Stytch” or remove it.



MFA and sessions

Amazon Cognito supports multi-factor authentication (MFA) — but they front-load friction for users, who are required to complete multi-step auth flows each time they engage with an app, regardless of the level of risk. This approach isn’t just tedious and unnecessary, it can negatively impact UX and tank conversion rates.

Stytch uses smart, route-based (or “just-in-time”) authentication, which introduces additional factors only when they’re warranted for higher-risk tasks — like moving money, editing financial details, or accessing sensitive personal data. All other, read-only actions can be met with scaled-down security for a smoother experience.

User management

Amazon Cognito has two frustrating practices when it comes to user management.

First, if you want to offer popular OAuth login options through platforms like Google or Facebook, you’re forced to use Cognito’s hosted UI — meaning you can’t use your own front end or control the UI/UX.

Second, once a user pool is created in Amazon Cognito, it can’t be changed. That means developers must decide which attributes they want to collect from a user during sign-up at the outset of a project. They can’t make edits later as their app grows and evolves (and most do).

With Stytch, apps can attach multiple authentication factors (like phone and email) to a user and change which options are implemented across the user life cycle.

Password exports

Amazon Cognito doesn’t allow password exports, making it very difficult for apps to switch auth providers. Their end users would be burdened with resetting their credentials for the new flow — which could lead to substantial dropoff. There may be some security logic to this choice, but it unfairly locks businesses into a single vendor.

If Stytch doesn’t live up to an app’s expectations, we think they should be free to switch. That’s why we allow for seamless imports and exports, providing an easy API to transfer all user data at once. Fortunately, our authentication products like Email Magic Links, OAuth Logins, and streamlined password resets are well architected to make migrations simple even if you’re using Amazon Cognito’s passwords product.

Documentation and time to value

We’ve heard from former Amazon Cognito customers that the company's docs and guides are hard to find and even harder to follow, leading to drawn-out and painful integrations.

Developer to developer, we know that no app wants to spend much time implementing their auth flow. They want to spend time focusing on their core product.

That’s why Stytch provides clear, easy-to-understand docs designed to get apps up and running in minutes, whether they’re building an auth solution from scratch or migrating from another platform.

Reliability / performance

Beyond their rigid authentication flows and limited customization options, Amazon Cognito’s reliability and performance is also hampered by their sole reliance on Amazon’s SNS service for messaging. This single point of failure brings about increased errors, meaning more customer support issues that you and your team have to deal with.

Consider Pronti, a smart wardrobe app that helps users plan their outfits and sustainably expand their closets. Pronti initially turned to Amazon Cognito for a simple passcode users could enter to log in, but they soon started seeing failed authentication attempts, mounting complaints, and rising costs.

“With Cognito, we’d get so many user complaints that it would affect our ratings in the App Store. We’d also get about 200 direct messages a week reporting authentication errors that we’d have to deal with. Now, we’re not getting any at all.” –Andrea Veintimilla, Founding Designer and Marketer at Pronti

With Stytch, Pronti went from 200 auth errors to zero — giving them back the time and resources they need to focus on and perfect their core product.

As mentioned in my Stytch vs. Auth0 blog post, Stytch builds redundancy into every communication-based auth product, monitoring uptime and using dynamic failover logic to route across multiple providers. This ensures vendor downtime doesn’t impact your platform and that your users always have a high-quality, uninterrupted experience, with no single point of failure.

Radio silence vs. an attentive team

When it comes to authentication, having a reliable, expert team at your back isn’t just important during the integration process, but on an ongoing basis — should issues arise.

Amazon Cognito has a notoriously bad response time, sometimes letting known bugs linger for years. This can have devastating consequences for companies, like Pronti, which have to spend valuable work hours cleaning up the mess and often suffer reputational damage as a result. With Amazon Cognito, Pronti struggled to get the tech support they needed but with Stytch, they’ve gotten hands-on-support every step of the way.

“With Stytch, it was a collaborative process — zero friction. Whenever an issue arose or something didn’t make sense, their team responded right away and jumped in to fix the docs.” –Mila Banerjee, Founder and CEO at Pronti

Stytch puts a priority on customer support and we have multiple channels to reach us so that you can get a quick and timely response whenever you have a question. I’m proud to say that our customer responsiveness truly stands out.

Per-click vs. per-user pricing

Beyond rigidity, reliability issues and lack of customer support, Cognito’s pricing is not designed to scale. For instance, Amazon Cognito charges for every SMS message sent as part of an MFA flow — which can quickly add up as users repeatedly try to access their account.

“If users grew impatient, they would keep clicking the resend-code button. Since Cognito priced us on a per-code basis, we were charged for every click. As we went viral and traffic increased, our authentication costs went through the roof.” –Mila Banerjee, Founder and CEO at Pronti

Stytch helped Pronti cut down their massive auth bill with a sensible, user-based pricing model that scales with their business. That means Pronti is charged only once per active user — no matter how many times they sign in.

The bottom line

As we’ve heard time and again from our customers, Amazon Cognito can hold applications back when it comes to UI and UX customization, reliability, support, and fair pricing.

That’s why many businesses make the switch to Stytch — and use our flexible, scalable, and hands-on approach to drive better user experiences and conversion rates.

Ready for a change?

Learn why Stytch is the top choice for developers who value security, flexibility and reliability.

Jump into our docs to check out the details behind our customizable, easy-to-integrate authentication solutions — or sign up for a free account to try them out for yourself!





---


# It's a (double) Stytchiversary! Meet Aiden Forrest & Ovadia Harary
Source: https://stytch.com/blog/meet-aiden-forrest-ovadia-harary/

Get the inside scoop on what it's like to work at Stytch.

What do you love most about working at Stytch?

Aiden (AF): As the first brand designer, I love that I helped build the brand and that I get to continue to grow and evolve it — basically I get to do what I love every day! I also love that at Stytch, we have built a company culture in which everyone has a seat at the table and all ideas are welcomed.

Ovadia (OH): I'm a big fan of the team. The team comes from a range of experiences and backgrounds, and I've learned a lot from everyone at the company, and most importantly everyone is fun and enjoyable to work with.

What does a typical day at Stytch look like for you?

AF: I don't think a typical day really exists for me but during the week I am usually heads down on a design project, reviewing design work and providing feedback or in meetings.

OH: I work on east coast hours, so while the rest of the team is snoozing, I get most of my code writing, code reviews and other heads-down work done in the morning. The afternoons are a mix of pairing with the team, writing technical specs and once in a while a meeting.

What’s been the most surprising thing about Stytch?

AF: The rate at which we've scaled! It's been really amazing to watch the team grow from 10 people to 50+ in little over a year.

OH: The pace and progress we’re able to make as a company. Everyone is heads down working and it is impressive what we are able to achieve.

Stytch has gone from 0-1 in the last year, what have been some of your biggest learnings about joining an early stage company?

AF: It is rewarding and fun to be apart of an early stage company but you have to be ready for a lot of change and pivots along the way. It's been important for me to stay adaptable and flexible.

OH: It's incredible what you learn from your early customers — you really can't build in a vacuum. You need to always be talking to your customers and having them use your product.

What’s your favorite part of the Stytch culture?

AF: Everyone is a team player and always happy to jump in and help one another out!

OH:The passion everyone brings to work.

What Stytch value resonates the most with you and why?

AF: Fail fast. As a designer I find myself moving quickly on projects so I can iterate multiple times to get to the best solution. This should be a part of every designer's DNA.

What’s the most interesting project you’ve worked on at Stytch?

AF: There have been so many already, but my favorite projects have been creating brand systems for the core Stytch brand and our Web3 consumer brand Vessel. I love the branding process and find that it's my happy place. It's also very rewarding to start out with just a name on a piece of paper and turn it into a whole visual system.

OH: We migrated our infrastructure we run our core services on and it reduced our deploy time by ~75%.

How did you end up becoming a Brand Designer?

AF: I went to school for graphic design! After graduating from college I moved to San Francisco where I started in advertising but soon pivoted to a small music tech company where I fell in love with in-house design and the impact you can have working with just one brand.

When’s the last time you did something for the first time and what was it?

AF: I've been working and living in Portugal for the summer! I've never been to Portugal or tried working remotely from another time zone. It's been a great experience and I'm so grateful the Stytch team has been so supportive.

OH: A couple months ago I was visiting Stytch HQ and I learned how to do my first somersault (at least as an adult). It was riveting.

What song, hobby, or receipe got you through COVID?

AF: None of the above. It was reality TV LOL! I watched a lot of Bachelor and Love Island.

What’s your ideal weekend?

AF: Going on a long walk and ending up a craft brewery.

OH: Beach. Eat. Sleep. Repeat.

What’s something that’s not on your resume that you’re passionate about?

AF: Thrift and vintage shopping! Anytime I travel I always make a point to find the best thrift stores and flea markets.

Wanna work with great people like Aiden and Ovadia? We're hiring! Check out the Stytch Careers page to see what fits.

---


# How the API economy can radically transform your business
Source: https://stytch.com/blog/the-api-economy-can-transform-your-business/

learn about the API economy and how API companies can benefit your business.

On June 22nd, 2022 Stytch co-founder Julianna Lamb presented on the API economy at Collision, one of North America’s largest tech conferences. Her presentation inspired this article — watch it here.

Stytch is an API-first company. That means we build and perfect turnkey, easy-to-integrate authentication solutions — so you don’t have to. But we’re just one part of a much larger API economy that’s radically transforming the way organizations approach their digital roadmaps.

When we say API economy, we’re referring to a global network of API companies, each providing the technical infrastructure to unlock a specific function or capability for growing companies and enabling them to scale faster.

Today, API companies command hundreds of billions in market cap, and they’re fundamentally changing the way your company can ideate and build products.

In this post, we explain what an API is, how different API companies make up the API economy, and how this new landscape can supercharge your team to ship better products and features more quickly.

What is an API — and why does it matter?

API stands for application programming interface. APIs essentially work as mediators or messengers that allow different applications to communicate. More specifically, APIs are responsible for exchanging data and performing actions across services.

But beyond the technical, why do APIs matter for your company, for your product and for your business? Because by facilitating interactions between systems, APIs make it easier and faster for developers to integrate and innovate around essential services needed for a business to succeed (e.g. the ability to communicate, to authenticate users, and receive payments).

Simply put, APIs allow you to focus on what you do best, and outsource the rest.

At earlier stages of web development (pre-API), you had to build a team of experts skilled at building an SMTP server, integrating with telecoms, authenticating users, processing payments, and so on. Building each of these essential app components could easily require an engineering team of dozens, if not more. But today, you can get all of these functionalities out of the box with a simple API – now, more than ever, you don’t have to worry about building it yourself because there are best-in-breed API companies to rely on for each of these application functionalities.

Understanding the different pieces of the API economy

The best part of API companies is that they have one sole focus. That means they invest all their engineering and product resources in building the best-in-class solution for a specific problem. By leaning on API companies with a niche area of expertise, you’re able to embed all that knowledge directly into your product — without having to invest significant time and resources in the process.

There are a myriad of different types of API companies that make up the API economy. Some major functions they can serve include:

Performing a specific action: for example, Twilio helps you send an SMS; Mailchimp helps you send an email; Checkr helps you perform a background check.

Providing a specific piece of a product’s functionality: for instance, Stripe helps companies facilitate and process payments for their goods and services, while Stytch authenticates users into an app or website.

Enabling data connectivity (APIs for APIs): companies like Plaid and Merge are universal APIs, which help companies aggregate data from dozens of different APIs, platforms, and accounts through a single integration.

Powering the API economy: companies like Postman make it easier for companies to use and manage APIs, while MuleSoft makes it easier to build APIs.



A modern tech stack including functional components like an SMS verification API, a search API, and a multi factor verification API enables rapid development. So, how does all this help you achieve real results?

Business benefits of the API economy

APIs can yield several important and immediate benefits for a partnering business. Among other advantages, they help you:

Increase efficiency: APIs abstract away the application layer, so you can focus on the unique and innovative parts of your products and rely on API companies for everything else.


Improve UX: a specialized API company lives and breathes a specific solution and will be able to provide a much better user experience than the fractional attention your team can spend on a non-differential feature.


Scale effortlessly: you can leverage an API to quickly test and validate your product roadmap and add additional solutions from the API platform as you grow and discover new needs. What's more, APIs will scale with you. API companies have built-in infrastructure to support your growth and handle any potential scale issues.


Future-proof your business: finally, API companies are continuously investing in cutting-edge technology in their domain of expertise. As they discover and implement new technology, you get instant access through your existing partnership and integration.

Embrace the API economy with Stytch

The main message here? Don’t reinvent the wheel. Take full advantage of third-party API companies’ expertise to fuel and accelerate your product development.

Just as it would seem outrageous to build your own data centers in 2022, it will soon feel just as outrageous to build undifferentiated pieces of your product — like login or search capabilities — when you could be investing that development time and effort in building a stellar, differentiated product.

If you want to learn more about Stytch’s API — and how you can build simple, out-of-the-box authentication flows directly into your product in minutes — reach out to our team, and get your questions answered.

Or — sign up, and explore our easy-to-integrate authentication solutions for yourself.







---


# A founder’s guide to raising your seed round
Source: https://stytch.com/blog/a-founders-guide-to-raising-your-seed-round/

Stytch co-founder and CEO Reed McGinley-Stempel shares his advice on raising your seed round

I’m often asked by other founders about Stytch’s seed fundraising experience and what advice I’d give to other early-stage founders navigating the process today. While the overall fundraising environment has shifted in recent months, I think my advice for approaching a seed fundraise still fundamentally applies in the current market. I wanted to take a moment to put in writing what I’ve shared with many founders one-on-one, with the hope of ultimately being helpful to a wider audience.

There are many things you can’t control when entering the fundraising process: an investor’s predisposition (or lack thereof) to your idea and space, your team’s background, the market environment, or even a VC’s relative mood on pitch day.

But there are two concrete things you do have control over:

How you craft your pitch deck

How you structure the fundraise process and timeline

These likely sound obvious, but there are some tactical learnings we had during our seed fundraise (both through the helpful advice of others and through our own initial mistakes) that I share with every early-stage founder who asks for advice on raising capital.

1. Craft a pitch that hits the right notes

You likely have a pretty good idea of what a pitch deck should look like, and there are lots of other great materials out there on what to include in your deck (founding backstory, market sizing, etc.). To avoid being repetitive, I’ll focus on two very specific learnings that helped elevate the conversations we were having with VCs and ultimately led to a competitive fundraise for Stytch’s seed round.

Anecdotal Data is underrated – use it to show expertise and make the problem more tangible to VCs

Quantitative data is great, but at the earliest stages, you often don’t have that much of it. During your pre-seed or seed fundraise, qualitative data will play an outsized role in convincing VCs (a) whether the problem you’re tackling is worth solving, (b) how acute the pain is for potential customers, and (c) whether there is founder-market fit with your startup (i.e. are you the right person to build this idea?).

Early stage VCs tend to be storytellers, so rather than dismissing anecdotal data, they actually embrace it – if you’re able to provide insightful anecdata (whether it’s user quotes, interviews, etc.), they can often be what VCs remember most vividly from the pitch. My recommendation is to find ways to weave in qualitative data throughout the presentation. This will be more effective than just dedicating one slide at the end to customer quotes. As an example, we included ten detailed quotes from interested customers on three different slides to help highlight the point we were making on each one.

The other advantage of weaving the right anecdata into your pitch is that it allows you to show your expertise on the topic and the extensive research that you’ve put into the space. That, in itself, is a superpower – you should know 10 to 100 times more about your subject than everyone else in the room. Demonstrating that level of expertise is powerful, and while it can be hard to show this in a 30-minute conversation with a VC, things like prospect or customer quotes help reveal how deeply you’ve investigated the space. Lean heavily into the deep conversations you’ve had with users and customers to craft a compelling pitch that demonstrates your familiarity with the pain you’re looking to address.

Here are a couple examples of how we weaved prospect quotes into our seed deck:













Make sure you have 1-2 slides at the end of the deck that help answer the following question: how could this ultimately be a $50B or $100B company?

As mentioned above, showing your expertise in the immediate problem to be solved is important. That said, it’s often easy to get too deep into the weeds, and it’s important to also take a step back and recognize your VC audience and their ultimate goal - returning the fund.

One of the most helpful pieces of advice we received when preparing our deck was to explicitly outline how Stytch could become a $100B company. You’ll want to illustrate how your company can reach that scale in the next decade to truly excite VCs about your potential given the power law curve governing venture capital’s investment strategy.

It’s helpful to understand the psychology of how VCs approach investment bets. Venture capital performance follows a power law curve rather than a normal distribution:

Source



Effectively, this means that a few great outlier performances will be responsible for determining whether a venture fund is successful. VCs need extremely high payouts on the few bets that perform well in order to justify the illiquidity of the asset class (without the potential of such outsized returns, LPs would be better served allocating their funds into a more liquid asset).

And while VCs know they need to find a few massive winners, they also understand that most investments in the fund will be underperformers. VCs are much more worried about missing an incredible positive outlier than they are about investing in a company that returns little to none of their investment. When you consider the psychology of how VCs invest, it becomes clear why you’ll want to argue how your company could be one of the few hyper performers in their portfolio if things go well. Very rarely is it obvious how a startup could become a $50B or $100B company – it’s much safer to explicitly outline how your startup could achieve this rather than expecting a VC to craft this narrative for you.

When we raised Stytch’s seed round, the most comparable company in our market (Auth0) had recently been valued at $1.9B. That’s obviously an impressive sum, but it’s not an extraordinary valuation since even surpassing Auth0 wouldn’t necessarily return the fund for many of the VCs we were pitching to.

While my co-founder and I had a firm idea for what could potentially enable us to build Stytch into an eye-popping valuation if the early years went well, I initially struggled to convey this in our pitch deck. Admittedly, it can feel absurd – even arrogant – to be thinking on such a large scale when you’re still pre-revenue, but VCs want to know that you’re thinking about the 10-year+ vision.

Chances are you won’t build a $100B+ company (exceptionally few people will), but given the type of founder mindset VCs want to bet on, you need to clearly articulate how this initial idea could grow into something much larger.

Note: If you’d like a copy of our seed pitch deck, feel free to reach out to us at startups@stytch.com and we’ll be happy to share it and answer any questions you have about the fundraising process.

2. Run a tight fundraising process

Just as important as the pitch deck is how you actually run the fundraise process itself. Being intentional and streamlined in your approach can help elicit more bids under better terms. Being unintentional often leads to fundraising rounds that drag on and suboptimal terms.

One small piece of advice when starting out is to maintain a simple spreadsheet of every firm you want to meet, your potential point of introduction, and notes from your meetings with those investors. This spreadsheet is most helpful at the beginning of your process when you’ll want to kick off your introductions to each of those firms in as compressed of a timeline as possible.

Make your own copy of this template



Keep timing tight and maintain leverage

Running a fundraising process can very quickly turn into an all-consuming effort that ends up distracting you from what you need to be focusing on, which is building your product. With that in mind, you’ll want to be intentional about keeping timelines as tight as possible, which means condensing everything into 2-4 weeks if you can. Treat it as your full-time job during this period.

Moreover, as a part of this tight process, you’ll want to kick off as many VC conversations as possible simultaneously in order to keep them on similar timelines. This will reduce the likelihood of VCs sharing information amongst themselves, which means you can maintain more of an advantage in your pricing negotiations. And finally, don’t underestimate the power of FOMO – keeping the process short means competing VCs are less likely to hear about funds that may have passed on you, ultimately keeping VC interest as high as possible.

There are many other important elements to a fundraise, but the above considerations for crafting your pitch deck and being intentional with your timeline are the most helpful learnings I had during Stytch’s seed raise. If you have any questions, feel free to reach out to startups@stytch.com to ask for anything – we’re happy to provide input on your seed deck and fundraising strategy!

---


# What is password salting?
Source: https://stytch.com/blog/what-is-password-salting/

Learn what password salting is, why it is important, best practices and how Stytch solutions create enhanced security.

Passwords remain the most common method of user authentication. Yet, they’re not the most secure. One solution to certain security concerns with password authentication involves hashing, a form of one-way encryption that transforms one string of characters in a password into a completely different string using a mathematical hashing function.

To improve the safety of your hashing algorithm, you can also use security techniques such as salting, where you add a “salt value,” or a set of random characters, to the password before hashing it. Using techniques like salting exponentially increase the computational cost for attackers to decipher the hash if your system is ever breached.

In this article, we will discuss what salting is, how it improves the strength of a hash, and what the differences are between salting and peppering. Then, we’ll discuss some best practices for salting a hash and highlight how Stytch’s Passwords solution uses salting to enhance security and protect against hackers.

What is salting?

Salting is the process of modifying the password string that is to be hashed by adding a salt value to that initial string. A salt is a string of characters that could either be a legible word or, preferably, a set of random characters.

For example, you might have a password like Pa$$word, with a salt value of Df)0!2. Instead of storing the hashed password as-is, the system will add the salt somewhere to the string — usually before the password, though it can also be after.

The string that will be hashed will be the salt plus the password: Df)0!2Pa$$word, in this example. This new string will then get hashed and saved into the database. So, even if there were to be a data breach and the hashed passwords were to be leaked, the added salt would make even common passwords tough to crack.

The value of salting in addition to hashing passwords becomes clearer when you consider how attackers will attempt to crack hashed passwords that are exposed in a data breach. While storing passwords in plaintext is the worst password storage hygiene, rainbow table attacks make the sole act of hashing passwords inadequate when it comes to securing your users. “Rainbow table attacks” leverage pre-computed lists of password hashes to infer the plaintext value of a leaked hash value. By adding a salt to your password hashing process, you remove the ability for hackers to leverage these pre-computed lists.

Salting versus peppering

Salting and peppering, at the core, have the same goal. Both involve altering the initial string by adding a random value to it before being hashed. The key difference between them is where they are stored.

Peppering also describes the adding of a pepper (a random value) to a password during hashing, but unlike salting, the value isn’t kept with the password in the database — instead, it’s saved separately in a different location and form, like in the application code or a Hardware Security Module.

One peppering technique is to randomly select a pepper from a list of strings. The pepper used isn’t saved, so each login attempt means the application needs to try each pepper in the list until it finds a matching hash. This is very effective against attacks but places a huge load on the software doing the authentication as you will essentially create multiple log-in attempts while cycling through the list of peppers.

Another notable difference is that salting is usually unique per password, whereas peppering would use the same value, or one value of a list of peppers, for each password. The salt would be saved with the hashed password in the database, and the pepper would be in the codebase, in a secure key vault type of service.

Unfortunately, this causes peppering to be more hardware intensive than salting, and the computational cost exponentially increases the more users you have. It also causes the login process to be much slower than salting due to the calculation processes.

Salting best practices

When implementing salting as part of a password storage and hashing process, there are some best practices to follow:

Use unique salts: Each unique salt will exponentially increase the computational load to crack the hashed passwords because cracking one password has no bearing on the rest of the passwords. Ideally, there is a unique salt per password, so when a user changes their password, that user-password combination would receive a new salt. This means you shouldn’t:

Use usernames as the salt value

Use actual words as salts

Instead, you use randomly generated strings that draws from upper- and lower-case characters, symbols, and numbers.

Use longer salts: The more characters a hash has, the more computational cost is involved in breaking the hash. Since each hash algorithm outputs a consistent hash length, it’s wise to have a salt of the same character length as what the hash would be.

Add extra security to your hashes: Add a key to the hash, which should be kept off-site on a separate server. That way, if a hacker were to access a database containing the hashed passwords, they would need to gain access to this separate server as well to get the key.

You can also run the password through the hash algorithm multiple times.



Salting with Stytch

Instead of trying to implement salting yourself, you can turn to Stytch to ensure your salting technique is thorough, advanced, and secure. Our new Passwords solution implements all of the best practices outlined above, offering the most secure, properly salted hash available. We wanted to ensure this password solution used the most efficient and secure hashing algorithm, so we’ve used Scrypt to support our salting and hashing algorithm.

Stytch also provides breach detection, helping to prevent the use of credentials that have been compromised, and password strength detection, which makes sure that each link in the chain is as strong and secure as possible. This helps dramatically reduce account takeover risk.

Since new ways are constantly being developed to hack passwords, one solution is to move away from passwords entirely. Stytch offers passwordless authentication, meaning users can use things like biometrics, OAuth, Magic Links, SMS and WhatsApp Passcodes, and other passwordless forms of authentication that keep your users — and your systems — secure.

But if you’re not quite ready for passwordless, that’s okay! Stytch’s password solution is the most secure option available and will help keep your sensitive information safe.

Protect your passwords with Stytch

Salting is a necessity when storing passwords, as it protects yourself as well as your users. It provides that extra set of uniqueness to a password and, in turn, makes the password exponentially more secure — on top of the base level of security that password hashing offers.

Stytch uses best practices to ensure that the salts used are unique and that each password is properly hashed and secure. To see Stytch’s salting strengths in action for yourself, get started with Stytch today.

---


# How to prevent account takeover (ATO) and improve user authentication
Source: https://stytch.com/blog/improve-user-authentication-to-prevent-data-breaches/

Learn how poor user authentication can lead to account takeover, and steps you can take to ensure your security and identity are protected and not at risk.

Poor user experiences are directly responsible for most instances of online fraud and account takeover (ATO).

Today, 82% of all successful data breaches can be traced to the human element in online security — specifically, weak or reused passwords that can be easily used by hackers to mount credential stuffing attacks or brute-force attacks and take over a user's account.

But users aren't really to blame for putting their data at risk. Instead, the fault lies in the burdensome password experiences many applications put them through whenever they want to create or safeguard a new account.

In this post, we review how account takeover attacks work — and how modern auth solutions with better user experiences can help prevent them.

Playing whack-a-mole with account security

Weak passwords have introduced major security threats that nearly every app developer finds themselves scrambling to prevent:

Credential stuffing attacks and brute-force attacks

Both of these strategies involve using compromised or stolen credentials to carry out an account takeover and data breach.

In a credential stuffing attack, a hacker intercepts account details — typically, username and password pairs — through a data breach. Since most users reuse the same credentials across multiple websites, the hacker can then use bot traffic to "stuff" these login details into different apps and websites on a trial-and-error basis to gain access to several of a user's accounts at once.

In a brute-force attack, on the other hand, these attempts are less targeted, with hackers trying popular password combinations (think "12345") at random across different accounts to gain access.

Account takeover

In an account takeover, hackers execute the final step to actually take control of a user's account(s). Account takeover attacks typically have a financial motive, with the hacker using stolen accounts to directly defraud users (e.g., draining funds from their bank account) or businesses (e.g., making an e-commerce purchase that the retailer will ultimately be forced to refund).

Adding friction to the user experience

Today, companies spend significant resources and place multiple points of friction in front of good users to reduce the risk of credential stuffing, brute-force, and account takeover attacks.

For instance, many apps integrate reCAPTCHA or hCAPTCHA technologies to detect and prevent bot activity. They may also add two-factor authentication (2FA) or multi-factor authentication (MFA) in the form of SMS one-time passcodes or TOTP to protect against account takeover once a user's password is compromised.

The anatomy of a successful account takeover attack

To understand how applications can optimize their account takeover prevention, it's helpful to understand how account takeover attacks work.

These attacks are attractive to fraudsters because they're 1) very lucrative and 2) easily scalable.

Paths to a successful account takeover

For one thing, account takeover attacks are often highly coordinated operations and fueled by an entire cottage industry of fraud. Different hacker teams may each conduct one of three different steps involved in account takeover attempts.



Let's explore these three steps in greater detail:

1. Hackers find a way to break into an app or website's user database to extract login credentials like emails, usernames, and passwords.

The applications most frequently targeted for these types of hacks tend to share two key traits:

They have a large user base.

They are not a security-centric company.

Of course, not being “security-centric” doesn't mean an app doesn't care about security. It simply means that security is not the primary consideration for their product or its value proposition. For example, banking apps and custodial crypto accounts are only valuable if they can safeguard a user's funds, so they typically invest heavily in security and are generally considered more difficult to breach. That said, hackers don't actually need to breach the Coinbase or Chase app to steal a user's bank account; they can just as easily get in via LinkedIn or DoorDash. More on that later.

2. Once hackers have successfully breached a database, they'll determine where else a user may have reused the same credentials, so they can gain access to multiple accounts.

Hackers realize that stealing a user's LinkedIn account holds some value, but the path to monetization is much more difficult and much less rewarding than stealing that same user's financial accounts.

That's why, at this point, they'll either sell the list of breached credentials to the highest bidder or invest in software that allows them to programmatically send login requests (via bots) to other apps and user accounts they're more interested in breaching. This is one of the main reasons users are often asked to confirm they're not a robot when signing in.

3. Once hackers have validated where else a user's stolen credentials can be used, they progress to exploitation, inflicting as much financial damage as possible.

The exact method of fraud and monetization may differ at this stage, depending on the type of account that's been stolen. For instance, a hacker can directly drain a financial account of the money within, but they may only seek to leverage a social media account to launch phishing attacks on a user's contacts or promote specific products for a kickback.

Scaling account takeover attacks

What makes these attacks so common and dangerous is the sheer scalability of the attack vector.

If a hacker can breach 10 million passwords, validate that 20% of them were also used at a major bank through programmatic means, and then drain those accounts without ever incurring the risk of walking into a bank branch, they've essentially found a modern, remote, and relatively low-risk way to become a bank robber.

It's no surprise that account takeover and online identity theft lead to massive financial losses every year. In 2021 alone, $12 billion was lost to account takeover fraud, representing a 3x increase from 2018. For context, that amount is roughly 25x higher than the worldwide fraud loss from bank robberies when last measured in 2019.

How better user experiences can prevent account takeover fraud

Tools like Google's Password Checkup can be a great way to audit the security posture of a user's online accounts. But the results of these audits can reveal just how risky a poor user experience can be and how overwhelming we've made it to actually remedy cybersecurity issues.



For example, the user in the screenshot above has:

15 known compromised passwords, meaning they've likely been exposed in data breaches like those suffered by Yahoo, Target, LinkedIn, and so on

107 re-used passwords across multiple accounts

109 weak passwords that can be easily guessed by hackers or bots

How did we end up in a world where a normal user has 200+ insecure online accounts? And why are we putting the onus on users to fix these vulnerabilities, when they ultimately come down to suboptimal sign up and log in flows?

There are two critical shortcomings apps introduce to the user experience when users attempt to create an account and/or improve their account security:

1. They make it easy for users to shoot themselves in the foot when creating passwords.

Today's users are asked to manage hundreds of online accounts, and each new password they create is required to include a complex mix of letters, digits, and symbols. It's no wonder they look for shortcuts and re-use the same password across multiple sites, ultimately putting themselves at risk when one or more of those sites is hacked.

Most users don't intuit the interconnectedness of online security, nor realize that an insecure password on their streaming service could actually imperil their bank account. And, given the decades of failed education on the topic, we may have to admit that they never will.

2. While tools like Password Checkup are extremely valuable, it's easy to see why users give up when presented with a multi-step process to fix their online security.

Simply put, we're never going to convince the average user to undergo this much friction to prevent account takeover fraud. Instead, this issue needs to be solved at the application level, so users are not asked to be their own security experts.

Currently, the user experience is broken when it comes to helping users create safer passwords and making it easy to remedy cybersecurity issues. Fortunately, there are modern authentication tools available that allow apps to protect their users (and themselves) with minimal engineering effort.

Using modern authentication tools for account takeover prevention

Over the past few years, the tools to prevent account takeover have dramatically improved, offering a great opportunity for apps to upgrade the UX and the security posture of their sign up and log in flows.

Here are some of the key strategies app developers should consider adopting to prevent account takeover attacks and ward off popular tactics like credential stuffing:

1. Improve the security of users' passwords.

There are two simple but concrete ways to do this right away.

 Don't allow users to enter compromised credentials in your sign up and log in flows.

There are endless data breaches exposing users' passwords, but there are also great resources developers can plug into to detect compromised credentials. Apps and websites can turn to tools like HaveIBeenPwned (supported by Stytch's password check API), which prevent users from re-using credentials that are known to have been stolen in a previous hack.

Or, if a user already has an existing password, apps can check whether it's been leaked when that user tries to log in again — and force a password-reset flow if it has. Doing so compels would-be hackers to also breach a user's email inbox, which is much more difficult given the prevalence of multi-factor authentication (MFA) on email accounts.


Move away from friction-heavy and security-light password strength estimators, and use more modern ways to improve users' passwords.

Traditional password strength estimators follow the LUDS formula, requiring users to include at least one lower-case and upper-case letter, digit, and symbol in a new password. Unfortunately, humans are predictable, and we often end up with insecure passwords that satisfy these conditions but are exceedingly easy for machines to crack — think, P@ssword1, Password1!, etc.

Instead, Stytch uses Dropbox's zxcvbn password strength estimator, which offers a more flexible assessment based on how resistant a password is to the latest password-guessing techniques. This feature is designed to make strong passwords easy for humans to generate and hard for robots to guess.



2. Integrate better bot prevention technologies.

Every app and website should integrate some form of bot detection and prevention. Google reCAPTCHA remains the standard option, but there are also more advanced products on the market, like hCaptcha and Arkose Labs.

Any type of bot prevention is better than nothing, but if an app is still suffering from attacks on sensitive user routes, it's likely due to the increasing availability (and relatively low cost) of CAPTCHA-solving services like Anti CAPTCHA, which make it easy for bots to bypass a CAPTCHA system if the hacker is willing to pay a minimal sum.

To make CAPTCHA solution un-bot-able, Stytch has developed a proprietary CAPTCHA solution that offers stronger protection against CAPTCHA-solving services.



3. Consider using passwordless auth, which is more difficult and more expensive for hackers to attack.

Passwordless technologies are particularly powerful because they can either be layered on in a multi-factor authentication flow or used as the primary auth method while reducing user friction.

Most passwordless methods are used as secondary factors, asking users to verify “something they have” (e.g., a specific device, access to a registered email address or phone number, a YubiKey, etc.) or “something they are” (via biometrics like facial recognition or fingerprint scans) once they've already presented "something they know" in the form of a password.

The two major benefits of passwordless auth are its ease of use — which can improve conversion rates, lower customer acquisition costs, and increase lifetime value — and the higher cost of an attack. Unlike traditional passwords, passwordless methods are not well-suited for scaled attacks, because hackers cannot steal phone numbers, on-device biometrics, or email accounts in bulk. This considerably increases the cost of each individual hack, which is why fraudsters focus their efforts on password reuse today.

While there are attack vectors focused on certain passwordless technologies (for instance, some users' phone numbers are targeted when attackers want to take control of their SMS inbox), these attacks are rarer, given the cost involved. They're also easily mitigated by using the appropriate authentication method. For instance, if an app protects financial assets, its developers may choose not to offer SMS-based auth as an option, instead gravitating toward biometrics or device-based methods like TOTP and WebAuthn.

Another simple way to improve both security and the user experience is to take a hybrid approach to password-based and passwordless auth with a streamlined password reset flow. Adding a simple magic link login option (instead of requiring users to change their password entirely) gives them the option to avoid the friction of a reset and log back in with a single click.



The bottom line

There's no one silver bullet that will eliminate the risk of account takeovers and data breaches — but thanks to modern auth tools, there are simple, straightforward ways that apps can enhance their sign up and log in flows while keeping their users safe.

Defend against account takeovers with Stytch

Stytch offers a range of robust passwordless and password-based auth solutions as part of our flexible product suite.

To learn more about how they work, reach out to a member of our team—or sign up for a free account to try them out for yourself.

---


# Stytch’s guide to adding passwordless options for password-based auth flows
Source: https://stytch.com/blog/adding-passwordless-to-passwords/

Learn how you can boost your app’s UX and security by adding passwordless auth options to your password-based flow.

Adding passwordless options to your password-based auth flow is a quick, seamless way to boost security and user engagement.

At Stytch, we’re passionate about the power of frictionless, passwordless authentication, and we believe it’s the way of the future. But we also realize that each application and user base is unique, and not everyone is ready to ditch passwords for good. For that reason, we offer a full suite of Customer and Identity Access Management (CIAM) solutions including both password-based and passwordless options to help you provide the most secure and high-converting auth flows to your customers.

Luckily, adopting passwordless auth isn’t an either/or proposition.

You can easily add passwordless options to your existing password-based flow — whether as one option among many or as a primary or secondary factor in a multi-factor authentication (MFA) flow — and still enjoy all of the associated UX and security benefits. As an added bonus, if or when you do decide to go fully passwordless, you’ll already have all the right pieces in place.

In this guide, we navigate the first step forward on the authentication adoption curve and share how you can shift from an exclusively password-based flow to a hybrid password/passwordless flow, with a glimpse into some of the most common transitional auth models in use today.



Finding the right path to passwordless

No two journeys on the authentication adoption curve are alike. You may be eager to implement a passwordless solution as your primary authentication factor, or you may merely want to include one as a parallel or secondary factor.

For those early in the passwordless adoption curve (or just starting to consider a change), we offer a modern Passwords product that enhances the security and UX of your current password-based flow. Among other innovations, our API scans the web for breached credentials and bakes smooth, passwordless Email Magic Links into the password reset template.

If you are ready to try passwordless, there are many passwordless solutions on the market. Each comes with its own distinguishing features, and identifying which method is right for your app often depends on your specific industry, audience, and target user experience.

Below, we explore some of the ways you can position a passwordless method within your flow — and which methods would be a good fit — to help you determine the best path forward.



Passwordless as a parallel option

In some cases, you may want to offer several primary authentication options, covering many bases at once and increasing the likelihood users will sign up for and engage with your app.

For instance, you could consider presenting high-converting, passwordless auth methods side-by-side with your current password-based flow:

OAuth (aka Social Logins)

OAuth logins allow users with accounts on platforms like Google and Facebook to sign up for and log in to your app using those existing credentials.

Spotify, for instance, gives users the choice of entering a classic username-and-password combination or using OAuth to sign in through their Facebook, Apple, or Google account.



OAuth offers several UX and security benefits, including:

Leveraging trust and credibility by authenticating users through popular, established platforms they’re already familiar with.

Removing the friction and risk of making users create and recall another set of credentials — or, worse, re-use existing passwords.

Giving users flexibility and control over their authentication experience.

OAuth is a good choice for apps that want to provide maximum flexibility with minimal risk. Make sure to look for account deduplication measures, which top providers like Stytch will build into their solutions to avoid vulnerabilities arising from multiple access points.

It’s worth noting that 70% of our new customers sign up for an account via OAuth versus other available flows, making it one of the highest converting methods we’ve seen.

Email Magic Links

While Email Magic Links work well as a primary auth factor, they’re often used as part of a password-reset flow. That’s because, in many cases, conventional password-based logins already include a user’s email address — so it’s a quick, painless process to send a link they can click to instantly verify their identity and log back in.

For example, companies like Instagram still put passwords first — but they rely on Email Magic Links to remove friction from their critical reset flow.



Of course, by using magic links as a reset measure, you’re embedding a passwordless auth flow into your app — so why not just offer it outright as a parallel primary option?

Some of the advantages of Email Magic Links include:

Higher conversion rates, since all users have to do is click on a link to log in.

Stepped-up security, since the added verification layer prevents cyber attacks from bots and other bad actors.

Smoother reset flows, since users don’t have to come up with (and remember) yet another convoluted password to re-engage with your app.

Magic links are a good option for apps with high email penetration among their user base. Stytch even offers Embeddable Magic Links that weave the authentication process seamlessly into your marketing campaigns and other customer communications, boosting conversion and engagement rates even further.

One-Time Passcodes

Like Email Magic Links, One-Time Passcodes (OTPs) can be used as a primary auth factor or as part of an MFA flow. Users are sent a unique passcode via SMS, email, or WhatsApp, which they then enter in-app to access their account.

ESPN, for instance, uses an email-based OTP flow as part of its password-reset process:



Passcodes share many of the benefits of Email Magic Links — and, for mobile apps, they may even be faster, since they make use of a device users already have in their hands.

Now, iOS and Android phones also have auto-fill capabilities for incoming passcodes, so users can onboard and log in with a single tap (and without ever leaving your platform).

Passwordless as a secondary factor

Including a passwordless solution as a secondary factor (2FA) means you can keep your current password-based approach as is. Adding a step to your initial login flow — or later in your user access journey to protect higher-risk actions — just means you offer an added layer of security.

In addition to those listed above and below, there are several passwordless methods you can use as a secondary or supplementary factor, including:

Time-based one-time passcodes (TOTP)

TOTP works well as a two-factor auth option in circumstances where you need added reassurance of ironclad security — like moving large volumes of money or handling personal payroll records.

It requires users to establish they’re holding a particular device, generating a passcode that’s based on the current time, as well as a shared secret between the server and an authenticator app like Google Authenticator.

That means TOTP allows you to:

Avoid common phishing attacks by removing users’ phone numbers from the equation, using an app on their local device instead.

Limit auth windows to a narrow window of time, usually about 30 seconds.

Authenticate offline, which may be significant for users in areas with poor or limited connectivity (like an airplane) who still need immediate access.

Inserting a secondary, passwordless factor like TOTP into your authentication flow means you can provide extra security — without the extra friction.

Passwordless as a primary factor

Going passwordless-first is as simple as making any of the above passwordless flows your primary (or even your only) authentication measure. In fact, virtually all of the passwordless auth products we offer through Stytch’s platform — including Email Magic Links, SMS and Email Passcodes, and OAuth Logins — can be mobilized as your sole factor.

Forward-thinking companies are also finding ways to innovate on frictionless, biometrics-based methods and make them the only auth solution apps will ever need:

Biometrics

Biometrics are an element of WebAuthn — a cutting-edge web standard that authenticates users through desktop and mobile browsers using built-in biometric scanners (like fingerprint, face, and iris IDs) or specialized hardware keys like YubiKeys.

Historically, biometric data has been stored locally on a mobile device or laptop, making it impossible to access across platforms, relegating it to supplementary-factor status. But now, groundbreaking solutions like Apple’s new passkeys can back up the cryptographic keys that contain biometric data to the cloud — making them interoperable across devices (and viable for primary auth).



Biometrics are considered next-level auth for good reason:

They’re pretty much unhackable, since a user has to prove possession of an original device and a unique biometric trait.

They introduce zero friction, since all a user has to do is touch or look at their device to be verified.

They fit neatly into any part of your auth flow, since they don’t require users to navigate away from your platform or app.

As cross-platform biometrics become increasingly available, our prediction is they will quickly become the gold standard for easy, high-converting authentication.

How will you go passwordless?

There are many creative ways you can add passwordless solutions to your app’s current authentication flow — and we love sharing them. Stay tuned for more content that covers the second half of the adoption curve and demonstrates how you can easily make the switch to fully passwordless auth.

To learn more about the ins and outs of passwordless auth — and find the method that’s right for you — join Stytch’s Slack channel or sign up to get started!

---


# Step-up versus multi-factor authentication (MFA)
Source: https://stytch.com/blog/step-up-auth-vs-mfa/

Learn how businesses strive to protect user data with two primary forms of authentication, step-up and multi-factor, and the differences of each.

Over the past decade, digital transformation has touched every part of our lives. Even companies that have historically provided analog services to users (e.g. shipping) have had to adjust to this digital transformation – that’s because consumers expect to be able to access and act upon information with the digital devices in their pockets and on their desks. On average, users now hold over one hundred online accounts for every type of service that you can imagine. This shift has required virtually all companies to create digital solutions to support their core business functions and store sensitive data such as customer and vendor information. Keeping confidential data secure needs to be a top priority for all organizations, and this is exactly what digital authentication tries to achieve.



Digital authentication verifies identity when accessing sensitive data, applications, or other services. An entity could be a user (a human), an Internet of things device, a process, application, or service. Authentication is the backbone of IT security. Without it, no one could safely use digital technology as we do today.

Various authentication methods protect digital assets and govern access to them. Some are more secure than others, and some require more than one authentication method to achieve their desired security level. This article compares two popular authentication strategies, step-up authentication and multi-factor authentication (MFA), and discusses where each fits best according to an organization’s security needs.

Defining multi-factor authentication (MFA)

As data breaches become common, the need to strengthen current authentication systems that still only use usernames and passwords to protect sensitive resources becomes paramount. According to the Verizon Data Breach Investigations Report, 82% of all breaches involve weak or stolen credentials. Most of these breaches would not have happened if an MFA mechanism had been in place.

MFA (also often called two-factor authentication or 2FA) is a mechanism that requires users to provide two or more authentication factors to verify their identity. There are three major types of authentication factors, and each one requires different authentication methods to satisfy its conditions.

The “something-you-know” authentication factor
This factor is something a user knows, such as a username and a password or the answer to a secret security question. This is the most common form of authentication online today where a user must re-supply some shared secret with the application (e.g. their password) in order to prove themselves.

The “something-you-have” factor
This factor is something the user has possession of, such as a smartphone to receive an SMS message containing a secret code or a hardware security device to generate a one-time passcode (OTP).

The “something-you-are” factor
This factor is something strictly unique about the user, such as a biometrics characteristic. Biometric authentication involves verifying users’ biological or behavioral characteristics, such as voice and facial recognition, fingerprints, or DNA matching.

The benefits and challenges of MFA

MFA provides numerous benefits for organizations:

It increases security by providing additional layers of authentication. If cybercriminals steal a user’s password, they must still give a second authentication factor.

It has become mandatory for many organizations working in high-value industries to comply with the relevant data protection requirements.

An MFA system that uses biometric and passwordless authentication streamlines the authentication process and makes employees and users happier by removing the need to remember traditional passwords.

Despite its benefits, MFA also comes with challenges:

Deploying an MFA system is costly compared with traditional password-only systems, especially in the initiation phase.

Implementing MFA to secure applications, data, and systems in hybrid environments is technically challenging. For example, some applications could be local while others are cloud-based. Implementing the same authentication system across hybrid environments requires continual monitoring and maintenance to remain operational.

Some users find it daunting to use MFA authentication, which makes them abandon the service in favor of the traditional username and password combination.



Defining step-up authentication

As mentioned above, organizations use various digital authentication methods to protect their sensitive assets. Multi-factor authentication describes the process of combining multiple authentication factors to increase the security of users’ accounts. Step-up authentication is a specific type of multi-factor authentication where the application implements an authentication strategy that requires an additional authentication level specifically when trying to perform high-risk operations on an IT system.

For example, customers can use the banking applications installed on their smartphones to view their profiles and check their latest account transactions. Of course, they must log in to their account using, for example, a username and password. However, suppose the customer tries to perform a risky operation, such as transferring a large sum of money to another account. In that case, the banking app requires an additional authentication method. Another method might be providing a one-time passcode (OTP) sent through email or text messaging, an authentication app, or biometrics.

As the previous example shows, step-up authentication requests additional identification information to verify a user’s identity when trying to accomplish sensitive actions. Requesting further information enables IT administrators to use different authentication levels based on the sensitivity of the resources.

You can contrast step-up authentication with another type of MFA called adaptive MFA – step-up authentication is a MFA strategy where particularly sensitive routes in an application require MFA while adaptive MFA is a strategy where only certain types of user characteristics (e.g. a suspicious IP address) require MFA. Both are individually helpful, but they become even more powerful when combined together into a comprehensive authentication strategy.

You can use step-up authentication to secure access to critical resources, such as updating payment information, transferring funds, and changing payment settings in an account to enable withdrawing funds to other accounts. You can also use the adaptive MFA scheme to verify users’ identities when:

They fail to log into their account several times — for example, by providing an incorrect username and password.

They access an online service from an unusual location, such as a foreign country, for the first time.



Step-up versus multi-factor authentication

In general, most authentication systems to date still use usernames and passwords as the first authentication factor. However, many organizations have strengthened their authentication systems by adding additional authentication factors like possession or biometrics. For instance, if the traditional password is the first authentication factor, the second one could be the following:

Hardware tokens that mimic USB dongles and generate a temporary code.

Software tokens generated by programs on computers or smartphones.

Magic links sent by the system to email addresses enabling users to log in by clicking the link. See the screen capture below for a sample magic link sent using Slack:



OTPs sent to a user’s registered mobile phone number by SMS that contain a temporary passcode.

Push notifications sent using an authentication application installed on users’ smartphones. An example of such an application is Microsoft Authenticator.

Biometric authentication using unique biological traits for verification, such as voice recognition, facial recognition, retina and iris recognition, fingerprint scanning, hand geometry, and vein recognition.

You can use step-up authentication with MFA to add additional layers of authentication when accessing critical resources. The system authenticates users with MFA. However, when they want to perform risky operations, the system requests additional authentication using a different factor to confirm their real identity. In this context, step-up authentication is a system that uses MFA techniques to provide a sequence of authentication chains when users want to access critical resources.

Organizations often use step-up authentication to follow their security policies and compliance requirements. This allows them to strengthen the security of their system while allowing the right amount of friction based on the different security needs of other parts of the application. It’s worth noting that route-based authentication and just-in-time authentication are other terms used synonymously with step-up authentication.

Managing the burden of MFA systems and incorporating the step-up approach within them requires investing in a solution that can handle this process. Stytch provides a rich authentication solution that uses a suite of authentication factors. We believe the best approach to MFA is to introduce friction when needed, using incremental security for higher-risk actions within an app. This approach allows you to restrict specific actions within an app that require higher security and allow lower security, read-only actions to occur easily.

In terms of the effort required to implement step-up versus MFA, any system that uses MFA can use step-up without much additional effort. As previously mentioned, you can consider step-up a subtype of MFA in terms of using different authentication factors when trying to access sensitive resources.

Authentication in practice

High-risk industries, such as finance, health care, e-commerce, and government, should use MFA to secure their digital assets. However, they should also deploy step-up authentication to protect access to the most critical areas within their IT systems. For example, in the health care sector, patients could use MFA authentication, such as a traditional password and an OTP sent by SMS, to access their medical profile held by a health institution. However, when a patient wants to access the area containing information about their diseases, medical treatment, or the type of medicine they take, they must submit an additional authentication factor, which is where step-up authentication can be used.

In finance, most people already use two-factor authentication (considered a type of MFA) when withdrawing funds from ATMs. For example, customers must provide their credit card and a memorized PIN code when withdrawing money from an ATM.

Developing MFA authentication that includes step-up authentication is a challenging task that most organizations can’t achieve alone. Stytch provides an authentication platform that handles the entire auth process for customers. It includes the following key features:

Magic Links to send password-free links for registration and login.

One-time passcode sent by SMS to registered mobile phone numbers.

One-time passcode sent to registered email addresses.

One-time passcode sent by WhatsApp, allowing users to sign in from any place worldwide.

OAuth 2.0 and OpenID to provide a low-friction authentication option.

Support for just-in-time authentication that allows for selecting the level of authentication based on the sensitivity of the accessed resources.

Support for built-in biometrics authentication and hardware token authentication.

Ability for crypto wallets to register and log in to any web2 or web3 app or service

Various additional security measures, such as breach detection for password authentication.

Bot prevention technologies.

Traditional password-only authentication systems are insufficient to stop the ever-growing number of data breaches. Deploying an MFA system has become necessary to protect the most sensitive digital assets. Step-up authentication adds extra security for logged-in users attempting to access sensitive information.

Despite numerous cyberattacks, organizations may still find it challenging to deploy modern authentication systems that use step-up authentication and MFA because of the technical complexity of developing and maintaining such solutions. Stytch provides a comprehensive authentication solution that includes today's most popular authentication factors to provide frictionless authentication solutions for both MFA and step-up approaches.

Talk to an auth expert to learn more about the authentication options that Stytch offers.

---


# Multi-factor authentication: how to choose the right approach for your business
Source: https://stytch.com/blog/which-mfa-is-right-for-your-business/

Understand what multi-factor authentication is, how it enhances the security of your users’ accounts and which MFA is right for your business.

Multi-factor authentication (MFA) is a key tool for companies looking to elevate users’ account security, helping to mitigate credential stuffing attacks and prevent account takeover fraud. Sometimes used interchangeably with the term two-factor authentication (or 2FA), MFA involves a layered approach to confirming a user’s identity to ensure they have permission to access a protected digital system (e.g. a website, application, network, etc.) or perform a specific protected task within that system.

As its name suggests, MFA requires users to successfully present two or more identity credentials, called authentication factors, in order to gain clearance. Implementing MFA is now a critical step for any company serious about their Customer Identity and Access Management (CIAM) program.

MFA often (but not always) occurs at initial login. Sometimes, however, the authentication factor prompts are dispersed throughout a user’s digital experience, only requiring 2FA when the user attempts to take a particularly sensitive action such as change their payment details. This latter implementation, where authentication friction is only introduced at the appropriate time in the user’s session, is referred to as “just-in-time” or step-up authentication. Finally, there’s also a type of step-up authentication called “adaptive MFA”, which requires users to go through a MFA step when a specific behavioral change on the account suggests a higher risk of account takeover (for instance, if it’s a new device or a suspicious IP address).

Typically, the user's credentials – whether a password, username, or some other type of secret key – will serve as the "something you know" factor, while a second factor of authentication that is unique to that individual, such as a fingerprint, retina scan, or one-time passcode generated by an authentication app, will serve as the "something you have" factor. The combined use of these two factors makes it much more difficult for an unauthorized user to gain access to an account, as they would need to have both the user's credentials and the second factor of authentication.

There are a number of different ways to implement MFA, and the specific method(s) used will depend on the type of system being accessed and the level of security required. For example, systems that require a high level of security, such as financial or healthcare applications, may use MFA that combines multiple factors, such as something you know, something you have, and something you are. In this case, the "something you are" factor would typically be a biometric, such as a fingerprint or iris scan.

The growing importance of secure multi-factor authentication

Today, supporting multi-factor authentication is necessary for most applications that safeguard even remotely sensitive data due to the prevalence of credential stuffing and account takeover attacks. Account takeover risk stems from the greatest weakness in online security: the human element. A Verizon Data Breach Report found that 82% of all data breaches can be traced back to the human element involved in online security – specifically, the weak and inadequate passwords that users often re-use across multiple sites.

Weak passwords have introduced two major security threats that nearly every application finds themselves playing whack-a-mole to prevent: 1) credential stuffing attacks and 2) account takeover. Credential stuffing involves fraudsters trying to validate whether a username or email and password pair are valid for a particular site and involves sending significant bot activity to applications’ login forms. 

Account takeover is an attack vector where hackers execute the final step to actually take control over online accounts that belong to another user. Account takeover attacks typically have a financial motive where the attackers intend to use the stolen account to defraud the user directly (e.g. draining funds from a bank account) or the business (e.g. making an e-commerce purchase that the business will ultimately need to refund to the original user).

One method for reducing account takeover risk is to require users to create passwords on your site that haven’t previously been exposed in a data breach (this is made possible by built-in breach detection in Stytch’s Passwords product), but another popular way to protect user accounts involves layering on additional security with multi-factor authentication. Fortunately, there are numerous secure options to choose from that can help you eliminate the vast majority of account takeover risk in your application.

When deciding to integrate MFA into your application, there are a few questions to ask yourself:

Will you make MFA optional or require it for all users?

Will you offer multiple MFA options so that users can choose what best fits their needs? How many and which options will you provide?

Will you layer on?



What MFA is right for you?

While you can theoretically use any authentication method for two-factor authentication, there are strengths and weaknesses associated with each one.



Unless you require it for your application, it can be difficult to convince users to enroll in two-factor authentication after they’ve already created an account. While there are versions of multi-factor authentication (e.g. Yubikeys and biometrics) that are more secure than common methods like phone number verification, our recommendation is to pursue a MFA strategy that allows you to enroll the highest percentage possible of your user base. This typically entails offering multiple options to users when enrolling in MFA.

Balancing security and user friction: step-up authentication

Organizations use various digital authentication methods to protect their sensitive assets. Multi-factor authentication describes the process of combining multiple authentication factors to increase the security of users’ accounts. Step-up authentication is a specific type of multi-factor authentication where the application implements an authentication strategy that requires an additional authentication level specifically when trying to perform high-risk operations on an IT system. 

For example, customers can use the banking applications installed on their smartphones to view their profiles and check their latest account transactions. Of course, they must log in to their account using, for example, a username and password. However, suppose the customer tries to perform a risky operation, such as transferring a large sum of money to another account. In that case, the banking app requires an additional authentication method. Another method might be providing a one-time password (OTP) sent through email or text messaging, an authentication app, or biometrics.

As the previous example shows, step-up authentication requests additional identification information to verify a user’s identity when trying to accomplish sensitive actions. Requesting further information enables IT administrators to use different authentication levels based on the sensitivity of the resources.

You can contrast step-up authentication with another type of MFA called adaptive MFA – step-up authentication is a MFA strategy where particularly sensitive routes in an application require MFA while adaptive MFA is a strategy where only certain types of user characteristics (e.g. a suspicious IP address) require MFA. Both are individually helpful, but they become even more powerful when combined together into a comprehensive authentication strategy.

You can use step-up authentication to secure access to critical resources, such as updating payment information, transferring funds, and changing payment settings in an account to enable withdrawing funds to other accounts. You can also use the adaptive MFA scheme to verify users’ identities when:

They fail to log into their account several times — for example, by providing an incorrect username and password.

They access an online service from an unusual location, such as a foreign country, for the first time.

Removing the hassle of MFA with Stytch

Stytch offers a suite of different MFA options that are easy to integrate, so that you can provide the right level of optionality to your user base. From SMS to TOTP to biometrics and hardware keys, we offer every conceivable 2FA option that you and your users could need. Additionally, we make it easy to minimize MFA friction by only introducing these requirements when a user is accessing sensitive information (step-up auth) or when suspicious behavior is detected (adaptive MFA).

To get started, you can sign up for Stytch or request to talk to an expert to chat through your organizations’ specific needs.

---


# Eliminate bot attacks from the CAPTCHA equation
Source: https://stytch.com/blog/protect-against-captcha-fraud/

Understand how CAPTCHA fraud works and how you can protect against it with Stytch’s stronger CAPTCHA solutions.

Today, humans only make up 38.5% of internet traffic. The other 61.5% is non-human (bots, hacking tools, etc). When you consider how pervasive non-human traffic is on the web and the potential threat this bot activity can pose to companies (brute forcing users’ passwords to steal their accounts, executing scripts to buy out concert tickets in order to profit on the secondary market, etc.), it’s not surprising that we’re often asked as users to prove our personhood when browsing the web. This incessant bot activity defrauds both users and businesses – when a user’s bank account is stolen, it’s typically the victim of a bot-powered credential stuffing attack. And all of this non-human traffic leads to both fraud losses for companies in addition to the increased compute costs it generates.

To combat this bot traffic over the past two decades, companies have been relying on the use of CAPTCHAs to distinguish between humans and bots. CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart. Most people are familiar with the nature of these tests — having to pick things like buses and crosswalks out of a lineup of images — but they pose a problem for most bots. The narrowly-defined nature of the tasks that bots perform prevents them from being able to interpret images or replicate the human responses that CAPTCHAs are based on. And while a bot could be developed with these capabilities, it would be both incredibly time-consuming and expensive. Furthermore, a solved CAPTCHA cannot be reused. So, even if a bot does correctly decipher one, it must repeat the process thousands of times, which negatively impacts the speed that makes credential stuffing so viable.

So, if we’re constantly bombarded with tests asking us to prove that we’re not bots, why are bot-based attacks (stolen accounts, spam, scalped tickets, etc.) still such familiar issues on the web? The answer is CAPTCHA fraud, a cottage industry in which humans play the role of Mechanical Turks to power the bot ecosystem.

Understanding CAPTCHA fraud

Bots’ ability to consistently trick CAPTCHA stems from a key design flaw in the architecture –– the public key problem. Every major CAPTCHA system exposes its public key, making it easy for bots to scrape and submit the public key to a ‘CAPTCHA-solving-as-a-service’ company. At CAPTCHA-solving companies, commonly referred to as CAPTCHA farms, people manually solve CAPTCHA tests for bots for a living. As mentioned, this involves a Mechanical Turk approach that utilizes low-cost labor to solve the challenges remotely and send the solved CAPTCHA back to the owner of the bot program. This is only possible because CAPTCHA does not require the solver of the challenge to be in the same browser used to submit the challenge’s solution.



If you google how to beat CAPTCHA challenges, you’ll find that dozens of companies fall into this cottage industry of CAPTCHA fraud. You’ll find many sites like https://anti-captcha.com/. And its website has many of the hallmarks of any good SaaS company!

1. A compelling landing page and detailed value proposition.



This is the landing page of one of the largest CAPTCHA solving services. Its website highlights why you should choose it over competitors: it’s cheap and reliable.

2. A detailed overview on how the service works.



The steps are made clear to the customer. A bot uploads the CAPTCHA to the website, it's solved by a worker, and sent back in an average of 11.3 seconds.

3. An up-to-date status page on how they’re performing and the pricing for their different products.



This is a snapshot of a live feed on a CAPTCHA farm website – it details what types and how many CAPTCHAs are being solved per minute and the price per type of CAPTCHA. CAPTCHA farms are in a position to solve every type of CAPTCHA at a mass scale.



4. A final demonstration of their expertise to drive it home.



The simple nature of the task is clear. All a bot has to do is scrape the public key and the CAPTCHA farm will do the rest.



5. Support for 15+ payment methods (necessary for such a global product)!



These services take a wide variety of payments. The economics make sense for attackers, it is really cheap (and easy to pay) to solve CAPTCHAs.



Protect against CAPTCHA fraud with Stytch

CAPTCHA solving services help bots dominate the internet today and impose real friction and cost on both users and business in the form of fraud, wasted resources and time. The exposed public key architecture has created scalable attack vectors for bots and the best solution for protecting against them is to remove this loophole altogether. With our Strong CAPTCHA solution, we've done exactly that.



As an example of the lengths companies need to go to today in order to counter this weakness in the existing CAPTCHA ecosystem, certain companies like Binance are forced to build their own custom version of CAPTCHA to reduce the risk of being aggregated by a CAPTCHA farm.

At Stytch, we’re on a mission to eliminate unnecessary friction on the internet, and today, CAPTCHA fraud is one of the greatest offenders. We’re excited about new methods for stopping bots without putting undue friction on good users. If you’re interested in learning more, check out our Strong CAPTCHA product page, or talk to an auth expert to learn more about how Stytch can help you stop bots on your application.

---


# The definitive guide to choosing a Customer and Identity Access Management (CIAM) solution
Source: https://stytch.com/blog/guide-to-choosing-ciam/

When it comes to customer identity and access management (CIAM), there are a lot of decisions to make. Learn how to think about building or buying a CIAM solution that best fits your business needs.

When it comes to customer identity and access management (CIAM), there are a lot of decisions to make. What features do you need? How will you integrate the solution into your existing infrastructure? Do you want to build or buy a CIAM platform?

These are all important questions, but they can be difficult to answer without first understanding the landscape of CIAM. In this blog post, we’ll introduce CIAM and provide a guide for your business on how to think about building or buying a CIAM solution that best fits your needs.

What is Customer Identity and Access Management (CIAM)?

Customer Identity and Access Management (CIAM) is a system that manages the identities of a company's customers and provides them with access to the company's digital resources. It includes features such as customer registration, login, password management, and single sign-on. CIAM also provides a way for companies to collect and manage customer data.

Every application that needs to authenticate their customers must build or buy a CIAM system to manage their users. You can build a CIAM system in-house, but it's recommended to use a trusted provider due to the added risk and cost of rolling your own system. If you’re looking to buy a CIAM solution, there are a number of companies that offer CIAM services, including Stytch, Auth0, Okta, Ping Identity, and OneLogin.

The build vs. buy decision

To solve for your company's CIAM needs, there are two main approaches: build or buy. There are pros and cons to each approach, and the decision ultimately comes down to your specific situation.

Building a CIAM solution from scratch can be a daunting task. Not only do you need to have the right team in place to develop the solution, but you also need to have the necessary budget and resources. Additionally, it can be difficult to keep up with the rapidly changing trends in CIAM if you're not dedicating a team specifically to this area.

Outsourcing CIAM to a third-party authentication provider (like Stytch) can be a more cost-effective and time-efficient solution. With a reliable platform for CIAM, businesses can quickly and securely get all of their authentication needs handled out-of-the-box.

When considering whether to build or buy a CIAM solution, there are a few key considerations to keep in mind:

The size of your company: If you're a small or mid-sized company, it may not make sense to invest the time and resources into building a CIAM solution from scratch. In this case, outsourcing CIAM to a third-party provider like Stytch can be a more efficient solution.

Your company's core competencies: Does your company have the necessary expertise to build a CIAM solution? If not, it may be more beneficial to outsource this function to a company that specializes in authentication.

The cost: Building a CIAM solution from scratch can be a costly endeavor. Not only do you need to invest in the development of the solution, but you also need to factor in the cost of maintaining and upgrading the solution over time. Outsourcing CIAM to a third-party provider can help reduce these costs.

Complexity of authentication needs: Some of the more complex authentication solutions include multi-factor authentication (MFA) and single sign-on (SSO). Both MFA and SSO are important security measures that businesses should consider when implementing a CIAM solution. However, these solutions require a much heavier lift than simply building passwords. If your company is not familiar with or does not have the resources to implement MFA or SSO, it may be more beneficial to outsource this function to a company that specializes in authentication.

When considering the build versus buy decision for CIAM, we sometimes hear a hesitancy to outsource authentication to a third-party provider given the critical nature of sign-up and login plays for all applications. One thing that many tend to overlook is that, as your authentication needs grow more complex, you'll inevitably outsource at least some portion of your auth stack.

For instance, whether you're building support for email verification (e.g. for password resets or sign-up), SMS two-factor authentication, or single sign-on (e.g. OneLogin), every road in your company's authentication journey eventually leads towards outsourcing some portion of your IAM needs to a programmatic email provider, or a programmatic SMS provider, or a SSO provider. Even if you have the in-house expertise to build these authentication capabilities, it's typically more efficient (both in terms of time-to-market and cost) to outsource them.

Thus, when making the build versus buy decision for CIAM, we recommend that companies consider their core competencies, the costs associated with building and maintaining a CIAM solution, and the benefits of outsourcing authentication to a specialized provider. If you have the in-house expertise and the resources to build a comprehensive CIAM solution, then by all means, go for it. However, if you're like most companies, it makes more sense to outsource your CIAM needs to a specialized provider like Stytch.



Purchasing a CIAM solution

Once you've decided whether to build or buy a CIAM solution, the next step is to assess the competition. When evaluating CIAM providers, there are a few key factors to keep in mind:

Ease of use: The platform should be easy to use for developers, administrators, and end users.

Security: The platform should offer robust security features to protect your customer's data. It’s recommended to require the vendor to provide a SOC 2 Type II report showing the controls they operate to keep you and your customers safe.

Integration: The platform should be able to seamlessly integrate with your existing infrastructure.

Support: The provider should offer excellent customer support in case you run into any problems.

Scale: The system should be able to scale to support a large number of users. Considering your CIAM provider protects the front door of your application, you’ll also want to ensure the provider has best-in-class uptime.

Recommended questions to ask potential CIAM providers

When determining which CIAM solution to use, here are some helpful questions to guide your investigation:

How do you scale your system reliably to manage large volumes of users? What’s your track record on uptime?

Can I see your SOC2 Type II compliance report to understand how you secure customer data? Are you compliant with privacy laws like GDPR and CCPA?

How flexible is your offering? Can I access a direct API in my integration for full control of the UX?

Is there vendor lock-in if I choose you? How would I export users if I decide to switch systems?

Are there any hidden fees if I expand my use of different authentication methods (e.g. multi-factor authentication) over time?

Consider using Stytch for your CIAM needs

Stytch is a customer and identity access management platform that provides a single, unified view of customer identity and activity across all channels and devices. It enables organizations to quickly and securely authenticate customers, authorize access to applications and data, and track and manage customer activity. With our simple API and flexible SDKs, you get secure and high-converting authentication out-of-the-box but retain the ability to own the UX of your application. One of the key advantages of Stytch is its simplicity. Our platform is easy to use for both administrators and end users and offers a comprehensive product suite that includes MFA and SSO capabilities.

---


# Making auth your growth lever
Source: https://stytch.com/blog/making-auth-your-growth-lever/

Making auth your growth lever

If you’re spending time figuring out why it’s costing you more to acquire new users, or why user retention rates aren’t where you’d like them to be, consider tackling your sign-up and login flows. It’s more than just a way to securely let in a user - the sign-up and login experiences can, in fact, be delightfully seamless for users, serving to both let your product stand out and increase your overall conversion and retention rates.

It’s not a surprise to most that customer acquisition cost (CAC) has been going up across the board for some time now, whether it’s due to increasingly ad-weary users or major changes like Apple’s introduction of App Tracking Transparency on iOS. This makes it all the more important that you convert as many visitors as possible to keep CAC low - after all, you’ve already spent significant resources on growing your top-of-funnel through things like content, organic search, and paid ads, the worst that could happen is for it to all be in vain when a user drops off upon encountering a cumbersome sign-up flow. Below, we discuss ways to make your customer authentication experiences a core growth lever to increase immediate top-line revenue and improve the lifetime value (LTV) of your users.



Even prior to Apple’s new App Tracking changes, CAC had risen sharply (~70%) in the previous 6 years. Most forecast another sharp increase with Apple’s new policy. (Source)

Boosting conversion

Authentication isn’t just something that your security team should care about. If you own your product’s growth metrics, auth is critically relevant to you as well. The user experience that you deliver to customers at sign-up and login directly impacts key business metrics, including top-line revenue, # of net new customers, CAC, and user retention figures like LTV.

To help illustrate this more concretely, consider the fact that typical website bounce rates average around 41 to 55%, meaning these potential new users and customers are abandoning your site without ever interacting, let alone signing up. Anything you can do at the margins to recover bounced users can be meaningful.

Let’s assume your website has 1M monthly visitors, 30% of whom are eligible new users, and you have a bounce rate of 50%. You can quickly see that recovering even just a small portion of bounced users can add up to material monetary impact.



Many innovative companies are already waking up to this and have endeavored to reduce friction as much as possible. Consider Slack, Cash App, or Monzo, who have all adopted passwordless flows through auth methods like email magic links and SMS passcodes. Or consider Pinterest, Zapier, and Doordash, who have all adopted Google One Tap to enable what is effectively one-click signup.

These companies have homed in on a few key principles around boosting signup conversion by using auth as a lever:

1. Optimizing the homepage. A common theme across these apps is a singular focus on nudging new visitors toward account creation. Consider how Monzo aims to make their call-to-action clear (front and center) and frictionless (on mobile, the CTA is deeplinked to the App Store, whereas on desktop a QR code allows the user to jump devices with minimal effort).



Monzo login with QR codes

And consider how Cash App removes all distractions and allows the user to focus on a single field and call-to-action (no password required).



CashApp login screen – no distractions, no notes!

2. Organically nudging visitors to sign up. These apps have also realized that there’s no better way to demonstrate your value prop than to get your user in the product ASAP, so they continue to nudge new visitors toward signup throughout their site. For example, Pinterest and Doordash leverage Google One Tap to ensure visitors are always one click away from signup wherever they are.





Note the sticky login modal for both Pinterest and DoorDash

Boosting retention

As much as customer identity and access management (CIAM) is about getting users in the door, it’s also critical to keep users returning and engaged to fully realize their potential LTV. Many of us are likely familiar with the experience of pulling up an app we’d downloaded weeks ago, only to have to go through an arduous password reset process just to get back into our account - many users give up halfway through this byzantine process and abandon the app completely.

With thoughtful tooling around how you build auth, you can make it as easy as possible for your users to return and re-engage with your product.



1. Take advantage of password resets. Users don’t actually want to reset their password - they just want to get back in. This is a perfect opportunity to offer a passwordless option and ensure they never encounter a forgotten password again. For example, The Washington Post provides an “Email a sign in link” option:



Alternatively, you could provide a passwordless option in the password reset flow itself:



2. Embed auth into CTAs. Imagine receiving an email from your favorite brand about an on-sale item you’ve had your eye on - you click through, ready to buy, but are prompted with a login screen instead. Companies frequently leave money on the table by throwing up these types of barriers, which you could easily avoid by embedding auth into the hyperlink itself. The user has already proven access to their email or phone, so you can quickly drop them into a logged-in state without disrupting the flow.



3. Use step up authentication to layer on extra security only when it’s needed. Lastly, it’s important to remember that not all authentication is created equal. Many apps (banking in particular) require multi-factor authentication each and every time a user opens their app, but often this is a heavy-handed experience built in the name of security at the expense of user experience. Instead, consider only stepping up users to a second factor when their action warrants it (e.g., making a financial transaction, updating personal information, etc.). This type of “just-in-time” auth ensures you only introduce friction as needed, rather than subjecting your entire user base to unnecessary re-engagement barriers.

How will you boost growth?

Customer identity and access management is often overlooked as something that can be optimized for growth, but some of the most innovative companies out there are already leading the way by ensuring their authentication experiences are finely tuned for maximum conversion and retention.

Here at Stytch, we have a front-row seat to how companies are modernizing their auth flows, and we’d love to chat with you about how you can as well. Feel free to reach out to us to book a quick UX consultation - we’re excited to review your UX and offer our tips and best practices around where you can optimize for continued growth.

---


# What is TOTP and why does it matter?
Source: https://stytch.com/blog/what-is-totp/

TOTP stands for time-based one-time passcodes. Learn about why it’s an important two-factor authentication option to uplevel your app’s security.

Time-based one-time passcodes (TOTP) are a type of multi-factor authentication (MFA) that leverages software authenticator apps (e.g. Google Authenticator, Authy, Microsoft Authenticator) to verify your identity. These authenticator apps supply a randomly generated code that changes every 30 seconds.

Time-based One-time Passcodes are generated using a shared secret (a random string of characters) and the current time.

The TOTP algorithm uses that shared secret to generate a 6-digit time-based code that expires every 30 seconds. The shared secret is used to generate the code on the user’s device as well as stored securely on the server. When a user needs to authenticate to an application, the user enters their code from their device and the server validates the code against its stored secret. If the code matches, the user is authenticated.

When you want to log into a site or service that uses TOTP, you complete your first method of authentication (e.g. password, sign in with Google, magic links, etc.) as usual. Then, you open your authenticator app and enter the code that is displayed. This proves that you have possession of your device and gives the application strong evidence that you are who you say you are.

SMS OTP vs. TOTP: What problems does TOTP solve?

While SMS one-time passcodes (OTPs) are the most common form of multi-factor authentication today, TOTP (time-based one-time passcodes) are an important two-factor authentication option that can be used in situations where you need higher security assurance than SMS verification can provide.

SMS OTP is familiar and convenient for users, but there are certain security weaknesses. SMS OTP is more vulnerable to SIM swapping attacks, where a fraudster who has stolen a user's phone number can route messages to their own device and intercept the code. TOTP is not vulnerable to this type of attack, as the authenticator app is tied to the user’s device rather than their phone number.

SIM swapping attacks are relatively rare (compared to other account attacks like credential stuffing) due to the effort and cost involved in executing it successfully – it typically involves either bribing employees at a telecommunication company or fabricating identity documents to impersonate the true owner of the phone number at a live branch.

TOTP authentication solutions are ideal for particularly sensitive use cases that are also highly attractive to attackers in terms of the potential payoff they offer – think money movement in fintech or cryptocurrency spaces or access to a company’s HR or payroll information. But even if a company’s use case isn’t particularly sensitive, TOTP can be a good option for organizations that prefer a higher assurance level for their MFA and 2FA. Many tech-savvy users also prefer TOTP over SMS OTP for MFA for important accounts due the heightened security.



Offering flexible and secure MFA options with Stytch

Ultimately, the best type of security is security that users will actually use, which is why it's important to offer multiple MFA options to increase the likelihood that a user enrolls in MFA.

There are many different MFA options you can offer users with SMS, TOTP, biometrics, and hardware keys being the most popular ones. Each of these methods has its own advantages and disadvantages, which is another reason it's important to offer multiple forms of MFA to your users. You can read more about these individual authentication options in our guide to passwordless authentication.

With Stytch, developers can embed MFA, including TOTP, into their authentication flows in minutes rather than months.Stytch's TOTP solution is designed to be used with any mobile authenticator app such as Google Authenticator, Microsoft Authenticator, or Authy. Check out our TOTP integration guide to get started.

---


# How compromised passwords lead to data breaches
Source: https://stytch.com/blog/how-compromised-passwords-lead-to-data-breaches/

Compromised passwords can lead to data breaches and hackers accessing personal information. Here are solutions to create strong passwords and authenticate users.

Data breaches have been in the headlines for several years, representing a rational fear for many organizations. A data breach is when someone — typically a hacker — gains unauthorized access to sensitive or confidential information. Hackers may do this for numerous reasons, including damaging the organization or its reputation, selling the retrieved data, or making a social or political statement.

Most data breaches seek personally identifiable information (PII), such as Social Security numbers or other official identity information, bank or credit card details, and passwords that they can use to either monetize the attack directly or indirectly by compromising adjacent financial accounts that rely on those stolen credentials.

Additionally, there are two significant aspects that most breaches share:

Often, organizations only detect them months after they’ve occurred.

Compromised passwords are the primary cause.

In this post, we’ll examine how easily compromised passwords can lead to data breaches, go over some common password vulnerabilities, and ultimately review some best practices to keep your passwords and other sensitive data as secure as possible.

Data breaches from compromised passwords

Compromised passwords are a top contributor to many recent large-scale breaches. This is unsurprising, as a password is often all it takes to authenticate into a system, application, or data store. Once a user authenticates successfully, there is little recourse.

That’s not to discount recent cybersecurity advancements that seek to improve how we protect electronic data. Traditional data center security includes some key security architecture, including network connectivity firewalls, virtual private network (VPN) connections, and encrypted tunnels for remote access. However, weak user authentication renders these measures all but useless.

As such, password-based authentication methodologies become a prime target for hackers.

How often are passwords compromised?

So, how often do passwords become compromised? In brief, all the time. Below are just a few of the more well-known breaches whose common thread is a known password:

The 2021 TicketMaster breach is a remarkable example of how substandard practices (and illegal behavior) can breach corporate security. An employee who saved credentials from their former employer — a competitor — provided access to TicketMaster executives with these credentials, enabling them to retrieve confidential financial and operational information from the rival company.

The root cause of the 2021 SolarWinds breach was a weak password on their prime software tooling: solarwinds123.

The New York City Law Enforcement Department was also a data breach victim. Attackers stole personal data from thousands of employees. This was possible after attackers stole one employee’s email account credentials.

The above examples represent only a few of the more well-known security breaches, but there are countless undetected or unreported security incidents for each known occurrence.

How do passwords become compromised?

There are many ways that bad actors can steal passwords. Moreover, they often use multiple strategies simultaneously.

Brute force

Brute force is the technique by which an attacker uses a “guessing” approach to determine a password for a system or user account. Cybercriminals often use robust scanning or password-cracking tools that enable looping through many possible password combinations. These tools address the common tendency to include birthdays, family members’ names, and pets’ names in created passwords.

Social engineering

The more a hacker can find out about their target, the greater the amount of helpful information there is to attempt to gain access. Consider the security questions you must answer when setting up a new account. Usually, answering these questions can help prove your identity to reset a lost or forgotten password. Most questions relate to your likes or hobbies (favorite car brands, travel destinations, visited cities) and family or pet names.

The “silly” games we play on social media are a way to obtain such data. Even games that don’t directly ask for this type of information understand what types of prompts will most efficiently garner responses.

In addition to falling victim to social media schemes, people tend to reuse passwords in multiple apps and accounts. This means that if one site’s credentials leak, malicious actors can use the same credentials to access several accounts belonging to each individual.

Password theft

Password theft is an umbrella term that takes many forms, including some of the previously mentioned scenarios. Complex passwords are more secure but challenging to remember but saving them in a sticky note or plain text file opens the possibility of password theft.

Another common type of password theft occurs through spam and junk phishing emails, which involves deceiving users into clicking a link that leads to a phony but often realistic-looking version of a legitimate website. The fake website is typically just a form to capture the user’s credentials when they believe they are logging in to the site or resetting their passwords.



How to prevent compromised passwords

Fortunately, there are plenty of ways to reduce the risks associated with compromised passwords.

Strengthening passwords with hashing and salting

In an ideal scenario, the password characters that a user enters are hashed and stored in a back-end identity database. Hashing encrypts a password into a string with a method that is extremely difficult to reverse engineer. The more complex the hashing mechanism (SHA, bcrypt), the harder it will be to break the code.

While this method is relatively secure, the encryption key used to hash passwords is static. This creates a vulnerability wherein deciphering the encryption key enables an attacker to decrypt any stored password. That’s where salting is useful. This process involves adding a series of randomly chosen characters to the password before hashing. This optimizes the security for the given credentials, as the hash will never be the same.

Delete inactive accounts

Moreover, it’s crucial to ensure you disable or delete inactive accounts. Leftover credentials are vulnerable targets for disgruntled employees or those with whom they may overshare. These unused accounts include employees who’ve left the organization but may also extend to those on temporary leave.

Additionally, integrating up-to-date security controls, such as validating security group memberships and ascribing to the principle of least privilege (PoLP), can significantly limit unauthorized access.

Use multi-factor authentication

Multi-factor authentication (MFA) dramatically improves the integrity of password-only logins. Whereas traditional authentication combines a username and password, MFA relies on an additional method to prove your identity. The desired combination includes factors based on:

Something you have (a mobile phone)

Something you know (a password)

Something you are (biometrics)

When you connect to an application (using a browser or a mobile app), using a powerful authentication solution typically follows this flow:

You are initially prompted for a username and password.

You then must validate using one or more factors, such as a one-time passcode (OTP) sent to your mobile phone or a fingerprint reader (or similar biometric method).

If any of the authentication steps are unsuccessful (for example, you cannot receive or read the one-time password, authentication will be unsuccessful until you can provide additional verification.

Prevent credential stuffing attacks

When a user’s account is stolen, it’s often the victim of a bot-powered credential stuffing attack. CAPTCHA challenges can be used to help combat bot traffic and attacks.

CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart. Most people are familiar with the simple nature of these tests, but they pose a problem for most bots to solve.

In recent years, however, bots have become more adept at beating CAPTCHA tests in order to validate credentials and compromise accounts. Bots’ ability to consistently trick CAPTCHA stems from a key design flaw in the architecture –– the public key problem. Every major CAPTCHA system exposes its public key, making it easy for bots to scrape and submit the public key to one of these ‘CAPTCHA-solving-as-a-service’ companies.

Stytch has developed a CAPTCHA solution that removes the public site key from the equation, leaving users with the exact same experience, but making it impossible for bots to scrape and mass attack your application. Visit our Strong CAPTCHA product page or talk to an auth expert to learn more about how Stytch can help you stop bots on your application.

Stytch’s password solution

Stytch recently launched a completely rebooted Passwords solution that innovates from the ground up to uplevel security and user experience and protect against data breach.

Stytch’s Passwords solution also introduces novel security features like breach detection (powered by tools like HaveIBeenPwned) and a better strength assessment called zxcvbn (aka “lower qwerty”), which makes it easy for humans to generate passwords but hard for robots to crack them. We’re committed to making secure authentication that’s as frictionless as possible, so we leverage our Email Magic Link technology to reduce the steps from a traditional password reset.

Stytch also salts and hashes all passwords using Scrypt, before storing in an encrypted database that we manage. We wanted to ensure our Passwords solution is secure and built for performance — we decided on Scrypt in order to strike that balance.

Passwordless: the ultimate protection

Stytch offers a variety of solutions to ensure that password-dependent credentials are optimally secure. However, the ideal strategy for reining in password-related breaches is to remove passwords from the equation. Stytch’s passwordless approach is the ultimate weapon against compromised passwords, ensuring that your confidential information stays that way.

Stytch’s modular solution suite means that you can construct a passwordless approach best tailored to your product and your industry. For example, industries with stringent privacy standards such as Fintech and healthcare often benefit the most from enforcing OTPs as the primary mode of authentication and biometric validation or TOTP authenticator apps as the second factor.

The OTP provides security to the users, validating their identity by sending a message to their phone or email. This creates flexibility for the device type using the app. Biometrics, as the second factor, can be viewed as an additional layer of security, where the mobile app can only be opened and used from a given device.

For B2B saas applications like Slack and Microsoft Teams, it is often best to use a low-friction approach like Email Magic Links or OAuth. The email-based scenario provides an easy, low-friction authentication method, often used for full-desktop applications. Adding OAuth-based capabilities can also allow for single sign-on (SSO) integration with corporate credentials.

Strengthen security with Stytch

Data breaches pose a tremendous risk for any organization, with compromised passwords proving to be a prevalent issue. Luckily, numerous scenarios are available to help optimize the security of your application or system and the integrity of your users’ account credentials. But ultimately, the best way to prevent password theft is to go passwordless. No master hacker can steal what isn’t there.

If you’re interested in learning more about how Stytch can help you maximize your password security or transition to a passwordless approach, discover our full suite of authentication products at Stytch.com.

---


# How we (re)made Passwords for next-generation auth
Source: https://stytch.com/blog/making-of-passwords/

Take a look behind the scenes at Stytch, and discover how we built our new Passwords solution to reduce friction and improve security online.

I joined Stytch this past spring, just as we launched a massive out-of-home campaign with dozens of billboards, buses, and transit shelters proclaiming the benefits of passwordless authentication across San Francisco. (And, to be clear, we still believe passwordless auth offers the best security and user experience for applications today.)

But as I settled into my role, I heard from many customers who were excited about the possibilities of going passwordless but concerned about how their users would handle an abrupt transition — and I wasn’t alone. It turned out Stytch’s leadership had been hearing the same thing for a while. We decided it was a left turn worth exploring.

While our end goal is killing the password, our company mission is to eliminate friction on the internet. We’ve learned that, in some cases, the lowest-friction option may include password-based logins for apps that are just starting on the passwordless adoption curve.



Instead of ignoring the present state, Stytch believes that the best path forward is to meet companies and people where they are and guide them along the adoption curve towards passwordless.



Of course, if we were going to create a password-based flow, we were going to create one that meets all the UX and security needs of modern developers. Below, I share how we came up with an enhanced solution and upgraded the password to fit our forward-looking approach to auth.

Weeding out the friction

As we began building our Passwords product, it helped that we had already spent considerable time thinking (and writing) about the many reasons why conventional passwords are terrible.

One of our main goals was to take a step back and think about the specific ways friction is typically introduced to an auth flow and whether the basic verification measures we take for granted actually serve their intended purpose.

For example, traditional LUDS standards — which ask users to include at least one lower- and upper-case letter, digit, and symbol when generating a new password — assume that complexity is the key to security. In theory, it would take thousands of years to crack a LUDS password using common hacking techniques. But in reality, convoluted passwords are hard to remember and put too much of a burden on users, who end up taking risky steps to manage their proliferating credentials.

Studies show that about 67% of users recycle the same credentials across multiple accounts so they don’t have to store and recall an average of 100 passwords. That can be a real problem given the growing number of breached data dumps and the growing sophistication of cyber attacks.

We knew one way to avoid these pitfalls was to put the user first and optimize for both security and usability, which meant rethinking many of the common components of a password-based flow.



Taking a human-centric approach to passwords

Our biggest challenge was designing a solution that would resemble the password-based logins users are familiar with while addressing critical security and UX issues behind the scenes.

We also wanted to make our product as simple as possible while giving users the flexibility to navigate auth on their terms. That meant building a flow that would work alongside other passwordless methods (like OAuth logins through Google or Facebook) that users could turn to under certain circumstances, like authenticating in a crowded space or via mobile, when they may not want to punch a password into a tiny keyboard.

As always at Stytch, we took a collaborative approach to negotiate the perfect balance between development and design.

As product lead, I worked closely with our engineering team to validate the APIs, test the feasibility of our goals, and minimize complexity. I also brought in our user research team to better understand our customers’ (and end users’) expectations and worked with our design team to set up easy, customizable configurations through Stytch’s dashboard.

Ultimately, we revolutionized the password experience in four important ways:

Strength: instead of imposing rigid LUDS requirements, we use Dropbox’s flexible zxcvbn strength estimator and offer users helpful tips on how to improve their passwords.

Flexibility: we automatically deduplicate accounts by email regardless of how users log in. That means apps can offer different auth options (password-based and passwordless) without allowing users to unintentionally create multiple accounts.

Simplicity: we overhauled the tired password reset flow, so users can create a new password if they want to — or skip the process altogether and just click a button to log in via an Email Magic Link.

Security: we integrated with Have I Been Pwned (HIBP) so we can check a user’s credentials against a database of 623+ pwned websites and nearly 12 billion pwned accounts and ensure they haven’t been compromised.

By thinking through the different ways users might encounter and navigate password-based logins — and the pain points they tend to hit along the way — we created a modern flow that actually works in the seamless way apps intend.



When a user initiates a “forget password?” flow, Stytch offers them the option to skip the reset and simply log in via Email Magic Link OR to reset password and log in.

A holistic approach to auth

Stytch’s Passwords solution can stand on its own, but it’s also well suited as the primary or secondary factor in a multi-factor authentication (MFA) flow or side-by-side with other, passwordless methods.

You can learn more about Passwords by checking out the product page or jumping into the docs. Or, for ideas on how to implement Passwords in tandem with other elements of Stytch’s passwordless product suite, reach out to one of our auth experts for a free consultation.

---


# What is identity and access management (IAM)?
Source: https://stytch.com/blog/identity-and-access-management/

Identity Access Management (IAM) allows organizations to assign identities to people and devices, authorize access to assets, and manage these relationships.

Identity and access management (IAM) is a broad term used to describe how organizations manage individuals and devices and control access to sensitive resources. With IAM, an organization can authenticate digital identities, define which assets they can access, and manage these relationships over time.

In an increasingly online world — with more users, more devices, and more threats — IAM plays a critical role in helping organizations protect their data, promote growth, comply with government regulations, and much more.

What are the benefits of IAM?

IAM is utilized throughout large and small organizations because it offers a wealth of proven benefits for enterprise.

Greater control over users

When unauthorized people have access to confidential and privileged information, an organization is at risk of costly data breaches and identity theft, among other issues. These concerns only grow as workforces remain highly distributed, and operate in fast-paced environments.

The primary purpose of IAM is to control who has access to information and assets, which is especially important if you are dealing with privilege creep (when access privileges expand unnecessarily) or large numbers of users being onboarded and offboarded.

With IAM, you can:

Manage and track nearly every aspect of a user’s identity and permissions.

Quickly and accurately see which users can access any specific asset.

Grant granular permissions to ensure that users only have access to assets that are relevant to their work.

Change privileges across the enterprise as groups and teams evolve and security policies are updated.

Incorporate proven security-related platforms and features such as single sign-on (SSO), which promotes good password hygiene by reducing the need for users to track and manage multiple credentials.

Collaborate more easily and cost-efficiently with third-party contractors, customers, and other outside groups by granting them controlled, secure access to your network.

Cloud-based IAM provides additional benefits, including controlling access with browser-based SSO.

Protect sensitive data, credentials, and other assets

Consider all of the digital threats to your organization, including hacking, phishing, and stolen passwords. These risks are directly related to unauthorized user access. By allowing you to control, manage, and limit user access through a centralized system, IAM helps keep your information safe and mitigates your risks.

An automated approach

Humans make mistakes. Automating the processes that are used for IAM helps minimize (or even eliminate) the human errors typical in manual account setup, permissions, and tracking processes. In addition to improving security, automation saves your IT department time and money by reducing the number of help desk requests for password resets and related tasks.

How does IAM work?

IAM enables access to an asset based on the identity of the user, device, or thing (such as an application or API) that is trying to access it.

The process starts with identifying individual users (e.g., employees and customers) and devices (e.g., smartphones, laptops, and servers) that could potentially access data, systems, and other assets. Each individual or device is assigned one identity.

Enterprises then manage these identities through a centralized service, which may be on-premise or cloud-based. Managing identities includes adding users, modifying their information as their responsibilities change, and removing their privileges when they are no longer authorized. Every identity will be granted access to assets based on the roles associated with the individual and/or group.

Authorizing identities is typically an automated process based on the user’s location, role, job title, and other information. For example, a customer will have different authorization than an employee, and a vice president will likely have more access to more systems than a manager. Customer IAM (or CIAM) involves authorizing access for customers based on their identity, while workforce IAM typically applies to an organization’s employees, partners, and vendors.

An IAM system will also incorporate auditing and reporting processes, as well as ways to regulate user access. While passwords and software tokens were often good enough to regulate access in the past, in recent years organizations have adopted more advanced IAM technologies, including multi-factor authentication (MFA), privileged access management, biometrics, and machine learning.

Ideally, the end result is that users can access the information they are authorized to access — and only that information — throughout their relationship with the organization.



Challenges, risks, and how to address them

IAM is a flexible tool that can help organizations stay ahead of ever-evolving threats and attacks. However, as with any security protocol, there are additional factors to consider both before and after implementing IAM.

Ultimately, the goal is to balance ease of use with the security and compliance needs of your organization. Some of the challenges and risks of IAM include:

Establishing centralized authority for an IAM system (and the resulting policies, documentation, and access approval process) may require new governance entities and cross-unit collaboration.

Understanding the enterprise’s needs requires a thorough examination of each audience (including their specific access requirements and risks), how to manage access across disparate business units, and how effectiveness will be measured, among other concerns.

Onboarding (including birthright access given upon joining an organization) and offboarding necessitate changes in permissions; keeping up with these adjustments may require automation, auditing systems, and other resources.

Cross-platform issues between applications (including cloud-based and in-house apps) may require SAML and other tools to bridge gaps.

Managing cloud architectures such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform may be a challenge, as each provider can have their own unique policies, best practices, and security challenges.

Evolving standards for IAM and related technologies, including open-standard platforms, requires ongoing vigilance to stay up to date.

Additional systems may enhance security but also introduce risk; for example, biometrics is an advanced tool for authenticating identity, but storing biometrics data adds an additional concern.

IAM’s role in a security stack

The broad applications for IAM throughout an organization make it exceptionally useful. However, this enterprise-wide impact can also make it challenging to define responsibilities, establish clear guidelines, and ensure that IAM is being properly implemented—especially since it may not fit neatly within a traditional security stack.

Here are some things to keep in mind:

IAM is not just for IT. Numerous departments need to be involved in determining what resources will be managed through IAM and which users in the organization will have access to each specific resource.

Leaders must consider how IAM will be used to authenticate people as well as APIs, application keys, and similar items.

Access guidelines must also be updated, maintained, and reviewed to protect valuable assets as users and resources change.

A critical part of compliance

IAM is a commonly used tool to help achieve compliance, given that it can regulate access to data (including vendor access), manage inactive accounts, restrict password access, and achieve other compliance-related mandates.

Many organizations are required to follow certain government regulations and guidelines, which may include:

FERPA (Family Educational Rights and Privacy Act)

GDPR (General Data Protection Regulation)

Gramm-Leach-Bliley

HIPAA (Health Insurance Portability and Accountability Act)

NIST (National Institute of Standards and Technology)

PCI-DSS (Payment Card Industry Data Security Standard)

SOX (Sarbanes-Oxley)

US state-by-state privacy laws

With IAM, companies can demonstrate that data is being used appropriately (including following least privilege, in which users only have access to necessary resources), meet their compliance goals, and provide information for auditors as needed.

Digital authentication methods

IAM gives an organization the flexibility to choose the digital authentication methods that best serve its purposes and goals. These digital authentication systems affirm a user’s identity and authorize their access to approved resources.

Unique passwords are used more than any other type of digital authentication. They are often complex by design, with long combinations of upper- and lowercase letters, as well as numbers and symbols (which is why SSO is often employed to help users remember them).

Pre-shared keys (PSK) are shared passwords that allow authorization to WiFi and other common resources. While they offer convenience, they provide a lower level of security and may not be changed as often given the impact on a large group of people.

Behavioral authentication is an advanced technique (often involving artificial intelligence) that analyzes how an individual user is typing on their keyboard, interacting with a tablet or smartphone, or using their mouse. If the user’s actions do not match the approved patterns, authorization can be denied or revoked.

Biometrics provide a higher level of security, as they rely on unique user characteristics including (but not limited to) their fingerprints, voices, and irises. However, organizations that collect and/or store biometric data must have a thorough understanding of the privacy risks, security concerns in the event of a data breach, and ethical issues.

Consider Stytch for your IAM needs

As authentication remains a primary concern throughout an enterprise, the benefits of IAM are clear. Stytch is an identity access management platform that provides a single, unified view of customer identity and activity across all channels and devices. It enables organizations to quickly and securely authenticate customers, authorize access to applications and data, and track and manage customer activity.

With our simple API and flexible SDKs, you get secure and high-converting authentication out-of-the-box but retain the ability to own the UX of your application. One of the key advantages of Stytch is the simplicity of our products. Our platform is easy to use for both administrators and end users and offers a comprehensive product suite that includes MFA and SSO capabilities. Sign up for a free account to get started, or contact support@stytch.com to discuss your IAM needs and learn more about how Stytch can meet them.

---


# Go big or go home: why it’s never too early to think about enterprise
Source: https://stytch.com/blog/building-for-enterprise-sales/

Enterprise selling requires more than adding a new tier to your pricing page. Here are 5 things you can do today to make the shift into enterprise sales.

After working in B2B SaaS over the past decade-plus one of my favorite questions is, “Should we expand into enterprise sales?”

I love this question because it tests the scale of a company’s ambition, the clarity of their vision and the viability of their product. Those who can successfully bridge the gap from SMB to enterprise dominance are rewarded when raising capital, getting acquired, or by the public markets (examples here, here, and here).

But making the transition to enterprise has significant challenges, like longer deal cycles, greater acquisition costs, and less revenue predictability. The companies that make this transition successfully are the ones that lay the groundwork early on for the shift to enterprise.

In this article, I’ll cover the five key actions companies can take today to make sure if and when the time comes to shift to enterprise, they’re ready.

Because “enterprise” can be used to refer to any number of companies, for the purposes of this article we’ll define “shift to enterprise” more broadly as the shift to larger customers with more complex needs and greater revenue potential. Whether for your company that means 500+ or 500,000+, the takeaways below still hold.

5 key actions to prepare for a shift into enterprise sales

1. Mind (and fill) your product gaps

This sounds like a no-brainer, but you won’t get far with your sales efforts if there are major gaps between enterprise expectations and what your product can deliver.

To close those gaps, you need to continually:

Assess the specific needs of your target customers

Pressure test your product-market fit with buyers

Shift your roadmap as needed to prioritize your target customers’ needs

As an example, early on at Stytch we were laser-focused on passwordless solutions. Over time though, we discovered a critical mass of customers weren’t ready to go fully passwordless, and instead wanted to support it for only subsets of their users. This was especially true of more upmarket prospects.

To make ourselves more enterprise-friendly, we shifted our priorities and built our own passwords solution to offer alongside our suite of passwordless products. We’ve since made investments in products like differentiated CAPTCHA and Single Sign-On solutions with a similar aim to close any gaps between our products and our prospective customer requirements.

As a result of these roadmap changes, we’ve broadened our total addressable market and created a compelling offering that has strengthened our enterprise position. If we hadn’t listened to our enterprise customers or been agile enough to shift our product roadmap, we’d have missed out on this upmarket TAM.

2. Tailor your playbook

The process of selling to the enterprise is completely different from selling to SMBs: each requires tailored sales motions.

With smaller companies, the person you are selling to likely is both the end-user of your product and the economic buyer. You often have less than three people involved in an evaluation and can make a buying decision in less than 14 days. For these customers, you want your sales motion to optimize for speed, ease of evaluation, efficiency, and volume. Think freemium or “product-led” growth strategies where sales reps are managing a high volume of deals.

In stark contrast, enterprise sales processes involve more stakeholders, more time, and more organizational hurdles. Companies of 100+ employees will involve on average 7 people when deciding to buy software, and often take months to close a deal. This requires a more hands-on approach: sales teams need a detailed understanding of your customers’ strategic priorities and KPIs. They should also consider leveraging partnership-selling between Account Executives and Solution Engineers to offer more tailored advice.

With all the different stakeholders and stages involved, enterprise deals can get complicated quickly. Consider visually mapping out the path to close to help navigate these lengthy, complex buyer journeys.

3. Maximize the impact of your people, and automate everything else



To effectively capture upmarket opportunities, it’s critical to understand where to leverage people and where to streamline with automation. This requires answering the following questions:

Do prospects understand your value proposition and differentiated solution from the outset, or does this only occur when a person presents it to them?

How complex is your product, and how easy is it for a customer to start using it?

How quickly in an evaluation will a customer realize value?

Which milestones do customers clear easily on their own, and where do we see significant dropoff?

How do these friction points map to customers of different financial value?

These questions will reveal the mission-critical junctures where you need people to sell your product, and the easier hurdles that you can leave to automation. In short: reserve your talented, creative, and expensive salespeople for the customers and moments where they have the greatest incremental impact, both on your customers and your business.

4. Learn to sell to strangers — invest in outbound before you think you need to

In the early days of growth, your company will likely employ founder-led sales to win your first set of customers. Companies at this stage often critically mistake founder-led customers as indicative of their product-market fit at scale. Your early customers will likely be early adopters willing to take a risk on a fledgling startup, and these sales likely won’t be reproducible at scale. As such, your true ideal customer profiles or sales playbook won’t reveal themselves until you’ve learned how to sell to strangers.

This is where outbound comes in.

In learning to sell to strangers, early outbound sales will give you the opportunity to:

Programmatically test messaging against target personas

Go deeper in your understanding of your buyer and their needs

Get a better signal around what does and doesn’t work with your go-to-market strategy

Identify key objections and sticking points to address in your sales playbook

All of this helps you refine your sales toolkit in the ways you’ll need for the longer, multi-stakeholder processes that enterprise sales require.

5. Build a strong feedback loop between EPD and GTM



Your sales team should be a conduit for customer feedback early on (something I’ve written about in the past). Because enterprise has more stakeholders with unique requirements than SMBs, it’s also important to invest in frameworks and rituals to organize that feedback in a way that’s easy to draw from later on. If you cannot adequately categorize and prioritize the needs of enterprise customers, you run the risk of missing critical components or prioritizing your efforts against the wrong needs.

To encourage early adoption and collaboration between your GTM and EPD teams, they should work together to:

a) Decide on a framework to track and prioritize customer requests

b) Agree on a regular cadence for discussing and evaluating them

Whether your teams are meeting once a month or once a quarter, the key is to establish this flywheel early on so your product can evolve with you as you scale. Here’s an example framework I use with my team that can get you started.

Recap

So, should you move your sales team upmarket? For most companies the answer is eventually “yes," but make sure you’re prepared for the road ahead. If enterprise sales will be important to your business, make sure to:

Mind (and fill) the gaps: make sure your product is ready by regularly mapping customer requests against your roadmap. Adapt and prioritize accordingly.

Tailor your playbook: enterprise sales are more complex than selling to the SMB, ensuring your team has adequate coverage and understanding of their customers is key to their success.

Maximize the impact of your people, and automate everything else: selling to the enterprise doesn’t mean you have to abandon product-led or freemium strategies, you simply need to choose the right approach for the right customer based on your growth ceiling.

Learn to sell to strangers–invest in outbound before you think you need to: outbound selling helps you validate product-market fit, ideal customer personas, and importantly teaches you how to “sell to strangers.”

Build a strong feedback loop between EPD and GTM: enterprise customers will have different needs than their SMB counterparts, ensuring you deeply understand and rigorously prioritize them is critical to your success and that of your engineering team.

While this isn’t a comprehensive guide on building enterprise sales teams, these principles have served me well at past companies and guide our thinking as we expand into enterprise sales at Stytch. I hope that they are helpful to you, and would love your thoughts or feedback at pete@stytch.com. In the meantime, good luck on your enterprise journey.

---


# Stytch Talks with Brian Hale: rethinking user sign-up and login to unlock growth
Source: https://stytch.com/blog/stytch-talks-with-brian-hale/

Check out a recap of our latest webinar, and learn how to optimize your sign-up and login flows to improve user conversion rates, CAC, and LTV.

Earlier this month, Stytch’s co-founder and CEO Reed McGinley-Stempel sat down with Brian Hale, VP of consumer product and growth at DoorDash, to discuss how companies can turn their authentication strategies into critical drivers of growth.

Hale shared how his aha moment came in 2014, when he was leading a product growth team at Facebook (now Meta). They began experimenting with logins after noticing that legitimate users were being shut out from the platform due to bugs in the security flow. It occurred to them that, if auth could serve as a negative growth lever, it could also be mobilized as a positive one.

McGinley-Stempel had his own aha moment while working at Plaid with Stytch co-founder Julianna Lamb. As part of the auth team, they met with both security and growth stakeholders and realized that the platform’s biggest conversion snag (the password) was also its greatest fraud vector.

Their main takeaway? When product and security teams work together, they can better identify elements in their sign-up and login flows that are standing in users’ way — and move quickly to fix them with lower-friction solutions.

Below, we recap the actionable tips their discussion brought to light, from merging growth and cyber-security elements in your organizational structure to taking the right authentication steps to meet your users’ needs.

Uniting product and security teams toward a common goal

Building an auth-as-growth strategy starts at the organizational level by aligning your product and security teams around a shared purpose.

Typically, product teams are focused on expanding a platform’s customer base — letting “good” users in through simple sign-up flows — while security teams are focused on preventing cyber attacks and keeping “bad” users out with robust login verifications. That’s why these teams are usually seen as at odds: You can’t boost security, the thinking goes, without adding extra friction, compromising the user experience, and tanking conversion rates.

But while their immediate interests may differ, product and protection teams’ fundamental goal is the same: attracting and retaining the right users. In an ideal scenario, they’d work in tandem to find the best possible balance between UX and security.

Business leaders can make that happen by building a company culture based on trust, investing in cross-departmental relationships, and maximizing opportunities for collaboration.

At the team level, product and security managers can help by holding regular one-on-ones with their counterparts and proactively sharing their roadmaps. That ensures no one is caught off-guard or derailed by a new initiative — like an SMS verification flow that interrupts the user journey or a product A/B test that interferes with the password processing system.

When your product and security teams work together, you can shift your approach from putting out auth fires and addressing growth regression after the fact to developing a broader authentication strategy that supports growth across the board.

Optimizing CAC and LTV through auth best practices

There’s no one-size-fits-all solution when it comes to authentication. The strategy that works best for your app will all come down to your users and their unique preferences and behaviors.

That said, Hale noted there are dozens of tangible, actionable auth levers that can have a big impact on your conversions at sign-up, to bring down customer acquisition costs (CAC), or at login, to boost your lifetime value (LTV). Some standout ideas he shared include:

Offer both phone number and email as account identity options.

This can be a generational issue, as young people are increasingly turning to SMS and other mobile communications over email addresses to set up their accounts. It can also help ease geographical and cultural divides, as email access is not universal across the globe. Hale estimates that including both phone and email options can expand an app’s reach by 5%.

Tailor your passwordless path to your users and your product.

Authentication isn’t black-and-white, and there are many paths along the passwordless adoption curve. If your products are multi-platform, if you use an email-based auth system that travels across devices, or if you have an older, more traditional user base, eliminating passwords abruptly may end up creating more friction and harming rather than helping your growth efforts. Luckily, it’s easy to add passwordless options to a password-based flow and ease the transition if you’re not yet ready to ditch credentials for good.

If you can’t eliminate passwords, eliminate as much friction as possible.

Stytch has always been passwordless-first, but we recently introduced a Password product. That’s because we recognize that different apps have different considerations, but they still need easy, low-friction waysto authenticate their users.



When upgrading a password-based flow, aim for the low-hanging fruit first — like tedious, multi-step password-reset flows. There are several ways you can improve this process:

Make the reset a secondary, optional flow: most users don’t actually want to create (and remember) a complicated new password; they just want to log in and access their account. Ease their pain by logging them in via an Email Magic Link — which still proves possession of an inbox — and let them be on their merry way.

Don’t wait for users to click the reset button: if you see a user has tried and failed to log in several times, save them the trouble and proactively send them a login link via SMS or email to let them in.

Take over the screen with an automated SMS: even better, if you can, send users an SMS that automatically populates the reset code in your app. That way, a user won’t have to navigate away from your platform to regain access to their account.

Once you’ve streamlined your reset flow, you can always strengthen your security posture by adding components that don’t add extra friction. For example, Stytch integrates with HaveIBeenPwnd to check if a password has previously been compromised in a data breach — and, if so, prompts the user to reset their credentials.



Stytch offers users the option to skip password reset and simply log in via Email Magic Link OR to reset their password and log in.

Don’t block good users for mistakes bad actors would never make.

The kinds of mistakes humans make when entering passwords are extremely predictable — and not at all the same tricks hackers and password-stuffing bots use when trying to breach accounts. That means you can account for common user errors without opening yourself up to fraud.

For example: If someone submits the correct password with the caps lock on or includes an extra character that’s immediately adjacent to the enter key, that’s not the type of error that an attacker in possession of a leaked list of passwords would make. In all likelihood, this is a good user, and it’s clear they know their password, so let them in, and don’t punish them for trying.



Find the right balance of auth options to meet users where they are.

You want to offer multiple ways into your app — which may include passwords, OAuth Logins via Google, Apple, and Facebook, or any number of auth factors — but your goal is to reduce friction. You don’t want a “login soup” where users forget which factor they signed up with, open a new account, and are forced to repeat the onboarding process.

Keep things simple with a maximum of four or five auth options, and let your specific industry and audience determine your selection. Make sure you’re also partnering with an auth provider, like Stytch, that de-duplicates accounts whenever possible.



Growth-oriented auth in action

Consider some visual examples that demonstrate how these levers work in practice to inspire your own growth-oriented auth strategy. For example:

Companies like DoorDash use Google One Tap to optimize their sign-up flows, boost top-of-funnel growth, and reduce CAC.

Typically, when you ask users to sign up for your app or website — via a homepage, blog post, or anywhere else — you ask them to complete various steps, like providing a name, email, password, password confirmation, and maybe even an email verification.

If you’re looking to reduce bounce rates along this multi-step flow, Google One Tap allows you to piggyback on an active Google/Gmail session on the user’s browser and collect and verify their information with a single click.

Companies that have A/B tested multiple authentication factors have found Google One Tap to be their most successful experiment by a long shot. For example, Pinterest saw a 47% jump in desktop conversion rates (and a 126% jump on Android), while Reddit doubled their new user sign-ups and returning user conversion rates.





Companies like Instagram simplify their password-reset flows to optimize login processes and reduce bounce rates.

Users on your login screen are typically those with the highest intent, since they’ve already signed up for your platform and are now returning to complete a specific action or to make a purchase. As noted earlier, the key to keeping those users happy is to make it easy for them to access their accounts — especially when they forget their credentials.

Instagram defaults to sending users a login link via email or SMS but also offers options for creating a new password or account — so they only have to navigate a reset flow if it’s what they really want.





Companies like 1-800 Contacts embed authentication tokens into their marketing materials to eliminate friction and increase LTV.

If you’re sending frequent marketing communications to users via email or SMS, you can build an authentication token into your call-to-action button via an Embeddable Magic Link. When it’s clicked, simple device fingerprinting allows you to ensure it’s by the user who owns that inbox or phone. You can then send them straight to their account — rather than a logged-out state — bypassing login friction and enhancing their overall experience. We’ve found this can increase engagement and conversion rates by as much as 300%.



Companies like DoorDash use “just-in-time” authentication to introduce friction only when it’s needed.

Finally, instead of front-loading their apps with multi-factor authentication at every single sign-up and login (regardless of the risk posture), forward-thinking companies like DoorDash only ask users for additional authentication factors when they’re looking to carry out sensitive tasks — like changing a delivery address or updating payment details.

We call it “just-in-time” authentication, because it saves the stepped-up security measures (and, with them, the extra friction) for when they matter most.





As you assess and update your auth strategy, make sure you’re sizing up your platform both qualitatively and quantitatively, including metrics like bounce rates on key onboarding pages, the percentage of users completing your password-reset flows, and where exactly they drop off in their journey. You should also ensure you’re auditing your flows regularly and investing in the best tools and technologies to enhance your growth.

Key takeaways

Your sign-up and login flows shouldn’t be an afterthought — and they shouldn’t belong to a product or security team alone. They’re critical to your user experience and can have a substantial impact on critical business metrics like conversion rates, CAC, and LTV.

Ensuring key teams and stakeholders are aligned when selecting and implementing the best flows for your app will go a long way toward creating an auth strategy that not only protects your users but fuels your growth.

Ready to power your growth through frictionless auth?

Visit our LinkedIn Events page to watch the full webinar — or download a copy of the slide deck here.

If you have any questions, want to learn more about best practices, or are interested in walking through your security flow with an expert, reach out to the Stytch team to book a free consultation. You can also check out our Slack channel to participate in daily discussions on all things auth.

---


# How to use references in your hiring process
Source: https://stytch.com/blog/how-to-use-references-in-your-hiring-process/

Don't overlook using references in your hiring process. Read about how you can make the most of using references when building out your team.

Hiring, especially in the early stages of your company’s journey, can be a harrowing prospect. Not only will your early hires make a foundational and long-lasting impact for years to come, but a wrong hire could be extra costly when you have little margin for error as a small team.

Several months ago, I wrote up a founder’s guide to hiring engineers, and in it raised the importance of making references as a part of the hiring process. In this post, I wanted to dive a little deeper into how you can go about using hiring references when building out your team.

Why references?

As thorough as your interviews may be, only so much can be gleaned about a candidate through a few hours spent with a couple interview panelists. As discussed in this Harvard Business Review article, references are more than just a checkbox - they provide a unique window into what the candidate is like as a teammate. References allow you to gain valuable context about how a candidate collaborates with others and their ability to execute over long periods of time. Interviews are a small peek into a candidate’s ability to do the job, but hearing from people who’ve worked with them for years provides a more in-depth perspective.

How to approach references

There are two types of references: those supplied by the candidate and backchannel references. Depending on the number of backchannel references we might have access to, we’ll ask candidates to supply 2-3. Candidate-supplied references are generally extremely positive (the candidate hand-picked them after all), so any candidate-supplied references that aren’t a glowing recommendation can be illuminating, but expect most to be fairly straightforward and positive.

For backchannel references, we prefer to make sure the candidate is aware that we’ll be contacting some references, so we tell them so explicitly. We typically say something like the following:

We'll do a back channel reference and reach out ourselves — we know this can sound a bit unconventional because many companies aren't always upfront that they do this, but we think it's important to be transparent. We want to be particularly sensitive not to reach out to anyone where it might create issues for you if they know you're considering new roles - is there anyone (or groups of people) that we should definitely not reach out to?

When reaching out to a candidate reference, your objective is to get a holistic view of your candidate’s past experience (both professionally and personally) as efficiently and concisely as possible, out of respect for the reference’s time. With that in mind, there are a few topics you’ll want to cover:

1. Context on the environment

If you’ve had experience working at multiple companies, you’ll know that workplace culture can vary significantly, and it’s critical to understand this backdrop when evaluating your candidate. Whether it’s organizational and team structure or other cultural quirks, be sure to ask your reference to establish this workplace context.

What was/is the workplace/organizational culture like at your company? What adjectives would you use to describe it?

Next, you’ll want to gauge your candidate’s past performance, and a crucial part of this is understanding the reference’s relationship to the candidate so that you can get a sense of how their roles interacted, what projects they may have worked on together, the amount of time they’ve worked together, etc.

What was your relationship with the candidate? (follow-ups: How long have you known the candidate? Did you share any projects? When did you most recently work together?)

2. Work quality and performance

Now that you’ve gathered context on how the reference and candidate have worked together in the past, you can move on to the quality of your candidate’s past work and how they performed. As much as possible, look for concrete examples.

What stood out most about their job performance when you worked together? Can you offer an example?

Can you describe an instance where they took initiative?

How would you compare them to others at the same level?

Your interview process likely already evaluates candidates on their “values” fit, so you’ll want to validate that your candidate will in fact work well with your team’s operating values, and that their approach to teamwork is positive and collaborative. Take some time to dig into how the reference’s experience with your candidate resonated at a more personal level.

What stood out about their character? Can you offer an example?

Would you want to work with them again?

3. The most insightful question

The most insightful question is one that requires the reference to put a hard number on the candidate’s performance, but the interesting part of this question is the follow-up question “what would it take for them to move up one point?” Specifically the question goes:

On a scale of 1-10, how would you rate their performance? Most importantly, what would it take for them to move up one point?

This question is illuminating in a few ways. It requires the reference to succinctly address any weaknesses and do so in a way that gives the reference the opportunity to frame weaknesses as growth areas while still being honest about what holds the candidate back. We find that the level of honesty we get in response to this question is on a different level than any other piece of the reference call. The score itself is generally not very meaningful but can occasionally be insightful. Usually, references answer something in the 7-9 range; and anything below a 7 tends to be a red flag, especially for a reference supplied by the candidate.

4. Ensuring success in their new role

Lastly, we’re all human and everyone has areas they can improve in, so you’ll want to ensure your candidate has the best chance at succeeding once they onboard and ramp up. References are a rare opportunity to dig beneath the surface and get a more objective perspective on your candidate’s strengths and weaknesses. Try to understand what they truly excelled at in past roles, and see how you can set them up for success once they join.

What advice would you give this candidate to help them excel in a new role?

As a last step, consider asking the reference whether there are any other references they would recommend speaking with - so take advantage of their network if you can!

Hiring is already an intensive process that you’re likely pouring significant time and resources into - be sure you’re not overlooking the last mile in the process by treating references as just a checkbox. It’s an invaluable tool that’s all the more crucial when you’re an early stage startup to ensure that you’re getting the most out of your new hires. Have more questions on hiring? Don’t hesitate to reach us at startups@stytch.com if you're looking for more advice and guidance!

---


# Stytch named as top authentication provider by Cybernews
Source: https://stytch.com/blog/stytch-named-top-authentication-provider-by-cybernews/

Stytch’s passwordless-first approach, easy implementation and flexible API and SDKs set it apart as a top authentication and identity management provider.

Stytch has made the list of Cybernews’ top 23 best authentication providers!

We are building an all-in-one platform for authentication and identity management. We offer a holistic suite of solutions that reimagine authentication, starting with out-of-the-box and customizable passwordless products that are easy for engineering teams to integrate and lead to improved user conversion, retention, and security.

We’re proud to be featured in Cybernews’ list of the top 23 best authentication solutions. Here’s a recap of what set Stytch apart:

Passwordless-first: a passwordless future is the main goal at Stytch. With Stytch’s modular, flexible passwordless solutions — from One-Time Passcodes to Magic Links, Biometrics and more — and enhanced password product, it's easy for your business to build towards a more secure, frictionless future.

Out-of-the-box implementation: offering a fully integrated suite of authentication and authorization products, Stytch removes the headache of developing an identity and access management system from scratch. Get up and running in minutes, not months.

Flexible SDKs and API: Stytch’s SDKs give you the option of using pre-built UI components or fully customizing the user authentication experience to fit your brand’s look and feel. For maximum flexibility, our direct API gives you the tools you need to build out authentication flows to fit your exact needs.

Learn more about Stytch and discover our full suite of products at Stytch.com. Sign up for a free account or reach out to talk to a Stytch Auth Expert today.

---


# Introducing Strong CAPTCHA, Stytch’s answer to CAPTCHA fraud
Source: https://stytch.com/blog/strong-captcha-announcement/

Introducing Strong CAPTCHA, Stytch’s answer to CAPTCHA fraud

Stytch is excited to announce Strong CAPTCHA, the newest addition to our product suite. Our modern take on anti-fraud protection tackles bot fraud at its root: on the backend site architecture. In this article, we'll first cover how CAPTCHA systems work and why they are vulnerable to attack. Then, we'll dive deeper into how we designed Strong Captcha to overcome these vulnerabilities and how it can fit into your auth flow.

Telling bots from humans

Humans are the minority on the internet today. According to a recent report, over 60% of internet traffic is bots, and over 50% of that bot traffic is malicious. This malicious traffic takes many forms, including:

Fake user account creation: for purposes ranging from buying and reselling concert tickets to influencing elections.

Spam: deceiving emails that get users to click on malicious links or provide security information to bad actors.

Account takeovers: in which username / passwords are used to gain access and take over someone’s account, typically for financial gain. This is often enabled by credential stuffing, in which bots attempt a high volume of username/password combinations obtained from a prior data breach.

With the wide variety of threats bot attacks pose to human internet users, it’s no wonder over the past two decades we’ve seen a rise in the use of CAPTCHA, or Completely Automated Public Turing Test to Tell Computers and Humans Apart. We’ve all had to complete these tests at some point, whether it’s selecting images that contain a traffic light, typing in a word displayed in squiggly font, or even just checking a box that asserts we are not a robot. While the challenges appear relatively simple to end users, they are a main line of defense against bot attacks.

CAPTCHA fraud

Unfortunately, CAPTCHA challenges today are engineered more for scale than security. Specifically, CAPTCHAs are vulnerable to a cottage industry called CAPTCHA fraud, in which bad actors outsource solving the test to people on behalf of bots. These companies (also called “CAPTCHA farms”) exploit CAPTCHA’s public key architecture, in which each CAPTCHA instance is identified by a sitekey publicly visible in the web page’s source code. These sitekeys make it easy to get CAPTCHA services up and running with little backend infrastructure. Crucially though, they also make it possible for the person who solves the challenge to be in a different browser from the one used to submit the solution. Like other (albeit more legitimate) SaaS businesses, CAPTCHA farms operate through APIs. Typically, the process looks something like this:

Get public key: to solve a challenge remotely, all a CAPTCHA farm needs to solve the challenge remotely is this public site key and the URL the CAPTCHA is protecting. So the bot simply scrapes this sitekey value and sends it and the URL as parameters to the CAPTCHA farm’s API endpoint.

Solve CAPTCHA: using the public site key and the URL, a human CAPTCHA solver receives the CAPTCHA challenge in their queue, solves it, and retrieves the response, also referred to as g-captcha-response. This response code comes in the form of a string, and communicates to the client that the CAPTCHA has been solved (regardless of who solved it or from where).

Return response: through a separate API call, malicious bots can then retrieve the g-captcha-response code and submit it to whatever page they’re trying to gain access to. Because they have the correct response code, the site in question registers them as a human, and grants them access.



Though CAPTCHA farms employ humans, they typically boast a response time of < 60 seconds. Because of this, hackers can automate the API calls to CAPTCHA farms into their scripts, accelerating the speed and scale of their attacks. This turns CAPTCHA challenges into minor obstacles for bad actors, and opens up scalable attack vectors for bots. The result is added friction and costs on both users and business in the form of fraud, wasted resources, and time.



Strong CAPTCHA: secure and scalable

If CAPTCHA infrastructure is so vulnerable, why do so many people still use the public key architecture? Simply, it’s scalable. For companies who process thousands or millions of authentication attempts, public key architecture offers a fast, affordable way to get CAPTCHA up and running. Fortunately at Stytch, we believe you shouldn’t have to trade scale for security. That’s why we created Strong CAPTCHA. Strong CAPTCHA is functionally incompatible with how most image captcha solver services work today because we have removed the public site key entirely from the end user’s browser environment. With the sitekey unavailable to the end user, we’ve made it architecturally impossible for a CAPTCHA provider service to easily, and directly generate solutions for CAPTCHA-protected sites using attacker preferred, easy-to-use paid API pathways.



Without direct public-key access, malicious bots can no longer use these services to easily get through CAPTCHA challenges, strengthening the line of defense between a given site and bad actors. The best part? Strong CAPTCHA introduces zero additional friction to the end user’s experience: they get the same familiar CAPTCHA challenge on the frontend, with a more secure infrastructure on the backend.

Use Strong CAPTCHA with your authentication flow

At Stytch, we are laser-focused on helping our customers authenticate their users and verify their identity with minimal friction. By distinguishing bots from humans, Strong CAPTCHA adds another vital solution to our arsenal, and only makes the Stytch suite a more comprehensive auth solution for our customers. While some of our customers may already have a CAPTCHA solution they’re looking to upgrade, we also recognize some companies may still be in the process of understanding where it fits into their authentication flow. You can always chat with an auth expert for more personalized guidance, but there are a couple key junctures where we generally find CAPTCHA to be helpful:

Account creation: account creation is a prime target for bots because of the volume of traffic and lack of authentication. Because of this, it’s an ideal juncture for using Strong CAPTCHA.

Just-in-time: many companies use CAPTCHA when they start to notice suspicious behavior, like when a high volume of login attempts come from the same IP address, or if a user’s login behavior is too fast (an indication bots are at work). They might also introduce CAPTCHA if the user is trying to do something involving sensitive or high value information, like change their payment information or account email.

While you can technically introduce CAPTCHA at any point in your login flow, we believe our customers will be most successful if they only use it where it’s most needed. Authentication is a critical growth lever, and you don’t want to create any more hoops for users to jump through than you have to. At the same time, CAPTCHA is just one piece of the authentication puzzle, and it’s important to think about how it fits into your complete customer journey and authentication experience. While we offer more detailed guidance on breach prevention on our blog, it’s safe to say we strongly advise our customers not to rely exclusively on any one given gateway, especially if that gateway is passwords. (For more information on some options to consider, check out our blog on step-up and multi-factor authentication flows). As an example, your Strong CAPTCHA-enhanced authentication flow for account creation might look something like this:

Provide email.

Solve Strong CAPTCHA to trigger verification email.

Verify email with a magic link.

Account creation success!

Or, you might use it in your login flow like this:

Provide username and password.

Strong CAPTCHA is prompted if the user is using an unusual IP or unrecognized device.

Solve Strong CAPTCHA.

Login success!

These examples are just the tip of the iceberg for how to configure your authentication flow with Strong CAPTCHA. You can learn more about this solution or other products at stytch.com, or book time with one of our auth experts to see Strong CAPTCHA in action. Whatever your questions or needs, we’d love to help you on your auth journey.

---


# The importance of investing in unphishable authentication
Source: https://stytch.com/blog/investing-in-unphishable-authentication/

Learn how unphishable MFA like WebAuthn can help you prevent the data breaches like the ones that recently targeted Uber, Twilio, and Okta.

 If you follow business news outlets, you’ve likely heard about the data breach that infiltrated Uber’s security in mid-September. It’s only the most recent in a string of similar security incidents that have impacted companies like Twilio, Okta, Microsoft, Samsung, Cisco, and other companies just this year. The common thread in all of these attacks? The use of phishable authentication factors, or sensitive user credentials that hackers can intercept and use to break into an account. In this post, we explain how these data breaches happen and how you can rely on unphishable authentication methods — like WebAuthn — to stop them from happening to you.

How phishing attacks bypass traditional MFA

Now, you may be asking, didn’t Uber use multi-factor authentication (MFA) to protect its sensitive data? And the answer is probably yes. But MFA can still be vulnerable to phishing attacks, which use social engineering tactics — like an email that mimics a password-reset flow or a push notification granting access — to trick employees into divulging their credentials. While phishing attacks often target passwords (something a user knows), they can also undermine auth methods that are typically used as secondary factors in an MFA flow, like SMS one-time passcodes, push notification, or email magic links. In fact, any factor tied to a user’s phone number or email address (something a user has) can potentially be rerouted at the source and compromised by a determined hacker.

What unphishable MFA does differently

Unphishable MFA offers industry-leading security by relying on asymmetric or public-key cryptography. That means valuable data, like factors that grant access to a server, are encrypted using both a public and a private key. While the public key is stored on the server, the private key can only be activated by a specific user. To gain entry to an account, both keys must be triggered, with the private key sending a customized message to the public key to grant access. To break it down, this two-part MFA flow is immune to remote phishing attacks because it:

Requires physical interaction with a specific device, meaning there’s no text-based secret code or password for a hacker to intercept.

Generates unique keys for every exchange, so they cannot be reused across multiple platforms.

Binds a user’s login to the site of origin, so they cannot be used on a fake or replica site.

Does not store or send private-key data over a public network.



The evolution of WebAuthn

WebAuthn is one of the leading forms of unphishable MFA. It encompasses three different categories of device-based authentication factors that can be used to verify a user’s identity:

Built-in biometrics like TouchID and FaceID. These auth factors fall into the something-you-are camp. They involve the unique attributes of a user’s body, including fingerprints, retinal scans, and facial features.

External hardware keys like Yubikey. These auth factors fall into the something-you-have camp. They involve a physical security key that is inserted into a user’s device.

Passkeys which are an adaptation of built-in biometrics combined with public key cryptography that makes them compatible across devices and even across operating systems. 

While WebAuthn has seen relatively low commercial adoption to date, it’s set to ramp up in the coming years, thanks to three significant advancements:

Passkeys are revolutionizing the WebAuthn user experience: With passkeys, users can now leverage the advantages of WebAuthn, without any of the drawbacks or impediments that made using it so cumbersome. 

The WebAuthn developer experience is improving. While WebAuthn has historically been fairly complex to integrate, major auth providers (like Stytch) have worked hard to enhance its usability, resulting in WebAuthn solutions that can be implemented in under an hour.

WebAuthn is becoming more affordable. One of the key barriers to entry for WebAuthn has been cost, with incumbents like Okta and Auth0 treating it as a premium feature and charging at least $30K a year for access. But the auth market is expanding, and the pricing of top security products has grown more competitive. In particular, pay-as-you-go pricing models mean developers can now tap into WebAuthn for a few pennies per active user.

Businesses are waking up to the value of unphishable MFA. Specifically, security and compliance teams are seeing the increasing prevalence and consequences of phishing attacks. These are the teams that spearheaded the widespread adoption of single sign-on (SSO) technologies years ago, and they’re catching on to the weaknesses in conventional SSO that newer solutions like WebAuthn can remedy. Soon, phishing-resistant MFA may be a similar requirement for signing an enterprise deal just like Single Sign-On support is today.

As the auth industry continues to advance — and with the introduction of adjacent technologies like Apple Passkeys that make the use of biometrics easier and more universal — we expect WebAuthn to become an even more popular way to neutralize the risk of remote phishing attempts.

Key takeaways

Adopting next-level authentication measures like WebAuthn isn’t just about keeping up with the latest security practices. It’s about protecting your users and your platform against real cyber attacks that are wreaking havoc on even some of the world’s biggest corporations. It’s as simple as investing in a comprehensive auth strategy that gives you access to a variety of robust solutions at once — and ensuring they include unphishable MFA factors that can defend your data against the worst that hackers can throw your way.

Discover the benefits of unphishable authentication

If you’re interested in learning how unphishable MFA factors might work on your platform, reach out to Stytch’s team to book a free consultation. You can also check out our Slack channel to join daily discussions on all things auth.

---


# What is unphishable MFA?
Source: https://stytch.com/blog/what-is-unphishable-mfa/

Not all MFA are created equal. Learn how unphishable MFA stops phishing scams in their tracks and keeps your app and user data secure.

In the world of authentication, there are many options when it comes to verifying a user's identity — but they’re not all created equal. For instance, passwords are easily compromised through common hacking methods like brute force attacks and credential stuffing because they’re often easy to guess or reused across multiple accounts. 

This is one reason many security-minded organizations are adopting multi-factor authentication (MFA) — which requires additional authentication factors like email magic links or biometrics — as the standard for identity verification. Still, there are many possible forms and variations of MFA, and some offer better security than others. In this article, we explore why some MFA flows fall prey to phishing attacks, explain what unphishable MFA does differently, and break down why it’s the best option for protecting your apps and data from malicious actors.

What is phishing?

To understand the importance of unphishable MFA, it’s important to first understand the dangers of phishing scams. Phishing is a form of social engineering. Rather than targeting vulnerabilities in computer systems or hardware, social engineering attacks aim to exploit the human component of an organization or user. They deploy deceptive tactics that trick people into divulging personal information or granting access to a sensitive database through fraudulent messages and/or malicious links. This might look like an email from an unknown contact containing a link that promises some kind of reward or to fix a “problem” the user isn’t aware of. 

But not all phishing attacks are so overtly suspicious. 

For example, password phishing scams frequently mimic legitimate password reset emails and are a popular way to gain access to user credentials. MFA is designed to thwart these scams by employing additional layers of security to verify a user's identity. With MFA, even if a user’s credentials are compromised, a hacker would have to bypass those extra security measures to gain access to the system, making a successful breach more difficult.

Is MFA phishable?

The short answer is, yes. Certain forms of MFA are phishable. Any MFA factor that is tied to a user’s personal phone number or email address—like an SMS one-time passcode, email magic link, or voice authentication—can be compromised by a determined hacker. 

Emails are a very common vector for phishing attacks. Hackers use malicious email links that direct users to fake landing pages and proxy servers that record any credentials and one-time passcodes users enter. The hacker can then plug in that information on the back end to gain access. This is also known as a man-in-the-middle (MitM) attack. With SMS, phishing can get a little more sophisticated, but similarly involves a phisher somehow convincing a user to share a one-time passcode (OTP) or other sensitive information that the hacker can use to gain access to their account.



How does unphishable MFA work?

Unphishable MFA is a multi-factor authentication flow that cannot be compromised by any of the tactics mentioned above. Relying on asymmetric or public-key cryptography, this form of authentication provides the highest level of security. Asymmetric cryptography encrypts valuable data — in this case, access to a server — using a public key and a private key. The public key is stored on the server, while the private key can only be unlocked by the user. Once unlocked, the private key sends a personalized message to the public key, providing the user with access. 

This cryptographic foundation can be paired with different authentication factors in an MFA flow, allowing users to verify their identity securely in the following ways:

Security key-based authentication (something you have) After inputting their credentials or code, a user is asked to provide a physical security key. When inserted into the user’s device, the private key is triggered, and the user is granted access to the server.

Biometric authentication (something you are) After inputting their credentials or code, a user is authenticated using a physical feature like a fingerprint, retinal scan, or facial scan. The private key is then triggered, granting access to the server.

How does unphishable MFA prevent the most persistent hackers?

This approach offers protection against phishing attacks in four critical ways:

It requires physical interaction Because users must engage physically with the device they’re requesting access from, they can’t be compromised through remote attacks by a hacker, bot, or trojan.

It uses unique keys every time An important characteristic of asymmetric cryptography is that it generates unique keys for each individual service, ensuring no two keys are reused across multiple sites. And, because only the public-facing key is stored, there’s no way for hackers to know which sites or services a user is registered on.

Biometrics aren’t saved on the network Similarly, unlike passwords, a user’s biometrics aren’t stored or sent over the internet. They’re only used to trigger the private key.

Access is bound by origin Only the real site can authenticate the private key, helping protect users against man-in-the-middle attacks.

Taken together, these factors explain why this type of MFA is referred to as “unphishable.” And they’re why incorporating unphishable MFA into your website or app is the best way to prevent cyberattacks and safeguard your and your users’ data.

Fight back against phishing

For Stytch, security comes first. Sign up for a free account, and discover our unphishable, easy-to-integrate solutions for passwordless authentication. Sign up today.

---


# Stytch Q3 wrap-up
Source: https://stytch.com/blog/q3-wrap-up/

It was a busy summer at Stytch. Here’s a recap of key new products and features we released in the identity & access management space in Q3 2022.

It was a busy summer season at Stytch and as we settle into fall, we’re reflecting back on all that we shipped in Q3. Here’s a look at some highlights…

Product news

Passwords

In July we launched a first for our company — Passwords. To help our customers make the transition to a frictionless login, we wanted to provide our own password-based auth solution. But of course, we’re Stytch, so we wanted to reimagine, not just rinse and repeat what’s been done before. Here’s how we made Passwords better:

Password strength and breach detection: In the face of password overload, users default to easy-to-guess or re-used passwords. Our Passwords product automatically detects breached passwords using HaveIBeenPwned and assesses passwords for strength.

Safe account de-duplication: Stytch de-duplicates accounts by email regardless of the authentication method. This allows your users to change which authentication option they are using to log in to an app without accidentally creating a new account (e.g. a password user can switch to sign in via Google OAuth) or being forced to re-authenticate with the same method originally used.

A more human-centric password reset flow: When an end user triggers a password reset, most of the time they really just want to access their account, not change their password. With Stytch, customers have the option to integrate a password reset powered by Email Magic Links for a more seamless experience.



To see Passwords in action, Watch Wes Doyle implement a complete password flow with Stytch Passwords in Vue.js + .NET 6. Wes walks you through the entire integration end-to-end and offers super helpful tips, like how to properly debounce your strength checking for a polished feel. You can also check out our guides for more detailed information.



React Native SDKs

We launched our brand new React Native SDKs! They make it easy for developers to use Stytch in their React Native projects.

iOS Mobile Biometrics

Native Mobile Biometric authentication lets your users leverage their devices’ built-in biometric authenticators such as FaceID and TouchID for seamless and secure login experiences. Our iOS SDK now supports Mobile Biometrics natively, check out the Docs to get started!

Strong Captcha

In Q3, we soft launched Strong Captcha, our latest product to prevent fraud in authentication. CAPTCHAs are a great way to mitigate bad actors from being able to attack your application, but they can be compromised at scale by bot farms. Strong CAPTCHA tackles this problem at the root by removing the primary vulnerability that attackers exploit. We’re super excited to ship more products in this space to help you make your login safer.

B2B Auth — coming soon!

Some big changes are coming to the Stytch platform! We're excited to share that we've started work on enterprise Single Sign On (SSO) to better serve our B2B customers. B2B authentication is an exciting space and we'd love for you to join us in building the next generation of SSO. Join our early access program here.

Other Q3 Stytch News

Website relaunched

We relaunched Stytch.com! In Q1, we kicked off a partnership with Together, a UK-based creative agency, to re-imagine our website and enhance discoverability of our growing portfolio of solutions. We were proud to release our new site into the world in Q3.

Docs rebooted

To improve our developer experience, we spent time re-organizing our Docs to make them more clear and accessible. One update that we are especially proud of is a new navbar featuring each of our products. It makes it easy to find all the resources you need, like guides and example apps, all in one place.

Stytch Talks with Brian Hale

Stytch hosted a live webinar (aka Stytch Talks) with Brian Hale, DoorDash's Head of Growth, to discuss in-depth why auth is such a critical lever for driving conversion and growth. Watch the full Talk and walk away with tips and best practices for optimizing your sign-up and login flows to drive key metrics like conversion rates, lower acquisition costs, and lifetime value.

Get started with Stytch

That’s a wrap on Q3. To try out Stytch for yourself, Sign up for a free account. Reach out to talk to an Auth Expert if you’d like to discuss how our API and SDPs can support your auth needs with easy, flexible solutions.

---


# Do passkeys live up to the hype?
Source: https://stytch.com/blog/passkeys-hype/

Do passkeys live up to the hype?

The dream that propels most people working in identity and access management (IAM) is the search for a frictionless yet secure way for users to authenticate themselves online. Legacy forms of authentication like passwords are friction-heavy and contain major security holes. Passwords specifically create significant negative externalities on both businesses and consumers, ranging from account takeovers to lower conversion at sign-up and login. Given the significant UX and security issues that legacy authentication methods pose for both companies and their customers, it’s no surprise that many in the IAM space believe that passwordless authentication will play a key role in the future of identity and access management. 

But passwordless authentication can mean many things — passwordless technologies include one-time passcodes (SMS/Email), email magic links, social logins (e.g. Google/Facebook/Apple/etc.), and biometrics like facial and fingerprint verification. To date, all of these authentication methods have gained considerable adoption, yet many apps continue to offer passwords as an authentication option to users. These technologies have reduced our reliance on passwords and many users prefer them, but they still haven’t managed to kill the password. 

Of the above technologies, studies continue to find that biometrics are the most enticing to both consumers and businesses — they’re fast, simple, secure, and familiar given the reliance of Apple, Microsoft, and Android devices on biometric-based authentication. In a recent PYMNTS and Mitek study, 55% of consumers trust biometric authentication methods more than passwords and PINs (31% remain undecided and only 14% prefer traditional methods like passwords).



Source: PYMENTS 

Users are highly supportive of biometric authentication, but it’s still not a ubiquitous experience. While many consumers use facial recognition on their mobile banking app or their fingerprint to log into their laptop, these biometric forms of authentication are still not supported by most applications. The technology exists and is familiar to users, so the question remains why it isn’t the primary option when we sign up for and log in to the hundreds of other online accounts that we manage. The answer has to do with some existing limitations to how biometric-based authentication works today. 

Fortunately, solutions aimed at fixing those current shortcomings are on the horizon. In May 2022, the Fast ID Online Alliance (FIDO Alliance) announced a major development in passwordless technology that would make biometric authentication significantly better suited for consumer use cases: passkeys. Passkeys aren’t necessarily a new technology, but they solve some of the major UX obstacles with existing biometric authentication technology and have support from the major tech platforms (Apple, Google, Microsoft) to drive widespread biometric adoption. So, are passkeys worth the hype? And if so, what might the path to passkey adoption look like for business and consumers? 

Working in this space requires a blend of eternal optimism and severe skepticism. We know the future holds better authentication experiences, but we’ve also been repeatedly subjected to hyped authentication technologies that ultimately failed to move us beyond passwords. Fortunately, passkeys appear to be the real deal. It will take time for businesses and consumers to adopt them, but the architecture provides a significant leap forward in the feasibility of wide-scale biometric authentication adoption.

Current gaps in WebAuthn and the case for passkeys

Passkeys are a new evolution built upon an existing passwordless technology called Web Authentication API or “WebAuthn.” To understand the promise of passkeys, it’s important to understand where the initial capabilities of WebAuthn technology have fallen short of consumer expectations. In March 2019, WebAuthn was declared a W3C web standard. At the time, WebAuthn received its own fair share of hype and was a critical stepping stone on the path to passkeys. It promised to smooth the user experience of biometrics by making user enrollment more intuitive and supporting cross-device and cross-platform biometrics. 

However, +3 years later, it’s fair to say that WebAuthn’s adoption has been minimal, particularly in B2C use cases where there’s a higher emphasis on user experience. A major reason for WebAuthn’s limited adoption is that the technology has been sidelined into a secondary authentication method rather than being offered as a true primary method to users signing up for or logging into an account. There have been two main problems with WebAuthn as a primary authentication factor:

UX: UX experience of WebAuthn as a primary factor - either for "passwordless" or "usernameless" scenarios - has been pretty rough. The WebAuthn W3C group has put together a document that goes into far more detail. One of the items out of that discussion was a standards change that was merged in a few months ago. Now it's up to browser vendors to implement that change over the coming months and years.

Lock-out risk: The second problem with WebAuthn is that device-based authentication has been historically risky for consumer users long-term. It's unreasonable to expect an individual to have access to their phone, YubiKey, or laptop over a period of years. In the B2B space, this isn't as big of a deal. Getting an IT admin that works for your company to reset your access and issue a new credential is not a complex problem. However, this is a major hurdle in the B2C space. Devices get lost or stolen, and then the service operator needs to build out an alternative recovery method that needs to be as secure as WebAuthn (ideally, without infringing on the user's privacy, as regulated by Know Your Customer (KYC) mandates).

To make this tangible, imagine you’re a user signing up for an account with HomeDepot in order to buy paint:

You start your search for paint on your mobile device and find a few colors you’re excited about. You create a HomeDepot account in order to complete the order. You see a FaceID icon and think “Great! No password needed — I can just use a biometric to sign up.

A day later, you see the shipping confirmation while checking email on your laptop, and you realize you’re out of paint brushes. You go to HomeDepot.com to order a few brushes as well. When it asks you to log in, you click on the same biometric icon you saw in the mobile app

However, laptops do not support FaceID, so HomeDepot asks you to go through the TouchID flow on your Mac. You enroll your fingerprint and you receive an error telling you an account doesn’t exist.

You know that’s not right, but you’re not sure what’s gone wrong, and you’re in a hurry. You decide to create a password, enter all of the same information you provided yesterday (address, credit card info, etc.) and make the purchase with this same account.

You’ve now experienced the biggest shortcoming with WebAuthn today — it doesn’t handle cross-device or cross-platform authentication well. Instead of it saving you time, it actually led to confusion and required you to duplicate work while also creating multiple accounts for HomeDepot to manage on their side. In short, WebAuthn isn’t a great replacement for passwords for most applications today, unless their users are tech savvy and OK with the lock-out risk. 

Luckily, passkeys build on over a decade of learnings like these to overcome these user challenges and become a major contender for preferred primary authentication factor. By enabling biometric authentication to work across all major devices and browsers, passkeys are likely to be a game changer for B2C WebAuthn adoption.



What are passkeys and how do they work?

Though passkeys are built upon WebAuthn, they improve on the older auth method in a few key ways. While WebAuthn pioneered the concept of a single-device passkey (i.e. a single hardware key or a biometric validation tied to your mobile device or laptop), “passkeys” as we’re discussing here refer to multi-device passkeys and introduce a few major UX and developer improvements:

They are a drop-in replacement for passwords.

They are cross-device, cross-platform, and cross-ecosystem.

Enrollment and login credentials with a passkey leverages UX patterns made familiar by password managers.

For higher security contexts, passkeys can discern between existing and new devices attempting to access an account.

Definitionally, there are a few different ways to describe passkeys depending on the audience you’re talking to:

For consumers, passkeys provide a simple and secure way to sign up and log in to sites and apps without the need for a password.

For the tech savvy, a passkey is a phishing-resistant, password replacement FIDO credential, usable across all of your devices.

For the tech-and-authentication savvy, a passkey is a FIDO2 discoverable credential which requires user verification and is backed up to survive device loss.

If you’ve ever used a password manager like LastPass or 1Password, you’ll understand the value proposition of passkeys. Password managers provide a much better user experience than fumbling around to remember a unique password for each different online account. Passkeys work similar to this, but they don’t require consumers to pay to use them or remember a master password. 

Instead, passkeys work by storing a key pair consisting of a public and private key in a user's primary device account (e.g. your iCloud account on your iPhone or Mac or your Google account on your Android or Chrome book). This key pair can then be used to sign up or sign in to applications without creating or remembering an additional password. The public key cryptography underpinning this technology isn’t new, but the way that multi-device passkeys leverage your logged in account across devices (e.g. iCloud, Google, Microsoft) to perform these cryptographic checks is novel. 

Whereas prior uses of public key cryptography have typically only allowed for device-bound keys, multi-device passkeys allow for these keys to be synced across cloud accounts to enable use on different devices. What’s more, passkeys also incorporate bluetooth and QR codes to enable login via biometric passkeys on different operating ecosystems. So hypothetically, users could use an iCloud passkey on their tablet to log into an app on their Android phone, and vice versa.



Source: FIDO Alliance 

If we return to our Home Depot example, we can see how multi-device passkeys with biometrics make the user’s experience much more streamlined than WebAuthn:

When a user is checking out on HomeDepot’s mobile app, they can choose to create an account in one click with their face ID on iOS or Android. At this point, their device generates a passkey and stores it on their device’s account.

If that user needs to access the account again from their laptop, their credential will already be synced with their iCloud or Google account. All they need to do is use whatever biometric credential their laptop uses, and the same passkey from their phone will be used to log them in on their laptop.

The user now has a fully biometric-only account that’s easy to navigate across different devices.

What will the path to passkey adoption look like for businesses and consumers?

In our opinion, passkeys offer the best chance to move us beyond passwords and into a more simple and secure biometric-based future. They’re fast, secure, familiar, and privacy-preserving (no biometric data is ever actually transmitted to the application verifying the user). While we believe the adoption curve for passkeys will be significantly steeper than WebAuthn, it won’t happen overnight. There are still some headwinds for universal passkey adoption, including:

Device and operating system support: While Apple, Microsoft, and Android have announced support for the latest versions of their respective operating systems, it will likely take years to get all users to update to the latest OS.

Application uptake: The UX and security benefits of integrating passkey support are clear, but it still requires an application to make the updates to integrate it into their sign-up and login forms. This also requires applications to think about how it changes their user model and any relevant account recovery flows to ensure their passkey rollout is frictionless.

User uptake: While passkeys fix the remaining shortcomings in WebAuthn, users will continue to value multiple options when it comes to choosing an authentication method, and some will be hesitant to adopt a new biometric method. In the same PYMNTS and Mitek study cited earlier, researchers found that 73% of consumers reported being able to choose their preferred authentication method in an application increases their trust in the app. Moreover, 14% of users still explicitly prefer legacy authentication methods like passwords and PINs.

While it will take time and effort to weather these headwinds, passkeys present a major leap forward for passwordless technologies. Companies should incorporate passkeys into their identity and access management strategies and figure out where it fits on their roadmap. In the long-term, their customers and their IT/security teams will be grateful. At Stytch, we’re building a modern identity and access management platform, which includes support for passkeys. If you’re considering adopting passkeys, we’d love to share our learnings and help you create a strategy to roll out passkey support — get in touch to get started with Stytch today.

---


# Introducing B2B Auth School
Source: https://stytch.com/blog/intro-b2b-auth-school/

Introducing B2B Auth School, Stytch’s crash-course designed to help B2B companies’ uplevel their auth game and upmarket growth.

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs. OIDC
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider 

Entering the world of identity and authentication for B2B companies can feel a bit like taking a big slurp of acronym soup: IAM, CIAM, SSO, SAML, RBAC, ABAC, SCIM…the list goes on. To help our customers and developer community make sense of this world, Stytch is excited to launch B2B Auth School, our in-house crash-course designed to help B2B companies’ uplevel their understanding and implementation of authentication. 

In this school, we’ll cover the technologies, processes, stakeholders, regulations, and external pressures on identity and authentication, and how they inform key decisions every B2B company must face when buying (or building) the authentication stack for their product. For our first series, we’ll focus on B2B auth technologies, specifically the world of Single Sign On or SSO. 

Why start with SSO? Many B2B decision-makers know they should care about or even invest in SSO without totally understanding what it is, and what building it entails. This is obviously not because they lack smarts or industry knowledge, but rather because SSO is highly complex, and does in fact encompass several different processes, code bases, and tools. They know their customers are asking for it, but they don’t have the time or resources to dive deep into why. 

So, to help our B2B customer base, we want to devote our first installment of B2B Auth School to SSO, in the hopes we can make it easy for B2B developers and decision-makers to figure out what they need for their product, and how best to meet their customers’ demands. But first, we want to go over the bigger picture of B2B auth, including:

Defining identity and B2B auth

Why B2B auth is different from B2C

Opportunities & challenges in B2B auth today

A sneak peak at our first topic: SSO

Let’s dive in!

Identity and B2B auth

In the digital realm, identity refers to the set of traits that uniquely identify a person, machine, group, or organization. As a B2B company, to manage all these identities for your customers, you must decide:

What defines it?

How and how often do we authenticate it?

What resources does it have access to, and when?

Identities are crucial in cybersecurity because they are the bedrock of how software companies make sure the right people have access to the right resources. For B2B companies, defining and authenticating those identities looks a little different from B2C companies, specifically around who owns the identities and resources. B2C customers are individual users, sole proprietors of their identity. 

But B2B SaaS customers are companies, which means their end users are not the sole proprietors of their identity, merely stewards; they are employees, consultants, or contractors – defined members within the enterprise. What different people and devices have access to at any given moment is subject to larger business imperatives, compliance requirements, and changing roles, departments and responsibilities within a company’s (i.e. your customer’s) workforce. In short, the stakes and the complexity are higher. 

To help distinguish the unique auth challenges that face B2B companies, we at Stytch have defined B2B as its own category, namely: the authentication of members and their organizations, and all the technical, regulatory, and business challenges and opportunities that go along with that.



B2B auth vs. B2C: why it’s different

While the difference between a member and a user may seem like semantics, it actually has huge implications that make the challenge of authentication for B2B companies unique from B2C. Even if on the surface some of the auth solutions appear similar, B2B auth is distinct in its…

Scale and risk

If someone gains access to the credentials of an individual customer, the results can be devastating on a personal level, but are generally limited to the scale of that single person’s account. But if someone gains access to the credentials of an employee, the scale of damage is much bigger. This is why so many of the major cybersecurity incidents over the past few years have involved employee credentials (SolarWinds, T-Mobile, Uber). In the B2B world, a breached identity could affect millions of people.

Stakeholders

In B2B auth, there are really two levels of stakeholders that are important to keep in mind when choosing or building your solution: stakeholders within the B2B SaaS company, and stakeholders within the customer companies of the B2B SaaS company. To work well, a B2B auth solution should satisfy the requirements of a B2B customer’s IT, compliance, risk, engineering teams, and anyone else who will be using that auth flow. Those requirements exist in conjunction with the requirements B2B decision-makers have for their application, as dictated by roles like CTO, VP of Engineering, Head of Product, etc.

Provisioning, roles, & controls

According to a recent study, the average business uses upwards of +88 applications, while for large firms the number can climb as high as 200. At the enterprise level, you can imagine 50,000 employees x two devices each x 150 applications…and you get millions of vectors for attack, not to mention a lot of administrative overhead. IT admins have to manage all of these vectors, and all of the rules that determine access. Certain resources are gated by department, others by role, others by seniority or geography, and some by a combination of all these and more. As people join or leave a company, get promoted, or change teams, their access must be kept up-to-date.

Priorities

Historically, CIAM and SSO providers have not had to prioritize user experience (do a quick search for product reviews for Auth0 or Okta, and you’ll find a rather vibrant array of responses). This is because the people buying B2B auth solutions are typically not the same as the people who have to use them every day. A typical end user for B2B auth solutions (ie your average individual contributor) has very little power over what authentication solution their company uses. As a result, their UX comes after a long list of other priorities for providers. Fortunately, with newer auth providers in the space this is starting to change.

Challenges & opportunities: B2B auth today

In recent years, B2B auth has become even more critical to the overall success of B2B SaaS companies, due to five main broader trends in the technology market. Rather than thinking of these sequentially, it’s more accurate to think of these as parallel transformations that have mutually accelerated each other:

Cloud migration

Moving away from on-premise solutions and towards cloud based solutions like AWS or Azure, has accentuated the need for more sophisticated IAM. Employees need to be able to access their resources from anywhere, and on any device, all while keeping everyone else out.

SaaS economy

The increasing adoption of cloud computing has come with the rise of Software as a Service (SaaS) and API-driven services, exploding the number of providers in the B2B space. As the number of services or apps a company’s workforce uses balloons, so do the number of potential attack vectors for fraud and account takeovers.

Dispersed workforce

Long gone are the days of ID badges and on-prem computers. The COVID-19 pandemic accelerated a widespread workplace transformation. While some companies have required workers to return to the office, the overall shift feels decisive: workers increasingly have the choice to work wherever and whenever they choose. This kind of flexibility puts additional onus on IAM systems to be able to protect those identities and company resources wherever and whenever employees need them.

Regulation ramp-up

With the migration to the cloud and proliferation of services has come increased concern and lively debate over privacy, data, and access that’s manifested in a slew of increased regulation. 

Depending on geography and industry, this can be quite an extensive nexus of requirements, including things like SOC2 (Service Organization Control 2), ISO (International Organization for Standardization) 27001, HIPAA (Health Insurance Portability and Accountability Act), GDPR (General Data Protection Regulation)…the list goes on. We’ll cover some of these in more detail later in the school, but suffice it to say B2B companies have a lot of regulatory hurdles to clear, and how they handle identity and authentication is a big part of that.

Fraud & attack vectors

With each of these developments, hackers and bad actors have adapted their approach to take advantage of emerging vulnerabilities in workforce identity. Over 80% of cyberattacks exploit weak or insecure passwords. As employees’ identities are linked with an increasing number of devices and services, the potential risk increases as well (think Solar Winds). If your company works with 100 different apps and services and each of those vendors works with 100 different apps and services, the vulnerabilities multiply without strong, centralized IAM systems in place.

All of these factors have transformed B2B auth from a box that needs to be checked into a key product differentiator. At Stytch, we talk a lot about B2C auth as a growth lever: the easier companies make it for their customers to access their service, the more they can drive conversion. A similar, but perhaps more overlooked logic, holds for B2B companies: The easier you make it for your customers to manage their employees' accounts and onboarding to your application, the more likely you are to land upmarket sales and see widespread adoption.

SSO: the beating heart of B2B auth

While B2B auth includes several different technologies and protocols, in Stytch’s conversation with B2B customers no other feature comes up more than SSO. We think there are a few reasons for this:

Reduced friction: Managing the identity and auth flows for members of multiple organizations involves a near endless number of decisions and variables. SSO helps simplify both by centralizing, bundling, and automating a lot of those decisions into a single service.

Security and compliance: For many B2B decision-makers, SSO becomes shorthand for meeting a number of security and compliance requirements. You don’t have to understand them in depth to know they’re covered, so checking that box takes a chunk of those concerns off their plate.

Your customers are asking for it: As B2B companies start to sell upmarket, SSO becomes table stakes. For many B2B customers, they won’t move forward with a given SaaS product without it. If you’re serious about scale, then you need to get serious about SSO.

This last driver is the main reason we want to start with SSO: because it’s important to you, our B2B customers. It’s a complex space, and involves a lot of different decisions, so it’s worth taking the time to unpack it piece by piece, so you feel empowered when it comes to choosing your B2B auth solution. For the next several articles, we’re going to go deep on SSO: its protocols, stakeholders, benefits, risks, footguns, and even fun features. Next up: organization tenancy!

---


# Anatomy of a strong password
Source: https://stytch.com/blog/strong-passwords/

A breakdown of what does and doesn’t make a strong password, and how you can protect your users with some simple, modern tooling.

If you’ve heard of Stytch already, you likely know how we feel about passwords. But we recognize that the journey to passwordless can be long and varied. And while we do hope one day to usher the world into a passwordless future, first and foremost we want to make it easy and safe for our customers to protect their users. 

One of the easiest ways to reduce friction and improve user security is through password strength requirements. Unfortunately, to date these requirements have been poorly designed so that both users and security teams take on unnecessary stress and work. 

In this article, we’ll go over the drawbacks of the de-facto legacy password strength method. Then, we’ll look at two specific tools developers can use today to protect their users, and the basics of how to set them up.

LUDS: an ineffective and frustrating legacy

If you’ve created an account recently, chances are you saw something like what this user saw when trying to order a late night pizza:



Source 

The intention here is good. Allowing users to submit low-entropy passwords that can easily be cracked (such as “qwerty” or “abc123”) would expose both the application and user to risk of account takeover. To avoid this scenario, applications will often require users’ passwords meet certain characteristics to ensure the user sets a sufficiently secure password during account creation. As part of this step, the application will inform the user whether their chosen password is insufficient – and if so, it will often provide helpful suggestions on how to fix it (e.g. add a special symbol, a digit, etc.). 

As we can see, though, the experience is…bad. Users who are trying to accomplish a simple, non-data-sensitive task, have to randomly insert a couple of exclamation marks or extra letters that they will likely forget as soon as the za arrives at their door. What happens the next time they want a late night pizza after a few beers with friends? Likely a labyrinthine password reset flow, in which they will add different random symbols just to get that midnight pie. 

So how did we get here? 

Typically, the legacy approach of password strength estimation follows the LUDS formula (lower case, upper case, digit, symbol). When implementing the LUDS method of password strength estimation, developers may think they are doing the right thing by checking to see if the password contains all of these characteristics. Unfortunately, humans are very predictable, and we often end up with insecure passwords that satisfy these conditions but are exceedingly easy for machines to crack. There are three main flaws in the LUDS approach:

The system may allow the user to submit a password that contains all of the required characteristics, but still uses a simple pattern that can be easily cracked, such as “A1b2C3d4”.

The system may allow the user to submit a password that contains all of the required characteristics, but also contains common substitutions that are weak – such as “p@ssword.”

From a user perspective, it’s very hard to remember. Did you choose “Sp0tisagoodboy,” “sPotisag00dboy!,” or “$pOt!s@goodboy”? Who the heck can keep track!?

While password managers may help with the last issue, adoption of these tools remains low. In short, though it’s a rather easy logic for engineers to set up on the backend, the LUDS approach to checking password strength is flawed, frustrating to use, and ineffective.



Entropy: accounting for human behavior

There is a better way to assess password strength that involves using a method known as “entropy.” Entropy is the measure of randomness in an information system. When applied to passwords, entropy is a measure of the length of the password and the randomness of the characters within the password. The higher the entropy, the higher the strength, because it becomes more difficult for someone to crack the password, even when using tactics like credential stuffing. Perhaps nothing explains password entropy better than this well-known XKCD comic:



Source 

As this comic shows so well, even though "Tr0ub4dor&3" looks like a strong password, it’s actually pretty easy to guess if you have some pretty simple resources most hackers have, ie., basic computing power, a database of common passwords, and knowledge of common character substitutions. 

On the other hand, a password such as "correct horse battery staple" is much harder for computers to guess (and much easier for people to remember!). LUDS actually has a lower entropy score because it doesn’t factor in common human behaviors and patterns. LUDS assumes that all strings have equal entropy, and therefore password strength is viewed entirely as a function of the total search space. But because humans are rather predictable, this actually isn’t true. In theory it would take ~92 billion years to brute force a 16 character LUDS password, but modern password cracking approaches don’t just randomly brute force — they leverage common patterns of human behavior, which can cut that ~92 billion years crack time down to mere seconds for something like “P@ssword12345678.” 

Rather than randomly swapping letters with symbols or numbers, entropy shows that length actually makes for pretty strong passwords (all other things being equal). You can confirm this yourself with something like rumkin.com's password strength checker. Even if the individual characters are all limited to [a-z], adding just one extra letter has an exponential effect on the password’s difficulty (and the time it would take a computer to guess it). 

As a bonus, long strings of lowercase characters are also easier to type on smartphones and soft keyboards, making them even more user-friendly. If you don’t feel like doing logarithmic calculations every time your users (or you!) need to create a username and password, or you dread a potential future of 62-character passwords, don’t worry: you’re in luck! There are two great public tools that we highly recommend for helping generate strong passwords: zxcvbn and HaveIBeenPwned.

Zxcvbn

Developed in-house by Dropbox’s engineering team, zxcvbn provides a flexible strength assessment based on how resistant a password is to modern password guessing techniques. Named after the same keyboard area as “qwerty” (just two rows down), it’s designed to make picking a strong password easy for humans to generate and hard for robots to guess.

How it works

Zxcvbn works by first searching for matches to your user’s password in a list of common passwords, common names, common words, etc. If a match is found, it returns a score based on the match’s dictionary and pattern rank. If a match is not found, the library uses a set of rules to generate possible patterns, and it uses pattern recognition to score the submission. This includes things like repeating characters, sequential keyboard patterns, dates, common numbers, and so on. Because zxcvbn focuses on estimating the actual crack time of a given password, it’s a much more accurate assessment of strength than LUDS.

How to use it

If you’re looking to improve password strength estimation in your application, or if you’re simply looking to get started with zxcvbn, there are many different ways to do it. The zxcvbn library is available in a variety of programming languages, including JavaScript, Python, Go, PHP, Ruby, and more (you can also use an API like Stytch, which incorporates the zxcvbn method into our Passwords product.) 

Once zxcvbn-async is installed in your application, you can simply call into the zxcvbn function, passing in the password and an array of user input fields (e.g. username, email, etc.) that are being used in the application. The function will then return an object with a score attribute, which is a numeric representation of the password’s strength. This score will range between 0 and 4, with 0 being weakest and 4 benign strongest. While it’s most common to set the rejection level to < 1, some services like Stytch will reject anything < 3 for the sake of avoiding even moderately guessable passwords.

HaveIBeenPwned

Zxcvbn is a major upgrade to the LUDS system for determining password strength, but it still doesn’t fully solve for the human tendency to reuse passwords across different applications. That’s where a tool like HaveIBeenPwned comes in handy.

How it works

HaveIBeenPwned offers both an individual-friendly website and a developer-targeted API that both monitor the web for stolen credentials in order to alert users and companies of those credentials’ insecurity. You can search for compromised emails, phone numbers, domains, passwords, and websites, and can even sign up for email notifications to notify you if one of your accounts has been compromised. 

While you can use HaveIBeenPwned as an individual user, you can also integrate it into your product via their API, which checks whether a user’s email address or password has been exposed in a data breach. If it has, the API will return a list of the data breaches in which the user’s information was compromised.

How to use it

To use the API, you would first need to sign up for a free API key. Once you have your key, you can then make a GET request to the API, passing in the user’s email address or password as a query parameter. If the user’s information has been compromised in a data breach, the API will return a list of the data breaches in which the user’s information was compromised. 

At Stytch, we integrate directly with HaveIBeenPwned’s API, so that your users can also benefit from built-in breach detection in our Passwords product.

Secure doesn’t have to mean frustrating

Just because passwords will one day be a thing of the past doesn’t mean they have to be such a pain in the present. Tools like zxcvbn and HaveIBeenPwned offer developers some lower-lift options that won’t make their users tear their hair out when trying to sign up. 

If you’re interested in additional ways to eliminate friction from you signup or login, we’d always love to chat about how we can help simplify and streamline your auth flow.

---


# The remote dev decision: part one
Source: https://stytch.com/blog/remote-dev-1/

A look at how Stytch decided to migrate to a remote development environment: pros, cons, and the longtail payoff.

Here at Stytch, we’re focused on building great developer experiences — for our customers and our coworkers. Engineers’ time is a precious resource, and we want to do everything we can to make sure it’s spent efficiently and effectively. 

For customers, we’ve created a suite of developer-friendly auth solutions with our API and SDKs, which allow developers to experiment and compare authentication solutions easily, and get up in running in a matter of hours.

In house, we need an equally strong developer experience to deliver on continuous improvements and features. We owe a lot of our agility, responsiveness, and speed to working in a remote development environment.

But it wasn’t always that way! In this series, we’ll go over some initial challenges our engineering team faced with local development, why we moved to the cloud, and some of our favorite fixes and tools for making remote dev work as efficiently as possible.

In this first installment, we’ll go over:

What remote dev is, its pros and cons

Stytch’s challenges with local dev

The reasons we ultimately went remote

Overview: remote dev pros and cons

What is remote development?

Remote development requires moving your team’s development environment outside of your local machine. Typically, this means moving the development process into a container or virtual machine (VM) in the cloud, and having a tool to sync the code from a developer’s machine to that remote environment. From there, a developer can build and run their service without being bogged down by the limits of their local machine. 

Pros and cons

The biggest benefits of remote dev are centralization, scale, and efficiency. Remote dev centralizes tooling versioning and updates, as well as idempotent resources, so there are no surprise edge cases in individual devs’ machines. Remote dev also helps maximize developer productivity by no longer limiting engineers to RAM or CPU of their individual machines, by minimizing differences between development and production, and by creating consistent and repeatable steps for developers. 

But migrating to remote dev is not without its challenges. Many companies delay their migration to remote dev because doing so creates a lot of initial friction to the development flow and requires a lot of time and person-power to get set up. This is why it’s more common for large enterprises like Google and GitHub to operate in a remote environment, but less common for startups like Stytch. For many, the up front costs are too great to justify when a company is getting off the ground. 

We can think of the tradeoff between local dev and remote dev as a function of two variables: the size of your team and the size of your software services. As both of those sizes increase, the scale tips towards remote dev as the more productive way to develop.



Early days: local and friction-filled

In the first few months of Stytch’s life, we had one goal and one goal only: ship. A couple months after we launched our first product Email Magic Links, we took a step back to evaluate our development cycle. We wanted to take a strategic stance on what kind of developer experience we wanted to build in-house, and what we needed to meet our goals of becoming a preferred auth provider on the market.

Some things were apparent from the outset, just from roadblocks we’d hit in our day-to-day flow.

For example, doing something as simple as editing our email template in our dashboard required running every service. This turned what would optimally be small tasks into time and resource intensive undertakings. And when we did ship features, we couldn’t guarantee that the development process was consistent. We even shipped a bug very early on because an engineer was writing a feature in the API with Redis disabled on their local machine. Local development was starting to slow us down. 

Before we took on our first customers, we wanted to minimize delays and mishaps like this as much as possible. As we looked at the bigger picture, we identified five main productivity drags in our dev environment we wanted to address:

Too many services: We had to run six different terminal windows and two databases to develop our dashboard and any example applications. 

Extra context, wasted time: The frontend team needed to understand how to run our backend code, and the backend team to understand the frontend code. That meant a lot of extra work on both sides. 

Time- and people-intensive: There was a fifteen-step process to set up the dashboard, and any changes to the process required coordinating with the other team members. The process would take over an hour to set up and required insider knowledge. New engineers needed context on code bases that they didn’t need to edit. 

Local configs vs. production configs: Some features were developed with different configuration than production, often causing issues even when they worked locally.

Hard to actually test: Testing across services was challenging as the team would need to make sure all the versions of the different services were aligned. 

With these five factors in mind, we set to work defining our ideal development environment.



What we needed

To meet our goals of scale and deployment speed, we had clear specifications for what we needed from our development environment. It needed to:

Allow engineers to update, upgrade, or experiment without disrupting other engineers or workflows or requiring extra work or syncing to avoid shipping bugs. 

Centralize tool versioning and updates: No more worrying about or managing weird edge cases in a lone engineer’s machine. 

Seamless transition between development and production: Because most local development is done with http (but we use https in production), any feature work related to domains like cookie and local storage was needlessly challenging. We wanted to minimize that challenge so we could get to production as easily as possible. 

Offer robust processing power: Stytch quickly grew from requiring six microservices to run to eight, in addition to two databases. To run and make changes to all of those and test end-to-end, we needed more raw computing power than we could milk from our local machines. 

Easy to test: “Fail fast” is one of our core values at Stytch, but to fail fast you need to be able to test end-to-end rapidly. We never wanted to hear the phrase “Well it worked on my machine” ever again

With these requirements, we first considered improving our local development environment, to defer the leap to the cloud. We saw three options:

Run all the services in Docker on our developer’s machines. This reduced the work to run the services, but didn’t solve for load or keeping all our engineers’ work in sync.

Have the service in development hit our staging environment for other environments. This simplified development, but complicated our staging environment’s data and made it difficult to test a service connected to a local machine. 

Mock out the endpoints for other services. While this is a common approach, we ran into problems where the system worked for a mock, but the real service returned different data.

In the end, we realized we needed to move ALL development into the cloud to meet our full requirements. Whatever initial set-up or resourcing might be required up front, we felt it was well worth it. Especially when we saw other startups who had deferred the decision and paid for it, we wanted to save ourselves those kinds of headaches down the road.

Today, we couldn’t be happier with our decision. But there were some fun challenges along the way we needed to solve in order to make sure remote dev at Stytch could reach its full potential.

Namely:

Scheduling all the different microservices and making them easily discoverable

Replacing a remote service with a local version for development

Load balancing and routing traffic through DNS records

Enabling consistency in developer tools and configs

Creating valid certificates for HTTPS

Automating the provisioning and syncing of new environments

Provisioning external cloud resources from AWS to use during development

Fostering a culture that rewards developer productivity and innovation

In the rest of this series, we’ll tackle each of these challenges one by one, breaking down each challenge and the steps required to fix them.

If tackling problems like this interests you, check out our career page!

---


# What is CAPTCHA, and how does it work?
Source: https://stytch.com/blog/what-is-captcha/

Learn how CAPTCHAs differentiate between real web users and bots — and how you can optimize them to protect your app.

CAPTCHA flows have long provided an essential security tool for developers as they work to protect their platforms and users from cyber attacks. Specifically, modern CAPTCHAs can help apps and websites tell the difference between the good, human users they want to let in and the bad, non-human users (namely, bots) they want to keep out.

In this guide, we explain exactly what CAPTCHA is, how it works, and how modern authentication providers are adapting the CAPTCHA system to keep up with evolving cyber threats — and stop malevolent bots in their tracks.

What is a CAPTCHA?

CAPTCHA stands for Completely Automated Public Turing Test to Tell Computers and Humans Apart. At the most basic level, a CAPTCHA is a computer-generated security flow meant to distinguish real users from automated web traffic like bots. It’s a form of challenge-response authentication, where a user must answer a question or solve a puzzle in order to be verified and gain access to an online account.

The “Turing” in CAPTCHA refers to Alan Turing, a renowned computer scientist and mathematician who, among other achievements, devised tests that could differentiate between the behavior of human beings and that of artificial intelligence (AI). CAPTCHA challenges are based on this work. They’re designed to elicit the kinds of sensory and cognitive responses that non-human bots could never reproduce.

How does CAPTCHA technology work?

Bots are programmed to carry out specific, repetitive tasks within a narrowly defined scope. For example, they might be set up to identify common customer questions and provide automated answers in an ecommerce chatbox or to comb the internet for the lowest price on a given product.

Simply put, bots cannot “think” or “feel” in any human sense. While AI has come a long way, resulting in sophisticated bots that can process complex images and sounds, those crawling the internet with malicious intent generally aren’t built with these abilities. Their pre-programmed nature prevents them from being able to spontaneously react to or reason through the sorts of challenges presented in a CAPTCHA flow.

In short, a CAPTCHA works by presenting these bots with a test or challenge that human users can solve, but bots cannot.

Let’s take a closer look at what such challenges involve.

Types of CAPTCHAs

CAPTCHA tests can take many different forms. Some of the most common challenges include:

Text-based CAPTCHAs: Users are asked to type a word or a series of letters presented to them as distorted text. This distorted text may and numbers written in a squiggly or strikethrough font or displayed against a grainy background. The idea is that web-crawling bots cannot “read” or recognize these figures among the visual noise.

Image-recognition CAPTCHAs: Users are presented with an array of images and asked to pick out familiar objects like fire hydrants, crosswalks, or trains. Since automated bots cannot understand the concept of a crosswalk or train or what it references in the real world, they are unable to match the prompt to related pictures.

Audio-based CAPTCHAs: Users type in a word, sequence, or phrase spoken by a muddled or distorted voice. The idea is that crawler bots cannot “listen” to distinguish between and interpret competing sounds. This can also be a good alternative CAPTCHA test for visually impaired users.

Question-based CAPTCHAs: Users must solve a simple math or word problem that is intended to test comprehension, rather than outright intelligence.

Why these challenges work

While an automated, web-crawling bot could theoretically be engineered to exhibit or mimic these capabilities, it would be an incredibly difficult, time-consuming, and expensive undertaking for a hacker. What’s more, a CAPTCHA test cannot be reused once it’s solved. That means, even if a bot does correctly decipher a CAPTCHA puzzle, it has to repeat the process thousands of times to be effective, neutralizing the speed and automation that makes bots so attractive in the first place.

CAPTCHAs have been around for a while, first used and distributed commercially in the early 2000s. Since then, they’ve undergone a few adjustments and advancements — most notably, in the form of reCAPTCHAs.



What is a reCAPTCHA (or Google reCAPTCHA)?

Computer scientist Luis von Ahn, part of the original team that invented the CAPTCHA system, grew increasingly concerned with how much time internet users were spending on CAPTCHA puzzles. In response, he developed reCAPTCHA, which was ultimately sold to Google in 2009.

At first, reCAPTCHA tests were intended to make CAPTCHA efforts more productive — for example, to assist with the digitization of books and other printed texts. To that end, instead of the random words and characters used in text-based traditional CAPTCHAs, reCAPTCHAs use actual printed words and phrases that book-scanning computers are having trouble recognizing.

In a reCAPTCHA, a user types in these words just as they would in a CAPTCHA challenge, simultaneously verifying their humanity and identifying the letters in an unidentified word. Typically, a reCAPTCHA features two words side by side, one known and one unknown to the system. The known word serves as a screen to ensure accuracy, while the unknown word is passed to many different users to be solved — so they’re ultimately working together to confirm its identity.

Over time, however, and with advances in optical character recognition (OCR) technology, reCAPTCHAs have become more focused on limiting levels of friction in the user experience.

For instance, Google rolled out what they call “noCAPTCHA reCAPTCHAs,” where users can prove they’re human without having to solve a CAPTCHA puzzle at all. The most common version involves a checkbox that allows users to confirm they’re not a robot with a single click.

Behind the scenes, the checkbox flow is actually analyzing the user’s IP address, plugins, browser history, behaviors (including actions like type rates, mouse clicks, and scrolls), and more to confirm that they’re not a bot.

More recently, Google further streamlined the verification process by removing challenges and checkboxes altogether. With invisible reCAPTCHAs, legitimate users are able to access their accounts without any disruption, while suspicious users and bots will still face a CAPTCHA or reCAPTCHA test.

Why are CAPTCHAs important?

Today, humans make up less than 40% of all internet traffic. The remaining 60%+ is bots. And while bots can be used benevolently — as in the ecommerce examples above — there are also malicious bots used by hackers to automate and amplify their cyber attacks. In fact, some studies estimate that more than half of the bots currently working online (representing about 39% of all web activity) are employed maliciously.

This can have disastrous consequences for individuals and businesses alike. For example, hackers can use bots to crawl the web, intercept users’ passwords, and take over their bank accounts in credential stuffing attacks. Hackers can also mobilize bots to, say, buy out concert tickets and resell them at inflated prices on the secondary market.

Given the prevalence of bots and the risks they can pose to legitimate users and organizations, it’s not surprising that users are often asked to prove their personhood when they want to access sensitive online accounts.

The problems with CAPTCHA

On the surface, CAPTCHA tools have a lot going for them. They’re relatively simple for users to solve, and they’re easily scalable. For sites and apps that are processing thousands (if not millions) of authentication attempts, computer-generated CAPTCHA tests offer a quick and affordable way for developers to weed out bots from user traffic.

But the CAPTCHA system also has its downsides. First of all, since it requires users to complete a specific action, it introduces substantial friction to sign up and login flows, potentially driving heightened rates of dropoff and churn.

More concerningly, CAPTCHA and reCAPTCHA challenges aren’t foolproof from a security standpoint. For one thing, it seems AI has been able to solve basic CAPTCHA tests for years. What’s more, an entire cottage industry of human-based fraud has emerged that enables hackers (and their bots) to clear CAPTCHA puzzles and breach users’ accounts. We’ll cover that next.

Understanding CAPTCHA fraud

Unfortunately, hackers have found a convenient and reliable loophole in the CAPTCHA system. It stems from a critical design flaw in the public key architecture, or the code used to encrypt backend data.

Basically, every major CAPTCHA system exposes its public key in the webpage source code. That means bots (and the hackers behind them) can easily scrape the site key value and submit it to a third party to be solved.

Dozens, if not hundreds or thousands, of CAPTCHA-solving-as-a-service companies — also known as CAPTCHA farms — employ low-paid workers around the world to manually solve CAPTCHA challenges one by one. Ultimately, they supply bots and hackers (their clients) with all the information they need to bypass the CAPTCHA system and gain access to users’ accounts.

These fraudulent tactics work because CAPTCHAs can be solved remotely. In other words, a CAPTCHA flow doesn’t require whoever is solving the puzzle to be working in the same browser that’s used to submit the solution.

Worst of all, CAPTCHA farm sites look and feel a lot like legitimate SaaS platforms, so it can be tough to tell the difference. In fact, they operate similarly to SaaS platforms using specialized APIs.

Let’s dive deeper into how CAPTCHA fraud typically plays out:

1. A bot scrapes the public site key from a CAPTCHA challenge and sends it to a CAPTCHA farm.

A CAPTCHA farm really only needs two parameters to solve a CAPTCHA challenge: the related web page’s URL and its public site key value. Since CAPTCHA systems publicly expose their site keys in the source code, it’s easy for bots to scrape the value and submit it along with the URL to a CAPTCHA farm’s API to kick off an account breach.

2. A human worker at the CAPTCHA farm solves the CAPTCHA challenge.

Any worker at the CAPTCHA farm can then use the URL and site key value sent by the bot to load and solve the CAPTCHA puzzle. From there, they receive a response code (also known as a g-captcha-response), which appears as a string of code. This lets their bot/hacker client know that the CAPTCHA challenge has been solved.

3. The bot uses the CAPTCHA response code to solve the puzzle and breach the user’s account.

Finally, the CAPTCHA farm sends the g-captcha-response to the bot, which uses it to solve the CAPTCHA challenge. Since the bot has a code representing the correct solution, the CAPTCHA system recognizes it as human and grants it access.

How can developers fight CAPTCHA fraud?

With such vulnerable public-key architecture at its core, many developers wonder how they can improve on the CAPTCHA system to outsmart hackers, bots, and CAPTCHA farms and bolster their app’s security.

Some companies — like the crypto exchange platform Binance — have taken on substantial costs and workloads to avoid traditional CAPTCHA design flaws by building their own, customized CAPTCHA flows in-house.

But thanks to modern authentication strategies, development teams don’t have to invest nearly that amount of time, effort, and resources to fortify their flow and strike an effective balance between security, efficiency, and scalability. In fact, the best auth providers on the market today remove CAPTCHA security loopholes through easy-to-use, turnkey products.

Introducing Strong CAPTCHA

Solutions like Stytch’s Strong CAPTCHA puzzles eliminate the public-key problem by removing the public key altogether from client-side browser environments — leaving bots with nothing to scrape and send to a CAPTCHA farm.

Strong CAPTCHA is image-based and can be added via API or SDK to any auth flow in a matter of hours, and they work with any web-based or native mobile platform. Meanwhile, the end user’s journey and experience remains the same. Users encounter the same simple CAPTCHA puzzles they’re already familiar with, just without the standard-issue risks and vulnerabilities.

The bottom line

Conventional CAPTCHA flows can play a fundamental role in app security and form part of a robust authentication strategy — but they’re far from bulletproof. Not only have bots learned to solve basic CAPTCHA challenges outright, but proliferating CAPTCHA farms have also established viable, human-based fraud vectors that can outmaneuver the CAPTCHA system.

That’s where innovative solutions like Stytch’s Strong CAPTCHA come in. With such tech-forward auth tools, developers can avoid the design and security flaws that have historically put CAPTCHAs at risk — and cut hackers and fraudsters off at the roots.

---


# Organization tenancy: the foundation of SSO and B2B data models
Source: https://stytch.com/blog/organization-tenancy/

In lesson two of B2B Auth School we dive deep into organization tenancy: the foundation of single sign-on and B2B SaaS data models.

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of authentication technologies. Our first series of posts is dedicated to Single Sign On (SSO). This article is lesson two in that series. 

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs. OIDC
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider 

In our previous lesson, we introduced you to the wide world of B2B auth. We established the big picture: B2B auth’s challenges, its value adds, and its key differences from B2C auth. Most importantly, we explained why SSO is B2B auth’s most requested feature and thus the topic of this series. 

If you recall, we defined the term B2B auth as the authentication of members and their organizations. Members, instead of individual users, change the whole paradigm of authentication because they come in groups. This change requires a new way of designing and building auth flows in applications. 

But to talk about SSO, we have to start with the foundation and building blocks upon which B2B SaaS technologies are built. Specifically, we need to talk about organization tenancy – or org tenancy for short. In this post we’ll go over:

Defining org tenancy

The features of org tenancy

Building org tenancy and authentication

How org tenancy unlocks SSO

Is org tenancy the same as multi-tenancy?

Multi-tenancy is the architecture characterized by multiple parties sharing the same resources. The tenants in multi-tenancy can be a wide variety of entities: customers, groups, applications, databases, containers, microservices, or workers. Nearly all SaaS applications implement multi-tenancy in some shape or form. 

Org tenancy is a type of multi-tenancy. The tenants are organizations stored in a shared data model as top level entities. Org tenancy focuses and zooms in on the B2B aspect of representing complex organizations like companies as individual customers.

Org tenancy and its elements

Org tenancy is the software architecture that governs multiple organizations within a single application. In other words, org tenancy is the design system that lets organizations coexist together within an application. It helps separate and coordinate resources. Like tenants or residents of a building, each organization uses the application without having to worry about its neighbors because org tenancy provides the walls, hallways, doors, and locks to achieve orderly separation. You may have noticed: the word “organization” is always brought up and emphasized. 

By name and design, org tenancy considers organizations as the primary unit of business data; the organization is a first-class entity. In an org tenancy model, the application will always scope an end user’s data and functions to their organization. In more practical B2B terms, we can say: the organization is the customer. Let’s break down the org tenancy model into its elements:

An organization is a grouping or collection of members, resources, settings, and other attributes that can be changed and updated. An organization could have thousands of members or just a few. In B2B auth, an organization (i.e. your customer) is typically a company.

A member is an end user with membership in an organization. Memberships resemble user profiles with attributes like email, username, phone number, role, title, etc. In B2B auth, a member is typically an employee of a company. It is a sub-entity of an organization.

The relationship between members and their organizations is fundamental to the org tenancy model. It dictates the logic and boundaries of the system. For example, like separate apartments, one organization should not be able to access the data of another organization. The application’s structure and features determine how complex or simple these rules and relationships will be.

B2B customers think, speak, and operate in terms of organizations. Org tenancy architecture equips B2B SaaS applications to codify that ideology into the data structure itself.



Features of org tenancy

If you’re a B2B company, you’re dealing with organizations all the time. Your customers are other companies – which are complex organizations by definition. So if you want more than one customer, you need an org tenancy model that will enable your customers to…

Represent the whole enterprise: The entire company should be treated as a single customer. Imagine how impractical it would be if you have to bill every single employee of a company separately for using your application. By grouping everyone into an organization, there’s one invoice for one customer. Remember, the organization is a first-class data entity. In org tenancy, we think primarily at the organizational level.

Manage memberships: A large company could have tens of thousands of employees. To take it further, they might also have a fleet of contractors and consultants that multiply the scale of their workforce. To avoid a huge operational headache, organizations need to be able to control access. An application with org tenancy needs to expose strong tools and definitions for granting and revoking memberships.

Customize and configure settings: A company should have their own preferred settings when using a B2B SaaS application. These settings need to be defined at the organizational level, so all their members will inherit and adhere to them. For example, many companies require that members are only able to invite end users with a specific email domain (@myfakecompany.com) to join the organization.

Structure teams and roles: Companies are composed of several departments (IT, engineering, product, analysts, sales, support, etc.) and several types of members (admins, editors, readers, etc.). Every organization will have a unique team structure and set of roles that compose its internal business-specific operations, and need to be stored somewhere in the application’s data model. This leads to more advanced topics like role-based access control (RBAC) which we’ll cover in future posts.

These requirements are considered table stakes by most B2B customers. If a B2B company doesn’t offer org tenancy, the customer has to deal with the fallout; the customer will need to use their own internal systems and tools to create ad-hoc solutions that can group together all of their employees’ user accounts – essentially replicating org tenancy logic on their end. A B2B company not supporting org tenancy puts a huge onus on customers they won’t be interested in taking on. It's a must-have when companies are purchasing B2B SaaS applications.



Building org tenancy and authentication

Now that we understand org tenancy’s importance, let’s talk about the build process. By itself, org tenancy architecture is a lot to construct. When adding authentication on top of that, the challenges start to stack. Here are the key considerations when building org tenancy:

Security and isolation

One of the worst possible things that could happen to a B2B company is data leaking between customers. To prevent this, you need really strong controls to guarantee that the data is scoped to the individual tenant. In SaaS applications, shared resources like databases, microservices, and memory need to be thoroughly tested and vetted for isolation. This is arguably org tenancy’s greatest responsibility and requirement. It’s a matter of security.

Data modeling and design

Unfortunately, there is no exact recipe to define the data model for org tenancy. Every B2B SaaS application must define their own schema to support its features and auth flows. The data model can change drastically depending on what use cases the application supports. When defining the data entities and their relationships, consider these questions: Can end users be members of multiple organizations? Are membership records tied to user records? What structure does the metadata need to be stored in? Can organizations have sub-organizations? And so on.

Org discovery

When an end user logs in to your B2B SaaS application, how do you know which organization they’re authenticating to? It’s a problem of discovery: how to find and identify the right organization based on a login. There are multiple strategies that sit on a spectrum of user friendliness. For a more seamless experience, a B2B SaaS application could attempt to automatically discover the organization from an end user’s membership attributes like email or username. On the other hand, they could require the end user to specify the organization before they can even attempt to log in (this is more thorough, but puts a bigger burden on the end user).

Auth settings

Authentication has many different features and behaviors. Each company may require their own unique combination of these properties for their auth flows. To support that variety, you’ll need to build controls that enable organizations to customize or configure their auth settings. You’ll then need to scope those auth settings to either the organization or member level. The common and fundamental authentication features you should consider supporting are:  

Just-in-Time (JIT) provisioning: the immediate creation and hydration of user accounts upon a successful login.

Allowed domains: an approved list of domains that end users must have in order to be a member.

Auth methods: an approved list of authentication methods (Email Magic Links, Passwords, OTP, etc.) that members can use for login.

Invites: the ability to allow members to invite non-members to join the organization.

MFA: the enforcement of multi-factor authentication for login.

The foundation of SSO

The biggest benefit to building org tenancy is that it lays the foundation for SSO. But how? Well, they are inherently linked; SSO is also directly tied to the concept of an organization as a first-class entity. In fact, its authentication scheme relies on the org tenancy data model (organizations, members, and their relationships) to function.



Org tenancy is a prerequisite because it unlocks the ability for:

Companies to securely manage their whole organization through a single interface.

Employees to have their accounts conveniently linked together.

SSO auth flows to have a single point of access for the organization.

To build SSO, the standard B2B auth experience for your customers, you first need org tenancy to coordinate organizations, members, and their relationships to all work together in concert within your application. For our next lesson, we’ll cover SSO! See you then.

---


# What is single sign on (SSO) and how does it work?
Source: https://stytch.com/blog/single-sign-on-sso/

Single sign on (SSO) allows members of an organization to access all their apps and services with one set of auth credentials.

Previously in B2B Auth School, we went over org tenancy, and why it’s a must-have for any B2B SaaS company.

In this lesson, we’ll look at the main feature driving demand for B2B auth: single sign on.

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on (SSO), and how does it work?
Lesson four | SSO protocols: SAML vs. OIDC
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider

In this blog post, we’ll go over:

What is single sign on?

The benefits of single sign on

How it works

Why it’s so important for B2B companies

Common mistakes to avoid when implementing

What is SSO?

Single sign on (SSO) is the process of allowing end users to securely authenticate to multiple applications based on their authenticated identity on another application.

In other words, SSO allows login to your app by proxy – the user signs in to a different app, that you trust to vouch for the user’s identity. You never store login credentials, but they can still securely login. Magic!

Security benefits of SSO

The main security benefit of leveraging an SSO solution for both you and your end users is that it eliminates the need for a distinct set of user credentials on each application.

For end users, SSO means security with ease. Because single sign on protects access to multiple cloud applications without the need to remember multiple passwords, it helps reduce password fatigue (and subsequent password reuse). Instead, user identities are proven through another application – ideally one where they actually use a unique, strong password and additional security measures like multi-factor authentication.

For you the app developer, it helps mitigate security risks by storing fewer potentially reused user passwords that could be exploited on your application via a credential stuffing attack.

How does single sign on work?

There are several different flavors of SSO solutions, depending on both the protocol chosen and the use case involved – but before we get into the details of the different protocol options, let’s review the basic commonalities of how all single sign on transactions work.

Every SSO process involves two parties:

Service Provider (SP): the application the user is trying to access

Identity Provider (IdP): the application that manages the user’s identity and is responsible for authenticating them

Prior to being able to enable single sign on, the Service Provider will need to register with the Identity Provider – establishing a way for both parties to securely identify one another, and ensure that the requests aren’t coming from a malicious actor.

Once the registration is complete, a basic Single Sign-On flow involves the following steps:



1. End user opts for SSO

For SSO to happen, the end user needs to be on the SP and indicate in some way that they wish to authenticate via a specific IdP

2. The SP redirects the user’s browser to the IdP

This redirect contains specific authentication request content that tells the Identity Provider what SP you came from, what information to send the SP, and where to redirect you back to upon success.

3. Enter user credentials

If the user is not already in an authenticated state, they will be prompted to provide their login credentials for the IdP.

4. The IdP redirects the user’s browser back to the SP

Once the user logs in and the IdP has validated the user credentials, the IdP will redirect the user back to the SP, typically with an authentication token. This redirect will contain some sort of information that the SP can then use to validate the response from the IdP, according to some set of trusted rules that are pre-configured.

5. Access = granted

Once redirected, the end user is now in an authenticated state on the SP.

The core basics of this flow remain largely the same regardless of the protocol chosen – but depending on protocol there are some differences in data type, format, and authentication mechanisms that allow the parties to securely identify one another and ensure this is a valid request. The primary protocols used in SSO solutions today are OpenID Connect (OIDC) or SAML (Security Assertion Markup Language).

SSO vs. OAuth



The SSO flow described above probably seems pretty familiar to you if you’ve ever done (or implemented) ‘Sign-in with Google.’ And for good reason: it’s a form of single sign-on facilitated via the OAuth/OIDC protocol, and most commonly referred to as ‘OAuth.’

OAuth is a type of SSO, but not all SSO is OAuth

So yes, the OAuth flows you’re familiar with count as single sign-on, and it’s an excellent login option to add to your B2B application. It improves security by eliminating the risk of reused user credentials, and reduces the support burden associated with forgotten passwords and password resets. In particular, email provider OAuth (such as Google or Microsoft) has the added benefit of providing a strong guarantee that the user has real time access to their corporate email account, which offers a stronger signal that the end user is still a part of the organization they are trying to access than password based login.

However, OAuth isn’t what your enterprise customers are talking about when they ask if you offer SSO authentication.

How SSO solutions are different in B2B

Relieving IT admin

Imagine you have 500 employees, who each need access to ~20 different applications to do their jobs. That’s 10k different accounts. When you onboard even five people, that’s 100 new app-specific invites you need to send. Every time an employee leaves, you need to frantically identify all the apps they used, and revoke the user’s access as quickly as possible. As you can see, this is an absolute nightmare from both a security and time perspective.

Instead, enterprise companies use a “workforce Identity Provider” which is a company-specific IdP instance that serves as a centralized source of truth on all employees’ identities and the applications they can access. Their employees will authenticate to these applications via a custom Single Sign-On setup (often referred to as an Enterprise Connection, or SSO Connection) that directs to the company’s specific workforce IdP instance. A successful response from the workforce IdP confirms both the user’s identity, and that they have been granted access to the SP.

This centralized source of truth on employee identity information and access, makes it possible for your customer’s IT Admin to quickly and efficiently make changes to profile information, user access and easily do user access auditing through this workforce IdP. Most Identity Providers also offer ways for IT Admins to group employees based on department or seniority to make application assignment, or Role assignment within those applications, even easier.



Element of Authorization

The main distinction between SSO done through GitHub or Google OAuth and enterprise SSO comes down to whether or not the Identity Provider provides some element of authorization.

Normal Google OAuth will verify my identity – but it doesn’t have any concept of whether it’s the right email to use, or if I should be able to access the SP. On the other hand, if my company sets up an Enterprise SSO Connection via Google Workspace (a workforce IdP), then the SP will redirect to my company’s specific Google Workspace instance where I must prove that I have credentials to access an @stytch.com account. Once I have successfully authenticated, the IdP will verify that I have been granted permission to access that specific application, before deciding whether or not to redirect me back to the SP to successfully complete the SSO flow.

Mistakes to avoid when implementing single sign-on



Before you start digging into the weeds of how to implement a SAML or OIDC SSO solution, there’s a few gotchas that you’ll want to be aware of before starting on solution design.

“Smart” detections of the redirect URL

The first step in an SSO flow is that the SP redirects the end user to the IdP. In OAuth, the redirect URL for the IdP is the same for all users – but in “enterprise SSO” this URL is different for each individual SSO connection, and your application needs a way to determine what redirect URL to use.

One common solution to this problem is to create a mapping between email domain and tenant/organization or SSO Connection, and then have your initial login form just be an email input. If the end user enters an email that is tied to an SSO Connection, you automatically redirect them to the appropriate SSO URL. If the email domain isn’t mapped to an SSO Connection, you show them the standard login options such as OAuth or email and password.

This flow has two issues:

1. Automatic redirect assumes that a given corporate email domain will only ever need to access a single organization or SSO Connection.

This assumption is not correct at scale – as large companies often need to subdivide their employees into different tenants – either within the SP (your app) or the IdP – for a range of reasons: access management, corporate structure, moving IdP providers, etc.

2. Surfacing information about the user’s membership without first authenticating opens up an account enumeration vector.

If you do this discovery based exclusively on the email address, without first requiring authentication, malicious actors can exploit this flow to learn information about your end users and customers

To ensure your SSO implementation is future proof you should make sure to:

Design your data model to account for tenants having multiple SSO connections, and email domains (and specific email addresses) to belong to multiple tenants.

Offer tenant-specific login pages (e.g. megacorp.your-app.com or your-app.com/megacorp) so that you can identify on page load which tenant the end user is trying to login to and surface all available SSO connections for that specific tenant.

No Backdoor Access

Once a customer has set up an SSO Connection to their workforce IdP, they will want to enforce that all users login via SSO. However, SSO Connections can be brittle, and require maintenance – such as adjusting Attribute Value mapping or rotating the shared secret used to do verification.

If your application makes the assumption that this login method enforcement is all or nothing, it will be impossible for your customer to make necessary updates to the SSO configuration without suddenly allowing all of their employees to authenticate through less secure login methods.

Instead, you should make sure to introduce the concept of a “breakglass” role or permission to bypass the login method requirement, allowing companies to grant to specific users the ability to login through other non-SSO methods if needed.

Not accounting for different IdPs or protocols

Most companies build an SSO solution when they land their first enterprise customer who requires it – and that customer will already have their workforce IdP and their preferred authentication protocol of choice (unfortunately it is almost always SAML).

But the more B2B customers you take on, the more variation you will find in their SSO requirements. SAML is the more common protocol, but OIDC is gaining traction with younger companies every day. And there is a wide range of IdPs to choose from – your best bet is to set yourself up in a way that you’re ready to work with at least the major IdPs.

Trusting the IdP too much

If your application allows a single email to have a membership to multiple organizations (which it should, but that’s another topic) you might assume that a successful authentication via a specific SSO connection is sufficient to log the user into all of the organizations they belong to under the returned email address. After all, your enterprise customers are adamant that SSO login is the most secure option!

Not so fast. Workforce IdPs might offer strong guarantees of the user’s identity within their own system – but there’s no guarantees around whether or not the returned email address was verified. There’s no reason your other customers should trust the identity information coming from the black box that is another company’s IdP, and as such SSO authentication should only ever issue a session for the specific Organization that the SSO Connection is scoped to.

Building it yourself

Sorry, shameless plug – but if you want to avoid all of this, just use Stytch and we take care of the headaches for you. Our B2B auth solution is built to flex with you as you scale and take on customers with more complex enterprise requirements – without requiring extra build time on your part.

If you want to read more about the details of implementing SSO before making your decision, check out our blogs covering the implementation details of SAML and OIDC.

---


# Engineering the engineering team
Source: https://stytch.com/blog/engineering-the-engineering-team/

On stage at Slush with Otto Hilska, Julianna Lamb, Stytch co-founder and CTO, unpacks the toolbox for building and leading engineering teams.

In November 2022, Stytch co-founder and CTO Julianna Lamb joined Otto Hilska, co-founder and CEO of Swarmia on stage at Slush in Helsinki to discuss Engineering the Engineering Team and how to effectively build and lead engineering teams, from startup to scale. Below is the transcript of their conversation, edited for clarity and readability. Watch the full conversation on YouTube, or read the transcript. 

Otto:

Welcome, welcome to the founders stage. My name is Otto, co-founder and CEO of Swarmia and for the next 25 minutes we're going to be talking about “Engineering the Engineering Team.” Our guest, Julianna Lamb, is a very impressive first time founder of Stytch who's recently raised money, became a unicorn and scaled into the CTO role while the company is growing. So glad to have you here!

Julianna:

Awesome, I'm excited to be here. To kick things off I just want to give a little bit on my background and how we ended up starting Stytch: My co-founder and I both worked together at Plaid – I was on the engineering team there and he was on the product team. We both worked on a lot of problems related to fraud and authentication when we were building out Plaid's features. But when we went to the market to look at vendors that we might be able to use to help solve some of these problems, we didn't find anything that we really liked. We were frustrated that we were having to build authentication ourselves, because it’s not a super differentiated feature – every company out there with login needs authentication. After building all of these things in-house, we thought it was crazy that nobody had built a really developer-friendly product that makes it easy to embed different authentication experiences, from passwordless authentication all the way to passwords and more traditional forms of authentication, and do so in a flexible, customizable way that enables great user experience. So that was the genesis of Stytch: that conversation happened about three years ago and it's pretty wild to see how far we've come in that time.

Otto:

Thanks for that context. Can you give people a little bit more context at what stage you are at, in terms of people, products, customers at the moment?

Julianna:

We’re a Series B company. We’ve raised about $125 million to date. Our team is about 70 people and a little over half of that is still on the engineering, product and design side of the house. We've supported thousands of developers building on the platform and have about a dozen different authentication methods that you can pick and choose from to build the experience that works for your use case, your users, etc.

Otto:

That's great. We're going to be talking about the journey of a CTO as a startup and how it is evolving, as well as building a team, onboarding them and managing them. Being a founding CTO is a pretty special role because in the beginning you have nothing, and then the role shifts very rapidly as the team grows and the business grows. But really the first job usually is to build the first product that gets to some kind of a product market fit. What did that journey look like for you?

Julianna:

At first, we were just exploring the idea of starting this company. I spent some time building what I would call a very rough proof of concept of what this product could look like. I designed some of the API endpoints and spun that up pretty quickly. But after we raised our seed round, it became clear that what we were doing here was building a company, not just hacking on a side project. From there, my focus shifted pretty quickly to recruiting and building the engineering team, and enabling them to go and build the product. I think there's still some of my code that runs in production but not very much of it anymore.

Otto:

Right. You mentioned your co-founder and you worked together previously – how did you work together and start leading the company together? How did you divide the responsibilities, and do you have any tips for working with a co-founder? That's another important aspect of an early stage startup.

Julianna:

My co-founder and I have pretty complementary backgrounds and skill sets. Where we do have overlap is product. But my background is all in software engineering, and then I was a product manager for a little bit before we started Stytch. My co-founder worked on the go-to-market team at Plaid before joining the product team there so it was it was a pretty clean split in terms of how we thought about dividing up responsibilities. He oversees all of Go-to-Market and Ops, and I oversee engineering, product, and design. I would say we spend the bulk of our time together talking about product and product strategy – that's where we really enjoy getting into the weeds, brainstorming. etc. I think it's been really beneficial to have fairly clear roles and responsibilities in terms of the teams that we manage and what we oversee. And as a very product-driven company, the fact that product is what gets us both excited I think is a really good unifying factor that helps us build together.

Otto:

The main topic here is the “engineering engineering team” – building a team. Do you have some kind of philosophy behind your team building, something that you're specifically looking for? How do you approach the whole thing?

Julianna:

The way that we articulate what we look for in people we bring onto the team is by two hiring values.The reason that we think it's important to have hiring values as you're interviewing candidates and evaluating their fit is that we want people to be able to have a lot of freedom when they join to go and tackle the problems in front of them. We want them to be able to think creatively and have a lot of ownership over the work that they're doing, and that requires a really high degree of trust in the people on your team. For that reason, we're pretty rigorous with our interview process, both from the technical side but also from the motivational side –we want to know what it is that gets this person going, what excites them and what kind of problems they like to work on. Our two hiring values are that we look for people who are ambitious and empathetic. We think that's a really fun combination to work with – they're excited to think about the big lofty goals that we have here at Stytch and how we can achieve them but they're also really good teammates that are going to help make everyone better throughout the process. It’s a nice way to find a balance in the type of personalities.

Otto:

Hiring at the very early days is maybe a bit different than it is at a later stage of a company. What's your guidance on the very early hires for your engineering teams – what makes a great hire?

Julianna:

In the early days my co-founder and I did all the interviews. I would do coding interviews and then architecture interviews and then he would do some of the more soft skills interviews. Beyond establishing clear roles for each of us during the process, in the early days we also leaned pretty hard into using references as part of the hiring process, which I think is sometimes not super common, especially with engineers in the Bay Area. We got really good advice early on that references help you visualize what it will be like to work with someone, which can be hard if you’re just starting to build your team. Hearing directly from people who have worked with candidates is super effective to that end. We spent a lot of time on those reference calls, to really understand what kind of a teammate they are, where they spike, and what are their specific strengths that we should really get excited about. I think the number one thing in early employees is just a really high degree of ownership and ability to deal with ambiguity. At that point, candidates were joining two of us and an idea, basically, and there was a lot to figure out. When there's kind of limitless possibilities – it’s a pretty tough challenge, so looking for people that have that high degree of ownership and are going to be effective at sort of navigating the ambiguity –– that's very important.

Otto:

I feel that's part of the recipe of the Silicon Valley startups. You have people who are very outcome-oriented who prioritize their own work and think about the customer. I feel that's maybe a little bit different in Europe where we don't have as strong of a background with great product companies but it's definitely changing and there's a lot of companies who are here doing that now. How do you test for this kind of ownership and "outcome-orientedness," and how do you build a culture that supports that in practice?

Julianna:

There are a few questions that we like to ask in the interview process to better understand how people think about the work that they're doing and the impact that it has. In particular, we really look for people who are business impact oriented – engineers who are excited to think about what they're building, not just how to build it. Especially as a developer company, a lot of our best product ideas come from our engineering team and so we’re looking for people who are excited to think creatively about the products that they're building. We tend to test for this by digging into past projects that they've worked on and how they articulate the impact of those projects. I think you can see pretty clearly people who tie the projects that they're working on back to team and company-level KPIs or metrics or other goals that were impacting the business at large, versus tying them to something that's maybe a little bit more sort of siloed within the team. Maybe they made some piece of the code base a lot cleaner, for example, for the sake of doing it, which is not necessarily the most impactful, versus doing it to accelerate the speed at which developers could contribute code, which is very impact oriented. Little nuances in how people talk about the impact of the work that they've done is how we evaluate for that throughout the interview process. In terms of building a culture that supports ownership and outcome orientedness – I think a lot of it comes from setting really clear company-level goals, and then giving people a lot of freedom within those goals to define the work that they're doing and what they're prioritizing. I think a lot of excitement comes from getting to explore creatively like that and so we think people's best work gets done when they have a lot of freedom to explore and can figure out how to make the most impact for the company as a whole.

Otto:

That's great, but what about all of this in practice? How do you run your recruiting? Who does it, how much time do you need to spend on building the team? Do you have ideas about the seniority mix or how do you evaluate people in practice?

Julianna:

It's definitely evolved a lot in the past two and a half years. In the beginning, I spent a very significant portion of my time doing everything from sourcing people on LinkedIn, trying to find good candidates, trying to get them engaged, to actually running the interview process. I spun up our first applicant tracking system and I was kind of our recruiting team zero. We prioritized hiring recruiters pretty early on – I think we added our first technical recruiter when we were still under 10 employees. I think that was really helpful in terms of giving me a lot of time back to focus on the interviews themselves and closing candidates instead of some of that more top of funnel aspect of recruiting, building the pipeline, etc. Today, it's mostly hiring managers at Stytch that run the recruiting process, and they partner really closely with our recruiting team. Our philosophy is that the teams hire for their team and recruiting is there to be a partner to help them with that process but the job of hiring really falls on the engineering team itself. A big part of a manager’s responsibilities is hiring. I still run some hiring processes myself – I'm hiring for an engineering manager right now, for example, and I still interview every single engineer that we make an offer to. I'm still heavily involved and while I don't think my time spent on recruiting has changed drastically, where I'm spending that time has changed quite a bit – from spending many many hours scraping LinkedIn to now mostly focusing on final round interviews for candidates.

Otto:

That makes sense – the work doesn't end with recruiting though, so when you have identified a great candidate, made an offer, got them to accept it, you need to get them to be a productive member of your team. Any thoughts on onboarding and how you're thinking about that?

Julianna:

Our philosophy is that onboarding starts when you first come in contact with Stytch, so the onboarding process actually begins during your interviews. That's how you're meeting some of the team for the first time and getting introduced to how we work in some ways. We're pretty intentional throughout the interview process that it's as much about selling the candidate and giving them the information they need to make a decision about whether they want to join as it is about evaluating their skills and their fit for our team. We really think of it as sort of that mutual process. There's also one thing we do when we give offers to candidates that I think really kicks off the more formal onboarding process and integration within the Stytch team. What we do is surprise candidates with a “Zoom bomb” – everyone from the interview panel joins that Zoom call and goes around and tells the candidate why they're so excited about them potentially joining the team. We really love doing that because it gives candidates a really clear picture of who they might work with and why those people are so excited about having them on the team. It lets them picture what it might be like to be on that team. Once they’ve started, on day one at Stytch, we also have a really structured onboarding process and we've actually had that since our first engineer joined. It probably felt very comical at the time because my co-founder and I basically ran a series of onboarding sessions. We would talk about things like the competitive landscape or what we think makes great developer products. We talked a little bit about recruiting and marketing and all these different aspects of the company that barely existed at that point. Now the function leads run all of those onboarding sessions, my co-founder and I just lead the company mission and value session. So while who leads what has changed, the philosophy is still the same: there is a really structured first week for anyone joining the team, where they learn about every single function at the company, directly from the people who run those functions. We also put a lot of thought and structure into what the first tasks are for engineers, to give them the ability to ship code within the first week. We’re really thoughtful about picking things for them to work on that give them good exposure to the code base, to help introduce them to what it's going to be like to contribute code at Stytch. I think the overarching philosophy from all of this is just being really intentional about how you integrate people to the team so that you can let them run with whatever it is that they're going to be doing. That means giving them the foundation of information that they need to be able to succeed.

Otto:

I love that, especially the kind of way to empower the teams really is to give them all the tools so that they can be successful and you need a certain level of knowledge to be able to successfully prioritize your own work. So, the sooner you get people on board, the faster they'll get to really own their own stuff. How quickly do you know if it was a “right hire,” if you succeeded in the hiring process?

Julianna:

I think you tend to know pretty quickly, maybe within the first couple of weeks. I think there's people that sometimes interview extremely well and then they join and maybe they're great but maybe they're not quite as exceptional as you thought they were during the interview process. On the other hand, I think sometimes you're really pleasantly surprised by just how impactful someone can be and I think you start to see that early on. Part of the responsibility lies with us, to make sure that we are setting people up for success. That starts with being really disciplined in that hiring process and making sure that we are getting really good signals, so that we hopefully aren't surprised by someone’s performance when they join the team. The onboarding is also supercritical to make sure that people are sort of set up for success, have the resources that they need and we don't leave them there wondering what to be doing on that first day.

Otto:

Makes sense. So you have any red flags or common things that might go wrong with building the team and hiring engineers?

Julianna:

We tend to look for in people who have grit and the ability to tackle whatever is necessary for the company to succeed. I think there's a really big difference between motivated by impact and being motivated by solving hard technical challenges for their own sake. I think for people who are motivated solely when they get to tackle a hard problems, a startup might not be the right fit, because they're going to get to do some of that but there's also a lot of other random stuff you have to do as you're building a startup. That's why we really look for that business impact-orientation – because if that's what motivates you then you're gonna be okay dealing with some of the more annoying tasks that you have to do that might have a really big impact but you know might not be the most technically challenging problem that you could work on. That's something that we really try and evaluate – that ability to go after those hard problems but not necessarily being solely motivated by those types of challenges, but by how solving them will have a larger impact on the company.

Otto:

Makes sense. What about dealing with growth? In the early days when you're just a small team, you as CTO are still a part of' that team. But as you grow, the org changes from being a single team to a team of many teams. How does your role change and how have you handled that?

Julianna:

I started out by managing all of the engineers. Then a little under a year and a half ago, we split into two teams, each managed by people other than me: one engineering manager join us who had previous management experience and in parallel, one of our early engineers stepped up and started managing one of the teams. At that point, I was no longer managing any of the IC engineers, which was a really big shift for me. I think there's been a series of these shifts – the first one is going from being in the weeds with people actually writing code and reviewing PRs, to then being more fully about managing people, and then it became about managing the managers. And it’s still changing! In about a week we have a Head of Engineering joining, so I won't even be managing managers any more. That's going to be a whole new sort of evolution of the role. I think it's something that you really have to be aware of – how your job is changing as a founder as the team is growing. The things that I was doing two years ago would be so ineffective today. I should not be in code reviews, leaving comments – that would not be productive for anyone. I think it can be really hard to leave some of that behind. The way that I've tried to deal with that and make sure that I am evolving at the pace that the company needs is by taking a lot of time to reflect on where I'm maybe still trying to get my hands on something that I should be delegating to someone else. I try to be cognizant of that and to talk to our managers as well and ask them, “Hey, is it helpful that I'm doing this thing or is that something that you think you should take on or someone on your team?” I think that self-awareness really helps with letting go of a lot of things that you used to do yourself.

Otto:

For the final question, I'm really impressed by founders who are able to scale with their companies. As a normal employee, you're kind of always learning and so on but as a founder, if the company is growing 10x, you have to grow with that company or otherwise you're not really able to scale the company anymore. How do you keep learning, how do you seek mentorship? How do you learn new stuff that you need to be prepared for next?

Julianna:

The way I think about it is: if I'm doing the same job that I was a month ago then I'm probably doing the wrong job today. One piece of it is just being aware that your job should be changing and then as you start to go and try to figure out what you need to delegate or hire for, look for experts in different areas. I wouldn't say there's necessarily one person that I go to but it kind of depends on the problem at hand. At Stytch, we’re fortunate to have a really fantastic board, and we'll go to them for a lot of things. They're really helpful about things like thinking through when to sequence various hires, etc. If I'm trying to figure out something like an engineering management problem, then I'll go to my engineering managers that I know and respect. If it's a design problem, I’ll connect with people with that expertise. When we were trying to hire our first designer in-house, I’ve never been a designer, I don't know what good looks like in that role. We talked to a ton of people that we really respected and that really helped. I think it's a lot about just going and seeking out experts. You have to identify the problem that you're trying to solve – I think that's the hardest part. There's definitely a steep learning curve, and making sure that you are continuously evolving and identifying new problems as you grow I think is the most effective way to scale.

Otto:

Thank you, Julianna. It was a very insightful discussion. Great having you, thank you, and thank you everyone who joined.

---


# Designing Passwords in the Stytch SDKs
Source: https://stytch.com/blog/designing-passwords-in-the-sdks/

We’ve built on our Passwords API by designing the corresponding UI in our SDKs, taking care of the end-to-end authentication flow so you don’t have to.

A few months ago, we wrote about how our Passwords API improved the password-based authentication experience and was a huge step forward in removing friction from a classically frustrating process. But our work wasn’t done with launching our API – to offer a complete product, we needed to build Passwords into our SDKs and UI components. 

By designing Passwords into Stytch’s SDKs, we added another route for building a secure, frictionless password authentication experience that uses our own API. Our SDKs serve as a template that can be built upon, rather than starting from scratch and building the UI from the ground up. You get to customize the SDKs to fit your own branding, but we’ll provide all the pieces so you can focus on building your core product, not on how a user signs up and logs in. 

As a Product Designer at Stytch, I worked closely with our PMs and engineers to design and launch passwords in the Stytch SDKs. Our team spent a lot of time thinking through how to create a product that would meet all of the UX and security needs of modern developers with the launch of our Passwords API. We were now ready to build on our API by designing the corresponding UI in our SDKs, taking care of the end-to-end authentication flow so you don’t have to.

Our design challenge: creating a frictionless hybrid flow in the SDKs

Part of the benefit of using our SDKs is that you get to choose from a menu of authentication methods without restrictions (i.e. we allow any of our available products to be enabled together). By introducing Passwords in our SDKs, we now had to think through a “hybrid” scenario we hadn’t faced before: the experience of our Passwords product being enabled in tandem with other passwordless methods. This was particularly challenging because we have multiple email-based authentication methods: email + Passwords, One-Time Passcodes (OTP) sent by email or SMS, and Email Magic Links. All three methods require the user to enter an email address (i.e. have the same “entry point”), and in the case that more than one of these methods is enabled in the SDKs, require us to determine the best way to avoid having multiple separate email input fields within a single flow.



Knowing that we needed to build an experience in which a user would only have to enter an email address and we would figure out whether to send them a link, code, or ask for a password, we were faced with one key design question. How do we know if a user will choose Passwords or passwordless if presented with both? 

We didn’t, and that made designing this product challenging. 

It was hard to know how we should surface the Passwords option because we didn’t initially have a strong sense of what end users would want and how developers might now use the SDKs. Our initial assumption was that going passwordless is typically easier than setting a password, and therefore, it makes sense to surface a passwordless option first. One recent survey found that 75% of users feel overwhelmed trying to keep track of their proliferating passwords. A separate survey found that the majority of respondents would prefer authentication methods for their personal and professional accounts that don’t involve a password. Rather than solely relying on our assumptions, we decided to test two different options with user research.



User research: leaning on evidence, not guesswork

Taking a human-centric approach to product design, and building user research into the process early, is something we pride ourselves on at Stytch. To help us determine which hybrid flow in the SDKs would be the most frictionless for users, we tested two different options: Option 1: prioritize passwordless

User enters email address

If Passwords and a passwordless email method are both enabled, always take the user through the email OTP of magic link flow. Include a secondary link to “Use a password instead.”

Option 2: allow users to choose

User enters email address

If Passwords and a passwordless email method are both enabled, take the user to a screen that presents both methods – i.e. a button to choose “Email me a login link/code” presented side by side with an email and password input.



After connecting with users, we learned that many actually prefer being presented with choices rather than deferring to us to remove a “click.” For example, when it comes to receiving One-Time Passcodes, users want the option to choose the delivery method so they know exactly where to look for their code.

"I just prefer to use the cell phone. Because usually on my iPhone when I'm on a website and see that I got sent a code, it will automatically type in the code for me. Microsoft teams, they always text my personal cell phone, but it's my work computer, they're not related." — Anonymous user

It makes sense — users want to know what to expect, rather than having us assume their preferred behavior through our UI/UX.

Our solution: present password and passwordless options side by side throughout the UI

Based on our research, we decided it was better to present users with the ability to choose their authentication method. Offering Passwords and passwordless options side by side would help reduce friction, even if it meant adding one more “click.” Knowing which direction we were going to pursue, the next task was to figure out the best way to design our UI to offer this.



For new users without an account, this meant assuming that setting a Password and using a passwordless method were equally likely, and should be given equal emphasis. When a new user enters their email address, we direct them to a screen that presents the option to receive a login link/code side by side with email and Password input fields. The user gets to decide which option they want to proceed with. 

For returning users, who had already logged in with an email, it was a little trickier. Because we only offered Email OTP and Email Magic Links previously (developers could only enable one of these two options), the user was always presented with a passwordless option. For these users, we decided to still give the option to choose which method to use. But to help reduce the number of screens and steps, we skip to the passwordless option right away with a link to “Use a password instead.” We send an OTP or Email Magic Link right away since we know this is a method the user has previously used successfully, but still make sure they have a touchpoint to easily access Passwords – still keeping Passwords and passwordless options on equal footing.

Apply the same “equal footing” logic to password reset emails

Even though we offer users the option to choose their authentication method, and touchpoints for passwordless options in tandem with Passwords, we also know that people are constantly forgetting passwords! It’s even a fact reported on by Mastercard and the University of Oxford: “According to a recent study, over 20% of users report forgetting a newly created password within two weeks. That number climbs to over 70% after just a few months.” This data, on top of our own research, helped us decide to apply the same logic we used in designing our SDK UIs – presenting password and passwordless options with equal weight – to the password reset flow. 

Even if we know a user has specifically requested a password reset (i.e. has chosen to use Passwords), we know that setting and remembering a password can be difficult. In the SDK UIs themselves, we include a link to continue passwordless with the password reset request and in the actual “Reset password” screens in case a user decides they’d rather skip another new password. We also added a “Login without password” in the password reset email to add the ability to log back into your account even faster.



Try Stytch’s Passwords in the SDKs product for yourself!

You can play around with our SDKs Passwords product through our integration builder on authkit.dev and see the ready-to-go product in action. Enable “Passwords” along with a few other passwordless products to see how the design decisions came to life. When you’re ready to start building, sign up for a free account to start integrating Stytch into your own product!

---


# SSO protocols: SAML vs. OIDC
Source: https://stytch.com/blog/sso-saml-vs-oidc/

SAML and OIDC are the two most common protocols for single sign on. It's important to understand their differences when building auth for B2B.

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson four in that series. 

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs. OIDC 
Lesson five | What is OpenID Connect (OIDC)?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider 

In the previous lesson we explained what single sign on is, and how it works between its essential components – service provider (SP), identity provider (IdP), auth provider, and the customer. We also diagramed full SSO auth sequences, like SP-initiated vs IdP-initiated, to demonstrate the number of actions and steps involved. The key takeaway? For SSO to function, all of its components must be able to communicate with each other efficiently and securely. This exchange of auth information between services occurs over something called protocols. 

In this blog post, we’ll go over:

What is SAML (Security Assertion Markup Language) and OIDC (OpenID Connect)

How SAML-SSO and OIDC-SSO works

The key SAML-SSO and OIDC-SSO flows

The key differences between SAML and OIDC

Why B2B SaaS vendors need to support both identity protocols

Let’s dive in

As a developer, you’ve probably had to build some form of user authentication functionality at work or in your side projects.

Whether you’re building an enterprise solution or a consumer-facing app, Single Sign-On (SSO) has become a key feature for implementing authentication without compromising security and UX. However, when it comes to choosing between SAML and OIDC, things can get confusing really fast, especially if you’re looking at the official specs.

SAML and OIDC are open SSO protocols that enable end users to access multiple applications without providing unique login credentials across these disparate systems. SAML is typically used by large enterprise organizations, B2B SaaS providers, government agencies, and high-grade security systems, while OIDC is commonly used in mobile and single-page applications (SPAs).

This article aims to clarify the core concepts, auth flows, and use cases of SAML (Security Assertion Markup Language) and OIDC (OpenID Connect). We’ll explore how each protocol works, their key differences, and when to use one over the other. By the end of this guide, you'll have a clear understanding of both protocols and be able to make informed decisions for your SSO implementation.

We'll start by diving into SAML, the XML-based protocol that has been a staple in enterprise environments for over two decades. Then, we'll explore OIDC, a more modern protocol built on top of OAuth 2.0 that’s gaining popularity in B2C and even B2B applications. We'll compare the structure of their assertions and scopes, discuss their interoperability, and highlight specific requirements for each.

What is SAML (Security Assertion Markup Language)?

SAML is an open identity protocol primarily used to implement SSO functionality within enterprise use cases. At its core, SAML SSO eliminates the need for employees to maintain unique credentials across all the intranet systems and SaaS applications they use for work. SAML achieves this by facilitating the exchange of authentication data between Identity Providers (IdPs) and Service Providers (SPs), according to SAML terminology.

Identity providers are the directories or data stores that organizations use to store and manage user profiles and identities within their companies, such as Entra ID, Okta, and Google Workspace. On the other hand, service providers are the internal systems or SaaS applications that employees use for their day-to-day work, such as GitHub, Linear, and Slack.

The basic SAML SSO flow is straightforward: When an employee needs to access an SP, they must first authenticate their IdP-provisioned credentials with the IdP used within their company. If their credentials are valid, the IdP sends an assertion to the SP, which then grants access to the employee without requesting additional credentials.

SAML uses XML (Extensible Markup Language) to structure user identity data and relies on HTTP or SOAP bindings to communicate this information between IdPs and SAML-enabled SPs. This user identity data is structured as attributes such as email, name, or department, and is enclosed in XML documents known as SAML assertions. In terms of security, SAML uses XML digital signatures and encryption to prevent tampering and unauthorized access to the SAML messages sent between IdPs and SPs via the protocol.

Here’s a sample structure of a SAML AuthnRequest in XML:



How does SAML SSO work?



Before a service provider can successfully communicate with an identity provider in a SAML authentication flow, both parties must first establish a trusted relationship. This process requires the SP and IdP to exchange preliminary configuration details with each other using XML-based metadata.

This metadata typically contains details such as endpoint URLs where each party can post SAML messages—whether SAML requests in the case of the SP or SAML responses and assertions in the case of the IdP as the sending party.

It also includes the formats in which user attributes should be structured, signing and encryption certificates, supported connection methods, encryption algorithms, and other relevant details. Each party, both the IdP and SP, must use each other’s metadata file to configure their respective systems before trust can be established.

In addition to the SAML metadata, the SAML specification relies on four other key elements that make SAML SSO authentication possible. We have covered these core elements of the SAML protocol in a separate article, which you can find here.

SAML SSO flows



Once trust has been established between an IdP and SP, there are two major ways in which SAML SSO can successfully happen—the SP-initiated SSO flow and the IdP-initiated SSO flow.

In the SP-initiated SSO flow, the user must visit the SP’s login page, select the “Login with SAML SSO” option, and provide their work email for which pre-configuration must have been set. The SP would then send a signed SAML authentication request (AuthnRequest) to the IdP, and redirect the user to the IdP’s login page.

After the user authenticates their IdP-provisioned credentials, the IdP would have to generate a signed/encrypted SAML response containing assertions about the user and redirect them back to the SP’s endpoint. The SP would then verify the response, parse the assertions, and grant access if valid.

On the other hand, the IdP-initiated SSO flow offers a slightly different user experience. In this flow, there's no need for the SP to make an initial SAML AuthnRequest because the process begins at the IdP, not at the SP's login page.

In the IdP-initiated SSO flow, the user would begin at the IdP and select the SP from a list of SAML-enabled applications provided by the IdP. The IdP would then generate a SAML response and assertion and redirect the user to the SP’s URL endpoint. The SP would have to then validate the response and grant or deny access based on the assertions.

For a more detailed explanation of these SAML SSO flows, please refer to our comprehensive article here.

What is OIDC (OpenID Connect)?

OIDC is an open identity protocol that extends the core tenets of the OAuth 2.0 authorization framework by enabling OIDC-compliant systems to authenticate users in a simple but standardized and interoperable manner, without directly managing user credentials.

Unlike SAML, which is primarily tailored to enterprise environments, OpenID Connect (OIDC) can be used to implement SSO in both B2C and B2B scenarios. OIDC offers a more lightweight and flexible approach that's particularly well-suited for modern web and mobile applications.

The protocol facilitates single sign-on (SSO) by allowing end users to access multiple applications or websites (known as Clients or Relying Parties in OIDC terminology) using a single set of credentials managed by an OpenID Provider (OP).

These relying parties (RPs) can be any application or system that supports OIDC SSO, while Open ID providers (OPs) can be OIDC-enabled identity providers such as Okta, Google, Microsoft, or social media providers such as LinkedIn, Facebook, Twitter, or even other large platform applications like Slack or Discord. Open ID providers can also include security token services such as AWS STS or a typical OAuth 2.0 authorization server capable of issuing identity tokens, not just access tokens.

While OIDC is built on top of OAuth, it's important to note that OAuth 2.0 is an authorization protocol, not an authentication protocol. OAuth 2.0 is a framework for implementing delegated access/authorization, which enables clients to gain access to resources via an authorization/resource server on behalf of a resource owner.

For example, if you've ever granted permission to a third-party add-on to help take notes on your Google Meet or Zoom calls, or allowed an application like Buffer or TweetDeck to access your Twitter/X account and schedule tweets on your behalf, you've seen OAuth 2.0 in action. This differs from the standard OIDC authentication flow we've discussed so far.

How does the OIDC protocol and OIDC SSO work?



When a user attempts to log into an application (OIDC client) using an OIDC-SSO option, the client/RP has to redirect the user to the respective OpenID provider (OP) with an authentication request. The user then has to authenticate their OP-provisioned credentials with the OP. If the credentials are valid, the OP typically sends an identity token back to the client application in the form of a JSON Web Token (JWT).

This ID token contains authentication scopes similar to SAML assertions and includes claims/attributes about the authentication event and the user’s identity. These claims typically include the user’s unique identifier (sub), the time of authentication (iat), the issuer of the token (iss), and other relevant details needed by the OIDC client to make an authentication decision. The use of JSON web tokens (JWTs) in OIDC is what makes the protocol easier to implement than SAML, especially in RESTful architectures.

Here’s a sample structure of a JSON object:



There are five key elements (URLs) that collectively and securely work together to make OIDC SSO possible. These include the Discovery Endpoint, Authorization Endpoint, Token Endpoint, JWKS Endpoint, and UserInfo Endpoint.

The Discovery Endpoint provides metadata about the OpenID provider's configuration, allowing clients (Relying Parties) to access the necessary endpoints and capabilities of the OP. The Authorization Endpoint handles the user authentication request and returns an authorization code to the client. The Token Endpoint then exchanges this authorization code for access and ID tokens, with the ID token specifically carrying user identity information.

On the other hand, the JWKS Endpoint provides public keys for verifying token signatures, ensuring the integrity and authenticity of these tokens. Lastly, the UserInfo Endpoint supplies additional profile data about an authenticated user using the already-issued access token.

Just like is obtainable in SAML, the OIDC client (relying party) and the OpenID Provider (OP) must exchange some form of pre-configuration data before SSO communication can successfully take place.

Typically, the RP must register with the OP to be issued client credentials (such as a client ID and client secret) that it will use to authenticate itself when making requests to the OP’s endpoints. The RP also has to provide information about itself to the OP, such as redirect URIs and other necessary metadata.

In addition, the RP must request the OP’s Discovery Endpoint (usually at .well-known/openid-configuration) to access the OP’s JSON-based discovery document which contains relevant configuration details such as supported endpoints, scopes, and public keys.

OIDC SSO flows

At its core, OIDC supports three key authentication flows that define how RPs and OPs should communicate across different types of applications, including mobile apps, single-page applications (SPAs), and web-based apps. These flows include the Implicit Flow, Authorization Code Flow, and Hybrid Flow, which are tailored to meet unique UX and security requirements across these apps.

The Implicit Flow is suited for client-side applications like SPAs where tokens are returned directly to the RP in the redirect URI.

The Authorization Code Flow is more secure than the Implicit Flow and is best for server-side applications, as it securely exchanges authorization codes for tokens—tokens aren’t returned directly.

The Hybrid Flow combines elements from both the Authorization Code Flow and Implicit Flow. It allows the RP to receive an ID token directly in the initial response, alongside an authorization code that can be exchanged for access tokens.

SAML vs. OIDC: What are the major differences?

As we’ve established so far, SAML and OIDC are both widely used authentication protocols, but they cater to different needs and have distinct features. Here are four key differences between SAML and OIDC:

Authentication source: SAML relies strictly on IdP-based authentication, but OIDC relies on any OIDC-enabled authorization server (whether traditional IdPs, social media providers such as Facebook or LinkedIn, Security Token Services (STSs), etc.) to authenticate user identity.

Data format: SAML uses XML to structure identity data, making it inherently verbose and more complex to process. In contrast, OIDC relies on JSON which is a more lightweight and readable format widely used in modern RESTful architectures.

Security and message integrity: SAML relies on XML-based signatures and X.509 certificates to ensure message integrity and authenticity. Specifically, SAML uses XML Digital Signatures (XML-DSig) with signing algorithms such as RSA-SHA1 or RSA-SHA256 to sign SAML messages. OIDC, on the other hand, uses RSA or ECDSA algorithms with JSON Web Signatures (JWS) and JSON Web Keys (JWKS) for signing and verifying tokens.

Application use cases: SAML is primarily used for implementing SSO in browser-based applications across enterprise environments. However, OIDC extends beyond browser-based SSO to support authentication for APIs, microservices, mobile apps, web apps, single-page apps (SPAs), and even IOT devices.

Authentication vs. authorization: While both protocols handle authentication, their approaches to authorization differ. SAML can inherently handle both authentication and authorization by embedding access control data within SAML assertions. OIDC, on the other hand, primarily focuses on user authentication. However, it can be used in tandem with OAuth 2.0 to support authorization use cases.

Can SAML and OIDC be used interchangeably?

Most IdPs support both SAML-based and OIDC-based SSO protocols. As such, the choice between SAML and OIDC depends on your particular use case (whether B2B or B2C or B2B2C), the regulatory requirements in your industry, and your company’s internal security policies.

If you’re a consumer-facing application (B2C) you’re just fine supporting OIDC alone. However, if you’re an enterprise-facing application (B2B), you may need to support both SAML and OIDC to accommodate varying customer needs.

Auth providers like Stytch offer support for both OIDC and SAML, and SaaS providers who intend to implement SSO can use our SDKs and APIs to implement both protocols in weeks or even days.



This flexibility is particularly useful for SaaS applications that serve both startup customers that have less stringent security needs, and large enterprises, which may have robust access management requirements. In such cases, you can use Stytch to support social login via OIDC for these startups, while implementing SAML for enterprise organizations that may have higher security standards.

On the other hand, it’s important to note that many SaaS vendors may not allow their customers to use both protocols simultaneously. Most providers offer support for OIDC-SSO on their free and basic plans. As such, if you want to leverage SAML, these providers may force your organization to upgrade to their enterprise plan and migrate to using SAML alone, instead of using both protocols simultaneously.

Get started with SAML-SSO and OIDC-SSO using Stytch

Ready to implement single sign-on (SSO) using Stytch? Check out our backend integration guide and our frontend integration guide for SAML and OIDC-SSO.

Want to learn more about our APIs and SDKs? You can check our docs and sign up for a free developer account to start building today.

If you want to learn more about our Enterprise features and pricing, feel free to schedule a call with a member of our Solutions Engineering team.





---


# Stytch + Cerbos + FastAPI: Flexible authentication meets decoupled role and access management
Source: https://stytch.com/blog/stytch-cerbos-demo/

Excited to share this demo by SCerbos that shows how to combine Stytch's authentication solutions with their stateless authorization.

We love finding innovative, like-minded partners in the market we can work with to build even stronger solutions for our customers. That’s why we’re so excited by Cerbos’ latest demo, which walks you through integrating Stytch Email Magic Links and Sessions with Cerbos' decoupled authorization for dialed-in, secure role and access management. In this demo, you’ll learn how to:

Easily serialize, deserialize and validate payloads

Add roles as a top-level key in user metadata

Configure Email Magic Links in the way that works best for your company

Use Cerbos’ stateless authorization for fine-tuned roles and permissions

Check out the full post and demo on Cerbos’ blog!

About Cerbos

Cerbos is an open source access control system that can handle complicated business logic through simple configuration. It allows customers to plug it into their existing stack as a decoupled service.

---


# What is device fingerprinting, and how does it work?
Source: https://stytch.com/blog/what-is-device-fingerprinting/

Device fingerprinting is an increasingly popular way to prevent fraud by identifying devices that are accessing a website or application.

Hackers have any number of methods they draw upon to take over user accounts and access sensitive information. Whether they’re stuffing credentials, using brute force attacks, phishing, or sending spam, they’re almost always making use of bots at some point in their process. The sophistication and potential scale of their techniques evolve every day.

While certain authentication flows help drastically reduce the chance that someone is impersonating a user – think passwordless methods like TOTPs or passkeys, along with multi-factor authentication flows – there are still ways around these techniques. One of the best ways companies can protect against fraud is by reinforcing secure auth methods with equally strong fraud protection tools. One of the most effective and user-friendly of those tools is device fingerprinting.

In this article, we’ll cover:

What is device fingerprinting?

How does device fingerprinting work?

What are the different kinds of device fingerprinting?

How does device fingerprinting prevent fraud?

How does device fingerprinting affect user privacy?

What should I look out for when implementing device fingerprinting?

Device fingerprinting best practices

Device fingerprinting with Stytch

What is device fingerprinting?

Device fingerprinting is a way of identifying and tracking devices that are accessing a website or application. A device’s identity can be composed of a number of attributes that an application detects when the user accesses the site or app that are then associated with a unique ID.

Unlike cookies, which are stored client-side, device IDs are stored in a server-side database. This database of device fingerprints can then be used to verify whether or not a user is accessing the app from the same device or not. If they use multiple devices or a new device and fraud is suspected, the application can block them or give additional authentication prompts to verify their identity.

How does device fingerprinting work?

When a user accesses a website or app, certain kinds of information about a user’s device have to be available in order for the website to load and display properly. Once a site or app has collected those attributes, it turns them into a device hash that can then be parsed by their fraud manager. 

With this hash safely stored, the next time someone logs on claiming to be that user, the app can compare the device fingerprints to see if the user is logging on from the same device, or a new one. If it’s a new one, depending on how suspicious it is, the application can either block the user or ask for further verification.



What kind of device data does device fingerprinting collect?

Attributes included in a device fingerprint include the IP address, browser brand and version, HTTP request headers, the user_agent string, operating system (OS), browser or operating system language, installed browser fonts, time zone, screen resolution, and many others.

What are different kinds of device fingerprinting?

While products like Stytch collect several different types of information in a single device fingerprint, you may hear or read a few different terms on the web that all refer to a kind of device fingerprinting.

To avoid confusion, we’ve broken down a few different ways you might hear a device fingerprint described:

Browser fingerprinting

Browser fingerprinting refers specifically to information gathered about a users’ web browser. It’s worth noting though that though the information comprising a browser fingerprint is gathered via the browser, much of the information that can be gathered via the browser can still be about the user’s device and their web browser configurations.

Desktop device fingerprinting

Whereas “browser fingerprinting” generally refers to information that is gathered via a browser, “desktop device fingerprinting” simply refers to a device fingerprint comprised of information about a user’s desktop device (typically gathered because of information exposed to the application or service while the person is accessing it from that desktop device).



Mobile device fingerprinting

Similar to desktop device fingerprinting, “mobile device fingerprinting” refers to a device fingerprint comprised of information about someone’s mobile device while they are accessing an application or service from that mobile device.

How does device fingerprinting help prevent fraud?



By allowing websites to affiliate device data with their users, device fingerprinting helps companies monitor for irregularities or suspicious activity, and intervene sooner if they detect a risk of fraud or account takeover.

For example, if a user who usually logs in from IP addresses exclusively in one time zone and one browser language suddenly logs in from a brand new IP with a different default browser language, companies can take additional steps to verify the user and/or protect their account. This action can mean something as unobtrusive as requesting additional authentication methods, or more robust responses like revoking access tokens or invalidating session cookies.

Device fingerprinting also helps prevent what’s known as “first-party fraud,” in which bots create net new accounts in order to abuse a website using spam, purchasing scarce assets (think of Nike shoe drops or Taylor Swift’s recent Ticketmaster fiasco), etc. By giving companies a better sense of which traffic is a genuine user and which is fraudulent / bot-created, they’re better able to protect their users from bot-driven experiences like automated ticket scalping and spammy advertisements / emails.

It’s important to note that a “device fingerprint” is only as unique as the information they collect. Obviously, there’s more than one person in the world on a MacBook Pro using Firefox! So the more data sources and more unique data points a device fingerprint is based on, the more unique that device fingerprint is. This is why Stytch uses device, network, and browser data points to make sure our device fingerprints are as unique as possible.

This is also why the power of device fingerprinting to prevent fraud is not just about what information is collected, but how that information matches or doesn’t match contextually with a given user, and the different notification and classification systems a given app sets up to monitor device behavior patterns within their platform.

How does device fingerprinting affect user privacy?



While Stytch is laser-focused on device fingerprinting for fraud prevention, companies may also use device fingerprinting for other purposes like marketing (to better target online advertisements or personalize consumer experiences).

Privacy regulations vary widely by geography, but more stringent legislation like Europe’s General Data Protection Regulation (GDPR) consider techniques like device fingerprinting that process personal data for the sake of preventing fraud as a legitimate interest. GDPR is much more strict with techniques like device fingerprinting when it comes to marketing or ecommerce use cases.

Whatever your app or site’s use case or geography, you must gain consent from users whenever collecting their information, including when using device fingerprinting. We find the best way to do this is to:

Explain to users exactly what an app is collecting and why

Explain how that information is being used, and how it will not be used

Explain all the additional steps and investments your company is making to actively protect your server-side databases and user information

The end goal with disclosures like these isn’t about checking a box: it’s about engendering trust. The whole reason we recommend fraud prevention tools like device fingerprinting is to make it easier for our customers to earn and keep their users’ trust with their information. A transparent, clear disclosure about precisely how you go about that is as important as the tool itself.

What should I look out for when implementing device fingerprinting?

As mentioned above, there are many different attributes an app or site could collect about a user, and different ways to configure the categories of risk and action a given website or app might take in case of suspicious behavior.

Generally there are three main things to look out for when configuring device fingerprinting for your site or app:

Insufficient data

As we mentioned earlier, the more data a device fingerprint tracker collects, the more unique that device ID will be. So while it may seem easiest when implementing device fingerprinting to just track a few core attributes, insufficient data will render your device fingerprints easier to imitate and thus ineffective.

Easily alterable or reverse-engineered data

In addition to the amount of data you collect, you want to consider how easy it might be for a hacker to alter the data you do collect. For instance, it can be very easy to alter an IP address with a VPN, or change a browser or OS language. But other kinds of data are harder to alter: touch hardware, video and audio capabilities, and other kinds of device data cannot be changed so easily.

An example of a vulnerable device fingerprint

To see how this might work in practice, let’s take a look at the following example:

In this code snippet, we use the user’s device information, including their userAgent, screen resolution, and time zone to create a unique device hash that can be used to identify and track the user’s device.

While these attributes may suffice for some basic device fingerprinting applications, they’re fairly easy to alter or obfuscate. Hackers can easily change their userAgent to a virtual machine (VM), or use a VPN or private browsing mode to elide giving an IP address, time zone, etc. Relatively simple factors like these are also fairly easy for hackers to “spoof” or imitate, by analyzing the fingerprint of other devices and then contriving or faking those data points on their machines.

Device fingerprinting best practices

So if we want to avoid falling prey to hackers, what are some best practices for implementing device fingerprinting we can keep in mind?

There are a few things developers can do to improve on these potential vulnerabilities:

Collect a wider variety of stable data points

One of the surest ways to make your device hashes more unique and harder to hack is simply by collecting a larger variety of data points – in particular, you should focus on stable data points that don’t change when a user changes WiFi networks or upgrades their browser. Unlike IP addresses or time zones, hardware data like the make and model of a device are more challenging for hackers to alter or hide from detection. You can also detect more detailed information about a device’s browser, like the installed plugins and fonts.

Prevent access for VPNs or private browsing modes

If certain kinds of user data are important to your device fingerprinting solution, you can also deny access to users logging in through a VPN or incognito browsers. Note though that this can introduce friction for users who prefer navigating online this way, so make sure you know your user base before doing anything that will make it harder for people to use your product.

Use machine learning to better understand user patterns

Machine learning algorithms can leverage the scale of traffic to your app or website to better understand user and device behavior, identifying patterns and suspicious devices based on a combination of factors or correlations.

This kind of computing can augment your device fingerprinting and keep it agile and responsive as hacking methods and behaviors change. Especially as device fingerprinting becomes more prevalent, fraudsters will invent new ways to spoof or fake their device fingerprint. Machine learning and data science can be a powerful tool to detect how fraudulent behaviors are evolving, so that device fingerprinting can keep pace.

Incorporate more contemporary cryptographic techniques to protect device fingerprints

It’s a lot more challenging for fraudsters to reverse engineer legitimate device fingerprints if those fingerprints are more securely stored. Cryptographic techniques help reinforce device fingerprints’ integrity by making them much harder to access, and to fake.

Device Fingerprinting with Stytch

As a comprehensive auth platform, Stytch’s Device Fingerprinting goes the extra mile for customizability and security: we collect device data from multiple sources and use advanced techniques to create a unique, cryptographically-secured fingerprint for each user’s device. This allows us to provide a higher level of security than other solutions, while still offering the same flexibility and developer-first experience that comes with any of our products.

If any of this sounds like it might be useful for your company, you get started for free, check out our docs, or book a demo today.

---


# What is OpenID Connect (OIDC)?
Source: https://stytch.com/blog/what-is-openid-connect-oidc/

OIDC is an authentication layer built on top of the OAuth protocol used to power B2B auth solutions like SSO. Here's a full breakdown.

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of user authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson five in that series.

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs OIDC
Lesson five | What is OIDC?
Lesson six | What is SAML and how does it work?
Lesson seven | Choosing a B2B auth provider


In the previous lesson we looked at the importance of single sign on protocols – what they are, how they’re created, and why they’re important for B2B Auth. We then went over the two most common protocols in single sign on: Secure Assertion Markup Language (SAML) and OpenID Connect (OIDC).

In this post, we’re going to look more closely at OpenID Connect to understand how it works, and get a more nuanced understanding of its benefits, drawbacks, and most common use cases. We’ll cover:

What are OAuth and OpenID Connect

The components of OpenID Connect

How OIDC works in three phases

What OIDC means for B2B auth

Now that we’ve got that straightened out, let’s dive in!

What are OAuth and OpenID Connect?

As we mentioned in our last post, OpenID Connect is an authentication layer built on top of an authorization protocol called OAuth. Because of their symbiotic relationship, the two protocols are often used interchangeably by developers; but to be precise, OAuth is for authorization and OpenID Connect is for user authentication.

Authorization verifies what a user is allowed to access.

Authentication verifies who a user is and their identity.

The two protocols are, so to speak, two sides of the same coin. To understand how OIDC functions as an SSO protocol, we need to cover the fundamental aspects of OAuth’s design because it was created first.

OAuth was jointly developed in 2006 by Twitter and Google. With near universal adoption of social media sites, developers realized that their applications would greatly benefit from letting users bring in their data from accounts like Facebook, Twitter, or Google. This linking of accounts has proven to be a powerful integration pattern. Users bring their data over to an application for convenience while developers build features on top of it.

You’re probably most familiar with OAuth with social accounts. If you’ve ever authorized an app to access the resources in your Gmail or Facebook account, you’ve used OAuth. Examples of these authorization prompts look like:

“Allow this app to add all your Facebook friends as contacts?”

“Allow this app to post links on your Twitter feed?”

“Allow this app to sync events with your Google Calendar?”

“Allow this app to use your profile picture from Gmail?”

If the user consents, the application can then access the user’s data and resources as if acting on the user’s behalf. This pattern of granting permissions is known as delegated access or delegated authority.

In order to do this safely, OAuth lets users provide access to their accounts without exposing their login credentials. It’s a protocol that delegates access and permissions between APIs and applications in a safe and reliable exchange.

We’ll cover how this all works under the hood in a later section.

So why do we need OpenID Connect?



The short answer is OAuth only really cares about access to resources. Once a user grants permissions, the OAuth protocol interprets that as a green light for data access but stops short of actually verifying the identity of the user. OAuth confirms the user’s ownership of an account and its data, but omits the details about who the user is. It’s a subtle but important distinction.

OAuth simply doesn’t provide enough assurance that the right resources are only accessible by the right people. Because these gaps limit OAuth’s ability to serve some of the most crucial needs in B2B auth, OpenID Connect was added and launched in 2014 to treat federated identity as a first-class concept within the OAuth protocol. OpenID Connect introduces a standardized implementation, set of scopes, and data format for exchanging information about the user’s identity.

In this way, OAuth is a bit like sharing the key to your apartment. The key does not provide any assurance or verification of who is using it: anyone with the key can get in. This may work great for your dog walker or a neighbor you trust, but there are other kinds of assets you want to make sure only you can see. OIDC is more like the reception desk: in order to get in the building, one must prove who they are first by providing something like an ID, passport, or a list of personal details like name, birthday, and phone number.

OIDC administers the identity logic necessary for proper authentication. It generates a proof of an identity for the user that applications can store and verify. And by piggybacking off the OAuth architecture, OIDC utilizes the same secure mechanisms to transport that identity data between applications, which means OIDC is a form of delegated authentication.

OAuth and OIDC work great together because they are so interwoven. But most crucially, their design of delegated access and authentication creates interoperable interfaces necessary for organization-based authentication flows like SSO to function.

In the world of B2B Auth, both the authorization and authentication process are critical, as B2B customers want fairly granular control over who can access what.



The OIDC components

It’s helpful to lay the groundwork with some key terms and flows. There are hundreds of terms listed in the OAuth spec and OIDC spec, and we encourage anyone interested in a deeper dive to take a look at those resources. In this article, we’ll just focus on the main terms developers need to know in order to evaluate different SSO solutions for their application.

Like SSO, OAuth and OIDC can be broken down into a few main components. These are similar and mostly analogous to the components involved in single sign on.



How does OIDC work?

OAuth is a deep and complex protocol if you explore every facet of it. To best understand its most important functions, and how it matters to SSO, it helps to analyze the protocol in three phases of action.

Phase one: a secure connection



A user initiates the OpenID Connect flow by choosing a third-party platform, such as Google or Facebook, to login with on a client application. The first phase involves the client application and the authorization server establishing a secure connection to prevent man-in-the-middle attacks and other security threats.

The client application can select several grant types to prove to the authorization server their connection is secure. The most secure is proof keys for code exchange (PKCE). You’ll also hear some OAuth literature discuss implicit and password grant types, but these are considered legacy practices and not recommended today because of various security concerns.

Using PKCE with OIDC adds an extra layer of security to the OAuth 2.0 authorization process by ensuring that any sensitive data is only sent to the original server that initiated the authentication request, and not to any other servers that may try to impersonate that server.

The client application generates a secret code, the code_verifier, and a hashed version of that code, the code_challenge.

The client application sends the code_challenge to the authorization server along with the authorization request.

The authorization server stores the code_challenge for a later phase.

Phase two: user login and consent



The authorization server prompts the user to log in to their third-party platform and to give consent to grant the client application access to their data. These actions are completely done in the UI by the user.

Once the authorization server confirms the user has logged in successfully, it resumes the PKCE code flow from phase one and generates an authorization code. The client application then sends both the authorization code and the original code_verifier back to the authorization server to verify against the code_challenge, thus proving the client application’s authorization request hasn’t been intercepted.

With the PKCE code flow completed, the client application can finally request what it needs most: tokens.

Phase three: bearer tokens



The OAuth and OIDC protocols use bearer tokens to transport access controls and data between the components. The name bearer token can be understood as “give access to the bearer of this token.” These tokens are encrypted pieces of data, like a JSON Web Token (JWT), that act as the main mechanism for delegated access and user authentication.

The main difference between OAuth and OIDC is the type of bearer token the client application requests from the authorization server. The types of tokens are:

An access token (OAuth) is used by the client application to access a given resource from the resource server. An access token is primarily used for authorization.

An ID token (OIDC) is used by the client application as a proof of identity for the user. Unlike an access token, an ID token is primarily used for authentication.

A refresh token is used by the client application to request either a new access token or ID token after they expire.

Once the authorization issues an access token or ID token, the client application has everything it needs for delegated access and authentication. The ID token confirms the user’s identity is genuine and the client application can consider the user fully authenticated via OIDC.

The full OIDC flow



OIDC for B2B auth

The OpenID Connect protocol is a deep and still evolving authentication framework boosted by OAuth’s architecture. Not only does the OIDC protocol fulfill the requirements for SSO login, but it is also designed for modern API support, mobile applications, and to handle the scale of social media platforms. It is a protocol well suited to support the diversity of both B2C and B2B auth models.

If you’re building SSO, OIDC is a future-forward path to create a robust and complex B2B auth solution. There is a lot more to the OIDC spec, but what we covered should give you a strong foundation of how the delegated authentication pattern works for SSO.

For our next lesson, we’ll be doing a tour of the SAML protocol.

See you then.

---


# Securing AI against bot attacks
Source: https://stytch.com/blog/securing-ai-against-bot-attacks/

AI apps like ChatGPT open a world of possibilities – and a world of potential fraud. Luckily, there some tools available today that can help.

ChatGPT and the acceleration of AI adoption

Since its release last week, ChatGPT has quickly captured the internet’s attention for its uncanny ability to generate human-like responses to a wide array of complex questions. While it’s far from perfect, ChatGPT is the first large-scale deployment of GPT-3.5, the latest AI advancement from OpenAI. For those familiar with OpenAI’s previous model, GPT-3, the improvement is startling. GPT-3 (short for “Generative Pre-Trained Transformer 3”) was already an impressive feat, but it feels like a toy compared to the surprisingly lucid experience of interacting with GPT-3.5. In many ways, ChatGPT feels like a watershed moment for artificial intelligence. 

And while we’re only able to speculate on many of the impacts that AI tech advancements may have, one thing is already clear – developers are eager to incorporate the APIs (Application Programming Interfaces) behind ChatGPT into existing and new applications in order to improve current workflows and introduce new, previously unimaginable user experiences. In just 5 days, ChatGPT amassed over 1 million users. Many of these early adopters are developers who are tinkering with the technology and exploring how it could be incorporated into various B2C and B2B use cases. 

The developer excitement behind these new capabilities is no surprise. In the 2010s, companies like Stripe, Twilio, and Plaid introduced new superpowers to developers through APIs that simplified embedded payments, telecommunications, and third-party data access into applications, and these building blocks unleashed a wave of application innovation. Similarly, in the 2020s, APIs providing access to underlying artificial intelligence models like GPT-3, ChatGPT and (soon) GPT-4 will unleash unprecedented innovation.

When AI meets API: security implications

While the opportunities are limitless, as more applications integrate these AI APIs, it will introduce new application security concerns for developers. In particular, applications building with these APIs should expect significant and sophisticated bot traffic directed at their sites. It’s a matter of simple game theory and what the last two decades of commercial APIs have shown us – anytime you expose a resource on the internet (e.g., compute) that offers significant monetization potential to an attacker, fraudsters will search for ways to exploit that resource. In the case of Stripe and Plaid, these companies provide API endpoints for validating credit card numbers and bank account credentials, which attackers exploit to perform account validation attacks to steal valuable financial accounts. In the case of Twilio, attackers commit SMS toll fraud in order to pump expensive SMS traffic through partner mobile network operators (MNO) and share the profits with the MNO. 



The value behind artificial intelligence APIs could prove similarly alluring to fraudsters now, just as Stripe, Twilio, or Plaid did when they emerged. Not only are artificial intelligence APIs expensive to use, their API responses are also relatively fungible and public-facing, making them particularly ripe for abuse. Cloud services and other tools that, by design, expose valuable compute resources (e.g. companies like Replit, Github, and Heroku) provide a glimpse into the attack vector that applications exposing AI APIs will need to anticipate. In attacks against open compute resources, fraudsters commit first-party fraud by creating fake accounts for the sole purpose of running commands that can be monetized – with cloud services, cryptomining has been the most reliable way for attackers to make money through this vector. 

For applications leveraging expensive AI APIs, we can expect a similar attack vector where fraudsters create numerous fake accounts to initiate valuable queries while purposefully evading rate limits. A couple of the most likely monetization paths behind this attack include:

API skimming attacks: This is an attack where the bots are effectively piggybacking on the the application’s AI resources as a sort of man-in-the-middle approach: the attacker sells access to the API outputs to another party, but they piggyback on a legitimate application’s API routes in order to avoid paying for the costly resource. Because the outputs are fungible and exposed to the end user in most cases, this is an API attack route that does not currently exist with services like Stripe or Twilio.

Model stealing: B2B AI companies often invest significant time and resources into developing their AI models. If these models are not properly protected, they can be stolen and used by competitors or malicious actors. In the case of theft, an attacker could attempt to reverse engineer the model by analyzing its behavior and trying to infer its structure and algorithms. This could be done by feeding the model a large number of inputs and analyzing the outputs, or by using machine learning techniques to try and recreate the model. This can be a difficult and time-consuming process, but a sophisticated botnet could potentially automate some of the steps involved.

Adversarial attacks: AI systems are vulnerable to adversarial attacks, where an attacker deliberately manipulates the input data to cause the AI model to make incorrect predictions or decisions. This could lead to serious consequences, such as financial losses or safety risks depending on the application use case.

How to protect AI from bot attacks

As a result of these threats, AI companies have unique bot detection needs, as they need to ensure that the APIs they expose are only accessed by authorized users and not by unauthorized bots or other malicious actors. 

Some of the unique bot detection needs that AI companies might implement include:

Detecting and blocking bots that are attempting to access the API without proper authorization. This could include bots that are attempting to scrape data from the API, or bots that are trying to use the API to carry out malicious activities, such as spamming or fraud. To defend against this, it’s critical to protect against common bot detection evasion techniques, which include reverse engineering APIs and using methods like headless browsing alongside proxies or residential IP addresses to appear like a human rather than a bot.

Monitoring the usage of the API to identify and block any suspicious or unusual patterns of behavior. This could include looking for anomalies in the frequency or volume of API requests, or for patterns of behavior that are indicative of bot activity, such as rapid and repeated requests from the same IP address.

Overall, AI companies have unique bot detection needs because of the valuable APIs they expose. To protect these APIs, AI companies need to implement effective bot detection and blocking mechanisms, and they need to monitor and protect against bot detection evasion techniques as well. 

At Stytch, we help companies tackle Fraud and Risk Prevention with products like Device Fingerprinting and Strong CAPTCHA, both of which make it easier for developers to build in bot-protection without adding any friction for the user. By combining these tools with our user-friendly, ironclad authentication products, companies can rest easy knowing their data and resources are protected from malicious bot traffic. If you want to learn more about how to protect your product from bot traffic, talk to an auth expert today!

---


# What is Security Assertion Markup Language (SAML) and how does it work?
Source: https://stytch.com/blog/what-is-saml/

Learn all about Security Assertion Markup Language (SAML) – its history, its benefits, basic code anatomy, and how it actually works.

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of user authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson six in that series. 

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs OIDC
Lesson five | What is OpenID Connect (OIDC)? 
Lesson six | What is Security Assertion Markup Language (SAML) and how does it work? 
Lesson seven | Choosing a B2B auth provider 

In the previous lesson, we took a close look at OpenID Connect or OIDC – one of the two most popular protocols for handling single sign on (SSO). We looked at the origin of OIDC, its close relation to OAuth, and how that authorization protocol was built upon to create what is now quickly becoming a preferred standard for identity claims for federated, enterprise SSO.

Today we’re going to look at the other most popular SSO protocol, Secure Assertion Markup Language, or SAML protocol. We’ll look at:

The legacy of this standard from SAML 1.1 to SAML 2.0

The key components of the SAML protocol

SAML-based single sign-on (SSO)

How SAML SSO authentication works

The key SAML SSO flows

The structure of SAML messages (requests and responses)

Why you should support SAML as an enterprise-focused B2B SaaS vendor

Let’s get started!

It’s quite common for employees within large enterprise organizations to use a shedload of internal and external systems for work.

In a company that doesn’t leverage SAML or Single-Sign-On (SSO), employees would typically have to manage unique login credentials for each of these systems they need to access. While it’s obvious how much of a poor user experience this is, it also poses significant security risks that can have costly consequences for employees and the organization.

This is where SAML (Security Assertion Markup Language) comes into play.

Within organizations that leverage SAML, both intranet systems and SaaS applications don’t need to manage employee identity credentials directly. Instead, an identity provider (IdP) can assume this responsibility.

The IdP maintains up-to-date profiles and attributes for every user or employee and is responsible for exchanging these profiles with the applications employees need to authenticate into at any given time.

This approach eliminates the need for employees to manage multiple sets of credentials and redundant login processes across several work applications. It minimizes the burden of password memorization and mitigates the security risks associated with employees reusing the same password across multiple apps, or setting up weak and pattern-based passwords that can be easily compromised.

What is SAML (Security Assertion Markup Language)?

SAML is a federated identity standard that allows identity providers (IdPs) to exchange authentication and authorization details about a user with applications that require this information to grant or deny access to their systems.

It’s also referred to as an XML-based protocol because it uses the Extensible Markup Language (XML) to facilitate this communication between IdPs and SaaS applications (also known as Service Providers in SAML terminology).

Here’s how this communication works: Before an end-user can access a SaaS application via SAML, the service provider (SaaS application) must send an authentication request to the IdP, and the IdP must issue a valid SAML assertion to the application in the form of a digitally signed XML response.

This assertion contains essential information about the user, such as their identity and access privileges, represented as attributes, alongside conditions that specify the validity period and constraints of the assertion.

In this article, you’ll learn about the SAML protocol according to the latest version of the OASIS SAML technical overview document. We’ll explore the key roles and components of the SAML 2.0 specification, and demonstrate how IdP-initiated and SP-initiated SAML SSO flows work. We’ll also discuss the top alternatives to the SAML protocol and show you when to choose one over the other.

SAML 1.1 vs SAML 2.0

There are two main versions of the SAML standard—the SAML 2.0 version which is now widely implemented in B2B and B2E use cases, and the SAML 1.1 version which is largely deprecated. SAML 1.1 was adopted in 2003 as an improvement to SAML 1.0, which was introduced in 2002. But in 2005, SAML 2.0 was adopted as the latest OASIS standard, essentially replacing SAML 1.1.

SAML 1.1 and SAML 2.0 were both designed to achieve federated identity and single sign-on (SSO), allowing users to access multiple systems with a single set of credentials. However, SAML 1.1 had significant limitations in its implementation, causing SAML 2.0 to introduce some of the following key improvements:

Multiple Bindings: SAML 2.0 introduced multiple communication methods known as bindings, including SOAP and non-SOAP options like HTTP Redirect, HTTP POST, and Artifact Binding. This expansion allows SAML 2.0 to work with a wider range of transport protocols that define how SAML messages are sent between IdPs and SPs on the browser.

Single Logout (SLO): For users to be able to terminate multiple active sessions at once, SAML 2.0 introduced SLO functionality. SLO enables users to log out of all connected applications simultaneously. This feature addressed a significant security concern that was present in SAML 1.1.

Improved Encryption and Security: SAML 2.0 offers more sophisticated encryption capabilities, allowing for the encryption of entire assertions or specific attributes. It also introduced persistent identifiers, enhancing user privacy across different service providers.

Enhanced SSO Profiles: Unlike SAML 1.1, which primarily supported two browser-based SSO profiles, SAML 2.0 introduced a more improved SSO profile including IdP discovery, name identifier mapping, artifact resolution profile, and SLO.

​​The rest of this article will cover the other protocol improvements introduced with SAML 2.0.

Key elements of the SAML 2.0 protocol

There are five key elements that collectively function together to make the SAML protocol work. These include SAML Metadata, SAML Protocols, SAML Bindings, SAML Assertions, and SAML Profiles

SAML Metadata: These are pre-configuration files that must be shared between SAML entities (IdPs and SPs) to establish a trusted relationship before SAML SSO can take place. SAML metadata is typically an XML document that contains entity identifiers, supported bindings, X.509 certificates for signing and encryption, endpoint URLs (e.g., SSO service URL in the case of an IdP and Assertion Consumer Service (ACS) URL in the case of an SP), and other relevant configuration details.

SAML Protocols: Define the request/response rules for sending data between IdPs and SPs in a standardized manner. The core SAML protocols include the Authentication Request Protocol, which allows SPs to request authentication from an IdP, and the Attribute Query Protocol, enabling SPs to query for assertions. There are other SAML protocols that we haven’t covered in this article, but you can find them in the official SAML specs.

SAML Bindings: Specify the transport mechanisms used to exchange SAML messages between IdPs and SPs. Common bindings include HTTP Redirect, HTTP POST, and SOAP. HTTP Redirect binding is typically used for transmitting authentication requests, while HTTP POST binding is often used for delivering SAML assertions. SOAP binding, on the other hand, is utilized for more complex or asynchronous communication.

SAML Assertions: These are XML documents that IdPs use to send authentication, attribute, and authorization data to SPs. These assertions are digitally signed by the IdP and contain statements about the user, such as their authentication status, timestamp, and other relevant attributes (e.g., name, email). Authentication assertions prove that the user has been authenticated, Attribute assertions provide specific information about the user, and Authorization assertions define what permissions have been granted to the user.

SAML Profiles: Describe how SAML assertions, protocols, and bindings are combined to support a defined use case or functionality. The most widely used profile is the Web Browser SSO Profile, which outlines how SAML can be used to enable single sign-on for web applications. The Enhanced Client or Proxy (ECP) Profile supports SSO for non-browser-based clients, such as rich clients or proxies, which need to interact with web services securely.

Other profiles include the Single Logout Profile, which describes how users can be logged out from multiple applications simultaneously, and other less popular profiles. These profiles provide detailed guidelines for deploying SAML in different contexts, ensuring interoperability and consistency across implementations.

So what exactly is SAML SSO?

SAML and SSO are often used interchangeably or even seen as alternatives. While there’s a mutual relationship between these two concepts, there’s also a stark difference between them.

Single Sign-On (SSO) is a broad authentication concept that enables users to access multiple applications using a single set of credentials that must have been provisioned on a separate application that can vouch for their identity. Once authenticated in one application, users can seamlessly access other connected applications without having to re-enter any credentials.

On the other hand, SAML is one of the several open protocols that can be used to implement an SSO experience or functionality. As we’ve seen thus far, it defines a standardized way for identity providers (IdPs) to pass authentication and authorization data to service providers (SPs)—the application a user attempts to access.

In essence, SSO is the “what”—the desired functionality—while open protocols like SAML, OIDC (OpenID Connect), Kerberos, and OAuth 2.0 are the “how”—the methods used to implement this functionality. As such, the discussion shouldn’t be “SAML versus SSO” or “OIDC versus SSO,” but rather “SAML + SSO” or “OIDC + SSO.”

SAML SSO specifically involves transferring a user’s identity profile from an IdP to an SP using XML-based assertions. These assertions confirm the user's authentication status and are signed by the IdP to ensure their validity. In this way, users can access multiple applications that support SAML SSO by authenticating their IdP-provisioned credentials with the respective IdP, eliminating the need for separate credentials for each application.

How does SAML SSO authentication work?

Like OIDC, SAML authentication also works through a series of redirects and information that is conveyed along with those redirects. To start, let’s take a look at the main components.



The SAML SSO authentication flow is a trust validation process that involves the exchange of identifiers, metadata files, security tokens, relay state, session indexes, and other relevant attributes between the key roles within a SAML SSO setup.

The key roles within a typical SAML SSO authentication flow include:

Principal (End users)

Browser agents

Identity providers (IdPs)

Service providers (SPs)

Auth providers (e.g., Stytch)

Principal

The principal, or end user, is the human who initiates the authentication process in order to access a protected resource or application. This is typically an employee, customer, or partner of an organization who owns a single set of credentials they use to log into the company’s identity provider. The principal is central to the SAML SSO process, as the entire flow is designed to facilitate their access to several applications without repeatedly entering unique credentials on each one.

Browser agent

The browser agent acts as the intermediary between the principal, the identity provider, and the service provider. It’s usually the web browser or a similar client application that the principal uses to interact with the web.

When a principal tries to access a protected resource, the browser agent initiates the SAML SSO process by redirecting the authentication request to the IdP. After successful authentication, the browser agent also handles the redirection of the SAML assertion from the IdP back to the SP. The browser agent is also responsible for storing and transmitting cookies that maintain the user's session state.

Identity provider (IdP)

The IdP is a trusted entity that authenticates the principal’s identity. It maintains the principal’s credentials and profile information and verifies their identity whenever they attempt to access a service provider. Upon successful authentication, the IdP generates a SAML assertion which contains information about the user’s identity, authentication status, and other relevant attributes. This assertion is digitally signed and sent to the SP via the browser agent.

Service provider (SP)

A service provider is the application or system that a principal is trying to access. The SP trusts the IdP to authenticate the principal and issue an assertion that confirms their identity and associated attributes. Once it receives a SAML assertion from the IdP, the SP validates the assertion's integrity and authenticity and uses the information within it to make access control decisions. If the assertion is valid, the SP will automatically grant the principal/user access to the requested resource or service, without having to manage the user authentication process by itself.

Auth provider (Stytch)

An auth provider like Stytch isn't a necessary component within a custom in-house SAML SSO setup. However, organizations can choose to build their SAML SSO infrastructure using third-party auth providers, in which case Stytch could become part of your SAML authentication flow.

Auth providers like Stytch don't function as standalone identity providers such as Okta or Microsoft Entra ID. Instead, they provide the APIs and SDKs that make it easier for developers to implement SAML SSO in their applications without directly handling the complexities of the SAML protocol.

Stytch only acts as an intermediary that standardizes the authentication process across multiple identity providers and can integrate with any organization’s IdP. The IdP remains solely responsible for authenticating users and issuing SAML assertions. Stytch's role is to facilitate the authentication process between the IdP and SP, forwarding XML requests and assertions between them.

SAML SSO authentication flows



Let’s assume we have an employee who needs to access a SaaS application to complete a task, maybe Figma in the case of a designer or GitHub in the case of an engineer. If these applications support SAML SSO, our hypothetical designer or engineer could access Figma or GitHub in two ways—via the service provider-initiated (SP-initiated) SAML SSO flow or the identity provider-initiated (IdP-initiated) SAML SSO flow.

In the SP-initiated flow, the user must attempt to access the SP directly (e.g., Figma or GitHub's login page). As such, the SP has to redirect the user to their IdP with a SAML authentication request (AuthnRequest). Once the user authenticates their IdP-provisioned credentials, the IdP would have to generate a SAML assertion and return a signed response to the SP. The SP then validates this assertion and grants or denies access to the user.



On the other hand, the IdP-initiated flow begins at the IdP portal and doesn’t require an initial SAML AuthnRequest from the SP. Firstly, the user must log into their IdP and select an SP (e.g., Figma or GitHub) from a list of SAML-enabled applications. Upon selecting the application, the IdP has to generate a SAML assertion and send it to the chosen SP. The SP then validates the assertion and grants or denies access.

In both flows, the common steps include the IdP authenticating the user, generating a SAML assertion, and the SP validating this assertion to grant access.

Structure of SAML messages (requests and responses)

To fully understand the SAML authentication process, we need to study the XML anatomy of SAML requests, responses and assertions.

As we’ve seen so far, SAML messages come in two forms—SAML requests and SAML responses.

The main difference between them is the direction in which they are sent. A SAML request is sent from the service provider to the identity provider in order to authenticate a user’s identity, while the identity provider sends a SAML response to the service provider to convey authentication status, assertions and other requested information about the user.

Structure of SAML requests

SAML requests are initiated by the SP to request authentication from the IdP on behalf of a user. These requests typically contain information such as the request ID, the SP's entity ID, and the ACS URL where the IdP is expected to send the response.

We won’t be going deep into XML semantics or schema, but if you want more specific information on SAML data schema or namespaces (mentioned below) check out page 11 in the SAML specs.

Here’s an example of a SAML request in XML:



From top to bottom, we can deconstruct this XML request into its most important parts and summarize their meaning:

AuthnRequest is the top level (root) element that represents the whole SAML message.

xmlns:samlp is an attribute that communicates two main things:

Namespaces are an XML-specific method for distinguishing between different element names. Any element prepended with a given namespace belongs to that namespace. In this case, xmlns:samlp establishes the samlp namespace, which means that any element names prepended with samlp, like the "samlp:NameID" element, are parts of that same namespace (elements prepended with other namespaces, like “saml:IssuerID” would not belong to the samlp namespace).

protocol-related: The word “protocol” appearing in the string value simply indicates that this is a protocol-related data element.

ProtocolBinding says the SAML request will use an HTTP POST to bind and transfer data to the identity provider.

Destination is the identity provider's endpoint where the request is directed.

AssertionConsumerServiceURL is the auth provider’s callback endpoint, where the identity provider should send the ensuing SAML response to.

Issuer specifies the entity ID of the identity provider that will issue an assertion to the requesting service provider (https://identityprovider.com/123456)

NameIDPolicy specifies the format of the user identifier (NameID) that the identity provider will include in the SAML assertion. In this case, the service provider requires an email address.

In summary, this SAML request is bound to an HTTP POST and is being sent to the specified destination and entity ID within the request. It asserts that it needs an email address in the response when returned to the callback URL. Congrats, you’re now successfully reading SAML.

Structure of SAML responses

SAML responses are a much longer and nastier XML document, because they contain more information. They contain one or more assertions, which include details about the user's authentication status, attributes, and any other relevant information. These responses are created and signed by the identity provider before they’re sent to the requesting service provider for validation. They’re the most important artifact in a SAML authentication flow, since they carry all the assertions necessary for SSO to work.

To examine the structure of SAML responses, we’ll have to break the full SAML response into three parts.

SAML response – part one:




At this point, part one should look familiar. Like the SAML request, the SAML response has a top level (root) element called the Response with attributes like xmlns and Destination, but with updated values. For example, the Destination attribute now specifies the service provider’s callback url that will parse and validate the SAML response.

SAML response – part two:



Part two of the SAML response is where all the relevant assertions start to come in. These assertions give context about the user and how they authenticated with the identity provider. The Assertion element wraps all the data statements, which include:

Subject – the user or member who is trying to authenticate via SSO. Notice how the user’s NameID is an email address (your_user@email.com), the specific format asserted in the SAML request from before.

Conditions – the requirements and rules for the SAML authentication flow. For example, the NotBefore and NotOnOrAfter attributes define a range of time for which the assertion is valid.

AuthnStatement – the information regarding how the user was authenticated by the identity provider. Taking a look at the string value, it seems the user logged in with their password credentials.

SAML response – part three:



And finally, part three contains all the assertions about the user’s identity and profile. These user assertions are called attributes. Common attributes about a user include but are not limited to name, phone, email, location, etc. In our example, you’ll see an Attribute element for:

The user’s name: Ada Lovelace

The user’s phone number: +1 (123) 456-7890

The two groups the user belongs to: Group One and Group Two

These attributes provide a robust profile of a user’s identity. And that’s because attributes are customizable, in the sense that assertions can include about as much information and metadata an IT admin cares to stuff in there. However, it's important to note that each identity provider has its own unique and generally configurable set of attributes for a user, which means the service provider will need to understand how to interpret them correctly.

Adding all three parts together, the SAML response gives a full picture of the authentication flow and the user’s identity. But with multiple assertions and custom attributes, the length and format of the XML starts to multiply in complexity very quickly. However, the service provider must be able to parse and validate all the different variations of SAML syntax and assertions.

Implementing SAML SSO using Stytch



If you’re a B2B company looking to move up-market or already serving enterprise clients that have custom security needs, you can implement the SAML protocol in weeks or even days using Stytch.

Many B2B companies either attempt to build SAML internally or choose auth providers that lack the flexibility needed as they scale. Unfortunately, both approaches end up draining engineering resources and then require even more time to rip and replace.

From our experience, and that of our customers, we wouldn’t advise any engineering team to attempt building SAML in-house. In addition to wasted resources, it’s easy to leave vulnerabilities that could make your infrastructure open to attackers.

However, with Stytch, you can easily and securely configure SAML for your enterprise customers regardless of the identity provider they use within their organization. Using Stytch, you can connect to any SAML-enabled service provider because we can forward AuthnRequests to whichever IdP, and also forward SAML responses back. It’s that easy and straightforward.

Ready to implement SAML SSO with Stytch? Check out our Docs and start coding.

If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our Solutions Engineering team.






---


# Stytch honored with BuiltIn's 2023 Best Places to Work award
Source: https://stytch.com/blog/stytch-builtin-2023-best-places-to-work-award/

Stytch is honored to be featured in BuiltIn's 2023 Best Places to Work Awards, for startup companies in both San Francisco and New York City.

Built In announced today that Stytch has been honored in its 2023 Best Places To Work Awards. Specifically, Stytch earned a place on both New York City’s and San Francisco’s Best Startups to Work For. 

The annual awards program includes companies of all sizes, from startups to those in the enterprise, and honors both remote-first employers as well as companies in large tech markets across the U.S. 

“It’s my honor to congratulate this year’s Best Places to Work winners,” says Sheridan Orr, Chief Marketing Officer at Built In. “These exemplary companies understand their people are their most valuable asset, and they’ve stepped up to meet the modern professional’s new expectations, including the desire to work for companies that deliver purpose, growth and inclusion. These winners set the stage for a human-centered future of work, and we can’t wait to see that future unfold.”



Built In determines the winners of Best Places to Work based on an algorithm, using company data about compensation and benefits. To reflect the benefits candidates are searching for more frequently on Built In, the program also weighs criteria like remote and flexible work opportunities, programs for DEI and other people-first cultural offerings. Stytch is thrilled to be recognized as a Built In Best Places to work award winner. 

We're a results-driven team, but we know we’d be nowhere without our company culture and guiding values: ambition and empathy. We want people with a high degree of ownership and drive to make our product the best it can be, but who also care about their team and support each other in our growth as individuals and as a company. While specialized skill sets are also important, we’ve found that those two values help ground and unite us as a team.





About careers at Stytch



Come work for us! Open positions are listed on our Careers page, along with contact info for us if you have any additional questions. To read a bit more about how we’ve built our team, check out our articles on how we’ve built our engineering team and how we use references in our hiring process.

About BuiltIn

Built In is creating the largest platform for technology professionals globally. Monthly, millions of the industry’s most in-demand professionals visit the site from across the world. They rely on our platform to stay ahead of tech trends and news, learn skills to accelerate their careers and find opportunities at companies whose values they share. Built In also serves 2,000 customers, innovative companies ranging from startups to those in the Fortune 500. By putting their stories in front of our uniquely engaged audience, we help them hire otherwise hard-to-reach tech professionals. www.builtin.com

About BuiltIn’s Best Places to Work

Built In’s esteemed Best Places to Work Awards, now in its fifth year, honor companies across numerous categories: 100 Best Places to Work, 50 Best Startup Places to Work, 100 Best Midsize Places to Work, 100 Best Large Places to Work and Editor’s Choice: 100 Best Hybrid Places to Work. The program honors companies – remote, hybrid and in-office – with the best total rewards packages across the U.S. and in the following tech hubs: Atlanta, Austin, Boston, Chicago, Colorado, Dallas, Houston, Los Angeles, Miami, New York, San Diego, San Francisco, Seattle and Washington DC.

---


# Choosing a B2B auth provider
Source: https://stytch.com/blog/choosing-a-b2b-auth-provider/

A step-by-step rundown of what you need to know and what you need to ask when choosing an auth provider for your B2B app

Welcome back to B2B Auth School. Our mission is to help B2B companies’ uplevel their understanding and implementation of user authentication technologies. Our first series of posts is dedicated to single sign on (SSO). This article is lesson seven, and the final lesson in this series. 

Lesson one | Introducing B2B Auth School
Lesson two | Organization tenancy: the foundation of SSO and B2B data models
Lesson three | What is single sign on?
Lesson four | SSO protocols: SAML vs OIDC
Lesson five | What is OpenID Connect (OIDC)? 
Lesson six | What is SAML and how does it work?
Lesson seven | How to choose your B2B auth provider 

In the previous lesson, we took a close look at Security Assertion Markup Language – the current legacy protocol for handling single sign on (SSO). We looked at SAML’s origins, its benefits, and the anatomy and quirks of SAML messages – including their core components and common challenges and footguns. 

To conclude this series of B2B Auth School, today we’re going to take a step back and walk through the decision of choosing a B2B auth provider – what you need to consider, what you need to ask, and how to choose a provider that will support your product in the long term.

Building your B2B auth profile

Because B2B businesses are so diverse, there’s no one-size fits all checklist for a B2B auth provider. BUT, all B2B companies can arm themselves for conversations with potential auth providers by taking a thorough inventory of their customer’s needs and expectations. 

Hint: it’s not just about SAML vs. OIDC! 

To choose the right auth provider for your B2B company, you need to develop two key customer profiles: one for the customers you have today, and the other for the customers you intend to have in the next year to five years.

1. How do my customers need to operate? How are they organized?

How do they currently handle identity management? Do they use an identity provider that’s on-prem or in the cloud?

Are their organizational and management structures complex? Do they have multiple personas, roles, teams, and departments using your application with different permissions and authorizations?

How do they manage, provision, and deprovision their corporate accounts for their employees? Do they also have accounts for consultants, contractors, and other third-party members?

2. What regulations are important for my customers’ vertical and/or geography? What kinds of data challenges / threats do they face?

Related to the above, are your customers in any uniquely regulated industries like healthcare or finance?

Are they dealing with healthcare or financial data? Bank accounts and/or major financial transactions?

Are they operating in specific geographies like Europe /GDPR, etc.?

Do they have any specific SOC2 compliance expectations (i.e, security, availability, processing integrity, confidentiality, privacy, or some combination thereof)?

Are they or have they been a target for account takeovers or ransomware?

Have they ever suffered a breach before?

What kinds of fraud protections do they currently have in place, and where might they still be vulnerable?

What are the biggest risks that keep their CISOs up at night?

3. What kind of single sign on experience are my customers used to? Where is there room to ease pain points or delight them with something better?

What kind of dashboard / management setup does their IT team use now?

What other auth providers/experiences have they worked with in the past? Who do their other B2B vendors use and what has their experience been?

Where have they encountered the most friction/greatest cost of engineering time with B2B vendors?

Do they have any unique needs or expectations around approved domains or just-in-time provisioning?

What kinds of metadata do they expect to be able to communicate during authentication transactions?

4. What kind of experience do your end users (i.e., customer org members) expect?

What kinds of devices are they on?

Are they dispersed across different time zones, geographies, native languages?

Are they typically accessing applications through their identity provider? Or do they prefer to go directly through their service provider?

What kind of authentication flow are they accustomed to? Which multi-factor methods are they already familiar with (if any)?

Once you’ve answered all these questions for your current customers and prospects, you should do it again – this time for the customers you want to go after in the next few years. Too many B2B companies we’ve talked to think of auth as a “set-it-and-forget-it” feature, but the reality for many startups and smaller companies is that their auth needs will change, and the sooner they take stock of that, the better positioned they’ll be to scale efficiently and avoid headaches down the road. 

For this, they need more than an authentication provider – they need an authentication partner.



B2B auth checklist – what you need to build

Once you have a clear profile of your customer’s B2B auth needs, it’s time to take stock of your own resources. Whether you decide to build B2B auth in-house or go with an outside provider, to be an informed collaborator in the process you should make sure you have a solid understanding of the full-breadth of the B2B auth tech stack. Looking back at our series, that includes the following:

Are you prepared to support organization tenancy?

How will you define organizations and organization membership? Your data model can change drastically depending on what use cases the application supports. You need to consider how you’re going to guarantee data isolation, what structure you need to store the metadata in, if there can be sub-organizations, etc.

How will you handle org discovery? – email domain, manual entry, etc.?

How will you manage membership and roles? Will your product allow members to belong to multiple organizations?

How will you handle various authentication/authorization settings, like account deduplication, just-in-time provisioning, etc.?

Do you understand SSO auth flows?

Do you have a solid understanding of the different roles and components of SSO? Ie., the roles and responsibilities of an identity provider, service provider, etc.?

Do you understand the differences between IdP- and SP-initiated SSO? And the risks involved with each?

Do you have a detailed grasp of the various transactions managed by the auth provider? This includes identity authentication, session management, and informational exchanges with both the identity provider and the service provider.

Do you understand the value SSO provides to your B2B customers, and where you can enhance and differentiate that value?



Do you know the protocols that facilitate SSO and the differences between them?

What are the origins of OIDC and SAML? And what needs did each arise to fulfill?

What is OIDC? And why are its roots in OAuth and use of JSON important?

What is SAML? Why is it the legacy protocol, and what are the implications of being XML-based?

What are the common customer profiles for OIDC vs. SAML? And is it worth it providing both? (Hint: almost certainly!)

Do you understand each protocol (SAML, OIDC) in enough depth to implement?

With OIDC…

How does OIDC build off of OAuth to offer authentication and authorization? Where do these two protocols diverge and complement each other?

How do the roles and functions differ between resource owners, relying parties, resource servers? How do those mirror terms from SAML?

What’s the role and anatomy of bearer tokens? What are best practices for using them?

With SAML…

What are the different data elements in SAML? How do they relate to each other?

What is the anatomy of a SAML message? What are the key differences and components of requests and responses?

What are XML/SAML’s common footguns, and how can you best avoid them? Which are specific to SAML, and which are vulnerabilities of XML more broadly?



Auth partner vs. auth provider – a future-forward approach

At the beginning of this series, we talked about B2B auth as a crucial growth lever: the easier you make it for your customers to manage their employees’ accounts and onboarding to your application, the more likely you are to land upmarket sales and see widespread adoption. 

Authentication is often framed as a pure security consideration. But authentication touches many different parts of your product and involves several customer touchpoints – especially with B2B companies. These touchpoints and product features also look very different as companies scale: the needs of startup B2B customers are very different from the enterprise. 

That’s why when working with an authentication or SSO provider, B2B companies should find someone that’s not just looking at what their customers today need: they want an auth provider that’s able to predict upmarket needs so that authentication becomes an enterprise catalyst that accelerates a B2B company’s growth. 

The decisions you make today about your authentication solution could have long-lasting effects that either hold your product up, or launch it into a bigger, brighter future. 

If you want to talk to an auth expert about the right data model and auth solution for your B2B product, chat with one of Stytch’s auth experts today. 

Congrats on finishing your first “course” in B2B auth school! 

---


# JWTs vs. sessions: which authentication approach is right for you?
Source: https://stytch.com/blog/jwts-vs-sessions-which-is-right-for-you/

JWTs vs. sessions: which authentication approach is right for you?

Your application just received a login request, and the credentials passed successfully to prove the identity of a user in your system. Wonderful, you have a high degree of confidence in who this user is and what they should be able to access!

But wait, what happens on the next API call where they don’t include their login credentials?

HTTP is stateless, meaning that each request is independent and doesn’t contain any context about previous requests, but asking your user to re-authenticate on every request isn’t exactly a friendly UX.

Session cookies and JSON Web Tokens (JWTs) are the two most popular ways to maintain this authentication state between calls. There are pros and cons to both, and choosing between them requires understanding these tradeoffs and how they relate to the specific needs of your application.

Session-based authentication

In session-based authentication (also known as cookie-based authentication), the server is responsible for creating and maintaining a record of the user’s authentication and providing a way for the client to reference that record in each subsequent request.

This flow starts by the user authenticating and providing some credentials to the server for verification. If the credentials are accepted, the server will create a persistent record that represents this authenticated browsing session. This record will have some sort of primary identifier (typically a random string that is at least 128 bits long) in addition to an identifier for the user, the time the session started, the expiry of the session, and perhaps context information like the IP address and User Agent. This information will be stored in the database, and the session identifier will be sent back to the client to be stored as a cookie in the user’s web browser.

Each subsequent request from the browser will include the session cookie in the HTTP headers, which the server can then use to look up the session record, confirm that it is valid and then make authorization decisions about what information to return based on the confirmed identity of the user.

The benefits of session cookies

The appeal of this approach is in its simplicity and reliability.

The database record of the session serves as a clear, centralized source of truth for the state of the session, which allows for a high degree of confidence that the session information is up to date and can be used to make authorization decisions. Revoking a user’s access to the system is quick and reliable with sessions, as you can simply delete the session record from the database or mark it as invalid. For any subsequent requests after revocation, the server will fail to find a valid session that matches the identifier in the headers and will return a 401 unauthenticated error to prompt the user to re-authenticate.

By offloading the state management to the server, we are able to reduce the data transfer overhead down to a single opaque string, which is lightweight and does not leak any information about the associated user or the context of the session.

The downside of session cookies

While session-based authentication is very reliable, at scale it can begin to introduce latency and performance issues.

Since you need the session record to be highly reliable and accessible from any host, this means inserting a write request to the database for every authentication and more importantly a read request to the database for every subsequent request that contains the session header. Since session expiry is often extended with constant use, this can also mean an additional update on every request. Over time all these database interactions can add up, and introduce notable latency across your application.

For applications that have highly dynamic clients, this latency overhead might not be worth the benefits that session-based authentication provides.

JWT authentication

JSON web tokens (JWTs) achieve similar goals of identifying and authorizing the logged-in user during subsequent requests, but solve the problem of how to manage that information in a very different way.

This flow also starts with the user providing some form of credentials that the server uses to authenticate that particular request. However, while the session-based flow relies on storing all the necessary state in a database and looking it up on every request, in the JSON web token flow all that context is self-contained in the string being sent back to the client.

At a high level, JWTs are JSON objects that follow a particular protocol for communicating “claims” or authorization context, and are then either signed or encrypted by the issuing server in order to provide assurance that these claims can be trusted. Clients can verify that the JWT has not been tampered with since the signature of the JWT contains the original header and payload data.

JWTs consist of three parts – the header, the payload and the signature.

The payload contains the core claims, such as the identity of the user the JWT was issued for, the permissions that the token might grant, and the expiry of the JWT, which indicates the time after which the JWT should no longer be accepted. The header contains information about the algorithm used to sign or encrypt the token. The header and payload are then base64url encoded, which makes the value easier to send and store. Since this is just as easy to decode, it means that the information stored in them can be viewed by anyone.

The signature is created by combining the header and the payload and then hashing that combination with a secret key, providing a way to detect if a malicious actor has tampered with the claims after the issuer signed the JWT. In distributed systems, this is typically an asymmetric signature, where the issuing server will use a private key to hash the contents and then the audience can use the corresponding public key to verify that the current payload is the same one that was signed by the issuer.

Once the JWT is constructed and signed, it is sent back to the client to store. This JWT can be used safely for authorization by verifying that the expiry has not passed and the signature is valid for the payload provided, all of which can be done on the client without checking with the server who initially issued the JWT.



The benefits of JWTs for authentication

JWTs contain all the information required to both verify the authenticity of the claims, as well as the information you’d need about the user to make authorization decisions. This self-contained quality of JWTs means that there is no longer a dependency on the server and database in order to validate the token and feel confident in making authorization decisions for the identified user.

There are several advantages to this, most obviously, a reduction in latency for your application since client-side authorization is possible and server-side authorization can happen much faster without a call to the database.

The other advantage is that it opens up a wider range of possible applications that can sign, verify and leverage the identity information and authorization granted through the JWT. Signatures and self-contained data make it possible to develop server-to-server applications that programmatically self-sign tokens and refresh them without needing manually entered credentials. In addition, the flexibility of the claims allows you to communicate other important information to these external applications within the token itself. This can be very useful when exposing APIs to external applications.

The downside of JWTs for authentication

The self-contained, stateless nature of JWTs has a significant downside though – once a JWT is signed, there is no way to invalidate the JWT or update the information contained within it. Provided the signature is valid and the expiry timestamp has not passed, the JWT will be considered valid by any process leveraging it for authorization decisions.

If a user requests to log out of all devices, there is no practical way to honor this request through local validation before the natural expiry of all currently issued JWTs. In theory, JWTs can also be invalidated by revoking the secret key used to sign the JWT but that would invalidate all JWTs that used that key and would require handling to evict any cached validation keys, making secret key revocation an unsustainable option for something as simple as a user log out.

Similarly, in the case where the JWT contains role-based authorization information (such as “admin” vs “member”), if the user is downgraded to a lower role that reduces the scope of what they are allowed to access, this change in authorization permissions would not be reflected until their existing JWTs expired.

JWTs versus sessions cookies

As we have seen, both JWTs and session cookies are viable approaches to solving the issue of persisting authentication and authorization context in a stateless HTTP world, but they take fairly different approaches that have their own pros and cons.

JWTs enable faster authorization and more interoperability with external apps, but they demand more developer investment to address their security complexities, and might not be the best fit for applications that enable access to sensitive data or actions.

On the other hand, while sessions provide stronger guarantees that each individual request is authorized and are simpler to implement securely, their bottleneck on the server-side database validation comes with a latency overhead that might ruin the user experience for highly responsive applications.

While there are maximalists out there who will tell you that one approach is always superior, at Stytch we recognize that every application is unique and the security and latency tradeoffs need to be evaluated in context.

Using a combination of session cookies and JWTs

For those looking to blend the performance benefits of JWTs and the security benefits of session cookies, Stytch’s session management product offers a powerful hybrid option that can be customized for your particular needs.

An extremely security-conscious organization, like a bank or government agency, might want to just use session cookies in order to ensure that every single call is authorized at that exact moment. Other applications might want the performance improvements of being able to do client-side JWT validation but do have some sensitive actions that require a source of truth to check in with before granting access. Applications without any sensitive info might value the performance benefits of JWTs and almost never want to ask their users to re-authenticate, but still want to be able to honor explicit logout requests.

When you’re using Stytch session management, you can configure the duration of a user’s session, which defines how long Stytch will keep the session active before prompting the user to re-authenticate. Stytch will return both a session_token, which is a static value that is good for the lifetime of the session, as well as a JWT that is associated with the underlying session but has its own, shorter lived, expiry of 5 minutes. Expired JWTs can be passed to the Stytch session API in order to retrieve a fresh JWT, and the Stytch servers will ensure that the underlying session is still active before passing back a new JWT. If the user logs out, this revocation of access will take place within a maximum of 5 minutes. If you have a particularly sensitive route, you can configure the Stytch client libraries to have an even more restrictive max_token_age which Stytch will use to request a new JWT, lowering the threshold for potential staleness even further.

This solution allows for a nice balance between performance and security. Getting started with session cookies is easy and secure. But as your app scales, you may start to notice the latency of the required API call. JWTs can help you reduce the number of calls you need for non-sensitive routes. If the API call only needs to happen every 5 minutes or before granting access to particularly sensitive actions, this greatly reduces the performance overhead while also protecting you and your end users from the risk of authorizing actions based on stale information.

Conclusion

While there may never be a clear consensus on which method is superior, the good news is that Stytch provides both options, with the ability to configure the perfect blend of latency vs security for your particular use case. Stytch is a modern authentication and fraud platform that lets you abstract over complexity and enables developers to choose what works for them. This choice includes the ability to switch between JWTs and session cookies as needed.

Regardless of your developers’ favored approach, Stytch makes authentication easier and more secure. Read more about how Stytch can provide simple and secure implementations out of the box, or take a look at how you can use the Stytch platform to build frictionless, secure authentication flows.

---


# Stytch Talks with Jaren Glover: Building high-powered engineering teams
Source: https://stytch.com/blog/stytch-talks-with-jaren-glover/

Five key takeaways on hiring and nurturing top engineers from our interview with Jaren Glover.

Assembling and growing a talented engineering team is a critical process that has an immediate impact on a company’s potential — especially for fast-growing startups. 

For our second Stytch Talks session, Stytch co-founder and CTO Julianna Lamb sat down with Jaren Glover, a seasoned software engineer, early stage investor, and advisor. Glover spent over five years as an early hire at Robinhood, where he helped scale their team and infrastructure as the platform ballooned from 150 thousand user accounts to over 22 million. He has a rich history of partnering with founders such has Parafin, Metronome, Arcade, and Stytch. He is now spending time investing and advising at the earliest stages – he has been a great partner to us! 

They discussed the growing pains that often accompany the early years of success, as well as the natural tradeoffs that arise as a startup makes its first major engineering hires. 

Below, we recap five of the key lessons and observations Glover and Lamb shared from their own experiences — along with their top tips for building a best-in-class engineering team to enhance both productivity and day-to-day culture.

1. It’s not just about thoughtful recruiting, but thoughtful onboarding.

“Always be hiring” isn’t just an expression. Finding qualified engineers — especially for specialized projects like your core infrastructure — can be challenging in the current landscape, and it’s important to keep your pipeline rich. 

Based on his time at Robinhood, Glover suggests going beyond recruitment. It’s not just about discovering top talent out in the field, but supporting the talent you already have and nurturing tomorrow’s high performers with a well thought-out onboarding process.

“At times, we were trying to find a needle in the haystack, when we should have been trying to hire new grads and create safe areas and guardrails for them to be able to evolve within the organization.”

A solid onboarding system begins with creating a culture of mentoring and accountability. The quality of an individual employee is almost always related to the quality of the supervisor who trains and evaluates them. Provide a foothold for new hires, and give them the opportunity to grow from smaller wins to more elaborate tasks to build their confidence and trust — with clear benchmarks and expectations in place. 

Most importantly, ensure everyone follows the same process, whether they’re fresh out of school or an established engineer from a big-name company.

2. Root your interview loops in reality.

If you want to suss out high-quality talent, avoid interview questions and assignments that aren’t relevant to the work you actually do. It may be impressive if a candidate can rattle off complex algorithms, but it doesn’t necessarily demonstrate how they’ll perform as a member of your team. 

Instead, introduce strainers that tackle problems you see in your day-to-day activities, like basic metric collection exercises. In the next round, you can spike from either an architecture or coding perspective to measure a candidate’s depth. As Glover points out, you should also run candidates through a project deep dive, which is the ultimate way to gauge how they’ll work as part of a team.

“The project deep dive is super important, because you need to be able to communicate with your peers. It turns out, you can be a really great engineer, but if you can’t work with someone, it’s not really a good exercise.”

Ideally, interviews should closely mirror problems and an environment that’s true to life. Ensure that the problems you’re asking candidates to solve are ones that will be truly indicative of their ability to solve the problems you’ll need them to do on the job. Above all, don’t let your interview loops grow stagnant. Make sure you’re constantly working to fill gaps in your method and keep up with best practices. If possible, work with a recruiter that can help you not only source promising new engineers but identify why any candidates are dropping out of the process.

3. Reward employees with meaningful incentives.

This one is simple. Incentives matter, and they start right from the top, right from day one. Whatever you reward employees for — either explicitly or implicitly — in your company’s early days will naturally spill over across the organization and into future projects, and your team will always reflect (and expect) those initial standards. 

For Glover, it’s a founder’s responsibility to establish what matters and to reward and incentivize employees accordingly. That means establishing how employee performance is evaluated, finding meaningful ways to acknowledge employee achievements, and codifying and applying that system fairly and consistently across different engineering teams (whether product or reliability).

“A strong set of founders can really turn an okay opportunity into a great opportunity, and a great opportunity into an exceptional opportunity.”

Keep in mind, incentives aren’t just about one-off perks like bonus checks, gift cards, and PTO. Employees also value — and may even prefer — immeasurable rewards like internal recognition, whether a shoutout in a shared forum or meeting or a crystal clear path to a promotion.

4. There’s an art and a science to scaling your engineering leadership.

One of the hardest parts of building an engineering team is knowing when and how to add in layers of management. On the one hand, you need to plan ahead and ensure you have the right leadership and resources in place as you grow. On the other hand, you don’t want to jump the gun and get to a point where you have too many people managing and not enough people doing. 

There are two key inflection points when strategic scaling is critical:

Going from zero to one: Introducing your first engineering manager can be daunting. Glover recommends hiring this initial role internally, due to the social capital that’s already been built up among your team. That said, it’s also smart to get external assistance from a coach or advisor — preferably from among your cap table and other entities that know your organization well — to support and guide your new leader.

Hiring the VP: The real question here is, do you need a VP of engineering, or are you actually looking for a head of engineering? Don’t be afraid to delay the VP role if you’re not ready, and focus on getting your first tier of managers right. You can always elevate an engineering manager or head if the right person comes along. When you do appoint a VP, be rigorous with your 30/60/90 evaluations, and be honest if it’s not working out. A VP can make or break an organization—and you want them to make yours great.

Two final words of wisdom:

First, whenever possible, promote from the inside. It sends a positive signal to your standing engineers that efforts will be rewarded — but make sure they also have technical opportunities to grow outside of a management track. 

Second, always check the references. It can be tempting to scoop up leaders from top tech companies when they show interest, but it’s more important to know that they’ll be a good fit.

5. Know what the best engineers are looking for.

Glover doesn’t just consult for leading startups, he also advises many up-and-coming engineers. If you’re looking to put together a winning team, it can be just as crucial to know what your top candidates are looking for in you. Be transparent, and encourage open, honest conversations about what your organization has to offer, from risk profiles, term sheets, and compensation, to your company’s culture and opportunities for professional growth. It not only creates a foundation of trust, it sends a strong message about the progress and promise of your business. That extends to founders, who are the beating heart of an organization and the best equipped to express the passion and purpose behind its work. Those who are not only accessible but excited to engage with the next generation of engineers are the ones who reap the benefits of proud and productive teams.

Looking to build a best-in-class engineering team?

Check out our YouTube channel to watch the full Stytch Talks interview, or follow Glover’s latest insights and investing tastes through his website or on his Twitter, LinkedIn, or GitHub feeds. If you want to learn more about Stytch’s approach to team-building, read through our Founder’s Guide to Hiring Engineers — or, if you’re interested in joining our growing team, browse our current list of open positions.

---


# Balancing security and adoption: preventing account takeover fraud with multi-factor authentication
Source: https://stytch.com/blog/prevent-account-takeover-with-multi-factor-authentication/

Find out how to strike the right balance between keeping your users' data safe and making it easy for them to log in using multi-factor authentication.

Since 2017, hackers have stolen 555 million passwords on the web. As a result, most security professionals consider passwords to be “pre-breached” when designing identity and access management for their applications – when you onboard a user, you have to presume that the password they’re using is either already compromised or likely to become implicated in a future data breach (after all, 45% of US companies suffered a data breach in 2021 and this figure continues to rise). In today's digital landscape where we have to assume that a user’s password is or will soon become compromised, multi-factor authentication (MFA) is a necessity for protecting against account takeovers and fraud. 

However, as an engineer, it can be challenging to determine which MFA options for your application strike the right balance between security and user adoption. Effective MFA adoption is dependent upon consumer access and usability, which is why we continue to see the popularity of less secure options like SMS passcodes far outpace phishing-resistant options like hardware keys or device-tied biometrics. In this post, we'll take a closer look at the different MFA options available, their relative security, and how to increase user adoption. 

To ground this discussion in real-world data, we'll draw upon Coinbase’s recent "Authentication Matters" article which shines a light on MFA types and the associated account takeover fraud. In this article, Coinbase provides detailed statistics on the cryptocurrency exchange’s customer adoption rates of different MFA options and the associated account takeover rates. It’s rare and commendable for a company to offer this level of transparency, and we believe that this data can be valuable for other engineers considering which MFA options to support and how to promote user adoption to prevent account takeover.

Coinbase’s case study: why the most popular MFA option isn’t the most secure

Coinbase’s data provides a great case study on both MFA adoption and security. Coinbase stores cryptocurrency on its exchange, which makes it a uniquely valuable account for hackers to target due to both the monetization potential and the irreversibility of cryptocurrency transactions on-chain. In other words, a hacker can make a lot of money off of a stolen Coinbase account. As a result, Coinbase requires all users to have MFA, but they provide multiple options:

SMS one-time passcodes (OTP)

Time-based one-time passwords (TOTPs)

Push notification via their app

Physical security keys (e.g. YubiKey)

And their experience with both adoption and account takeover fraud rates illustrates the relative benefits and drawbacks of these various methods. For example, Coinbase discovered that their most popular 2FA option with users (SMS passcodes) is also the least secure – 95% of users opt for SMS, but this also accounts for 95% of successful account takeover attacks.



A particular MFA type’s user adoption rate being correlated with account takeover rate isn’t surprising in a vacuum, but it is more of an indictment of SMS 2FA when you consider Coinbase’s attack surface and hackers’ incentives. The majority of customers’ funds on Coinbase (57%) is held in accounts that are protected by a 2FA option other than SMS (either TOTP, push notification, or a physical security key). From a hacker’s perspective, they are most incentivized to target user accounts that hold larger amounts of crypto if the effort to attack those accounts is similar.



However, these larger accounts are seldom stolen by attackers because of the increased effort involved in breaking the MFA types that these customers use. Coinbase found that for these accounts using advanced MFA (TOTP, push notification, or security keys), only 5% of all account takeovers were successfully executed against these users. And of these rarer account thefts, 86% are concentrated on TOTP and push notification MFA, which unlike security keys, are not “phishing-resistant." 

Despite most Coinbase customer funds being protected by advanced MFA, only 5% of those accounts are stolen due to the increased effort involved in attackers’ trying to break those MFA methods. Meanwhile, SMS 2FA protects only 43% of Coinbase customer funds but comprises nearly all (95%) of account takeovers.



Evaluating MFA options: Advantages and disadvantages of commonly used methods

When it comes to MFA options, there are several available, each with its own set of advantages and disadvantages. Every application is different, but most should be offering multiple MFA options to promote both maximum adoption and advanced security options. 

When considering which options to offer, here’s some important considerations for each MFA method:

SMS One-time Passcodes: This is the most basic form of MFA, where a user receives a one-time passcode via text message.

Pros: This option is familiar and easy for users. It offers a particularly seamless experience on mobile due to the auto-fill capabilities on iOS and Android that allow a user to stay within the application experience when inputting the passcode.

Cons: SMS 2FA is vulnerable to both reliability issues (it’s dependent on a single point-of-failure – the SMS provider – for the authentication) and security concerns. The major security shortcomings are phishing – where a user is deceived into sharing the passcode with an attacker – and SIM-swap attacks. A SIM-swap attack is a type of cyber attack in which a malicious actor convinces a mobile carrier to reassign a mobile number to a SIM card they control. Once they have control of the number, they can use it to reset the victim's password on any account that uses the phone number as a form of verification and gain access to sensitive information such as bank accounts, emails, and social media profiles. This type of attack is particularly concerning because it can bypass most two-factor authentication systems that rely on text messages.

Time-based One-time Passwords (TOTP): This option uses an app like Duo or Google Authenticator to generate a time-based password (or passcode), eliminating the dependency on a customer's mobile carrier.

Pros: TOTP isn’t dependent on mobile carriers, so there’s no deliverability issues or SIM-swapping concerns.

Cons: This option requires users to have their mobile phone with them and can be a bit more complex to set up due to the need to download an application. Phishing also remains a key risk as a user can still be convinced to pass the code along to an attacker – this phishing risk is shared by SMS, TOTP, and Push notification and it explains why these three MFA methods account for 99.96% of all Coinbase account takeovers.

Push Notifications: This option sends a push notification to a registered and authenticated device, which the user must approve before logging in.

Pros: This option is convenient for users, but it requires them to have their device with them and have a stable internet connection. It’s been made more familiar for users through examples like Gmail promoting this method.

Cons: From a security perspective, phishing is the primary concern here as a user can be tricked into clicking a push notification to grant access or may accidentally do so when on their phone. This method also requires users to have their device with them and have a stable internet connection (TOTP and hardware security keys do not require internet connection).

Hardware Keys: This option uses a physical security key, such as a YubiKey, as the second factor of authentication. However, it can be more expensive and may require additional setup steps for users.

Pros: This is considered the most robust form of MFA as it is phishing-resistant and requires a physical device to access the account.

Cons: It’s more expensive and complex for users to initially set up a security key (for example, a YubiKey costs $50), which is why consumer adoption remains quite low.

Biometrics: This option uses a fingerprint or facial recognition as the second factor of authentication.

Pros: It is considered more secure than SMS one-time passcodes, TOTP, and push notification due to being resistant to phishing attacks, and it has the consumer benefit of being more familiar, convenient, and cheaper than setting up a physical security key.

Cons: It requires users to have a device with a biometric sensor. Additionally, some users remain skeptical of biometrics due to the misunderstanding that their biometric data is accessed and stored by the application.

Effective MFA requires maximizing user enrollment

In conclusion, choosing the right MFA options for your application requires a balance between security and user adoption. By understanding the relative security and adoption rates of different MFA options, engineers can make informed decisions that protect their users while also ensuring maximum adoption. By studying examples like Coinbase, engineers can gain valuable insights into the effectiveness and uptake of different MFA options. While some MFA options are superior when it comes to security, the theoretical security model of any particular MFA method is useless if users find it too friction-heavy to enroll in that MFA option. 

The pragmatic path typically involves offering multiple MFA options to your user base and explaining the security benefits of enrolling in more advanced and phishing-resistant MFA. At Stytch, we’re particularly excited about the promise of new authentication technologies like passkeys, which provide many of the usability benefits of conventional MFA like SMS 2FA while also providing the security benefits of physical security keys like YubiKey.

About Stytch

With multi-factor authentication from Stytch, you’ll get the security protection your application needs, to prevent account takeovers, with a UX that will delight your users. Stytch offers a suite of MFA solutions that offer maximum flexibility and security while maintaining a great customer experience. Check out our products, explore our Docs or talk to an auth expert today!

---


# TOTP vs SMS: Which one is better for two-factor authentication (2FA)?
Source: https://stytch.com/blog/totp-vs-sms/

A side-by-side look at SMS one-time passcodes vs. time-based one-time-passcodes, and how to choose the right 2FA method for your product.

With the staggering number of data breaches in recent years - 45% of US companies alone suffered a breach in 2021 – it's become clear that traditional passwords alone are no longer a sufficient form of security for preventing account takeovers. Hackers have stolen over 555 million passwords since just 2017, which is why security professionals now view passwords as "pre-breached" when designing identity and access management policies. 

Multi-factor authentication (MFA) is a crucial solution for this problem, but it can be difficult to determine which options are the most secure and user-friendly for a particular application. SMS 2FA (which uses one-time passcodes), for example, are less secure but more widely adopted by consumers, while phishing-resistant options like hardware keys or device-tied biometrics are more secure but less adopted. 

In this post, we'll examine the two most popular MFA options today (SMS 2FA and TOTP 2FA) , their relative security levels, and strategies for increasing user adoption.

Pros and cons of SMS and TOTP 2FA

SMS-based 2FA is the most widely used type of 2FA. It works by sending a one-time code to your mobile phone via text message, which you then enter to access your account. This option is familiar and easy for users. It offers a particularly seamless experience on mobile due to the auto-fill capabilities on iOS and Android that allow a user to stay within the application experience when inputting the passcode. 

However, SMS 2FA is not considered as secure as TOTP-based 2FA. The major security shortcomings are phishing – where a user is deceived into sharing the passcode with an attacker – and SIM-swap attacks. A SIM-swap attack is a type of cyber attack in which a malicious actor convinces a mobile carrier to reassign a mobile number to a SIM card they control. Once they have control of the number, they can use it to reset the victim's password on any account that uses the phone number as a form of verification and gain access to sensitive information such as bank accounts, emails, and social media profiles. This type of attack is particularly concerning because it can bypass most two-factor authentication systems that rely on text messages. In addition to these security concerns, SMS 2FA also involves reliability risk as you’re dependent on mobile carriers (and a SMS provider’s uptime) for delivery of the authentication code. Provider downtime or poor cell coverage can both complicate reliability of this method. 

TOTP-based 2FA, on the other hand, uses an app on your smartphone to generate a one-time code that changes every 30 seconds. To access your account, you need to enter the current code displayed in the app. TOTP-based 2FA is considered to be more secure than SMS-based 2FA because it is less susceptible to intercepts and spoofing. Additionally, TOTP-based 2FA does not rely on a phone number, so it can be used with any device that has the app installed.



TOTP vs. SMS: Why Is TOTP more secure than SMS?

Both SMS 2FA as well as TOTP 2FA use unique passwords to secure accounts. With SMS 2FA, the server generates and sends the random code to the phone of the user. Those codes will expire after use. Pending codes remain in effect for the amount of time the application sets (often at least a couple minutes to allow ample time for the user, but the maximum is typically bound at 10 minutes to reduce the attack surface). If the code is intercepted through a SIM-swapping attack, this allows for attackers to break into users' accounts. 

In contrast, TOTP token-generated codes generate every 15 to 20 sec and are only available in a device-tied application, which removes the SIM swap attack and reduces the potential time frame of attacks significantly. When the new TOTP code is generated, the previous code will be automatically invalidated. Both TOTP and SMS 2FA are susceptible to phishing attacks though, where a user is tricked into forwarding a code to an attacker. 

With SMS, it’s only necessary for the user to manually enter the OTP into the browser. On mobile, the SMS 2FA workflow is considerably easier due to the OS auto-fill capabilities mentioned above.

How TOTP 2FA trumps SMS 2FA

Both SMS and TOTP add another factor to the authentication process to protect users against unauthorized brute-force attacks. SMS 2FA is, however, using static codes which expire once they are used or not reused within ten minutes of sending. A fraudster may already have access to the user’s phone number through a successful SIM swap, or they may be able to convince a user to forward their code (often by acting as a fake support agent) within the valid 10-minute window. 

With TOTP, there’s no SIM swap risk because the TOTP application is tied to the user’s device (rather than being tied to their phone number). Additionally, the more ephemeral nature of the generated passcode with TOTP makes phishing attempts materially harder as an attacker has often 1/10th or 1/100th of the time available to them to convince a user to forward a valid code.

The two-factor authentication winner

In summary, SMS-based 2FA is easier to set up and use, but it is not as secure as TOTP-based 2FA. TOTP-based 2FA is more secure but requires an additional app to be installed on your smartphone. Ultimately, the choice between the two will depend on your individual needs and the level of security required for your specific use case. 

To ground the differences in real-world data, let’s consider Coinbase’s public data on MFA method popularity and account takeover rates. While only 43% of customers’ funds are protected by SMS 2FA, 95% of successful account takeovers exploit weaker SMS-protected accounts. In contrast, advanced MFA like TOTP protects the majority of Coinbase’s customer funds but only accounts for 4.13% of successful account takeover attacks.



Table from Coinbase shows how often different authentication types are targets for account take overs (ATOs) proportional to each other. 

When choosing a 2FA solution for your organization or personal accounts, make sure to evaluate the security and usability requirements and choose the one that best fits your needs. Ultimately, the best MFA strategy is the one in which your users actually enroll in MFA – one approach is to offer both options to users but encourage users to select the more secure method.

FAQs: Two-factor authentication (2FA)

What is the difference between OTP and TOTP?

One-Time Passcodes (OTPs) are unique and temporary codes sent to a user via SMS, WhatsApp, or email, and can be used as the primary auth factor or as a two-factor authentication to strengthen security. Time-Based One-Time Passwords (TOTPs) are unique time-based codes generated by authenticator apps, like Google Authenticator. The app is tied to a user’s device, preventing issues like SIM swapping, which can occur with SMS One-Time Passcodes. TOTPs are typically only used for 2FA.

Is SMS better than an authenticator app?

SMS-based passcodes are a commonly used solution but while it is easily accessible, it isn't the most reliable. Authentication apps are a second-level authentication solution that is safer, more reliable, and fast.

Is TOTP more secure than HOTP and SMS?

Hardware One Time Passscodes (HOTP), otherwise called physical security keys, are more secure than either SMS or TOTP 2FA. BUT, they historically have very low adoption because only extremely tech savvy individuals are willing to buy a hardware security key like a YubiKey.

What is the benefit of TOTP?

Time-based passwords available offline offer streamlined user protection for the second factor in the user experience. Similarly, TOTP can be referred to in applications or as a scalability token. The API for the authentication of applications is based on the TOTP standard.

---


# The FIDO alliance and a passwordless future
Source: https://stytch.com/blog/fido-passwordless-authentication/

An overview of the FIDO alliance, their important work in building a passwordless future, and why Stytch became a member.

Stytch is thrilled to announce that as of 2023 we are now part of the FIDO alliance. In this article, we’ll discuss what FIDO is, why they’re important in the world of authentication, and why we joined.

What is the FIDO Alliance?

The FIDO Alliance is a nonprofit that began developing and improving security protocols to reduce the overreliance on passwords. In 2009 PayPal discussed its proposal for using biometrics as an alternative way to authenticate users, instead of using passwords. These conversations inspired a new industry standard for passwordless access using public-key cryptography and local logging technologies. In 2012, the FIDO alliance (Fast Identity Online) was formed.

Why is FIDO authentication passwordless?

We’ve written about the advantages of passwordless auth at length at Stytch – including the weaknesses of passwords, how to introduce passwordless options to password-familiar users, an overview of passwordless auth methods by business vertical, and more. But in a nutshell, passwords…

1. Aren’t secure enough

According to Verizon’s Data Breach Investigations Report, passwords or compromised user credentials have been the cause of over 80% of breaches. With the sophistication of phishing attacks and credential stuffing techniques, passwords as a security technology are no longer enough to protect our accounts and information. Even with newer developments with two-factor or multi-factor authentication, they're simply too easy to compromise.

2. Create friction for users

One of the reasons passwords are so insecure is that they’re hard to remember, and most users don’t receive good guidance about how to make passwords secure. Account creation and password reset flows tend to be long and convoluted, meaning users bounce from sites or abandon carts far more than they would if there were an easier way to sign up or log in. With passwords proving to be a let-down in both security and user experience, it’s easy to see why an alliance formed to create a better alternative.

How FIDO pursues a passwordless future

Since its founding, the alliance has pursued its passwordless mission by:

Technical specifications: FIDO develops open and interoperable tech specs for passwordless solutions to make it as easy as possible for companies to wean themselves off of passwords and pursue more secure, user-friendly alternatives.

Certification: FIDO runs certification programs that maintain quality and oversight of passwordless adoption.

Standardization: Once mature, FIDO submits their technical specifications to standards development organizations to get their specs standardized and popularized in the dev community at large.

FIDO passwordless authentication technology – how it works

While we’ll be publishing a deeper dive into the ins and outs of this technology later on this quarter, at their core all FIDO technologies rely on public key cryptography to both identify users and keep their information secure.

Public key cryptography

Public key cryptography is an encryption scheme built around the relationship between two unique keys—a public key that encrypts the data, and a private key that decrypts it. What makes this kind of cryptography more secure is that while the public key is stored on the server (and thus fairly easy for others to access), the private key is stored either on the user’s device or on a hardware security module like a USB or biometric scanner. When a user authenticates, the private key sends a message with a unique signature to the public key, which then decrypts access to the server.



WebAuthn

After developing some initial standards and specs based on public key cryptography, FIDO wanted to find a way to make their passwordless methods more widely available. To do this, they started to work on new technical specifications that enabled FIDO authentication methods to be called directly in browsers and platforms via APIs. The most well-known of these API-based specs is called FIDO2: Web Authentication, or WebAuthn. Initially released in partnership with the World Wide Web Consortium (W3C) in 2019, WebAuthn has quickly become one of the most important advances in popularizing passwordless authentication because of its ability to be easily adopted and integrated by a much wider community of web browsers and applications.



Common WebAuthn applications

While you might not be familiar with the inner workings of FIDO2 or its technical specifications, you have probably encountered FIDO specs in the wild in one of three main ways:

In-device biometrics

If you’ve ever used your phone or computer’s thumbprint reader to log into an app or website from that device, you’ve used in-device biometrics. In-device biometrics – sometimes also referred to as a “platform authenticator” – verify both possession of the user’s original device and biometric proof in the user’s facial ID or fingerprints. That strength though is also its weakness: because in-device biometrics are by definition device-specific, they are somewhat limited for users who live their online lives on multiple devices.

Yubikey

Yubikeys are a small piece of hardware you can plug into a number of devices that exchange public and private key information with various apps on that device. They are referred to as “cross-platform authenticators” because, unlike platform authenticators that are tied to a particular device, the hardware key can be moved from one device to another and retain your authentication method. Similar to device biometrics, Yubikey's strength is also its downside: if you lose your key, there is no backup, and it can be very difficult and time-consuming to regain access to all of your accounts that relied on Yubikey for authentication.

Passkeys

Passkeys are the most recent implementation and combine the power of in-device biometrics with the flexibility of something more like a password manager. Their power is that they leverage WebAuthn but are no longer device-limited. Whereas prior uses of WebAuthn have typically only allowed for device-bound public and private keys, multi-device passkeys allow for these keys to be synced across cloud accounts to enable use on different devices. 

What’s more, passkeys also incorporate bluetooth and QR codes to enable login via biometric passkeys on different operating ecosystems. So hypothetically, users could use an iCloud passkey on their tablet to log into an app on their Android phone, and vice versa. While there are still some additional hurdles to be cleared on the road to widespread passkeys adoption, this latest breakthrough is the most promising of all of FIDO’s work to truly evangelize passwordless authentication methods on a massive scale.



Why Stytch joined FIDO

As a pro-passwordless platform from our inception, we’ve been impressed by the work FIDO has done to increase passwordless adoption. We’re particularly excited about everything they’ve done to make passkeys a reality, as it’s one of the new passwordless technologies we’re most excited about. 

At the same time, we’re also excited to join FIDO because we think we bring a decidedly different approach to the alliance. Lots of FIDO members are passwordless only, and we consider ourselves an identity and access management platform that’s building the bridge to passwordless adoption. But we strongly believe that the bridge to passwordless is paved with, you guessed it – passwords. 

Internet-based companies won’t pursue passwordless at the expense of customer comfort or experience – we shouldn’t ask them to take that kind of risk or leap. Instead, they need partners and bridge-builders to help them transition smoothly and profitably to a more future-forward user flow. 

At Stytch, we’re trying to model that kind of partnership in a way that other FIDO members can follow, in a way that will make passwordless authentication feel more palatable and attainable, even for the most password-entrenched among us. We think we have a unique position to embrace the passwordless world through our pragmatic approach to meeting companies where they are and think joining the FIDO alliance will help us improve our ability to move companies into a passwordless future.

---


# Bot mitigation for identity and access management
Source: https://stytch.com/blog/bot-mitigation-for-iam/

An overview of malicious bot traffic, and which bot mitigation solutions (i.e. device fingerprinting, CAPTCHA) are right for your product

A crucial but sometimes overlooked aspect of customer identity and access management (CIAM) is the need to discern whether something interacting with your application is a real human user or a bot. This is also called bot mitigation. 

Most CIAM work understandably focuses on how to correctly validate identities and provide the appropriate access to those users, but bot detection and mitigation is an essential tool in building signup and login flows that provides protection to both your application and users. 

When done correctly, bot mitigation helps stop attacks at the perimeter of your application before bot attacks like phishing, credential stuffing, or account exploitation can take place.

What is a bot? How are malicious bots different?

Human beings make up less than 40% of all internet traffic. The other 60+%? Bots. And over half of that traffic is malicious bots.



Bots are software that's been programmed to perform specific, repetitive, automated tasks online. They can be used benevolently — like to answer common customer questions in an ecommerce chat box — but they can also be used by hackers to automate and amplify cyber attacks. 

For example, bots can crawl the internet intercepting usernames and passwords, which they then mobilize to breach user accounts on different apps and websites. With bot attacks on the rise, it's no wonder that bot mitigation solutions are increasingly a part of conversations about broader CIAM and fraud and risk prevention.

Common types of bad bots

When it comes to CIAM, malicious bots enter the equation in a couple different ways and are a common weapon used in both first-party and third-party fraud. Before we dive into the specific ways bad bots are used in each fraud vector to attack applications, let’s align on two distinct fraud types: first-party fraud and third-party fraud.

First-party fraud

This is when the true account owner is the perpetrator (rather than the victim) of the fraud. There are a number of reasons an attacker would want to create a fraudulent first-party account with your application. Here are some of the most common examples we see:

Abusing signup rewards

In this attack, the intent is to create numerous fake accounts to take advantage of a limited offer (e.g. $10 in cashback for taking a certain onboarding action).

Stockpiling items for resale

Instead of signup, some bots target checkout flows to purchase limited resources only to resell at a higher price on the secondary market. This is particularly common with ticket sales (think Taylor Swift) and sneaker drops.

Creating fintech accounts

For certain digital investing, banking, and payment apps, bad bots target them by taking advantage of policies in which users can spend money before a deposit actually settles in the account. For example, if I can buy crypto before my ACH payment settles, that presents an opportunity for the fraudster to take advantage of this time delay.

Third-party fraud

This is when the account owner is the victim of the fraud. The user owns a legitimate account with an application, and that account is stolen by an attacker. This type of attack is called an account takeover or ATO, and the purpose is to exploit the underlying value of the account, which may hold money or sensitive data that the attacker can monetize. Here are a few of the attacks that can lead to account takeover via this vector:

Credential stuffing

In these cases, bots will try to log in with large numbers of credentials that they’ve stolen from other data breaches. If credentials are validated during this automated attack, they know those credentials can be used to breach the account.

Phishing

This can be perpetrated by real humans or bots. The intent is to trick a user into unwittingly providing their credentials (password, one-time passcode, etc.) to an attacker. Users often believe they’re providing their credentials to a secure site or to a bonafide support representative at the targeted application.

What are botnets? Is that the same as first-party fraud?

A botnet – short for “robotic network” – is a kind of malware that carries out tasks on other machines on behalf of an attacker, called the bot-herder. 

Botnets are typically established when the bot herder tries to gain unauthorized access by installing the bot on other peoples’ machines. They do this through file sharing, emails, or other protocols in which people are tricked into downloading and opening a malicious file without them ever knowing anything has happened. Once the bot is installed on a foreign machine, the bot-herder can control its actions remotely.



A diagram of how botnets leverage other machines to perpetrate attacks.

Botnets can be used for both first-party and third-party fraud. Botnets can infect millions of machines at a given time, giving the hacker controlling them a great deal of computing power. For attacks of scale that are best carried out by a large number of bots performing the same action (credential stuffing, stockpiling the latest Nike drop, etc.), they can be incredibly effective – and harmful. 

Because botnets can be used for both first- and third-party fraud, the bot mitigation solutions for botnets vs. a single bot are usually the same.



Which bot attacks should I worry about?

Many companies face both types of fraud, but which attack surface (signup vs. login) is more frequently and aggressively targeted depends on which vector provides the most potential monetization value to attackers. 

Put another way, the incentives are different for bots attacking signup and checkout forms vs. login flows. Most first-party fraud focuses on the account creation flow, and most third-party fraud focuses on the login flow. First-party fraud abuses your system by creating fake accounts, while third-party fraud abuses your system by stealing existing ones. 

So, if you’re an ecommerce site or marketplace with limited time rewards and deals, or a Fintech company with more flexible allowances for your customers ability to pay before deposits go through, your signup and account creation flows are more likely to be a target for bot attacks than your login flow for existing customers. That’s likely where you want to focus your anti-fraud protections the most. 

If on the other hand your customer or employee accounts have access to large amounts of sensitive data, there’s a higher incentive for attackers to target your login flow through third-party fraud tactics like credential stuffing and phishing. In that case, you’d likely want to invest in bot mitigation as well as unphishable authentication methods as your most probable attack vectors.

Bot mitigation – telling bots from humans



To understand the field of bot mitigation, it can be helpful to first think about where and when online users provide signal as to who they are and what they’re trying to do – signals beyond their username and password. 

There are several junctures in the signup or login process where bots may give away their, well, bot-ness (some of these are also general indications of fraud, whether from a human or a bot):

Speed

Bots can perform tasks on the web much faster than humans – this is one of their biggest advantages as a tool both for good and for ill. So if a user is creating an account or logging in at a super-human speed, it’s quite possible it’s bot traffic.

Volume

Similarly, most people don’t try to log in to their account thousands of times in an hour. They’ll usually try a few times and then call customer service or initiate a password reset. If a “user” is attempting certain repetitive tasks at a volume no typical user would benefit from, it might be a bot.

Intelligence

Bots are usually designed to perform a very limited number of tasks, and thus don’t have a lot of flexibility to perform tasks outside of what it was programmed to do.

Consistency

Like human fraud, bots also may give signal with behavior or characteristics that are inconsistent with a user’s typical behavior. If a user usually logs in from the same IP address, zip code, or device, and is suddenly halfway across the world on a new machine, there’s a strong possibility the “user” is a bot, fraudulent, or both. 

There are of course more technical nuances to these categories of bot detection methods, but they give a general overview of what bot mitigation tools use to identify and stop bot traffic.

Bot mitigation products

Today, two of the most common tools to thwart malicious bot traffic are CAPTCHA and device fingerprinting.

CAPTCHA



CAPTCHA, or Completely Automated Public Turing Test to Tell Computers and Humans Apart, is a bot mitigation solution that uses computer-generated puzzle or question to stump most bots. Bots are programmed to carry out specific, repetitive tasks within a narrowly defined scope. CAPTCHA puzzles are designed to give bots tasks outside of that scope, like identifying objects in a picture, performing basic math equations, or transcribing audio.

Different types of CAPTCHA

It’s worth noting though that not all CAPTCHA products are created equal, either for security or customer experience. Invisible reCAPTCHA from Google is a more recent kind of CAPTCHA that evaluates traffic without ever disrupting the user experience (hence the invisible part). But there are also hackers who use something calledCAPTCHA fraud. Also called CAPTCHA farms, these companies hire real humans to complete CAPTCHA puzzles on behalf of using a loophole in CAPTCHA’s source code.



This is the landing page of one of the largest CAPTCHA solving services. Its website highlights why you should choose it over competitors: it’s cheap and reliable. 

Bot mitigation solutions like Stytch’s Strong CAPTCHA have protections built against CAPTCHA fraud, but not all CAPTCHA services do. Depending on the sophistication of your company’s typical attacker, you may want to consider more thorough or ironclad CAPTCHA services. Because CAPTCHA puzzles introduce a bit of friction into the user flow, they’re best reserved for situations that are either highly sensitive or in which fraud is suspected for other reasons.

Device fingerprinting



Device fingerprinting is a bot mitigation solution that identifies devices that are accessing a website or application, and store and associate those devices with different user accounts. A device’s identity can be composed of a number of attributes that an application detects when the user accesses the site or app that are then associated with a unique ID. These attributes range from things like an IP address or browser type, to things like graphics card models, browser default language, etc.

Different types of device fingerprinting

Similar to CAPTCHA, not all device fingerprinting services are created equally. 

In part, this is because as device fingerprinting has become more common, hackers have designed more sophisticated bots to make them appear more like humans. For instance, many hackers automate speed-mitigation, so bots move and perform actions at a speed that is more akin to a person. They can also use VPNs or incognito browsers to fake or mask IP addresses. 

So when looking at device fingerprinting vendors, it’s important to ask which factors / attributes the fingerprint collects, and what other kinds of bot mitigation or authentication are stacked with it. Some solutions like Stytch’s Device Fingerprinting, use highly unique combinations of device properties, such as operating system, browser version, and IP address, whereas others just use a combination of browser make and model and time zone. 

Remember: the more unique the fingerprint, the stronger the solution at stopping bots in their tracks. 

Unlike CAPTCHA, device fingerprinting is completely unobtrusive to the user experience unless fraud is suspected. So while CAPTCHA solutions may only be introduced in a case-by-case basis, device fingerprinting is a broader bot mitigation solution that’s easier to implement without disrupting a user’s normal signup or login flow.

Which bot mitigation solutions are best for me?



The kind of arms race between cybersecurity professionals and hackers may seem overwhelming, especially if you’re just trying to sell shoes or provide a B2B data analytics tool. 

But like other areas of authentication, not every hacker on the internet is using the most sophisticated techniques to commit fraud. In fact, like white hat businesspeople, they’re usually going to invest only as much as they think they need to to be successful to maximize their ROI. 

When evaluating different bot mitigation services, you need to understand what those hackers are trying to do, and how hard they’re willing to try to evade detection. The more valuable and sensitive the information they’re after, the more sophisticated their techniques will likely get.

Choose bot mitigation based on risk and sophistication

At Stytch, we believe that authentication and fraud prevention should only introduce friction where it’s absolutely critical. When talking with customers, we usually scale our recommendations for fraud prevention based on the amount of risk and the sophistication of the hacker, to minimize any unnecessary disruption to the user flow.

For the least sophisticated attackers + spammers, invisible CAPTCHA will likely do the trick.

For medium-to-highly sophisticated attackers, device fingerprinting is recommended to pierce the various deceptions they may be attempting.

For extremely advanced attackers, it’s best to layer CAPTCHA on top of device fingerprinting. If hackers are investing a lot of money to look like a legitimate device + browser, they’re also likely willing to invest in something like a CAPTCHA farm, so it’s worth also making them perform a Turing test in case their device deception is highly effective.

The other important layer to consider beyond hacker sophistication of course is your company’s level of risk and the sensitivity and/or value of the data hackers are after. If you’re curious about how bot mitigation tools could help protect your product and customers, talk with an auth expert at Stytch today.

---


# What are one-time passcodes (OTPs)?
Source: https://stytch.com/blog/what-are-otps/

Learn how one-time passcodes (OTPs) can verify a user’s identity without the hassles of a traditional password.

As developers step up security measures to evade the latest cyber threats, they’re adding a range of innovative authentication and identity management solutions to their sign up and log in flows.

One of the strongest tools in their modern arsenal is the one-time passcode (OTP), also sometimes referred to as a one-time password.

Below, we explain what OTPs are, how they work, and why they best traditional passwords when it comes to offering a more robust security profile with a smoother user experience.

What are OTPs, exactly?

OTPs are security codes that are automatically sent to a user’s phone number or email address upon a sign up or log in attempt. They typically contain a randomly generated string of numeric or alphanumeric characters that a user must input to verify their identity and gain access to or carry out sensitive actions within an app or website.

As the name suggests, a one-time passcode can only be used once — that is, for a single authentication event. After a given code is entered, it is invalidated and cannot be used again.

What are different types of OTPs?

There are several different categories of OTPs, which are defined by the communication method involved. The most common forms include:

Email one-time passcodes

Email OTPs are sent to a user’s registered email address and can be accessed via their inbox on a desktop or mobile device.

SMS one-time passcodes

SMS OTPs are sent via text to a user’s registered phone number. While typically received through a mobile device, they can also be accessed on a computer using a messaging app like iMessage.

WhatsApp one-time passcodes

WhatsApp OTPs are sent through the WhatsApp messaging service, an app used by over 3 billion people worldwide. They’re a popular option for developers and platforms with a global user base, as they avoid the deliverability issues that can arise when sending text messages internationally.

How do OTPs work?

OTPs are considered something-you-have authentication, because codes are sent to a specific phone number or email address and must be accessed via a messaging app or inbox that is in the user’s possession.

In practice, OTPs generally follow a simple progression:

A user attempts to sign up for or log in to an app or website, initiating a verification request.

The back-end server generates a unique, random code, which is sent to the user’s registered phone number or email address.

The user accesses this code and enters it within the app or website to gain access.

If correct, the server validates the code, and the user is granted access.

The code is invalidated, preventing its future use.

Using OTPs in an MFA flow

Because of their ease and flexibility, OTPs can be used as a primary authentication factor or as a secondary factor in a two-factor authentication (2FA) or multi-factor authentication (MFA) flow. That means they can stand on their own or be combined with one or more other authentication methods, like OAuth logins, biometrics, or even traditional passwords.

MFA takes a layered approach to verifying a user’s identity and role-based permissions, boosting an app’s overall security. Auth factors can be grouped together and front-loaded at the initial login or dispersed throughout the user journey in a process known as route-based (or just-in-time) authentication.

With this approach, additional auth factors are only required when a user wants to perform a particularly sensitive task — like changing payment details or making a purchase — introducing extra friction only when it’s needed.



How are OTPs different from traditional passwords?

While one-time passcodes are sometimes referred to as “one-time passwords,” one of the most distinguishing (and advantageous) qualities of OTPs is that they are completely passwordless.

In fact, OTPs differ from traditional, static passwords in two key ways that boost both their safety and their usability. Let’s explore them one by one.

Stronger security

Passwords are the single most dangerous element in cybersecurity today. According to one recent report, 82% of all online data breaches involved the “human element” of authentication — in other words, weak, shared, or stolen passwords.

Unlike traditional passwords, however, OTPs:

Cannot be predicted: With OTPs, each new string of characters is randomly generated, so it’s unlikely to contain easily guessable information like a user’s birthday or pet name. It’s also impossible to guess what the next passcode will be based on past examples.

Cannot be reused: A static password remains fixed until it is changed by the user — so if a hacker intercepts it, they can enjoy ongoing access to that user’s account. But each one-time passcode is unique and can’t be used beyond a single login session.

Cannot be repeated: 85% of users admit to repeating the same password across multiple sites and apps, putting all accounts at risk if a password is intercepted. OTPs, on the other hand, are generated for a specific platform and can’t be applied across accounts.

That makes OTPs more resistant to common cyber attacks that target password-based authentication, like credential-stuffing, password spraying>, and account takeovers.

Frictionless UX

On top of security concerns, passwords are just plain stressful. In a recent study, 75% of users reported feeling anxious about the number of passwords they’re expected to remember across many online accounts.

What’s more, passwords are bad for business. 65% of consumers say they’ve abandoned a website or app because the process of creating credentials was too complex — and 92% would rather give up than have to recover or reset a forgotten password.

The user experience of OTPs is comparatively frictionless. Unlike traditional passwords, OTPs:

Are accessible: OTPs often come in the form of 6- or 8-digit codes, so they’re easy to remember. Besides, they’re typically right in front of a user in a readable text or email.

Are automatically fillable: Auth providers like Stytch offer auto-fill capabilities for OTPs sent to Android or iOS devices, so a user doesn’t even have to navigate away from an app to enter them.

Are flexible: OTPs can be seamlessly inserted anywhere in an authentication flow or user journey as a secondary factor, adding extra security without extra hassle.

Thanks to their ease of use, OTPs promise not only greater protections, but greater conversion rates, as well.

Potential drawbacks of OTPs

Like many authentication methods, OTPs aren’t absolutely foolproof, even when used as a secondary factor in an MFA flow.

Why? The short explanation is that any auth factor tied to a user’s phone number or email address can be compromised by a skilled hacker. For one thing, OTPs are sent as unencrypted plain text, so any communication that can be intercepted and read by a malicious actor — through rare but viable tactics like SIM swapping> — potentially puts a passcode at risk.

Moreover, OTPs are also subject to phishing attacks. These are social engineering schemes, in which hackers send fraudulent emails or text messages that manipulate users into clicking on a bad link or unwittingly sharing a passcode.

That’s why auth experts recommend fortifying all MFA flows with unphishable factors to ensure top-notch security and outmaneuver even the most determined hackers.

What are TOTPs?

Time-based one-time passcodes (TOTPs) are a newer, more advanced form of OTP often included as part of an MFA flow. They rely on authenticator apps — like Google Authenticator, Microsoft Authenticator, or Authy — to generate a random passcode that automatically changes every 30 or 60 seconds. That means a potential hacker has only a very short window to carry out an attack before a code is invalidated.

Additionally, unlike with original OTPs, authenticator apps are installed on and tied to a specific user device (rather than just their phone number). That means TOTPs can protect users against more sophisticated attacks like SIM swapping, while original OTPs cannot.

While TOTP provides stepped-up security, the time limitations means users need to be able to move fast to verify their identity and gain access to their desired app. Otherwise, they risk adding extra steps and friction to the login process. As a result, TOTP flows are typically reserved for highly risky actions or sensitive data — like moving money across fintech platforms or accessing a company’s payroll records.

Key takeaway

OTPs are a great option for modern developers who want to reinforce the security of their app or website without the inconveniences of passwords, and they work well as primary or secondary factors in a sign up or login flow.

Discover Stytch’s OTPs and TOTPs

Stytch offers flexible, frictionless One-Time Passcodes and advanced TOTP Authenticator Apps/a> as part of our comprehensive product suite.

If you want to learn more about how these or other solutions work, reach out to an auth expert to start a conversation — or sign up for a free account to try them out for yourself.

---


# What is passwordless authentication?
Source: https://stytch.com/blog/what-is-passwordless-authentication/

Learn how the advanced cybersecurity of passwordless authentication can manage user access without the security and UX risks of a password.

On the surface, passwordless authentication is a pretty straightforward concept. It's simply allowing users to access an online account, application, or website without the use of a password.

Under the surface, however, there's a lot going on. There are many different types of passwordless authentication factors, many different ways that passwordless login can be applied in an auth flow, and many different reasons why traditional passwords are no longer a secure or convenient way to verify a user's identity. Let's tackle these topics one by one — starting with the reasons why passwordless authentication is necessary in the first place.

What’s wrong with traditional passwords?



What isn't? Passwords made sense in the 1990s, when the internet first went mainstream. At the time, users had few online accounts, and remembering one or two simple credentials didn't pose a burden. Moreover, most users were not yet using the internet for highly sensitive activities like banking and commerce, so the stakes of a swiped password weren't quite as high as they are now.

Today, though, the average user has 100 passwords — far too many to remember outright. Since less than 23% of users employ a password manager, the vast majority use riskier methods to keep track of their proliferating credentials. According to a recent survey, 65% end up reusing the same password across multiple accounts, and 23 million still use “123456” as their password of choice. That has led to a situation where passwords are neither safe nor practical. Among other issues:

Passwords are easy to breach.

It's estimated that 82% of all online data breaches exploit the “human element” of cybersecurity — in other words, passwords that are easily guessed, stolen, or otherwise compromised. Passwords are considered something-you-know authentication, and anyone who knows one can gain access to every related account. Modern hackers have a variety of methods they can turn to — from malware and phishing scams to brute force attacks and credential stuffing — to intercept or crack a legitimate user's password and capture their sensitive data.

Passwords are frustrating.

On top of having to recall dozens (if not hundreds) of passwords, no one enjoys the drawn-out password recovery and reset processes they must follow if they happen to forget one. In fact, 92% of users report that they'd rather abandon an app or website altogether than undergo a password reset flow.

Passwords have gotten overly complicated.

In an attempt to offset the risks of weak credentials, many apps have imposed increasingly complex password creation rules. Many follow the LUDS formula, which requires a password to contain at least one lowercase letter, uppercase letter, digit, and symbol. In many cases, this leads users to make simple substitutions that are easy for bots to crack (like P@ssword1 or Password1!) or convoluted strings of characters (like I8*&YnF&#2hyg) that are difficult for humans to remember — triggering even more password reset flows.

Passwords are arguably destroying the planet.

You may not think passwords have a big carbon footprint, but we calculated that a year's worth of password usage in the U.S. alone produces the greenhouse gas equivalent of 877,415 cars, due to the time (and energy) it takes to type in and reset credentials. All that said, auth providers like Stytch are improving on antiquated password models to bring them up to speed with modern expectations. More on that later.

How does passwordless authentication work?

Passwordless authentication is not one-size-fits-all. There's a wide variety of passwordless authentication factors, and each involves a different process and results in a different user experience. Some of the most common passwordless authentication methods include:

Magic links



With email magic links, users can sign up for or log in to an app or website with a click. They simply enter their email address when prompted, receive a unique, single-use URL in their inbox, and click on the link to instantly verify their identity. This form of passwordless authentication is considered something-you-have authentication, because the user must prove they have ownership of a specific, registered email address.

With embeddable magic links, these same unique URLs are embedded into marketing materials sent to a user via email, SMS, or other form of communication. Because the user is accessing these materials through their inbox or messaging app, clicking on the link necessarily demonstrates their possession of that email address or phone number.

One-time passcodes



One-time passcodes (OTPs) are randomly generated security codes that are sent to a user's phone number or email address and accessed through an inbox or messaging app. As the name suggests, a one-time passcode can only be used once — or, for a single verification event. After a code is entered, it is invalidated and cannot be used again. Like magic links, OTPs are considered something-you-have type of authentication factor, as users must show they can access a given phone number or email.



Time-based one-time passcodes (TOTPs) offer a stronger version of OTPs for particularly sensitive apps or user activities. They rely on authenticator apps — like Google Authenticator or Authy — to generate passcodes that change every 30 or 60 seconds. That means a hacker has only a very short window to carry out an attack before a code is voided. Additionally, unlike OTPs, authenticator apps are installed on and tied to a specific user device (rather than just a phone number or email), so they can protect users against remote cyberattacks.

OAuth logins



OAuth logins allow users to leverage single sign on capabilities and access an app or website using a pre-existing third-party account. That means, if they have an active social account through Google, Facebook, Apple, or other platform — or an active dev account through Github, GitLab, or BitBucket — they can enter those credentials to verify their identity. Innovative options like Google One Tap take this one step further, detecting an already logged-in Chrome or Gmail session and allowing users to automatically apply those credentials.

Web3 logins



Much like OAuth, Web3 logins allow users to access an app or website using any existing Ethereum- or Solana-based crypt wallet. In addition, forward-thinking providers like Stytch are now offering encrypted, consumer-facing browser extensions — we call ours Vessel — that function like a passport to the internet, empowering users to navigate limitlessly online without ever having to manage another password, private key, or seed phrase.

Biometrics



Biometric authentication is considered something-you-are authentication, as they rely on physical attributes that are inherent to a user's body or behavior. Biometric tools are typically built into a device and are designed to scan, analyze, and recognize distinctive, measurable features — like a user's fingerprint, facial contours, iris/retina patterns, and voice qualities. Many biometric solutions are also equipped with liveness detection tools, so they can distinguish between a legitimate user and a reproduction (like a photograph or voice recording) in order to prevent fraud.

Historically, biometric data has been stored locally on a user's mobile device or laptop, making it impossible to transfer biometric logins across different devices and platforms. Next-generation solutions like passkeys, however, can now back up the cryptographic keys containing a user's biometric data to their cloud account, enabling smooth interoperability.

WebAuthn



Web Authentication API (WebAuthn) is one of the most exciting passwordless technologies on the market, building on advanced public-key cryptography. WebAuthn combines the layered security of multi-factor authentication (MFA) with the physical component of built-in biometrics or external security-key hardware like YubiKey.

This is by no means an exhaustive list, with passwordless authentication methods like push notifications, device fingerprinting, and CAPTCHA solutions also helping to detect bad actors like bots, prevent fraud, and manage legitimate user access.

Passkeys



Passkeys are a new evolution built on WebAuthn, with some key improvements. While WebAuthn pioneered the concept of a single-device passkey (i.e. a single hardware key or a biometric validation tied to your mobile device or laptop), “passkeys” as we're discussing here refer to multi-device passkeys and introduce a few major UX and developer improvements:

They are a drop-in replacement for passwords.

They are cross-device, cross-platform, and cross-ecosystem.

Enrollment and login credentials with a passkey leverages UX patterns made familiar by password managers.

For higher security contexts, passkeys can discern between existing and new devices attempting to access an account.

While passkeys have a couple of infrastructural hurdles to clear before they become widely available, it's Stytch's firm prediction that passkeys will be a tipping point in helping companies and users alike make the full transition into a passwordless future.

What's the role of multi-factor authentication in the world of passwordless?



Multi-factor authentication (MFA) is a layered approach to confirming a user's identity when logging into an app or web service. Whereas many authentication flows today only consist of one factor (like a username and password), multi-factor authentication will ask a user to use at least one additional authentication factor – like the answer to a security question, or a one-time passcode.

Though the passwordless authentication methods described above are generally more secure than passwords (can't be reused, harder to steal), each still comes with its own vulnerabilities. That's why at Stytch we not only recommend going passwordless, but also implementing them as part of a multi-factor authentication process. MFA helps ensure that if one authentication method is compromised, your user's accounts are still protected.

The benefits passwordless authentication solutions

There are many advantages to eliminating passwords from your authentication flows. Some of the most notable benefits include:

Passwordless authentication is more secure.

As noted above, passwords are the most common and vulnerable target for capable hackers, and taking them out of the equation bolsters an app's protections exponentially.

Passwordless authentication is more efficient.

Passwordless authentication flows often allow users to log in with a single click — and to avoid lengthy, multi-step password reset processes. For developers, they slash the time it takes to record and respond to log in issues, error tickets, and security risks. Some studies estimate that around 40% of all help desk calls are related to password resets.

Passwordless authentication is more cost-effective.

Similarly, research suggests that each password reset flow costs upwards of $70 in lost productivity and support time. In total, the average organization stands to lose around $5.2 million each year due to the inconveniences of passwords.

Passwordless authentication gives a better user experience.

Passwordless authentication flows are faster and friendlier, ultimately driving better user experiences, engagement rates, and lifetime value. For example, one Web3 mobile wallet platform jumped to 80%+ conversion rates at onboarding after integrating with Stytch's frictionless One-Time Passcodes.

Potential drawbacks of passwordless authentication factors

While passwordless authentication is popular among both users and developers, there can be shortcomings when it comes to implementation, including:

Access: Many passwordless auth methods require users to verify their identity using a separate account, application, or physical device, which may not be readily available.

Interoperability: As mentioned, some forms of passwordless authentication — like native, built-in biometrics — aren't able to travel across different platforms or devices.

Complexity: Many users are still unfamiliar or uncomfortable with the idea of passwordless authentication and may hesitate to install a related application or extension on their device.

Security: While safer than passwords, passwordless methods aren't 100% foolproof on their own. Any factor that is tied to a user's phone number or email address can be intercepted by a determined hacker through strategic phishing or SIM swapping, and even robust factors like biometrics can be compromised by successful spoofing. That's why experts recommend investing in MFA to keep up with and outsmart the most sophisticated attacks.

Not all apps (or their users) are ready to take the leap into a fully passwordless experience. Nonetheless, adopting passwordless auth isn't an either/or proposition. It's easy to add a passwordless option as a seamless primary or secondary factor in an existing auth flow and still enjoy all of the associated UX and security benefits.

Is it difficult to implement passwordless authentication?

No. The truth is, many companies don't realize that they're already relying on passwordless authentication. They call it a password reset flow. Password resets are really just an overly complicated email verification flow, with a requirement to create a new password tacked on at the end. Remove that, and you're left with an easy email magic link — so why not trim all the excess steps and offer a streamlined (but equally secure) experience?

Not all passwords are bad

It's worth noting that passwords aren't inherently evil, they just haven't been properly updated and upgraded to address the latest cybersecurity threats and user expectations. Stytch offers a modern Passwords solution for companies that (for whatever reason) still need or prefer to offer traditional sign up and log in factors as part of their auth flow. Unlike conventional passwords, however, ours feature next-level breach detection, strength assessment, deduplication measures, and intuitive, human-first reset options to give users the smooth experience they're looking for, plus the peace of mind that comes with stepped-up security.

The bottom line

There are good reasons why traditional passwords are on the way out, and why a completely passwordless internet is the way of the future. Fortunately for today's businesses and developers, there's a variety of advanced passwordless factors and flows that are easy to implement and to use, making them a promising path to stronger security, better user experiences and engagement, and greater overall value.

Discover Stytch's passwordless product suite

Stytch offers a range of frictionless passwordless solutions — including one-click Email Magic Links, instant One-Time Passcodes and seamless OAuth Logins — as part of our integrated product suite, which can be fully customized to your needs. If you want to learn more about how these or other flows work, reach out to one of our auth experts to start a conversation — or sign up for a free account to try our platform out for yourself.

---


# All about biometric authentication
Source: https://stytch.com/blog/all-about-biometrics/

A deep-dive on biometric authentication – its history, current types, how they work, and the pros and cons of using them in your product.

It wasn't too long ago that biometric authentication was the stuff of science fiction and spy films. When Back to the Future Part II premiered, paying for a cab ride with a fingerprint in 2015 seemed nearly unimaginable. But from where we’re standing in 2023, that future is just about here.



Biff, Marty McFly's nemesis across time-space, pays for a taxi ride using his fingerprint in Back to the Future Part II. 

Today, biometric authentication has become a part of daily life for just about anyone with a smartphone. Unsurprisingly though, it works a little differently from how it appears in films or TV. 

In this blog post, we'll take a deep dive on biometric authentication, including:

What it is and how it came about

Types of biometric authentication

FIDO and the future of biometric adoption

How it works

Advantages and challenges compared to other authentication methods

Biometrics: definition and history

A biometric (also called biometric identification) refers to a set of physical or behavioral traits that can be used to uniquely identify a person. 

In the world of authentication, a biometric authentication method refers to the process of using someone's biometric information to identify and grant (or deny) access to accounts and/or resources. Biometric authentication is considered a “what you are” form of ID (as opposed to what you have or what you know). 

Note the key difference here: whereas biometrics in general are simply used to confirm someone's identity, biometric authentication specifically refers to confirming that identity for the purpose of accessing resources online. As Stytch is an authentication platform, we're most concerned with the latter.

Biometric authentication: a brief history

In the 20th century, scientists made major leaps and bounds with a variety of biometric identification factors, including iris patterns, hand geometry, and facial and voice recognition. Though the last century didn’t see widespread biometric adoption, it laid important groundwork for the momentum biometrics would gain in the new millennium. Some key events included:

1969: The FBI launched research into how to automate fingerprint scanning and verification, which until that time had been a laborious, manual process.

1976: The first prototype for a speaker / voice recognition system was developed by Texas Instruments.

1971: Hand geometry biometric identification was patented by Robert Miller at Stanford University.

1994: Iris recognition was developed and then patented by John Gustav Daugman at Cambridge.

1996: Hand geometry was used for admission to the Olympic Village at the Atlanta Summer Olympic games.

1997: The National Security Administration sponsored the Human Authentication Application Programming Interface (API) – the first standard for commercial biometric interoperability. This was a key step forward, and would help make widespread biometric adoption much more feasible.

While there have been incremental advances in biometric authentication adoption in the 21st century, perhaps the most significant milestone was 2013, in which Apple released Touch ID for the iPhone, marking the first integration of biometric authentication into a major commercial product. 

Since then, biometric technology has rapidly accelerated. As of 2022, 80% of smartphones now have biometrics enabled.

Types of biometric identification methods

Biometric identification methods can generally be grouped into two categories: physical biometrics and behavioral biometrics. 

Physical biometrics are what most people are familiar with in their day-to-day use, and consist of a computer gathering, storing, and comparing data relating to someone’s physical traits. 

Behavioral biometrics relate to how a person behaves online, and typically deals with motor / manual actions on a computer like typing, mouse movement, etc. 

Since physical biometrics are more common, we’ll start with those.

Fingerprints



A biometric fingerprint scan is used to get into one's home in Total Recall, a science fiction film. 

Fingerprint biometrics are the most common form of biometric authentication today, in part because they were so widespread in identity and law enforcement before the internet. 

Today, fingerprint biometric authentication relies on scanners to gather a person’s unique finger or thumbprint. While there are different types of scanners, they all rely on receiving a signal from someone’s finger that returns different values when it interacts with the ridges of the fingerprint and when it interacts with the valleys.

Optical fingerprint scanners rely on bouncing light off of the finger.

Capacitive fingerprint scanners discharge a very small electric charge onto the finger.

Ultrasound fingerprint scanners rely on bouncing sonic waves off of the finger (much like ultrasounds in other medical uses).

Thermal fingerprint scanners detect the temperature difference between the valleys and ridges.

Regardless of the type of scanner being used, once it receives the data points about the precise location of an individual's valleys and ridges, an algorithm is then used to translate that biometric data into a character string that is then stored either on the device that took the print (more common) or on a cloud or server (less common). 

Importantly, the algorithm that encodes the fingerprint into a character string cannot be reverse-engineered to generate an image of the fingerprint.

Face



A thumbnail from the Bourne Identity movies, in which a face is matched using facial recognition technology. 

Facial recognition is the next most common form of biometric authentication found on everyday devices today. Like other biometric authentication methods, facial recognition scanners take various measurements of the user's face to create a unique data set that is then compared against future scans. 

While some facial recognition systems have been updated to detect liveness, many are still based on analyses of still images, rather than live scans of light, sound, or heat.

Hand geometry



A hand geometry scan as represented in the 2015 film Jurassic World 

Hand geometry identification is composed of several measurements of different dimensions of the human hand, such as the length and width of each finger, the span of the hand at various cross sections, etc. Because hand geometries are not as unique as other biometrics like fingerprint, iris, or retina, they are not considered as secure. 

For this reason, hand geometry is more often combined with other forms of identification and authentication (such as ID cards, etc.) rather than serving as the primary auth or identification factor. 

Voice



In the Star Trek franchise, certain sensitive actions could only be performed once the captain's voice had been authenticated. 

Voice biometric authentication analyzes the unique sound characteristics of a person’s voice, including duration, dynamics, intensity, and pitch. The uniqueness of these characteristics results from a combination of their own jaw and mouth movements, throat shape, vocal cords, etc. 

Many biometric auth solutions are equipped with liveness detection capabilities, so they can distinguish between a real, live user and a mere reproduction or copy — like a photographic image or voice recording — in order to detect and prevent fraud.

Eyes



A thumbnail from the film Minority Report in which Tom Cruise performs an eye-based biometric authentication scan 

While certainly less common in everyday devices, eye-based biometric scanners focus on highly unique biological characteristics that are near-impossible to fabricate – namely the retinas and irises.

Retina Scanners

Retina scanners might more accurately be called blood vessel scanners, since they’re actually mapping the network of blood vessels that feed into a person’s retina at the back of the eyeball. This blood vessel network is unique in every person, and is scanned by sending UV light into the back of someone’s eye and then registering the reflections of light sent back by the blood vessels. 

While retina scanning probably sounds extreme for everyday uses, it is incredibly accurate. Retinal patterns are consistent throughout a person’s life, but certain diseases like glaucoma, diabetes, and a few select others can alter them.



Iris Recognition

Iris patterns are also incredibly unique, but these scanners instead detect biometric data from the front of the eye to capture patterns on a person’s iris, including size, color, etc. 

Unlike retina recognition, which bounces off UV light and registers the reflection, iris recognition and scanning is done with cameras (albeit UV cameras). This makes the technology required for successful iris recognition biometrics much less expensive and less complicated, and thus a bit easier to implement.

Behavioral Biometrics



Unlike physical biometrics, which are used to identify a single user, behavioral biometrics are more commonly used to distinguish fraudulent users (often bots) from human ones. While this is not the only way to mitigate malicious bot traffic, it can provide helpful signal because of the particular ways bots behave. Behavioral biometric factors include:

Mouse activity and motion, including speed, movement patterns, scrolling behaviors. Bots tend to move multiple times faster than a human does.

Keystrokes, including speed, use of shortcuts, and use of copy and paste functions, which bots tend to use instead of actually typing.

Touchscreens, including the pressure and surface area that interacts with a touchscreen surface.

Device being used, including gyroscopic movement of the device, orientation, etc. Bots don’t need the computer oriented or stable in any kind of way to operate (since they’re software-based) whereas humans have specific orientation needs for their device hardware.

What are the pros and cons of different biometric authentication methods?

At Stytch, we always believe the security provided by a given authentication method must always be measured against the amount of friction it introduces for users – what they trust, understand, are most familiar and comfortable with, etc. 

This tradeoff often varies depending on a variety of factors, including the industry, user population, and product design. But really, the choice of biometric detection is often not up to the average app or product builder, but is instead a decision for hardware makers. 

So if you’re building an iOS app, you’re already locked into the Face and TouchID biometrics Apple has built into their iPhone.

FIDO – popularizing biometric security

In addition to Apple's introduction of TouchID in 2013, the a group called Fast Identity Online, (or the FIDO alliance) has been instrumental in evangelizing biometric authentication systems and making them easier for companies to adopt and implement. 

FIDO was originally formed in 2012 by a group of invested parties from across cybersecurity who united behind a simple goal: make the internet easier and more secure to navigate by developing a more intuitive, standardized approach to passwordless authentication. 

Over the past decade, FIDO has made impressive strides in developing technical standards that improve on both security and usability. Two of the most well-known technical standards FIDO has advanced are WebAuthn and passkeys. If you’ve interacted with a web app that allows you to authenticate with on-device biometrics on your phone or a Yubikey, you’ve likely interacted with WebAuthn. 

While spy thrillers often show biometric authentication being used as a primary authentication factor (think of using retinal scans to get into government buildings), in both WebAuthn and passkeys biometrics instead serve an intermediary function that safeguards access to login credentials or cryptographic key pairs. That combination is also referred to as device biometrics, on-device biometrics, or native biometrics. 

It’s the combination of biometric data with public key cryptography that makes biometric authentication on one’s phone or computer so secure, and such a promising alternative to passwords. 

But FIDO has recently taken device biometrics one step further. While WebAuthn solutions were historically limited to a specific device, passkeys improve on WebAuthn by leveraging a user's cloud account (e.g. iCloud) to securely log people in across devices and operating systems with biometrics. This means that a person's biometric data that's saved to their iPhone can be used to log them into an app on their MacBook, or even their PC. 

Thanks to FIDO, the world of ubiquitous, secure biometrics just got a lot closer. 

Because device biometrics are one of the more common implementation cases for biometric authentication today, it's worth breaking down what exactly is happening under the hood. 

Let's take a look.

Device biometrics – a step-by-step guide

The first crucial component to device biometrics (besides the biometric reader itself) is public key cryptography, and how it's different from more basic cryptographic systems.

Basic cryptography

To understand public key cryptography, it’s helpful to have a basic understanding of cryptography as a whole. In cybersecurity, cryptography generally has four parts:

Plain text message: the information being protected by encryption

Cipher algorithm: the mathematical operation done to the plain text message to encrypt it. These algorithms are generally common and publicly known, and utilize keys in their operation.

Cipher message: the result of encrypting the plain text message with the cipher algorithm.

Key: This is the unique value or string used by the algorithm to encrypt or decrypt the cipher message.

To give an over-simplified example of how this works: 

Let’s say you want to share the message “apple” with someone. “Apple” is your plain text message. You use the cipher algorithm of addition paired with the key of 4. In this case, “4” indicates the number of letters you move down the alphabet to create your cipher message. With this cryptographic process, “apple” would become “ettpi.” “ettpi” is then your cipher message. 

In reality of course, both the keys and the algorithms are much more complex. Keys are usually randomly generated strings of letters and numbers, and the algorithms involve a bit more advanced mathematics than basic addition. But the main principle and roles as described above apply. 

Now in order for this to work, both people and/or entities sending and receiving the encrypted message have to know both the cipher algorithm and the key. In cybersecurity, because the algorithms are more or less public knowledge, that makes the key an incredibly valuable piece of information. So the question of how keys are initially shared and then stored is a critical juncture in keeping data and accounts secure. 

Enter public key cryptography.

Public key cryptography

Unlike basic cryptography in which the algorithm and key are shared between parties exchanging data, in public key cryptography each party possesses a different key – one to encrypt, and one to decrypt. Typically, the public key is used to encrypt the data, and the private key is used to decrypt it.



What makes this kind of cryptography more secure than regular cryptography is that while the public key is stored on the server (and thus fairly easy for others to access), the private key is stored either on the user’s device (like your iPhone) or on a hardware security module like a USB or biometric scanner. Because the keys are asymmetric and one of them is stored locally, this makes it much more challenging for hackers to access, thus helping prevent account takeovers.

Device biometrics – bringing it all together

Now that we have a good understanding of public key cryptography and biometric authentication factors, we can see how it all fits together on a day-to-day basis when we use biometric auth on our iPhones or Androids. 

When you first sign up for an application or service, you may be asked if you want to use biometrics on your device, let’s say an iPhone, to log in. If you say yes, and have already saved your biometric information to your phone (be that a thumb print or a face scan), the following will happen:

Signing up with biometrics

The app you want to access generates a key pair to be used throughout this sign-in process.

That application notifies their authentication provider (let’s say Stytch) that you, the user, want to use biometric authentication, and register for a biometric key with Stytch. Stytch stores the public key, and sends a challenge for the device to solve with the private key to confirm ownership of the other half of the key pair.

The app on your phone receives the challenge, solves it with the private key, and returns that puzzle answer (also sometimes called a signature) to confirm the registration process.

After each party verifies each other, the private key registration is stored securely on your device (in the case of an iPhone, it’s stored in the Keychain), along with any other metadata that’s helpful when logging into the app.

That’s a successful biometric authentication registration!

Logging in with biometrics

When it comes time to log into the app or service, that app or service will do the following:

First, the app will check to make sure there’s a keypair registration on the device you’re using. Most authentication providers only allow one keypair per application per device.

When the app asks the Keychain on your phone for the keypair, that’s when the system will ask for the biometric prompt.

You provide your device with your biometric information, which prompts the device to unlock the keystore. Note at no point does the app have any access to your biometric data! This is only stored on your device, as a way to protect any credentials or keys stored locally.

Just like they did with the signup flow, once you’ve unlocked your key data with your biometrics, the auth provider will use the public key that they have to create a challenge that can only be solved with the private key on your phone. The auth provider here does not have access to the private key, but they do know what the answer should be based on the public key.

The challenge is solved using the private key on your phone, and that answer/signature is returned to the auth provider for verification.

If the response matches what Stytch believes it should be, you are authenticated and officially logged in!

The main takeaway here is that biometric authentication is especially powerful in cybersecurity when paired with public key cryptography. This combination helps reduce friction and increase security all at once, without giving your biometric information to a single application.

What are the advantages and challenges of working with biometric authentication?

Advantages

The two main advantages of biometric authentication are security and ease of use.

Enhanced security

Because biometric authentication is based on a user’s unique characteristics, it cannot be lost, forgotten, or guessed. This makes it a more safe and secure authentication option vs password-based authentication, which is an increasingly insufficient means of protecting sensitive information. A

dditionally, biometric authentication offers best-in-class security by ensuring that a user demonstrates both possession of an original device and a unique biometric trait such as a Face ID or fingerprint.

Ease of use

Convenience and ease of use is the major advantage of biometric authentication. It’s much easier for users to glance at their phone or tap a sensor to unlock a device or log in to an app than it is for them to enter (and remember) a password or request a SMS passcode every time they want access. Biometric authentication reduces friction, which, in turn, can increase user conversion and retention.

Challenges

The biggest challenges with biometric authentication relate to spoofing,usability, and trust.

Spoofing

While much more secure than other forms of authentication, hackers are quickly developing ways to get past biometric authentication processes. They may use an authorized user’s photo, voice recording, fingerprint replica or other form of mimicry to trick a biometric reader into giving them access. 

Fortunately, spoofing isn't possible with the device-tied nature of on-device biometrics. So for any developer building for FaceID, TouchID or other mobile applications, spoofing is not a concern. 

And for that small cadre of developers who have non-on-device biometric authentication in mind, mapping users’ faces in 3D or requiring them to say a unique phrase at every login, for example, can help mitigate the risk of spoofing.

Usability

While the technology is improving every day, there are still some false rejections with biometric authentication that users may find frustrating. These can result from changes to users’ faces and voices as they age or due to circumstances such as mask-wearing, glasses, or lighting. 

Biometric methods like facial recognition systems have also come under scrutiny in their confluence with artificial intelligence (AI) and law enforcement use cases, particularly for the ways their inaccuracies affect treatment of those who are underrepresented in AI's databases, particularly women and people of color.

Privacy & trust

Biometric data is highly sensitive, and people are understandably wary about it being stored in centralized databases or transmitted between systems susceptible to a breach. As of 2019, 25% of people surveyed said they did not trust biometrics, while 35% felt they didn’t have enough information. There are a few things companies can do to help build trust and protect privacy:

Triple-check your security measures: This should go without saying, but biometric authentication is no different from other types: it’s very easy to do poorly, and hard to do well. If you’re going to be using biometric authentication information in your app, do due diligence and our partner with a third party (like Stytch!) to help manage your security risks.

Transparency and education: Develop a highly secure and transparent plan for using and protecting biometric data. Explain how your technology works to your users, so they understand who has access to what, and all the ways in which they’re protected.

Device biometrics: Because of some of the risks that can come with storing biometric information, it often makes more sense for app developers to use device-based biometrics (described above) for their purposes. Using Apple and Android biometric technologies allows them to avoid many liabilities, and device-based methods are becoming increasingly easy to implement.

Get started with biometric authentication

Stytch is leading the way in easy-to-implement authentication solutions that boost security and increase conversions. If you’re interested in integrating biometric authentication, check out our WebAuthn and Passkeys products, or check out our docs. Sign up for a free account to get started, or contact support@stytch.com to discuss all things auth.

---


# What is a passkey?
Source: https://stytch.com/blog/what-is-a-passkey/

Stytch goes over the basics of the passkey – what it is, how it works, and how it improves on past auth methods like passwords and WebAuthn.

Of all the innovations in passwordless authentication over recent years, passkeys are arguably the most exciting. Passkeys expand on biometric technology by allowing biometric data to be backed up to (and accessed from) a user’s cloud account, enabling a level of interoperability that has never before been possible.

Given their portability and ease of use, passkeys are a top contender to dethrone the password as the dominant form of passwordless authentication, and we’re here for it. Still, they face several hurdles when it comes to implementation, especially since they require biometric-protected keys to be synced across different platforms and devices. For this reason, we expect that widespread passkey adoption will be slow to take hold — more like a dimmer light gradually turning on than the instant flip of a switch. 

In this post, we run through the basics of passkeys: what they are, how they work, the barriers they face, and the steps we’re taking at Stytch to support every stage of their rollout.

What is a passkey?

Passkeys were developed by the Fast Identity Online (or FIDO) alliance, a group of cybersecurity experts dedicated to creating secure, frictionless authentication standards that eliminate the need for passwords. In fact, passkeys were originally introduced as “multi-device FIDO credentials” — “passkeys” is just a catchier term, and it has the added benefit of emphasizing how this new auth solution departs from and improves on the less-secure password. 

Essentially, passkeys are a phishing-resistant, drop-in replacement for passwords. They rely on biometric verifications like FaceID or TouchID and can be used across different devices, platforms, and ecosystems. Using a passkey is a bit like using a password manager, since a user’s credentials are stored in the cloud and easily accessible from any connected device, just like other cloud-synced features like a user’s photos, contacts, emails, and documents.



How do passkeys work?

Passkeys rely on pre-existing public key (or asymmetric) cryptography, which creates pairs of public and private cryptographic keys that usually encrypt and decrypt user data, respectively. Typically, the public key is stored on the server, while the private key is stored locally on a user’s device or on hardware like a USB drive or biometric scanner.



With passkeys, however, the key pair is end-to-end encrypted and backed up to the cloud account on a user’s primary device — that is, iCloud for iPhones and Macs, Google for Androids and Chromebooks, and so on. That means that any device that syncs to this cloud account can use a biometric factor like FaceID or TouchID to verify a user, access the cryptographic key pair, and log the user in. 

It is worth noting, too, that the raw data from the biometric authentication itself is not stored in the cloud — just the cryptographic key pair it unlocks — so it cannot be stolen and put to malicious use.

How are passkeys different from native biometrics and WebAuthn?

Passkeys have certain commonalities with other forms of passwordless authentication like biometrics, but there are key technical differences when it comes to how the biometric data is captured and where it is stored. Let's look a little closer.

Native (or on-device) biometrics

Native biometrics leverage a biometric scanner on a user’s laptop or mobile device and ties it to locked storage of either credentials or public/private key pairs. For example, a user might use a fingerprint, faceprint, or voiceprint to unlock the key pair sharing capability with an application in order to log in. This is referred to as native biometrics because the biometric data is only stored on their local phone — never on the app itself.

WebAuthn



WebAuthn is the combination of public key cryptography with either native biometrics or a piece of physical hardware like a YubiKey. As with native biometrics, the identity data from WebAuthn is always tied to a specific device, whether that’s a user’s phone or their YubiKey.

Passkeys



Passkeys as we've covered also combine public key cryptography with native biometrics, but unlike WebAuthn they are not limited to a single device. Using wireless technologies like bluetooth or a QR code, a user can sync passkey data with other devices within the same operating system (like from an iPhone to a MacBook) or even a device on a different operating system (like from an iPhone to a PC).

What are the benefits of passkey login?

Passkeys offer the same advantages as biometric authentication more generally, including one-step account creation, a seamless user experience, and stepped-up security. It comes with three big advantages:

Passkeys make recovery easy

Unlike on-device biometrics or WebAuthn, backed-up biometric data means users have ongoing access to a biometrics-enabled account, even if they lose or break the original device used to create it.

Passkeys optimize access and usability for FIDO authentication

Before, biometrics were restricted to a single device, so a user would need to re-enroll in a new biometric auth flow for each of their devices — on their phone, their tablet, their laptop, etc. — for the same account. With passkeys, the original biometric flow carries over.

Passkeys are as user-friendly as a password, but more secure

As with native biometrics and FIDO's WebAuthn, passkeys rely on unique bodily or behavioral traits to verify a user’s identity, and these attributes cannot be lost, forgotten, guessed, or easily replicated by a hacker. Moreover, passkeys are equally impervious to phishing, because they’re tied to the specific website or application that prompted them and can’t be used on a malicious or fraudulent site instead. 

To put it another way, passkeys work just like traditional, interoperable passwords, but without the security risks and the need to remember complex credentials. Like all biometrics, passkeys still fall under the category of “something-you-are” authentication — they just respect the fact that you’re still you, regardless of where you go or which device you use.

What are the challenges to using passkeys?

Various platforms have already begun implementing passkeys, including Apple, Google, and Microsoft, and their future looks bright. However, there are still a few obstacles to face in terms of usability, security, and implementation. 

From a usability standpoint, passkeys share some of the same drawbacks as other forms of biometrics. These include occasional false rejections, which can occur with everyday variations to a user’s physical features — for example, if they’re wearing a mask or their voice is altered due to illness. Biometrics are also imbued with society’s systemic biases, exhibiting higher error rates for AI-underrepresented groups like women and people of color. 

Furthermore, passkeys are only as secure as the cloud accounts they’re stored on. And the fact that users’ biometric credentials are automatically synced across all cloud connections means their data may end up on devices where it was not intended to be. 

In terms of implementation, passkeys are currently somewhat limited in scope, since biometric-protected keys are still incompatible with the cloud-syncing function in many cases. For this reason, their large-scale adoption will be a slow burn as auth providers and other cybersecurity platforms learn to integrate their syncing features securely and effectively.

How Stytch is supporting passkeys

Stytch is committed to providing phishing-resistant FIDO credentials as part of our suite of passwordless authentication products. 

We’ve already launched a set of robust native biometrics, including fingerprint and facial recognition tools powered by our flexible API, as well as frictionless WebAuthn solutions. Today, we support multi-device passkeys as a secondary authentication factor for 2FA, but we're also excited to extend support for passkeys as a primary authentication factor in the near future, too.

Check out our biometric solutions

To learn more about our approach to biometrics — and how we’re opening the door to multi-device, phishing-resistant passkeys — get in touch with one of our auth experts. You can also sign up for a free account to try our solutions out for yourself.

---


# Argon2 vs bcrypt vs. scrypt: which hashing algorithm is right for you?
Source: https://stytch.com/blog/argon2-vs-bcrypt-vs-scrypt/

A look at the hashing algorithms Argon2, bcrypt, and scrypt – their benefits, differences, and how to choose the right one for your product.

As an engineer, you’ll likely come across the concepts of data hashing and encryption whenever you’re handling sensitive data. Both hashing and encryption are important to cryptography and are often confused, and choosing the right algorithms for your use case is not necessarily a straightforward decision. 

In this article, we'll cover the basic definitions of hashing and encryption, and compare three common hashing algorithms you're likely to come across in your work: Argon2, bcrypt and scrypt. We'll look at their origins, their strengths and weaknesses, and in what circumstances you'd likely use each. L

et's dive in.

What is encryption?

Encryption is a process that involves scrambling or coding information so that only someone with a key to how you scrambled or coded it can read it. This is key: you only encrypt information when you expect or intend at least certain parties to decrypt it and access it later. It is a two-way, reversible process. In computer science, encrypting is typically done with complex mathematical algorithms.

What is hashing?

Similar to encryption, hashing is another mathematical technique used to obfuscate data you want to keep unavailable to other people. But there are two major distinctions that make hashing different:

Hashing goes one way – if you hash something, it is not intended to be "un-hashed."

Hashing converts data into a fixed-length output, also known as a hash value. With encryption, the output from the encryption may vary in length depending on the algorithm.

The conversion from data to hash value is done by an algorithm, and the choices and operations involved are what make each hashing algorithm unique. Every hashing algorithm has its own history and design. Some were created to support additional parameters that you can adjust to meet your security or computational needs. What parameters are available depends on the hashing algorithm you choose to use. 

This is why the choice of hashing algorithm is so important: you want to make sure it meets the computational and security needs of your use case.

Why do we hash passwords?

Password storage is one of the paramount concerns for any application or web service that deals with authentication. Depending on how and where they store passwords, their users' credentials could be exposed to bad actors in the event of a data breach or cyber attack. 

Password hashing is a great way apps and online services can protect users' accounts in the case of a cyber attack or data leak. A stored hash has two big advantages over storing a plain text password or even an encrypted password.

Irreversibility

Once a hash value is generated, there is no way to derive the original input based on the hash value alone. Hash values usually appear as a random string of characters.

Consistency

At the same time, companies that only store a password's hash can still verify the identity of a user with their username and password because the same input string will always generate the same hash. So if a user enters their password and it generates the same hash as the one in the application's database, they can safely verify the user without storing their credentials.

Is password hashing unhackable?

Like any cybersecurity measure, though password hashing can greatly increase the cost of hacking or account takeovers, it is not completely attack proof. 

The main way hackers can break a hashing system occurs requires a few steps, each one of which can be thwarted by additional security measures:

To gain access to a hashed password, the hackers must first breach the account storage information of their attack target. If these passwords are hashed, this information on its own is not usable – hence why password hashing is such a valued protection!

Once hackers have a list of hashed passwords, they can create a database of words they think are likely to be used as passwords (strings like "password123," "qwerty," or perhaps even passwords they've obtained from other breaches). They then hash these likely passwords using the hashing algorithm they either suspect or or know their attack target uses. This creates a database of password hashes.

With their possible or probable hashes in hand, the attackers then compare their database with entries in the hacked database of password hashes. If they find any matches, they can then gain access to those accounts.

While we've summed up this process in three neat steps, it's a very time and computing-intensive process, which serves as a strong deterrent against most hackers.



How does hashing work?

All hashing algorithms involve taking a piece of information called the "input" and a number of other parameters that determine the hash's complexity, computing requirements, and additional security measures. 

Note that not all hashing algorithms use all the parameters below. Indeed, the parameters hashing algorithm use are a big part of what distinguishes one from another. 

Some examples of parameters include:

Input: Every hashing algorithm needs an input to hash. The input is usually a plain text string of varying lengths (like a password).

Salt: The "salt" refers to a string of characters that is appended or prepended to the input before it is hashed. A salt changes the hash value by increasing the length and complexity of the input. It is a common practice to help guard against dictionary attacks (a kind of brute force attack that tries to reverse engineer the hash) or rainbow tables (a more sophisticated method and dictionary attacks.

Length: Length refers to the number of bytes or HEX characters in the generated hash value.

Cycles: The number of cycles describe how many times or iterations the algorithm’s hashing function will run. More cycles create a stronger hash but require more time to compute. The number of cycles are determined by the work factor, by an exponential relation in which cycles = 2^work factor.

Work factor: The work factor refers to the number of times the hashing algorithm is performed – this is usually expressed as an exponent, like 2^work iterations. The higher the work factor, the harder it would be for a hacker to crack the hashing algorithm. But, the higher the work factor, the greater the computational cost to the application and/or its auth provider.

Threads: Threads refers to the number of concurrent threads, or degrees of parallelism, that the algorithm will utilize to compute the hash.

Memory/memory hardness: The amount of memory to be used in the hashing process. Algorithms generally are evaluated by many factors, one of which is called "memory hardness," which refers to how much CPU and RAM usage is required to perform a given function or action. Hashing algorithms need to strike a balance between not being too memory hard without being too easy to crack either.

CPU: The cost or work factor that increases the memory and CPU usage needed to generate the hash. Some scrypt implementations require this parameter to be a power of 2.

What are the different types of hashing algorithms?

With so many options for hashing algorithms, like SHA-1, SHA-256, MD-5, Argon2, scrypt, and bcrypt, it's important to understand the differences and choose the right one for your needs. For password protection, Argon2, bcrypt, and scrypt are recommended due to their configurable memory and cost parameters that can increase computational strength against attacks.

Argon2

Argon2 was designed by Alex Biryukov, Daniel Dinu, and Dmitry Khovratovich from the University of Luxembourg. They released their specification paper on Argon2 in 2015 and that same year won the Password Hashing Competition, organized by a global panel of security and cryptographic experts. In their paper, the designers state their motivation for creating Argon2 was "to maximize the cost of password cracking" and that "passwords, despite all their drawbacks, remain the primary form of authentication."

bcrypt

Bcrypt was designed by Niels Provos and David Mazières. They presented their paper "A Future-Adaptable Password Scheme" in 1999 at the Unix Users Group conference. They based their hashing algorithm on Blowfish, an encryption algorithm created by Bruce Schneier in 1993, to take advantage of its purposefully expensive key setup phase. Provos and Mazières took the concept further by designing bcrypt to have adjustable cost. In their paper, they state that "the computational cost of any secure password scheme must increase as hardware improves."

scrypt

Scrypt was created by Colin Percival who presented his conference paper in 2009 at the Berkeley Software Distribution conference. It was originally developed for Tarsnap, an encrypted online backup service for UNIX operating systems, which Percival also created. Scrypt was designed to be a memory-hard algorithm that would be maximally secure against hardware brute-force attacks.

Which algorithm is right for you – Argon2 vs. bcrypt vs. scrypt

While there are of course deeper nuances to Argon2, bcrypt, and scrypt, the choice between them boils down to weighing computing and time requirements against memory hardness and parameter number.

Argon2 is a great memory-hard password hashing algorithm, which makes it good for offline key derivation. But it requires more time, which, for web applications is less ideal. 

bcrypt can deliver hashing times under 1 second long, but does not include parameters like threads, CPU, or memory hardness. 

scrypt (Stytch's personal choice!) is maximally hard against brute force attacks, but not quite as memory hard or time-intensive as Argon2. 

At Stytch, once we've salted and hashed all passwords using scrypt, we store them in an encrypted database that we manage. This ensures our Passwords solution is secure and built for performance. 

If you’re looking for more information on each hashing algorithm, read more about the differences here.

---


# Onboarding the next Web3 wave with Crossmint + Stytch
Source: https://stytch.com/blog/onboarding-the-next-web3-wave-with-crossmint-stytch/

Onboarding the next Web3 wave with Crossmint + Stytch

Crossmint’s mission is to make NFTs easy to access for users and simple to deploy for developers and enterprises. Part of that mission means bridging the gap between users that are comfortable with Web2 but aren’t yet Web3 native. Onboarding this wave of users means building familiar and delightful onboarding flows – that’s where Stytch comes in.



See how you can build API first and combine the best of both Web2/3 worlds with our Stytch + Crossmint example app and guide. Now, you can deploy Stytch’s seamless authentication (social and passwordless) with Crossmint’s powerful wallet APIs to launch an end-to-end wallet onramp in minutes. Check out Crossmint’s blog post about this launch or jump into writing code with their guide!

About Crossmint

Crossmint is a leading NFT infrastructure provider, with tools like credit card payments for NFTs, enterprise-grade minting APIs, and secure NFT custodial wallets. We’ve supported over 9,000 developers and enterprises - including key customers like Magic Eden, Origin, Rarible, X2Y2, Crown Royal / Diageo, Salesforce, Cinemark, Armin van Buuren and more. Read more about Crossmint at their website, docs, or contact sales to learn more.

---


# Stytch Talks With Jordan Burris: “The Future of Multi-Factor Authentication (MFA)”
Source: https://stytch.com/blog/stytch-talks-jordan-burris-mfa/

A recap of our live conversation with security expert Jordan Burris, focusing on the future of multi-factor authentication.

As traditional passwords become increasingly unreliable, more app developers have decided to enhance their sign up and log in flows with layered multi-factor authentication (MFA), which requires two or more verification steps to confirm a user’s identity. But not all MFA is created equal, and there are many different ways apps can implement it to protect their users and stave off the latest online threats. 

To explore the nuances of MFA and how it fits into the current digital landscape, Stytch’s co-founder and CEO Reed McGinley-Stempel sat down with Jordan Burris, VP and head of public sector strategy at Socure, the preeminent platform for identity verification. As former chief of staff for the White House’s federal chief information officer, Jordan led cybersecurity efforts across two presidential administrations, and he’s a leading expert on issues of identity management and digital trust. 

Missed the live webinar? You can find a full recording of the event on Stytch’s YouTube channel. 

In the latest installment of Stytch Talks, Jordan and Reed tackled everything from the state of the password and advances in biometrics to how new AI tools are emboldening modern hackers. Below, we share seven key takeaways from their discussion and the Q&A, along with actionable strategies to help you take full advantage of MFA.

1. Passwords should be considered “pre-breached” in today’s cybersecurity climate, which is why we need stepped-up auth measures like MFA.

According to recent studies, over half (52%) of global companies have experienced a cybersecurity breach in their operational history, with each attack carrying an average price tag of $4.35 million. 

These stats are scary, but their root cause is entirely avoidable. The vast majority of data breaches (80% in total) can be traced to compromised credentials — that is, weak or reused passwords that can be easily intercepted by hackers and used to take over legitimate accounts. In fact, industry experts at the Open Worldwide Application Security Project (OWASP) advise app developers to treat all passwords as “pre-breached” and to supplement them with stronger security measures like MFA to protect their data. 

Research by Microsoft has shown that layered MFA flows can successfully block up to 99.9% of all password-based cyberattacks. 

That’s because most hackers prefer cheap, high-yield strategies, like using >pre-programmed bots to run automated brute-force or credential-stuffing attacks. By asking for additional credentials that a bot cannot easily provide — like an SMS passcode or biometric verification — MFA requires human intervention, raising the cost and complexity of an attack.



2. The most popular MFA methods are also the least secure, and companies need to find ways to make robust factors easier to adopt.

There’s no one-size-fits-all when it comes to MFA. Which factors a company decides to include in their flow (and when) will largely depend on criteria like their user demographics and the sensitivity of their data. That said, some forms of MFA are inherently more secure than others, and there’s often a tradeoff between strength and usability. 

Most apps opt for factors like SMS one-time passcodes that are both familiar and easy to use, resulting in higher conversion rates. Unfortunately, they’re also the easiest to circumvent, as they’re vulnerable to both phishing and SIM-swapping attacks. 



Stronger factors like time-based one-time passcodes (TOTPs) require users to download a third-party app, introducing friction and the potential for drop-offs. And the strongest WebAuthn factors either force users to buy physical hardware (like YubiKeys) or cannot be implemented across devices (like native biometrics).



Coinbase recently discovered (and publicized) that 95% of their users opt to log in via SMS passcodes, but passcodes also account for 95.65% of their account takeover volume—compared to 4.13% with TOTPs, 0.18% with push authentications, and just 0.04% with a physical security key. 

While optionality will continue to be crucial, companies interested in providing the best protection will find ways to make it easier to adopt more secure factors like TOTPs and passkeys.

3. Emerging AI tools are enabling more sophisticated phishing attacks, making more advanced unphishable MFA more important than ever.

New, AI-powered chatbots like ChatGPT, which saw 100 million users within two months of launching, are empowering hackers to be bolder and more prolific. 

Historically, hackers have used obvious typos in phishing emails, as a way of ensuring respondents are gullible and thus more likely to unwittingly carry out a fraudulent action. That’s because phishing is a predominantly manual method, requiring hackers to interact live with their victims. If conversations can be delegated to a convincing chatbot, hackers can target more sophisticated users with little to no human cost, allowing them to widen their net and increase the volume and scope of their attacks through automation. 

As phishing gets more sophisticated, it’s on companies to adopt unphishable MFA practices that render these more sophisticated fraud attempts a moot point.

4. A top priority is pairing enhanced MFA flows with innovative identity verification tools, to protect users across the access lifecycle.



One of the most pressing needs in cybersecurity is supporting authentication with next-level identity verification strategies — essentially, pairing strong MFA factors from Stytch’s product suite with strong fraud-detection and ID-verification tools from Socure’s. Without the former, you get legitimate user accounts that can be easily breached. Without the latter, you get heavily protected accounts with fake or fraudulent identities behind them. 

In other words, an identity verification flow confirms that a user is the actual individual they claim to be — avoiding gaffes like 2022’s messy Twitter Blue rollout, where any internet troll could claim an “official” Twitter profile under any real/stolen or fictitious identity. 

One instance where this relationship matters is the account recovery process. Authentication can only take users so far if they lose all of their identifiers (their email inbox, the device that was hosting their biometric data, etc.) and they need an easy, secure way to verify their identity and regain access to their accounts. 

That’s why prominent organizations like the FIDO Alliance are making identity verification and binding a top priority in their upcoming cybersecurity initiatives.

5. Biometrics is the future of phishing-resistant MFA, but that means little if people won’t use it.

Biometric factors like fingerprints and facial recognition allow for high-security, low-friction logins, giving them an edge over other auth methods. But biometrics also faces steep challenges when it comes to both user trust and implementation. 

Currently, over half of users (around 58%) trust biometrics more than they do traditional usernames and passwords — but many in the remaining 42% feel strongly that biometric technology violates their privacy and puts their personal data at risk. To bridge these adoption gaps, more education and transparency is needed for users to understand how and why biometric data is used and when it’s shared. Advances are also needed to address situational hurdles, like shared devices used by multiple members of a household. 

From an implementation standpoint, biometric auth has historically been locally bound to a specific device, disrupting the user experience and hindering universal use. Fortunately, innovations like passkeys are making it possible to store and sync biometric data through the cloud, so it’s accessible and interoperable across different platforms and devices. That said, it will be some time before these tools can be widely implemented and adopted. 

In the meantime, a more practical and comfortable solution is to give users and developers a choice in their auth journeys and to ensure the technology used in cybersecurity is as open and inclusive as possible.



6. For a glimpse into best-in-class MFA, look to high-stakes sectors like fintech and government.

Because they have a lot to lose in a data breach, high-risk sectors like fintech and government are great spaces to find examples of MFA best practices in action. Some of the best practices to look for include:

Optionality: Though MFA factors vary in terms of security strength, any MFA is better than no MFA at all. That’s why companies like Coinbase (in the example above) offer users several different paths to log in, so they’re sure to find factors that meet their needs and comfort level.

Future-proofing: Young fintechs like Robinhood tend to be more tech-forward than legacy banks, building advanced factors like TOTP authenticator apps into their log in flows, rather than just SMS and email passcodes. One reason for this could be the irreversible nature of crypto transactions, which places a greater fraud liability on newer companies that trade heavily in digital currencies.

Mandatory (but flexible) MFA: While choices are good, safe choices are better. On the SaaS side, B2B apps like Stripe and Gusto often require MFA, either at initial login or as part of a route-based or just-in-time auth flow. These platforms tend to deal with high-value use cases like payroll, payments, and invoicing with bank accounts attached, so they’ve thought a lot about optimizing both security and adoption

7. The secret to building your MFA flow? Just get started.

Our panelists had a few helpful tips on how to implement MFA efficiently and effectively. Most notably: act decisively, and don’t get mired in analysis paralysis.







The bottom line

MFA is playing an increasingly important role in fighting off evolving cyber attacks, but its success largely depends on how it’s implemented. Learning the ins and outs of different factors, how they match up against the latest threats, and how they affect your specific user base can help you minimize friction, maximize security, and create seamless digital experiences.

Want to learn more about the latest in MFA?

Reach out reed@stytch.com or jordan.burris@socure.com to continue the conversation — or check out Stytch’s flexible suite of authentication solutions to optimize your MFA flow.

---


# Foundations of scalable B2B auth
Source: https://stytch.com/blog/foundations-scalable-b2b-auth/

The foundations of your app's B2B auth solution can make or break your growth trajectory. Learn what to do, and what to avoid.

It’s easy to think about “authentication” as just an isolated, brief interaction where the user performs some sort of challenge to prove their identity. If you think about authentication in that way, your criteria for an authentication provider is probably something like “do they support X login method.” 

However, authentication is anything but isolated – it’s deeply coupled with your core assumptions about what defines a user. The foundational decisions you make around auth and user definitions have long-lasting impacts on how well you are able to scale to meet tomorrow’s needs. 

Nowhere is that more true than in B2B. 

There are a few specific decisions that can make your later scaling journey either painless or challenging, so we’ll look at them one by one.

1. Users and organizations

One of the very first decisions you need to make when building a B2B application is what defines a User, an Organization and their relationship. That sounds pretty easy at first glance – you’re building a tool for teams at work, so a User is an employee of an Organization. Employees of the same company are all typically issued work email addresses, so a User is defined by their work email address. Right? 

Kind of. 

The details around how you might implement this seemingly simple model can end up being the source of enormous headaches and end up limiting the use cases and enterprise customers you can sell to in the future. 

Let’s take a look at each of those approaches and their implications.

One to one relationship

One common approach is to say a User is defined by a globally unique email address and belongs to a single Organization. This makes a lot of intuitive sense – if your application is only something that people would use at work, then the most straightforward approach is to have them login and immediately land in the Organization context that they have access to. 

However, this assumption will start to break down for any companies who work with contractors, agencies or external services that don’t receive corporate email addresses – or where a single company has multiple tenants within your application, in which a few individuals have access to multiple instances. 

If your data model and app architecture are based on the assumption that a user only has access to one Organization, users who need to have access to multiple Organizations will need to leverage email aliases to work around this constraint and will need to constantly be logging out and logging back in, just to switch Organization context. As you scale and start to hit these use cases, you are faced with a difficult choice between a time intensive migration of your core data model or continued frustration on the part of your users.



One to many relationship

If you already know that there are use cases in which a single end user will have access to multiple Organizations, you might choose to say that a User is defined by a globally unique email address but can have permissions or membership to multiple Organizations. 

It is particularly common to choose this data model in the interest of creating a seamless end user experience. After all, if we already know that this is ada.lovelace@stytch.com on Organization A, why would we add additional friction for the end user by asking them to re-authenticate when switching over to Organization B? Shouldn’t we just ask them to login once and then allow them to easily toggle between their different Organizations under the same session? 

Unfortunately, if you achieve this low-friction experience by consolidating into a single User entity that spans multiple Organizations, that consolidation creates a lot of issues the minute you start trying to sell upmarket to enterprise companies. 

Most enterprises require the ability to set their own authentication policies for their members, and they have no reason to trust the authentication policies of other Organizations – particularly when it comes to authentication that happens through another company’s IdP. 

Therefore if ada.lovelace@stytch.com is a single UserID that belongs to both Organization A, which requires that their members all do password login with TOTP MFA, and Organization B, which requires that their members SSO via their workforce IdP, then she would need to go through both sets of authentication requirements – even if she just wants to access Organization A. This can become even more frustrating once you introduce configurable session durations, and Organization A requires that their users have to re-authenticate every 6 hours. 

The data model that seems low-friction for end users at small companies ends up creating tons of friction once you start selling to larger, more security aware customers.

2. JIT (Just-in-Time) provisioning

If you allow self-onboarding (signing up for a new Organization via your site) you might have noticed that people frequently create a new Organization when really what they meant to do was join their co-workers in an existing Organization. 

One really helpful way to address this issue is to introduce the concept of “JIT (Just-in-Time) Provisioning” by email domain. In this setup, an Organization can specify that users with a verified email address from a particular domain can automatically join their Organization without an explicit invite. 

This is incredibly helpful for smaller customers, who likely don’t have a dedicated IT admin in charge of provisioning employees to the tools that they need. Their team is small enough where they’re able to audit on an ad hoc basis. 

That said, it can be easy to go overboard with JIT provisioning, and make decisions that haunt or hurt you – today or in the future.

JIT and 1:1 user/org relationships

One common mistake we’ve seen that quickly becomes an issue is pairing JIT Provisioning with a 1:1 relationship between Users and Organizations. In this data model, an end user can only join a single Organization under their email address. 

This is fine, except if a new end user is accidentally JIT Provisioned to the wrong Organization, they are now prevented from joining the Organization they intended to or creating a new Organization without first deleting their account – which may require reaching out to customer support, creating a frustrating and friction-filled experience. 

This situation may seem unlikely, but consider the case where john.von.neumann@acme.com creates a new Organization on your application, turns on JIT Provisioning for all @acme.com email addresses – and then leaves Acme shortly after. As other Acme employees go to check out your app, they are JIT Provisioned to this abandoned Organization without an active owner – and since the 1:1 data model only allows a single email to belong to a single Organization, they must delete their accounts before being able to create a new Organization. This becomes even messier if your application automatically JIT Provisions, instead of asking the end user if they would like to join the application – because then there is no recourse without deleting the abandoned Organization itself.

JIT and SSO

JIT can also complicate matters further down the road when introducing SSO. Given that the main function of a workforce Identity Provider (IdP) is to centralize managing employee access to the company’s applications, it seems very natural to assume that you can automatically JIT provision any new user who successfully authenticates via the Organization’s IdP. 

However, this assumption starts to break down at scale, especially as you start to take on larger enterprise clients. Some of the biggest Fortune 100 companies in the world use home-grown IdPs that don’t handle app-specific provisioning – meaning that these companies will want to explicitly provision users to your application, rather than rely on their IdP as the source of truth on who can create an account. 

It is important to always make JIT Provisioning configurable to account for the wide variety of company setups and preferences you’ll encounter at scale. As one tech lead we interviewed noted: “For every feature you introduce, someone will literally pay you for the ability to turn it off.”

3. Simplicity doesn’t hold

Early on, all of the members of a given Organization share the same email domain and all use the same Identity Provider. Before you know it, these assumptions have been baked into the foundations of your application: your Organization object uses email_domain as the unique, primary identifier; you put the SAML IdP URI as a singular field on the Organization object; JIT Provisioning is a simple boolean. etc.

Until one day, you encounter your first prospect with subsidiary companies with different email domains, or different IdPs that all follow different JIT Provisioning rules, all within a single Organization. 

Now you are tasked with the unpleasant reality of needing to take a massive refactor to remove uniqueness assumptions spread throughout your database models and millions of lines of application logic – right at the stage of growth when you have a million other, validated and differentiated projects you could be working on instead – or lose out on enterprise prospects whose basic authentication requirements are now “unsupported use cases”.

Save your team future headaches by making the right investments today

Speed of execution is one of the most critical factors in a company’s success or failure, and it is a very rational reaction to read this list of edge cases and say “that’s nice, but we can deal with that if we get there.” 

When you’re still iterating towards PMF, or if your target ICP today are other small startups, it would likely be a waste of precious time to build a fully extensible approach to auth that accounts for multinational subsidiaries, large scale acquisitions and homegrown IdPs. That’s years away, and you have pressing client needs now. 

However, once you’ve made some of these foundational decisions they become incredibly difficult and time consuming to unwind, crippling your ability to scale smoothly, and forcing you to shift resources away from much more differentiated and exciting parts of your product roadmap. 

Luckily, you don’t actually need to make that tradeoff. Instead you can use an authentication provider that is built with these edge cases in mind, that can deliver the consumer-grade, conversion oriented authentication experiences that drive growth and align with your smaller customer’s authentication needs alongside the robust, enterprise grade requirements of the Fortune 100.

---


# Stytch postmortem 2023-02-23
Source: https://stytch.com/blog/stytch-postmortem-2023-02-23/

Stytch postmortem 2023-02-23

On February 23, 2023, an infrastructure configuration change took down all our Kubernetes worker nodes resulting in a full system outage of the Live Stytch API for 14 minutes, the Stytch Frontend SDKs for 17 minutes, and the Stytch Dashboard for 17 minutes. 

We have published our full, internal RCA here. 

We’re sharing these technical details to give our community an understanding of the root cause, how we addressed it, and what we are doing to prevent similar issues from happening again.

Table of contents

Timeline of outage

Background

What happened

Action items

Conclusion

Timeline of outage



Available replicas in the production environment.

All times in the postmortem are in UTC.

20:48 – Deployment Replicas Unavailable Alerts begin firing in production.

21:00 – Engineers identify node group change as likely root cause.

21:10 – Production Live and Test API go down.

21:14 – Support team flags outage.

21:15 – New node groups are launched.

21:17 – Dashboard and SDKs go down.

21:24 – Production Live API service is restored.

21:34 – Dashboard and SDK services are restored.

21:36 – Production Test API service is restored. All systems are operational.

Background

A primer on Stytch infrastructure

Stytch uses AWS EKS, a managed Kubernetes service, to manage our compute infrastructure. AWS EKS offers a few different ways to host nodes that will run the containers – each have their own strengths and unique qualities. Self-managed nodes provide complete control over the instance at the expense of full management of the instance itself. Managed node groups handle the provisioning and lifecycle of Elastic Compute Cloud (EC2) instances through Auto Scaling Groups (ASGs). 

AWS Fargate, as a serverless platform, can offload the complete node management to AWS. 

Stytch initially used managed node groups for shared resources such as CoreDNS, log forwarding, ingress controllers, etc. and Fargate to run major data plane services such as the Stytch API. 

To create these cloud resources (EKS cluster, managed node groups, Fargate profiles, etc.), Stytch uses Crossplane, an open-source tool, which allows us to manage our clusters in code. It also utilizes the Kubernetes control plane to consistently reconcile differences between our clusters and the desired state. Our Crossplane is set up to utilize a “management cluster” which provisions our clusters across environments and accounts.

Migrating from Fargate to EC2 and Karpenter

In H1 2022, we began an effort to migrate from Fargate to EC2 nodes to run our pods and workloads ourselves. Fargate’s slow time to spin up a new pod both impeded our internal development process and hampered our agility to deploy in the case of an incident. We had two major milestones in the project:

Move to intentionally over-provisioned managed node groups which were statically sized.

Use Karpenter to dynamically provision and manage self-managed nodes as our scaling solution for worker nodes to achieve the elastic compute parity that we had with Fargate.



Illustration of how Karpenter operates (source: Karpenter).

Both milestones created positive results for us. Our move to EC2 nodes with managed node groups reduced our complete deploy time from 25+ minutes to under five minutes. Meanwhile, Karpenter’s just-in-time provisioning of a dynamic number of nodes proved to be highly available, quick to schedule new pods, and resilient. We not only made our internal development teams much more efficient, but also improved our ability to scale to meet peak customer load and greatly reduced our time to resolution in the event of an incident. 

Using managed node groups and Karpenter, we had both static compute and dynamic compute. After about a year with this redundancy in place, we felt confident enough in Karpenter’s dynamic compute that the managed node groups were no longer needed. We decided to move fully to just-in-time-provisioned nodes by Karpenter and to remove managed node groups for our data plane applications.

What happened

Root cause: deletion of instance profile (14:21 - 14:50)

14:21 – We landed a change to remove and delete unused managed node groups. 

As a safeguard, our Crossplane resources (XRDs) are set up to use an orphan deletion policy – meaning that, if the Crossplane Kubernetes resource is deleted, the resource is not deleted from the provider. Because of our Crossplane orphan deletion policy, this required us to do some operations in the AWS console. 

In line with established team norms, two engineers paired on the process to make the changes to staging first before rolling out to production. While deleting the node group, the engineers noticed a warning that deleting a managed node group could affect self-managed node groups since the worker role is removed from the aws-auth ConfigMap.



Warning in AWS console.

Like the rest of our infrastructure, this ConfigMap is managed by Crossplane, and we were confident that even if the role was removed from the config map it would be replaced immediately. After noticing no impact in staging, we applied the same changes in production. 

However, unknown to our engineers and absent from AWS documentation, in the background, the AWS API was making opaque clean up calls after a node group deletion. Upon inspection of our CloudTrail logs, we were able to confirm that the node group deletion resulted in the deletion of the instance profile. 

14:24 – The instance profile in staging was deleted. 

14:50 – The instance profile in production was deleted. 

Managing our resources through Crossplane should have saved us here by automatically recreating the deleted instance profile. But while the role was recreated, our Crossplane Cluster Composition used a randomly generated name instead of the previous instance’s profile name which our Karpenter configuration depended on. With these incompatible names, Karpenter did not have the permissions to launch new nodes. 

We would encounter issues several hours later once the deleted instance profile needed to be used again – by either new or existing nodes.

First warning and nodes shutting down (16:06 - 19:54)



Time series of root cause, warning, and outage.

16:06 – We received a low urgency warning in staging that Karpenter could not find the specified instance profile and was unable to launch a new node. The on-call engineer triaged the alert and identified that there were some issues related to the staging environment. The issues were limited to staging and deemed low urgency because existing deployments were healthy and new pods were being scheduled. 

17:48 – We received a similar low urgency warning in production. We came to the same conclusion as we did in staging: we should resolve it today, but it wasn’t a critical incident. 

19:40 – The on-call engineer began investigating the issue in staging to try and understand what changed with the IAM instance profile. 

19:54 – Existing staging nodes began shutting down. We started to receive kube-proxy health notifications in the staging environment. These kube-proxy issues were a symptom of the deletion of the IAM instance profile. At this point our production environment still appeared to be healthy, so we remained focused on fixing staging issues and addressing the root cause.

Unhealthy nodes in production (20:13 - 20:26)

20:13 – Our first production node status was marked as Ready:Unknown by the Kubernetes Control Plane. Because our nodes were running with a deleted instance profile, they slowly began to terminate as they attempted to use the profile.



Rise of unhealthy nodes.

Typically, when a node is in Unknown ready status, and after a five minute wait, the taint controller in the Kubernetes control plane adds an unreachable taint to the node. The taint causes the eviction of all pods running on that node. In our case, our existing nodes were all slowly shut down, then evicted, and we were unable to schedule new pods. 

The Karpenter controller attempted to launch new nodes with the deleted instance profile. Very quickly, our services began degrading with fewer and fewer pods being scheduled.



Pods not being scheduled.

20:26 – These node launching failures spiked our Karpenter error rate. We kicked off our incident process and froze deployments. 

At this point in time, the Stytch API and SDKs were still operational. 

Outage and return to service (20:44 - 21:36)

20:44 – Our Kubernetes monitoring alerts triggered in production. We immediately reshifted our focus to mitigating the impact to production.

21:00 – We identified a node group change as the likely root cause. We reverted the node group deletion, which quickly recreated the node groups. We thought this would mitigate the issue by spinning up healthy nodes with a working instance profile to schedule new pods. But, the new pods did not schedule quickly enough because they had to wait for the new nodes to spin up. 

21:10 – Stytch API went down in production.



Stytch API calls all returning 5XX.

In order to return to service quickly, we manually scaled up one of the Live API node groups with more nodes that were significantly bigger in compute size and removed taints from the node group. We then removed node selectors from the application consecutively so they could schedule. Within minutes, each application was successfully scheduled with the correct number of nodes. 

21:24 – We confirmed the Live API returned to service. 

21:34 – We confirmed the Dashboard and Frontend SDKs returned to service. 

21:36 – We confirmed the Test API returned to service. All our systems were operational again.

Action items

We have a detailed incident postmortem process which allows our team to debrief exactly what went wrong and, most importantly, identify concrete action items and owners to prevent this class of failures from happening again. In this case, we came away with four main focus areas with specific action items that we are either actively working on or have already completed.

1. Alerting improvements

Raise the severity of Karpenter errors and treat them as high urgency alerts that go straight to the on-call pager.

Tune the cluster alerting thresholds to send a high urgency page earlier.

Add alerts for nodes marked as NotReady or Unknown for long periods to better keep track of the health of existing nodes.

Raise the thresholds for other deployment-related alerts including unschedulable pods and replicas not available.

2. Cloud configuration and IAC improvements

Replace the IAM instance profile used by Karpenter to be distinct from the IAM profile used by the node groups.

Separate out other AWS resources (specifically IAM and security group) that were being overloaded in usage.

Overhaul our EKS and Karpenter configuration so that new system instance profiles are unique and static per cluster and generated by Karpenter, reducing complexity.

Introduce a cloud visualization tool to further improve the tools available to our developer team when making infrastructure changes.

3. Status page improvements

Add live system and product metrics to the status page to provide a real-time view of how our Stytch API is behaving.

4. AWS improvements and learnings

Reach out to AWS to confirm the undocumented actions and side effects.

Correct overloaded use of IAM roles and security groups in our infrastructure.

In the wake of the incident, we reached out to AWS in hopes of getting a better understanding of how they handle managed node group deletions. AWS confirmed that the Delete Node Group Action sparked off a set of (undocumented) cascading actions:

DeleteNodegroup API invoked > worker nodes are drained

Pods running on the target node are evicted from draining nodes

Service role cleans up (deletes) any resources associated with the node group (i.e. roles, policies, security groups, etc.)

Worker node instances are terminated

Although it’s not obvious that the instance profile would get deleted, in retrospect, we should never have used the same IAM role for Karpenter self managed nodes as the node groups because overloading the usage of an IAM role would cause the exact issue we encountered during the incident. During our initial configuration of Karpenter, we missed separating out these roles in the interest of expediency and simplicity. 

What made this incident difficult to assess as a whole was the delay between cause and effect. It took on the order of hours until the configuration change started to impact our clusters. We have confirmed with AWS that this is expected behavior and will take this into account when making future IAM instance profile changes.

Conclusion

We are committed to improving our platform and incident process to reduce frequency and duration of incidents, ensure a smoother response and tighter, more detailed communications. In the event of any major disruption of service, Stytch will continue to publish an incident postmortem with context, learnings, and follow ups to share with the community. 

Visit and subscribe to Stytch’s status page and changelog for future updates.

---


# How do voice recognition biometrics work?
Source: https://stytch.com/blog/what-is-voice-biometric-authentication/

Learn how voice recognition technologies enable fast, frictionless logins that protect and delight your users.

In recent years, advances in authentication technology have enabled developers to enhance the cybersecurity of their app or website without overburdening their users or disrupting the user experience. One of the most powerful innovations in this regard is biometrics, or tech-forward tools that can verify a user’s identity using only their physical or behavioral characteristics. 

While fingerprint scans and facial recognition remain the most popular forms of biometrics, other emerging methods like voice remain more on the fringe. 

Below, we explore how voice authentication works, what its benefits are, and perhaps why it hasn’t seen the same level of adoption as other biometric methods.

The basics of biometrics

Biometrics is considered something-you-are authentication, because it relies on attributes that are inherent to a user’s body or behavior. 

This sets biometrics apart from something-you-know auth factors (like passwords), which require users to create and remember complex credentials, and something-you-have auth factors (like one-time passcodes or security keys), which require users to prove possession of a registered phone number, email inbox, or physical device. 

Instead, biometric factors use built-in verification tools to capture, analyze, and recognize a user’s distinctive, measurable features. There are many different types of biometric authentication, with flows that vary according to the specific feature involved. Some of the most common include:

Fingerprint recognition

Fingerprint recognition tools scan and map the unique ridges and valleys of a user’s fingerprint when they press their finger to their laptop or mobile device.

Facial recognition

Facial recognition tools scan and map the proportions and contours of a user’s face and translate them into a unique numerical code known as a “faceprint.”

Iris/retina recognition

Iris and retina recognition tools scan and analyze the distinctive color markings (iris) or the distinctive blood vessel patterns (retina) in a user’s eye.

Voice recognition

Voice recognition tools capture and analyze the sound qualities and other unique properties of a user’s voice, which are determined by their particular jaw movements, throat shape, and behavioral or linguistic inflections. 

Many biometric auth solutions are equipped with liveness detection capabilities, so they can distinguish between a real, live user and a mere reproduction or copy — like a photographic image or voice recording — in order to detect and prevent fraud. 

Let’s dive deeper into what voice recognition technology does and how it works.



What does voice recognition do?

Essentially, voice recognition tools allow users to access, activate, and/or interact with digital platforms simply by speaking to them. They’ve become well-known in recent years, with the release of smartphone software (like Siri) and virtual assistants (like Amazon’s Alexa and Echo devices or Google’s Home or Nest systems). 

However, there’s a big difference between voice recognition technology and the speech recognition technology many of these voice-controlled systems rely on.

Automatic speech recognition (ASR) technology is trained to identify and act upon what is being said, regardless of who is saying it. Think, someone instructing an Alexa device to play a specific song or using a speech-to-text program to transcribe what different participants say during a meeting.

Voice recognition (or speaker recognition) technology is trained to identify who is speaking, based on the unique attributes of their voice. For this reason, voice recognition is typically used to offer a personalized user experience or to provide extra protection in sensitive or risky use cases. Think, someone using a voice command to set or disarm a home security system through Google Home.

When used as an authentication factor, biometric flows rely on voice recognition technology to verify that the person speaking is the legitimate, registered user they say they are.

How does voice recognition work?

Voice recognition tools must be programmed or trained to identify a specific user’s voice. 

This typically involves taking one or more speech samples and creating a unique digital template or “voiceprint” — similar to the fingerprints and faceprints used in other biometrics. This voiceprint is stored within the system and compared against any sample obtained during a log in attempt. 

A voiceprint takes into account physical/physiological as well as behavioral/inflectional attributes, such as a user’s:

Pitch

Timbre

Intensity

Accent or pronunciation

Cadence

Some voice recognition systems require a user to input a specific, pre-determined phrase or sentence — which they must then repeat with every login — whereas others allow a user to say whatever they please.

Accuracy of voice biometrics

The precision of voice recognition technology has improved significantly in recent years, and it continues to make steady progress. As with many authentication methods, voice biometrics is not foolproof, but accuracy rates top 95% on average and frequently reach up to 99%. Compare that to passwords, only 80% of which can be considered even remotely secure.

The benefits of voice biometrics for authentication

When compared to other biometric authentication factors, voice biometric authentication has a couple of distinct advantages. Voice recognition can be used with accessories that sometimes get in the way of other methods, like hats, gloves, masks or sunglasses. Voice biometrics is also contactless. 

That said, there are a few shortcomings that make the voice a less preferable biometric method than others.

Shortcomings of voice biometrics

Some of the downsides that have hampered voice biometric authentication adoption to date include:

Advanced cyber attacks like “voice spoofing” that attempt to record and/or replicate a user’s voice and gain access to an online account. While liveness detection tools help defend against such attacks, hackers are always adapting and improving upon their methods in an effort to outsmart the latest cybersecurity efforts.

Environmental interference like loud background noise, static, and poor connections that can muddle the quality of an audio sample.

Physical impairments like respiratory illnesses, allergies, vocal cord injuries, and other conditions that may alter the sound qualities of a user’s voice.

Privacy concerns around the ethics or safety of devices potentially “listening to” and capturing users’ personal communications.



While some voice recognition solutions are turning to artificial intelligence (AI) and machine learning models to better understand and adapt to changes in the human voice across circumstance, these friction points and spoofability factors make the voice a less attractive biometric option than say, face recognition or fingerprints.

When in doubt, choose what users will adopt

At the end of the day, we at Stytch believe that the security of any given authentication method is effectively moot if users won’t adopt it. So while the tech of voice biometrics may feel like the thing of sci fi movies (and kinda fun!), we’re far more interested in the biometric methods that are gaining traction and popularity, in large part due to the pioneering work of companies like Apple, who have worked hard to make biometrics a seamless, integrated part of their user experience.

Discover Stytch’s biometric authentication

Stytch offers many passwordless authentication solutions as part of our comprehensive product suite, including Native Mobile Biometrics.

---


# What is OAuth 2.0?
Source: https://stytch.com/blog/what-is-oauth-2-0/

An introduction to the OAuth 2.0 protocol, one of the most widely used and influential authorization protocols on the web today.

OAuth (which stands for open authorization) refers to a set of protocols that allow web apps to share information with each other on behalf of a user, without sharing any account credentials. In more technical terms, we can say that OAuth is a protocol that delegates access and permissions between APIs and applications in a safe and reliable exchange. 

OAuth 2.0 is the most recent version of these protocols.

What is the history of OAuth?

OAuth was jointly developed in 2006 by Twitter and Google. With near universal adoption of social media sites, developers realized that their applications would greatly benefit from letting users bring in their data from accounts like Facebook, Twitter, or Google. 

You’re probably most familiar using OAuth with social accounts. If you’ve ever authorized an app to access the resources in your Gmail or Facebook account, you’ve used OAuth. Examples of these authorization prompts look like:

“Allow this app to add all your Facebook friends as contacts?”

“Allow this app to post links on your Twitter feed?”

“Allow this app to sync events with your Google Calendar?”

“Allow this app to use your profile picture from Gmail?”

The beauty of OAuth is its ability to let users provide access to their accounts without exposing their login credentials, and to fine tune what exactly each app can or cannot access within the others' resources. When you're able to specify which actions another app can take with your GoogleDrive contents, you're benefiting from OAuth.

OAuth 2.0 roles

There are four key roles involved in any OAuth transaction: the client, the resource owner, the resource server, and the authorization server. (If you've read our material on OIDC, these may seem familiar because OIDC was built on top of OAuth 2.0!)

Client

This is the service that attempts to obtain access to the resource owner's account or resources that are held on the resource server. This is the application seeking authorization, and is often also referred to as the application.

Resource owner

The resource owner is the user, application, site, or system that owns the resources the client is trying to access. This is the application granting authorization, and is often also referred to as the user.

Resource server

The resource server is where the resource owner hosts its protected resources or accounts on behalf of the user, or resource owner.

Authorization server

The authorization server is the party that makes it possible to grant authorization between different apps or services without sharing credentials. They both verify the identity of the user and send the access tokens to the client on behalf of the resource server once access has been granted.

OAuth 2.0 basic flow

Now that we understand the main roles involved in an OAuth 2.0 transaction, let’s look at the basic flow. Note that there are a few different OAuth flows that vary by the grant type (see below), so for covering the basics today we're just going to look at the most common – the authorization code flow. 

Here's how it works:

Client requests access to the resource server from the resource owner.

If this is something they want, the resource owner then grants access.

Upon granting access, the client receives an authorization grant.

The client then presents this authorization grant to the authorization server, and requests an access token.

Assuming the resource owner granted access, the authorization server will then issue an access token to the client.

Using their newly-minted access token, the client then requests access to the resources in question from the resource server.

The resource server then passes the resources to the client.

Success! Now that we have the lay of the land, let’s look a little closer at each of these steps to understand what exactly each role is passing to each other, and how.

Step 0 – Client registration

While the first step of a basic OAuth 2.0 generally begins with the client's authorization request, it technically begins with client registration. To do this, they’ll need three main inputs: their application name, their application website, and a redirect URI where the resource server can redirect the user after access has been authorized. These registered URIs help prevent token stealing and other attacks. 

Upon completing registration, the client receives two key pieces of information they’ll need for their authorization request:

CLIENT ID

The client ID is a public string that the resource server uses to identify the client.

CLIENT SECRET

The client secret is a private string that is used to verify the identity of the client with the resource server when they submit their access token in step 6.



Step 1 – Client requests authorization

Once registered, a client kicks off an OAuth 2.0 transaction when the client requests to access resources belonging to the resource owner. 

This is most commonly done by actually creating a URL for the user to click on that redirects them to the authorization server. The application makes sure this URL has all the relevant information including the client_id, the scope, the authorization grant type, and a PKCE code, if they have one. Let’s look at what all of those parameters entail (except client ID, which we just learned):

SCOPE

The scope defines the exact resources to which the resource owner is granting the client access. So if for example you want to give Twitter access to your GooglePhotos, the scope parameter helps ensure that Twitter doesn't also gain access to any other resources on your Google account.

GRANT TYPE

The grant type refers to the method used to authorize the client on behalf of the resource server, and depends both on the grant type requested by the client and the capabilities of the resource server's API. 

There are generally three types of authorization grants, each with their own best use cases: authorization code, client credentials, and device code. (You may also hear some OAuth literature discuss implicit and password grant types, but these are considered legacy practices and not recommended today because of various security concerns).

Grant Type: Authorization Code: The authorization code grant type is the most popular among server-side web and mobile apps, as these apps' source code is not publicly available, making it easier to protect confidential information like the client secret. It is usually a simple string of alphanumeric characters.

Grant Type: Client Credentials: The client credentials grant type is a bit of an outlier, as it's only used when the client is trying to access its own account, not the account of a user. This can be helpful if and when the client needs to update their information with the resource server, like their redirect URI.

Grant type: device code: Device code grants are best suited to use cases where a device has no browser access (and thus is unable to meet the requirements of an authorization code grant type). Good examples of this include SmartTVs or other media devices, which have tons of apps that may want to access a user's resources, but have no ability to interact with a browser on the client's side.

PKCE CODE

The authorization code flow also has an extension called PKCE, or Proof Key for Code Exchange, that helps thwart cross site request forgery (CSRF) and authorization code injection attacks. In this system, the client creates a secret with each authorization request, which they then resubmit with the authorization code when requesting the access token. This helps ensure that if the authorization code is intercepted, attackers still won't be able to gain authorization without that additional secret.

Step 2 — User authorizes client access

When the user clicks on this newly-minted link, they will be taken to a URL with an authorization request. This is the part of this transaction we've most likely seen before, something like, "This application [aka the client] would like to access resources on your account [aka the resource server]. Do you authorize this access?" 

We'll proceed with the rest of this flow on the assumption the user clicks "Yes"!

Step 3 — Client receives authorization grant (in this case authorization code)

Once the user authorizes access, the authorization server will redirect them back to the client's application, but to a URL that includes the authorization code. Note this is sent as an HTTP request from the authorization server to the user's browser – there's no direct communication with the client's application.

Step 4 – Client requests access token

Once they have their authorization code, the client requests the access token from the authorization server by making an HTTP POST request, which includes the authorization code, the grant type, the redirect URI, the client ID, client secret, and PKCE code verifier if they're using it.

ACCESS TOKENS

Access tokens are how the client is able to make API calls on behalf of the resource owner: they prove to the resource server that the client is authorized to do and access certain resources on that user's behalf. Because they give authorization permission to whoever bears them, they are also sometimes called bearer tokens. 

Access tokens can come in a variety of formats, but generally consist of an alphanumeric string that is randomly generated and then securely stored with the authorization server. Some authorization servers opt for self-encoded tokens, which encode all the necessary information within the code string itself, thereby eliminating the need of a server-side database. 

Regardless of the token's form, it is important in every case that they are kept confidential when in transit from the authorization server to the client, and from the client to the resource server. For that reason, access tokens can only be exchanged across HTTPS connections.

Step 5 - Authorization server issues access token

Upon receiving this HTTP post request, assuming all of the parameters are correct, the authorization server will issue an access token (and sometimes a refresh token), along with the token type and the expiration time.

Step 6 — Client requests resources with the access token

With the access token in hand, the client can now request access directly from the resource server via an API call. This should be successful so long as the access token has not yet expired.

Step 7 — Resource server returns the resource to the client

If the API request contains all the correct information, the resource server will grant the client access to the scoped resources. 

And with that, we have a successful OAuth 2.0 transaction!

How is OAuth 2.0 different from OAuth 1.0?

OAuth 1.0, released in 2007, was the initial result of Twitter and Google's collaboration. It was largely based on two pre-existing protocols: Flickr’s authorization API (remember Flicker?) and Google’s AuthSub. After several years of developers using OAuth 1.0 out in the wild, a larger group of invested companies began discussing possible improvements. These companies included Facebook, Microsoft, Mozilla, and Yahoo!, (as well as the original collaborators Google and Twitter). 

In 2012, five years after 1.0, OAuth 2.0 was released. It came with some major improvements:

From three roles to four

In OAuth 1.0, there are only three roles, not four: the consumer (what we now call the client), the user (what we now call the resource owner), and the service provider (what we now call the resource server and the authorization server, collapsed into one).

From cryptographic signatures to bearer tokens

Instead of bearer tokens, OAuth 1.0 uses cryptographic signatures, in which each access token has both a public and private string, with the private string being used to sign the authorization request. Because bearer tokens don't require a cryptographic signing of every request, they're viewed as a simpler, more elegant access token solution.

From one flow to several grant types

OAuth 1.0 originally had three flow types, but those were eventually collapsed into a single flow that was supposed to work for all use cases – web-based apps, desktop clients, and browserless apps. But as OAuth use scaled, it became clear that this "one-size-fits-all" approach actually resulted in clunky functionality and poor user experience. Hence the variety of grant types in OAuth 2.0, that allow more tailored flows for different use cases.

From long to short-lived access tokens

As originally implemented, OAuth 1.0 tokens were valid for a very long time, sometimes indefinitely or up to a year (yikes!). OAuth 2.0 replaced this system with very short-lived access tokens and the option to implement longer-lasting refresh tokens – a much better way of allowing minimally disruptive session refreshes without compromising on security.

Why is OAuth 2.0 important?

Every person who's online today divides their resources between upwards of dozens of applications. With so many of our individual and company resources increasingly stored on the cloud, interoperability and mutual access become all the more important. But with that increased interoperability comes great responsibility, and potential security risk. OAuth 2.0 is a crucial piece of cloud-based information access and sharing because it enables for secure, scoped, delegated access. 

Additionally, OAuth 2.0 paved the way for OpenID Connect (OIDC), an authentication and authorization protocol that allows users authenticated in one place to gain access to resources in another (if you've ever used "social login," or logged into another app with your Google, Facebook, or LinkedIn account – you've used OIDC!). 

At Stytch, we offer social login for consumer-facing applications, and are on the verge of releasing our beta OIDC-based single sign on for B2B businesses. 

If you're interested in how these products might help streamline your developer's workload, feel free to explore our docs or talk to sales by clicking the links below.

---


# Authentication vs. authorization: what you need to know
Source: https://stytch.com/blog/authentication-vs-authorization/

Both authentication and authorization are critical for session management. Let's look at how they're different, and how they work together.

Authentication (authN) and authorization (authZ) have a lot in common, which is why they’re often confused. Both play a key role in user identity and access management (IAM), both have a big impact on the user experience, and as words, they look and sound pretty alike.

But the parallels end there. In fact, authentication and authorization serve very different purposes, though each is essential when it comes to protecting your app. Ideally, it shouldn’t be “authentication vs. authorization,” but both “authentication and authorization.”

In this post, we explore the key differences between these two critical processes and explain how they work together (but separately) as part of your app’s security architecture.

What is authentication?

At the most basic level, authentication verifies a user’s identity, ensuring a user is who they claim to be before they gain access to an app. Typically, a user must provide one or more authentication factors (or credentials), which can fall into three different categories:

Something-you-know, like a password or personal detail

Something-you-have, like proven possession of a registered mobile device, security access token, or digital ID card

Something-you-are, like biometric data from fingerprints, retinal scans, facial recognition, or voice recognition

The authentication process

Historically, the user authentication process relied on basic factors like passwords and PINs, which can cause significant cybersecurity gaps and UX concerns. (Case in point: today, over 80% of data breaches come from stolen or otherwise compromised passwords).

But as the online security process has evolved and grown more sophisticated, forward-thinking companies have increasingly switched to passwordless authentication methods, like one-time passcodes, email magic links, and biometrics.

Depending on your business needs and the sensitivity of the user data you work with, there’s a wide range of methods you can use to build out your authentication system. The three main types, from least to most secure, are:

Single-factor authentication

In a single-factor flow, only one layer of verification is required — for example, a username-and-password pair.

Two-factor authentication (2FA)

In a two-factor flow, a user must supply a password plus a secondary credential, which could be anything from a security question (e.g., the classic “What’s your mother’s maiden name?”) to an SMS one-time passcode.

Multi-factor authentication (MFA)

In a multi-factor authentication (or MFA) flow, two authentication factors or more are required. That means 2FA is considered MFA, but not all MFA flows are 2FA.

Multi-factor authentication can be front-loaded at initial log in — meaning users must pass through all authentication steps at once just to enter an app — or they can be spread throughout the user journey. The latter method is known as just-in-time authentication, as it allows developers to introduce extra security steps (and thus, extra friction) only when a user attempts to access sensitive information or carry out a sensitive task, like changing payment details or viewing confidential data.

What is authorization?

After a successful authentication, authorization verifies what a user is permitted — and not permitted — to do within the app. In other words, user authorization processes grant access rights to specific resources and give a user permission to undertake specific actions like viewing, editing, downloading, or deleting important data.



How authorization determines access control

Access control, or unique user permissions, can be structured in a few different ways:

Role-based access control (RBAC)

In a role-based model of control, access to information is based on the user’s position within an organization.

Attribute-based access control (ABAC)

In an attribute-based model, access to information is limited and based on a complex series of factors, potentially including:

User attributes, such as name, organization, ID, and level of security clearance

Environmental attributes, such as the time or location of access or the current level of organizational threat

Resource attributes, such as a file’s owner or department or its level of data sensitivity

Rule-based access control (also RBAC)

In a rule-based access control model, user access is determined by fixed, standardized guidelines, rather than subjective or variable criteria.

Authentication vs. authorization: key points of difference

There’s a common analogy used to explain the difference between authentication and authorization: think of it like an airport. When you pass through security, you’re asked to provide a boarding pass and formal identification like a driver’s license or passport. These two factors prove that you’re allowed to enter the terminal. That’s authentication.

Once you’re in the terminal, the details on the boarding pass determine where you can go. For example, you can use your pass to board your plane and take your assigned seat, but if you try to get on a different flight or gain access to an employee-only area, you’ll be denied entry. That’s authorization.

In addition to having separate functions, authentication and authorization differ in the role played by the user:

The authentication process is visible to the user. The user can also change certain authentication settings by resetting a password, modifying security questions, or choosing to register biometric data.

The authorization process is rarely user-facing. Rather, permissions are pre-set and maintained on the back end by the organization.

Let’s break these differences down into one easy chart for comparison:



Combining authentication and authorization with session management

Authentication and authorization work in tandem to create a secure environment for both the end user and the app or website they’re using. In a standard flow, authentication comes first, followed by authorization.

One component of authorization is session management, or the process of storing contextual information for a given user. For example, session management can be used to determine if a user is still logged in or if their session has expired, and it’s often coupled with permissions data about what that authenticated user can and cannot access.

Typically, that permissions data is stored either with session cookies or access tokens (typically JSON web tokens, or JWTs). At Stytch, we let you use both, but if you want to dive deeper you can read our blog on the differences and tradeoffs between session cookies and JWTs.

The bottom line

“Authentication vs. authorization” is a bit of misnomer – both contribute substantially to your app’s IAM. Together, authentication and authorization ensure you grant secure access to the right users at the right time.

Take your auth up a notch with Stytch

Now that you can distinguish authentication vs. authorization, the next step is finding a security flow that fits your needs. That’s where Stytch comes in. Our passwordless product suite and breach-resistant Passwords strike the perfect balance between robust protections and a frictionless user experience.

Register for a free account to begin exploring — or reach out to our team to get your questions answered.

---


# What is SOC 1 Type 2?
Source: https://stytch.com/blog/what-is-soc-1-type-2/

An overview of SOC reports, and the specific importance of SOC 1 Type 2 for service organizations and applications.

If you’re working as or with a company that handles sensitive financial data, at some point you’re going to need to ask for — or you're going to be asked for — a SOC 1 Type 2 report. 

When this occurs, it helps to know what to expect from a SOC 1 report, how it differs from other SOC reports, and why it’s a good idea for any service-providing organization to have their report up-to-date and at the ready. 

So, let’s break it all down, starting with the basics.

What is a SOC report, exactly?

SOC stands for system and organization controls, formerly service organizations controls. At the broadest level, SOC refers to a suite of reports issued and overseen by the American Institute of Certified Public Accountants (AICPA). 

To receive any SOC report, a service provider — or any organization that handles potentially sensitive customer data and documents, including user entities' financial statements, health records, and any other private or confidential information — must pass a SOC examination or audit conducted by an independent, third-party CPA.

Types of SOC reports

There are three general categories of SOC reports. Each reporting option is subject to distinct AICPA auditing standards, which are outlined in their Statements on Standards for Attestation Engagements (SSAE).

SOC 1 reports

SOC 1 reports are financial in scope. They mainly concern what AICPA refers to as the "controls at a service organization relevant to user entities' internal control over financial reporting." 

In simpler terms, a SOC 1 report evaluates the systems, policies, and procedures that a financial service organization uses to manage and protect their customers’ financial data. How these systems work, and how well they work, will directly affect customers' internal controls over financial reporting (ICFR). 

In a SOC 1 audit, key control objectives are identified and tested for both information technology (IT) and business processes around the specific services an organization provides their customers.

SOC 2 reports

SOC 2 reports deal with a service organization's internal controls around operations and compliance. They test in five specific areas that are laid out in the AICPA’s Trust Services Criteria (TSC):

Security

Availability

Processing integrity

Confidentiality

Privacy

The security criteria (also called the common criteria) are the only required elements when it comes to SOC 2. Otherwise, the main difference between SOC 1 and SOC 2 reports is that, in a SOC 2 report, an organization can choose which other criteria to include in an audit.

SOC 3 reports

SOC 3 reports are far less common. They cover much of the same ground as SOC 2 reports, but with a less comprehensive approach. 

Typically, a SOC 3 report omits details around the specific controls at a service organization and the results of any SOC examinations. That also means that, unlike a SOC 2 report, a SOC 3 report can be publicly shared. For example, a service organization can post its SOC 3 report on their website or distribute it to potential clients as a marketing asset.

SOC for cybersecurity

More recently, as cyberattacks have increased in both frequency and sophistication, AICPA has developed a new SOC for Cybersecurity report. This report examines a service organization's system as it relates to their risk management program and online security practices.

Type 1 and Type 2 reports

Each of the above SOC categories can be further broken down into Type 1 and Type 2 reports. While each report type includes similar parameters, there are a few key differences between them. 

A Type 1 (or Type I) report evaluates the design of a service organization's system and its ability to achieve the related control objectives included in the audit, as of a specified date. 

A Type 2 (or Type II) report assesses both the design and operating effectiveness of a service organization's system and its ability to achieve related control objectives over a specific period of time — usually six months. 

In short, a Type 2 report sets a higher bar by examining not only the design of a service organization's system, but also its performance. Furthermore, Type 2 reports cover a longer audit period, ensuring that a service organization's controls work reliably and consistently. 

There are times when a service organization might pursue a Type 1 report on its own — like if they are pressed for time and just need to prove that they have certain controls in place. But generally, Type 2 reports are seen as the standard to which service organizations should be held.

Meeting control objectives and criteria

It should be noted that SOC reporting allows for flexibility in terms of how exactly different objectives and criteria are met. 

For example, when evaluating controls related to cybersecurity, any combination of safeguards and authentication methods — from passcodes to biometrics — can be used to fulfill necessary criteria.

Why is a SOC 1 Type 2 report important?

Putting the above points together, a SOC 1 Type 2 report attests not only that a given service organization has the right controls over financial reporting in place, but that an objective auditor has confirmed that those controls are performing reliably and effectively. 

In other words, it goes beyond mere compliance. A SOC 1 Type 2 report is a stamp of approval from a recognized regulatory body verifying that a service organization can be trusted to maintain the security and integrity of their customers' financial data.

When should you ask a service organization for a SOC 1 Type 2 report? (Or, when might you be asked to provide one?)

SOC 1 report checks are a key ingredient in strong organization vendor management programs. Ideally, you should ask to see evidence of a valid SOC 1 Type 2 report any time you outsource a financial service to a third-party vendor. 

For example, if you rely on an external partner or platform to handle your payroll processing, the way they handle your payroll data will have a direct impact on your own financial reports and processes. You want to know that they have solid policies and procedures in place to handle your data accurately and responsibly. 

Similarly, if you handle financial services on other companies' behalf, you want to be able to demonstrate the same — and you should have evidence of your own SOC 1 certifications ready to go. 

It's not just a best practice and part of being an ethical business partner; it's a key selling point for your organization as you work to stand out from the competition.

The bottom line

A SOC 1 Type 2 report demonstrates that a service provider has the right controls in place to manage financial data on behalf of their customers and to handle that data properly. 

Obtaining and presenting these certifications should be standard practice for all financial service organizations, and making this a universal practice will help us to build safer and more transparent partnerships when it comes to sharing sensitive data online.

Learn more

Stytch is committed to supporting secure, frictionless digital experiences, from robust authentication solutions to fraud and risk prevention strategies. 

If you want to learn more about how SOC 1 and SOC 2 reports contribute to your online security — or what they might mean for your organization — reach out to one of our data experts, and get your questions answered.

---


# IdP- vs SP-initiated SSO
Source: https://stytch.com/blog/idp-vs-sp-sso/

IdP and SP initiated SSO may appear similar on the surface, but a few differences result in critical vulnerabilities for B2B customers.

In today's world where the average business manages 88 applications, single sign-on has become indispensable. IT professionals looking to manage their company's identity and access management, from user authentication to identity providers, rely on SSO to simplify work streams for them and the users they manage. 

But not all single sign-on solutions are created equally. 

As we covered in-depth in our B2B Auth School series, there are two main technical protocols used for single sign on today: Security Assertion Markup Language (SAML) and OpenID Connect (OIDC). Within SAML, there are two main types of login flows: those initiated by identity providers, and those initiated with service providers. 

In this blog post, we'll look at the differences between these two forms of SAML single sign-on, and their implications for developers looking to incorporate SSO capabilities into their application.

Recap: what is SAML and how does it work?

Security Assertion Markup Language, or SAML, is the legacy standard protocol for single sign on. Specifically, SAML standardizes the exchange of authentication and authorization data between parties, most commonly for single sign-on transactions. Those parties are typically defined as:

Service Provider (SP): the B2B app or website that users attempt to log into. In SAML, they receive both user identities and control user access to resources from the Identity Provider via a SAML assertion.

Identity Provider (IdP): the service that maintains user identities and issues SAML responses on behalf of the B2B customer (i.e. Okta, OneLogin).

Auth provider: a 3rd party or in-house auth solution that interfaces and coordinates auth flows between identity providers and service providers.

B2B customer: the customers of the SP (usually a company or businesses) that wish to log into the service provider’s application with SSO, and use an identity provider for identity management.

Member: also often referred to as a user, the member in B2B authentication is the end user who is a part of the B2B customer’s organization within the service provider’s app. They are the person or machine attempting to authenticate (or “gain user access”) to resources within the service provider using their identity provider.

SAML standardizes transactions between these different parties through requests and responses written in extensible markup language (XML) (for a closer look at how these SAML messages work, check out our in-depth blog on SAML transactions).

SP vs. IdP SSO: a crucial difference

The phrases "SP" or "IdP-initiated SSO" refers to where a member begins their user authentication journey.

SP-initiated: they can start their login journey with the service provider, which will then redirect them to the identity provider for authentication, OR

IdP-initiated: they can start their login journey directly with their identity provider, and once authenticated they can navigate to the service provider they wish to access.



While these two options only slightly alter the experience for the end user, it's the transactions behind the scenes that are crucially different.

SP-initiated

A member of an organization (likely an employee of a company) goes to log in to the app they want to use (i.e., the SP).

The service provider then redirects that member to their company's identity provider, with a SAML request. Among other pieces of information, this request contains two key parameters: a requestID, that uniquely identifies this authentication request, and a RelayState, which can be a string of any value added to the SAML request URL. These two parameters are used later to verify that the IdP's response is in fact intended for this user and this SP.

Once redirected, the member authenticates with the identity provider.

After the member has authenticated, the identity provider then creates a SAML response with all the relevant information about that member (their ID, what resources they're authorized to access). This response also includes an InResponseTo field that verifies requestID, as well a separate parameter verifying the RelayState

When the SP receives the IdP's SAML assertion, it checks the requestID and RelayState against the ones in its records, to make sure the correct request is being addressed by the IdP.

Upon receipt and verification of the SAML response by the SP, the user is logged in.

IdP-initiated

Instead of going to the SP, the member begins by logging in directly to their IdP.

Once authenticated, the member can then see all of the apps and resources their company has granted them access to. They select the app or service they want to use.

The IdP then creates the SAML assertion, and redirects the member to the SP. Like with SP-initiated SSO, this assertion contains information about the user and resources they can access, but it does not contain a requestID or RelayState.

Assuming the SP accepts the assertion, the member is then logged in.

The main difference then, between IdP and SP-initiated SSO on the backend amounts to one additional redirect and two additional parameters. As we'll see in the next section, those components can make a world of difference.



IdP-initiated vulnerabilities

Without the requestID and RelayState in IdP-initiated SSO, there is no way for the SP to verify that the SAML assertion they're receiving corresponds to the right request. 

In other words, if a hacker or bad actor were to gain access to an IdP-initiated SAML assertion, they could access the member's account with the SP application, even if the member themselves did not request it. 

In this "man-in-the-middle" type of attack, the SAML assertion is intercepted on its way from the IdP to the SP, as follows:

  The member logs in directly to their IdP.

Once authenticated, the member can then see all of the apps and resources their company has granted them access to. They select the app or service they want to use.

The IdP then creates the SAML assertion, and redirects the member to the SP. Like with SP-initiated SSO, this assertion contains information about the user and resources they can access, but it does not contain a requestID or RelayState.

The hacker-in-the-middle intercepts the SAML assertion before it reaches the SP.

At this point, the hacker will either log into the SP posing as the organization member, or it can replace the IdP's SAML assertion with another that logs the member into the SP as the attacker.

When the SP receives the SAML assertion, all they have to go off of are the issuer (the IdP) and the signature, which, if the hacker leaves them untampered, will appear valid.



In each of these scenarios, without additional security measures, there's no way to verify this SAML assertion is in fact resulting from a legitimate member's authentication request.

A SAML-only issue

If you’ve read any of our B2B auth school series, you’ll know that SAML is now one of two major protocols for single sign on – OpenID Connect, or OIDC is the other. 

IdP-initiated SSO is not a concern with OIDC though because it is not possible with that protocol. By design and because of its direct evolution from OAuth 2.0, OIDC authentication is token-based, with identity tokens that are designed to be read and validated by the same application that made the authorization request. Even in cases where members begin the authentication process from a third party that is not the service provider (or what’s called the relying party or RP in OIDC), the member is still first directed to the RP initiation endpoint, and begins the transaction almost identically to a true RP (or in SAML’s case, SP) initiated SSO login. 

XML is more flexible, but as we’ve seen, that flexibility comes with risk.

Protecting IdP-initiated SSO

So what's to be done? There are a few steps that can be taken to thwart these attacks, but they unfortunately put the onus on the SP (and/or the SP's authentication provider):

Beware the unsolicited InResponseTo

The SAML 2.0 specification warns that an SP must not validate any unsolicited SAML responses they receive from IdPs that contain the InResponseTo parameter. This indicates a prior SP-initiated SAML assertion has been intercepted from the IdP and is being falsely re-used in an attempt to gain unauthorized access to the member's account.

Set tight validity periods

Both the IdP and the SP have the power to set the validity period (the time for which a SAML assertion is considered trustworthy or valid). Generally, no IdP should take more than a couple minutes to issue a SAML assertion, so any time longer than that and you risk leaving your application open to those attacks. Standard constraints include NotBefore and NotOnOrAfter.

Replay detection

In addition to setting tight expiry windows on your SAML assertions, SPs can also track which messages have already been used and prevent those from being reused by hackers. That said, replay detection does not protect against hackers intercepting unused SAML assertions.

Dealing with SAML for your product

Despite these vulnerabilities, many B2B customers today still prefer IdP-initiated SSO. This is in part because from their IT department's perspective, certain aspects of user identity and authentication services are easier to manage with centralized, gated, access to all their different apps and services. 

But this means that service providers working with these IdPs then need to work very carefully with either their in-house auth team or their auth provider to put all necessary precautions in place to protect their customers and users from IdP-initiated SSO vulnerabilities. None of the solutions above are ironclad, so it's doubly important to have dedicated conversations with your customers and your auth provider about how best to offer protection with their preferred SSO method.

If these challenges sound like something you'd like to talk to an auth provider about, we'd love to chat about our own SSO solutions.

---


# Announcing new pricing and self-serve options
Source: https://stytch.com/blog/announcing-new-pricing-and-self-serve-options/

Stytch announces our new pricing model, designed with more tiers and support for our growing diverse base of customers.

Today, we’re excited to launch new pricing tiers that will provide customers with more self-serve options along with greater transparency, flexibility, and scalability. 

These changes will take effect today for all new customers. For our existing contracted customers, you will continue to enjoy access to your full features and benefits at the same price. For our existing pay-as-you-go customers, you will be moved to our free self-serve tier while maintaining your full set of existing features. Specific details can be found on our website at https://stytch.com/pricing. 

In particular, customers will see the following changes:

We’ve created a feature-packed free tier for both our B2C and B2B product suites. For B2C, all of our auth products and 5,000 MAUs are included. For B2B, all basic auth products and 1,000 MAUs + 25 monthly active organizations are included

We’re introducing new, distinct pricing tiers for our B2B product offerings

Self-serve upgrades and downgrades are now available in the Stytch dashboard

We will be adding pass-through usage fees for International (non-US or Canada) WhatsApp and SMS passcodes, but this change will not take effect for existing customers until 8/1/23

A history of pricing at Stytch – in SaaS pricing, simplicity can become a false idol

Our initial (and very basic) pricing philosophy was that simplicity > perfection. Based on our own frustrations with the incumbent solutions in the authentication market, we believed that presenting our pricing more simply than competitors’ complex, opaque tiers could absolve many of our yet-to-be-discovered pricing shortcomings. This philosophy scaled surprisingly well with us for most of the past 2 years as we brought thousands of developers, hundreds of paying customers, and millions of users onto our platform. 

But as we’ve grown our product suite, we’ve found that simplicity can become a false idol if it’s your primary pricing objective. Simplicity matters a lot in purchasing decisions (and it remains one of our pricing values), but overly simplistic pricing can actually harm customers. With our legacy pricing, we took the approach of offering developers two options:

A pay-as-you-go self-serve tier that included all authentication products at a higher unit rate

A custom contract with volume discounts, personalized pricing, and premium features



We’d seen this simpler two-option approach work well with some of our favorite developer tools (e.g. Stripe), but we’ve found it doesn’t translate well from the payments market to the authentication market for a number of reasons. For us, it created unintended consequences that required a new pricing philosophy to account for our maturing product and customer base.



Given Stripe's value prop as the "gatekeeper" of their customers' payments, Stripe has been able to maintain a consistent, single self-serve option for more than a decade. This fits Stripe’s business model well because payment acceptance products are always placed at the exact point of realized customer value – customers only pay Stripe when they make money. This allows Stripe to forgo a free offering and immediately start customers on a higher margin pay-as-you-go plan. And despite offering a high margin for Stripe, this is also amenable for customers because most internet businesses can easily absorb a ~3% cost of revenue for core infrastructure. For non-payments SaaS, there’s a much wider spectrum of value you’re providing to different customers, which makes a “one size fits all” self-serve tier untenable.

Crafting a new pricing philosophy

As our legacy pricing model started to strain in recent months, the primary culprit was the oversimplification of our self-serve tier. What started as a singular pay-as-you-go option when we had just one authentication product became a catch-all bucket for most new features. As new auth products launched, we’d roll these new features into the overall monthly active user (MAU) cost of 10 cents in our pay-as-you-go plan. Initially, we deemed this the most customer-friendly route (providing more features at the same cost meant customers didn’t have to worry about being nickel and dimed for each new feature). 

However, this “one size fits all” approach became a “one size fits none” approach as customer segments were using markedly different products (and receiving disparate value) but all paying the same MAU cost, regardless of the underlying cost of serving each customer. In particular, the cost to serve each customer began to diverge significantly once we launched our phone-based authentication products (SMS and WhatsApp). SMS and WhatsApp are relatively expensive rails when compared to authentication methods like email (programmatic email is a commoditized product with small unit rate costs) and social logins or biometrics (e.g. offering FaceID and Sign in with Google/Apple/Facebook/etc involve significant upfront costs but are lower marginal cost to serve thereafter). Additionally, SMS/WhatsApp are even more expensive to serve internationally. 

Our self-serve pricing tier first started to strain when we included these phone-based auth methods within our overall MAU rate. This decision stemmed from initially only supporting North America for these products – in these geographies, the costs were low enough to roll into the 10 cent MAU cost and maintain a healthy margin. But as we onboarded more global customers, we incurred significantly higher international SMS and WhatsApp costs. 

While this is a particularly salient example, we found similar issues arise as we launched other new products like B2B authentication (SSO), fraud + risk tools, extensive customization, and enterprise admin controls – rolling so many disparate features into a single self-serve tier became increasingly untenable. As both our customer base and platform has expanded over the past couple years, we want to give customers enough options to choose what works best for their needs and budget. Here are the primary changes we’re incorporating:

Launching multiple self-serve tiers to better segment customer needs

Our current "one size fits all" pricing means "one size fits none" - we’re launching new tiers to better segment customers into different tiers (free and paid), so they can self-select into the tier that fits their needs and budget

Additional self-serve tiers reduce friction for customers to sign up with Stytch and access features without having to contact our Sales team.

This means you can talk to our team on your terms and timeframes.. Our sales team is ready to assist you when your needs evolve, your company grows, and you require enterprise-grade features like bot prevention, uptime SLAs, and volume discounts.

Creating a more generous free tier

We’re intentionally providing far more features in our free tier than competitors, so customers can set up auth for free without hitting annoying roadblocks with feature gates. In our free tier, we’re proud to include all of our authentication methods, no admin limits, password breach detection, phishing-resistant MFA like biometrics, unlimited OAuth connections, SMS and WhatsApp OTPs, and much more.

Separating B2C and B2B pricing for greater customer clarity + customization

We’re excited to introduce standalone B2B and B2C pricing tiers - these distinct tiers should help minimize confusion across our feature sets. And if you do have a use case across our B2B and B2C product lines, you can manage both within the same workspace.

Improving how we scale with customers

We care about pricing that scales as you grow - avoiding a common practice by competitors to charge predatory pricing once you're already locked in. Our MAU costs won't scale by 5x when you want to access more features - and from the start, you can access all of our auth products, MFA, unlimited OAuth, and plenty more without being forced into a five- or six-digit contract.

Passing through expensive marginal costs (e.g. international SMS/WhatsApp) to ensure cost is value aligned for all customers

To lower our starting price per MAU for all customers, we’ll be passing through international (non-US, non-Canada) SMS and WhatsApp OTP costs as these costs have an outsized impact on our cost of goods sold (COGS). Historically, we needed to charge a higher MAU rate for all customers to cover these costs, which was unfair to those not sending international OTPs.

Opening consistent lines of communication with customers and prospects on pricing

We’ve interviewed dozens of customers and prospective customers to preview the changes, but we can’t anticipate everything. We actively welcome feedback from customers and prospects to help us determine where we need to continue iterating.

Supporting customers through this transition

While we made these changes with the intent of improving pricing for customers, we understand that change can sometimes be difficult, and we value the trust you've placed in us. To make this transition as smooth as possible, we are pleased to offer the following to existing customers:

Legacy Pricing: For our contracted customers, you will continue to enjoy access to your features and benefits with no impact on your pricing. If you do have questions on any changes, please reach out to your Sales representative. For our self-serve customers, you will have access to your existing features, plus full access to the new free tier - including free usage up to 5,000 B2C MAUs or 1,000 B2B MAUs. As part of this transition, we will not charge any existing customers for International WhatsApp and SMS passcodes until 8/1/23.

Hands-on Support: Our support team will be at your service to discuss your needs and help you select the most suitable plan when the time comes for you to transition to our updated pricing structure.

Flexibility: We understand that your company’s circumstances and requirements may vary. We pledge to be as accommodating as possible to ensure a seamless transition that suits your needs.

As pricing is core to your experience using Stytch, we would love to hear your feedback. If you have suggestions or concerns, please reach out to our customer support team at support@stytch.com or send us a message in our #stytch-feedback channel in the Stytch community slack. 

Thank you for your continued trust in Stytch. We look forward to providing you with exceptional products and services that help power your growth.

---


# Make a memorable first impression with messaging from Enveloop + Stytch
Source: https://stytch.com/blog/enveloop-stytch/

Learn how to create beautiful, customer emails that increase engagement and boost conversion by integrating with Enveloop and Stytch.

Enveloop understands that it's not enough to have a great app – you need stellar user communications too. That's why they've created an API-first, developer-focused message builder that helps engineers create user messages as elegant as their tech. But as we know at Stytch, user communications – especially emails – can do so much more than just send copy. They can log you in, passwordlessly and seamlessly.



In a new blogpost, Enveloop walks you through how to combine their sharp, easy-to-use messaging platform with Stytch's Email Magic Links, all for a smoother user experience and higher conversion. Check out the blog today!

About Enveloop

Enveloop is a developer-focused message builder and API that makes it easy to design & send beautiful emails and texts from your app using one simple implementation. And you don’t have to be a designer — we’re focused on making developers look awesome. Read more about Enveloop on their website, docs, or create an account to get started today.

---


# Build a no-code signup & onboarding flow with Feathery + Stytch
Source: https://stytch.com/blog/feathery-stytch/

Learn how to build a seamless signup flow using Feathery's visual editor and Stytch's intuitive auth platform, in just four simple steps.

Feathery is a powerful form builder that allows users to deploy beautiful login and signup flows powered by Stytch, without writing code. Instead of manually coding custom UI components, state management, and Stytch API integrations, Feathery’s visual editor allows you to design the flow and configure Stytch authentication actions (magic links, social logins, etc.) directly from the editor. 

Check out the full guide in Feathery’s documentation or follow along below for a quickstart tutorial.

How to build a no-code signup & onboarding flow

Sign up for Feathery and choose a signup form template to start from.



By default, your form will have test Stytch credentials enabled so you can immediately test your new signup flow. However, to use this form in your product you will need to create your own Stytch account and replace the credentials in your Feathery form settings.



(Optional) You can adjust your login flow behavior from the visual editor. 

Adjust login methods (magic link, social login, SMS code, etc.)

Edit form design

Add and remove onboarding steps



Congratulations! Your signup & onboarding flow is ready to integrate with the rest of your site. Follow our integration guide for step-by-step instructions on integrating your flow.

About Feathery

Feathery is the leading form builder for product teams, with a beautiful visual editor that allows users to launch brand-native forms and user journeys. With millions of forms served, Feathery is a scalable solution for any company. By building your signup and onboarding flow with Feathery and Stytch, you can save time and developer resources while retaining total control over the experience. Read more about Feathery on their website, docs, or sign up directly.

---


# Stytch Talks with Enzo Avigo: Building a high-performing B2B sign up flow
Source: https://stytch.com/blog/stytch-talks-with-june-analytics/

Discover top insights from our recent webinar on the value of optimized onboarding, with June Analytics CEO and co-founder Enzo Avigo.

How do onboarding processes impact the B2B user experience? And how can B2B app developers build sign up and log in flows that maximize conversion and retention rates?

These are common questions in the authentication community, and they were top of mind when Stytch’s Reed McGinley-Stempel invited Enzo Avigo to join our Stytch Talks webinar series. As the co-founder and CEO of June, a plug-and-play product analytics tool for B2B SaaS, Enzo sees first-hand the effects that frictionless onboarding flows can have on user engagement — and his professional background in product management has instilled a passion for simple SaaS solutions that are easy to use right off the bat.

Missed the live webinar and Q&A? You can access a full recording of the event over on our YouTube channel.

Optimizing your B2B onboarding can be a complicated lift, as there are unique considerations when it comes to managing organizations, preventing account deduplication, and implementing complex auth flows like single sign on (SSO) and multi-factor authentication (MFA), among other things. But there are certain steps you can take and best practices you can follow to ensure it’s worth your while.

In this post, we recap the expert tips Reed and Enzo had to share from their respective domains of auth and analytics — so you can build smooth, secure B2B sign up flows that convert and delight.



Auth is arguably the most critical investment you’ll make for your onboarding flow. It’s typically the first interaction a customer has with your app, and it has a direct impact on multiple touchpoints, from user experience and cybersecurity to product adoption.

While B2B auth methods are similar to B2C — they include passwords, 0Auth logins, email magic links, and so on — considerations differ from a data model perspective. That’s because B2C flows are focused on a single user, while B2B flows ultimately serve the organization that user belongs to. Organizations tend to have distinct security needs, often requiring advanced authentication and authorization settings. They might mandate the use of SSO or MFA, implement custom session duration limits, or have several levels of user access permissions. In short, while organizations care about the user experience, they also need to have complete control over user accounts to mitigate the risk of a data breach.





Reed had a few recommendations for building effective auth flows for the B2B market:

1. Meet organizations where they are on security.

When it comes to B2B auth, security is relative. It’s not only about the strength of your auth flows, but whether they fit the IT architecture and policies of the organizations you serve. You want to make sure you’re providing a range of factors for different verticals and levels of data sensitivity and that you have options in place if customers aren’t yet ready to go fully passwordless.

Chessly is a great example of an app doing this well on the B2C side. They offer a mix of auth factors, from secure passwords and Google OAuth to magic links and OTPs, basing their flows on customer demand to drive adoption.

2. Eliminate barriers to conversion and retention.

You want to get users to not only sign up for but return to your app. That means implementing low-friction auth flows and strategically managing sessions so users don’t hit dead ends.

For example, one common snag when B2B auth hasn’t been fully thought out is having a user try to join an organization, only to be told someone has already created an organization for that appdomain.com. They then have to identify the responsible team member and request access, resulting in needless friction and dropoffs — or they end up accidentally creating a duplicate account. Either way, it’s bad for business.

You want to get users to not only sign up for but return to your app. That means implementing low-friction auth flows and strategically managing sessions so users don’t hit dead ends. For example, one common snag when B2B auth hasn’t been fully thought out is having a user try to join an organization, only to be told someone has already created an organization for that appdomain.com. They then have to identify the responsible team member and request access, resulting in needless friction and dropoffs — or they end up accidentally creating a duplicate account. Either way, it’s bad for business.



3. Build your auth flows to scale.

If you’re still young in B2B SaaS, you’re likely selling to smaller startups and SMBs. But over time, you’ll find you’re moving upmarket for larger deals. The reality is, as an organization grows, their auth needs change. Enterprises in particular tend to have more idiosyncratic identity policies, requiring complex solutions like MFA, SSO support, SAML and OIDC, approved domains, and just-in-time provisioning.

That means, even if you’re just starting out, It’s important to anticipate the need to scale your data model to accommodate these more complex tools, so they’ll just be a one-sprint effort when the time comes. As an example of the future customer headaches you can encounter in the B2B world, here’s a likely outcome when it comes to the various org-level differences 4 different customers might have in the future:





You’ll also want to decide when to start upcharging, and which services that will involve. For Stytch, our first upsell was allowing bigger customers (that is, those willing to pay more) to remove the “powered by Stytch” watermark at the bottom of their auth flow, so they could own their UX and UI from end to end.



4. Auth can be a growth opportunity.

As you may remember from earlier Stytch Talks, auth isn’t just a box to check — it can be a differentiator. 

Getting a B2B auth flow right can deliver real results. Consider Zapier, a workflow automation app that makes it easy for users to try the platform and invite other team members to join. Zapier made mild changes to their auth flow — like maximizing optionality and implementing Google OneTap (which recognizes active login sessions), ultimately increasing conversion rates by 20%. 

The main takeaway? If you take time to think about your customer journey and reflect it in your auth flow, you can create seamless sign up and log in experiences that improve acquisition costs and lifetime value.



The role of analytics

Analytics allow you to measure the performance of your sign up flow once implemented and to use real data to identify and improve critical problem points in your onboarding process.

Whether you have no analytics program in place — or even if you have a mature analytics flow — Enzo had a few pointers to share around how tracking key metrics can help you move the needle.

1. Method matters.

When it comes to leveraging onboarding data, the first thing to think about is the method you will use — and there are three considerations to keep in mind:

Activation, or the checkpoints users need to follow to ensure they not only land on but keep using your product. These will differ depending on your product category and vision, but there’s a simple data method you can use to find them. It involves looking into your best/busiest accounts, finding patterns in the actions they take, and using those patterns to create specific milestones. With an analytics tool like June, you can even determine when (and if) users are completing milestones, so you can organize customer support, marketing, and other initiatives to ensure success.

At June, for instance, milestones include checking if and when users connect to a data source, invite teammates, and load at least 10 reports in their first week. The cherry on top is having users integrate June into their workflows, which allows them to receive value on autopilot and makes the product extra sticky in their day-to-day operations.

Qualifying signups. In B2B SaaS, not every signup is equal. You’re going to have a lot of users who go through your onboarding flow, but your goal is to identify the relevant signups and learn from them. There are three important insights you can glean: 

Where users are coming from, whether you’re capturing the source of the signup through a UTM or posting a survey that asks users where they heard about your app. It’s important to figure out how GTM channels are performing, so you can allocate resources accordingly.

User segmentation metrics, including job roles and functions, levels of product expertise, or main goal(s), so you can build ideal customer profiles (ICPs) and build your onboarding, sales, and customer success processes around real data

Overall onboarding success, including common problem points where users are likely to drop off, so you can take actionable steps to improve them

Moving beyond conversions. When users first visit your site, they’re an anonymous number. You don’t know much about them, other than they’ve agreed to your cookie policy. But then they start to navigate your product, complete your onboarding flow, and provide you with additional information.

Analytics can help you reconcile the anonymous user data with their later, identified data by ensuring you have a cross-functional setup between your website and your app. The point is, if you look beyond conversion metrics and can connect earlier touchpoints to later behaviors, you can optimize your onboarding flows to match the actual journeys your users take.



2. Onboarding flows aren’t set in stone.

It’s important to always be iterating on your onboarding experiences to improve their performance. 

For example, at one point, June used a self-serve, forced-assist model, where users could sign up and at some point would be offered an account lease so they would take a call. They found that many users were taking calls, improving their activation, but many less-motivated users were instantly turned off. Over time, June shifted to branched onboarding, where tech-proficient users can self-serve, while others can invite someone for additional support.



3. Track user actions minimally and strategically.

You can visualize a user’s onboarding journey with a funnel view by tracking the linear steps they take — but track less, rather than more. If you track too many aspects of your product, you’ll quickly lose the crucial context around a user’s actions. 

One suggestion is to track and compare only the first and last steps of your onboarding process. You can then assess how it’s performing by talking to other startup founders, product managers, and investors to gain a frame of reference. You can also use the user segmentation stats (outlined above) to strike an ideal balance for user stickiness. For example, you don’t want users signing up too quickly, not understanding your core value propositions, and ultimately dropping off.

4. Tracking analytics are simpler than they seem.

If you’re unfamiliar with tracking, there a few main concepts you can latch onto to get started:

The identify call is how you capture personal data when users first sign up for your product and initiate your onboarding. From a technical standpoint, it’s a couple of lines of code that you insert in your sign up flow, including any data points you think are relevant — like email address or job title.

The track event is the equivalent of a tag in Google Analytics. Basically, it’s a line of code that records if and when a user takes a specific action in your product — like clicking a certain button.

Web to product analytics reconcile data on how and when users traveled from your site to your product. Most tracking tools have well-crafted documentation in place to help you through this.

Finally, it’s important to balance your desire for information against your users’ desire for low-friction flows. There’s a limit on how much you can ask at onboarding, and a good rule of thumb is to keep it to 2 screens and 2-3 questions — especially if you can capture this data in other ways. Also, make sure you’re providing a backdoor for users to skip questions if they wish, so they’re not just entering random answers (and skewing your data) to move forward. 

The key takeaway here? First-party data can yield some surprising and fruitful results — and help you enhance your sign up and onboarding flows for greater conversions and engagement. 

For example, June found that adding sharing options to the beginning of an onboarding flow, when users are still very excited about a new product, led to around a 15% uptick in user invites and an overall stickier organizational relationship. 

Ultimately, data means knowledge, and knowledge means power over your UX, so you can build secure and frictionless flows that sustain and grow your business.

Want to learn more about optimizing your B2B SaaS sign up flow?

You can contact our panelists by emailing Reed at reed@stytch.com or reaching out to Enzo via LinkedIn. You can also watch a full recording of the webinar on YouTube — including a lively Q&A that addresses “aha moments” in onboarding, the build-versus-buy auth debate, and how to prioritize (and eventually monetize) the features your users want. 

If you’re interested in learning other B2B SaaS best practices, check out our larger B2B Auth School series.

---


# An engineer's guide to mobile biometrics: event- vs result-based
Source: https://stytch.com/blog/biometrics-event-vs-result-based/

An engineer's deep dive into mobile biometrics, part two: looking at the implications of event- vs result-based architecture.

At Stytch, we uncovered a variety of interesting challenges and oft-overlooked choices when building our mobile biometrics product. Each problem required us to think deeply about security implications, architecture, and mobile development patterns.

We discovered, unsurprisingly, that when it comes to mobile biometrics, the devil really is in the details.

This is the second post of a three-part series on mobile biometric authentication. We’ll share what we learned and experienced throughout the development process. This content is intended for engineers or folks interested in diving deeper into mobile biometrics implementation.

In this post, we’ll cover different types of mobile biometric architectures and the significant security implications that come with them.

Part one | An engineer's guide to mobile biometrics: step-by-step
Part two | An engineer's guide to mobile biometrics: event- vs result-based
Part three | An engineer's guide to mobile biometrics: Android Keystore pitfalls and best practices

Table of contents

What is the application sandbox
Event-based vs. result-based architecture
Why event-based architecture is less secure
Security implications and tradeoffs
Security without the hassle

What is the application sandbox

For local storage, most mobile applications today rely on the application sandbox. The application sandbox is a per-app, isolated system environment that separates and protects each app's filesystem, manages access to system resources, etc. It allows mobile apps to store information between app lifecycles (aka between killing an app and starting it again, or between phone reboots).

This data, in an ideal world, is only accessible via that application, and allows the app to maintain state across lifecycles. Because access to the data is scoped exclusively to an application, apps should be able to store sensitive data in the application sandbox in order to persist user sessions, and perform other sensitive actions that improve user experience.



Read about the app sandbox for iOS and Android

Why does the application sandbox matter for biometrics? It matters because nearly every implementation of native biometrics in a mobile application is going to rely on local storage to some degree in order to store and access credentials to authenticate. The requirement for local storage plays a crucial part in assessing the security of mobile biometric architectures.

Event-based vs. result-based architecture

While there are many nuances to how a developer can implement a biometric authentication system, there is one important decision to be made from a binary set of options: will the architecture be event-based or result-based?

Event-based biometrics

Event-based biometric authentication is an if-else gate that depends on whether or not the user can pass an agnostic biometric prompt. The application raises a biometric challenge, and after a “success” response, authenticates the user using some data (such as a long lived session token or even username/password) stored locally in the application.



Result-based biometrics

Result-based biometric authentication relies on hardware-backed biometric APIs to generate cryptographic keys that are only accessible via biometric authentication. These keys are not only stored in the application sandbox, but also gated behind a biometric challenge the operating system enforces. The application must pass a biometric challenge in order to gain access to the cryptographic keys. The application can then authenticate the user in a number of ways:

Use the unlocked key to decrypt and send locally stored credentials (such as a long lived session token or username/password) to the application’s backend.

Use the key to sign a cryptographic challenge generated by a pre-registered public key, which is derived from the biometrically-protected secret key on the device (similar to a WebAuthn flow).

Either way, user authentication within the application depends on access to the cryptographic key stored on-device that is only accessible via biometric authentication.



Result-based biometrics open source code in Stytch’s Android SDK


Why event-based architecture is less secure

Event-based biometric authentication is less secure primarily due to its returning a boolean value. By acting as a simple pass or fail gate, the implementation logic creates two vulnerabilities:

It can be spoofed and bypassed by injecting the “success” code or by changing the return value.

It stores sensitive information somewhere in local storage insecurely without proper encryption: whether that is a long-lived session token, user credentials, or even a secret key used for cryptographic data signing.

Result-based biometric authentication, on the other hand, is inherently encrypted. In order to breach it, a much more sophisticated attack is required – for example, injecting into the app right after the cryptographic key has been decrypted into application memory – as opposed to simply reading from the application’s local storage like with event-based architecture.





Security implications and tradeoffs

Are the security vulnerabilities exposed by event-based biometric flows critical vulnerabilities for any app? Only you can decide what security requirements and risks are acceptable for your application. Let’s further dissect and weigh the tradeoffs and pros and cons between result-based and event-based architecture.



MASVS L1 and L2 security levels

If a biometrics implementation is event-based, it means that some kind of sensitive data is being stored insecurely on the device. However, that data is theoretically still exclusively scoped to a single application because of the application sandbox. So, in what scenarios does event-based architecture truly result in a security vulnerability? This includes but is not limited to attacks such as:

Data extraction via forensics software

Data extraction via iTunes or adb backup files

Code instrumentation tools like Frida that are used to manually trigger the “success” flow

A bad actor gains root access to the device

The Open Worldwide Application Security Project (OWASP) defines multiple layers of security in the Mobile Application Security Verification Standard (MASVS).

L1 (Standard Security) is recommended for all mobile applications.

L2 (Defense in depth) is recommended for industries like healthcare, finance, and other applications that have access to user’s sensitive data.

R (Resiliency Against Reverse Engineering and Tampering) is for institutions that need cutting-edge state-of-the-art security like banking and government agencies.



OWASP MASVS verification levels (source)

Event-based biometric architecture does meet L1 standards, as it only exposes sensitive data in the event of a second layer vulnerability – so event-based architecture itself does not pose a security vulnerability. But, only a result-based biometrics flow would be considered secure enough for mobile applications aiming to meet MASVS L2 security requirements – which is non-negotiable if your application handles sensitive user information.

Adding new biometric factors

Do you want to allow biometric factors added to the device after the initial biometric factor (either face or thumbprint) was enabled in-app to have access? With event-based architecture you can’t control this – you must allow all biometric factors registered with the device to have access, or none. With result-based architecture, you can decide whether or not future biometric factors added to the device can be used to authenticate in your application.

Implementation

Another element, ever-present in all engineering decisions, is ease of implementation. This is where event-based has the edge. There are a plethora of event-based biometric authentication libraries publicly available, and fewer complexities to consider when implementing. Result-based architecture on the other hand requires in-depth knowledge of iOS and Android mobile architecture, data encryption/decryption, and native biometric APIs to implement, and the solution is inherently more complex.

Security without the hassle

At Stytch, our customers trust us with their authentication and expect intuitive, frictionless application interfaces.

Our internal mobile biometric solution is result-based, so developers can be sure that their application and users are receiving a higher degree of security. On top of that, implementing biometric authentication for your application is as simple as accessing a handful of methods exposed by Stytch’s mobile SDKs. Our customers get the sophisticated security of result-based architecture, but with the ease of implementation afforded by our dev kits.

Next up in the series, we’ll walk you through building biometric authentication within the Android operating system. With such a large and diverse ecosystem, you need to consider all the pitfalls and gotchas in order to support a secure and stable mobile biometric implementation.

Not ready to build mobile biometrcs from the ground up? Try Stytch’s mobile SDKs for iOS, Android, or ReactNative, and get started with mobile biometrics with just a few lines of code.

Check out our career page if solving problems and reading topics like this interest you!

---


# An engineer's guide to mobile biometrics: step-by-step
Source: https://stytch.com/blog/biometrics-step-by-step/

An engineer's deep dive into mobile biometrics: how they work, how to implement them, and key decisions and pitfalls along the way.

In 2013 Apple introduced TouchID, marking the first integration of biometric authentication into a major commercial product. Since then, biometric technology has rapidly accelerated.

As of 2022, 80% of smartphones now have biometrics enabled. Today, biometric technology is the de facto standard for mobile authentication. At Stytch, we uncovered a variety of interesting challenges and oft-overlooked choices when building our mobile biometrics product. Each problem required us to think deeply about security implications, architecture, and mobile development patterns. 

This is the first post of a three-part series on mobile biometric authentication. We’ll share what we learned and experienced throughout our development process. This content is intended for engineers or folks interested in diving deeper into mobile biometrics implementation.

In this post, we’ll cover how mobile biometric authentication works end-to-end, how to build it with code examples, and what you need to consider during development.

Part one | An engineer's guide to mobile biometrics: step-by-step
Part two | An engineer's guide to mobile biometrics: event- vs. result-based
Part three | An engineer's guide to mobile biometrics: Android Keystore pitfalls and best practices

Table of contents

What are mobile biometrics
Why use mobile biometrics
How mobile biometrics work as an auth factor
How to build mobile biometric auth with example code
What else you need to know
A great authentication choice

What are mobile biometrics?

In the field of authentication, we generally talk about auth factors as breaking down into three categories:

Something-you-know (SYK)

Something-you-have (SYH)

Something-you-are (SYA)



Historically, digital authentication has relied heavily on something-you-know in the form of passwords and PINs. More recently, something-you-have has also become a common tool via the introduction of devices like YubiKeys and auth methods like TOTP.

Though biometrics have existed in some form for a number of years now — think fingerprint readers, iris scanning tools, DNA testing — these “something-you-are” technologies were predominantly an expensive on-premise tool used for the highest levels of security or the futuristic props of sci-fi movies. But with the advent of smartphones, biometrics have become widely accessible to everyday technology users.



A biometric fingerprint scan is used to get into one’s home in Total Recall (1990), a science fiction film

If you want a comprehensive history and high-level overview of biometrics, also check out our All about biometrics post.

Why use mobile biometrics?

Biometrics are generally an ideal authentication tool for both companies and their users: they are fast, easy to use, and are highly resistant to attacks from bad actors. Users love the speed and ease of use as they allow them to do what they want quickly (vs. spending extra time authenticating) and without trying to remember the complex password they were forced to enter when signing up. Businesses, by the same token, want their users to spend time in their applications utilizing or purchasing their products and want to avoid the conversion issues associated with many other authentication factors.

Both users and businesses appreciate the higher levels of security associated with biometrics. Not only are biometrics great in the ways listed above, they are also highly useful because users tend to have their smartphone (a portable biometric reader) everywhere they go.



That said, as the general populace has used biometrics more often, minor inconveniences have become more obvious — namely the fact that, due to the nature of how this information is stored (more on this later), biometrics are limited to the specific device on which they’ve been registered.

If a user switches from their iPhone to an unregistered device like their iPad or to their Macbook, they will have to authenticate through other means like username/password (yuck) and re-register biometrics on that device. In addition to its benefits, an engineer must account for all the pitfalls and inconveniences when implementing mobile biometrics for primary authentication.

A note: passkeys provide the benefits of biometrics while circumventing the historic device-specific limitations of mobile biometrics, and as a result are gaining traction.

How mobile biometrics work as an auth factor

Biometrics on mobile devices work by locally storing a user’s biometric data, like a fingerprint or face scan. This is stored and managed by the operating system, and your biometric data never actually leaves the device. Because biometric data is never transferred over the wire, users needn’t be concerned about a man-in-the-middle attack wherein a bad actor could steal their biometric data and later use that to authenticate as that user. The operating system uses these scans to confirm “device ownership” at the time of need via a biometric prompt where the user’s face/finger is compared to the stored value. The system can use the result of this biometric check in one of two ways:

To return a verdict of pass or fail, acting like a gatekeeper.

To return some form of associated data like a credential or cryptographic key.

This choice has major security architecture implications (which we will cover in depth in the next article of this series). In many cases, you’ll want to go with the second route of storing data behind the biometrics prompt (which is the route we’ve chosen here at Stytch), because it strengthens security by requiring additional user interaction in order to use the associated data. After making a decision, you must also determine what kind of data you want the system to store behind the prompt. Your options are generally between:

Storing credentials themselves (username/password), or

Storing an asymmetric key pair so the device can perform public key authentication with the server (challenge/signature).

At Stytch, since we are an auth platform that offers customers myriad authentication options, we can’t guarantee that a user will consistently have credentials like a username and password. Because of this, we chose instead to provide the ability to register a public key for a given user and utilize public key authentication as the backing mechanism to power our biometrics product. In practice, the full end-to-end mobile biometric authentication flow looks something like this:





How to build mobile biometric authentication with example code

To implement biometric authentication on iOS, we can walk through the following example code step-by-step:

The first thing you’ll need to do when you initiate authentication is retrieve the data stored with your key, in this case by calling 'keychainClient.get(privateKeyRegistration)'. In this example we’ve stored a single private key for biometric authentication behind a `.deviceOwnerWithBiometrics` access policy. This forces the system to challenge the user with a biometric prompt prior to returning the associated data.

After we’ve retrieved the data, which is an array of bytes representing the private key, we can use that to derive the public key. 'cryptoClient.publicKeyForPrivateKey(privatekey)'.

We can then send the public key to our server to allow the backend to look up the user associated with the public key and return a challenge for the client to sign.

Upon receiving the challenge, we can sign it with the private key, 'cryptoClient.signChallengeWithPrivateKey(startResponse.challenge, privateKey)', and return the signature to our servers in a final `authenticate` call.

Once the server can verify the signature is valid, it can issue a session for that user and return the session information in the response.



What else you need to know

Once you understand the overall mobile biometric auth flow, you’re ready to get into the weeds. To actually implement mobile biometrics, you’ll also need to factor in a few important decisions during development.

1. Choosing a signing algorithm

When you’ve settled in on using public-key cryptography, you’ll notice there are many algorithms and curves to choose from, leaving you with yet another difficult choice.

Generally the industry is moving away from RSA and DSA and toward misuse resistant and deterministic elliptical-curve-based signature schemes. These are not areas where you want to roll your own solution, so you should leverage hardened libraries provided by the system or by an industry supported vendor and maintainer.



RFC sources for each signature family: RFC 4056, RFC 6979, and RFC 8709

For this reason, Stytch chose Ed25519 signatures, from the family of EdDSA signature schemes. We utilize the system-provided CryptoKit library on iOS andindustry-trusted BouncyCastle library on Android.

2. Falling back to the device PIN code

As was mentioned above, the operating system treats biometrics as a means of determining device ownership. There is, however, an alternative way to confirm device ownership — namely falling back to the device PIN code.

For the purposes of biometric authentication, we must choose whether we believe the PIN code is sufficient to access the data secured by biometrics. To explore this further, let’s think about certain scenarios a user might encounter:

Imagine a user is on a roadtrip with friends and their phone is playing music for the car. The device owner may choose to share their PIN with their friend to allow them to adjust the music. They are likely OK with providing access to their music player; however, there’s a good chance they’d frown if that same PIN gave their friend full access to their banking app.

You can imagine a similar situation with a parent providing their young child with the PIN to their phone — similarly, they would likely want to restrict their child from being able to make expensive purchases with their PIN.

At Stytch, we’ve chosen to default to proof of device ownership with biometrics, with the ability to override this choice if it’s safe for their application to do so. We want our customers to make the safe choice by default and allow overriding that default only if they’ve explicitly decided that falling back to PIN is a safe choice for their data and their application.



As general guidance here, access to financial, medical, and other sensitive info should almost certainly stick with the more secure default choice. In cases where an application is storing less sensitive data, and a streamlined fallback like device PIN is desirable for ease of use or conversion reasons, that may be a case where overriding the default is a good option to consider.



3. Local storage and operating systems

Whether you are storing credentials or asymmetric key pairs, the data stored in these transactions are sensitive and need to be persisted in some form of secure storage. The local storage options and details will be specific to the operating system your application is running on (or the framework you’re using as a go between); namely, iOS and Android, or React Native.

iOS

On iOS, this choice is straightforward: the Keychain is the tried and true method of securely storing small bits of data on behalf of the user. Not limited to just passwords, the Keychain can not only save information a user explicitly cares about, such as credit card information, but also items the user needs but may not be aware of, like the cryptographic keys we need to enable secure communication for our mobile biometric authentication flow.



ANDROID

On Android, however, the choice is a bit more complicated. The Android landscape is much more fragmented since there are multiple options for storage (flat file stored in sandbox, preferences, or database). Some secure guarantees may not hold up on certain devices or versions of Android. A good option that works safely and consistently (and the option we’ve chosen here at Stytch) is to use SharedPreferences in conjunction with the Keystore. You can generate and use a key from the Keystore to encrypt the data stored in shared preferences, and can manage access to encryption Keystore keys to ensure they are secured via biometrics.



REACT NATIVE

React Native, given it covers both iOS and Android, has to consider both of the scenarios described above. You may be able to utilize existing libraries which abstract these concerns, though if these don’t meet your needs, you can also create your own “native module” and handle platform-specific code in a more custom manner.

At Stytch, we decided to go down this path and to leverage slightly-modified versions of our iOS and Android solutions in a custom native module.

A great authentication choice

When it’s all said and done, it’s difficult to come up with an authentication flow use case where biometrics would not be a good choice for your application. It’s convenient, easy to use, and is both safe and trusted by consumers.

Next up in the series, we’ll break down the two different mobile biometric architectures that use the application sandbox. This choice of architecture, which we alluded to earlier in the How mobile biometrics work as an auth factor section, has a major security impact on mobile biometrics.

Not ready to build mobile biometrics from the ground up? Try Stytch’s mobile SDKs for iOS, Android, or React Native, and get started with mobile biometrics with just a few lines of code.

Check out our career page if solving problems and reading topics like this interest you!

---


# Introducing B2B Authentication
Source: https://stytch.com/blog/introducing-b2b-authentication/

Introducing B2B Authentication

Today, Stytch is excited to introduce our authentication suite for business-to-business (B2B) companies, complete with SSO (both OIDC and SAML), built-in organization-based tenancy, and platform staples our business-to consumer (B2C) platform is known for like breach-resistant passwords and passwordless auth options like email magic links, SMS one-time passcodes, and OAuth.

The importance of authentication for B2B applications

Authentication is a critical requirement for B2B applications to successfully grow their customer base. The authentication and authorization requirements that your business customers need only grow in number and complexity as you move upmarket and sell to larger customers. Enterprise customers require more advanced controls and capabilities to manage provisioning of user accounts, control user access and permissions, and mitigate any security risks tied to their users’ accounts. 

When a business has a need for specific authentication features – whether it’s SSO, controlling how members can join an Organization, or something else – these are hard requirements that can become dealbreakers, especially for enterprise customers. B2B applications need to be able to support these authentication requirements in order to win these customers and scale successfully.

Current challenges with B2B authentication

When compared to B2C authentication, B2B is much more complex. It requires:

More complicated data models that are built around organizations and members instead of users

Handling provisioning/access/permissions for users across different organizations

Providing unique authentication settings for each B2B customer while still ensuring security at scale

These complexities mean that B2B auth is much more difficult and time-consuming to build in-house: to achieve even the basic requirements of B2B authentication, in-house developers need to build a multi-tenancy data model from the ground up, in addition to key infrastructure and features like SSO, organization auth settings, invitation management, and more. 

At the same time, existing solutions fall short: they lack the foundational data structures necessary to build scalable B2B authentication. In fact, until now, no B2B authentication solution on the market has offered organization tenancy (also known as “multitenancy”) built into their data architecture. Instead, they offer what is fundamentally a B2C architecture with a few B2B elements tacked on. 

Why is this such a big deal? 

By failing to build this structure into their B2B product from the beginning, the onus of building and maintaining this incredibly complex architecture falls to your eng team. 

Not only does this tax precious developer resources, it also often results in under-informed decisions that can have big downstream effects when new edge cases inevitably arise as your business grows and your authentication needs evolve. How companies handle things like org and member definition, onboarding and provisioning, or the relationship between email domains, Identity Providers, and organizations can each become big obstacles for your business. They ultimately require significant rebuilds as B2B companies take on bigger, more complex customers, each of whom will likely expect unique specifications / settings for their organization. Without an organization-first data model built in to your authentication architecture, these customizations will require custom code and constant painful revisions to your backend systems. 

Providers like Auth0 will tell you their solution simplifies the developer experience, but that simplicity is only skin-deep. Without an organization-first data model at the core of their product, they ultimately create pain points both for developers and end users that cost more time and money to resolve. At Stytch, we decided to do things differently.



The only organization-first authentication solution

In light of the gap in the current B2B authentication market, Stytch decided to build an organization-first authentication solution, with organization-based tenancy built directly into our data models. 

What this means is that our architecture is built with a membership model in mind – a critical requirement for building scalable, flexible B2B authentication. In contrast with a B2C data model, which is built entirely around the concept of an individual user, an org-first data model is built on the presumption that all users are members of an organization. Unlike a B2C app in which a user is the sole owner of the resources in their account, members of organizations must establish and verify not just their identity, but their membership in the organization. Apps must also orchestrate how members are invited to organizations, and how their permissions and accessible resources within that organization are governed. In case it’s not evident in the description, that’s a very different and more difficult data model to build, and it is fundamental to B2B authentication. 

What’s more, as many B2B companies find as they scale, their enterprise customers expect to be able to set custom member invitations, provisioning, and authentication factors that are unique to their app. Without an org-first data model, it’s impossible to offer these customizations without ripping out your data model and building it from scratch. Authentication capabilities that organizations often want to offer and customize include:

Organization creation & onboarding

Approved domains and login methods (including enterprise auth factors like passwords, OAuth, etc.)

Setting up single sign on connections (both OIDC & SAML)

Member creation settings (invitations, just-in-time provisioning, etc.)

Session length

Stytch’s org-first architecture makes all of these settings easy to customize and set by organization. This is incredibly important for companies that want to scale (and really, what company doesn’t?), because enterprise companies have more idiosyncratic, tailored demands of their vendors, especially when it comes to things like auth and SSO.

Benefits of the org-first approach

Without an org-first approach, developers who buy B2B auth from current market solutions like Auth0 still have to build the features described above themselves. With Stytch’s solution, they come out of the box: you simply have to integrate our solution and set up how your customers will leverage those features. Stytch enables all the key requirements for B2B authentication – organization management, invites, approved domains and logins, SSO, etc. – right from the start. No superfluous assembly required. 

By virtue of all the core B2B features an org-first architecture enables, we believe our approach to B2B auth uniquely delivers three outsized benefits to our customers:

It saves valuable developer resources: An org-first data model not only saves your developers time in the short-term, it saves them headaches in the long run too. An org-first model can handle all the various auth requirements a B2B company may encounter with their customers. And as your business grows to take on more enterprise clients, the various edge cases and unique auth demands will only proliferate. Stytch’s data model is ready for any of these scenarios, making them incredibly easy and time-efficient to set-up.

It offers more fine-grained customization and features: B2B auth is not a one-size-fits-all solution. Depending on their size, industry, end users, and any regulations they may be subject to, B2B customers have requirements for the end user experience and security they want to provide for their customers. An organization-first architecture allows your platform to build and offer enterprise-level customization for authentication so each organization can have fine-grained control over their authentication experience.



It empowers developers to provide a better end user experience: By simplifying the work developers need to do on the backend, Stytch makes it easy to build a good B2B auth experience. With features like invitations, organization discovery,organization switching, and account deduplication built into our platform, our B2B solution avoids all the pitfalls and provides the key capabilities that help you deliver a delightful and effortless end user experience.



In sum, Stytch’s org-first solution offers a vastly different product and developer experience than anything else on the market: an unparalleled depth and range of auth capabilities out of the box, greater flexibility so you can offer a tailor-made auth solution for your customers, and the ability to customize the exact experience you want for their end users. On top of all of this, our customers get the same great service we offer with our B2C product.

Start building for free

Interested in seeing how Stytch can accelerate your B2B product? Check out our docs and start building for free today. 

And if you have any questions, feel free to contact us at support@stytch.com or schedule a chat with a member of our team.

---


# Stytch events with Orb: securing and pricing AI products
Source: https://stytch.com/blog/stytch-orb-securing-and-pricing-ai-products/

Stytch got together with Orb to discuss the future of AI – how to build great products in this space, and how to protect them from fraud.

As AI takes off, there’s a lot to be excited about. Incorporating AI is already allowing companies of all sizes to delight users, make their products stickier, and generate new revenue streams. 

However, as companies start to productionize AI, they also need to ensure their products are priced in a way that still allows for viable unit economics, and are secure against a quickly evolving threat landscape. 

In our recent fireside chat, Stytch co-founders Julianna Lamb and Reed McGinley Stempel sat down with Alvaro Morales, the CEO and co-founder of usage-based billing company Orb, to chat about some of the pricing and security challenges that companies need to consider when incorporating AI into their products. 

We’ve highlighted a few of our favorite takeaways from the discussion.

1. In the long run, you’ll need pricing that scales with your costs.

"If you look at OpenAI, they charge ~$0.0004 per thousand API tokens, whereas Notion adds an $8 per member per month add-on to leverage all of their AI capabilities. In the long run, OpenAI’s pricing is better positioned to account for an increase of costs that come with scale, whereas Notion’s flat fee could leave them vulnerable to decreasing margins over time."

If we look at typical industry benchmarks, most application-level software companies are expected to have around an 80 to 85% gross margin profile. Most infrastructure-level companies hover at around 70% or above margins.



This makes sense if you're an application-level software company that can take advantage of capabilities like multi-tenancy: the marginal cost of delivering software is generally quite low. But AI has a rather unique cost structure that adds a few dimensions to cost:

Models: First, there’s a cost that comes from the foundational models that you're leveraging to power these capabilities. This could be calls to the API where you're being charged on a token basis, or it could be the hosting cost of deploying an open source model.

Training: AI companies also need to consider the cost of training and fine tuning their models. If you’re taking a powerful foundation model and adapting and tailoring it to your individual use case, that requires some significant compute costs.

Operations: This is the DevOps analog in the AI space – something you might call “ML Ops” or “AI Ops.” AI companies need these operations to deliver an enterprise-grade, production-ready service over time, but it certainly doesn’t come free.



Given these three cost factors, as an AI feature is adopted more and more, it will hurt a company’s margins if their pricing doesn’t adjust with scale.

2. In the short term, don’t be afraid to experiment with pricing.

There can be a lot of anxiety around how to approach pricing in the new AI landscape. But we think a lot of this anxiety can be reduced if companies approach this initial phase with an attitude of experimentation, learning, and iteration. 

"It's a common pitfall in software that companies delay pricing changes for a long time. This often leads to a massive, painful change management effort to raise prices to catch up with the value being delivered. Instead, I believe it's more effective to make pricing an iterative and ongoing exercise. As you add new AI capabilities and the value of your product changes rapidly, you might want to start experimenting more."

Alvaro Morales Co-founder and CEO, Orb

If we look back to the Notion example, it makes sense that they’ve started with a relatively simple pricing model – the more interesting question is how they’ll evolve it. In this initial phase, they can learn a lot about the value they can derive from adding new AI capabilities. Based on customer engagement, they can examine how AI features impact customer retention, churn, and lifetime value, and experiment with the improvements and features that will make their AI features stickier. 

To get to the heart of these questions, it makes a lot of sense to start with pricing models that get customers on board as quickly as possible. The first six months to a year when companies introduce new AI features is not necessarily the best time to optimize for margins. Instead, it’s the time to study and experiment: as companies learn, they should not shy away from experimenting with their pricing alongside experiments in the product.

3. Be aware of new attack surfaces introduced by adding AI features.



Introducing AI definitely introduces new potential revenue streams, but it also adds new attack surfaces to your products. 

One major risk is the threat of reverse engineering. For example, when working with customers like You.com and Hex, Stytch discovered the surprising economic incentives to reverse engineer apps that incorporate AI functionality. 

One example of this in action is GPT for Free, an open-source project on GitHub. It has gained over 30,000 stars, and it focuses on reverse engineering sites that offer AI capabilities.



The motivation behind this attack is to fool the site into thinking that a bot is a real human user, thereby exploiting the valuable AI feature without paying for it. This is particularly relevant because serving AI features is expensive but relatively fungible, allowing attackers to monetize API endpoints and get free API usage. 

However, the most interesting attacks are carried out on sites not listed by GPT for Free, because they’re performed by individuals who haven't open-sourced their methods. For instance, one of Stytch’s clients recently discovered that 20% of their traffic, consisting of millions of fingerprints per day, was from headless browser automation. 

Even bot mitigation tactics like CAPTCHAs are easy to bypass with tools like anti-captcha.com. For attackers, it’s worth it to pay a small fee to get past a CAPTCHA, because they can extract significant value from reverse engineering AI APIs. 

This threat is quite technical, but often overlooked when organizations focus on product features and use cases, neglecting the adverse impacts and security risks associated with incorporating AI resources. Thankfully, there are tools that can help, like Device Fingerprinting.

4. Consider future security considerations around autonomous AI.



Another trend to watch is the rise of autonomous AI agents, like the project AutoGPT. Unlike with Chat GPT, where you're always in the loop, AutoGPT allows the AI to prompt itself. This means that, given a broad directive, the AI agent can carry out the tasks independently. 

This new kind of AI potentially overhauls everything we’ve come to take for granted about user/computer interactions: what things should an AI agent be allowed to do on our behalf? How does that change depending on the service? Sure, you might let an AI agent book the best flights for you based on your schedule, but would you let it, say, refinance your mortgage? More importantly, how do those permissions get set and managed? 

Today, we have something called role-based access controls, or RBAC, that designates permissions and actions by user. But if every user is now comprised of one human being and one or several AI agents, that introduces new constraints these human-based systems need to account for. 

Although we're not seeing security pitfalls from this yet (the technology is still very new), we're intrigued by the underlying trend. It introduces some interesting ideas around authorization and fraud detection that will only become more prevalent as the technology catches on.



Interested in learning more?

If you’d like to dive deeper into AI, check out Stytch’s piece in TechCrunch about securing AI applications. You can also follow Stytch and Orb on Twitter to get a heads up about future events. 

About Stytch: Stytch is a developer-first authentication platform with solutions for B2C and B2B, including breach-resistant passwords, passwordless auth flows, MFA, SSO with SAML and OIDC, and fraud and risk protection. Learn more at stytch.com. 

About Orb: Orb is a modern pricing platform that helps companies automate billing for seats, usage-based consumption, and everything in between. Learn more at withorb.com. 

Our thanks to ChatGPT for drafting the initial version of this blog post from an AI-generated transcript.

---


# An engineer’s guide to mobile biometrics: Android Keystore pitfalls and best practices
Source: https://stytch.com/blog/android-keystore-pitfalls-and-best-practices/

In this article, we’ll show you the best practices and pitfalls when implementing mobile biometrics in the Android ecoystem.

At Stytch, we uncovered a variety of interesting challenges and oft-overlooked choices when building our mobile biometrics product. Each problem required us to think deeply about security implications, architecture, and mobile development patterns. 

We discovered, unsurprisingly, that when it comes to mobile biometrics, the devil really is in the details. This is the third and final post of a three-part series on mobile biometric authentication. 

This content is intended for engineers or folks interested in diving deeper into mobile biometrics implementation. 

In this post, we’ll build on the result-based architecture concepts of the last post and look specifically at some of the idiosyncrasies of the Android ecosystem, and how to prepare for and build around those. 

Part one | An engineer's guide to mobile biometrics: step-by-step
Part two | An engineer's guide to mobile biometrics: event- vs result-based
Part three | An engineer's guide to mobile biometrics: Android Keystore pitfalls and best practices

Table of contents

Insecure mobile biometrics in the wild
Context on the Android ecosystem
Recap: result-based architecture and key configuration
The CryptoObject
Tink, BouncyCastle, and the Keystore
Android Keystore support
Empower the developer
Concluding thoughts

Insecure mobile biometrics in the wild

Given how mature the Android ecosystem is, you might assume there would be a well-defined and easy-to-follow path to build secure authentication for mobile applications. You might also assume that most security-focused products (like banking applications!) would be using best practices to guard against common vulnerabilities and threats. But when it comes to authentication, the only way to validate your assumptions – of what is or isn’t secure – is by testing it yourself.

As part of our research into the Android ecosystem when building our mobile biometrics product, we tested biometric authentication flows for dozens of popular mobile applications. Our testing focused on applications with large usership and a variety of use cases, including healthcare, social media, sportsbooks, insurance, trading, banking, and other high-security industries.

We found that 50% of the Android apps we tested failed to meet OWASP’s AUTH-2 security standards. And according to F-Secure Labs, “about 70% of the assessed [Android] applications that utilized fingerprint authentication were unlocked without even requiring a valid fingerprint.”

Context on the Android ecosystem



Android biometric stack (source)

You may still be wondering what makes Android so special as to warrant its own dedicated blog in our biometric series. The answer is – it’s fraught with pitfalls due to a complicated history.

Unlike competitors like Apple, the Android ecosystem was initially designed to grow via open, fairly unregulated access. The thought was the easier Google made it for Original Equipment Manufacturers (OEMs) – think Samsung, Motorola, LG, OnePlus, etc. – to build on the Android OS, the quicker they could capture mobile market share.

As a result, for the first decade or so of Android’s existence, what it meant to “be an Android” was a bit of a wild west. Each OEM could make significant software modifications and tweaks to suit their product line, with little oversight or regulation from Google. As a downstream effect of this open approach, whenever Google pushed a patch or over-the-air update (OTA), many OEMs couldn’t deploy them without significant adaptations and resourcing, creating a very uneven and unpredictable ecosystem with idiosyncrasies and bugs specific to each phone manufacturer.

Around Android 8, Google began to crack down on the use of Android OS, creating tighter restrictions on what could be adapted and what could not. But the reality is for any devices still on Android 2-7, quirks still often abound.

The Android Keystore

Of these Android bugs and idiosyncrasies, our team was especially focused on those that affected the Android Keystore, the system that locally stores and handles cryptographic keys. It is an essential component of a secure, effective mobile biometric authentication flow.



Android IssueTracker results for "keystore biometrics"

But in a diverse, open source Android ecosystem, devices may not support the Keystore – which subjects all applications on that device to security vulnerabilities like account takeover. It’s impossible to prove or disprove that all Android phones will work reliably with the Keystore. Unfortunately, developers must factor this severe possibility into their application’s auth logic in order to be secure. 

We’ll show you the best practices on implementing mobile biometrics in both scenarios: with and without the Android Keystore.

Recap: result-based architecture and key configuration

In the previous post we discussed the differences between what we’re calling event and result-based biometric architectures. We’ve already established that a result-based architecture is more secure than an event-based version, but there’s slightly more to it than that. When using a result-based architecture, you also need to think about:

How the key is configured.

What you're doing with that key once the biometric prompt has passed.

When configuring the secret key that you will be using to encrypt/decrypt sensitive information, you have the option of enforcing whether or not the key is authorized for use with or without user authentication. By default, the key is authorized to be used regardless of whether the user has been authenticated, but Android allows you to enable stronger behavior when configuring the KeyGenerator by setting a property called UserAuthenticationRequired.



Android Keystore docs for KeyGenerator and UserAuthenticationRequired

When UserAuthenticationRequired is set, there are some guarantees that the device makes in order to allow the key to be used:

The key can only be generated if a lock screen is configured.

At least one biometric must be enrolled (on Android 11 and greater).

The use of the key must be authorized by the user after authenticating with secure lock screen credentials such as a password/PIN/pattern or biometric.

The key will become irreversibly invalidated once the secure lock screen is disabled, or when the secure lock screen is forcibly reset, or (on Android 11 and greater) once a new biometric is enrolled or all biometrics are deleted.

It’s this step where many widely used mobile applications, mentioned at the beginning of this post, failed to implement secure mobile biometrics. Without UserAuthenticationRequired, they lack the strong security guarantees around how their secret key is used, thus exposing their user bases to account takeover via mobile biometrics. 

Once you’ve configured your key to require user authentication, it’s also important to consider how you use that key. If you’re not performing a cryptographic operation on your private data with that key, and instead are just using the presence of a CryptoObject to assume user authentication, you’re no better off than if you were using an event-based approach. Both the event-based approach and the result-based-but-not-doing-cryptography-approach are susceptible to simple attacks like these:

https://github.com/ax/android-fingerprint-bypass

https://github.com/WithSecureLabs/android-keystore-audit/blob/master/frida-scripts/fingerprint-bypass-via-exception-handling.js



The CryptoObject

But what does it mean to use the CryptoObject to encrypt your private data? Well, once you’ve securely configured your key, and it’s only accessible after passing user authentication, the CryptoObject gives you one opportunity to perform a cryptographic operation (encryption or decryption), which you should use either to encrypt your private data before persisting it to device or decrypting your previously-encrypted private data. 

For Stytch’s biometric implementation, we use a public/private keypair to sign and verify challenges provided by our backend. What this means is that a string encoded with our public key can only be decoded by our private key, and we must safely persist our private key to the device for future usage.

The CryptoObject brokers access between the stored, encrypted private key and the biometric prompt.



When registering a new biometric authentication with Stytch, we:

Generate a biometrically-secure key, as described above, in the Android Keystore.

Generate an Ed25519 keypair (using BouncyCastle).

Register the public key with our servers.

Use the private key to sign a challenge string and authenticate that with our servers.

Use the CryptoObject returned from the biometric prompt to access the biometrically-secure key, which we use our one cryptographic operation allowance to encrypt the private key.

Encrypt the key again (with Tink), and persist it to SharedPreferences.

Authenticating with biometrics follows a similar flow, but in reverse:

Use Tink to decrypt the first-pass encryption of the private key from SharedPreferences.

Use the CryptoObject returned from the biometric prompt to access the biometrically-secure key, which we use to decrypt the private key recovered in step 1.

Derive the public key from the private key.

Request a challenge from the Stytch servers.

Use the decrypted private key to sign the challenge and authenticate that with our servers.

When it comes to persisting your now-encrypted private data, you have a few options on Android: saving it to a file in internal/external storage, in a database, or to SharedPreferences (a simple key-value store). For our use, we’re simply storing an encrypted private key, so SharedPreferences makes the most sense; it avoids having to do any file and string parsing, and avoids the unnecessary overhead of a full database. 

On Android, we also encrypt all data before saving it to SharedPreferences (using Tink), so your private key is protected with two layers of encryption, using two different keys. This means that even if the SharedPreferences master key is compromised (more on that later), the Ed25519 private key is still encrypted by the biometrically-locked key. 

A high-level diagram of how our flow uses the Android Keystore and SharedPreferences looks something like this:



Tink, BouncyCastle, and the Keystore

As mentioned above, we use a library called BouncyCastle for generating Ed25519 keypairs and Tink for encrypting data in SharedPreferences.

BouncyCastle and Tink are both industry standard, open source libraries for performing cryptographic operations. They can perform similar functions, but due to a limitation in Tink around support for our chosen public/private keypair implementation (Ed25519), we chose to augment our existing Tink infrastructure with BouncyCastle specifically for our biometrics product.

Tink, which is a Google product, is a multi-language, cross-platform cryptography solution which integrates with both on-device (Android Keystore, iOS Keychain) and online (Amazon KMS, Google Cloud KMS) keystores. From the beginning of the Stytch Android SDK, we’ve used Tink to encrypt all data in SharedPreferences using an AES-256 key saved in the Android Keystore. When it came time to implement biometrics, we initially turned to our existing Tink implementation; but while Tink theoretically supports Ed25519 keypairs, that functionality is provided within a package that is not recommended for public consumption.

Enter BouncyCastle. BouncyCastle is a 20+ year strong, actively supported cryptography library available for both Java and C#, and a stripped-down version comes natively bundled on Android devices. On early Android versions (pre-4.0), this caused a namespace conflict when trying to use full-or-newer versions within application dependencies, but is no longer a problem on our supported platforms (Android 6.0+). BouncyCastle officially supports generating and interacting with Ed25519 keypairs, and given its long track record, it was a no-brainer to choose for our biometrics product.

Generating an Ed25519 keypair with BouncyCastle is easy:



Once we have this keypair, we can Base64 encode it, register the public key with our servers, encrypt the private key with a biometrically-secured key from the Android Keystore, and save it to SharedPreferences, where it is encrypted a second time by Tink. 

On authentication flows, we make one decryption pass to load the private key from SharedPreferences (using Tink), then decrypt it again using the biometrically-secured key from Android Keystore. Once we have the unencrypted private key byte array, we can derive the public key from it, like so:



Now that we have a public key and a private key, we can request the code challenge from the Stytch servers (with the public key), and sign and authenticate it (with the private key).

Android Keystore support

There is one big GOTCHA when it comes to Tink and the Android Keystore that we need to discuss: some devices may not have a functioning Keystore, and in those cases, Tink deactivates the Keystore and stores its keys in the application sandbox. From the Tink documentation:

"When Android Keystore is disabled or otherwise unavailable, keysets will be stored in cleartext. This is not as bad as it sounds because keysets remain inaccessible to any other apps running on the same device. Moreover, as of July 2020, most active Android devices support either full-disk encryption or file-based encryption, which provide strong security protection against key theft even from attackers with physical access to the device."

Tink has a self-test that it runs at runtime to determine whether or not the Keystore is “reliable”, and exposes a helper method to indicate whether or not it is using the Keystore.

In order to fully secure an encryption key behind a biometric authentication, we have to use the Android Keystore, and do so directly, regardless of whether or not Tink is using it. And it’s that key, which is always saved in the Keystore, that is used as the first-pass encryption of the private key.

Since we only use Tink for encrypting the already-encrypted private key bytes, even if the application sandbox were compromised, and the Tink master key were extracted, all an attacker would gain would be an encrypted string that cannot be decrypted unless they also were to break the Android Keystore itself. 

Empower the developer

But the Keystore being potentially unreliable is still concerning, since we need the Keystore to biometrically secure that first-pass encryption key/second-pass decryption key. 

So what do we do if the Keystore isn’t available? Empower the developer with the information to make a choice.

First and foremost, developers need to know of the security and functionality implications laid out above. To support that, we make it easy with our SDK to tell if a device passes the self-test and force developers to opt-in to using biometrics on a device without a reliable Keystore.

First off, developers can call the StytchClient.biometrics.isUsingKeystore() method to determine if the Keystore is reliable. If this returns false, the safest thing to do is disable biometric registrations for that device.

Second, when attempting a biometric registration we internally make the same check to determine Keystore reliability and, by default, reject the registration flow before doing anything with a NOT_USING_KEYSTORE error. If a developer still wants to attempt biometric registration, they must explicitly set allowFallbackToCleartext to true in the Biometrics.RegistrationParameters.

If allowFallbackToCleartext is set to true, then the methods will succeed regardless of the device’s access to the Keystore. If the parameter is set to false, then the SDK will verify that the device has a working implementation of Keystore before proceeding. If it does not, then the attempt to register or authenticate with biometrics will fail. The SDK exposes mechanisms for developers to only show biometric options if the Keystore is working, and defaults allowFallbackToCleartext to false so that developers must intentionally opt in if they are allowing this functionality.

We believe that providing options and cautious defaults empower developers to make the best decisions for their applications, while encouraging the safest practice.

Concluding thoughts on building mobile biometric authentication

Users are becoming more and more comfortable securing their accounts with biometrics and expect it in a wider variety of applications. Biometrics are a quick, trusted feature that reduces friction around authentication.

With this blog series, we hope we’ve helped you understand the many steps involved in building mobile biometrics, the implications of choosing an event- or result-based architecture, and the Android-specific considerations to take regarding key generation and persistence.

If you were to take away just four main lessons on biometrics from this series, we’d want those to be the following:

1. Biometric implementation is complex, but is a worthwhile investment for your app

From choosing an encryption algorithm, to deciding on the appropriateness of fallback authentication, to understanding the options available to you for persisting your secure data, every choice you make impacts the overall security of your biometric implementation. That said, every application will have unique choices to make based on the sensitivity of the data they handle, its value to potential hackers, and the types of user experience that matters most to your customers.

But once you understand these intricacies enough to make informed decisions, it’s difficult to come up with an authentication flow use case where biometrics would not be a good choice for your application.

2. The choice between event- vs. result-based architecture is one of the most impactful decisions you’ll make in your build

One of the most important things we’ve learned in the auth business is how to think through worst-case scenarios. So while superficially event- and result-based architectures may not seem all that different, a closer look at potential breach scenarios revealed to us that result-based was by far and away preferred, even if it took a bit more time to implement. We also felt it was our job as an auth provider to make that added security more easily attainable for our customers, which is why we’ve built it into our mobile SDKs.

3. The mobile OS ecosystem is diverse, and Android in particular includes pitfalls that require some extra vigilance and due diligence

The Android ecosystem is generally diverse and historically unregulated, so whenever building anything for this OS developers need to do some homework on legacy issues. 

For biometrics in particular, this means carefully considering your options when generating your biometrically-secure Key and the steps you take to persist your secure data to the device. Specifically, we recommend ensuring that your keys are generated with the UserAuthenticationRequired flag, and that you use that key to encrypt/decrypt your secure data. You also need to be aware that some Android devices may not have a reliable Keystore and that, in those instances, the best solution is to not allow biometric registrations at all. We’ve enabled that by default, but as always, the choice is yours.

4. When in doubt…

When it comes to building any product in auth, either in-house or like in Stytch’s case for our customers, we really stick to two basic principles:

Developer friction and user experience should always be weighed against the risk that is specific to your product. There are of course standards and general best practices one must follow, but every app has unique needs for security and UX. Take the time to evaluate your app on its own terms. 

When building for developers, always inform them when they need to make an important choice. There should be no scary default behaviors, risky edge cases or quirks they’re left to discover on their own. Build defaults for the best practice in your view, and inform them of the tradeoffs. That way, you both maximize your protection while empowering them with choice.

Our goal with this series was to offer visibility into the decisions that went into our own biometric product, whether you’re looking to build or buy. But we’re proud to have built what we’ve found is an easy, safe-by-default option for bringing biometric authentication to applications without having to worry about the nitty-gritty details explored in this blog series.

So if you’re not ready to build mobile biometrics from the ground up, try Stytch’s mobile SDKs for iOS, Android, or ReactNative, and get started with just a few lines of code.

Check out our careers page if solving problems and reading topics like this interest you!

About Latacora

A big thank you to Latacora for helping us with our research. 

Latacora bootstraps security practices for startups. Instead of wasting your time trying to hire a security person who is good at everything from Android security to AWS IAM strategies to SOC2 and apparently has the time to answer all your security questionnaires plus never gets sick or takes a day off, you hire us. We provide a crack team of professionals prepped with processes and power tools, coupling individual security capabilities with strategic program management and tactical project management.

Other awesome resources to check out:

Using BiometricPrompt with CryptoObject: how and why
How secure is your android keystore authentication
How you should secure your Android’s app biometric authentication
A closer look at the security of React Native biometric libraries
Audit: Biometric authentication should always be used with a cryptographic object
Android Biometric API: Getting Started
Android Keystore
BiometricPrompt
CipherObject
Tink
BouncyCastle

---


# The top 10 password cracking techniques – and how to outmaneuver them
Source: https://stytch.com/blog/top-10-password-cracking-techniques/

Learn about today’s most-used password cracking techniques, and the technologies that can help protect you

From brute force attacks to phishing scams, learn what to look out for and how to protect your app against today's sneakiest password attacks

We've said it before, and we'll definitely say it again: traditional passwords are the weakest link in the cybersecurity chain. In fact, 82% of all data breaches come down to avoidable human errors — like easily guessable passwords and other poor security practices that can put a user's online accounts, data, and assets at risk. The good news is that the cybercriminals behind "password cracking" attacks tend to follow predictable patterns and resort to the same methods time and again to ensnare unsuspecting users and developers. By brushing up on the most common attack vectors and learning which red flags to watch out for, you can stay one step ahead of the hackers and keep your app (and your users) safe. In this post, we cover the basics of password attacks, review ten of the most popular password cracking tools and tactics, and share expert tips to ensure they don't work on you.

What is password cracking?

Password cracking, also known as password hacking, is any type of cyber attack that involves intercepting or otherwise compromising user passwords. The ultimate goal is to "crack" (or successfully guess) the passwords that are used to protect sensitive accounts. Hackers can then use stolen credentials to breach or take over a user's account and gain access to sensitive data, confidential business records, and other valuable online assets. They may do this for material gain, for an ideological cause, or even just for fun.

How a password hack works

Password cracking can be divided into two categories: online and offline attacks. In an online password attack, a hacker attempts to enter the correct password on an app's login page, directly on the server. Online password attacks can be challenging to carry out, as they're limited by the speed of the network. They're also relatively easy to detect, due to the web noise generated by constant login requests. On the other hand, offline password attacks provide hackers with more time and flexibility. In an offline password attack, a hacker intercepts one or more password hashes — algorithms used to encrypt passwords, converting plaintext passwords into unintelligible strings of letters, numbers, and symbols, so they're harder to read and recognize when stored in a database. The hacker can then take these password hashes offline and unencrypt them using a password cracking tool.

Common password cracking techniques

There are many types of online and offline strategies cybercriminals use to crack user passwords. Ten of the most common include:

1. BRUTE FORCE ATTACK

In a brute-force password attack, a hacker tries to access a secure user account through trial and error. This typically involves systematically entering every possible combination of letters, numbers, and symbols into a password field until one works. Today, almost all brute force attacks are carried out by bots, or automated software that can be programmed to carry out repetitive, predetermined tasks. Among other actions, bots can randomly generate passwords and quickly enter them into an app or website. This eliminates a lot of the time and hassle required to mount a brute force attack, making it a much more efficient and attractive method for hackers. Simple cybersecurity measures — like account lockout systems, which block entry to certain IP addresses after a certain number of incorrect login attempts — can thwart a basic brute force attack. That's why, in recent years, hackers have developed the more sophisticated brute force methods outlined below.

2. PASSWORD SPRAYING

A password spray attack is a type of brute force attack in which, rather than trying many random passwords against a single account, a hacker tries the same password against many user accounts at once. This allows them to get around rudimentary security measures like account lockouts. To maximize the impact of password spraying, hackers often employ weak or commonly used passwords (such as "password" or "123456") in their attacks, which they can source from public reports like NordPass's annual list of the 200 most common passwords.

3. CREDENTIAL STUFFING

Credential stuffing is another brute-force technique. In a credential stuffing attack, hackers use compromised credentials (which they've purchased from the dark web or obtained from a data breach) to log in to other, unrelated user accounts. Unlike a traditional brute force attack, credential stuffing attacks aren't entirely random, as they rely on known username and password pairs. Since users tend to recycle the same credentials across multiple accounts, it's likely that one breached password will appear again on one of the other apps or websites that they use.

4. DICTIONARY ATTACK

In a dictionary attack, a hacker systematically enters common words and word variations from a specific, preselected list — kind of like a hacker "dictionary." A dictionary attack can be tailored to a specific group or region that a hacker is targeting. For example, a hacker might use terms and phrases related to local businesses, landmarks, and sports teams when mounting a dictionary attack against a particular company or city. While custom dictionary attacks can be dangerously effective, they tend to only work when users employ ordinary, everyday terms as passwords. That means enforcing strict password rules — like requiring users to create strong passwords with unique, randomized strings of characters — can be enough to prevent a dictionary attack.

5. MASK ATTACK

A mask attack is similar to a dictionary attack, but it's a far more targeted brute-force technique. In a mask attack, a hacker analyzes recognizable password creation patterns and/or password hashes they've picked from known data breaches and uses them to apply a filter (or "mask") to their dictionary list of possible passwords. This dramatically reduces the total number of password guesses they must make for a given account, resulting in a much more efficient attack.

6. SPIDERING

Spidering is also intended to support a dictionary attack and similarly requires some dedicated effort on the part of the hacker. In a spidering attack, a hacker gets to know their intended victim — generally, a larger, more established company — by studying their internal and external communications. This can include social media posts, web content, employee handbooks, product manuals, and even marketing style guides. From there, the hacker can compile a list of identifying information and common keywords and business/product terms that are unique to the company. They can use these terms to generate a shortlist of possible credentials, which makes guessing passwords on key corporate accounts that much easier.

7. MAN-IN-THE-MIDDLE (MitM) ATTACK

Man-in-the-middle (MitM) attacks involve eavesdropping on or otherwise intercepting sensitive communications between the app or website a user is connected to and another, separate platform. MitM attacks can take active or passive form. Active MitM attacks often manifest as session hijacking, where a hacker spies on web traffic over a given network, identifies active session IDs, and then uses the attached session tokens to breach a user's account. In a passive MitM attack, a hacker might create a free, public wifi hotspot, like the kind offered at airports, cafes, and public parks. They then get a full view of all of the online activities and data exchanges carried out by unsuspecting users who join their fraudulent network.

8. RAINBOW TABLES

Rainbow tables are comprehensive directories that use a password hash algorithm to list out every possible plaintext version of an encrypted password. Think of it like a hacker "cheat sheet" that allows cybercriminals to skip the work of actually having to hack passwords or a password hash themselves. In a rainbow table attack, a hacker consults this directory and matches the list of solved password hashes to encrypted passwords they find in a breached database, allowing them to successfully sign in to a user's account.



9. PHISHING

A phishing attack is less about cracking passwords and more about getting users to share them voluntarily, albeit through deceitful means. Essentially, phishing is a form of social engineering. In a typical phishing attack, a hacker sends their intended victim a persuasive message via email or text, hoping to trick them into sharing their credentials or other sensitive information. This can happen by way of a fraudulent link that, when clicked, downloads malicious software on a user's device, or via a spoofed website that gets the user to type their credentials into a fake login screen. Phishing attacks can be random, or they can target specific individuals or organizations. A common example of a random phishing attack involves an email scam, in which the author pretends to be the executor of a will, which they claim comes from a recipient's (fictional) long-lost relative. This fake executor promises to transfer a large sum of inheritance money to the recipient, but claims they need the recipient's bank account credentials in order to wire the funds. Of course, if the recipient provides these credentials, the hacker behind the scheme will simply breach their account and quickly drain their balance. A more targeted phishing attack, on the other hand, might mimic the messages a certain company sends to help users reset passwords. By clicking an embedded reset-password link and/or entering their credentials, a user is actually giving a hacker access to their account or allowing them to install dangerous programs on their device.

10. MALWARE

Malware, short for "malicious software," refers to programs that are designed specifically for stealing passwords and other private information from a device where they have been (often unknowingly) installed. Malware can piggyback on a link embedded within a phishing text or email, or it can hide within attachments, files, or websites that a user is tricked into opening or downloading. Malware can take many different forms and work in a number of ways. Two categories of malware that can be used to crack passwords are:

Spyware: Spyware hides on a user's system and secretly gathers information about their internet activity and behaviors, including any passwords, pins, and payment information they enter on an app or website.

Keyloggers: Keyloggers are a specific type of spyware that monitors and records a user's keystrokes, or everything a user types into their device. That makes it easy for hackers to track and recognize common typing patterns, like a user's password for a given app or website.

Password cracking tools

Password cracking tools help hackers, well, crack passwords. They're especially useful in offline password attacks, where there might be thousands or even millions of possible plaintext combinations for each of the password hashes uncovered in a database breach. In this case, the right cracking tool can do all the computational work, applying strategic algorithms and machine learning to unencrypt each hash. Some of the most popular password cracking tools include:

JOHN THE RIPPER

John the Ripper (JTR) is one of the oldest and most well-known password crackers on the market. It's a command-based app that works in Linux and Mac OS environments, and it can automatically detect and support a wide range of hash types and ciphers. While John the Ripper's basic platform comes as free, open-source software, there is also a "pro" version of the app that includes a more extensive wordlist, as well as support for specific operating systems.

CAIN AND ABEL

Another leading password cracker is Cain and Abel (frequently shortened to just Cain). It's available for Windows only, and it uses a graphical user interface (GUI) format, which makes it particularly attractive to amateur or beginner hackers. Much like John the Ripper, Cain and Abel can recover passwords using a variety of password cracking and decrypting methods, including through brute-force and dictionary attacks.

OTHER PASSWORD CRACKING TOOLS

While JTR and Cain are the two most common password cracking tools, they are far from the only available options. There are many other password crackers on the market, including platforms like Ophcrack, Hashcat, and THC Hydra, all of which can pose a significant threat to your app and your users.

What makes a password easy to hack?

There are many categories of "bad" passwords, but they all have one thing in common: they make a hacker's job easy. Here are some of the many ways users actually give cybercriminals a leg up:

Creating weak passwords

Simply put, a weak password is any password that's easy to guess or crack. It's estimated that around 30% of internet users have fallen victim to a data breach because of a subpar password. A password can be weak for various reasons. Users might keep the default passwords they're given to set up an account and then forget to upgrade to a more secure password once they're logged in. Or they might resort to simple words and phrases (the kind that end up in the NordPass list mentioned above) or familiar, meaningful terms (like their dog's name) because they find more complex passwords difficult to remember. For reference, nearly a quarter (24%) of internet users admit to using common passwords like "abc123" and "Qwerty," while 59% have included a family member's name or birthday in their credentials. That's not great.

Reusing the same password across different accounts

Users are opening more and more accounts online, and they're finding it difficult to keep track of their proliferating passwords. Many end up recycling the same credentials across many different sites and apps, rather than using unique passwords for every new account. Recent studies have found that password reuse is very common. In fact, 52% of surveyed users report reusing the same password across multiple apps and websites, and 13% use the same credentials across all of their online accounts. That means, if a hacker gets hold of one set of credentials using any of the above password cracking techniques, they have everything they need to break into some or all of that user's other accounts.

Connecting via an insecure network

As mentioned, users will sometimes connect to free, unsecured wireless hotspots when using their device in a public place like a park or cafe. In some cases, these are not legitimate wifi networks, but hackers mounting a man-in-the-middle attack to spy on unsuspecting users, which can leave their passwords (and their data) vulnerable.

How to protect against password cracking attacks

When it comes to traditional passwords, there's no bulletproof security measure that will prevent every single password cracking attempt. But there are some steps you can take to make a password attack much more challenging and inconvenient to carry out. Some simple best practices include:

Enforce and support secure passwords

Creating strong passwords (as a user) and enforcing strict password policies (as a developer) can help thwart basic brute-force attacks. This might include:

LUDS REQUIREMENTS

The LUDS system requires all users to include one or more lowercase letters (L), uppercase letters (U), digits (D), and special characters (S) when creating a new password. This increases the number of permutations a hacker would need to try to successfully mount a brute-force attack. You can also choose to reject any password containing a recognizable word or phrase, protecting against targeted dictionary, masking, and spidering attacks. As we’ve covered in our approach to strong passwords, though, LUDS has a few big shortcomings:

There are still many potential passwords that meet all of the required characteristics, but still use a simple pattern that can be easily cracked, like “A1b2C3d4”.

LUDS can still allow passwords that technically contain all of the required characteristics, but only because it uses common substitutions that are weak – like “p@ssword.”

From a user perspective, LUDS passwords are very hard to remember! Did you choose “Sp0tisagoodboy,” “sPotisag00dboy!,” or “$pOt!s@goodboy”? Who the heck can keep track!?

ZXCVBN

Given the weaknesses in the LUDS system, Stytch suggests services like zxcvbn, a flexible strength assessment based on how resistant a password is to modern password guessing techniques. Named after the same keyboard area as “qwerty” (just two rows down), it’s designed to make picking a strong password easy for humans to generate and hard for robots to guess. Zxcvbn works by first searching for matches to your user’s password in a list of common passwords, common names, common words, etc. If a match is found, it returns a score based on the match’s dictionary and pattern rank. There are many different ways to use it, but typically it’s implemented on the application side of a product, and not as commonly for individual users. The zxcvbn library is available in a variety of programming languages, including JavaScript, Python, Go, PHP, Ruby, and more. (You can also use an API like Stytch, which incorporates the zxcvbn method into our Passwords product.)

HAVEIBEENPWNED

HaveIBeenPwned offers both an individual-friendly website and a developer-targeted API that both monitor the web for stolen credentials in order to alert users and companies of those credentials’ insecurity. You can search for compromised emails, phone numbers, domains, passwords, and websites, and can even sign up for email notifications to notify you if one of your accounts has been compromised. While you can use HaveIBeenPwned as an individual user, you can also integrate it into your product via their API, which checks whether a user’s email address or password has been exposed in a data breach. If it has, the API will return a list of the data breaches in which the user’s information was compromised. This is what Stytch has done in our breach-resistant password solution.

PASSWORD MANAGERS

A password manager is software that helps users manage their passwords by encrypting them and saving them locally on a user's device. Stored passwords are then automatically pulled up whenever a user wants to log in to the associated account. Some password managers, like Google Password Manager, will even suggest a strong password at signup, ensuring secure practices are built into every stored credential. While password managers are effective tools, as a developer you can’t assume your users are using them. Adoption remains low, and growth in adoption still rather modest.

SALTING

A password "salt" is a random string of 32 or more characters that's added to a password before hashing. Salting makes it nearly impossible for hackers to comb through a database and recognize a hashed password in order to mount an offline attack or apply a password cracking tool. As we’ve pointed out in our article on hashing, though, salting on its own is not that great a protection. Only when combined with the best hashing algorithms does salting really have a significant effect on password security.

EDUCATION

Finally, educating users about different password attacks can help them avoid falling victim to common schemes — especially when it comes to social engineering tactics like phishing. Education is also a great precedent to set if you’re interested in gradually transitioning your users to a passwordless authentication solution. We’re strong advocates for this at Stytch where it makes sense for our customers, and if customers aren’t ready a great place to begin is through friendly, approachable education that helps make your users more auth-savvy.

Add fraud and bot protection to your authentication flow

Adding extra steps to your signup and login flows can help you differentiate between a legitimate user and automated bot traffic. At Stytch, we offer and see the benefits in two main approaches to bot detection: device fingerprinting and StrongCAPTCHA.

DEVICE FINGERPRINTING

Device fingerprinting is a way to identify devices that are accessing a website or application. A device’s identity can be composed of a number of attributes that an application detects when the user accesses the site or app that are then associated with a unique ID. Unlike cookies, which are stored client-side, device attributes and IDs are stored in a server-side database, which the website or app can then use to check against future behavior from their users. Note though that not all device fingerprinting solutions are created equally: a large part of their efficacy depends on the kinds of attacks a given app or service is suffering from, the sophistication of their attackers, and how their auth flow responds to possible fraud without creating undue friction for their users. Fingerprint attributes like IP address are easy to detect but are also easy to fake or obscure through VPNs – the best fingerprinting solutions combine a multitude of factors, and also allow for a range of escalation procedures to further investigate the identity of a user. If you’re interested in learning more, check out Stytch’s own Device Fingerprinting solution.

STRONGCAPTCHA

The most common bot-detection technology is the CAPTCHA test, which has users pick out objects like motorcycles and crosswalks from a lineup of images to prove they're human before they can access their account. While traditional CAPTCHAs have recently fallen prey to a cottage industry of CAPTCHA fraud, next-generation versions — like Stytch's Strong CAPTCHA solution — have emerged to bridge this security gap.

Implement multi-factor authentication (MFA)

Multi-factor authentication (MFA), which includes two-factor authentication (2FA), takes a layered approach to auth, requiring two or more identity credentials before a user can access their account. This might include a traditional username-and-password pair (factor 1), plus a security question (factor 2) and a one-time passcode sent via text or email (factor 3). These factors can all be front-loaded at initial login, or they can be interspersed throughout the user journey, with extra auth steps (and thus, extra friction) introduced only for especially sensitive actions — like if a user wants to change their payment details. This is known as "just-in-time" authentication. The best MFA flows today are unphishable, meaning they avoid any type of auth factor that can be intercepted by a determined hacker.

Go passwordless

When it comes down to it, the only surefire way to stave off a password attack is to eliminate passwords altogether. Today, there are many secure, frictionless, and completely passwordless authentication solutions that are easy to implement and to use, from one-time passcodes and embeddable email magic links to seamless biometric factors and WebAuthn. As adopting such passwordless solutions gets even easier — slowly becoming the norm for online life — we'll finally make password cracking a thing of the past.

How Stytch can help

Stytch is committed to fighting any and all password cracking methods that can put your app and your users at risk. That's why we offer a full suite of modern passwordless products — as well as Breach-Resistant Passwords that build strength assessment, breach detection, and account deduplication measures into every signup and login flow. To learn more about our platform, get in touch with one of our cybersecurity experts — or register for a free account to try our solutions first-hand.

---


# The journey to ISO 27001 certification
Source: https://stytch.com/blog/iso-27001-certification/

A step-by-step guide to our journey to ISO 27001 certification – what it is, why it matters, and how to do it.

In today's digital age, where data breaches and cyber threats have become an unfortunate reality, the need for robust information security practices has never been more critical. As technology evolves, so do the risks associated with storing and managing sensitive information. That's why we are thrilled to announce our achievement of the ISO 27001 certification (in addition to maintaining our SOC 2 report), a testament to our commitment to protecting our clients and their users as well as ensuring the highest standards of information security.

Today we'll cover:

What ISO 27001 is
How to prepare for certification
What's involved in the audit process
How to maintain certification
FAQs
Stytch's top three takeaways from our own certification

What is ISO 27001?

ISO 27001 is an internationally recognized standard for information security management systems (ISMS) that defines a set of requirements a company’s ISMS must meet. It provides a systematic and proactive approach to managing sensitive company and customer information by identifying potential risks, implementing security controls, and continuously improving processes.

History of ISO 27001 certification

Though the official ISO 27001 standard was minted in 2005, its history dates back to the early 1990s in the U.K. Rapid advancements in information technology prompted the government to request a set of standards for evaluating the security of IT systems and products from the Department of Trade and Industry's Commercial Computer Security Centre (CCSC). 

The CCSC created a code of best practices called DISC PD003, which by the late 90s they organized into two major components: BS7799-1, which outlined controls and control objectives, and BS7799-2, which outlined a formal standard for information security management systems. By 2000, the International Organization for Standardization had adopted and re-christened the former as the ISO/IEC 17799 standard (or what would become ISO 27002). In 2005, they formally adopted the latter as ISO 27001.

Why does this history matter?

Once the CCSC's standards were adopted by the International Organization of Standardization, they gained a level of international legitimacy that is near unrivaled in the world of standardizations. The ISO is in fact an international, non-governmental body that issues standardizations across industries. 168 of the world's 195 countries are members. This means if you attain ISO 27001 certification, you literally open borders for your business by creating massive opportunities for scale.

Why is ISO 27001 important for an information security management system?

An information security management system is by default charged with one of the most important tasks on the internet: protecting the integrity of the information of people and companies. When that is your main function, an ISO 27001 certification is one of the surest way to accomplish the following:

Ensures enhanced information security

The ISO 27001 certification demonstrates our unwavering commitment to safeguarding our customers and their users. By implementing a comprehensive information security management system, we have put in place measures to protect sensitive information from unauthorized access, disclosure, alteration, or destruction.

Attests to compliance with regulatory requirements

ISO 27001 certification helps us meet and exceed legal and regulatory requirements related to data security. It ensures that our information security practices align with industry standards and best practices, providing peace of mind to our clients and stakeholders.

Offers competitive advantage

In today's competitive landscape, organizations that prioritize information security gain a competitive advantage. ISO 27001 certification sets us apart from the competition by showcasing the maturity of our information security program and our dedication to maintaining the confidentiality, integrity, and availability of customer information.

Earns customer trust and confidence

Data breaches can have far-reaching consequences, eroding customer trust and damaging a company's reputation. By achieving ISO 27001 certification, we provide our clients with the assurance that their information is in safe hands, building trust and fostering long-lasting relationships.

ISO 27001 certification vs. compliance

Technically, companies can be ISO 27001 compliant without being certified. If you're ISO 27001 certified, that means that an external auditor has gone through a specific set of evaluations and audits to confirm that you're ISO 27001 compliant. Generally, when companies request or refer to ISO 27001 for a vendor they're considering, they'll want that external certification, not just documentation that proves you're compliant.

Preparing for ISO 27001 certification



ISO 27001 certification is granted upon successfully completing stage 1 and 2 ISO 27001 certification audits, but there's a lot of preparatory work companies need to do before the audit takes place to make sure they're ready. Before engaging external auditors, a company should make sure to:

1. Scope and implement an information security management system or framework

This may sound like a no-brainer, but some companies, especially new ones, may have a hodge podge of different practices and protocols they use to protect information security at their company without having an explicit management system or framework. This includes delegated employees whose job it is to maintain that management system, oversee its quality and efficacy, and monitor its compliance with standards like ISO 27001.

2. Conduct a risk assessment, and mitigate any found risks with a clearly documented risk treatment plan

Any company looking to receive ISO 27001 certification needs to conduct regular, well-documented risk assessments followed by treatment plans with necessary controls and policies. Both for the sake of internal efficiency and a smooth certification, companies should remember that more does not necessarily mean better when it comes to controls. Controls are only as useful as they eliminate security risks without undue burden or friction on internal processes. Because of that, any control or policy should clearly dock to your company's use case and priorities.

3. Document all relevant systems and processes

ISO 27001 certification has many requirements, but companies do not need to meet every requirement to get certified. Instead, you should carefully evaluate their specific use case to understand which of these requirements apply to their business. Your ISO 27001 documentation should make it easy for both internal stakeholders and external auditors to assess whether or not their information security management system meets those requirements. This documentation should also clearly and succinctly show their approach to risk assessment and risk management. 

The more thoroughly you show your work, i.e., document all your company has done and regularly does to maintain a compliant ISO 27001 service, the better. Note that without careful management and systems in place, this can get unwieldy, difficult to organize, and/or create bloat. Be very mindful of how you organize your risk assessments, your processes, and findings in ways that are usable to your internal stakeholders and accessible and clear for external auditors.

4. Conduct an internal audit & resolve any nonconformities

Every company applying for ISO 27001 certification is required to do an internal audit before an external audit or review – and hold regular internal audits in order to maintain their certification. This "internal" audit is intended to surface any nonconformities with the ISO 27001 standard, raise them to the relevant stakeholders at a company so they can be resolved before the external audit. 

Though this final step is called "internal," companies can either choose someone who is in fact internal to their company, or hire an outside vendor to conduct this audit for them. That said, if you end up using someone in-house to conduct your internal audit, you must make sure they have no conflict of interest, i.e. are not responsible for implementing or maintaining any of the systems, controls, or policies they're evaluating.

5. Onto the external audit

Once you've completed all of the necessary preparatory work, you can then solicit an external audit.

The ISO 27001 certification external audit – what to expect



While the most important legwork for your own team takes place in the lead-up to your audit, the audit itself is clearly the moment of truth for any company seeking certification. There are three important steps to completing the audit: choosing your auditor, and stages 1 and 2 of the audit itself.

Choosing your ISO 27001 external auditor

When choosing an external ISO 27001 auditor, there are a few key things to look for:

1. Accreditation

Check an accreditation directory as your starting point. These directories do a fairly thorough job vetting for the auditors listed on their site, but it never hurts to do your due diligence and make sure the information listed in the directory corresponds to the auditor's website and own materials.

2. Industry alignment

Though not required, you'll likely find it helps to have an auditor who knows your particular industry well. They're more likely to ask you the right questions, give nuanced and helpful guidance, and understand the constraints and demands on your information security management system better than someone outside your industry.

3. Bundled or additional certifications

There are fewer more painful time-drains than vendor searches. If you know your company plans to scale at some point or have other security compliance certifications on your horizons, it could be nice to find an auditor that does more than one. Forming a strong relationship will make future certifications and audits smoother down the line. Furthermore, you can reduce your own audit fatigue by selecting an auditor to address multiple certifications/frameworks simultaneously.

ISO 27001 certification audit – stage 1

The ISO 27001 audit takes place in two stages. In Stage 1, your auditor is basically making sure that you have all the necessary documentation and processes established to undergo a stage 2 audit. At this time they'll review what are referred to specific clauses from the ISO 27001 standard, specifically clauses 4-10. Together, these clauses cover all the requirements an information security management system needs to meet to get certified. They are:

Clause 4: Context of the organization

This covers the very foundation of your company's ISMS – its scope, why you need one, what information you handle, and who your key stakeholders are.

Clause 5: Leadership

Clause 5 covers the roles and responsibilities of your ISMS team and the policies they must abide by.

Clause 6: Planning

Clause 6 offers a clear-eyed overview how your organization will achieve its objectives especially as it relates to risk and opportunities.

Clause 7: Support

Clause 7 outlines the resources your company has devoted to maintaining its ISMS.

Clause 8: Operation

Clause 8 is where you discuss your risk assessment and treatment plans, and whatever controls you've put in to mitigate those risks and other information security requirements.

Clause 9: Performance evaluation

Clause 9 is where you document how you evaluate your performance, how and how often you conduct internal audits and reviews.

Clause 10: Improvement

Improvement covers any nonconformities you may have identified in your internal audit, and how you plan to address those. Upon reviewing your documentation to make sure all these requirements are accounted for, your auditor will either pass you on to stage 2, or will first raise what are called "areas of concern" you need to address in order to pass stage 2.

ISO 27001 certification audit – stage 2

In ISO 27001 stage 2, your auditor moves on from reviewing your clauses to a second part of the ISO 27001 standard called Annex A. While Clauses 4-10 address the requirements for an ISO 27001 certified company, Annex A covers the possible security controls a company could use to meet those requirements. 

As mentioned before, no company is expected to implement all controls. You are simply expected to have the necessary controls in place for your context and industry, and for the goals and measurements you've outlined in your own ISMS.

Maintaining ISO 27001 certification

Achieving ISO 27001 certification is not a one-time accomplishment. It requires continuous monitoring, assessment, and improvement of the ISMS. By establishing a framework for monitoring and reporting security incidents, conducting regular audits, carrying out management reviews, and continually improving, you can ensure the effectiveness of our ISMS on a recurring basis. 

As part of maintaining your certification, you'll also need to undergo what are called surveillance audits, which are regular (generally annual) audits to make sure your company is still adhering to ISO 27001 standards. 

This is another reason why the systems, documentation, and controls you set up during your prep work are so crucial: ISO 27001 is not just a box to check, it is a marathon you'll be running for the rest of your company's life! Dedicating the regular

ISO 27001 certification – FAQs

How many companies are ISO certified today?

According to the ISO 2021 Survey, nearly 60,000 companies worldwide had attained ISO 27001 certification. That may seem like a lot, but consider that the U.S. alone is home to over half a million technology companies. 

While not every one of those companies may need ISO 27001 certification to do their business securely, it does show what a differentiator this certification can mean in the global market for an information security management system.

How long does it take to get ISO 27001 certification?

The amount of time required to get ISO 27001 certified can range depending on many factors, like:

How established your company's ISMS was before beginning the process

Your industry and use case, with its particular risks, information, and intellectual property to protect

The resources you have available already, vs. how much headcount you may need to pull of other tasks to complete your prep work

Whether the stakeholders involved at your company are familiar with the process or not

Generally, however, most small to mid-sized companies are able to finish the preparatory work for the audit within four to six months.

How much does it cost to complete ISO 27001 certification?

While some sources may give ballpark figures for an ISO 27001 certification process, the reality is it's highly dependent on many different factors that could influence the end costs. Some of which are: whether your internal audit is in-house or not, the specific audit firm you select, the scope of your assessment, and whether other frameworks are being simultaneously audited. 

Best practice is to get quotes based on each of these factors so your company can budget appropriately.

Our take

Looking back on our own ISO 27001 certification process, we have a few learnings we think would be useful for companies considering this for themselves:

Lesson 1: Define the scope early

<It is important to clarify the certification’s scope early in the process so as to ensure you are thinking about all the relevant applications, services, controls, and processes for each requirement of the standard. While it is doable to fold an application into policies and controls after the fact, it is much easier to create the appropriate documentation and processes with all relevant applications and services in mind from the start.

Lesson 2: Documentation is incredibly important

As we’ve mentioned a few times in this post, documentation, and more importantly thorough and accurate documentation, is essential for a smooth implementation and certification. Documentation provides ongoing references to all personnel on the ISMS as a whole, the scope of controls and processes, as well as everyone’s responsibilities. Ensuring this is accurate and updated frequently, helps to avoid actions drifting apart from well established processes. It also helps with our next key learning…

Lesson 3: Continual (re)education

As part of any good information security program, continual (re)education is essential. Not only does this offer another opportunity to introduce and reinforce policies & controls, it also helps to remind everyone of their responsibilities and the importance of those to the overall success of the ISMS. Lastly, education offers an opportunity for personnel to offer insight in case there are use cases that do not align with historically documented controls/processes, for which, documentation can be updated to reflect this.

Conclusion:

As technology continues to advance, the need for robust information security practices becomes increasingly vital. Achieving ISO 27001 certification is a significant milestone for Stytch. It signifies our commitment to protecting sensitive information and fostering trust with our clients. With Stytch's robust Information Security Management System in place, we are well-equipped to navigate the ever-evolving landscape of cyber threats, ensuring the highest level of data security for our stakeholders. 

At Stytch, we firmly believe that information security is not just a responsibility; it is a priority. Our ISO 27001 certification is a testament to our dedication to providing secure and reliable technology solutions. Together, let's embrace the future with confidence and trust in our commitment to protecting your valuable data.

---


# What does compiler theory have to do with auth?
Source: https://stytch.com/blog/what-does-compiler-theory-have-to-do-with-auth/

On a hunch, this engineer considered the following question: what if you transpiled your API definition into client code?

Question: What does compiler theory have to do with authentication?

Beyond the fact that normal people don’t think much about either, there’s another, more fecund connection…

One of the challenges of building and maintaining an API, whether you’re building a product like Stytch or a service that’s used internally, is maintaining SDKs or client libraries, usually in many languages. One of the big hidden costs to maintaining a service like auth that’s consumed by many other services is maintaining client libraries — usually in at least a couple different languages. When building an auth API, like Stytch, this is made all the more complex by the security and reliability concerns peculiar to libraries tied to a critical security infrastructure component such as auth. Even with well factored code and extensive unit tests it’s still subject to human error, especially given what a tedious chore of a developer task it is.

Much as we love humans at Stytch (and our human developers in particular), we’re a teeny bit obsessive about systems that help eliminate those pesky errors, especially where they can cause latency or security risks for our customers. Luckily, at least one person on our team was paying attention in their compiler theory class (thanks Prof. Galles), and realized a solution for maintaining our libraries might just lie in that obscure collegiate experience.

On a hunch, this engineer considered the following question: what if you transpiled your API definition (ideally strongly typed and versioned) into client code?

This article covers the first part of Stytch’s attempt to answer that “What if?” and how we began designing a code generator for our backend SDKs in Go, Python, Ruby, and Node.

Part one | What does compiler theory have to do with auth?
Part two | Generating "humanlike" code for our backend SDKs

Table of contents

The problem: maintaining clients
Step 1: Generating clients from a declarative spec
Step 2: Hacking out a protobuf transpiler in awk
Step 3: Writing a proper AST-based transpiler
Good for you, why should I care?

The problem: maintaining clients

If you’ve dabbled in API schema evolution (and who hasn’t really?) you may know that there are a number of challenges. Depending on your use case, the worst of these can include maintaining strong typing, forward and backward compatibility, and mapping complex data structures across languages. What do those things mean? Well let’s take it one thing at a time.

Strong typing

Strong typing is the ability to strongly assert that a given variable has a particular type at compile time rather than having to check at runtime. Some languages like python have traditionally made do without this, but many people (your author included) sleep better at night knowing that people can’t just pass arbitrary types as arguments to a function I only intended to work with strings.

Forward and backward compatibility

Forward and backward compatibility are things that you have to worry about when you start changing your API. You might wind up adding a new field to a request, but does that mean that old versions of the client that don’t populate that field will break? What if you need to remove a field, or use a different type for a field, or heaven forfend modify the response? If you’re using regular JSON or a naïve binary protocol, these simple things can cause breakage any time you make a small change and the server and client aren’t using the exact same version.

Mapping complex data structures

Mapping complex data structures across languages is always very interesting. Much of the value in having lots of different programming languages to work with comes from the different paradigms they offer, which lend themselves to different approaches to solving problems. The problem is that many of those different paradigms have to do with how data is represented. Some languages only have one list/array type and swap out implementations under the covers; some languages have algebraic type systems that let you construct whole worlds for others to shudder at; and some languages just have scalars, lists of scalars, and maps of scalars.

So how do you reason about sending messages between servers and clients written in these different languages? Well, you start by defining your API in a fairly generic way that only uses the very simplest types. But soon you realize that what you thought was simple was in fact totally unworkable in some weird case you have to support, and then you wake up in the bathtub covered in bourbon and cold sweat.



Luckily, there is a great deal of prior art concerning these challenges. One of the better solutions is protobufs (protocol buffers), a really lovely declarative API schema language that’s built from the ground up to support strong typing, forward and backward compatibility, as well as mapping complex types between languages. There are other options as well, like OpenAPI, Thrift, or even Cap’n Proto if you’re feeling zany, but Stytch went with protobufs because of their majestic and expansive open source ecosystem.

There is also a great deal of prior art in how to programmatically generate API clients from protobufs; unfortunately the code they generate usually looks something like this…



…which is sort of the opposite of a user-friendly API, and still requires a bunch of protobuf-specific boilerplate. In fact, if protobuf 3 isn’t well-supported for all your client library languages, you’ll need to figure out mapping between a StringValue and a nullable string for every language. Then, for every client language you get to spend a significant amount of time writing or finding a good library to manage mapping the protobuf types to something readable and at least vaguely idiomatic to each language.

Given that our aim was to make auth easier, this clearly wasn’t a viable option. Instead, we decided to maintain our clients manually.



As the reader can likely imagine, this manual endeavor turned out to be tremendously tedious and tiresome toil. Every API change required making changes across no less than 6 repositories, 5 of those changes effectively identical with the exception of language syntax. The result was exactly what one would expect, the languages people are most familiar with stay more up to date than others, drift crept in between languages as small irregularities due to human error built up over time, and there were numerous small oversights like missing response fields and differences in the object mappings between languages that further compounded this tech debt.

Then one day in an effort to change all that, one brave engineer at Stytch undertook a 20% project to template one of these clients.

Step 1: Generating clients from a declarative spec

Web clients range in complexity from simple Create, Read, Update, Delete (CRUD) interfaces to complex, cluster-aware, concurrent computational linguistics interfaces. Luckily, auth is one of the simpler APIs and has very few cases that deviate from simple CRUD mechanics. Auth clients therefore tend to be fairly repetitive, with most of the logic being simple serialization/deserialization (serde). This makes it extremely well suited to templating.

Such was the foundational insight of this intrepid engineer’s efforts and – spoiler alert – it was borne out to spectacular success. This engineer wrote a python program that would:

Parse a YAML (Yet Another Markup Language) specification and

Render it using Jinja2 templates to create a client interface that was readable, performant, secure, and required significantly less effort to keep up-to-date.

Manually writing client changes to this library became a thing of the past, the code templates since are occasionally modified to fix bugs but otherwise require very little changes. Moreover, modifying the specifications is now considerably lower effort than writing boilerplate code.

So why not stop there? Two reasons:

The up front cost of adding a new language to this templating engine involves weeks of tedious work creating the API specification for that language.

Even after you pay that upfront cost you do then still need to update those specifications for every client after you make an API change.

Until just a couple months ago, such was the state of affairs for our downtrodden iconoclast.

Lucky for this engineer, though, his team had just acquired a new addition, a very particular kind of lunatic who happened to have experience transpiling protobufs: your dear author.

Step 2: Hacking out a protobuf transpiler in awk

In the weeks that followed, this arguably unstable individual (but very reliable narrator) eschewed traditional tools like YACC (Yet Another Compiler Compiler) and ANTLR (ANother Tool for Language Recognition) in favor of awk and sed.

Why would one use general command line text processing languages rather than something purpose built for such a task? One would assume some combination of familiarity and some special flavor of engineering perversion, but it’s hard to say anything definitive about such a brilliant cipher of a man. Fortunately, awk and sed are tremendously adaptable tools that specialize in matching and transforming text, which is all code really is, so with something like this you can in fact lex, parse, and generate code all in one step if you can stomach what’s necessary:



So after a couple 20% project sessions, with a number of hacky scripts like this in hand, your author went to that original engineer and boldly claimed that this would solve all the maintainability problems with the existing templating solution.

That original pioneer was quite taken with this idea of transpiling protobufs, and willing to indulge your troubled author’s fascination with awk and sed long enough to win a hackathon prize by using this approach to add another couple languages to the templating engine and some CI magic to generate PRs from commits to the protobuf repo.

Luckily for everyone involved, this modern day Teddy Roosevelt refused to rely on your author’s arcane solution for production client generation, and treated it instead as a reference implementation for what was to come next.

Step 3: Writing a proper AST-based transpiler

If upon seeing that block of awk you wondered if this was something discovered in Roswell or the Mariana Trench, you’re not alone, or even that far off. It is wildly unsuitable for production usage since the only real way to debug it is to use your terminal as a REPL (Read Eval Print Loop) and add strategic print statements, and that’s assuming you’ve spent several years learning the many quirks of command line text processing.

However, it should come as no surprise that there is a significantly easier way to handle the lexing and parsing of protobufs. What is it? Well you’ll just have to read the next article in this series to find out.

Good for you, why should I care?

If you don’t have any APIs to manage and you don’t like cool computer stuff you probably don’t care and it’s quite strange you made it this far. If, on the other hand, you read through this because you’re an engineer who might have to maintain auth clients someday or you’re building an API product and trying to figure out how to manage building a myriad of different SDKs, then hopefully this walkthrough of our approach was a helpful primer on the problem space.

If solving problems and reading topics like this also excite you, check out our career page!

---


# Generating "humanlike" code for our backend SDKs
Source: https://stytch.com/blog/generating-humanlike-code-for-our-backend-sdks/

In this article, we'll discuss what it takes to make computer-generated code feel "humanlike" for Stytch's backend SDKs.

In our previous article, my colleague, aka the “intrepid lunatic” Josh walked you through some of the details of how we brought compiler theory into the authentication world by generating our backend SDK clients directly from our protobuf specs for Go, Python, Ruby, and Node.

In this article, we’ll discuss what it takes to make computer-generated code feel “humanlike” and how we generate +35k lines of code with just a few command lines at Stytch. This is essential in making sure that it’s easy for external developers to understand how our SDKs work and be able to debug their auth when something isn’t working like they might expect.

Ultimately, generating the SDKs automatically was an exercise in patience and attention to detail. Along every step of the way, we had to consider what sort of “rules” we had already implicitly adopted in our API, and how we could programmatically enforce them in our SDKs.

Let’s take a look at what made this a hard problem and how we solved it at Stytch.

Part one | What does compiler theory have to do with auth?
Part two | Generating “humanlike” code for our backend SDKs

Table of contents

Graduating from awk
Abstract Syntax Trees
Turning trees into… more trees
Turning trees into… code!
The codegen architecture
The impact for our teamTakeaways



Graduating from awk

When we first wanted to try auto generating our SDKs from protobuf definitions, it began as a hackathon project. Over the course of a few days, we proved that we could parse our protobuf definitions and turn them into a spec that could be used to generate methods in our target languages.

This was a fine start, but left us with more than a few issues to resolve.

Getting protobufs into a readable format

Though our first pass was perfect for showing the viability of the approach, it was nearly impossible to debug. We had this very specifically written awk program with random bits of sed sprinkled in to make names match up – there was no logging, no debugger to jump into, and every time we found a new edge case.

In short, it was a massive pain to update.

We looked into what solutions were available for parsing protobufs already and found that buf supported outputting a protobuf spec to JSON directly. JSON is certainly a far more predictable structure than raw protobuf definitions, so we took this as our starting point to build our codegen library.

Moving to a debuggable language

The exact choice of language didn’t particularly matter for this project, but we evaluated our options through the lens of a few primary drivers:

Our choice should be something that our developers are comfortable reading and writing.

The language should offer strong support for logging and debugging.

A scripting language would likely make it easier to build a solution quickly since we needed some dynamic flexibility given the recursive nature of many of our definitions.

These factors led us to choose Python to build our first version of the code generator.

Abstract Syntax Trees

Once we had the protobufs in a JSON spec, we wanted to build an abstract syntax tree that represented the Stytch API. We didn’t think this task alone would be too difficult, but we quickly realized that our mental model didn’t necessarily match reality.



In our mental model, the Stytch API consisted of multiple products. So there would be a MagicLinks product, a Passwords product, etc. Each product could have one or more services, one or more structs, and one or more enums. Each struct had a list of fields, each enum had a list of variants, and each service had a list of methods. Each method consisted of a request type and a response type, which referenced some other struct within the product. 

As we got started in development, our mental model had to be… amended.



In reality, there were many edge cases to consider:

Some protobuf files contained struct or enum definitions without actually defining any callable method. These "utility" files still needed to be generated if their structs were used elsewhere even though they wouldn't define any new services.

Methods get added to protobufs while being developed before we're ready to expose them in our SDKs. For example, we'll be offering MFA in our B2B suite later this year, but we don't want to expose SDK stubs before it's publicly available.

We had bifurcated our SDKs into a Consumer and B2B API and needed to programmatically parse this from the protobuf definitions. For our developers, this meant we needed to make our SDKs clear that a project had access to either the Consumer API or the B2B API.

Our SDKs define virtual "sub-products" (like otp.sms, otp.whatsapp, and otp.email) to make the flow more natural for developers.

In some cases, we even define nested sub-products (like magic_links.email.discovery in our B2B API) which means we need to allow for arbitrary nesting.

Structs which are only referenced internally but don't correspond to anything in our public SDK shouldn't be added to the backend SDKs. We have APIs like DeleteProject which can be called from the Stytch Dashboard, but aren't available as an API call from the backend SDK since programmatic deletion of your running project is a recipe for disaster.

Fields can be nullable, fields can be deprecated, and the type of a field can be anything… a basic type, a struct, an enum, or a mapping from a string to one of those types… and those structs and enums may come from this product, another product, or a virtual sub-product.

Many of our APIs have flexibility where there are optional parameters you may not need. magic_links.email.send(...) allows you to attach an email to an existing Stytch user, but you don't have to do so. How could we best represent this in our SDKs to help developers understand this?

In a method's HTTP spec, a path may contain path parameters (like /v1/users/emails/{email_id}) which need to be interpolated from the request data.

Enum variants are sent as strings from clients which get translated into proper enum types internally. We used strongly-typed enums for our API internally (like DeliverMethod.WHATSAPP), but in an API response, we'll translate this into something more clear like "delivery_method":"whatsapp". Making this translation automatic in our SDKs would be a huge win for usability.

Turning trees into... more trees?

After turning our specs into abstract syntax trees in the "ideal" case, we started thinking about how to handle each of these edge cases. As we tackled each edge case, we had to determine how we could avoid patching immediate problems and instead solve underlying issues. 

If we decided to hard code something like "the otp product has three sub-products called sms, whatsapp, and email" into our code generator, and then next month we added a new sub-product, we would have to update our code generator. This isn't impossible, but one of the biggest reasons we started this product was to free our developers' time for things other than worrying about how to build the SDKs.



The only realistic way to make codegen line up with what we had already built by hand in our SDKs was to run the generator, note what was different, and then think logically about how we could resolve the differences. This led to a three step process in our AST translation phase:

Find an inconsistency between the generated output and existing output.

Build an AST translation to resolve the difference.

Ask ourselves if this was a generic translation that should apply to every SDK.

Finding inconsistencies

At each junction, we thought about how we could programmatically handle the edge case now and into the future. We examined the elements that defined the rule and codified those into our code generator. We did find some instances where we were seemingly inconsistent with our own behavior, but this allowed us to rectify those mistakes and become more internally consistent.

Translating ASTs

Taking a step back and examining what we were doing, we realized that we wanted to support a series of translators that would run on the AST and modify it according to some rule. Each language's generator would then have an abstract method returning the sequence of translators that should run on the input.

"Is this a generic translation?"

During this project, we started by trying to generate the stytch-python SDK since we had already dabbled with code generation there in the past. Every time we encountered a discrepancy between the input JSON spec and the Python code, we asked ourselves whether the transformation was something that all SDKs would need or something specific for Python. We ended up grouping all of these initial translations into something we've called the default translator.

Defining the default translator

The end result is that we were able to push much of the AST translation up in the stack before we had even picked a language. This was incredibly beneficial since it meant the gap to supporting a new language gets that much shorter. Today, the Python-specific translators that get run are incredibly simple:

We translate all method names to snake_case

We translate all object names to PascalCase

Types get translated to Python-specific names (OPTIONAL_TYPE_STRING becomes Optional[str], for example)

Because we were able to push up so much AST generation into the "generic translator" stage, Python-specific translations are possible in under 50 lines of code. Our Go SDK is a bit more opinionated (rather… the Go language is more opinionated on variable names like userId being converted to userID), but we also have all of its translations done in under 100 lines of code.

Adding backpressure

There was a discussion about whether anyone would intentionally build a new product or endpoint that fit a rule they did not wish to cover. What if we had a new method and the default translator resulted in a "bad" translation when generating that method? 

We decided that these instances would be treated as exceptions to the rule and require the Stytch developer to add the exception into the code generator. Cases where we wish to go against our own rules should be exceptionally rare, and an active decision should be made if someone wishes to be inconsistent with those rules.

Turning trees into... code!

Once the AST had been translated, we could finally start the code generation process. There are two broad categories of approaches you can take to generate code, and both have their merits and drawbacks.

Approach 1: "walk the tree"

In the first approach, you pass the root node of your AST and have your generator recursively generate the code corresponding to each node in the tree. This solution is pure in that a generator can build a render method for each type of tree node. The downside is that it can be overly abstract (no pun intended). Especially when generating an entire API, you may wish to spread definitions across different files in a repository and this can be awkward with this method.

Approach 2: templates, templates everywhere

The second approach is more recognizable to developers, even if you've never thought about code generation before: You have an object and a template… render the template. If you give it enough thought, you can easily use this solution and develop an API of arbitrary complexity just using templates. The problem here, though, is that if you don't add sufficient safeguards and suggestions, you can end up with templates spanning hundreds of lines that get difficult to maintain.

Approach 3: a hybrid model

For our case, we decided to build a hybrid approach between these two. 

In our code generation, we pass the AST to the language-specific generator and let it decide how to handle it. In practice, we implement an abstract interface that defines methods for rendering a service, a method, a struct, and an enum from the AST. Generally speaking, this isn't too prescriptive and guides the codegen developer towards building something extensible and maintainable in the long term. For some languages, each service gets its own file. 

For other languages, every struct may live in a centralized models file. There's no rule that perfectly fits every language, so by adopting this hybrid approach and providing tools to iterate through the AST and also define templated sections with a smorgasbord of utilities available, we've made it easy to extend our API to support new languages in the future.



Our Python generator is about 250 lines of code and 175 lines of templates. Including the translators mentioned above, we generate the entire backend Python SDK in just about 500 lines of code. This turns into 8k lines of code and inline documentation in the stytch-python repository.

The best part is that Stytch engineers no longer need to worry about updating the SDK by hand. Instead, our codegen repository will build the types and methods automatically.

Similarly, our Go generator only takes about 200 lines of code and 200 lines of templates. This means we have another entire backend SDK being written in under 500 lines of code.

For the languages we want to officially support, we can build a small “core” library that gives us the ability to easily call HTTP methods and parse JSON responses into typed structs and turn it into a fully-fledged backend SDK just by writing about 500 lines of type translations and templates. From then on, any new updates to our documentation or public API will be had “for free” in that backend SDK.

The codegen architecture

Putting it all together, we built the following architecture:



1: Generate JSON specs

In step 1, we run some commands in our docs and protobuf repos to generate JSON specs. For the protobufs, we use buf, as mentioned previously. For our docs repo, we have a simple solution that looks at exported symbols and generates a large collection of JSON objects. We'll talk about how these get joined together in step 3.

2: Read the spec into Python

We define a collection of pydantic.BaseModel objects to load the JSON spec into Python. While technically a tree at this point, there isn't much structure to it. For example, methods have declared input and output types, but these are just simple strings (like api.users.v1.User). It would be a rather tedious traversal to find the actual definition of what that User object actually is.



3: Build the initial AST

From these naïve objects, we built the "real" AST by resolving typenames to actual references to other objects in the tree. The end result is that our AST becomes something more like an "Abstract Syntax Directed Graph of Objects and References" but that doesn't really roll off the tongue as well. 

The implication here is huge, though. We could now rename a struct in one place and have that propagate throughout the entire tree. So if we wanted to rename the api.users.v1.User object to something like StytchUser, every reference would also update. This gave us the power to really start molding the AST into the shape we wanted.



4: Run the default translator

We talked about the default translator earlier, but to reiterate, this is a core translator that always runs for every SDK. Philosophically, we say that the default translator fixes the AST "shape" while specialized language-based translators should only change the "color" of nodes (like renaming operations). This philosophy allows us to keep our Stytch SDKs consistent since major AST structural changes happen the same way for every SDK. 

Speaking concretely, here are some operations the default translator does for us:

Generate sub-APIs by converting methods like magic_links/email/send to MagicLinks.Email.Send(). This happens by inspecting the HTTP path of each method and determining whether it looks like it should belong to a sub-API.

Unnest nested structs and enums and "promote" them to standalone types. Since not every language supports nested types, this promotion also helps us keep the SDKs more consistent.

Manually rename some methods for clarity. For example, internally the getJWKS() method is just called JWKS(), but this isn't particularly descriptive to external developers.

5: Run specialized translators

Each language defines its own set of translators that get run after the default translator. Since we have made the decision that the default translator fixes structure and specialized translators just do name updates, these are basic classes. Below you can see the translators defined for our PythonGenerator.



The PythonTranslator just converts protobuf type names to Python type names. In case you're curious, the special google.protobuf.XValue types below generally just refer to a nullable X, but field nullability is stored on the Field object, so we don't have to worry about translating the name to something like Optional[int] here.



6: Generate output

Once all translation is done, all that's left is to render output. We took a hybrid approach to rendering code which gave us flexibility in using the most efficient tool for the job when rendering the different kinds of nodes. 

For simple nodes, we returned strings directly from methods. This worked well for nodes like Field which often rendered as a one-liner. It also allowed us to encapsulate conditional or looping logic easier, since it's generally not pretty to add conditional logic into a template file.



For more complex nodes, we used a templating approach that would pass the entire node into our templating engine. For a node like Method which will render as many different lines in an SDK, templates work well for making sure everything is aligned properly.



The impact for our team

At the end of June, we launched major versions of our SDKs built entirely from this codegen solution. Ultimately, this work is helping us save dozens of engineering hours from updating our backend SDKs. 

For Stytch's customers, this automation ensures that all of our SDKs will be kept up-to-date and if we find a way to improve one, we can easily make that improvement in all of them (a rising tide lifts all boats). Beyond the immediate impact of freshening up these backend SDKs, this work also allows us to automate parts of our changelog by detecting when methods, fields, or even documentation gets updated.

Takeaways

There are many reasons why our SDKs don't look exactly like our protobuf definitions (and that's a good thing!), but if we stop to consider what "rules" we've set for ourselves in those SDKs, we can internally enforce that we're consistent in the future.

We now save dozens of hours of engineering time for Stytch developers who don't have to worry about updating every backend SDK whenever they want to release a new method or update an existing one.

Because we were able to push up so much AST generation into the "default translator" stage, generating a new language SDK from scratch only takes about 500 lines of code (including templates).

Looking at the bigger picture of what each of our SDKs did well let us bring those improvements to the other libraries and build a more cohesive set of backend SDKs.

We've had a lot of fun generating "humanlike" code for our backend SDKs, and we hope you enjoy using them! Check out our careers page if solving problems and reading topics like this interest you.

---


# Extending authorization code flows with PKCE
Source: https://stytch.com/blog/authorization-code-flow-with-pkce/

Understand how to enhance security by extending the OAuth 2.0 authorization code flow with PKCE (Proof Key for Code Exchange).

Introduction to PKCE

First things first: it’s pronounced “pixie”, not “P-K-C-E”. Now that you sound like you know what you’re talking about – let’s make sure you can back it up.

At a high level, Proof Key for Code Exchange (PKCE) uses dynamically generated secrets to ensure that the user finishing an auth flow is the same user who initiated it – and not a malicious actor. While PKCE was initially designed for native applications like mobile, it has uses elsewhere – but there are a few key caveats to consider when implementing PKCE in your application.

Why do we need PKCE?

To understand PKCE, we first need a quick refresher on the OAuth 2.0 authorization code flow – the gold standard protocol for allowing an app (the Client) to access another system (the Authorization Server) on behalf of an end user using a short-lived code, or token. 

Clients need to register with the Authorization Server in advance and receive a client_id and client_secret that they will send with their request to the Authorization Server – sort of like their username and password.

The authorization code flow is broken into two main steps:

1. The authorization request

The Client redirects the user to the Authorization Server, and includes their client_id to identify the origin of the request, as well as additional details such as the scope of information they are requesting and a redirect_url

Once the user has granted access, the Authorization Server redirects the user back to the provided redirect_url along with an authorization code.

2. The token request

Once the Client receives the response and the code, they can call the Authorization Server again – this time with both their client_id and client_secret as well as the authorization code returned from the initial request. If successful, this request exchanges the code for an access_token that actually grants the Client the requested access

The reason this is a two-step flow is that the initial request is done via a browser redirect of the user, which doesn’t offer a secure way to authenticate that the request is coming from a legitimate Client. While there are ways that a hacker could intercept the returned authorization code in this browser-driven portion of the exchange, the code itself is useless without the client_secret. Once your frontend receives the code, it can pass it along to your backend, which is capable of making secure, direct requests to the Authorization Server with both the authorization code and the client credentials.

If you’re not a mobile engineer, you’re probably thinking “great, problem solved!” But if you have worked on “public clients” – like native mobile apps or single-page apps (SPAs) – you know that keeping a secret isn’t quite that simple. These apps are considered public clients because the source code of these apps can be viewed by anyone either directly (SPAs) or via decompiling (native apps), which makes it impossible to securely store the client_secret that they need to authenticate during the authorization code flow. To make matters worse, native applications also rely on the operating system to redirect the user back to the application – which is often done via native deeplinks (e.g. myapp://deeplink). However, native deeplinks are not actually uniquely registered to the application and can be easily spoofed to steal the authorization code.

So now you’ve got a client secret you can’t secure, and an authorization code that is easy to intercept. What do you do? Enter PKCE.

How does PKCE work?

The root of our problem is the fact that public clients can’t keep a secret. But what if instead of a single, static secret that needs to be loaded into the app’s source code, we had a dynamically generated secret?

PKCE does just that, by introducing three new fields:

code_verifier: our dynamic secret – a cryptographically random string generated by the Client

code_challenge_method: a hash method (typically SHA256)

code_challenge: the hash of the code_verifier, hashed based on the specified code_challenge_method

These fields are used throughout the standard authorization code flow to prove possession of the dynamic secret and ensure that the flow is finished by the same client who initiated it:

1. The authorization request

The Client includes the code_challenge and code_challenge_method in their authorization request

The Authorization Server stores these values, before returning the authorization code as normal

2. The token request

The Client includes the code_verifier in their token request

The Authorization Server authenticates the request by taking the code_verifier, hashing it according to the code_challenge_method and ensuring that it matches the code_challenge included in the initial request

These small changes dramatically mitigate the risks we laid out earlier by introducing a secret that cannot be pulled from the source code of public apps, and providing a way to guarantee that the client issuing the token request is the same as the client that initiated the start of the flow.



When should you add PKCE?

You can use PKCE to provide more security for your end users any time you have a two-step authorization flow, where the steps are connected via a short-lived token. This applies to the traditional OAuth 2.0 authorization code flow that it was designed for, with use cases such as “Sign in with Google” – but it could also be leveraged to improve the security of other two-step, token-based authentication flows, such as password resets or magic links. While PKCE was designed specifically to address the security issues of public apps, it still provides an extra layer of security for normal web applications to protect against other forms of token interception.

In short: PKCE is an excellent addition to a lot of flows. However, there are some situations where PKCE is more critical than others – and also a few situations where PKCE may cause issues for your end users.

Critical

If you are using native deeplinks to power redirects back to your application, it is absolutely critical that you use PKCE. As mentioned earlier, native deeplinks are not actually uniquely registered to a given application, so can be spoofed to steal the user’s access token. As the React Native docs put it, “deep links are not secure and you should never send any sensitive data in them.”

At Stytch, we enforce the use of PKCE for our customers across all of our two-part authentication flows – OAuth, magic links and email-based password resets – if we detect that the triggering request contains a deeplink (in other words, any protocol that isn’t http or https). (And, if you’re using our SDK for both sending and authenticating a magic link, we will take care of generating and sending the code_verifier / code_challenge for you!).

Strongly Recommended

Even if you are not using native deeplinks, it’s still strongly recommended that you leverage PKCE for mobile flows or other public app use cases. 

Regardless of your application type, adding PKCE to your standard OAuth flows like ““Sign in with Google” is also strongly recommended – as it adds extra security without any downsides.

Recommended, with caveats

As mentioned earlier, while not strictly the OAuth 2.0 authorization code flow, most implementations of email-based token auth flows, like magic links and password reset requests, can also leverage the foundations of PKCE to add additional security to their flows!

However, before you add PKCE to these flows, it’s important to call out that there are certain legitimate use cases where the link driving an email-based flow will be opened in a different context than where the link was requested – which is by design prevented by PKCE.

The most common cause of this is the use of a mobile WebView. For example, imagine a user is on the Twitter mobile app and clicks on a link to your application, opening a mobile WebView of your app, where they then request to log in via magic link. When the user goes to their email app and clicks on the magic link, they will be redirected to your application in their native mobile browser app – not the Twitter WebView they were in when they initiated the request. The browser app they end up in doesn’t know the code_verifier needed to complete the request, and as a result the user’s authentication attempt will fail.



If your application contains sensitive information and has a high risk profile, Stytch strongly recommends still using PKCE and simply asking end users to retry the request from their native mobile browser, which will allow them to both initiate and complete the flow from a consistent client.

For applications without sensitive content, and whose users will often be interacting with the app via another app’s mobile WebView (e.g. news publications, eCommerce sites) PKCE might not be the right fit for your web implementation. In this case, we recommend adding a secondary auth factor such as SMS or WebAuthn for additional security. You can read more details on best practices for adding PKCE to magic link login flows in the Stytch docs.

Isn’t there a simpler option?

Depending on your research, you may have also heard reference to the OAuth 2.0 implicit flow being used for public apps – and at this point, you might be thinking it sounds a lot more straightforward than the PKCE protected authorization code flow.

You’d be correct – it is simpler, but it’s also incredibly insecure and essentially should be considered deprecated as a protocol. The implicit flow solved the lack of secrets in public apps by simply cutting out the whole authorization code exchange, and just directly returning the access_token as a URL fragment of the authorization redirect. This exposes the access token to all sorts of vulnerabilities and for any modern application that supports cross-origin requests (CORS) there is no reason to choose the implicit flow over the more secure authorization code flow combined with PKCE.

Conclusion

If you have a public client (mobile, serverless or single-page), PKCE is an absolute necessity, particularly if you use native deeplinking. However, PKCE can also help strengthen the security of private clients, and at Stytch we strongly recommend adding it to any authorization code flowin order to provide maximum protection for both you and your customers.

---


# What is an enumeration attack?
Source: https://stytch.com/blog/what-is-an-enumeration-attack/

Enumeration attacks are a kind of brute force or credential stuffing attack – the good news is, they’re very preventable.

An account enumeration attack occurs when a bad actor tries to identify valid users, emails, or accounts with an app’s authentication flow. Account enumeration is primarily used to gain information about a system that can be used in further attacks, and does not directly result in compromised accounts. Because it’s most successful when executed at scale, it’s typically performed and classified as a brute force attack.

What are user enumeration attacks?

User enumeration attacks specifically target a user database, and are typically trying to verify whether a specific account exists with a given email, username or other basic user information. At Stytch, this is the type of enumeration attack we’re most concerned with and the ones we work with customers most on preventing.

A note on “user” vs. “account”: You may also find “user enumeration attacks” referred to as “account enumeration attacks,” as the main goal of verifying usernames in databases is in fact to gain access to users’ accounts. Typically, enumeration attacks are working with a list of usernames / credentials from previous breaches, as this makes their work a lot easier. Once an enumeration attack is successful for a particular login, bad actors will then attempt to use those same credentials on the victim’s other accounts.

How do user enumeration attacks work?

In order for account enumeration to occur, your app must expose some information about a user’s state. This most commonly happens on a login window, login form, or password reset page (hence why we at Stytch have thought about it so much!).

Let’s say a bad actor navigates to your application’s login page. If they enter an arbitrary username and password combo, they will typically come away with one of three outcomes:

They will get an invalid username message saying that the username does not exist,

They will get an error message saying that the password is incorrect (confirming that the username exists), or

They successfully log in.

In all three of these instances, the bad actor gets useful information. In the first scenario, they learn which username is not in your database. In the second, they can at least confirm a valid username that is in your database. The third, though unlikely, obviously gives them most of the information they need to take over someone’s account (assuming of course you don’t have other preventative measures in place like multi-factor authentication or device fingerprinting to flag potentially fraudulent activity!).

Because of the unlikelihood of the third scenario, most bad actors are primarily targeting username information with this attack. 

Usually, these attacks follow a very general two-step sequence:

1. Guess existing usernames with brute force

While it would take many lifetimes to manually guess arbitrary usernames and passwords, most bad actors work around this constraint by using bots to automate login attempts, flooding login or password reset pages with potential usernames. If there are no security measures in place to prevent such attacks (often called brute force attacks), they can come away with a fairly robust list of usernames for your application.

Once an attacker has a list of usernames or accounts for your application, they can run more sophisticated and targeted attacks, including:

Credential stuffing: As outlined in step two, credential stuffing is when bad actors flood your login page with potential username/password pairs. Unlike in this step however, for credential stuffing they’re not trying to mine or confirm valid usernames – they’re trying to validate username/password pairs. 

Social engineering: Social engineering attacks involve using deceit to convince a user to give over their account information willingly. These can take place over email, text, phone, or even in person, depending on the information the hacker has available. 

Phishing: Phishing is a specific type of social engineering typically involving an email or text message, usually from an authoritative institution and using a sense of urgency, danger, or high reward to lure the user into sharing sensitive information. 

For more detailed information on these techniques, check out our blog on the top ten password hacking techniques, and how to protect yourself against them.



2. Pair existing usernames with possible passwords

With a list of valid usernames in hand, hackers usually then proceed one of two ways:

They will then “credential stuff” your login page with valid usernames and common passwords, or

They will search databases of leaked username/password combinations and attempt to log in with any matches they find.

If they opt for the first route, they’ll leverage the same exposed information they did in credential stuffing to find valid usernames, only this time with potentially graver results – accessing one of your user’s accounts.

Thinking outside the password box



While a web server database with username/email combinations is the most common type of user database target for enumeration attacks (largely because they are unfortunately still the most common type of authentication), they are not the only potential targets.

One of Stytch’s most popular solutions is – Email Magic Links, and just like with a username/password login page an EML login page can still expose information about the user if a bad actor enters an arbitrary email, which in this case serves as the username. Worst case for them, they discover an email is not in your database. But in their best case scenario, they can discover an email that is in your database, and still leverage that information subsequent attack to phish or compromise the user.

Server response times – enumeration attacks with minimal info

While the most common way to collect valid usernames is by directly reading the messages returned by the application, some more sophisticated hackers will instead monitor the server response time. Usually, servers take more time responding to an invalid username than they do a valid one.

By monitoring server response times instead of the actual message, hackers can deduce whether or not the username is in the database even if a company is obfuscating their user data with a message like “Your username and/or password is incorrect.” Typically, they do this by coopting or misusing common penetration testing tools.

Examples of other complex enumeration attacks



While user enumeration attacks are the most common type of enumeration attack, there are a couple others that are worth being aware of. All three typically rely on specific tooling.

NetBIOS Enumeration

NetBIOS stands for Network Basic Input Output System, and is a protocol used to enable communication between devices over TCP/IP (Transmission Control Protocol/Internet Protocol). It is used only on Microsoft operating systems.

Devices on TCP/IP networks are identified with a 16-character NetBIOS string. When printer and file services are enabled, hackers can perform enumeration attacks to try to derive those strings using specific tools.

If a valid NetBIOS string is discovered, hackers can either then recruit that device to become part of a botnet, or can use it to obtain additional information like a list of the devices that belong to a given domain, policies, and passwords to the TCP/IP network.

LDAP Enumeration

Lightweight Directory Access Protocol (LDAP) is another internet protocol that works on TCP/IP, and is specifically used to store and authenticate specific user information across directory services.

Using specific tools, hackers perform enumeration attacks on LDAPs to obtain ​usernames, addresses, and other contact information.

SNMP Enumeration

Simple Network Management Protocol (SNMP) refers to an application layer protocol that manages IP network routers, hubs, and switches, specifically for User Datagram Protocols (UDPs). You might see this protocol in video playback transmissions or looking up a DNS. SNMP agents run, and are thus only vulnerable to attacks, on Windows and UNIX networks.

Critically, SNMP stores two passwords, one of which is always publicly available, and thus exploitable by bad actors.

Hackers engaging in SNMP enumeration are typically targeting user accounts, passwords, groups, system names, and devices.

The dangers of an enumeration attack

Clearly, user enumeration attacks can be grave, namely in the form of an account takeover. This can be especially consequential if the credentials a hacker obtains through a user enumeration attack belong to an admin or employee of a company with privileged access.

Successful user enumeration attacks could result in:

Identity theft

Intellectual property theft

Fraud

Corruption of database

Breach of regulatory requirements or contractual obligations

While user enumeration attacks are not a particularly heavy target for most non-sensitive consumer applications, apps or services with access to PII (personal identifying information) should be mindful.

Very preventable



In spite of the many different kinds of enumeration attacks that exist, the good news is they’re generally preventable through a variety of methods. Which method is right for your application simply will depend on the sensitivity of the information you’re protecting (i.e., how likely you are to be a target), and where and how much you are willing to introduce friction into your user experience.

Read our next blog to learn about how to prevent enumeration attacks.

---


# How to prevent enumeration attacks
Source: https://stytch.com/blog/prevent-enumeration-attacks/

Learn the best methods for protecting your application against enumeration attacks – while maintaining a seamless user experience.

In a previous article we went over enumeration attacks – what they are, how they work, and what’s at risk.

In this article, we’ll look at how you can protect your web application against these kinds of attacks.

Remind me: what’s an enumeration attack?

Account or user enumeration attacks occur when a bad actor tries to identify valid users, emails, etc within web applications’ authentication flows.

Enumeration attacks are primarily used to gain information about a system that can be used in further attacks, and does not directly result in compromised accounts. Because it’s most successful when executed at scale, it’s typically performed and classified as a brute force attack.

To learn, read our blog on the ins and outs of enumeration attacks.

Best methods for preventing enumeration attacks

Generally, non-sensitive consumer applications carry very little risk from user enumeration attacks. In fact, user enumeration via useful and actionable error messages is often helpful for consumer login flows. For example, telling a user that their login failed because they do not have an account is a better user experience than presenting a generic failure message.

However if your domain is particularly sensitive to security, e.g. government, fintech, healthcare etc, or your application is at a large enough scale, we do recommend you take a few steps to protect your against account enumeration.

Compose your error messages carefully on your login and password reset page

Don’t use error messages that give away key information about why a particular action failed. This applies for both login forms and password reset pages.

For example, if an actor initiates a password reset for an account that does not exist, don’t show an error message. Instead, show a message to the effect of “If an account is associated with that email, a reset link has been sent.”

Again, it’s worth noting that if your message is too vague, it may frustrate users, so it’s up to you to find the right balance between a message that will aid legitimate users and thwart those of ill-intent.

Conceal PII

Don’t expose unmasked Personally Identifiable Information (PII), e.g. only display the last four digits of a phone number in your UI as opposed to the full value.

Show discretion with your user state

Limit how much user state you share with your frontend (user-facing client).

Incorporate multi-factor authentication into your login flow



While the initial impact of an enumeration attack may be limited, the end goal is of course account takeover. One of the surest ways to prevent account takeover is multi-factor authentication.

This means that even if a hacker gains access to a valid username and its matching password, they won’t be able to log in without additional access to other accounts or devices belonging to that user, such as their phone, tablet, or email. The most common types of multi-factor authentication are:

SMS or email-based one-time passcodes (OTP): SMS OTP asks users to enter a unique numeric or alphanumeric sequence (e.g. 123456) sent by text to a recognized mobile phone number or email.

Time-based one-time passwords (TOTPs): Also known as authenticator apps, TOTP asks users to confirm control of their device within a certain time frame via a passcode generated by a smartphone app like Google Authenticator, Authy, Duo, or others.

Push notification via their app: In this option, the app itself sends a notification to a registered and authenticated device belonging to the user, which the user must approve before logging in. Some of the most common of these are Google and Apple push notifications.

Hardware authenticators (e.g. YubiKey): Cross-platform hardware authenticators like YubiKeys enable users to use a hardware device external to their phone or laptop to verify possession of this factor.



Consider auth methods more immune to enumeration

Whether on their own or in addition to MFA, you can also consider primary auth methods that are inherently safer from enumeration tactics:

OAuth: Sometimes referred to as “social logins,” OAuth allows users to log into an application using a 3rd party identity provider without sharing or exposing information about a user’s credentials. 

In-device biometrics: Built-in device biometrics allow users to verify themselves with the same facial recognition or fingerprint identification they use to access their phone or laptop. No biometric data is ever passed to the application, but the user is able to verify possession of both the user’s device and a biometric marker.

Passkeys: While passkeys were recently launched with the goal to replace, not supplement, usernames and passwords, they are a powerful new login method that elides the pitfalls of usernames and passwords by leveraging cryptography and biometric information together. This makes them a great anecdote for enumeration attacks. Learn more about how passkeys work on our blog.

Randomize server response times



As we mentioned in our last article [insert link] an enumeration attack need not even read an invalid user username message to deduce whether or not a username exists. Instead, hackers can simply monitor server response times, as the response time for an invalid username is usually much higher than for a valid one.

An easy way to thwart this type of enumeration attack is by randomizing server’s response times, so that there’s no correlation between them and valid or invalid username entries.

Reduce login attempts with rate-limiting, CAPTCHA, or device fingerprinting



Enumeration attacks are only feasible for most hackers if they are able to execute vast amounts of login attempts. As we mentioned in our last article, even failed login attempts help them deduce information about a user database.

There are three main ways to limit login attempts to web applications:

Rate limiting: Rate limiting limits the amount of times a user can take a specific action within a designated time frame.

CAPTCHA: CAPTCHA tests give the user agent tasks that only a human being should be able to complete. By design, they should help stop automated enumeration attacks then by identifying and stopping bots in their tracks – but they still have a few loopholes.

Device Fingerprinting: Device fingerprinting identifies the devices that access a website or application by tracking a given set of device attributes, IP address, browser brand and version, operating systems (OS), and more.

Got more questions? Stytch can help.

At Stytch, we pride ourselves on being an identity platform that’s powerful enough to meet your toughest security requirements, while adaptable enough to fit any app’s stack, use case, and scale.

From multi-factor authentication to fraud and risk tools like sophisticated device fingerprinting and Strong CAPTCHA, our identity platform has everything you need to secure and scale your app.

---


# Open-sourcing SQX, a way to build flexible database models in Go
Source: https://stytch.com/blog/open-sourcing-sqx-a-way-to-build-flexible-database-models-in-go/

Open-sourcing SQX, a way to build flexible database models in Go

Mapping between database rows and in-memory structs can be difficult. Dozens of solutions are available across a plethora of design patterns. Today, we’d like to talk about how we handle this common problem at Stytch using a lightweight approach and our SQX library.

We’re excited to show off SQX, which we’ve just open sourced (available here). We’ll show you the approach we use to keep our code reusable, testable, and easy to maintain and how the SQX library eliminates most of the boilerplate code from the process.

Queryables and Widgets

The first thing we want to talk about is the sqx.Queryable interface (defined here). This is an interface for dealing with databases that allows us to use a sql.DB, a sql.TX, or even our internal db.DBConnector, which is a special interface with additional functionality built on top of a sql.DB object. The important point is that most models don’t care what kind of reference to a database they have – as long as it’s queryable.



Next, let’s take a look at the model we’ll use for our examples. We’re going to be showing examples from our test Widget class (code):



Although it’s simple, it will allow us to show off why SQX is so powerful and how you can build a fully-fledged model <-> db interaction interface with just a few lines of code.

Create, Delete, and DBWidget

The first two methods we’ll talk about are Create and Delete. With SQX, these methods are one-liners. Note that sqx.ToSetMap() will handle converting our struct into a map automatically. We add just a bit of logic for our own toSetMap() just to make sure that the ID and Status strings have actually been initialized. This prevents us from accidentally writing widgets into the db with empty IDs.



We also include dbWidgetin this example. It’s common practice for us to define a specific interface for dealing with database models. In the case of many Stytch models, we commonly take as input a project_id here, which enforces that all interactions are scoped to a specific project. This is a handy way of ensuring that all filters are scoped to the correct project when doing SELECTs or UPDATEs.



Generic filters and clauses

The next concept we want to introduce is the “filter” (or more generally, “clauses”) that uses nil to represent a clause that should not be applied and any non-nil value as something that should be applied. This is incredibly powerful and allows us to define simple Get and Update methods that can be reused across a variety of applications for a single database model.

Here we can see that we’ve once again added some lightweight checks on top of toSetMap for our use case: in this case, we return an error if someone tries to set a widget status to “Greasy” and otherwise defer to the SQX implementation of ToSetMap.



SELECT One(), SELECT All()

It’s possible to reuse the wdigetUpdateFilter for SELECT operations, too, but for some applications, it may be desirable to intentionally limit the scope of what can be filtered or updated – in those cases, you may want to define separate getFilters and updateFilters. That’s what we’ve done here for Widgets. We add a Get method that allows filtering on Widget IDs and Statuses and a GetAll method that returns all widgets in the table.

Quick note: Since WidgetID in the widgetGetFilter is a slice, it gets translated to a clause like “WHERE widget_id IN (‘111’, ‘222’, ‘333’)” in the generated SQL. This is another feature that makes it easy to define complex queries in very little code.

As a side note, you may be wondering what OneStrict() does. That method will raise an error if more than one result is returned by the underlying query. This is useful in cases where you want to hint to the reader that the query should return exactly one result and otherwise something has gone wrong.

If you instead wanted to create a query that may return multiple results but you only care about one of them, you can use sqx.First()instead of sqx.OneStrict(). Lastly, sqx.One() exists which will log a warning if multiple rows are returned, but won’t completely raise an error.

Testing the code

We’ve just defined a flexible interface to handle any necessary Widget query in under 100 lines of code, which is incredible… but you shouldn’t trust code until you’ve tested it! Luckily, our design allows us to make testing easy. Furthermore, our usage of the Queryable interface will let us use sql.Tx to run a test and automatically clean up data at the end without polluting our local database.

Pro tip: if you ever need to debug something and want to persist the data longer, you can replace your sql.Tx in a test with a sql.DB with no need to change anything else since we built our solution against the genericQueryable interface.

Below you can see an example of how we test our Widget reading ability (the full test code is available here). First we write our simple setupTestWidgetsTable function, which starts a transaction and creates a clean table for all of our testing.



We can use that setup function to then test each Get method along with typical error cases that may arise.



Summary

The SQX library is a powerful tool that simplifies the process of creating flexible database interfaces. This combination of a robust library and well-crafted design patterns enables Stytch developers to efficiently handle database interactions while maintaining code reusability, testability, and ease of maintenance. We’re excited to open source this critical piece of code and see how others can benefit.

---


# Our approach to developer-focused conferences
Source: https://stytch.com/blog/developer-conferences/

We've been making the rounds on developer conferences, and have a few learnings on how to make the most out of them – and have the most fun.

Developer conferences can be a daunting sea of badges, booths, tote bags, and t-shirts with vowel-swapped startup names (Stytch notwithstanding of course). How do you stand out? More importantly, how do you find your target audience and generate valuable conversations and brand recognition?

Let’s chat about how Stytch does it.

Know your audience

The first thing we like to think about when gearing up for a conference is, “Who is attending this event?” The audience at RSA Conference is not the same as the audience at Reactathon or GitHub Universe – and your approach to each should be different.

Even amongst developer focused conferences, the audiences might have differences; frontend vs backend, senior vs junior, security vs product focused. Be as specific as you can about your company’s Ideal Developer Profile (play on the more common Ideal Customer Profile that we use here at Stytch), and make cool stuff for them.

Here are some examples for conferences we’ve attended:

Render

Developers here tend to be more junior

Frontend and mobile developers

More product focused

A lot of consumer focused companies

RSA Conference

Attendees tend to be managers and above

Very security focused

Enterprise heavy

SaaStr

Mix of senior engineers and senior leadership

Both SMB and enterprise

Primarily SaaS companies, a lot of B2B

Does it spark activation joy?

During one of our company-wide hackathons, some folks got together to create a retro themed video game to demonstrate to new employees what Stytch actually does in a hands-on way. We dubbed it Stytchemon.

This game starts you off in a locked room where you must generate a key (a session), by authenticating a One-Time Passcode (OTP). Once you’ve got the key you can unlock the door and play a few different mini-games to earn points and record a high score.



How we built it

Kaboom.js is an awesome open source JavaScript video game engine and as soon as we saw how fun its documentation was, we knew it was a great fit.

We used Kaboom.js to build out the overall game’s structure and leveraged a lot of their great built-in art and game mechanics, though of course we had to add our Stytch Twist™ to some of the characters.



Once we had the game structure in place, we wanted to build out the login flow with our frontend JavaScript SDK to smoothly send an OTP code to either your phone or your email and visually show the API response and authentication that the game gets back from the Stytch API. In real time you see exactly how OTP authentication works for the user and under the hood so that ah-hah moment comes quickly. Additionally, we used our User Metadata feature to store and retrieve the user’s high score and name to display on the leaderboard to show off the flexibility of our API and what you can build with it.



Now that we had authentication working, we built three mini games based on some Kaboom.js examples to play once you’re logged in:

Attack of the Burrito: Shoot the burrito mothership and avoid its alien allies. Spacebar to shoot and arrows to move left and right. Up arrow if you’re a pro.

Find my key: A simple platformer where the goal is to grab as many authentication keys as you can in 30 seconds. Arrows to move, spacebar to jump (and double jump).

Flappy burrito: Flappy bird where you have to avoid the burritos! Space bar to flap.

Burrito aside: You might notice that burritos show up in this game a lot. Part of our company culture is security, we’re responsible for your authentication so everyone within the company always has an eye on security. Part of that is always ensuring that our laptops are always locked when unattended, if they aren’t, your coworker might open up Slack on your unlocked laptop and post a message in #all-general with a burrito themed copypasta. We call this “getting burrito’d”. Avoid burritos at all cost in the game!

And that was it! A super fun hackathon project to learn how Stytch works. You can play it online at https://stytchemon-game.vercel.app/ or check out the source in our GitHub!

Bringing it to a conference

Our team had so much fun playing Stytchemon that we thought it’d be a great idea to polish it up and bring it to a developer focused conference to create some joy and break the ice. Seeing your booth filled with smiles and fun is a great way to draw people in and put them immediately at ease. Striking up a conversation about the video game lets you move past the awkward introduction and build rapport immediately.

An added bonus to Stytchemon was that attendees got a crash course in the Stytch API as they “logged in” and created the key. So even before we’d mentioned a talk track on our marketing prepared battle card, they already understood what Stytch is. Then of course, they get to have fun!

To make sure the game was ready for prime time, we added in a high score leaderboard that we could display alongside the game on another monitor, bought some SNES-style game controllers, and spent a few hours bug bashing and adjusting the difficulty to make sure you could pick it up and have fun quickly.

It was such a hit with attendees and so fun for us in the booth. We’ll definitely be bringing it to more conferences in the future.



Swag; be different

If you’ve attended any tech conferences before, you’ve probably received a tote, a few logo t-shirts, another tote, a stress ball, maybe a hat, and probably a third tote.

We like to approach swag a little bit differently and lean into both our developer focus and team culture to ship creative swag items that grab attention and more importantly start conversations.

Hot sauce

Our team loves hot sauce, we always stock some in the kitchen and it’s a common tradition for folks to bring new and interesting hot sauces to share around the lunch table. We thought, “What about making our own hot sauce and giving it away as swag?”

At RenderATL (an amazing, developer focused conference in Atlanta btw) we launched our first two Stytch hot sauces, a sweet heat Sriracha and a very spicy Louisiana Red. The sauce was a great conversation starter, “How spicy do you like your hot sauce?”, and generated tons of word of mouth buzz, “I saw your hot sauce at lunch, can I get some?”



Learnings? Spicy can be too spicy. Our spicier sauce was a bit too spicy for broad appeal, we’re going to ratchet it down for the next time. Second lesson, keep it under 3oz! We had one attendee lose their hot sauce to the TSA on their flight back.

Visit us at QCon in October for the next hot sauce drop

Wearables

Just slapping your wordmark on a water bottle or tote doesn’t really cut it in today’s developer communities. We’ve found that being a bit more creative, relevant, and putting thought into the swag that we bring to conferences drastically increases the brand awareness and recognition value of what we create.

It’s not just a hat

Let’s take a look at the hat that we brought to RenderATL. Just a baseball cap with Stytch on the front? Absolutely not; it was created specifically for RenderATL and the audience there. RenderATL had themes for each day and one of the days was tie-dye day. We figured some folks might not have tie-dye in their closet, so let’s make sure they have some to wear by making a tie-dye bucket hat.

But what else can we do to make the swag even more relevant to the audience? These are React developers, what about an npx? We embroidered npx login-with-vibes on the front of the hats to lean into that developer focus and good vibes that Atlanta always brings.



And of course, that npx command has to be functional and fun right? Try it out in your terminal! 

Whatever you create and give away to prospects, it should feel like it is a part of your brand and also be at least one of the following:

Fun: The signal to noise ratio at these conferences is low. The more memorable and delightful you make your experience, the more likely you are to make a lasting impression. 

Actionable or useful: What do you do with your nth free keychain? You likely throw it in the trash. The npx command may not have been a practical auth tool, but it gave devs something to do in the moment without weighing down their tote bag. 

Relevant: This last one cannot be overstated. But know that there are various degrees of relevance. If you’re going to a “developer conference,” one would hope the lowest bar you clear is having swag and/or activation that is relevant to developers generally. But better if you can tailor it even more specifically to the specific crowd of developers the conference in question attracts. 

TL;DR – consider your brand and audience closely, and build for them!

Generate conversations, not leads

Though your marketing or sales team might be responsible for the operations of the conferences, at developer-centric conferences, developers want to talk to other developers. We always like to bring folks from our EPD teams (Engineering, Product, and Design) to make sure that our booth staff create valuable conversations with visitors and our booth isn’t just a lead gen mill.

Maybe a backend developer is visiting your booth and has always struggled to communicate how their auth system works to their designer. Having someone from our design team, who lives and breathes auth, at our booth might spark a great conversation that helps the developer work more smoothly with their designer.

In the same vein, don’t be afraid to dive deep; developers love talking about hard problems they’re facing and finding out exactly how your product works. Gloss can help sell your product to the C-suite, but very often we find ourselves cracking open the browser console or an IDE with developers to talk through exactly how cookies work in our JavaScript SDK or what Passkeys actually does under the hood.

People remember great conversations, they don’t remember having their badge QR code scanned. Having a diverse set of teammates and skill sets at your booth lets you create more meaningful interactions and lasting, positive impressions with attendees. If you do it right, nobody needs to follow up on your leads list, the leads will contact you.

Going to any of these conferences? Drop by our booth(s)!

QCon: Oct 2-4

Authenticate: Oct 16-18

Going to a conference that you think we should be at? Drop us a line at support@stytch.com or join our Slack community!

---


# How to manage Auth0’s rules and hooks deprecation: a shift towards actions
Source: https://stytch.com/blog/auth0-rules-and-hooks-deprecation-disadvantages/

A look at how Auth0's recent decision to deprecate rules and hooks could hurt developers and end users – and what you can do about it.

Auth0, a widely-used customer identity management platform, recently made a significant announcement that directly influences their clients and partners when they announced they will be deprecating the popular Rules and Hooks features. Instead, they’re focusing on unifying all extensibility features under a single segment, known as Actions.

Unfortunately, many customers still depend on certain Auth0 rules that aren’t supported in Auth0’s actions feature, which means navigating new ways to ensure their application’s authentication works as intended.

In this blog post, we’re going to go through the logic behind Auth0’s decision, the potential fallout for their customers, and possible alternatives available with Stytch.

Background, timeline, and current resources

What were rules?

Auth0’s Rules is a serverless function engine that lets developers insert custom JavaScript code during the authentication process. Given that the Universal Login is hosted, businesses using Auth0 have less direct control over the authentication process. Rules enable them to inject specific logic into this process, such as adding user profile enrichment, enforcing multifactor authentication, or implementing fraud detection.

Why is this happening?

While unpopular with many developers that rely on Auth0’s Rules and Hooks, the aim of this move is to rearchitect its extensibility offering as Auth0 is integrated into the Okta identity platform. Indeed, Okta’s acquisition of Auth0 has been implicated in several noticeable shifts in Auth0’s platform, from day-to-day customer support to larger changes like supported features.

When is this happening?

The deprecation process will start with the gradual removal of Hooks access from new tenants and customers. Existing customers will start experiencing this change starting October 16th, 2023. The final end of life for Rules and Hooks is slated for November 2024 for all customers.

Auth0 made this deprecation announcement roughly eighteen months ahead of the final end of life in order to provide users sufficient time to handle the migration process. During the transitional phase, existing tenants using Rules can expect only maintenance support, and all Rules will be fully removed from all tenants by November 2024.

What support is available?

Clients and partners currently using Auth0’s Rules and Hooks features are encouraged to migrate to the Actions feature as soon as possible. To assist in this transition, Auth0 has provided migrating documentation to facilitate the shift from Hooks to Actions and from Rules to Actions. The online resources include an Actions demo, and a ‘Move to Actions’ page that explores feature comparisons, etc.

Deprecation Concerns

Despite migration resources like those described above, we’ve consistently heard concern from current Auth0 customers about certain limitations present in the new Actions feature, especially pertaining to Actions’ technical limitations that are as of yet either unaddressed or unresolved.

Those concerns involve account linking limitations, access to customer IdP attributes, custom claims and apps metadata access, and data from third-party IdPs.



1. Account linking limitation

Actions, in their current state, do not support account linking. Account-linking is a pivotal feature for many businesses that enables seamless sharing and unification of data across multiple user accounts. The absence of this feature from Actions introduces a substantial obstacle for those currently relying on Rules for this functionality.

2. Access to customer IdP attributes

Users have reported that the event.user object in Actions does not include all the custom Identity Provider (IdP) attributes. This limitation can disrupt the user information flow and authentication process as many organizations require all user attributes for application safety and smoother functionality.

3. Custom claims and app metadata access

There are specific cases where users need to map custom SAML (Security Assertion Markup Language) attributes into a user’s app_metadata. This handling is only possible via Rules and not supported in Actions. Losing this functionality poses a challenge for migration as it limits application-to-application user data transfers, crucial for understanding user roles and claims.

4. Data from third-party IdPs

Some users have used Rules to pass data from the access token received from a third-party IdP into the access token generated by Auth0. Currently, there’s no known method to implement this with Actions, which might disrupt user access and role management.

As the migration continues, addressing these technical impediments is of utmost importance to ensure a smooth and problem-free transition for all Auth0 users. While Auth0 has pledged ongoing support throughout the process, addressing these gaps is critical to the shift to Actions satisfying customers’ needs fully.

The decision to deprecate Rules and Hooks is clearly a significant one, reflecting Auth0’s aim to streamline and centralize their features. It’s a bold move, and although it’s caused some concerns, only time will tell whether it’s the right decision. Meanwhile, users of Auth0 that are finding limitations can consider alternatives to Auth0 like Stytch, which integrates auth more tightly with your application to eliminate the need for rules, hooks, or actions.

Stytch vs. Auth0

Unlike Auth0, Stytch is an embedded authentication solution. This means logic that in Auth0 lives within Actions instead lives in our clients’ own backend services, allowing for a tighter integration between your application and your auth logic. This has the added benefits of being able to version control and better test your logic, instead of having to go into the Auth0 dashboard.

For development teams eager to build, troubleshoot, and deploy quickly, the visibility and control of a backend-based system means a lot less time futzing with widgets, and more time spent shipping. Out of the box, Stytch abstracts away most of the complexity that comes with the Auth0 Rules and Hooks deprecation (e.g. secure account deduplication, IdP attribute access, etc.).

On top of our embedded authentication solution, Stytch also offers powerful features like device fingerprinting, a comprehensive suite of authentication products and account takeover prevention, and extra-mile infrastructural features like account deduplication and provider failover that boost your product’s reliability and scalability.

Learn more about how Stytch stacks up to Auth0, or get started building for free today.

---


# So you want to write an Engineering career ladder?
Source: https://stytch.com/blog/engineering-levels/

So you want to write an Engineering career ladder?

So, you’re a founder, engineering manager, committee member, or other person/entity/collective that’s interested in introducing levels to your small (but growing!) company’s engineering team. Awesome! The good news first – there’s a ton of information available to you on the internet, including companies like Square/Block that have effectively open-sourced their ladders. The bad news is there’s a lot of nuance in when and how you roll out the framework to your team, and not a lot of guidance in that area.

While almost nothing is truly irreversible, levels are pretty damn close – they can be adjusted after the fact, but there’s no way to really roll them back once they’re out. Because of this, rolling levels out can seem daunting or scary, but it really shouldn’t be. In fact, if you’re reading this blog post, and others on the subject, and thinking “hey, maybe it’s time to start thinking about levels for my team”, well…



Let’s take a look at some of the considerations you should be thinking about before you present your shiny new framework to your team.

Why have levels at all?

Chances are you have some idea of what levels provide your team – but let’s make that explicit. What levels really do is make three things formulaic:

Expectation setting – Clear expectations aren’t just helpful for managers – they’re important for your reports too. Nobody likes to be in a position where they don’t know what they need to do, and how they’re doing. Levels make it easy to be explicit about these things, and gives you a repeatable framework to bring into performance conversations and career development. It’s honestly the biggest advantage you get from levels.

Compensation – You probably already have rough bands, with more experienced engineers sorted into the upper end of them. Great. Just like above, levels make them explicit, and allows you to easily compare engineers to ensure fairness, as well as design formulaic performance and tenure bonuses based on level.

Hiring – There’s really two aspects here, one is already covered: compensation. Properly written, levels allow you to sort a new hire into a band and write a fair offer for them. But they also allow you to easily plan headcount. – With levels, you can easily plan team composition and move budget around as needed.

The thing is, you can technically do all of this without levels. You probably already do – but you have to do it on a case-by-case basis. This is complicated, time consuming, and ultimately unnecessary. You may even be tempted by a flat org – hiring all seniors and holding them to the same expectations ala Netflix. Let me dissuade you – there’s enough variance in experience and aptitude in “senior” engineers that you’re really asking for trouble later on, as Netflix itself is finding out.

Better to roll out levels too early than too late

Levels clearly have advantages, but you might be thinking about some of the bad things that can happen: engineers focused on ladder-climbing instead of doing what’s best for the company, engineers afraid to speak their mind because a more senior engineer ‘outranks’ them, and a myriad of other possibilities. Levels are tied to compensation, so it’s natural that you’re going to run into some of these issues.

It’s easier to manage these concerns when your company is still on the small side. At smaller sizes, you can personally talk to all the individuals on the team and make sure they understand the intention behind levels and your framework. You can (and should) also get input from individual engineers as well as managers during the process of creating levels, which builds buy-in and ownership on your team. With big teams, you’ll need to be more selective of who you involve in the process just out of ability to manage the group size.

Ultimately, the longer you wait, the more it will seem like a Big Deal, and you will have far fewer opportunities to work one-on-one with the actual humans who are impacted by the change. In worst case scenarios like the one I mentioned with Netflix above, you have to deal with nasty organizational debt that frankly isn’t correctable – people will leave.

So how small is too small, and how big is too big? I’m not going to pretend I have a hard and fast answer here, but at 10 engineers, levels are a distraction. At 100, they’re a godsend. At Stytch, we rolled out levels when the company was around 50 people, with roughly 20 engineers, which is on the early side. At the end of the day, you know your team best, and should pick a stage before it becomes untenable to manually handle the things – namely, compensation and expectation setting – that levels take care of for you.

I described our early rollout to our team with the analogy of buying slightly-too-big pants for your growing kid – you can always wear a belt (in the case of this questionable analogy, context provided by your manager) while you grow into them.

“It’s all about impact”

This is the first sentence you see when you open Stytch Engineering’s career ladder. It’s probably the most opinionated feature of Stytch’s engineering ladder – we don’t require engineers at a given level to check all the skill boxes at that level. What we DO require is that engineers are able to personally deliver impact consistent with their level. This does a few things:

1. It helps hedge against some of the aforementioned things that can go wrong with levels.

If you don’t require everyone at, say, L5 to exhibit the exact same skillset, you prevent resource starvation and the bad things that come along with it. This includes things like fighting over the exec darling or technically challenging projects that are viewed as a path to promotion, etc.

2. It allows engineers to build their superpowers.

Much has been written on the subject of staff engineering archetypes, to the point where there are literal books on the subject, but realistically all engineers, regardless of level, have unique shapes and skillsets, especially if you’re hiring for spikes (and if you’re not, you should be). Focusing on their level of scope and ownership (e.g. impact) gives engineers the breathing room to achieve that in a way that makes sense to them as individuals. 

For example, one L5 may develop and roll out an incident process that ultimately gets adopted by other engineering teams, another may find and fix a complex cross-system bug impacting our largest customers, and yet another may lead a team shipping a critical product or initiative for their team. As long as they’re producing consistent outcomes consistent with their level, the ‘how’ is much less important – this ultimately gives engineers and their managers the leeway to keep a team collectively engaged and excited about what they’re working on.

3. Designing a ladder for outcomes over skills gives you some flexibility in writing the ladder.

Instead of having to be super dialed or prescriptive about an exact set of skills, you can ship and iterate on a lighter, more outcome-driven ladder first that can grow with your team and product as they mature. In fact, I’d argue that you don’t know what skills you want to highlight right now – your team and culture are still growing, and you don’t want to make the mistake of leaning too heavily on skills that may not scale with you. You can always change the ladder, but you can’t change the impact on culture and hiring that they’ve had in the meantime.

Don’t try to get creative

Good management is boring. Of all the things that managers do, creating systems and frameworks might be THE most boring. This isn’t a bad thing – people are going to people, and consistently surprise you in both good and bad ways. Your job in creating a framework is to provide enough wiggle room for interpretation to maximize the former, and enough structure to minimize the latter. 

The good news is that engineering career ladders are almost approaching an industry standard, with more and more companies adopting the L3-8+ levels popularized by Google and Meta (give or take some seasoning to taste). Levels.fyi is, of course, a good resource for benchmarking your comp bands, but also for exploring where various companies set their levels – you can infer the width of a level by how wide the comp band is. Numerous companies, as mentioned, have effectively open-sourced their levels and the methodology behind them: – Square, Carta, Gitlab, and many, many others are available for you to peruse, be inspired by, or steal borrow from.

Whatever you do, don’t start with a blank slate. Take the impact-first approach Stytch chose – this isn’t even unique to Stytch! While we arrived at this conclusion independently, this is exactly the same premise companies like Carta and Honeycomb have based their ladders on. Not convinced yet? There’s two more big advantages:

When you hire someone, they already roughly understand your levels. This is a huge win for both managers, who you can immediately speak a common language with, and engineers, who immediately understand what’s expected of them. Uber recently re-leveled Senior II and up to better align with the broader industry for this exact reason.

If something breaks down, you have resources. There’s a goldmine of blog posts (not to mention industry gossip on Quora and Blind) talking about career ladders, and the problems and solutions people have encountered as theirs have evolved. The more you go off the beaten track and forge your own destiny, the less help you have to fix it. – that vintage 1978 Porsche you’re eyeing sure looks cool, but when it breaks down, you’re going to be wishing it was a Honda instead.

The big irreversible decisions

Most of you are probably familiar with some decision-making framework highlighting the importance of paying attention to irreversible decisions. In developing a career ladder, there’s really only two in my mind – promotions and level visibility.

Promotions

Really, your decision here comes down to whether you promote as a lagging indicator (e.g. you’re already doing the job) or as a leading indicator (e.g. your manager is reasonably confident that you can do the job).

In my mind, the only choice is to promote as a lagging indicator – this is almost an industry standard at this point. If you promote as a leading indicator, engineers might be happy at first (they get the promotion earlier!) but might change their minds when they realize that their expectations have increased significantly in the next performance review cycle, and find themselves scrambling to even scrape by with an average review. Don’t make this mistake.

Level visibility

This is another deceptively simple binary decision is whether or not your levels are public internally, or not. The big advantage to public levels is that folks understand concretely what the next level looks like by just looking at an engineer at that level. I’m sure you can think of all the disadvantages, though – comparing yourself to others at your level and above, being intimidated by ‘higher ranking’ engineers, getting upset when a peer is promoted and you aren’t…the list goes on.

At Stytch, we decided to make levels private, which is consistent with the majority of companies in the industry with levels. This was actually not a popular decision among engineers on the team, but I’m still a firm believer it was the right one. I’m not convinced just yet that we’ll want to keep levels this way permanently, but we do have the option to make levels public at a future point – the inverse isn’t true, which makes this a logical starting point in my mind.

It’ll all be OK

So if you do all the things I mentioned above, can you roll out levels completely problem-free? Absolutely not. Maybe an engineer won’t get the level they wanted, or will be disappointed you’re rolling out levels because it’s a sign of Big Company things to come. Maybe an EM will struggle with a skill ladder they feel doesn’t fit their team because it’s too backend or product-heavy.

This is all normal! Remember, it’s a human system written by humans. As long as you’re willing to put in the work to invest in your system, and provide the context needed to interface with it, you’ll get through the initial pain points and have a system in place that should pay immediate dividends the next time you go through a review cycle or sit down to build a career development plan with someone. Remember, you’re going to have to pay these costs at some point, and the longer you wait, the higher the price.

Just do it – you’ll be happy you did!

About me

Hi, I’m Judd – I lead Engineering at Stytch. I’ve been programming computers since I was in the 3rd grade, and working in the industry for 15 years – somewhere along the way my love of systems and people combined, and I’ve morphed into one of those weirdos that is actually passionate about (shudder) management. I’m a big believer in the power of people, and building frameworks that let excellent engineers be excellent. When I’m not working I have an assortment of unreasonably expensive and time consuming hobbies – including (but not limited to) cycling, hifi and collecting records, cooking, art, interior design, wine, and probably more I’m not thinking of. I live in SF with my wife Dayna and my sheepadoodle Maisie.

---


# Evaluating Auth0 alternatives for authentication and authorization
Source: https://stytch.com/blog/auth0-alternatives/

Evaluating Auth0 alternatives for authentication and authorization

Auth0 is a popular auth provider offering numerous authentication methods and access management features.

Founded in 2013, Auth0 became a popular user authentication choice over the past decade. Since being acquired by Okta in 2021, however, many developers have grown frustrated with the platform.



Reasons to consider Auth0 alternatives

There are several factors that spur developers to search for Auth0 alternatives.

Limited UI/UX flexibility

Auth0’s Universal Login offers few customization options and requires a redirect to their domain, affecting user experience and lowering conversion rates.

Their authentication logic also doesn’t sit within your application’s backend, which results in a heavy reliance on Auth0’s Actions. But because actions don’t easily allow for a lot of the things developers want to do, they end up having to write a lot of extra code to get their auth flow to function the way they want.

Lacking fraud prevention

Auth0’s fraud detection is basic, so depending on the sophistication of bot attacks your app faces, an additional security vendor might be necessary. This increases complexity and costs.

B2B limitations

Auth0’s approach to B2B multi-tenancy is not comprehensive, posing challenges for complex, scalable authentication needs. Based on a user-first rather than an organization-first data model, Auth0’s single sign on design makes it difficult to manage the growing enterprise requests for bespoke, org-specific auth settings as you scale.

Rising costs

Since its acquisition by Okta, Auth0’s pricing has continuously increased, becoming a growing concern for cost-sensitive businesses. There is also often a significant price jump to their enterprise plan, posing a challenge for growing businesses.

Feature gaps

Auth0 lacks conversion-focused, B2C features like Google One-Tap and WhatsApp OTP. Their user-first B2B data model, as mentioned above, also means you’ll likely need to spend time building enterprise-level customization features on top of your Auth0 integration.



Types of authentication solutions

Depending on your team’s use case, there are two types of authentication providers to consider.

Managed service

Managed services, like Stytch or Auth0, come with built-in best practices that save developer time and increase security.

By taking care of features like multi-factor authentication and fraud detection, managed services allow developers to focus on their core product while passively benefiting from compliance readiness and ongoing updates.

Open source

Open source identity and access management solutions like Keycloak allow developers to self-host their own auth solution. Although well-priced and fully-featured, the developer lift is heftier as you’ll need to bring your own database and manage ongoing provider updates.

Popular Auth0 alternatives

Below we’ve gathered four of the best alternatives to Auth0 (note: these are all managed services).

Option 1: Stytch



Stytch is a developer-focused customer identity and access management platform. Our infrastructure, fraud/risk suite, and account takeover-resistant authentication enable your company to build and manage secure access for B2C and B2B user management use cases.



As an identity and access management solution designed for both startup and enterprise, we offer scalable user management for businesses at all stages.



Whether you need passwordless authentication, social logins, multi factor authentication, single sign on multi-tenancy controls, or a more bespoke auth flow, Stytch’s SDKs and API can be used alone or alongside Device Fingerprinting that provides fine-grained traffic shaping and bot mitigation.



Key features of Stytch

Comprehensive auth and fraud: Stytch offers both user management and advanced bot mitigation capabilities. This means that developers can use Stytch in three ways – auth, fraud, or auth and fraud.

Flexibility to build for your use case: Customizable frontend SDKs and core APIs for custom-built UI flows and headless SDK methods.

Future-proof infrastructure: Infrastructure with 99.999%+ uptime SLA, SMS/email provider failover, and account deduplication are built to handle customer growth.

Consumer-centric B2C features: Passwordless authentication, passwords, social logins, Google One-Tap, and Whatsapp OTPs help seamlessly onboard and convert users.

Comprehensive B2B features: Our B2B platform includes single sign on with multi-tenancy and organizations built into the data model. It also includes just-in-time provisioning, discovery flows, enterprise onboarding, and self-onboarding features.

Because we’ve built our data models organization-first, it’s easy to customize single sign on requirements and flows on an organization-by-organization basis, as can be seen below.



Advantages over Auth0

No need for external security vendors: With a Device Fingerprinting product that rivals industry leaders, Stytch’s comprehensive auth and fraud solution means one less vendor to manage.

Greater UI/UX control: Build a native auth experience without redirects to Auth0’s domain.

Scalable pricing with more features: If you are concerned about rising costs, Stytch pricing does not include the same price jump to enterprise plans as Auth0’s does and includes more features across the board.

Shortcomings

Less out-of-the-box: Although we find that developers value the control from Stytch’s API-first model, if you’re looking to get basic authentication up and running quickly, Auth0 can be dropped in quickly, so long as you don’t need to customize.

Self-implementation for uncommon MFA: Auth0 supports push notifications, voice call, Duo, and recovery code multi factor authentication on enterprise plans, whereas those features must be self-implemented on Stytch with our API.



Conclusion

If you’re looking for an expertly-designed auth and fraud platform, Stytch is an excellent Auth0 alternative. Check out our Stytch vs. Auth0 side-by-side for feature comparisons.

Option 2: Amazon Cognito



Amazon Cognito provides identity services for applications hosted on the AWS ecosystem. It offers functionalities like user registration, authentication, and user data synchronization across devices. As an AWS offering, Cognito seamlessly integrates with other AWS services, offering a unified solution for developers deeply invested in the AWS stack.

Key features of Amazon Cognito

AWS Integration: Cognito offers tight integration with the AWS ecosystem, with advantages like single billing and native support for AWS-based apps.

Scalability: Built to handle AWS-level scale, Cognito is suitable for applications expecting rapid growth or high user loads.

Customization: While not as flexible as Auth0 in terms of user interface customization, Cognito does offer some customization for workflows.

Identity Pools: Provides the ability to federate identities from social identity providers like Facebook, Google, and even enterprise identity providers via SAML.

Security: Strong security measures, including multi-factor authentication and encryption, although less focus on specialized fraud detection tools.

Advantages over Auth0

Cost-effectiveness: Generally less expensive, especially for businesses already utilizing other AWS services.

AWS Ecosystem: If your application is built around AWS services, using Cognito simplifies the architecture and potentially reduces latency.

Shortcomings

Minimum Flexibility: Cognito is not as developer-friendly as Auth0 when it comes to customizing authentication flows or UI.

Minimum Focus on Fraud Detection: While Cognito offers basic security features, it doesn’t have as robust a set of fraud detection capabilities as Auth0.

Conclusion

Although both Amazon Cognito and Auth0 offer robust solutions for managing user identity, the choice between the two often boils down to the specific needs of your application and your investment in the AWS ecosystem. Auth0 offers greater flexibility and specialized fraud detection tools, whereas Amazon Cognito excels in scalability and AWS integration.

Option 3: Firebase Authentication



Firebase Authentication is part of Google’s Firebase platform, a suite of services designed to help build mobile and web applications. Firebase Authentication aims to make it easier to add secure sign-in features to your web and mobile applications too, supporting a variety of standard identity providers like Google, Facebook, and Twitter, as well as email/password and phone number authentication.

Key features of Firebase Authentication

Platform Ecosystem: Being a part of Google’s Firebase, Firebase offers seamless integration with other services like Firestore, Analytics, and Cloud Messaging.

Client-Side Focus: Designed with a client-side architecture in mind, Firebase is particularly well-suited for mobile and web applications.

UI Libraries: Comes with ready-made UI libraries for common authentication tasks, making it easy to get up and running quickly.

Social Sign-In: Supports a variety of third-party identity providers right out of the box.

Security: Offers basic security features like multi-factor authentication and account recovery.

Advantages over Auth0

Simplicity: Generally simpler to set up and integrate into mobile and client-focused applications.

Cost: The free tier is generous, making it a good choice for startups and smaller projects.

Google Ecosystem: If you’re already using other Google services, Firebase Authentication integrates seamlessly.

Shortcomings

Limited Customization: Not as customizable in terms of authentication flows and user experience compared to Auth0.

Enterprise Features: Lacks some advanced enterprise features like detailed auditing and specialized fraud detection.

Server-Side Limitations: Less suited for server-to-server authentication compared to Auth0.

Conclusion

Firebase Authentication is an excellent choice for projects that benefit from its simplicity, client-side focus, and integration with other Firebase services. However, Auth0 offers more depth in customization, enterprise features, and server-side capabilities.

Your choice between Firebase Authentication and Auth0 will depend on your specific needs, whether you prioritize ease of use and client-side features, or require more complex, customizable authentication solutions. Understanding the unique selling points of each will help you make an informed decision on an access management solution that aligns with your application’s requirements.

Option 4: Ping Identity



Ping Identity is an enterprise-focused identity management solution that offers single sign on, multi factor authentication, and API security among other features. It’s designed to offer a secure, seamless experience for both internal and external users, bridging the gap between various application types including legacy, cloud, and hybrid applications.

Key features of Ping Identity

Enterprise Focus: Designed to meet the stringent requirements of large organizations, offering advanced compliance and governance features.

Identity Governance: Includes a full suite of identity governance tools, something often lacking in competitors like Auth0.

Wide Range of Integrations: Extensive out-of-the-box integrations, including support for older, legacy systems.

API Security: Strong focus on API security, making it a suitable choice for businesses with extensive API integrations.

Customization: High level of configurability, allowing businesses to tailor the service to meet unique requirements.

Advantages over Auth0

Enterprise Readiness: Well-suited for large organizations with complex governance and compliance needs.

Holistic Identity Governance: Provides a comprehensive set of digital identity governance tools for full lifecycle management of user identities.

Legacy Support: Better equipped to handle businesses running a mix of legacy and modern application architectures.

Shortcomings

Complexity: The enterprise focus means it can be overkill for smaller businesses or simpler applications.

Cost: Generally more expensive, particularly for smaller businesses that don’t need all of the enterprise-level features.

Learning Curve: Due to its extensive features and focus on enterprise-level customization, it may have a steeper learning curve compared to Auth0.

Conclusion

Ping Identity is an identity and access management solution that caters to large organizations with identity governance, compliance, and single sign on requirements.

If you are a smaller company that doesn’t require an enterprise-level, robust solution, however, you’re better off choosing a developer-focused identity platform that can be quickly and easily integrated.

In summary

When evaluating authentication providers ten years ago, Auth0 was the default choice. But today, developers have more customer identity and access management providers to choose from.

If you’d like to explore all the features of Stytch, in particular, click here start building for free.

---


# What is a JSON web token?
Source: https://stytch.com/blog/what-is-a-json-web-token/

Learn about JSON web tokens: what they are, how they're used, and the pros and cons of using them to manage authentication.

A JSON web token (aka JWT, pronounced “jot”) is an open standard that securely relays information between clients and servers as a compact, self contained JSON object.

So, what exactly does this mean?

JSON web token uses

Secure communication

At a fundamental level, web applications pass data back and forth between the client and the server. JSON web tokens are a form of secure communication between the two.

Think of receiving a card in the mail from your aunt. The envelope is sealed, so you know that she chose this dog in a party hat, and you received the message (happy birthday!). Now you can send your own thank you note back to her. A successful exchange of information in tamper-evident containers.

In the case of online communication, JWTs can be thought of as the signed card, the sealed envelope, and the sender’s information on the envelope all in one.

Authentication and authorization

Authentication and authorization are two specific, related types of data exchange. 

Authentication is the process by which applications verify a user is who they say they are, while authorization is the process by which applications verify what that user is or is not allowed to do and access within an application.

When a user successfully logs in to your application, an API call is sent from their user object to the client’s authentication server. That initial API call includes login credentials (core to authentication), which are typically tied to specific access permissions (core to authorization). Once the user is in, however, subsequent API calls won’t include those login credentials or permissions – how does the client know it’s still them, and what they’re allowed to do within the application?

JSON web tokens are a fast, efficient way to answer those questions securely – they keep users in an authenticated state while dictating how they are authorized to engage with an application (i.e., permitted actions, routes, etc.).

Structure of a JSON web token

JSON web tokens include three parts: the header, the payload, and the signature, each a Base64Url encoded string. The final output is formatted like this: header.payload.signature



Header

The header contains two parts: the type of token (here it’s a JWT token) and signing algorithm (commonly a HMAC SHA256 or RSA).



The header is finalized by Base64url encoding the token and signing algorithm.

Payload

The payload consists of one of three claims – registered, public, private – that hold the user’s information.

These claims are the core information that JWTs transmit. The types of claims included in the payload determine which information the JWTs communicate (i.e., user identity, permissions, expiration of JWT, to name a few).

Registered claims are pre-established claims found in established databases like the Internet Assigned Numbers Authority (IANA) and JWT. Using a registered claim ensures your JWTs will operate smoothly across applications.



For example, a subject claim lets you know which user is the subject of the JWT or an expiration claim lets you know until when a JWT can be accepted.

Public claims comprise one of two types of custom claims. Developers create and define public claims themselves and then register the claims with the IANA registry mentioned above to avoid collision.

Private claims are the second type of custom claim. Like a public claim, developers create and define private claims themselves. Rather than publishing them in one of these directories, however, they make local agreements between private parties to ensure operability.



The payload is finalized by Base64url encoding the claim. You can learn more about claims in our article, JWT claims.

Signature

The signature is created by hashing the combination of header and payload with a secret key.



The signature is the JWT component used to verify user identity. A consistent JWT across client requests confirms the API calls come from the same user.

Final output

The ultimate JWT will consist of three Base64Url encoded strings connected with dots:



Once the server has constructed the JWT, it will send the final product to the client to store.

How to use JSON web tokens for auth

Overview

Now that we know what JWTs look like, let’s talk about how to use them. Although JSON web tokens can be used to exchange information in a variety of use cases, at Stytch we value them for their applicability in authentication and authorization.

Between the token’s header, payload, and signature, a JWT can comprehensively verify the user themself, what they’re authorized to do, and the integrity of the data. Storing this user data client side, as opposed to in sessions on the server, is called stateless authentication.

JWTs vs. sessions

You may have seen sessions used to manage similar situations in auth. You can read more about the differences between sessions and JWTs on our blog, but generally the difference can be summed up as follows:

Session-based auth relies on the server to create and maintain a record of a user’s authentication, as well provide a way for the client to reference it on each request.

Step by step

Here’s how a JSON web token is created and used:

The authentication server validates that a user has logged in with correct credentials – hooray!

The server creates a JWT by signing all necessary user information into a claim with a private key.

The server returns the JWT to the user object where it will remain client-side.

The JWT will be included in an authorization header as the user makes additional API calls. This way, when the call comes server-side, the server can decode and verify the signature of the JWT.

The server will validate the JWT. If the claim indicates the token has not expired and that the signature is valid (or, the same as it was in the prior call), the JWT can be trusted to authorize a user.



Pros and cons of JSON web tokens

Zooming out from the mechanics, there are benefits to managing user access with JWTs along with a drawback to consider.

Pro: reduced latency

JWTs hold all information needed for user auth in a small token.

This self-containment eliminates reliance on the server and database, which in turn, reduces latency in the application and the need for server-side storage – a real asset for applications where responsiveness is top of mind for user experience.

The compactness of the tokens also speed things up – all claims are only three characters to keep length short!

Pro: application connectivity

Self-contained JWTs also allow developers to authenticate users across external applications. The signatures and identity information within a JWT allow for server-to-server applications to self-sign and refresh tokens without the user needing to re-enter credentials.

Take OAuth for example. When your aunt bought your birthday card, she logged in to Hallmark’s website using Google OAuth. This means her user information was shared across three servers – her own client server, Google’s server, and Hallmark’s server – in the form of a JWT.

These separate applications passed the token around, securely transmitting information, to authenticate your aunt’s identity and authorize her to purchase your birthday card using information from her Google account, all in seconds.

Con: token revocation

Signed tokens cannot be invalidated or updated. This means that a valid signature in an unexpired token will always allow users to access protected resources.

The effects of the JWT’s independence from the server range from inconvenient to a security threat.

For example, user requests such as “log me out of all devices” or role-based authorization changes will not be reflected until the existing access token has expired. Waiting five minutes (Stytch’s default token lifetime) for these changes to take effect is potentially annoying, but okay.

The real problem comes from compromised JWTs. No matter how quickly you take action server-side, there will always be a lag. This gives bad actors a window where they can act as the user and the only thing that can stop them is the expiration window locked in the token.

This means that JWTs’ greatest asset – its safeguarded information – is also its biggest vulnerability.

That said, there are many security measures and steps companies can take to protect user accounts, while still reaping the benefits of JWTs. To learn more about those, you can dive deeper into our blog comparing JWTs and sessions, and best practices for working with each.

JSON web tokens with Stytch

Stytch’s API and SDKs support JSON web tokens. Or if session cookies alone better serve your use case, Stytch offers this method, too.

Alternatively, you can have the best of both worlds – want the flexibility of JWTs with the security of Stytch’s servers on sensitive requests? This combination is possible with our step-up-auth!

---


# JWT claims
Source: https://stytch.com/blog/jwt-claims/

Learn about the types of user data contained in JWT claims. Registered claims and custom claims (both private and public), explained!

In what is a JSON web token, we explored JSON web tokens (JWTs pronounced “jots”, for short) as a whole. 

In this article we’ll dive into the meatiest part of a JSON web token: JWT claims.

Back up: what is a JSON web token?

A JSON web token is an open standard that securely relays information between clients and servers as a compact, self contained JSON object.

Simply put, it’s a form of secure communication between a client and server.

JSON web tokens’ overwhelming use case is user access management. By storing all user data client-side in the token – specifically as JWT claims – users remain both authenticated after their initial login and authorized to engage with the application according to their role and permissions.

Despite the broad range of claim values possible, all JSON web tokens take the same shape.

Structure of a JSON web token

JWTs include three components – a header, payload, and signature – that work together to store and protect user data.

Each string is Base64url encoded and separated with a dot, so all JWTs’ final form is header.payload.signature.



Read more about the role each JWT component plays in our article, what is a JSON web token?

So, what is a JWT claim?

Now that we know the function of a JWT (secure information transmission) and its core components (header, payload, signature), we’re ready to look at JWT claims.

JWT claims are the core information that JWTs transmit (kinda like the letter inside a sealed envelope).

The JWT claims included in the payload determine which information the JWT communicates (i.e., user identity, permissions, expiration of JWT, to name a few).

That said, developers can include however many claims they want in a given payload. They can also choose the type of claim that makes sense.

Types of JWT claims

JWT claims fall into three categories – registered, public, or private.

A quick formatting note: JWT claims are all three characters long no matter the type. This keeps the JWTs as compact as possible so servers can easily pass them back and forth.



Registered claims

Registered claims are pre-established and publicly documented. Below are the seven registered claims found in the official Internet Assigned Numbers Authority (IANA) and JWT databases:

Issuer Claim (“iss”): which application issued the JWT?

Subject Claim (“sub”): who is the user subject of the JWT?

Audience Claim (“aud”): which application is the JWT intended for?

Expiration Time Claim (“exp”): until what date/time can the JWT be accepted?

Not Before Claim (“nbf”): what date/time can the JWT start being accepted?

Issued At Claim (“iat”): when was the JWT issued?

JWT ID Claim (“jti”): which individual JWT is this?

Using a registered claim ensures your JWTs will operate smoothly across applications. This is because all libraries recognize these common, standardized claims.

Custom claims

Although it’s simplest to use registered claims, sometimes you’ll need to include user information outside the realm of those seven claims.

For example, if you want to store user metadata like email address or phone number, you’ll need to create your own custom claims.

There are two sub-categories of custom claims:

Public claims: Developers define their own claims and register them with the IANA registry mentioned above.

Private claims: Developers define their own claims but do not publish them. Instead, they make local agreements to ensure operability between private parties.

If you decide to register your custom claim, it’s critical that you name it something different than the registered claims. Collisions, in the case of JWTs, occur when a developer creates a custom claim with the same name as a registered term.

For example, if you’d like to associate a sandwich type with each user, you should not name your custom claim “sub.” Another application will read it as the registered “subject claim,” so your JWT won’t convey the user data that you want.



Manage user access with Stytch

Stytch offers the tools to manage user access.

In addition to supporting registered claims and your own custom claims, our JSON web tokens include guardrails such as five minute expirations and automatic fallbacks to Stytch’s API once the local JSON web token expires.

You may have also seen sessions as an access management option. If you’re debating the two, you can learn more about the difference between JWTs vs. sessions on our blog.

---


# Upleveling our SQL models to manage DBT query speeds
Source: https://stytch.com/blog/upleveling-sql-for-dbt-query-speeds/

How our team improved our SQL models to improve DBT query speeds



At Stytch we help developers create secure, defensible user authentication. Developers call our API to authenticate their endusers and prevent fraud and abuse on their applications. We route API request activity into our Snowflake data warehouse to enable our team to track and monitor the growth of our product suite.



Data flows from our application into Snowflake for batch analytics.

Our goal is to ask a suite of analytics questions similar to APIs:

How many customers and total endusers use each API endpoint?

For each customer, how many of their users are authenticating with our different products like Email Magic Links, Passkeys, OAuth, Sessions, or Biometrics?

How are these numbers growing day-over-day, and month-over-month?

Designing our first product analytics pipeline

When we built the first version of our SQL-based product analytics, we chose DBT as our transformation layer to take raw event data and clean, denormalize, and aggregate into the analytics layer stack. From the get-go, we were disciplined about separating the management of raw data from the visualization layer:



We organize SQL models into staging, reporting, and daramarts. This helps us control query performance, data access permissions, and stay organized.

We built the first version of our core product analytics in 2022. At that time, running the entire model pipeline end-to-end took about four minutes. Our SQL queries we’re simple, straight-forward implementations of what we wanted to query:



For example, to get the distinct number of monthly users for each customer and product, we can run a straight-forward count(distinct) on the users. This worked well at first, but as the company and API usage grew, it was untenable to recompute the entire analysis every time.

Using incremental update strategies

We turn to the standard DBT solution to build incremental models, rather than run a full update every time.



This bought us several months of lede time. Now, instead of scanning the entire authentication_events table on each update, we only look at the most recent month worth of data. Using this trick, we were able to manage the steady growth of our SQL pipelines even as we added more data, more SQL queries, and more users building DBT models.

However, we hit a stopping point in September ’23 where leveraging this trick alone was insufficient — some of our query models were taking a long to run even when building incrementally across time periods. We had been leveraging the (very helpful!) DBT model timing chart to optimize queries, but had hit the limit of understanding.



The total time to update our DBT pipeline was growing longer, and being dominated by the slowest queries.

Finding our count(distinct) problem

By 2023, our total pipeline had grown to include over 300 SQL models. We set more query threads in DBT than we have query slots in Snowflake, this helps us unsure that Snowflake is able to immediately start executing a query when a slot is available. Still, when we looked at the query queue pattern in Snowflake, we saw that queries were, in aggregate, spending more time in queue than executing — not a desirable pattern.



Our Snowflake Warehouse tasked with running our DBT pipeline would get flooded with queries. Long-running queries would block the queue, and our incremental updates were taking about 45 minutes to run.

Diving into the Snowflake query dashboard, we saw a revealing trend: many of the queries that spent a long time executing were scanning a large amount of data, but then returning a small number of rows. These queries were the cause of our general slow-down, and generally these queries included a count(distinct) aggregation.



Green bars is time spent executing a query, yellow is time spent in queue.

The issue jumped out at us seeing numbers like 62.13GB of data being scanned for different queries. As our queries are fairly simple, our Snowflake performance is dictated by the time it takes for Snowflake to scan disk and load data.

Our first inquiry was to consider setting Snowflake cluster keys — maybe some of our incremental update strategies weren’t being recognized by Snowflake’s built-in data management systems, and we should provide clustering guidance in our DBT model configuration. However, we were a bit trepidatious to leverage this tool: once we start self administering the data layouts, we’re going to continually pay a human cost of thinking about table layouts when designing and iterating on models. We decided to first explore if there were logical design improvements that could be made to the models themselves.

Optimizing the whole pipeline

Our query pipeline had been built up with some organic growth. As the needs of the business grew and changed, we added more models and had different models querying the same raw staging datasets for similar, but slightly different, use-cases. Could we improve our design?

One type of analysis we conduct is to know what is the first time we encounter a new customer or end-user. For example, we keep track of the first time an enduser uses one of our products each month.



By using the first value Snowflake window function, we can keep track of the first time we see new combinations of a user and a product per month.

We can improve our original count(distinct) query performance by leveraging this dataset! Our original query can remove the need for a distinct count completely by taking the absolute count of rows in our user-centric table.



By keeping incremental updates of the first time we see each of our users, and then computing the (non-distinct) count of rows across our user dataset, we’re able to optimize away the need for count(distinct) . On average, one user produces about 50 events per month, and we had reduced our query from looking at O(events) to O(users) data, a 98% reduction in data size. Snowflake was now once again able to run most of it’s queries out of the caching layer, removing the need for expensive disk scans.



We are able to trigger all our DBT model pipeline and quickly churn through it.

Applying model to our whole pipeline

We were able to apply this deduplication of effort strategy to our entire model hierarchy. The results were immediately apparent: our incremental update pipeline improved from running in 45 minutes to under four minutes by leveraging a logical refactoring of the data flow.

---


# What is SIM-swap scam, and how can you protect your users against one?
Source: https://stytch.com/blog/sim-swapping/

Learn all about SIM-swap scams – an increasingly popular kind of attacks targeting the passwordless authentication method SMS OTPs.

A SIM-swap scam, also referred to as SIM-swapping, is a type of account takeover attack that specifically targets someone’s phone as a way to get access to their online accounts. SIM-swapping is notable because unlike many account takeover attacks, it specifically targets a something-you-have authentication factor – namely, verification codes sent to your phone by a call or text.

As multi-factor authentication becomes increasingly commonplace for web applications, understanding how a SIM-swap scam works, and how to protect you and your customers against it are increasingly important for online applications.

Remind me: what is a SIM card?



The SIM in SIM card actually stands for subscriber identity module, which is apt – the SIM card in your phone contains the chip that identifies your phone number with your physical device. It’s what enables you not only to use your smartphone as a computer – to access the web, send emails, use apps – but to make and receive phone calls and critically, to send and receive text messages.

For our purposes, it’s also important to note that your mobile phone carrier has the power to change the phone number associated with a SIM card through a feature called mobile number portability. If you’ve ever kept your phone number when changing phone providers or needed to replace a lost or stolen phone, you’ve taken advantage of this feature. Mobile number portability means phone numbers are not locked to a specific SIM card, but are in fact portable.

It’s this mobile number portability feature that enables SIM-swap attacks to happen.

And…what are SMS one-time passcodes (SMS OTP)?



SMS one-time passcodes, (or SMS OTPs) are security codes that are automatically sent to a user’s phone number upon a signup or login attempt. They typically contain a randomly generated string of numeric or alphanumeric characters that a user must input to verify their identity and gain access to or carry out sensitive actions within an app or website.

As the name suggests, a one-time passcode can only be used once — that is, for a single authentication event. After a given code is entered, it is invalidated and cannot be used again.

While in the case of SIM-swapping we’re focused on SMS OTPs (and in some rare cases OTPs that are received through a phone call) it’s worth noting you can also receive OTPs via other services like email or WhatsApp.

Why SMS OTPs are popular

To understand why SMS OTPs are a cybersecurity attack vector, it’s helpful to understand why they’re currently such a popular form of user authentication.

1. Something-you-have

As mentioned above, SMS OTPs are a something-you-have type of authentication. This means that rather than verifying something that you know (like a password) or something that you are (via a biometric reader) the SMS OTP verifies that the user has access to a personal device. Passwords and something-you-know factors are notoriously easier to hack than other factors, so SMS OTPs protect applications from some of the lowest hanging fruit in the fraudster’s arsenal.

2. Versatility

SMS OTPs can be used as a primary or secondary authentication factor, though they’re most commonly used as a secondary one in multi- or two-factor authentication. This means that when someone attempts to log into an application with a password or an email magic link, your app can get additional assurance the user is who they say they are with a second auth factor.

3. Accessible

Unlike some more sophisticated or expensive authentication factors like YubiKeys or passkeys, SMS OTPs are accessible to anyone with a SIM card – you don’t even have to have a smartphone. They’re a great additional auth factor both for any mobile application because the phone is already in the user’s hands. Simultaneously they’re great for applications whose users may not typically have access to other forms of authentication (embeddable magic links, email OTPs, authenticator apps, etc.).

Why are these advantages important to understanding SIM-swapping?

As we’ll see, though SIM-swapping is a bit more labor intensive and less scalable than other forms of account takeover, part of what makes it alluring is the popularity of the SMS OTP itself. Were SMS OTPs less popular among applications, SIM-swapping would be far less tempting as an attack vector.

How does SIM-swapping work?



The end goal of SIM-swapping is to gain remote access to a person’s SIM card, and any SMS OTPs they may receive. Typically, fraudsters do this through a combination of phishing and social engineering, both of their target and of their target’s mobile carrier.

Let’s take a look at a SIM-swap attack step-by-step.

1. Obtain personal details

In order to successfully carry out SIM-swap fraud, fraudsters need some personal information about their victim(s). They typically obtain this through phishing emails (which target large groups of people at scale), buying already compromised credentials or personal information.

Note that scammers these days are getting trickier – many are using their targets’ social media accounts to gain personal information. This often involves the fraudster creating fake social media accounts and trying to get their target’s personal info through private messages, perhaps feigning romantic interest or promising alluring business deals. And if they’ve already successfully gotten access to the SIM-card and/or social media accounts of someone you personally know, they will use those accounts to try to get you to reveal personal information by leveraging the higher degree of trust you’re likely to have in known contacts like friends or family.

2. Contact target’s mobile carrier

While phishing or purchasing sensitive information can be done at a fairly large scale, this next step is a little harder to do at a mass level. Once they have a target’s information, the fraudster usually has to call their target’s mobile carrier and convince them that:

They are the target

Their SIM card has been lost or stolen.

This is where the personal information phished or purchased comes in handy – to confirm the caller is in fact the owner of the account (which they’re not!) mobile carriers may ask for an email address, physical address, or other types of identity verification. Depending on how successful the fraudster was in obtaining information on their target, if they answer these questions successfully they can successfully convince the mobile carrier to switch their target’s phone number to a SIM-card that they control.

3. Account takeover

With personal information on hand and control of their target’s phone number, the fraudster can now likely take over online accounts from their target even if those accounts are protected by two-factor authentication. Any SMS directed to their target’s phone number, including SMS OTPs, will go directly to their SIM-card. To boot, they now control all incoming and outgoing phone calls from that person’s phone number. In other words, they have effectively swapped their SIM-card for their target’s.

Assuming the information they phished or purchased included one or more usernames and passwords, they have enough information to gain access to financial accounts, bank accounts – even those protected by two-factor authentication.



SIM-swapping in the news

Perhaps the most well-known SIM-swap attack occurred in 2019 against former Twitter CEO Jack Dorsey. As a high net-worth individual and someone with a lot of publicly available personal details, Dorsey was a prime SIM-swap target. SIM-swap attacks both need to be higher reward to be worth the hacker’s high touch effort and often rely on publicly available personal information – Dorsey checked both those boxes. 

Signs of a SIM-swap attack



So how will a user know know if they’ve been the victim of SIM-swap fraud? There are often a few key signs:

1. They can’t make phone calls or send text messages.

If your user suddenly can’t make phone calls or text messages, or if they’re not receiving calls or texts, that could be a strong indicator of SIM-swapping. Of course, users should make sure there aren’t any obvious explanations like their phone accidentally got switched into Airplane Mode, or they’re traveling through an area of notoriously poor reception! But once other factors have been eliminated, it’s worth reaching out to their phone carrier.

2. They don’t have phone service.

Relatedly, if a user’s mobile phone consistently and very suddenly has no service, especially in locales where they previously did, it may be worth reaching out to their phone carrier in these instances.

3. Unrecognized activity on your social media accounts.

Social media accounts are a common account target for fraudsters, because they can leverage them to phish and scam other people in their target’s network. If someone notices activity on their social media accounts that wasn’t them, they’ve likely been hacked in one way or another. If that activity is present with other indications of SIM-swapping, it’s a good time to reach out to their mobile provider to see if their phone number has recently been moved to another SIM card.

4. Their mobile carrier notifies you that your number has been moved to a new SIM-card.

Perhaps one of the most obvious signs of a SIM swap, one should take note if their cell phone carrier contacts them notifying you of a SIM swap that they did not initiate.

5. Unrecognized activity on bank or other financial accounts.

Typical of any kind of fraud or account takeover, if someone notices any unusual activity on their bank or financial accounts, it’s definitely likely a sign that some kind of fraud or hacking has taken place.

Protecting against SIM-swap scams



To prevent SIM-swapping, there are two main areas where companies and individuals can take precautions: on the individual, behavioral level, and at the application-wide, security infrastructure level.

Behavioral precautions against SIM-swap attacks

Be wise to signs of phishing and social engineering: Don’t trust emails from people or organizations you don’t recognize, especially if those emails come with calls-to-action (CTAs) to click on links, fill out forms, or send back personal information. While there are often telltale signs these come from a fraudster like typos or an email address that doesn’t correspond to the sender’s information, also be wary of CTAs that are conjuring up a sense of urgency, danger, or big reward (“Send me your bank account info so you can claim your prize!” etc. etc.).

Use unique, strong passwords: In order to SIM-swap, fraudsters first need to be able to obtain your personal information. In addition to phishing or social engineering, they may also try to obtain that information through various kinds of brute force attacks. 

Protect your personal information: Unless you’re a professional social media influencer, you may want to consider keeping your social media accounts private. Many fraudsters will closely follow social media accounts of their targets to try to glean personal information like their birthday, pets’ names, birthplace, address, etc.

Always use two-factor authentication: Even though second auth factors like SMS OTP are vulnerable to certain kinds of attacks, they’re still a crucial protection between individual users and hackers. Any point of resistance or additional labor you can add to their plate, the less likely they are to pursue you. If the possibility of SIM-swapping makes you wary of SMS OTP, consider other 2nd auth factors like passkeys, time-based one-time passcodes (TOTPs), or physical hardware keys like YubiKeys.

Application-wide protections against SIM-swapping

SIM-swap fraud may be on the rise, but so is the use of more secure authentication methods. Some of the best that can protect your company and your customers include:

Incorporate step-up authentication: If the day-to-day transactions on your app may not immediately implicate your users’ personal information, you might not want to require several authentication methods just to get in. BUT, certain actions like updating payment information or passwords are more sensitive, and could benefit from added protection. Step-up authentication is a form of MFA that is only triggered for more sensitive account-related actions. By requiring an email OTP or a biometric only for certain transactions, you keep your users safe without imposing undue friction.

Upgrade to more modern authentication methods: With newer auth methods like TOTPs (also called authenticator apps) and passkeys now available, it’s a great moment to encourage users away from less secure methods like passwords and SMS OTP and towards these more future-forward, secured approaches. You can start by giving them additional options for their primary and secondary authentication methods, offering additional education, etc., to see how these newer methods perform with your users. Which authentication methods you choose will likely depend on your use case – do most of your users have access to a smart phone? Are they familiar with or likely to adopt newer technologies? The more you give them options now, the more easily you’ll be able to wean them off of these less secure methods in the long run. Because remember: SIM-swapping isn’t a vulnerability merely because SIM cards are vulnerable, they’re a vulnerability because passwords are also highly breachable. It’s the combination of passwords’ weakness as a primary auth factor with SIM-swapping as a secondary that make them both prime targets of fraud.

Invest in fraud prevention tools: Because SIM-swapping happens in conjunction with other kinds of attacks targeting personal information, applications can benefit from fraud prevention measures like device fingerprinting or CAPTCHA that help detect and block suspicious behavior before they even get to the point of requesting an SMS OTP. Additionally, products like Stytch’s Device Fingerprinting can generate device identifiers that can be used defensively against SIM-swapping attacks even after the phone number has been swapped. For example, if an application adds a Stytch device fingerprinting checks to either their OTP pin submit or request otp PIN endpoints, that application could actually detect a sim-swap attack before the OTP is transmitted or allowed to be used for access by the fraudster, because the fraudster’s physical device characteristics/versions/etc., would likely differ from the original user whom they targeted.

Protect your users with authentication and fraud protection from Stytch

Stytch is unique in the world of identity platforms in that we offer both a wide range of passwordless authentication solutions alongside a robust set of fraud prevention tools. Get started building for free, explore our docs, or get in touch to schedule a demo today. 

---


# What is browser fingerprinting?
Source: https://stytch.com/blog/what-is-browser-fingerprinting/

Browser fingerprinting is a subset of device fingerprinting that pulls data from web browsers to create unique user identifiers.

Have you ever been asked to put in an additional auth factor because an app says it doesn’t recognize your device? If this has happened to you, you’ve likely been subject to a security measure called “device fingerprinting.”

Device fingerprinting is a way to identify devices that are accessing a website or application. When a user enters a platform, device fingerprinting can detect a number of their device attributes and compile them into a unique user ID.

One subset of device fingerprinting is called browser fingerprinting. Browser fingerprinting shares the same principle of device fingerprinting – identifying users through their individual device information.

Browser fingerprinting, however, refers to the specific device attributes that can be gleaned through a user’s web browser.

This technique relies on the configuration specifically of a user’s web browser to reveal information about their device’s software and hardware. Here’s how it works.

How browser fingerprinting works

Browser fingerprinting takes advantage of the information exchange that must occur in order for a device to display a website properly.

In order for a website to display correctly on your smartphone (vs. your tablet or desktop), the application looks for a few different kinds of information, ranging from critical to nice-to-haves. Below are some common examples of this data:



Caption: IP address; user agent; fonts; touch hardware; cookies enablement; screen resolution; operating system; HTTP header attributes; language; browser settings; keyboard layout; audio setup; HTML5

When a user visits a website that analyzes its traffic via browser fingerprinting, JavaScript code on that website pulls three categories of visitor information:

Browser usage (IP address, user agent, fonts, cookies enablement, HTTP header attributes, HTML5, language, browser settings, etc.)

User device hardware (touch hardware, screen resolution, operating system, keyboard layout, audio setup, etc.)

Cookie history (third party cookies saved on the browser from prior web activity not to be confused with the actual functionality of cookies, which we dive into later on)

These three categories of visitor data are hashed to become a browser fingerprint and stored server-side.



The next time you (or worse, someone pretending to be you) tries to log into or use an online app or service, that app can then compare this hashed browser fingerprint to the current device.

If there’s a discrepancy or an unverified browser, that can be a signal to the app either to deny you access, or force you to engage in an additional step of authentication, and/or register the browser information as an additional authorized device/browser on your account.

Browser fingerprinting uses cases

Depending on who you talk to, some internet users today are skeptical of device fingerprinting, particularly in the case where they’re concerned their data might be sold to a third party.

But many applications leveraging a form of device fingerprinting are using them by well-intentioned developers in order to protect users, not exploit them.

Security

Browser fingerprinting has a high success rate for identifying and blocking increasingly sophisticated fraudulent users and bots.

Bad actors constantly figure out new ways to compromise passwords and get their hands on MFA passcodes. Fingerprinting techniques run undetected in the background to identify these malicious users before they even get a chance to enter credentials.

Certain device attributes are red flags that a user could be malicious. For example, devices with anti-fingerprinting plugins, running outdated software, or odd screen resolutions could all signal that a user has configured their device to evade detection.

Browser fingerprinting also guards against account takeovers (ATOs). If a user’s fingerprint is the same every time, then one day their location and device type are completely different, that could signal somebody else hacking into their account. A good device fingerprint integration will flag and block, or at the very least ask for additional verification from this user.

User experience

Browser fingerprinting can also identify good users. When someone who has already been deemed a valid user returns to an application, browser fingerprinting will recognize the returning user.

Rather than making it more difficult for this same user to access the application, like for a suspicious user, developers can improve the experience for them by reducing the number of authentication factors they encounter.

Advertising

Finally, marketers use browser fingerprinting to present relevant content to users.

Everyone who’s online shopped has experienced this targeted advertising tracking method – you poke around Sunglasses Hut once only to be served advertisements for sunglasses all over your browser.

This is, perhaps, the most noticeable type of browser fingerprinting. Some users may value this kind of fingerprinting because it helps personalize their experience, while others may prefer greater privacy protections. The permitted uses of device fingerprinting for advertising also vary widely by country and continent, as covered in our device fingerprinting blog.



Types of browser fingerprinting

We’ve covered what browser fingerprinting is and how it’s used. Now let’s talk about how websites gather information via browser fingerprinting.

Canvas fingerprinting



Canvas fingerprinting plays off of the interaction between device-type and website display. Devices that show websites configure the visuals in a way that works for that device. Nike.com will look different on a 2015 ThinkPad than on a 2023 iPhone 15 Pro.

Canvas fingerprints use HTML5’s canvas element, the component of HTML code that forces browsers to render a hidden image. This invisible image reveals the graphics processing unit (GPU), graphics drivers, and/or graphics card of a particular device.

Given the ubiquity of HTML websites, canvas fingerprinting is a widely used form of online fingerprinting.

WebGL fingerprinting



WebGL fingerprinting is very similar to canvas fingerprinting. Short for Web Graphics Library, WebGL is a javascript API that displays images.

Just like canvas fingerprinting, this javascript code forces a device to render a behind-the-scenes image. Based on this image, WebGL fingerprinting can discern the device’s graphics card model and screen resolution.

Audio fingerprinting



Whereas canvas fingerprinting and webGL fingerprinting reveal how devices process images, audio fingerprinting reveals how devices process audio.

Developers use the Web Audio API to control how their websites play sound (specifically, this API gauges how a device plays sound). So based on factors like sound waves produced by the digital oscillator, audio fingerprinting can reveal information about a device’s central processing unit (CPU).

Media device fingerprinting



Media device fingerprinting analyzes the devices that are built-in and/or connected to a user device.

Webcam and speaker type, for example, are collected via internal video and audio cards, respectively. This type of fingerprinting also assesses any headphones or bluetooth devices connected externally to a device.

Browser fingerprinting vs cookies

Cookies are the other major way to collect the above user data. These are pieces of compact tracking code that websites place on visiting users’ browsers.

This section will explore the differences between browser fingerprinting and cookies, and their various strengths as methods for tracking user behavior online.

User experience

These tracking techniques create very different user experiences.

Cookies (thanks to regulations mentioned below under “privacy concerns for browser fingerprinting,”) must be announced to the user whereas browser fingerprinting (yet to be regulated) may run undetected.

This means users will know when a website uses cookies but be unaware of browser fingerprinting.

Storage

Cookies are pieces of tracking code stored client-side as small text files. This means that users have control over blocking or clearing cookie caches as they please.

Browser fingerprints, however, are stored beyond user reach in server-side databases. Because it is stateless, a browser fingerprint cannot be accessed or deleted by the user, making it a consistent method for tracking their behavior for any anomalous or suspicious activity.

Accuracy

Cookies and browser fingerprinting are both highly accurate fingerprinting techniques.

Because cookies are placed on a user’s device, they will identify users with 100% uniqueness in all cases. The downside to this persistent identifier is that cookies can be lost or cleared.

Although slightly less certain than cookies, developers can still have a high degree of confidence that browser fingerprinting will accurately and uniquely identify users. Browser fingerprints may not always be completely unique depending on the hardware and software types in question, but they are more enduring because they are not stored locally. 

In summary

Given the pros and cons of these two fingerprinting approaches, it often makes sense to use both together. Most users will have cookies present for their sessions, but if they don’t, you can fall back to browser fingerprinting to create a unique identifier regardless of user behavior.

Privacy concerns for browser fingerprinting

Many people find fingerprinting technology off-putting, and worry about the implications of companies being able to track their behavior.

Users should always be empowered to make informed decisions about what data they do and don’t give away online, but it also helps to understand why this technology is being used by so many applications.

Stytch’s Device Fingerprinting (which includes elements of browser fingerprinting) helps our customers keep their users safe. By immediately and accurately identifying bots, fingerprinting technology keeps bad actors out of applications and away from good users’ data.

Legality

To some, personal data collection feels intrusive enough to wonder, “Is browser fingerprinting legal?”

The short answer is: yes, it is.

In fact, both cookies and browser fingerprinting are legal and regulated by the GDPR and CCPA.

Preventing online tracking

For users who are concerned about being tracked, even when it’s for their own protection, there are some common practices that can help reduce online tracking, such as:

A privacy focused browser to impact the efficacy of online tracking. Tor Browser, for example, anonymizes users through multiple encryption layers, but beware! Using this sanitized Tor Browser can sometimes draw more attention as potentially suspicious behavior.

Default device settings make a user’s device less unique, so a browser fingerprint will share more attributes with other users and may not be as accurate.

VPNs encrypt user data and hide IP addresses, making less information available to browser fingerprints. Be forewarned though that many sites are now blocking VPN traffic – if they can’t accurately fingerprint a user, they block certain features. This helps them incentivize stronger security practices. 

Multiple devices attempt to confound browser fingerprinting attempts by associating a user with more than one device. Typically, though, once a device or browser is verified it then becomes one of many that are associated with a given user’s account. 

Anti-tracking browser extensions and ad blockers such as Ghosterly give fingerprinting technologies less data to create a user’s fingerprint. Anti-fingerprinting browser extensions will, however, typically result in a user being automatically challenged with CAPTCHA, 2FA, or even blocked.

Regulating your own online activity by regularly clearing browsing history, blocking cookies, disabling JavaScript, and only sharing limited (or disposable) personal information can reduce tracking. Keep in mind some of these choices may affect website performance or introduce more friction into the online web experience.

Although masking your device or browser software settings using the techniques above may make tracking more difficult, you will likely encounter more friction across the internet.

Companies who make tracking technology like device fingerprinting a part of their core security will want to take further steps to verify your identity or legitimate intentions another way, to make sure they’re keeping their users safe.

Browser fingerprinting at Stytch

Stytch offers Device Fingerprinting to mitigate fraud and risk. Our device fingerprinting product, as the umbrella term for creating unique user identifiers, uses browser fingerprinting in addition to other sophisticated fingerprinting techniques to create unique user identifiers.

Our solution analyzes user traffic and flags suspicious users. Developers can either block, challenge with additional security, or allow flagged users. See which device attributes we combine into each device fingerprint in our docs.

---


# What is fraud prevention?
Source: https://stytch.com/blog/what-is-fraud-prevention/

Learn about the latest developments in cyber fraud, how AI is changing the landscape, and how you can protect your company and customers.

As we navigate the complexities of the digital age, the importance of fraud prevention for businesses has only increased. But what is fraud prevention and detection in the context of today’s complex, high-stakes environment, and how has it evolved?

Today, artificial intelligence (AI) and machine learning are not only tools for growth but also instruments for fraudsters’ sophisticated schemes, posing new threats. And while not every threat is a Walter White to an organization’s reputation, it pays serious dividends to set some guardrails.

Let’s delve into fraud prevention and the various types of fraud, highlighting how businesses can arm themselves against an ever-evolving risk landscape.

Table of contents

What is fraud prevention and detection, and why should it matter to businesses?

Foundational fraud prevention and risk management considerations

Breaking bad actors: fraud prevention tools to consider for the AI era

What is fraud prevention and detection, and why should it matter to businesses?

Fraud prevention: anticipating threats

At its core, fraud prevention refers to strategies and solutions put in place to avoid fraudulent activities before they occur. In an age where online transactions have become the norm, the need for advanced fraud prevention is more critical than ever. Cybercriminals are constantly finding new ways to commit fraud – from identity theft to credit card fraud, and now fraud both enabled by and targeting AI applications – making it imperative for businesses to stay one step ahead.

At a high level, fraud prevention for organizations encompasses various measures, tools, and best practices designed to identify and reduce the risk of fraudulent transactions. This involves not just technical solutions but also policies and procedures that help prevent fraud from infiltrating business operations. The ultimate goal is to protect the financial assets, personal information, and trustworthiness of businesses and their clients.

Fraud detection: mitigating risks in real time

Fraud detection plays an additional critical role in combating cyber threats, working hand-in-hand with fraud prevention measures to strengthen overall security. While fraud prevention focuses on preempting fraudulent activities, fraud detection aims to identify these activities as they occur or even after they’ve taken place. Advanced fraud detection systems use complex algorithms and machine learning to recognize patterns of behavior that are indicative of fraud.

Implementing timely and effective fraud detection and prevention together is vital to minimizing the potential damage caused by fraudulent transactions. While fraud prevention and fraud detection serve different purposes, their integrated applications form a robust defense against the multifaceted challenges of cybersecurity.

Recognizing types of fraud



Recognizing various types of fraud is the first step in building an effective fraud prevention strategy. Common forms include:

Identity theft: This occurs when fraudsters obtain and use someone’s personal information for gain. From securing loans to purchasing items online, the repercussions for victims can be far-reaching.

Credit card fraud: Criminals make unauthorized transactions using stolen credit card details. The ease of online shopping has only exacerbated this issue, calling for more stringent fraud detection mechanisms to secure credit card transactions.

Bank fraud and money laundering: These sophisticated schemes can involve multiple parties and obscure money trails, often requiring significant investigative resources to unravel.

Business email compromise (BEC): A high-impact scam, BEC involves fraudsters impersonating company executives or business contacts to mislead employees or customers into transferring funds or revealing sensitive information such as personal information.

Phishing: Criminals use phishing schemes to deceive users into revealing their personal and financial information. Strong authentication methods are needed to protect against these kinds of scams. To combat reverse engineering and increasingly potent phishing attacks in the AI era, businesses should consider advanced security technologies with stronger user access controls and more phishing-resistant forms of authentication.

AI bot attacks: Increasingly common in the AI era, bot attacks are challenging AI companies (or companies relying heavily on AI) to implement effective bot detection and blocking mechanisms. They also need to monitor and protect against bot detection evasion techniques. For more on AI bot attacks, check out “Securing AI against bot attacks.“

These types of fraud underscore the need for a multifaceted approach to fraud prevention in the digital age, demanding collaboration across various business units and sometimes third-party services.



Implementing effective fraud detection not only protects businesses from financial losses but also safeguards their reputation and customer trust. By proactively identifying and preventing fraudulent activities, businesses can maintain a secure environment for their customers to conduct transactions in – table stakes for any serious organization.

AI and the evolving threat landscape



Those stakes are undoubtedly higher in the current digital milieu. Fraudsters can create fake accounts, engage in business email compromise, and even utilize AI to mimic user behavior, blurring the line between bot and human, and complicating the process of detecting fraud.

Furthermore, companies increasingly need bot detection that protects APIs – often the secure barrier between sensitive data and malicious actors – from exposure to unauthorized bots.

In response to these emerging threats, businesses must continuously update their fraud detection and prevention strategies to stay ahead of the evolving tactics used by cybercriminals.

In addition to traditional methods of fraud detection, such as manual review and rule-based systems, businesses are increasingly turning to advanced technologies like artificial intelligence (AI) and predictive analytics. These tools enable businesses to analyze large volumes of data in real-time to detect fraud quickly and accurately. They also continuously adapt and learn from new information, making them highly effective at detecting emerging fraud patterns and techniques.

Foundational fraud prevention and risk management considerations

So where to begin in this multifaceted fight against fraud? While at Stytch we’re focused on equipping businesses with the right tech tools to combat fraud, it’s beneficial to begin with some strategic groundwork before you make any new technology investments to set your organization on the right path to effective adoption and utilization of such tools. 

Five core areas of a defensive strategy

A comprehensive fraud prevention program is essential for any business seeking to safeguard its operations. At a high level, this might involve:

Risk management strategies: Regular, comprehensive assessments to identify vulnerabilities within the system and determine the company’s risk appetite.

Policies and procedures: Clear guidelines on handling sensitive information and financial transactions, as well as protocols for responding to suspected fraud.

Internal controls: Checks and balances, such as segregating duties and setting up approval processes for transactions.

Employee training: Regular sessions to educate staff on the latest fraud trends and the role they play in preventing fraud.

Customer due diligence: Procedures to verify the identity of customers and assess the risk of potential fraud.

By implementing these elements, businesses can establish a solid foundation to combat the multifaceted threat of cyber fraud. But in addition to internal controls, organizations must comply and collaborate with regulatory bodies – and perhaps consider insuring themselves – to create an environment where inevitable security missteps won’t prove destructive.

The need for regulatory compliance



Consistent adherence to regulatory compliance plays a crucial role in fraud prevention. It’s not just as a legal obligation – it’s a strategic tool for business growth and sustainability.

Businesses need to be keenly aware of the regulations related to data security and fraud in their specific industry. Compliance with these regulations not only helps in reducing the risk of fraud but also protects the business from potential legal implications. Moreover, regulatory bodies often provide guidelines on best practices for fraud detection and prevention, which can serve as a valuable resource for businesses.

Failing to adhere to regulatory compliance can have disastrous consequences for businesses. Penalties can range from hefty fines to loss of licenses, and in severe cases, they may face lawsuits or criminal charges.

Additionally, non-compliance can severely tarnish a business’s reputation, eroding customer trust and loyalty. Businesses may also lose their competitive edge as regulatory compliance often means adopting the latest security technologies and practices, which can enhance overall business efficiency and performance.

Cyber insurance policies

Businesses should consider investing in cyber insurance policies as an added layer of protection against financial loss in the event of a security breach. These policies can help cover expenses such as legal fees, public relations costs, and lost revenue.

In the case of a security breach, businesses should have protocols in place for notifying affected customers and addressing their concerns. Transparency and effective communication are crucial in maintaining customer trust, risk management, and mitigating potential damage to the business’s reputation.

Institutional collaboration: joining forces against fraud



Combating cyber fraud isn't a solo endeavor. Collaboration between businesses, financial institutions, and government agencies can enhance fraud prevention and detection efforts. Sharing information about emerging threats, known fraudsters, and effective prevention techniques can fortify individual defenses, creating a united front against cyber fraud.

Furthermore, working together can help identify patterns and trends across industries, leading to more comprehensive and effective fraud prevention strategies. By pooling resources and knowledge, organizations can better protect themselves and their customers from fraudulent activities.

Breaking bad actors: fraud prevention tools to consider for the AI era

With the rise of emerging technologies such as blockchain and biometrics, businesses must stay current on these technologies and incorporate them into their fraud prevention arsenal. By being proactive in adopting them, organizations can future-proof themselves against fraudulent activities.

Unphishable authentication solutions

Unphishable authentication solutions aim to counteract phishing attempts that trick individuals into revealing sensitive information like passwords. By removing the traditional password element or adding extra layers of security, these methods greatly reduce the risk of account breaches due to phishing. 

Some prominent strategies of unphishable authentication solutions include passwordless methods like biometric verification and magic links, which eliminate the traditional password vulnerability; Multi-Factor Authentication (MFA) that enhances security by requiring additional verification elements, ranging from physical devices to biometric confirmations; and passkeys and Single Sign-On (SSO) solutions that provide secure, centralized access to multiple platforms, reducing the reliance on multiple vulnerable password points and simplifying user experience while maintaining a high security level.

Device fingerprinting

Device fingerprinting is a technique for identifying individual devices based on a combination of information, such as browser type and version, operating system, IP address, installed fonts, and more. This unique fingerprint enables organizations to pinpoint authentic users from malicious actors and detect suspicious activities, even if fraudsters change their IP addresses or use VPNs.

Stytch’s Device Fingerprinting provides a set of customizable tools for your business to accurately identify devices. Stytch’s device fingerprints remain stable across incognito browsing, webviews, VPNs, changes to user agent or IP addresses, and more.

Stronger access controls

Closing the door to unauthorized access can be challenging, but Time-based One-Time Passcodes (TOTP) that involve short-lived, automatically generated codes and offer temporary access can significantly reduce the risk of unauthorized access. They are one of the most commonly deployed and effective methods.

Additionally, a more complex CAPTCHA – the challenges users must solve to prevent bots from accessing websites and applications – can be another powerful layer of security. Unlike conventional CAPTCHAs which can often be bypassed by bots, StrongCAPTCHA by Stytch employs complex problem-solving tasks that are easy for humans but challenging for bots.

All these solutions and tools are ideal ways to tackle some of the most common emerging threats depending on the level of threat risk and sophistication your organization is confronting.

For more insights on enhancing your fraud prevention strategies, explore the wealth of resources available on the Stytch blog, or talk with an auth expert at Stytch today.

---


# One-Time Password (OTP) bots: what they are and how to stop them
Source: https://stytch.com/blog/otp-bots/

Learn all about the bots that are enabling faster, more effective OTP hacking, and what you can do to stop them.

OTP bots are a relatively new and sophisticated threat in the increasingly wide world of Multi-Factor-Authentication (MFA) scams. In short, they’re automated software – or bots – that bypass two-factor authentication, causing a security nightmare for users and online services.

As they challenge many conventional security measures, understanding and neutralizing OTP bots has become a priority for many organizations.

But before we dive into prevention strategies, let’s first understand the anatomy of two-factor and multi-factor authentication to see how these bad actors work their dark and deceptive magic.

The lay of the auth land: OTPs and 2FA

What are One-Time Passwords (OTPs)?

One-Time Passwords (OTPs) are unique, short-lived passcodes sent to a person’s phone number to be used as an additional layer of security for online transactions or logins. Typically sent to a user’s registered phone number or email, an OTP must be entered within a specified time period to confirm the user’s identity.

Unlike traditional static passwords, OTPs are much harder to compromise because they are dynamic and expire after a single use or short duration, making them a popular choice for two-factor and multi-factor authentication processes.

Understanding Two-Factor Authentication

Two-factor authentication (2FA) enhances security by requiring two separate verification methods. Usually, after entering a password, users receive a one-time password (OTP) to their phone number via SMS, providing a second layer of security. However, OTP bots have emerged as a tool for intercepting these crucial OTP codes, creating a pressing security issue.



The process of 2FA involves a combination of two different factors: something you know (like a password), something you have (like your phone), or something you are (like your fingerprint). This means that even if an attacker knows your password, they’ll still need the second factor—usually a temporary verification code sent to your mobile device phone number —to access your account.

With OTP bots now being able to intercept these codes, 2FA’s effectiveness is somewhat compromised, pushing for the development of more advanced and secure authentication methods.

What are OTP Bots?

OTP bots are automated software programs that are designed to bypass two-factor authentication (2FA) systems. OTP bots are typically used for financial gain, such as accessing and draining bank accounts or making fraudulent transactions.

As more and more online services have implemented 2FA as an extra layer of security, OTP bots have become a more significant threat with their ability to bypass traditional authentication methods, making it easier for hackers to gain access to sensitive information using a victim’s phone number and other methods. The rise of OTP bots can also be attributed to the increasing availability and affordability of automated software tools.

Understanding OTP bot attacks and their impact

While OTP bots are not essential for OTP scams to work, they can massively scale and improve scam success rates through automation and an extra layer of credibility. There are two common scam types where OTP bots can make a massive impact:

Phishing

In a phishing attack, the potential victim usually receives a text message or an email claiming that something is wrong with their bank account with a plausible looking URL / link to click on. The scam usually goes down as follows:

The victim clicks the link, taking them to a fraudulent site mimicking the bank’s login page, and enters their credentials which the attacker then uses to access the actual bank site.

At this stage, direct bank account access is blocked due to the unfamiliar IP address of the attacker, so a Two-Factor Authentication (2FA) OTP challenge is initiated.

The scammer’s site prompts the victim to select a 2FA method, forwarding the choice to the bank.

The bank sends an OTP to the victim, who enters it on the phishing site. The attacker uses the OTP to gain full access to the bank account.

To avoid suspicion, the scammer may allow transparent access to the bank or display a fake error message.

The scammer can then conduct fraudulent transactions or collect financial information from the victim.

Malware

As mentioned, OTP bots are automated software which we’ll categorize as malware given the malicious nature of their design. In a malware attack, the attacker will trick the victim into installing the OTP bot (malware) on their device. This is often accomplished through exploiting password reset flows for sites that use only OTP pin validation as a challenge to resetting the password. Once the OTP bot (malware) is on the victim’s device, it can monitor the device’s activities as follows:

OTPs for authentication, like bank logins, are sent to the user’s phone.

Malware on the user’s device detects and secretly forwards the OTP to the attacker.

Advanced malware automates the process: initiating login, intercepting OTP, and completing authentication.

Attackers gain unauthorized access to perform malicious actions (funds transfer, data theft).

The malware may erase the OTP message to avoid detection by the user.

Additional malware or backdoors may be installed for sustained access.

By automating the OTP interception process, these bots can conduct widespread attacks, compromising numerous accounts swiftly and often going undetected until the damage unfolds.

Let’s dig a bit deeper into why they’ve been so successful.

The problem with 2FA

One of the main reasons why OTP bot attacks have become so prevalent is due to the popularity of 2FA as an added security measure. With the increasing popularity, new methods of circumventing this popular authentication method have sprung up. 2FA is now a lucrative target for cybercriminals looking for ways to exploit vulnerabilities and steal sensitive information.

Once attackers obtain an OTP, they can bypass the 2FA, leading to account takeover. With this unauthorized access, scammers can engage in malicious activities, including stealing financial resources, personal data, or using the account for other fraudulent schemes. This poses a significant risk to individuals and can also result in substantial financial losses for organizations and institutions.



LLMs and Modern Social Engineering



With modern generative AI-platforms such as ChatGPT 4, automated responses can feel so human it often feels like there’s a real person behind the ‘curtain.’ Modern social engineering seeks to exploit this incredibly promising – and daunting – technological advancement in the world of fraud.

In traditional social engineering, attackers use deceptive messages, e.g. posing as a company’s CEO and requesting urgent information, or pretending to be a reputable service requesting a verification code, to trick victims into a scam. By ‘engineering’ their responses in their favor, unsuspecting victims believe they’re securing their accounts and will provide the OTP or verification code, inadvertently granting attackers access to their information.

Scammers are increasingly experimenting with advanced Large Language Models (LLMs) – the machine learning powering generative AI – to create sophisticated automated systems capable of executing social engineering attacks. These fraud bots are being designed to mimic human interaction more compellingly than ever. LLMs build on ‘traditional’ fraud techniques and can vastly expand the creativity and adaptability of fraudsters.

LLM-powered bots can engage in conversations in multiple languages, and could even be programmed to perform Open Source Intelligence (OSINT) to gather publicly available data about their targets. This would enable them to craft highly personalized and convincing messages that take social engineering to the next level of believability.

The Flaws of SMS-Based OTPs

Despite their encryption, SMS text messages can be intercepted either by technical means (such as OTP bots) or by deceiving telecom service representatives, exploiting the weakest security link: human error.

Moreover, attackers can hijack a victim’s SIM card by using social engineering techniques to impersonate the user and obtain a new SIM with the same number (a rather nefarious technique called SIM-swapping). They then receive all incoming SMS messages, including OTPs, essentially bypassing 2FA measures to compromise victim accounts.

To mitigate vulnerabilities associated with SMS-based OTPs, organizations are increasingly turning towards app-based OTP solutions. Instead of receiving one-time codes through text messages, users generate them within a designated mobile application or hardware token.

The ‘SMS Buster’

Some attackers have broadened their market to offer OTP bot services to other would-be fraudsters, like the infamous ‘SMS Buster,’ for a subscription fee. These OTP bot services allow even low-skilled individuals to launch attacks, making them even more prevalent.

‘SMS Busters’ can read OTPs from text messages, parsing them for OTPs and automatically inputting them into the targeted application. These bots can also bypass CAPTCHA challenges by using Optical Character Recognition (OCR) technology.

The impact on organizations and networks

Financial institutions are prime targets for OTP bots. Attackers exploit these bots to perform unauthorized transactions, transferring funds without consent. The automation and scale of these attacks amplify the risks and potential losses for both banks and customers, who may be unable to access their funds or suffer losses – not to mention face reputational damage and regulatory sanctions.

Services like Google, PayPal, and Instagram are common victims of OTP bot assaults. Users often link financial details with these platforms, making them attractive targets. The bots’ ability to bypass security protocols creates vulnerabilities around user funds and sensitive data. It’s no wonder why Elon Musk’s somewhat messy rollout of X, the app formerly known as Twitter, is facing such strong fintech industry pushback for throwing itself into the payments game.

Prevention strategies

To combat OTP bots, businesses and online services must implement strong security measures that go beyond traditional 2FA methods. These include biometric authentication methods, such as fingerprint or facial recognition, which are more difficult for bots to bypass. Additionally, businesses and services should regularly review and update their security protocols to stay ahead of evolving bot tactics.

Individual users can also take steps to protect themselves, including regularly changing passwords and using unique and complex login credentials for each online account.

Stronger 2FA factors

Adding stronger security layers can make it harder for OTP bots to gain access to user accounts. Incorporating methods like biometric verification or cross-platform hardware tokens fortify and diversify checkpoints leading to account access. This makes it difficult for bots to bypass security protocols and gain unauthorized access.

Behavioral biometrics

Behavioral biometrics, also known as passive biometrics, is an emerging authentication method that analyzes user behavior patterns to identify and verify individuals. These include keystroke dynamics, mouse movements, swipe patterns, and other unique behaviors that are difficult for bots to replicate. By continuously monitoring these behavioral patterns, online services can detect suspicious activity and block OTP bot attacks before they compromise sensitive information.

Web authentication and hardware tokens

Web authentication works by using public key cryptography and secure hardware tokens or biometrics stored on the user’s device, effectively preventing OTP bot attacks. When a user registers an account, the server creates a public-private key pair, with the private key, or hardware token, securely stored on the user’s device, and the public key stored on the server.

During login, the server sends a challenge to the user’s device, which the device signs with the private key. The server can then verify the signature with the stored public key, ensuring that the user, and not a bot, is attempting to access the account. This procedure significantly raises the bar for attackers, as they must now gain access to the user’s physical device or biometric data to bypass authentication – no easy feat.

Tools that can help



In light of the availability of newer authentication methods such as TOTPs (authenticator apps) and passkeys, now is the perfect time to steer users away from less secure methods like passwords and SMS OTP as OTP bots continue to rise.

Stytch can help developers and organizations prepare their defenses using both physical and API-powered device security measures, such as our WebAuthn solutions. 

Device fingerprinting identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP address, helping safeguard against OTP bot attacks and other potential breaches.

Step-up authentication allows for more rigorous authentication processes like additional verification steps if a user logs in from a new location or attempts to conduct a high-risk transaction. By leveraging real-time risk assessment, step-up authentication ensures that stronger security measures kick in only when they’re most needed – without adding friction or compromising on user experience.

Stytch also offers ‘unphishable’ multi-factor authentication (MFA) that require users to authenticate their identities using multiple factors, including something they know (like a password), something they have (like a hardware token or a registered device), and something they are (like a fingerprint or other biometric data) — making it challenging for cybercriminals to gain access.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation, or get started on our platform for free today.

---


# Preventing contact spam form submissions
Source: https://stytch.com/blog/prevent-contact-form-spam/

Understand the options available to prevent spam form submissions, by using tools such as Device Fingerprinting to detect and stop bots.

It’s an all-too-common narrative. You’ve worked closely across engineering, marketing, and product to build compelling “contact us” forms – and suddenly, they’re filling up with spam. Now, all the previously happy stakeholders are concerned and want to see the spam form submissions stopped, asap.

We provide a quick tutorial below for removing that contact form spam without a CAPTCHA by using Stytch Device Fingerprinting. Feel free to skip ahead. Otherwise, let’s dig into the problem a bit more.

Why is this spam happening? Is it worth the effort to stop spammy form-fills? And if so, what are the options to prevent spam submissions?

These were the questions that we asked ourselves at Stytch recently, when junk leads on stytch.com/contact were frustrating Sales and skewing Marketing numbers. 

Not blocking form spam is surprisingly expensive.

Spammy contact form submissions and invalid traffic have a very real cost for both engineering and go-to-market teams.

For engineering and data teams, the primary cost driver is time – time answering questions from Marketing or Sales on why this is happening, time spent scrubbing data to remove the bad leads, and time exploring solutions that may not work – or may only partially solve the problem.

For Marketing teams, spammy contact form signups skew data and reporting – both internally, and in the conversion data that’s reported back to platforms like Google Ads or LinkedIn ads. Plus, spam that comes through ad platforms can also consume valuable ad dollars that could otherwise be spent on real prospects.

And for Sales teams, spam form submissions lead to wasted time sorting spam from legit sign-ups – which also means that legitimate leads may have to wait longer for a response, or even that legitimate leads may fall through the cracks or get lost amidst the spam. Leads are 100x more likely to respond when they receive a follow-up within 5 minutes; so even wasting a minute or two every hour clearing out spam leads can add up to real dollars lost.

Why do people (or bots) spam forms in the first place?

One of the first questions to ask when trying to understand and block fraud is why. Bad actors don’t usually spam just to spam; most likely, they’re spamming your form, calendar, or login flow because they believe there’s value they can extract.

In our experience, one of the most common sources of form spam is ad fraud. In a form of ad fraud called click fraud, bad actors will use bots of headless browsing to click ads and then fill out contact forms or book meetings to successfully trigger a ‘conversion event.’ Sometimes, click fraud might be perpetrated by your competitors – who know that by triggering clicks and conversions against your ads, they can deplete your paid ad budget, allowing their ads or organic results to show instead. In other cases, the ad networks themselves may engage in click fraud, since elevated clicks and conversions from their ad platform might convince companies to spend even more money with them.

These are only two examples of the financial incentives that bad actors have to spam forms; others might be less even more nefarious – like testing your forms for vulnerabilities, including susceptibility to injection attacks. Not fun.

So, what are options to stop spammy form submissions?

There are a range of options to stop bots from filling out forms on your site (and therefore – wasting your team’s time and energy). Each of them have pros and cons:

Content-based rules:

While this is the option that many people turn to first, filtering spam contact form signups purely based on the submission content often isn’t good enough. While some spammy submissions can be easily identified programmatically and filtered out (for example – names that contain ‘test’, ‘aaa’, or a URL), bad actors who are spamming forms at scale are more sophisticated, and will use realistic values to avoid rule-based logic. Here’s a great example:



Upon human review, this submission is clearly invalid – but simple rule-based filtering may not catch it.

CAPTCHA

CAPTCHAs, and in particular Google reCAPTCHA, are among the most common solutions to prevent spam form signups. Some companies like Hubspot offer reCAPTCHA integrations for their forms by default given how widespread this problem is.

However, CAPTCHAs have some downsides – they create friction for real users, who have to pause while filling out your form to check a box, select crosswalks, or solve a puzzle. Traditional CAPTCHAs are also far from bot-proof; there are a wide range of services like anti-captcha or 2captcha that solve CAPTCHAs for fractions of a cent. 

That said, if your spam problem is fairly mild, or the financial incentives for the spammers are low, a CAPTCHA may be enough, and is typically simple to set up and deploy.

Honeypots

The preferred solution among many developers to trap spambots is to use a ‘Honeypot.’ Setting up a honeypot essentially just means creating a decoy to trick bad actors into identifying themselves.

The most common honeypot strategy for contact forms is to include an ‘invisible field,’ or a form field where the display property is set to ‘none.’ Spam bots filling out the form with junk signups may not realize that the field isn’t visible, and will fill it out anyway, identifying themselves as automated actors.

Stack Overflow and other sites offer a wide range of explanations for how to set effective honeypots to stop form spam; however, as evidenced by the follow-up article on nuclear honeypots, automated form spammers can easily become sophisticated enough to avoid basic traps.

In addition, these solutions are usually optimized for spammers using scripts or CURL to interact with your site, and aren’t equipped to stop other types of bot traffic like headless browsing. As a result, honey pots are a great example of an initial fix that may help, but that often isn’t a sustainable end to form spam.

Browser or device fingerprinting

An alternative option to prevent spammy form submissions is to use browser fingerprinting or device fingerprinting to both generate unique visitor IDs and to distinguish real users from bots. Browser fingerprinting works by looking at a range of factors – such as a computer’s browser, user agent, IP address, hardware configuration, and more – to develop a unique identifier for each visitor. That identifier is typically coupled with information about if the visitor is a bot or is engaging in any type of deception, and so therefore should be challenged or blocked. 

By using device fingerprinting to distinguish real users from bots, and to uniquely identify visitors, it’s possible both to programmatically block or challenge submissions from bots and automation, as well as to build rules to individually ban human users who are abusing resources.

One downside of browser fingerprinting is that if your goal is to entirely stop spam form-fills, a fingerprinting verdict alone is not enough; you also need to build a mechanism to act on that knowledge, for example by showing a CAPTCHA or requiring authentication to continue when a user’s status is unclear. However, this allows users who are clearly above-board to be quickly routed through to marketing and Sales systems, while bots or suspicious actors can either be challenged programmatically, or their form submissions can be reviewed upfront before being filtered onward into Sales systems.


Our answer: fingerprinting our contact form-fills

At Stytch, we’re biased because we have our own Device Fingerprinting solution. While it’s coupled by default with our authentication systems, it can also be used standalone to protect any resource that may be at risk of abuse – including, you guessed it, contact us forms.

When our team started seeing an uptick in form spam, our Web team turned to device fingerprinting to block spam signups. This reduced frustration and ad spend for our marketing team and saved time for our Sales team in reviewing low-quality leads. And for the Web team, this stopped the influx of Linear tickets from Sales and Marketing reporting spam in the first place!



How we used fingerprinting to block spam submissions

Setting up Device Fingerprinting on our site

The good news: using device fingerprinting, we were able to spin up a quick solution to block spam signups without adding user friction.

Following the installation guide, we updated the page that contains our contact us form to include the very simple device fingerprinting script in the header:



We then configured the form to call the GetTelemetryId() whenever the form is submitted. As a result, each form submission is also coupled with a unique telemetry ID. If your goal is to block form submissions before they begin, you could also call this function on page load; we chose to call it on submission since our focus was not on preventing bots from accessing our site as a whole, but rather on preventing spammy signups from being passed to our Sales systems (in this case, Hubspot). 

Returning a fingerprinting verdict and unique visitor identifiers

As a result, each form-fill now logs the basic form fields – name, email, company size, and such – but also includes a telemetry ID. We can then use this telemetry ID on the server side – so therefore, fully hidden from bad actors – to look up a ‘verdict’ from our device fingerprinting endpoint. This lookup provides a more holistic set of identifiers (e.g. a browser, network, and visitor fingerprint), a verdict (ALLOW, BLOCK, or CHALLENGE), and some additional context on why the verdict was returned. 

Here’s the basic idea of what the architecture and interactions look like:



Blocking bot spam contact form submissions from our systems

Since our priority is preventing spammy signups from entering our Sales funnel, rather than exposing a CAPTCHA or similar to users, we leverage the verdict and reasons on the backend to filter out questionable submissions. Submissions that return an ‘ALLOW’ verdict are almost always from real humans, and are passed directly to Hubspot via an API call, so that BDRs can quickly work the leads.

Submissions that return a ‘CHALLENGE’ or ‘BLOCK’ verdict are logged to our backend for periodic review by our team – who can see the form submission details, the fingerprinting identifiers, and the reasons for the verdict (typically – clear signs of automation or deception) at a glance. This ensures that we don’t lose or provide prohibitive friction for real users. After all, some legitimate developers take steps to protect their privacy, such as disabling JavaScript, that may result in a challenge verdict. These submissions remain available in our logs and can be pushed to our Sales Systems if needed, but don’t clog up our systems and our data.

Providing stakeholders with the ability to stop individual spammers

Another advantage of using device fingerprinting is that in addition to programmatically stopping bots and users that are engaged in some sort of deception, we can also manually block bad actors if we have one-off individuals who are personally abusing our systems. Based on the telemetry ID included with each contact form submission, we’re able to pass a unique visitor ID to Hubspot. As a result, if Sales reps or BDRs are repeatedly seeing trolling or spam from a user, they can set a rule to block that individual going forward.

This is as simple as a single CURL request or, with <5 minutes of additional configuration, a quick input into a Retool GUI like this:



Spam takes many forms

While spam form signups are a particularly annoying and visible form of spam across the org – since they typically impact engineering, marketing, sales, and sometimes other teams like technical support or customer success – spam takes many forms. This same type of logic and technique can be used to protect other resources, like help ticket submissions or authentication flows.

Or – if you use fingerprinting on page load, rather than on submit, it can also be used to prevent having bots or other invalid traffic skew visitor and conversion data on your contact forms, or to protect ads from click fraud. If you’re interested in learning more, you can read more about how browser fingerprinting works or explore Stytch’s Device Fingerprinting docs.

There are also a wide range of other ways to submit spam form signups; if you have other ideas you would suggest to our team or other use cases we should consider, consider dropping into our Developer Slack to let us know! Alternately, feel free to fill out our Contact Us form to get in touch; after all, we’ll know right away if you’re a real person or a bot.

Thanks for reading, and good luck fighting spam.

---


# What is a bot and how do they work
Source: https://stytch.com/blog/what-is-a-bot/

What is a bot and how do they work

What is a bot, exactly?

A bot, short for robot, refers to computer software programmed to perform automated tasks. Bots are everywhere, from chatbots on customer service platforms that can simulate human conversation, to search engine bots that index web pages.

Bots operate under a wide umbrella of functions, with some designed to help human users navigate the vastness of the internet. Others may serve more dubious purposes, and we’ll cover the mechanics of both in this article.

ELIZA: the birth of a bot



Bots have been around since the early days of computing, with the first one being developed in 1966 by MIT Professor Joseph Weizenbaum. Named ELIZA, this chatbot was programmed to simulate a psychotherapist by responding with scripted phrases based on keywords from the user’s input. It sparked widespread interest and set off a wave of innovation in the field of artificial intelligence, leading to some of the great innovations we’re seeing today.

The early experiments with bots, such as ELIZA, laid the groundwork for their expansion in our digital lives. These rudimentary systems primarily utilized pattern matching and substitution methodologies to simulate conversation, and over the decades, the significant advances in Machine Learning (ML), Artificial Intelligence (AI) and Natural Language Processing (NLP) have revolutionized the capabilities of bots.

Today, these social bots are integral to search engines, aiding in web crawling and indexing, and play a crucial role in engagement on social media platforms.

Types of Bots

So what is a bot in real life, today? There are various types of bots, each designed for specific purposes. They include:

Web scraping bots: These bots crawl through web pages, extracting data such as prices, reviews, and product information.

Transactional bots: These bots handle transactions automatically, such as booking flights or making purchases.

Chatbots: These bots simulate human conversation and are commonly used for customer service purposes.

Social media bots: These bots can be used to automatically post content, like posts, and follow/unfollow accounts on social media platforms. They can also be used for malicious purposes, such as spreading fake news or manipulating public opinion.

Entertainment bots: These bots are designed to entertain users through conversation or gameplay. Examples include virtual assistants like Siri and Alexa, and gaming bots on platforms like Discord.

Health bots: These bots assist in healthcare tasks such as scheduling appointments, providing medical advice, and monitoring health data.

Finance bots: Sometimes known as robo-advisors, these bots handle financial tasks such as stock trading, personal budgeting, and fraud detection.

In recent years, there has been a surge in the use of chatbots vs. other bots, particularly in the realm of customer service. Companies are leveraging chatbot technology to automate repetitive tasks and provide quick responses to common inquiries, freeing up human employees to focus on more complex issues.

Major tech companies like Google, Facebook, and Amazon have all invested heavily in chatbot development, with the goal of creating more efficient and streamlined interactions for their users. But as useful as they’ve proven to be, there’s a substantial risk constantly evolving under the helm.

Bots make up half of the internet



Ever wonder if that person really has 100k followers? Bots account for a significant amount of internet traffic — so much so that they’ve blended right into the human cohorts of many online platforms. We rub shoulders with bots just about every time we hop on a website or social media platform.

According to reports, 47.4% of all internet traffic comes from bots, indicating that nearly every second click, view, or interaction online could be attributed to a bot rather than a human. They are pervasive on social media platforms and various online sectors, including e-commerce sites where they simulate customer interactions, to news platforms where they can amplify specific articles or narratives. Search engines also see significant bot traffic, with bots performing automated queries or scraping content. Even online gaming isn’t immune, with bots often used to automate gameplay or manipulate in-game payments.

The dual nature of bot traffic

Just like humans online, bots can be both benevolent and malicious.

Good bots, like those that power search engines and provide instantaneous customer service, have become essential to the efficiency of online services. While these good bots help manage the flow and sharing of information, increasing engagement and facilitating smoother user experiences, bad bots can turn it all right on its head, leading to a host of cybersecurity challenges.

Malware bots, spam bots, OTP bots, and other malicious bots are frequently implicated in fraudulent activities and identity theft, and can even disrupt services through bot attacks like DDoS.

Understanding this dual nature is crucial for anyone navigating the digital world — from individual users to large corporations.

Bot behavior: The good



No place is more fertile ground for human imitation than the web, where an internet bot can be programmed to act as a human user, creating user accounts and interacting with content. These functions can arguably have both positive effects, like boosting engagement for good causes, and negative ones, such as spreading disinformation.

The staggering power of machine learning and artificial intelligence has made all of this possible at a new scale of impact. We’ll start with the encouraging positive impacts of these powerful virtual machines.

Machine learning and AI: breakthrough bot behaviors

Modern bots have advanced far beyond simple, repetitive tasks. Today, various types of bots leverage cutting-edge technologies such as artificial intelligence (AI) and machine learning (ML) to learn from their interactions and improve their responses over time. This allows them to mimic human-like behaviors, making them harder to detect and block. For instance, a chatbot may use natural language processing (NLP) and machine learning to better understand and respond to human language over time, improving its ability to provide customer service.

Internet bots can also employ advanced techniques like rotating IP addresses or changing user agents to evade detection mechanisms. Some sophisticated internet bots may even employ captcha-solving services to bypass security measures — necessitating stronger CAPTCHA design.

In essence, the complexity of tasks a bot can execute is only limited by the sophistication of its programming. These advanced capabilities make them a double-edged sword – while they can enhance efficiency and productivity when used responsibly, they can also cause significant harm when used maliciously.

Friendly bots on social media

First, the good news: when utilized ethically, and due to the incredible advancements in AI/ML, bots can significantly enhance the user experience on social media platforms. They play a crucial role in customer service, handling common queries automatically and freeing up humans to handle more complex issues.

Bots can also aid in content curation, helping users discover content tailored to their interests and behavior. They’re also able watchdogs, and can be programmed to monitor a platform for harmful behavior such as hate speech or cyberbullying, providing a safer and more inclusive environment for users.



Customer service bots

Customer service bots, powered by natural language processing, can handle a multitude of user requests simultaneously, from answering FAQs to guiding users through troubleshooting processes. These bots work by analyzing the input from the user and providing the most accurate response based on their programming and learned experiences.

In high-traffic customer service scenarios, bots can manage excessive inquiries with aplomb, ensuring that human conversation with live agents is reserved for more complex issues. This type of bot is an amazing time-saver for users, and relieves the workload of human customer service agents, allowing them to focus on more complex tasks and improving overall efficiency.

On the commerce side, advanced customer service bots can personalize interactions by accessing user accounts and their history to provide tailored assistance. This level of service, which mimics human conversation and attention to detail, has become a benchmark for modern customer support.

Bot behavior: The bad & the ugly



Unfortunately, it’s not all sunny days with the advent of machine learning, particularly on social media. Using ML, bots can create human-like posts and build networks to amplify their (often harmful or deceptive) messages. This has made it an essential challenge for social media platforms to detect and prevent malicious bot activity through the spread of dangerous or false information.

Given their capability of mimicking human interactions to a degree that can often deceive actual human users, bot management on these platforms is crucial.

Bot management on social media

Malicious bot activity is an evergreen threat these days, and social media companies invest heavily in bot management solutions to differentiate between legitimate human users and bots. This involves detecting patterns that are not characteristic of human behavior, such as the same address requests being made in a short period (indicating a potential bot attack).

In addition to technical measures, some platforms also rely on user reports and community moderation to identify and remove malicious bot accounts. The constant evolution and sophistication of bots make it a continual challenge with a steep and learning curve.

What is a bot attack?

A bot attack refers to a malicious attempt by one or more bots to compromise, disrupt, or manipulate digital systems, networks, or online services. Bad bots can perform a range of activities, from brute force attacks that aim to break into user accounts to sophisticated schemes that mimic human activity to evade detection. This makes malicious bots a threat to many different types of industries – particularly banks, businesses, and financial institutions.

Risks associated with malicious bot activity

Some of the dangers to businesses and individuals posed by malicious bots & attacks include:

Website scraping: Bots can be used to scrape large amounts of data from websites. These download bots can potentially expose sensitive information.

Account takeover attacks: Bots can attempt to login to user accounts using stolen credentials or brute force techniques. This technique is often seen in Phishing scams.

Price and inventory manipulation: Bots can be used to artificially inflate or deflate prices and manipulate inventory levels.

Ad fraud: Bots can mimic human behavior and generate fake clicks on online ads, costing businesses millions of dollars each year.

Website takedowns: These are often led by Distributed Denial of Service (DDoS) bots that can take down websites by overwhelming them with traffic.

Putting a stop to the malicious bot economy

There’s an entire underground economy based around malicious bots and the profitable criminal opportunities they offer, and monitoring bots and their many associated pathways to fraud is no easy feat.

Given that bots can penetrate an organization’s defenses in numerous ways, a multi-faceted approach is needed to stop malicious bots, including web app security platforms that can detect and block bot traffic, machine learning tools that can learn and adapt to new bot behaviors, and vigilant monitoring by bot managers to continuously update defense mechanisms.

Here are some of the ways businesses and organizations are shutting down malicious bots through technology:

CAPTCHA: Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) is a tool that challenges users to prove that they are human. This is often done through tasks that are difficult for bots to perform, like identifying distorted text or images.

Behavioral Analysis: By monitoring how users interact with a website, it is possible to distinguish between human and bot behavior. Behavioral biometrics, also known as passive biometrics, is an emerging authentication method that analyzes user behavior patterns to identify and verify individuals.

Device Fingerprinting: This involves collecting information about a device’s browser, operating system, and settings to create a unique “fingerprint” that can be used to track and block bots.

Two-Factor Authentication (2FA): Requiring a second form of identification, typically a code sent to a user’s mobile device, can prevent malicious bots from gaining unauthorized access to accounts.

IP Analysis and Blacklisting: Analyzing the IP addresses of incoming traffic can reveal bots, especially if multiple requests are coming from the same address in a short period. Once identified, these IPs can be blacklisted, preventing them from accessing the site.

How Stytch can help



Strong, bot-resistant authentication for systems and devices is one of the most reliable methods at keeping bad bots out. Stytch can help developers and organizations monitor and prevent bot attacks using both physical and API-powered device security measures.

Device fingerprinting identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP address, helping safeguard against bot attacks and other potential breaches.

A step beyond traditional CAPTCHA, Stytch’s Strong CAPTCHA uses complex challenges that are easy for humans but difficult for bots to solve, effectively distinguishing between legitimate users and automated systems.

Step-up authentication allows for more rigorous authentication processes like additional verification steps if a user logs in from a new location or attempts to conduct a high-risk transaction. By leveraging real-time risk assessment, step-up authentication ensures that stronger security measures kick in only when they’re most needed – without adding friction or compromising on user experience.

Stytch also offers ‘unphishable’ multi-factor authentication (MFA) that require users to authenticate their identities using multiple factors, including something they know (like a password), something they have (like a hardware token or a registered device), and something they are (like a fingerprint or other biometric data) — making it challenging for cybercriminals to gain access.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation, or get started on our platform for free today.

---


# What is a common indicator of a phishing attempt?
Source: https://stytch.com/blog/what-is-a-common-indicator-of-a-phishing-attempt/

What is a common indicator of a phishing attempt?

A phishing scam is one of the oldest tricks in the online fraudster playbook: pose as a trusted source or person of authority to gain access to someone’s personal, financial and/or business accounts.

A nightmare for many individuals and businesses, phishing scams were recently cited as the most common type of cybercrime by the FBI’s Internet Crime Complaint Center, with more incidents than any other type of computer crime.

Let’s take a look at what phishing scams, generally referred to as phishing attempts or phishing attacks, are made of, how they look, and how to get ahead of them before the damage is done.

An intro to phishing

Phishing’s origins trace all the way back to AOL in 1995, when Khan C. Smith, a well-known spammer and hacker (where’s his Hollywood star?), apparently invented the term when using the aptly-named hacking tool “AOHell” to impersonate AOL staff and “phish” for passwords among them.

Today, in our increasingly digital, AI-fueled world, phishing attempts have evolved to deploy across a much wider array of channels, so for businesses and individuals, understanding what constitutes a common indicator of a phishing attempt is more critical than ever.

Let’s unpack the various makings of a phishing attempt, with an eye on how to better identify and protect against these attacks.


The anatomy of a phishing attempt



The lasting success of phishing attempts speaks to the inventiveness and sophistication of the modern hacker. Today’s phishing attempts are intricate, highly manipulative methods no longer limited to emails – they can occur via text messages, social media, and even phone calls.

Nevertheless, the goal has always been the same throughout its history: in order to succeed, a phishing attempt must trick individuals into providing sensitive data like login credentials, credit card details, or personal information.

A blend of understanding human psychology and behavior coupled with technological mastery is table stakes for any would-be phishing attacker. Let’s drill down on what phishing looks like, and how it’s done.

An example of a phishing attack

Email is a primary vehicle for phishing attempts, and has been one of the more common and persistent techniques throughout history. A seasoned social engineer will find particular success with the text-heavy, often personal nature of emails and the inbox. Here’s an example of how one such attack might go down in your own inbox.

Imagine receiving an email from “Microsoft Outlook Support,” with a subject line “Urgent: Password Expiration Notice.” It appears legitimate, featuring the Microsoft logo and a professional design. The message warns that your Outlook password has expired and urges immediate action to avoid account lockout. This is a classic phishing tactic, where the scammer mimics an authoritative source, Microsoft, to create a sense of urgency and legitimacy.

The email contains a link, deceptively designed to look like an official Microsoft URL, leading to a fake password reset page. This page, again skillfully mimicking the source, prompts you to enter your current credentials and set a new password. In this telltale step, by entering your details, you unknowingly hand over your login information directly to the attacker. And just like that, you’ve been phished.

This phishing example showcases the common attacker’s strategy: posing as a trusted entity, prompting urgent action, and leading you to a malicious site where you inadvertently compromise your own security.



The telltale signs of phishing attacks

Phishing attacks often begin with a deceptive email or message from a seemingly ‘legitimate’ organization or individual. Using a technique called social engineering, phishing messages are designed to instill urgency or fear, prompting the recipient to respond with the requested information or click on malicious links. These links often lead to fake websites that mimic legitimate ones, tricking victims into divulging sensitive information.

So what is a common indicator of a phishing attempt? It’s usually a predictable cocktail of markers. All phishing attack methods share some traits, and while phishing attacks can be highly personalized and quite convincing, there are several common indicators of a phishing attempt that individuals can look out for:

Suspicious sender: Check the sender’s email address carefully. If it’s an unfamiliar or misspelled address, it could be an indicator of a phishing attempt (or, it could just be your grandpa who still uses AOL).

Urgency or fear tactics: As mentioned, phishing messages often use urgent or fear-inducing language to prompt quick action. Persuasive messages, often masquerading as a person of authority, fall under the common technique of social engineering and are indicators of a phishing attack.

Requests for sensitive information: Legitimate organizations will never ask for sensitive information like passwords or credit card details via email. If an email asks for this information, it’s most likely a phishing attempt.

Generic greetings: Phishing attempts often use generic greetings or no greeting at all, whereas legitimate organizations will address the recipient by name. “Hey, send me your Amazon credentials – it’s your birthday and I’m phishing for ideas based on your purchase history,” said no client, ever.

Poor Grammar and Spelling: Grammatical errors and spelling errors can be common indicators of a phishing attempt. Most legitimate organizations take care to proofread their emails before sending them (yes, we all produce phishy writing sometimes). But while minor grammatical and spelling errors can occur in any communication, phishing emails often contain grammatical errors that are uncharacteristic of professional correspondence.

Fake URLs: Phishing messages often include links that appear legitimate but actually lead to fake websites. Hovering over a link can reveal the true URL and help identify a phishing attempt.

Suspicious attachments: Email attachments in phishing emails pose an added threat and can contain malware that, once downloaded, infects a device and compromises its data. These email attachments might be disguised as invoices, legal documents, or other seemingly important files. This is why it’s crucial to be cautious with email attachments, particularly from unknown or suspicious sources.

The role of social engineering in phishing attempts



Phishing scams are not just technology hacks; they also exploit human psychology. Social engineering is the deliberate and manipulative use of persuasive messages to influence the behavior of someone online. Through social engineering, a victim might be influenced to break certain standard security procedures with a sense of urgency, exploiting their natural human curiosity.

For example, a phishing email may claim that there has been suspicious activity on the recipient’s account and urge them to click on a link or provide personal information to verify their identity. By preying on human emotions and our natural vulnerabilities, social engineering allows scammers to trick individuals into divulging information or unwittingly downloading malicious software.

The devil’s in the details

Without a modicum of legitimacy, phishing messages and emails would rarely find a victim. To appear authentic, they often replicate the logos, color schemes, and overall layout of communications from genuine organizations. This effectively lowers the guard of potential victims and makes them more likely to divulge sensitive information or click on malicious links.

Links in phishing emails often lead to websites that are clones of legitimate sites, designed to steal login credentials or personal information. These sites may have URLs that are subtly different from the authentic ones – a tactic known as clone phishing. With phishing, the devil’s truly in the details.

Spear phishing



Phishing has evolved over time, from more broad attempts at scale using generic language, to highly personalized messaging targeting specific individuals of higher potential value to an attacker.

Spear phishing and whaling are advanced phishing techniques that target such specific individuals or organizations. These methods are more personalized and hence, more difficult to detect.

Spear phishing attacks are tailored to their targets. They may include specific information about the victim, such as their job title, workplace, or personal interests, gleaned from online research or previous data breaches. These emails may appear to come from a trusted colleague or superior, making the request seem more legitimate. As a result, spear phishing attacks have a higher success rate than a generic phishing attempt.

Whaling

Whaling attacks are a form of spear phishing attack directed at high-level targets (whales), such as senior executives. These attacks are thoroughly researched and often mimic the tone and language used in official business communication. The goal of a whaling attack is often to gain access to high-value information or to authorize financial transactions fraudulently.

Whaling attacks are highly sophisticated and require a great deal of planning, making them even more dangerous than other phishing attempts.

Combating phishing attacks



While regular training and awareness programs can help in educating individuals about the risks of phishing, fortifying your website or app’s authentication strategy and flows can greatly reduce phishing attempts and attacks before they even occur, with multi-factor, ‘unphishable’ authentication solutions and device fingerprinting at the helm.

“Unphishable” multi-factor authentication (MFA) from Stych helps prevent phishing attempts by requiring users to authenticate their identities using multiple factors: something they know (like a password), something they have (like a hardware token or registered device), and something they are (like a fingerprint or other biometric data).

Additionally, Stytch offers device fingerprinting, which identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and IP address. This helps safeguard against OTP bot attacks and other potential breaches.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation, or get started on our platform for free today.

---


# Passkey vs. password: a new era of secure authentication
Source: https://stytch.com/blog/passkey-vs-password/

Passkey vs. password: a new era of secure authentication

Ah, the password — simple, personal, and painfully unreliable.

If you’re like many folks, you’re choosing passwords every week that are simple and easy to remember – creating low-hanging fruit for bots and hackers to easily exploit. What’s worse…you’re using them across multiple platforms and accounts, effectively 10x-ing your security risk.

But when you try to think of a more ‘secure’ password, you’re doomed to amnesia. How many times have we all hit that “forgot password?” button only to create a new one we forget two weeks later? Complex passwords, while more secure, present a different challenge — they are hard to remember and manage, especially when users have multiple accounts across various platforms.

This article looks at the inherent flaws of passwords in detail, and why passkeys — a replacement for passwords that is cross-device, cross-platform, and cross-ecosystem — could provide a truly lasting solution that is more secure and user-friendly for users, applications and the many businesses that increasingly rely on frictionless authentication.

The evolving authentication landscape

Passwords as a means of authentication have been in use since ancient times. They served as a rudimentary security measure to protect resources, with soldiers using them to safeguard entrances to forts and camps. Fast forward to the modern era, and we still see the same concept being used today: a secret phrase or string of characters that allows access to something valuable.

But as technology evolved, passwords were no longer just needed for physical protection. With the advent of personal computers and eventually smartphones, digital security became a pressing issue. This is where traditional passwords began to show their glaring vulnerabilities.

The problems with weak passwords

The primary issue lies in the simplicity and predictability of user-created passwords. As humans, our ability to remember complex information is limited, and our tendency to lean towards easily guessable passwords is all too common. Creating unique passwords can truly be a headache.

Our tendency towards password reuse compounds the danger of easily guessable passwords. Many users happily reuse the same password across multiple platforms, such as Google accounts, but most folks don’t know just how risky this can be – or, they simply don’t care enough.

But if one account is compromised, all accounts using the same password are equally vulnerable. The situation worsens with the advent of automated brute force attacks, where bots can attempt thousands of combinations per second, breaching even moderately complex passwords.

Even when users opt for complex passwords, they often forget them due to their less personal or memorable nature, leading to frequent password resets and further undermining security.

Why password alternatives have struggled, too

There is clearly a need for more reliable and user-friendly authentication measures to keep accounts secure. Among the promising potential solutions introduced in recent years to solve the password dilemma are web authentication (or WebAuthn), one-time passcodes (OTPs) and magic links. All three of these fall under the category of something you have or something you are – vs. something you know – making them less portable with the potential to negatively impact the user authentication experience by being more cumbersome.

WebAuthn, endorsed by the World Wide Web Consortium (W3C), aims to replace traditional password inputs with local authentication assisted by devices like security keys, biometrics, or mobile phones. Theoretically, this approach offers a more secure and user-friendly experience, eliminating the need for users to remember complex passwords while simultaneously enhancing protection against phishing and password theft.

However, the anticipated broad adoption of WebAuthn has been slower than expected. The primary barrier is its perceived lack of user-friendliness due to the need for hardware (e.g. security keys or biometrics-enabled smartphones). Passkeys, WebAuthn credentials themselves, are one of the promising new authentication measures designed to address this inconvenience. More on that later.

One-time passcodes (OTPs) are passcodes with an expiration date as part of a two-step authentication process for users to access their accounts by inputting the passcode sent via email, text or authentication app. The natural drawbacks in the experience are obvious: a user needs a phone number to receive an SMS, or must take steps to login to an email account for email-based OTPs, often involving multiple clicks and steps. OTPs via SMS pose security risks such as sim swapping, and a user can sometimes be made to wait more than just seconds for OTPs to deliver — far from ideal.

Lastly, email magic links have struggled to provide the right balance for similar reasons to OTPs, requiring an email account login with multiple clicks, navigation across browsers, and potential lag in the email being received.

Ultimately, while password alternatives like WebAuthn offer compelling security enhancements, their adoption hinges on striking a balance between enhanced protection and user convenience. Until the proper balance is achieved, traditional passwords — despite their flaws — will continue to serve as the de facto standard for user authentication.

This is where the concept of passkeys comes into play as a potentially superior alternative to traditional passwords.

What are passkeys, and what makes them great?



So what are passkeys, and why are they gaining in popularity among not just the tech and auth savvy, but also consumers?

Passkeys are an advanced, biometric-based authentication method developed by the Fast Identity Online (FIDO) alliance, aimed at replacing traditional passwords. They employ the WebAuthn standard with local biometric verifications, such as FaceID or TouchID, to generate a pair of asymmetric keys for secure authentication.

Most importantly, passkeys can be shared and synced across various devices and platforms – offering unmatched portability and convenience in biometric-based authentication.

Let’s break down how the battle of passkey vs password authentication took shape.



A secure alternative to the password?

In 2021, FIDO – composed of major tech platforms like Apple, Google, Microsoft, and even a little auth provider you may have heard of called Stytch – introduced passkeys as a new ‘passwordless’ technology in order to enhance the usability of biometric authentication for consumers. While not a new concept, passkeys promised to address significant user experience challenges associated with existing biometric authentication technology.

Passkeys offer a unified solution to the problem of managing multiple accounts. They allow users to securely log in to various services without the need to remember or input a correct password for each. This not only enhances security but also streamlines the authentication process, making it more user-friendly.

Major cloud platforms including Google, Apple, and Microsoft, as well as mobile operating systems like Android and iOS, are increasingly adopting passkey technology, shifting away from relying on passwords alone for their authentication strategies.

Passkeys and multi-factor security for online accounts

Passkeys are often integrated with biometric authentication systems, such as facial recognition or fingerprint scans. Biometrics is one of the most crucial advancements of multi-factor authentication in recent years. Passkeys are designed to combine the factors hardest to hack: “what-you-have” (i.e., the private key) and “what-you-are” (i.e., your biometric information). This has the potential to significantly bolster security beyond two factor authentication, protecting against common threats like phishing attacks.

Biometric authentication adds a level of physical proximity and personalization to the security process for online users and businesses as well. For instance, a user might use a face scan on their Apple device to authenticate their identity, which then grants access using the passkey. It’s more secure than passwords but also faster and more convenient, reducing the average time spent authenticating.

Multi-device syncing: the secret passkey sauce



Perhaps the most important element for adoption of newer authentication methods is the user experience. Fortunately, passkeys leapfrog the WebAuthn UX dilemma in one crucial way: the ability to sync authentication across multiple devices.

As with WebAuthn, logins with passkeys are almost instantaneous, often requiring just a simple biometric check or the proximity of a device. However, while the technical backbone of passkeys lies in WebAuthn technology, what makes them truly unique is that you can sync them across multiple devices. The single-device limitations of WebAuthn may have finally met their conqueror.

This combination of passkeys and the cloud (as well as bluetooth/NFC technology if the user is physically close to their devices) now means it’s possible for a passkey created on your laptop to be easily ported over to your phone, unlocking the device and its applications alongside a whole new level of UX joy.

Not surprisingly, operating systems like Windows and macOS, along with mobile platforms such as iOS and Android, have thrown their confidence behind the future of passkeys. With cloud support from these major players (iCloud, Google Cloud, and Azure), and the likely widespread adoption that results, users can enjoy the exact same (minimal) security and authentication steps on any device they use – whether on desktop or smartphone, Android or iOS.

The future of passkeys: barriers and opportunities



As we continue to witness broader adoption, passkeys are uniquely positioned to redefine digital authentication for the better, ensuring a safer and more efficient digital experience for businesses, developers and users worldwide.

Despite the incredible flexibility and efficiency they can provide, a seamless passkey authentication experience hinges on cross-platform compatibility – and not every end user will be set up for this given the variance among operating systems and devices. Being able to log in to your Chrome browser using a passkey stored on your Apple device sounds amazing but may not be an experience within reach for some developers and their users.

Some of the challenges to adoption of passkeys facing businesses, developers, and end users include:

Support for devices and operating systems: While industry giants such as Apple, Microsoft, and Android have announced their backing for the latest iterations of their operating systems, it may take considerable time for all users to transition to these updated versions.

Adoption by developers, businesses and their applications: Applications and businesses need to implement the necessary updates to integrate passkeys into their sign-up and login processes and consider how these changes impact the user model and relevant account recovery procedures for a smooth rollout.

Acceptance by users: Consumers still value having multiple authentication options, and some may show hesitation in embracing a new biometric method.

With these challenges in mind, Stytch can offer both the passkey enthusiast or the password adherent multiple options to face the ever-evolving threats in auth land. We recommend an approach to passkeys that thoughtfully balances the needs of your end users with the security requirements of your industry. One size fits all doesn’t apply here. Read more on Stych’s approach to passkeys and how we can help businesses and developers find the strategy that fits their user’s best.

Not ready to move forward on passkeys but want to improve your password setup? By anticipating our human tendency towards password reuse, Stytch has built breach-resistant layers into our Passwords solution so you can protect your users against using weak and compromised credentials and prevent data breaches.

To learn more about our approach to biometrics — and how we’re opening the door to multi-device, phishing-resistant passkeys — get in touch with one of our auth experts. You can also sign up for a free account to try our solutions out for yourself.

---


# Introducing Passkeys authentication
Source: https://stytch.com/blog/introducing-passkeys-authentication/

An overview of Stytch's passkey product, and the nuances in setting up passkey authentication today

We are incredibly excited to announce Stytch’s Passkeys offering, a complete developer toolkit for building passkeys into web and mobile applications.

As members of the FIDO alliance, we’ve long believed that passkeys will serve as a turning point in the advent of passwordless authentication. With a fraction of the security risks and user frustrations that come with passwords, plus early advocacy and adoption among tech giants like Google, Apple, and Microsoft, we believe passkeys are the death knell of passwords.

However, passkeys have faced some significant headwinds in their adoption because there are many factors that lie under the hood for developers to consider when they’re implementing passkeys. While passkeys can feel magical and seamless for users, it can be a significant undertaking for developers to build a seamless experience and uphold the security promise of the technology.

This is where Stytch’s Passkeys offering comes into play, by abstracting the complex logic and extensive development effort needed to build a secure, seamless passkeys experience – into just two simple API calls.

In this article, we evaluate the factors that complicate building passkeys authentication and the decisions that Stytch made for our solution to reduce the implementation effort needed for developers to offer passkeys to their customers.

Core considerations when implementing passkeys

Since their release earlier this year, passkeys have generated a lot of hype. Much of that hype is well-earned – as designed, passkeys have the potential to become a drop-in replacement for passwords, with improved UX and security. This is because – again, as designed, though not necessarily as implemented – passkeys are WebAuthn credentials that are synced to the cloud, discoverable, require user verification, and work across devices.

The dream passkeys promise is that from any device, users will be able to simply use their faceID or fingerprint to autofill their WebAuthn credentials for any app or service, regardless of whether they’re on their iPhone, their iPad, or even their work’s SurfacePro.

In reality though, most developers cannot guarantee their users this exact experience – at least not yet. In fact, while passkeys have the potential to offer the most secure and frictionless login experience to-date, they require a lot of decisions and work for developers to get right.

Today, to provide the best possible version of passkeys to their users, developers have to contend with three considerations:

The end user’s platform

The technical configuration of the passkey

The UI implementation

In the following three sections, we’ll look at each of these factors, why they vary, and how they determine both the experience and security of a given passkeys implementation.

1. The end user’s platform

Can you control it? No! 

Developer considerations: Cloud syncing, user verification

When an end user creates or uses a passkey, their platform is comprised of a combination of the following:

Operating System (OS) – e.g. MacOS, Windows, iOS, Android

Cloud Ecosystem – e.g. Apple iCloud, Google Cloud

Browser – e.g. Chrome, Safari, Edge, Firefox etc

Device – The type of device they’re using and whether it supports some method of biometric authentication (e.g. Face Unlock, Fingerprint Unlock)

Password Manager – The password manager they’re using – and whether it is the one built into their OS or Browser or a 3rd party password manager (e.g. 1Password)

Platform effects on syncing across devices

Today, the state of syncing support for Passkeys looks like this:



As you can see, depending on the operating system and browser an end user chooses, their passkeys’ ability to sync to the cloud varies greatly – even more so when you get into the type of authenticator the passkey uses (we’ll get into this more in a sec). 

Platform effects on user verification

One of passkeys’ most powerful protections against breaches is its inclusion of user verification as part of the authentication process. Depending on how you view it, it could be argued that passkeys give applications and services a multi-factor authentication experience through a single auth factor.

As designed, passkeys combine two of three types of user verification: the “what-you-have” (i.e., the private key) and “what-you-are” (i.e., your biometric information). These are generally considered to be much harder to hack or forge than the “what-you-know.”



But if someone’s device doesn’t offer biometric authentication, the two-in-one MFA assurance isn’t nearly as strong: it is much easier to illicitly obtain and fake someone’s PIN or pattern unlock than it is to fake their thumbprint or face. 

Additionally, if someone is using a 3rd party password manager to create and store their passkeys, the protection of their passkeys hinges on how they secure their password manager. It could actually be the case that the only thing needed to unlock their password manager and thus use their passkeys is simply a password.

Platform effects on cross-device compatibility

In order for passkeys to be useful in cross-device scenarios, they generally need to be synced to the cloud. These scenarios typically involve using a passkey on a mobile device to sign into a service on some other device on which the user does not have a passkey. If the user’s passkeys do not all sync to the cloud, there is a high chance that a lot of them will never be usable on additional devices. So by extension, if a passkey is created on an OS/device/browser combination that doesn’t allow for this, the usefulness of those passkeys in cross-device scenarios will be limited. 

Bottom line

Depending on the platform your end users choose, you may not be able to guarantee the same degree of cloud syncing or secure user verification.



2. Technical configuration

Can you control it? Yes!

Developer considerations: Cloud syncing, discoverability, user verification, cross-device compatibility

While a developer does not have much control over their end user’s platform, they do need to make several decisions regarding the technical configuration of three key characteristics: the authenticator type, the resident key, and user verification method. 

Authenticator type

Possible values: Platform, Cross-platform, Any

Controls: Whether the authenticator used to generate the passkey can be of the type built into the device (e.g. Mac with Fingerprint Unlock), or a removable authenticator (aka roaming authentication) such as a hardware key (e.g. YubiKey)

Resident key

Possible values: Required, Preferred, Discouraged

Controls: Whether the authenticator stores certain metadata (i.e. origin domain, user id, name) upon passkey creation that make the passkey discoverable client-side (i.e. one that is usable in authentication requests where the relying party does not provide credential IDs).

User verification method

Possible values: Required, Preferred, Discouraged

Controls: Whether the user need to conduct a verification step (e.g. biometric based unlock) before the authenticator can generate or fill in a passkey

Technical configuration effects on syncing across devices

In addition to various platforms coming with their own cloud syncing limitations, the authenticator type also has a huge effect on the ability of passkeys to sync to the cloud.

If we look at the chart reflecting the current state of passkeys, the four OS/browser scenarios that currently offer syncing ONLY do so when the passkeys are created with platform authenticators. This means that the alleged “seamless” experience offered by passkeys is actually only available if the end user stays within a given provider’s ecosystem, browser, and devices. 

Though support for broader syncing capabilities is growing, a developer optimizing for syncing experience may want to restrict the creation of passkeys only to platform authenticators.

Technical configuration effects on discoverability

In order for passkeys to be discoverable, they need to be created as resident keys. This requires the authenticator to store some metadata – including the relying parties domain and a user ID – and thus requires an authenticator that supports storing data.

But unfortunately, because not all authenticators can store data, not all authenticators can create resident key passkeys. Generally, platform authenticators can store data, but not all roaming authenticators can.

To complicate things further, some roaming authenticators do support storing data – but only a limited amount (e.g. enough for 8 passkeys). After that they cannot create more passkeys, and the only way to do so is to wipe all of the existing ones!

If a developer wants to ensure that Passkeys will be discoverable they should make sure they require them to be resident keys.

Technical configuration effects on user verification

As mentioned in instances of device variation, the user verification methods configured by developers also has a huge effect on…you guessed it – user verification. The developer has some choices here and ultimately it is a balance between security and usability 

Stytch defaults to the “preferred” value here which results in user verification being required on all the major platforms a user might be using – all without making the login flow unusable for edge case scenarios like users who strictly prefer or need to use a hardware key that supports discoverable credentials.

Technical configuration effects on cross-device compatibility

The cross compatibility of passkeys can be facilitated in two ways:

Via cloud syncing of the credential

Via the CTAP protocol.

CTAP is built into all major devices and browsers. This is what you are doing when you scan a QR code to use a passkey on your phone, but it is also what’s used by a hardware key to communicate to your laptop via the USB port or to your phone via NFC.

By defaulting passkeys to be resident keys, we ensure that they can sync to the cloud and become available across all your devices. And, when you are using a device you do not own, CTAP enables you to use your passkey in that situation too.

Bottom line

Though the user’s platform is largely outside of a developer’s control, there are several key decisions involved in the technical configuration of a given passkeys implementation that can have a huge effect on both the security and user experience, affecting nearly every core attribute of the standard passkeys definition!

Stytch’s passkeys solution defaults to passkeys settings and setup that maximize the security and user experience of passkeys. However, we still provide developers with the flexibility to customize their passkeys configuration as they see fit.

3. UI implementation

Can you control it? Yes!

Developer considerations: Discoverability, cross-device compatibility

Nowadays when you use a password manager, it’s all but expected that the app will also come with an auto-fill feature. For convenience, many implementations of passkeys also incorporate this user interaction. But to do that, two features need to be enabled:

Conditional mediation: This is what allows a given website or app to check the device for available saved credentials and display them as a suggestion without disrupting the login flow. 

Autofill: As the name suggests, this is the feature that accepts the suggestion, and actually automatically fills a password or passkeys field with the appropriate information. 

While this may seem like a relatively marginal UI consideration, the autofill UI and its underlying requirements have a couple of implications for the overall passkeys experience.

Autofill’s effects on discoverability

Passkeys’ discoverability depends on two factors: the credentials must be set as “resident keys”, and they must have a UI that can autofill. Without conditional mediation enabled, there’s no way for the relying party (or auth provider) to search a device or “discover” the saved passkeys. 

Bottom line

Though a seemingly minor decision, the autofill UI has a big impact on your end user’s experience, and the extent to which passkeys feel like a low-lift / easy replacement for passwords. This can have big downstream effects on adoption and user engagement in the long-run, so don’t overlook this crucial feature!

Because passkeys discoverability and implementation are such a crucial component of the passkeys experience, Stytch’s solution automatically ensures that conditional mediation and autofill are supported to provide the best user experience for your customers.

The right passkeys for your use case

At Stytch, we have made certain default decisions around our own Passkeys implementation that focus on maximizing security and optimizing the UX. That said, the reality is that there is no single “one-size fits all approach” to auth, and that includes Passkeys. So in building our platform, we’ve implemented defaults that we recommend based on working extensively with FIDO, the OS and device manufacturers and development community – all while providing as much customizability for developers as possible.

Like with all authentication factors, if and how you use passkeys should always be in response to two main factors:


Security requirements: What are the security requirements of your industry, and what kind of information are you handling?

The needs of your end user: What kind of devices and browsers are most popular with your users? What kind of login experience and auth factors are they currently used to?

Stytch makes it easy to build and implement passkeys

Believe it or not, there are many more configuration decisions when it comes to passkeys – like how to prevent password managers from disrupting autofill functionality and other details – which most product developers probably don’t want to wrestle with but still impact the end user experience. Or even if they want to, most developers simply don’t have the time to geek out down passkeys rabbit holes that aren’t essential to advancing their core product.

The good news is you don’t have to be a passkeys expert to provide an optimal passkeys experience to your users – that’s where Stytch comes in. Our Passkeys solution requires just two APIs: one to create the passkeys, and one to authenticate them. We also offer frontend SDKs with prebuilt UIs, so all you need to do is drop them in. No fiddling with authenticator types or resident keys, no mapping out all the different device OSs – we’ve set up smart defaults so you can plug and play, and get back to building your core product. 

Get started for free or schedule a demo today!

---


# Log in with Passkeys: an example app using React and Stytch’s frontend SDK
Source: https://stytch.com/blog/log-in-with-passkeys-an-example-app/

In this article, we’ll walk you through a React example app that can log in users in with passkeys, powered by the Stytch frontend SDK and its pre-built UI components. 

Today, Stytch launched Passkeys with the most complete and intuitive developer toolkit available. Our Passkeys offering includes:

REST API endpoints

Backend SDKs for Go, Ruby, Python, and Node.js 

Mobile SDKs for Android, iOS, and ReactNative

Frontend SDKs for vanilla JavaScript, React, and Next.js 

Pre-built UI components that can be easily configured and customized 

For those unfamiliar, passkeys are a biometrics-based, phishing-resistant, replacement for passwords. They are already being used by industry leaders such as Google, Github, Amazon, Uber, Shopify, LinkedIn and more.

For developers, it’s essential to implement the most secure and convenient authentication methods – like passkeys – for your applications to protect your users’ account while still delivering a frictionless user experience. However, passkeys implementation can be quite complicated, and developers need tools they actually like working with and solutions that will integrate with their architectures. This is where Stytch steps in, empowering developers to easily build passkey-based authentication flows into any stack or code base.

In this article, we’ll walk you through a React example app that can log in users in with passkeys, powered by the Stytch frontend SDK and its pre-built UI components. We’ll focus on the key steps and important parts of the app’s code, including:

The developer environment.

The React app structure.

The login page for authenticating with passkeys.

The dashboard page where you can register and manage your passkeys.

The full example app code is open-sourced and available on Github.

A sneak preview of Passkeys in action

Before diving, let’s take a peek at what the end-to-end flow looks like. Here is a demo video of our example web application showing the seamless login experience of passkeys across various devices.

Try passkeys for yourself and explore the live demo app hosted at https://stytch-passkey-demo.app.


Setting up the developer environment

Prerequisites

If you want to follow along and run the example app on your machine, make sure you have the following set up:

A Stytch account. If you don’t have one, sign up to get your API keys. 

A Stytch Consumer Authentication Project.

Node.js installed.

Clone the example app

Run the following commands in the terminal to clone the example app repo. The example app was bootstrapped with create-react-app and has a similar folder structure.



Next, install the dependencies at the example app’s root directory and ./server directory.



Get your Stytch API credentials and enable the SDK

Log in to your Stytch account. If you don’t have one already, create a Consumer Authentication project. 



In the Dashboard, click Frontend SDKs under the Configuration section of the sidenav. Then click Enable SDK in Test. We’ll be using the Project’s Test environment, but the steps are identical if you want to use the Live environment.



By default, the SDK settings will have localhost:3000 as an authorized domain – which is the port we’ll use to run our React example app. Under Authentication products, make sure the WebAuthn toggle is on and enabled.

Navigate to API Keys in the sidenav and copy your Project’s credentials: the project_id, secret, and public_token. Create a .env.local file and populate the fields with your Project’s credentials with the following key value format:



Running the example app locally

After completing all the setup steps above the application can be run with the command:



The React application will be available at http://localhost:3000 and the Express server will be available at http://localhost:3001.

And voila! You should have a fully functioning website called SurveyAmp running locally on your machine.

Breaking down the React app structure

Now that you have the app running, let’s break down how the code is structured and built at a high-level.

We’ll be analyzing simplified versions of the example app’s code to better explain how the auth flows function.

Three main pages

Open the App.tsx file and you’ll find the React application is organized into three main pages.

A login.tsx page, which hosts the login component for passkeys.

A dashboard.tsx page, where you register and manage your passkeys after logging in.

A home page at the root / directory, which simply redirects you to either the login page or dashboard page if you’re authenticated.



Initializing the Stytch SDK client

Open the index.tsx file at the example app’s root directory. There are three Stytch SDK imports we need to be aware of:

<StytchProvider>, the wrapper component for the SDK client.

StytchUIClient, the constructor for using pre-built UI components.

StytchClientOptions, a config object for setting cookie and domain options.



Refer to the SDK Reference for a full list of settings you can control with the StytchClientOptions. For the example app, we only need to set the names of the cookies that contain the newly minted JWT sessions after authentication.

The StytchClientOptions object and your Project’s public token, from the .env.local credentials file we just set up, are arguments for the StytchUIClient constructor. The StytchUIClient is then passed to the <StytchProvider> component which wraps the <App> component, ensuring the Stytch SDK is loaded everywhere and can control the authentication state across our application. 

The Stytch SDK is officially bootstrapped, which also means we can call the SDK methods headlessly anywhere.



Breaking down the login.tsx page

Now that the high-level React structure has been covered, let’s break down the individual app pages starting with the login.tsx page.



The <StytchLogin> component with passkeys and OTP

The <StytchLogin> component is Stytch’s configurable and customizable login and signup form. Meant to be a complete out-of-the-box experience, the component will handle all the auth logic and requests to the Stytch API. It only needs a few things to get up and running.

A config object: which bootstraps the authentication methods of your choice. For this example app, we’ll use both passkeys and One-Time-Passcodes (OTP) as auth methods.



Why use OTP? For signup. Stytch Passkeys can only be used for login. In order to ensure account recovery, we recommend and enforce users to have a verified email or phone from primary auth factors like OTP, Magic Links, or OAuth.

A callbacks object: which executes triggered functions of custom logic after specific authentication events. For the login page, we’ll wire navigation functions that will redirect users to the dashboard page after logging in successfully with either OTP or passkeys.



Putting it all together, the <StytchLogin> component takes the defined config and callbacks objects as props. 



The <StytchLogin> component renders the fully functional login form UI. For signup and first login, users will enter an email address or phone number and authenticate with OTP which will redirect them to the dashboard page. 

If you click on the text input, the autofill behavior will bring up a browser prompt for passkeys.



Breaking down the dashboard.tsx page

Now that users can signup and login with OTP, let’s move on to the dashboard page which acts as a centralized hub for registering and managing their passkeys. Users must be logged in to access the dashboard.



The <StytchPasskeyRegistration> component

<StytchPasskeyRegistration> is another pre-built UI component that will handle all the registration flows for passkeys. Conveniently, it accepts the same props as <StytchLogin>. The view can be as simple as this:



With the <StytchPasskeysRegistration> component, users can create multiple passkeys, edit their names and labels, or delete them all together from their accounts. It’s an all-in-one management interface for the web application’s passkeys, automatically handling the public-private key orchestration between the application’s domain, the device, and Stytch – all under the hood.



With just two components, <StytchLogin> and <StytchPasskeyRegistration>, users can create and log into the application using passkeys!

Step-up authentication for extra security

Our dashboard.tsx page also has an extra layer of security and safeguards when managing passkeys. Given their nature as credentials, passkeys need to be treated as highly sensitive and personal information.

In our example app, we’ve integrated app logic where users, when attempting to create new passkeys or modify existing ones, will be prompted to perform step-up authentication. This process involves verifying their session with two distinct auth factors. For example, if a user logs in with passkeys, they’ll be prompted to step up and authenticate with OTP.



Step-up authentication is a crucial security strategy that balances usability with robust protection. Fortunately, Stytch’s SDK makes implementation straightforward and intuitive. 

Because we can invoke the Stytch SDK client headlessly, we can simply call any required Stytch auth methods and seamlessly wire them to the UI.



The Dashboard view

If we extend this step-up logic further to account for any combination of auth factors the application supports, the final Dashboard view will end up looking like this:



Conclusion

And you’ve done it! Throughout this walkthrough, you’ve gained a comprehensive understanding of the application’s set up, its structure, and the Stytch SDK implementation of passkey authentication and management with the additional security of step-up.

You can explore the live demo site or find the full source code on Github.

Ready to implement passkeys in your project? Check out the Docs and start coding.







---


# Passkey authentication: The cure for password dependency?
Source: https://stytch.com/blog/passkey-authentication-the-cure-for-password-dependency/

Discover the potential of passkey authentication in replacing passwords with our in-depth exploration of this emerging technology. Learn how passkeys, leveraging WebAuthn credentials and cloud syncing, offer enhanced security and user convenience across devices. Understand the challenges and opportunities in adopting this passwordless future, including industry standardization, user education, and practical implementation tips.

Our traditional reliance on passwords has proven to be one of the most glaring authentication vulnerabilities in modern times. Phishing attacks, password reuse, and credential stuffing are just a few of the risks still raining upon our fragile digital ecosystems with no end in sight.

Enter passkeys. Passkeys are a groundbreaking approach developed by the FIDO Alliance, offering a secure and potentially user-friendly (cross-platform!) alternative to passwords, and marking a significant step towards a ‘passwordless’ future.

Here we’ll cover what passkeys are and some examples of how they work their authentication magic.

What are Passkeys?

At their core, passkeys are biometric-based credentials, created by the WebAuthn standard, that are synced to the cloud, discoverable, require user verification, and work across devices. Passkey authentication has the potential to replace traditional passwords due to its innate security and portability.

The key aspect of passkey authentication is that it does not rely on passwords. Instead, the user’s identity is verified through a cryptographic exchange between the device and an authenticating server.

Authentication via passkeys and biometrics looks something like this:

Upon selecting the passkey login option on a website or app, the user’s device immediately prompts for biometric authentication, such as a fingerprint scan, facial recognition, or similar alternative such as PIN.

The user simply provides their biometric input for quick verification, and once authenticated, the passkey automatically logs them into their account, eliminating the need for manual password entry.

Authentication devices can be plug-in hardware like Yubikeys or embedded into a device like a smartphone’s or laptop’s biometric sensor.

Public key cryptography and the cloud

Passkeys use asymmetric public key cryptography to create a unique pair of public and private keys. The unique aspect of passkeys lies in their dual components: the private key, which is securely stored on the user’s device, and the public key, which is registered with the application (such as an online shop). Excitingly, the cloud enables passkeys to be stored and synced across devices and operating systems, unleashing a whole new level of user-friendly authentication with the cloud storing and syncing the user’s private keys.

While challenges remain in broadly scaling the benefits of passkey authentication to diverse end users and hardware, increasing adoption of passkey authentication options by cloud services giants like Microsoft, Google, and Apple are certainly pointing things in a promising direction.

Passwordless authentication with passkeys, step-by-step



Let’s take a closer look at what passkey authentication looks like across the user journey.

Account Registration: Passkey authentication begins when a user visits a site and sets up a new account on a platform that supports passkey authentication. The user’s device, be it an Apple device, an Android phone, or any other smart device, generates a new passkey for this account.

Key Storage: The private key is securely stored on the user’s device, protected by the device’s security measures like Touch ID, facial recognition, or device PIN. Meanwhile, the public key is sent to the service provider’s server .

Cloud sync: The private key on the device can be synced with cloud platforms like iCloud, Google Cloud, and Microsoft and even credential managers 1Password, enabling its use across multiple devices owned by the user.

Sign-In Request: When the user attempts to access the service later, the server sends a challenge to the user’s device, initiating the authentication process.

User Approval: The user approves the sign-in request. This could be through a biometric sensor or a simple approval on the device.

Responding to the Challenge: The device responds to the server’s challenge using the private key. This process is securely conducted and is invisible to the user.

Access Granted: The server verifies the response using the public key it has on file and grants the user access to their account.

With so little friction to the user, it’s easy to see why and how passkeys offer a better experience than traditional password-based authentication and even WebAuthn alone, which is bound to a single device.

Keep in mind, however, that a perfect implementation of passkey auth across platforms is not always possible. You may not be able to ensure the same level of cloud syncing or secure user verification across all platforms or devices chosen by your end users. For example, not all devices can handle biometric authentication, leading to a less-than-ideal, more hackable MFA procedure using PINs or patterns rather than the virtually inimitable fingerprint or facial scan.

But that’s OK! For now. Progress is the prize we’ve been waiting for, technology advances rapidly, and even passkey auth in its early stages delivers significant advantages.

Unlike passwords, passkeys are super secure

Passkeys have the power to mitigate common security issues and vulnerabilities to brute force attacks. Now that we’ve spent some time focusing on the UX benefits of passkeys for users, let’s zero in on their security advantages.

The password buster

By design, passkey authentication eliminates the need for users to remember complex passwords, which often leads to password reuse and increases vulnerability. This “password fatigue” phenomenon is a common cause of security breaches. With passkeys, there are no passwords to remember, no sticky notes to be lost, and no password docs accidentally flushed down the digital trash can. This also means there are no passwords to steal — hackers and thieves will find little to feast upon once passkeys go mainstream.

WebAuthn

Passkeys are a form of WebAuthn, which provides an open authentication standard using public key cryptography, eliminating the need for passwords. With WebAuthn, website users can use devices they already own, such as their mobile phones or security keys, for secure and easy authentication. This promotes better security practices while enhancing the user experience (though it does not solve for the multiple device login issue that can hinder UX — that’s where passkeys come in).

WebAuthn was designed with privacy in mind and does not rely on personally identifiable information (PII) for authentication. This means that even if a company’s database is breached, user accounts are still secure as the passkey itself is not linked to any personal information.

With the addition of private key storage in the cloud, passkeys are moving the WebAuthn needle further towards a far more seamless yet equally secure UX across devices and platforms that doesn’t rely on multiple-device authentication.



The benefits of physical devices

One of the primary reasons passkeys are a superior method of authentication is their requirement for physical device proximity. This adds an extra layer of security as it significantly reduces the risk of unauthorized remote access to user accounts. A potential attacker not only needs to know the passkey but also needs physical access to the device, making it exceptionally difficult to get in.

When combined with additional security measures like biometric checks, the likelihood of a security breach dims even further. Passkeys are inherently phishing-resistant, as the authentication process requires physical proximity and often a biometric check, rendering remote phishing attacks far less effective.

In essence, passkeys can provide a multi-factor authentication experience through a single authentication factor, combining two out of three types of user verification: the private key (what you have) and biometric information (what you are). These verification methods are widely recognized as more secure and difficult to hack or forge compared to traditional knowledge-based authentication (what you know).

Cross-platform in practice: progress & challenges



So how will passkeys find their way to the top? Major operating systems and platform/cloud vendors have already started to integrate passkey support, making it increasingly possible to use passkeys across various devices, including mobile phones, tablets, and laptops. But challenges remain.

Let’s cover some markers of progress and remaining hurdles towards achieving a passwordless future.

Synchronization in the cloud

As mentioned, the ability to synchronize passkeys across devices massively raises the bar for user convenience and accessibility. For instance, Apple devices allow passkeys to be synchronized via an iCloud account, ensuring that users can access their accounts from any trusted device. Similarly, Google accounts offer passkey synchronization for Android devices, providing a cohesive experience across the user’s devices.

These features are not yet available for all passkey providers due to the multitude of devices and OSs that users and employees enjoy, and thus may prove challenging for developers to implement universally.

Industry standards and collaboration

To ensure the smooth adoption and interoperability of passkeys, it is crucial that industry-wide standards are established. This includes standardizing the format of passkeys, as well as developing protocols for their storage and transmission. The FIDO (Fast Identity Online) Alliance (of which Stych is a proud member) is working towards these goals, and its efforts have already resulted in the WebAuthn standards. However, widespread adoption of these standards may still take time as different vendors may have varying interpretations or implementations of the standards that support passkeys.

Collaboration may also be challenging due to competitive pressures and differing business objectives. Ensuring the same level of security across various platforms can be resource-intensive and complex. Developers should account for potential vulnerabilities in each platform and create solutions that are effective without compromising the user experience.

Lastly, creating a seamless user experience across all devices and platforms requires extensive testing and may require updates or changes to existing software, which can be time-consuming and costly.

Passkey authentication in practice



When integrating passkeys into your system, two critical considerations should guide your approach:

Industry-specific security needs: Consider the security demands of your sector and the nature of the data you’re handling. Are you working with sensitive financial data? This, for example, might lead you towards a passkey strategy with less reliance on the cloud for passkey storage, and more deliberate use of hardware or multi-device WebAuth.

End-user requirements: It’s important to take stock of the common devices and browsers used by your audience. Understanding their preferences for login experiences and authentication methods will help reveal the right auth fit – not too snug, nor too loose.

Simplifying passkey authentication with Stytch

The intricacies of configuring passkeys can be overwhelming when considering specific authenticator types, resident keys, and compatibility across diverse device operating systems. These are technical details that, while important, might be too time-consuming for product developers who need to focus on their primary offerings — but it’s not the end of your passkey journey!

You truly don’t need to be an expert in passkeys to provide a top-notch experience to your users. Our passkeys solution is streamlined and efficient, requiring only two APIs: one for creating passkeys and another for authentication.

To further ease the integration process, we also offer frontend SDKs equipped with ready-to-use UIs. This setup allows for quick implementation without the hassle of dealing with various authenticator types or different device operating systems. We’ve established intelligent defaults so you can easily integrate our solutions and focus on what you do best — developing your core product.

Every company and developer journey in authentication is unique. Whether you’re looking to get started for free or wish to explore our solutions through a demo, we’re here to assist. We’ll handle the complexities of passkey authentication, so you can dedicate your resources to your product.

Get in touch with us today and take the first step towards a more secure, user-friendly authentication system.

---


# Beating back bot fraud in 2024
Source: https://stytch.com/blog/beating-back-bot-fraud-in-2024/

Understand what bot fraud looks like 2024 and how to prevent it. Dive into various bot fraud types, from account takeovers to fake reviews,Explore what bot fraud might look like in 2024. and understand their impact on businesses. Discover advanced techniques and solutions, like Stytch's bot-resistant authentication, to combat these digital threats effectively. Stay ahead in the fight against bot fraud with our comprehensive analysis and expert insights.

The rise of bot fraud has been astounding in the past few years and is estimated to cost businesses billions of dollars annually. According to Sift’s Q2 2023 Digital Trust & Safety Index, account takeover (ATO) bot attacks spiked by a staggering 427% in Q1 2023, compared to all of 2022.

Bot fraud involves the use of automated software programs, known as bots, to conduct illicit activities online. These activities range from unauthorized access to e-commerce and bank accounts, to the inflation or falsification of reviews online, to ever more sophisticated financial frauds.

In this article, we’ll delve into the different types of bot fraud and the measures that can be taken to combat them.

Understanding bot fraud

Bot fraud is characterized by the deployment of bots to mimic human behavior and interact with our digital systems, often with malicious intent. These bots can automate tasks at superhuman scale and speed, making them a potent tool for fraudsters.

Bot fraud can take many forms. Below are 7 of the many suits commonly worn by bots:

Click fraud: In this type of fraud, bots simulate clicks on online advertisements, artificially inflating the number of clicks and leading to a waste of advertising budgets.

Account takeover (ATO): Bots often try to access user accounts by guessing or stealing login credentials (often bank accounts), using the stolen credentials to carry out various fraudulent activities.

Spam messaging: Bots can be used to send spam emails, messages, and comments on social media platforms, often promoting illegal products or services.

Impersonation: Some bots are designed to impersonate humans on online platforms, creating fake profiles and generating fake engagement such as likes and follows.

Inventory hoarding: In this type of fraud, bots are used to buy up large quantities of limited edition products or concert tickets, reselling them at inflated prices.

Web scraping: Bots can be programmed to automatically gather data from websites, often for competitive intelligence or price comparison purposes.

Fake reviews and ratings: Bots can manipulate online reviews and ratings, creating false positive or negative feedback to influence consumer decisions.

Credit card and bank credential fraud: Bots attempt ATO attacks to gain control over user accounts for financial exploitation. Services like Stripe and Plaid, which offer API endpoints for credit card and bank account verification, are frequent targets of these types of attacks.

SMS toll fraud: Bad bots send expensive SMS messages through international mobile operators. This fraudulent activity is more common with international mobile networks.

Compute resource fraud: Platforms offering compute resources, such as Replit, AWS, Github, Railway, and Heroku, attract bad bots seeking free computational power. The open availability of these valuable resources makes these platforms prime targets.

The evolution of bot fraud

In their early days, bots were simple scripts used for repetitive tasks like data scraping or auto-filling online forms. Over time, bots have benefited from technological advancements in parallel with humans, wielding sophisticated tools capable of executing complex fraud attacks. Eliza sure has come a long way.

Modern-day bots can easily bypass traditional security measures, forcing their human counterparts to scramble, invent, and scale increasingly complex, intricate prevention measures. The rise of artificial intelligence and machine learning has only compounded this challenge. Bots now learn from user behavior and adapt their tactics accordingly, making it harder to detect and stop them. As a result, bot fraud has become a lucrative business for cybercriminals.

To leapfrog the next new bot-based scheme, a quick study of known bot attack methods can help prepare you for battle with these persistent digital foils.

Malicious bots: methods behind the mayhem



Malicious bots have become a prevalent tool for cybercriminals and can be used to commit identity theft, launch DDoS attacks, steal sensitive data, and spread malware. While we can learn from the past, there’s always a new bot attack method brewing — but today’s prevalent methods give some clues as to where an organization should focus its prevention efforts.

Bot attacks on user accounts

Accessing existing accounts, particularly those linked to financial institutions, are prime targets for bot attacks. These attacks represent a significant portion of online fraud and identity theft incidents. Malicious bots use various methods to access user accounts, including credential stuffing, brute force attacks, and phishing.

Credential stuffing: This popular password cracking method uses login credentials from data breaches on multiple websites to gain unauthorized access, essentially by ‘stuffing’ as many stolen credentials into a login attempt until successful.

Brute force attacks: This is carried out by repeatedly trying different combinations of usernames and passwords until the correct combination is discovered.

Phishing attacks: These common attacks trick users into providing their login credentials through fake websites or malicious links.

Techniques of automated bot attacks

Automated bots can do the work of thousands of humans in one sweep, achieving an incredible scale of impact and finding ‘weak links’ in traditional authentication or security gateways.

One example of an automated bot attack is the use of “headless” browsers. These are browser-like applications that do not have a user interface but can perform web-based tasks automatically. Attackers use headless browsers to carry out malicious activities, such as account takeover attempts or click fraud, without being detected by traditional security measures.

Another technique used in automated bot attacks is API abuse. APIs (application programming interfaces) allow different software systems to communicate with each other. Attackers can manipulate APIs to gain unauthorized access to user accounts or steal sensitive information.

The automated nature of such attacks allows for rapid, efficient execution of complex tasks, using advanced algorithms that mimic human behavior to bypass CAPTCHAs and exploit system vulnerabilities. It all begs the question — could the problem be cut off at the source if bad bot traffic could be spotted more easily?

Stopping bot attacks in their tracks



To answer that, it’s important to note that not all bots are malicious; some perform legitimate tasks like indexing for search engines. However, distinguishing between good and bad bots ain’t as simple as calling the kettle black — and plenty of bad bots masquerade rather surreptitiously as benign internet creatures.

There’s a simple (generalized) rule of thumb that sets good and bad bots apart: good bots typically follow set rules and patterns, whereas bad or malicious bots often exhibit erratic or suspicious behavior.

A combination of prevention techniques such as behavioral analysis, machine learning, modern authentication methods and network monitoring can help identify malicious bots, and slow or even stop bot attacks. These methods can help identify abnormal patterns or behaviors that indicate bad bot activity. However, attackers are also constantly evolving their tactics, making it an ongoing battle that will likely never see an ‘end.’

How Stytch can help

Strong, bot-resistant authentication for systems and devices is one of the most reliable methods at keeping bad bots out. Stytch can help developers and organizations monitor and prevent bot attacks using both physical and API-powered device security measures.

Device fingerprinting identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP address, helping safeguard against bot attacks and other potential breaches.

A step beyond traditional CAPTCHA, Stytch’s Strong CAPTCHA uses complex challenges that are easy for humans but difficult for bots to solve, effectively distinguishing between legitimate users and automated systems.

Step-up authentication allows for more rigorous authentication processes like additional verification steps if a user logs in from a new location or attempts to conduct a high-risk transaction. By leveraging real-time risk assessment, step-up authentication ensures that stronger security measures kick in only when they’re most needed – without adding friction or compromising on user experience.

Stytch also offers ‘unphishable’ multi-factor authentication (MFA) that require users to authenticate their identities using multiple factors, including something they know (like a password), something they have (like a hardware token or a registered device), and something they are (like a fingerprint or other biometric data) — making it challenging for bots and cybercriminals to gain access.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation, or get started on our platform for free today.







---


# Optimizing DBs at scale: how we reduced writes by 1000x for one of our most accessed tables
Source: https://stytch.com/blog/optimizing-dbs-at-scale/

Today we’ll talk about how we reduced writes by 1000x for one of our most accessed tables, saving us valuable DB CPU and freeing up dozens of connections to do more impactful work.

Most of us have probably heard the quote, “Premature optimization is the root of all evil.” At some point, though, you may come to realize that there is a serious bottleneck in your system and it’s no longer premature – you need to optimize to meet the scale you’re now facing.

When writing an application, you may have encountered the guideline that you should let your database just handle the things it does well and not try to get too clever or creative with your queries. In the majority of cases, the engineering hours lost from someone having to debug something “clever” will outweigh the benefits of you saving a few milliseconds in every API call.

But what do you do when you start to hit a limit? You reach a point where there’s a noticeable impact on your database and it threatens to block you from scaling further. Now it’s not premature – now it’s just optimization.

Today we’ll talk about how we reduced writes by 1000x for one of our most accessed tables, saving us valuable DB CPU and freeing up dozens of connections to do more impactful work.

Sessions custom claims

Sessions are by far the biggest product at Stytch in terms of number of API calls – and that makes sense. No matter which authentication factors you support in your application, chances are that you’ll also choose to use Stytch Sessions to reap the benefits there.

One common operation is to add custom claims to a session. This is arbitrary JSON data you can assign to a user session. This could be something like a URL to a profile picture for the user, their preferred display name, or any other data that could be useful to your application.




Most projects will make use of custom claims for something, but it’s a relatively rare occurrence for this data to actually change.

By optimizing one of the hottest functions in our codebase, we were able to shave a significant number of writes from our database by being smarter about how and when we choose to perform an update. This ultimately allowed us to drastically cut back on the number of concurrent open connections to our production database.

No-ops are free, right?

Custom claims are read every time a call to SessionsAuthenticate is made to Stytch. Additionally, every other /v1/:product/authenticate call has a chance to read custom claims if the authentication is linked to an existing session. As for writing custom claims, if the incoming request included any custom claims at all, we upsert those claims back into the database.

If you look at any random authentication call, you would see that only a tiny fraction of the total time is spent handling custom claims (generally around 1-3ms) and doing this upsert.





On average about 1.7% of the time spent in a request involves an upsert into the custom claims table.

But while the time spent in a single request is inconsequential, take a step back and you’d realize that aggregated over all calls, a significant number of db connections were used in this code path. In fact, about 4% of all database queries were going through this no-op flow.



No-op custom claim upserts used to account for 4% of all db queries while actionable custom claim upserts made up just 0.01% of queries.

Quick note: the actionable upserts are closer to 0.01%, but rounding makes it look like they’re not even present!

The vast majority of the time, custom claims aren’t changing. Even if they’re being sent in every request from an application, those applications typically just send the same custom claims we’ve already stored in our database. The end result? We’re calling a no-op update… often.

We knew that this was a no-op, but we didn’t care. Our upsert operation accounted for this possibility and we thought it was reasonable to leave the logic to MySQL. This allowed us to simplify the application code and avoid maintaining too many different paths for control flow.

While there’s no harm in doing these no-op updates, as we began scaling, we realized that we were taking over a database connection that could be used for something more useful. And at times where our system experienced a spike in requests, we saw a noticeable increase in internal errors due to requests being blocked waiting for a database connection.

Getting smarter: detecting updates

As exponential growth drove us to optimize performance where possible, we reached a point where we wanted to start being more cognizant of how often we were talking to the DB in our Sessions product.

When we perform a SessionsAuthenticate call, we know what we’ve previously stored in the database and we know what we’ve been sent in the request. So then, there’s a solution: if those two claims are equivalent, we know we can skip the upsert!

In our Go codebase, that could be modeled with a function like so:



We can go one small step further, though. We’re not just checking whether the two sets of claims are equivalent – we want to know if we have any claims to add, modify, or delete from what we’ve stored in the database. We already had a function for merging claims together…



So we just had to modify it slightly to also return whether any update occurred.



Later in our code, we added a simple condition that if didUpdate is false, we don’t even ask the database to perform the upsert – we know it will be a no-op. This saved us a call to the database and freed up a connection to do something more useful.

The results



When we switched over to the new logic to skip no-op upserts, we saw a 99.9% reduction in custom claim writes

The results were instantaneous. Writes to custom claims dropped off so significantly, the graph would make you think they stopped completely. We’re still writing and updating custom claims – but only 0.1% of requests actually trigger a DB write now, which is a massive win for us.

There was a ripple effect in our database when we deployed this change. We saw a small reduction in DB CPU, we reduced our average number of open connections, and we saw a modest improvement in our p75 and p99 response time metrics (due to requests not getting stuck waiting for a DB connection).

What we learned

We don’t regret how our system was initially designed. While it wasn’t overly complex to add the logic to skip the no-op write, it was certainly more complex than doing nothing and letting the database handle it completely. Adapting to current needs is a key problem in navigating the complexity of system scalability.

The introduction of nuanced logic to skip the no-op writes in custom claims showed us the balance we must strike between code simplicity and strategic optimization. We were able to use this opportunity to shine a light on other slow or frequent queries and decide which ones need addressed as we continue to scale.

From this experience, we’ve started to build more tooling and dashboards to allow us to step back and view system performance more holistically. Over time, this should help us to understand our bottlenecks long before they ever pose a real threat to Stytch’s ability to scale.

Check out our careers page if solving problems and reading topics like this interest you!




---


# Bot mitigation software: A fraudster's foil in an automated world
Source: https://stytch.com/blog/bot-mitigation-software/

This blog post addresses the growing challenge of bot attacks, covering various types, including DDoS and credential stuffing. It underscores the importance of bot mitigation software in protecting against these threats, which now constitute a significant portion of internet traffic. The article discusses effective strategies like device fingerprinting and behavioral analysis for detecting and blocking malicious bots. It concludes with a look at the future of bot management and introduces Stytch's Device Fingerprinting as an innovative solution for securing digital applications and businesses against automated attacks.

We talk a lot here at Stytch about how malicious bot traffic has become a significant threat, constituting an increasingly large portion of web traffic. Given that bots make up around 40% of all internet traffic (and growing), bot mitigation software should be at the forefront of any security team’s conversations, no matter the industry.

In this article, we’ll go a little bit deeper than usual into bot mitigation software, exploring its necessity, functionality, and benefits in safeguarding digital applications and businesses from bot traffic.

But first, some background on bad bots and their methods of attack.

Types of bot attacks: what you should know

To best understand the role that bot mitigation software can play, it helps to first understand the nature of common bot attacks. In our AI-infused era, the types of modern bot attacks are many, and inevitably scammers will find novel ways year after year to deploy software that circumvents new security measures and bot detection software. Nevertheless, let’s cover some of the more common types of bot attacks that persist.

DDoS attacks and credential stuffing

DDoS attacks, where bots flood a website with traffic to render it unusable, are a common threat. Bot detection and mitigation software employs DDoS protection to filter out this malicious traffic. Similarly, credential stuffing attacks, where bots attempt to gain unauthorized access using stolen credentials, can be stopped by identifying and blocking bots before they can breach security – a strong argument for improving authentication with measures such as device fingerprinting, strong CAPTCHA protocols, and ‘unphishable’ authentication (we cover several of these in practice at the end of this article).

Payment fraud and account takeover

Likewise, payment fraud and account takeover are significant concerns for online businesses, particularly of the financial services ilk. Bot detection software plays a crucial role in preventing these types of attacks by detecting and blocking bots attempting to perform unauthorized transactions or access user accounts.

Content scraping and price scraping

Bots can also be used to scrape content from websites or apps, including sensitive data like pricing information. This can lead to competitors gaining an unfair advantage or users receiving incorrect pricing. Bot detection software helps prevent this type of data theft by detecting and blocking bots attempting to scrape information.

Web scraping and API abuse

Web scraping is another form of data theft where bots gather information from websites or APIs for malicious purposes. Bot protection and bot detection software can detect and block these scraping attempts, preventing sensitive data from falling into the wrong hands.

Credit card and bank credential fraud

Bots attempt ATO attacks to gain control over user accounts for financial exploitation. Services like Stripe and Plaid, which offer API endpoints for credit card and bank account verification, are frequent targets of these types of attacks.

SMS toll fraud

In SMS toll fraud, unauthorized individuals or bots manipulate messaging services to send large volumes of SMS messages to premium-rate numbers owned by the fraudsters. Often, these messages are sent without the owner’s knowledge, leading to unexpected and excessive charges on their phone bill. SMS toll fraud is more prevalent in international mobile networks due to varying regulations and oversight across countries.

Compute resource fraud

Compute resource fraud is where bots exploit platforms offering computational resources. These bots, controlled by fraudsters, leverage free tiers of cloud-based services or computational platforms to mine cryptocurrencies, conduct data processing tasks, or even host illicit content. The inherent open-access nature of platforms like AWS, Github, and Heroku make them attractive targets for this type of fraud.

The impact of malicious bots



It’s well-documented that bad bot traffic can cause significant financial losses, reputational damage, and many other potentially catastrophic outcomes for businesses. And the chances are only increasing: According to Sift’s Q2 2023 Digital Trust & Safety Index, account takeover (ATO) bot attacks spiked by a staggering 427% in Q1 2023, compared to all of 2022.

How bad bots break things

Here are some of the many negative outcomes we’ve seen as a result of bot attacks in recent history:

Financial losses: Depending on the severity of the attack, malicious bots can cause financial losses for businesses by disrupting their operations, stealing sensitive information, or extorting money to stop the attack. For individuals, bot attacks can result in identity theft or unauthorized access to personal accounts.

Damage to reputation: A successful bot attack can damage a business’s reputation and erode trust with customers. For example, if a website is repeatedly taken down by DDoS attacks, customers may lose confidence in the company’s ability to protect their data and seek services elsewhere.

Wasted resources: Dealing with bad bots also wastes valuable resources for businesses. Employees may have to spend time identifying and mitigating the attack, resulting in a loss of productivity. In some cases, businesses may have to invest in additional security measures or hire outside help to protect against future bot traffic and attacks.

Disruption of services: Without proper bot detection, bots can disrupt various online services, including e-commerce sites, social media platforms, and financial institutions. This can cause inconvenience to users and result in lost revenue for businesses that rely on these services.

Spread of misinformation: Bots can be used to spread fake news and misinformation, causing harm to individuals and society as a whole. This can also damage the credibility of reputable sources and make it difficult for people to distinguish between real and fake information.

Legal consequences: Depending on the severity of the attack and its impact, businesses may face legal consequences for not adequately protecting their systems against bot traffic and bot attacks. This can result in fines, lawsuits, and damage to their reputation.

The necessity of bot detection and mitigation software

Given the extensive damage that uncontrolled bot activity can cause, implementing bot management, detection, and mitigation software has become a priority for many businesses. Here are some of the reasons why it should sit as item #1 on your bot management security roadmap, now.

The prime targets: applications and businesses

Recent research from Barracuda Networks suggest that bad bots account for nearly 30% of all bot traffic in 2023 from January to June. Moreover, according to Barracuda, account takeover (ATO) attacks – including attacks against APIs – are increasing. The data suggests that APIs, or application programming interfaces, remain under-protected and easy to target through automated attacks.

Applications and the businesses that offer them will always be among the most vulnerable to bot attacks given their distributed nature and inherent security gaps. Bot protection software is essential in this context.

Integrating bot detection and mitigation software in web applications and mobile apps is crucial to protecting sensitive data and maintaining functionality. This integration is especially important for mobile apps dealing with financial transactions, personal data, and other sensitive information.

Protecting web traffic from bot traffic inflow

People like us use the web and applications every day, browsing and scrolling for just about every aspect of our lives. But these days, we’re not alone out there: nearly HALF of the internet is comprised of bots, making bot mitigation excruciatingly hard.

Differentiating between bots and humans is a significant challenge, but bot detection tools and bot mitigation software hold some promise here. They can analyze traffic patterns and user behaviors on web or mobile apps to identify and block malicious bot traffic, ensuring that only legitimate users have access to a website or an app. This not only protects the website from potential harm but also ensures that genuine users have a seamless and secure experience without bot traffic that can distort the flow of code and information.

Virtual waiting rooms and sensitive traffic inflow management are two useful additional systems designed to protect websites from bad bot traffic without adversely impacting legitimate web visitors. This approach ensures that bot mitigation security measures do not become a barrier for real users.

How bot detection works at a high level



Bot management and detection software functions by scrutinizing incoming traffic to a website or application. It analyzes various attributes such as IP addresses, device characteristics with mobile apps, and behavioral patterns to identify potential bots. It can also block malicious bots at the door with various sophisticated authentication solutions (more on that below).

Flushing out bad bot traffic

Bots that accurately mimic human behavior pose a particular challenge. Advances in online behavioral analysis as well as leading-edge bot management threat intelligence can often distinguish them from legitimate users. Bot management software tools can help keep users and applications safe from emerging threats as well as credential stuffing, account takeovers, and web scraping which continue to be pervasive.

In addition to behavioral analysis, IP addresses are also closely monitored to identify and block bot traffic. Blacklisting known malicious IPs can effectively filter out a lot of bad bots, but it does not solve the problem entirely. Bot operators are continually changing IP addresses to evade detection, making it challenging for traditional methods like blacklisting to keep up.

As such, more advanced techniques are being developed by bot management software companies that go beyond just relying on blacklists. Some use machine learning algorithms to analyze and identify bot patterns, while others employ browser fingerprinting techniques to track user behavior over time and distinguish them from bots. Others implement bot traffic control mechanisms at the web application firewall (WAF) layer. Additionally, solutions like CAPTCHA tests can help filter out bad bot traffic by requiring users to prove they are human through visual or audio challenges.

A balance between security and performance

While the primary goal of bot management software is to mitigate threats, it’s essential to find a balance between security and performance. Overzealous bot detection can result in false positives, causing legitimate users to be blocked from accessing the site or application.

One way to ensure this balance is through customization options within the bot management software. This allows website owners and managers to fine-tune their settings and thresholds to fit their specific needs. For example, some companies may want to prioritize security over performance, while others may prioritize user experience and allow for a higher tolerance of bot traffic.

In addition, regular monitoring and analysis of bot traffic can help optimize the settings and thresholds used by the software to strike the right balance between security and performance. It’s also important to regularly update the software and stay informed about emerging bot threats to ensure continuous protection.

The future of bot management

Bot management software will continue to evolve and adapt to keep up with these changes. In the future, machine learning algorithms will become even more sophisticated and effective at identifying and mitigating bots. This will help reduce the need for manual intervention and customization, allowing the software to autonomously protect websites and applications.

Additionally, as bot attacks become more complex and difficult to detect, there will likely be an increased focus on proactive measures rather than reactive ones. This could include implementing strategies to actively prevent bots from accessing a website or application in the first place, rather than just mitigating their impact after they’ve already caused damage. This is where a strong authentication strategy coupled with technology to prevent bot-driven fraud can be the ace up your sleeve.

Stytch’s Device Fingerprinting: Leading-edge bot detection



Stytch’s Device Fingerprinting (DFP) can protect against automated attacks by aggregating various attributes of a user’s device into a unique identifier, ensuring a high degree of accuracy in distinguishing legitimate users from fraudulent actors. The use of attributes like browser type, screen size, operating system, and timezone, combined into a single identifier, provides a unique ‘fingerprint’ for each device, effectively detecting and blocking bad bot traffic.

In-depth defenses

One of the key strengths of Stytch’s solution is its defense-in-depth approach, which obfuscates the fingerprinting process. This approach makes it tamper-resistant to reverse engineering and spoofing attempts by sophisticated attackers, addressing a common vulnerability in many DFP solutions. This level of protection is crucial in today’s digital landscape, where attackers continually evolve their techniques to bypass security measures.

Among other DFP solutions, Stytch’s DFP product stands out by integrating a mix of industry-standard and proprietary signals into stable identifiers. This capability, coupled with multiple security measures to prevent reverse engineering, ensures that Stytch’s device fingerprints remain reliable across various challenging scenarios such as incognito browsing, webviews, VPNs, and changes in user agent or IP addresses. Features like 99.9% unique signals to the device, clear action recommendations (ALLOW, BLOCK, CHALLENGE), and multiple fingerprint types tailored for different use cases further enhance its effectiveness.

An innovative approach to bot mitigation

The core of our DFP solution, a JavaScript library coupled with a Web Assembly binary, is a testament to Stytch’s innovative approach. This setup not only gathers and sends signals efficiently but also processes these fingerprints on the backend to provide actionable telemetry IDs. These IDs come with clear recommendations, simplifying the decision-making process for businesses in real time.

To learn more about Stytch’s DFP or other innovative solutions we offer to help protect your business and applications from the many threats present today, reach out to an auth expert, or get started on our platform for free.








---


# The complete guide to machine-to-machine (M2M) authentication and authorization
Source: https://stytch.com/blog/the-complete-guide-to-m2m-auth/

Learn all about machine-to-machine authentication and authorization – what it is, how it works, M2M implementation best practices, and where it might fit within your zero-trust security architecture.

Today, we’re experiencing the exciting possibilities of being interconnected more than ever. Our devices and networks communicate with each other every second, generating billions of requests and exchanging large gigabytes of data — all without human intervention.

Machine-to-machine (M2M) communication is transforming how modern applications and devices deliver real-time product experiences. From the millions of IoT devices now connected to the internet to the search engines that process billions of search queries every day, computer networks are connecting humans and machines in unimaginable ways.

As such, our traditional methods of protecting machines and service accounts using usernames and passwords may not be the most secure way to govern how autonomous systems communicate, especially at scale.

To address this concern, machine-to-machine (M2M) applications now adopt the Client Credentials Flow, which is defined in the OAuth 2.0 RFC 6749 authorization protocol. If you aren’t familiar with the OAuth 2.0 standard, do not worry, we’ll go over this protocol as simply as possible later in this article.

For now, let’s assume we have two backend services that are trying to communicate using the client credentials flow. One service, the Client, needs to access information from the other service, the Resource.

This approach enables the Client to use its unique Client ID and Client Secret to authenticate its identity with an OAuth 2.0 Authorization server, such as Stytch. If the credentials are valid and the Resource grants consent, the Authorization server will issue an Access Token to the Client. This access token then serves as the authorization grant that gives the Client access to specific protected resources or services provided by the Resource.

In this article, we’ll explore what machine-to-machine authentication and authorization is, how it works, discuss M2M implementation best practices, and where all of this might fit within your application’s security stack.

What is machine-to-machine (M2M) communication?

Machine-to-machine (M2M) communication is the autonomous exchange of data between machines, devices, or networks without the need for human involvement.

When it comes to M2M communication, the term “machine” refers to any autonomous system or agent that can send or receive information within a network. This encompasses physical servers, computers, IoT devices, as well as workloads like your automation scripts, Docker containers, K8s clusters, and mobile/web applications.

M2M authentication vs M2M authorization

Before machines can securely exchange information, they must first verify their identities. This is where machine-to-machine (M2M) authentication and authorization come into play.

Developers often use the terms “M2M authentication” and “M2M authorization” interchangeably. But really, do these terms mean the same thing?

Let’s assume you are at the airport, preparing to board a flight. Before you can board the plane (authorization), you must first prove your identity as a human by presenting your passport and booking details (authentication). Once your identity has been verified, you will be issued a boarding pass (authorization) that grants you access to your assigned seat (resources) based on your booking information. Your boarding pass (authorization) determines whether you will fly comfortably in business class or economy.

The same idea applies to machines. Authentication verifies the identity of a machine, while authorization determines what the authenticated machine is allowed to do or access. Before authorization can happen, authentication must have taken place.

What is machine-to-machine (M2M) authentication?

Machine-to-machine (M2M) authentication is the process of verifying the identity of a machine, whether it’s a hardware device or a software program. When a machine attempts to communicate securely with another machine, the Client must first authenticate its identity credentials before it can access the other machine which is the Resource.

What is machine-to-machine (M2M) authorization?

Machine-to-machine (M2M) authorization is the process of providing authenticated machines with secure access to specific resources using cryptographically signed JSON web tokens (JWTs). These access tokens contain information such as the machine’s identity, the expiration date of the token, and the list of resources that the machine is authorized to access. With M2M authorization, machines can communicate autonomously, execute core business functions, and access protected resources at a granular level, all without human users.

How is M2M authentication and authorization used in machine-to-machine communication?

Software machines such as APIs, servers, and other workloads rely on client credentials and JWT-based access tokens to securely exchange data and functionality, without exposing key resources to potential bad actors. This is based on the Client Credentials grant type as defined in the OAuth 2.0 protocol.

Hardware machines, such as sensors, smart wearables, and other physical devices, use various M2M authentication and authorization methods to prove their identity before connecting to other devices or networks. These methods include shared secrets, digital certificates, cryptographic identifiers, and established protocols such as MQTT (Message Queuing Telemetry Transport), CoAP (Constrained Application Protocol), OPC UA (OPC Unified Architecture), and RADIUS (Remote Authentication Dial-In User Service).

How does M2M authorization work using OAuth 2.0?

OAuth 2.0 is the industry-standard framework for authorization and access control in machine-to-machine (M2M) communication. The OAuth 2.0 protocol defines the steps that a machine (the Client) must follow to securely access protected resources or functionality from another machine (the Resource), using the Client Credentials grant flow.

The OAuth 2.0 Client Credentials grant type is ideal for securing autonomous interactions in machine-to-machine (M2M) applications, such as APIs, backend services, servers, background processes, or command line interfaces (CLIs) that don’t require human users.

In addition to the client credential grant type, the OAuth 2.0 authorization framework supports several other grant types to address different authorization use cases. For example, the authorization code grant type is used when applications require end users to authenticate their identities with the authorization server. The device code grant type is used to authorize devices that lack a browser or have limited input capabilities, such as smart TVs or IoT (Internet of Things) devices. Other grant types are also available.

Client Credentials grant flow in OAuth 2.0

The Client Credentials grant flow, as defined in section 4.4 of the OAuth 2.0 RFC 6749 standard, details the steps that client applications must take to access protected resources.

Client applications must exchange their client credentials, such as a client ID and client secret, for an OAuth token that authorizes the client to access some specified resource. The client application must authenticate its credentials with an OAuth 2.0 authorization server, which can be powered by Stytch or another identity provider that supports the OAuth 2.0 standard.



The Client Credentials grant flow:

The Client application must send its Client ID, Client Secret, an array of Scopes, and an endpoint redirect URI in a secure HTTPs POST request to the token endpoint of the OAuth 2.0 Authorization server.

The Authorization server verifies the Client’s credentials and determines if the Client is permitted to access the specified Scopes from the Resource server.

If the client credentials are valid, the Authorization server will send a response to the endpoint redirect URI containing a cryptographically signed Access Token (JSON Web Token (JWT)).

The client now uses this JWT token to gain authorized access to the Resource server based on the specified Scopes, only if the token is valid.

When a Client application requests access to a protected resource, it must include the scope of resources that it requires from the Resource in the POST request that it sends to the Authorization server. A scope can be a string (claim) or a list of strings or claims that defines the functionality or resources that a client needs access to.

JWTs vs API keys for M2M API authorization

When it comes to securing machine-to-machine (M2M) APIs, JSON Web Tokens (JWTs) are generally considered to be more secure and standardized than API keys. However, the best option for your specific use case will depend on several factors, including the type of application you are building, your security requirements, API architecture, and risk tolerance.

Before now, API keys were the standard way to manage access control between internal and/or external APIs across different companies communicating. However, as our security needs have evolved with the internet, JWTs in OAuth 2.0 are now considered a more secure and developer-friendly way to manage APIs.



If your API only needs to grant basic read access to non-sensitive information and doesn’t require granular permissions and access control, API keys are easier to implement and manage than JWTs.

However, if your API serves multiple clients, such as an external-facing API or in a microservices architecture, OAuth 2.0 JWTs are a more secure and scalable alternative to API keys. This is because JWTs are signed, self-contained tokens that can provide granular levels of permissions for each tenant without the need for multiple API calls.

M2M API authorization using JWTs in OAuth 2.0

JSON Web Tokens (JWTs) are a URL-safe means of sharing information as JSON objects, as defined by the OAuth 2.0 RFC 7519 standard.

JWTs are self-contained tokens structured in three parts: the header, the payload, and the signature. The header defines the type of token (JWT) and the hashing algorithm used to sign it, the payload holds the claims (issuer, audience, expiration, etc.), and the signature verifies the token’s integrity.



When a client API sends a request to a server API, it includes the JWT that it must have obtained from the OAuth 2.0 authorization server in the authorization header of its API request. The server API then validates the JWT’s signature and uses the specified claims in the JWT’s payload to either authorize or deny the request.

Securing APIs using JWTs is very different from using API keys or traditional service accounts. While service accounts and API keys are easier to set up for static access control, they lack the dynamic authorization and security capabilities of JWTs. This is why JWTs are becoming the most popular choice for protecting APIs in modern architectures.

M2M API authentication using API keys

API keys are a string of alphanumeric characters that are issued to client APIs. They serve as the client’s unique identifier during authentication with the server API that issued the key.

When a client API makes a request to a server API, the client must include its API key in the header, query parameter, or body of that API request. The most secure way to do this is to include the API key in the HTTP header.

Upon receiving the request, the server API gateway will verify the identity of the client API and grant the request if the API key is valid. Unlike JWTs, API keys can’t hold any information or claims other than the string that uniquely identifies the client. You may need to make additional authorization requests to a centralized server to determine the specific scopes of access granted to the client, depending on how the API has been implemented.

On the other hand, API keys are not cryptographically signed like JWTs, so their security relies on how well they are managed to prevent leakage or unauthorized access. Another concerning security risk with API keys is their long lifespan. If an API key is compromised, it can be used to access sensitive resources and perform unauthorized actions for a long time before you realize the breach and revoke the key.

Identifying a compromised API key can be challenging, especially if the API is not used frequently or for activities that raise immediate red flags. Attackers can often operate stealthily, making it harder to detect their unauthorized access.

Real-world applications of machine-to-machine (M2M) communication

Backend-to-backend communication

These days, most SaaS tech companies and applications are either built on modular monoliths or microservices or are in the process of migrating to one of these architectures.

In all of these architectures, when two backend services communicate, the client service must be authenticated before it can access any resource from the other service. This is important because each service is responsible for a specific business domain and may be accessed by multiple other services, either synchronously or asynchronously.

Imagine you are a hungry DoorDash customer who has just placed an order for lunch from your favorite restaurant and is patiently waiting for the driver to deliver. If DoorDash runs on a microservices architecture, which backend services do you think would need to securely communicate to ensure your order arrives at your doorstep as quickly as possible?

When you place an order, the order management service would need to securely communicate with the user management service, the inventory management service, the payment management service, the driver management service, the notification service, and most likely other services we aren’t considering here. To secure communication between all these backend services at DoorDash, each service must be authenticated and authorized using the OAuth 2.0 client credentials grant flow.

In contrast to microservices architectures which run on multiple servers, modular monolithic architectures typically run on a single server. However, you can still set up an OAuth 2.0 authorization middleware between your other backend services or modules to secure how they communicate and access resources.

Cronjobs and background processes

In software automation, cronjobs and background processes are essential tools for automating pre-defined tasks and processes. Cronjobs are scheduled tasks that are executed at specific intervals, initiated by the system’s cron daemon in Unix-like operating systems. Background processes, on the other hand, are tasks that run continuously in the background, often initiated by the system’s boot sequence or by specific system events.

These scripts and commands, often referred to as daemons, can perform background tasks that range from managing network requests and system resources to scheduled maintenance activities like database backups and even data synchronization between servers.

Daemons run autonomously and interface with various system resources without human supervision, making them vulnerable to attack if not properly secured. Daemons may need to access system memory or communicate with other daemons and programs just to perform their tasks. As a result, M2M authentication, encryption protocols, and other authorized communication channels can be used to ensure daemons only have access to the system resources they require.

Device-to-device communication (IoT authorization)

M2M and IoT devices leverage several technologies to securely exchange information, including sensors, wired or wireless networks, communication and encryption protocols, and gateway servers. This creates an interconnected network of smart devices that can make autonomous decisions without human input.

Most M2M and IoT devices communicate with each other and the internet using wireless network channels, such as Wi-Fi, Bluetooth, RFID, BLE, NFC, and secure M2M communication protocols like MQTT, CoAP, OPC UA, and RADIUS.

Let’s take your living room, for example. Imagine you own a smart thermostat that can communicate with your smart air conditioner. The thermostat continuously monitors the temperature in your room using built-in sensors, while the air conditioner is a self-regulating device that can receive commands from the thermostat.

If your room temperature goes above or below a limit you set — for instance, if it gets too hot — the thermostat can instruct the smart air conditioner to start cooling. Once the room cools to your desired temperature, the thermostat can send another signal to the air conditioner to stop cooling.

In this example of M2M communication, the smart thermostat and the smart air conditioner communicate over secure network channels and protocols to maintain your desired room temperature without requiring any input from you for each adjustment.

M2M authentication and authorization best practices

Use an OAuth 2.0 authorization server and encrypt all communication channels

The best way to secure protected resources from unauthorized access is to encrypt all communications between your servers, APIs, and intermediary services, and implement the OAuth 2.0 authorization protocol. As you already know, the OAuth 2.0 standard is the most comprehensive industry-wide authorization framework that defines how machines can securely communicate without compromising the confidentiality and integrity of the data being shared.

You can encrypt your communication channels using different industry-standard protocols such as transport layer security (TLS) and secure sockets layer (SSL) which are cryptographic protocols that encrypt data sent over a network, rendering it unreadable to any attacker. If you require both parties to verify each other’s identities (mutual two-way authentication), you can always use an authorized communication channel like mutual TLS (mTLS).

Create unique credentials for each service

Using the same client credentials across multiple services can be a potential security risk. If an attacker compromises one service, they may be able to use the same shared credentials to access other services.

To mitigate this risk, it’s best to create and use unique client IDs and client secrets for each service. In this way, if one service is compromised, the damage will be localized to that service alone. You can use a secure centralized vault that is only accessible by administrators to maintain a comprehensive list of all your active M2M clients, along with their credentials. You can always update this list with the latest information about existing or new client identities.

Protect credentials from unauthorized access

It’s important to have a credential rotation policy that governs how you rotate client credentials. This will help to reduce your exposure window in the event of a potential breach or unauthorized access. However, the intervals at which you rotate different secrets should be determined by the security policies of your company or industry, as well as the importance of the resource or functionality being accessed.

In addition to rotating credentials, you can use short-lived access tokens and refresh tokens to control the validity of your tokens as needed. You can also implement logging and monitoring tools to actively track API calls, and analyze system logs and audit trails to detect suspicious activity and anomalous access patterns.

Enforce the principle of least privilege

When granting access to critical services, you should always adhere to the principle of least privilege. This means that you should only grant each service or entity the necessary permissions it needs to perform its specific tasks. This approach helps mitigate the potential risks associated with over-privileged services, ensuring that the damage is minimized if a security breach occurs.

When granting access to third-party APIs and external systems, you should only grant the minimum level of access necessary to execute their tasks. After the task or collaboration is complete, always revoke their credentials and access tokens.

Machine-to-machine (M2M) authentication and authorization at Stytch

Whether you need to authenticate between APIs, servers, or services, Stytch has got you covered. We provide easy-to-implement M2M authorization solutions for both startups and enterprises that need to protect their businesses from unauthorized access and attacks.



Stytch’s M2M auth product is built on the OAuth 2.0 open protocol, which is the industry standard for securing access to APIs and other machines. We provide several REST endpoints that you can use to create secure M2M applications, request and authenticate JWT access tokens, and define permissions with granular scopes.

Stytch uses the RS256 hashing algorithm to sign all M2M access tokens (JWTs) using your Stytch project’s JWKS (JSON Web Key Set). And you can validate these access tokens using any of Stytch’s backend SDKs, or locally using any library that supports the JWT protocol.

We also provide endpoints that let you update your M2M clients, rotate your client secrets at intervals, specify the validity period of any authorization token, and even delete M2M clients if necessary. These endpoints give you the flexibility and control you need to effectively manage your M2M clients.

And what’s more, if you already have pre-existing M2M clients with other identity providers, such as Auth0, you can import them into Stytch without having to reassign credentials and scopes.

Want to see how you can implement M2M authorization with Stytch? Check out our documentation and sign up for a free developer account to start building with our easy-to-integrate M2M solutions today.

If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our team.










---


# Scalper bots: The box office boom no one wants
Source: https://stytch.com/blog/scalper-bots/

These malicious bots are a significant threat that can mimic human users and disrupt online platforms by buying up products and tickets at an alarming rate. 

Ticket scalpers have a mixed reputation. On the one hand, they might be your one chance at attending that sold-out Taylor Swift concert you’ve been dreaming of, but on the other, you’re getting ripped off to high heaven and back, dropping 5x what was originally paid.

Scalper bots, on the other hand, likely won’t be getting you into that concert of your dreams. These malicious bots are a significant threat that can mimic human users and disrupt online platforms by buying up products and tickets at an alarming rate. This scalper bot ‘routing’ of the box office hurts event organizers, ticketing companies and, of course, the Swiftie dreamer looking for their golden ticket.

This article looks at the bad bots known as scalper bots (or scalping bots), examining their nature, the problems they cause, and the strategies that can be used to combat them effectively.

Understanding scalper bots

Scalper bots, in simple terms, are automated software scripts specifically programmed to purchase items faster than human users. They are predominantly used in ticket scalping and retail, where high-demand products are bought quickly for resale at inflated prices. These bots represent a significant portion of bot traffic on many e-commerce platforms, often leading to rapid sellouts of popular items (much to the dismay of genuine customers).

The use of these scalping bots has become increasingly prevalent in recent years, leading to a growing number of complaints from customers and online retailers. Whether it’s trying to buy tickets for a concert or sporting event, limited edition sneakers, or high-demand tech products like new iPhones, scalper bots leave a trail of frustration and disappointment in their wake.

The evolution of online scalping and ticket bots

Unlike traditional scalpers who physically bought and resold tickets, modern scalpers use scalping bots to automate the process. Scalper bots are capable of executing large-scale purchases within seconds of an item’s release, a feat impossible for a human user. This evolution has not only made scalping more efficient but also more widespread, affecting a broader range of industries, from gaming to live events.

How scalper bots work

Scalper bots automate the process of buying products or tickets through rapid and repetitive access to web pages. They frequently use auto-refresh features to monitor for new sales and act instantly to gain an advantage. These bots can mimic the browsing patterns of human users to evade detection, filling out online forms, navigating through ecommerce sites, and even completing purchases using saved credit card details. Such sophisticated automation makes it challenging to distinguish between genuine users and bots.



Specializations and types of scalper bots

There are various types of specialized scalper bots for different tasks and bot attacks. They include:

Account creation bots: These bots are used to create multiple fake new accounts on websites, helping scalpers bypass purchase limits. Examples include Nike account creation bots, Supreme account creation bots, etc.

Monitor bots: These bots continuously scan and auto refresh web pages for product launches and alert bot operators the moment items go on sale. Examples include sneaker monitor bots and ticket monitor bots.

Price tracking bots: These bots track price fluctuations of products and notify scalpers when prices drop to a desired level. They include Amazon price tracker bots, eBay price tracker bots, etc.

Checkout bots: These bots automate the checkout process, allowing scalpers to quickly complete purchases before others. Examples include Shopify checkout bots, Yeezy checkout bots, etc.

Proxy bots: These types of scalper bots facilitate the use of multiple IP addresses to mask the identity of scalpers and avoid detection. Examples include residential proxy bots, datacenter proxy bots, etc.

Captcha solver bots: These bots are used to bypass captcha tests that prevent automated activities on websites. These include reCAPTCHA solver bots and hCaptcha solver bots.

Breaking down the threat

Like the grinch stealing your gifts at Christmas, scalping bots ruin the fun by outpacing human users and making it difficult for customers to purchase popular products and tickets. At the same time, industries also suffer from the impact on the consumer experience, potential revenue loss, and the need to invest heavily in bot detection and mitigation strategies.

Let’s break down the potential impacts of these ‘grinch bots’ across availability, pricing, competition, and revenue.

The impacts of scalper bots

The use of scalper bots has significant impacts on both businesses and consumers, including:

Artificial scarcity: By using bot technology to quickly purchase large quantities of products, scalpers create an artificial scarcity of the desired products, driving up demand and prices.

Higher prices: With limited supply and high demand for certain products, scalpers can sell them at inflated prices, making a profit while also increasing the cost for consumers.

Unfair competition: Scalper bots give an unfair advantage to those who use them, allowing them to bypass purchasing limits and secure items before others who are trying to purchase legitimately.

Damage to brand reputation: When scalpers can buy large quantities of products from a brand’s website or third-party retailers, it can lead to negative reviews and damage the brand’s reputation for not being able to meet demand.

Loss of revenue for businesses: Scalper bots can lead to a loss of revenue for businesses, as they miss out on legitimate sales and have to deal with an influx of negative feedback from consumers.

Frustration for consumers: The use of scalper bots makes it difficult for genuine customers to purchase products at fair prices, leading to frustration and disappointment. This can also damage the relationship between the brand and its customers.

The scalper bot effect on markets

With regards to unfair competition, one of the most damaging outcomes is that scalper bots can be used to monopolize markets by a few individuals or groups who have the resources and technical knowledge to constantly purchase large quantities of products. This creates an imbalance in the market and limits fair competition for both businesses and consumers.

This disparity raises concerns about market fairness and the accessibility of products and events to the general public. It also brings into question the responsibility of companies and organizations to protect their customers from such activities.

Strategies for combating scalping bots

As with all bots, certain signs can indicate bot activity vs. real users, such as an unusually high volume of traffic from similar IP addresses, rapid and repetitive access patterns, or the simultaneous creation of numerous new accounts. Employing advanced software tools and algorithms as part of your bot mitigation solution can help detect these patterns and reduce the impact of scalper bots on a website or online platform. But there are several more advanced and nuanced ways of stopping scalper bots that could save you a lot of time and investment.

Advanced detection methods

Behavioral analysis, machine learning, and device fingerprinting are increasingly used to differentiate bots from real users. By analyzing patterns such as mouse movements, typing speed, and navigation patterns, advanced detection systems can identify inconsistencies typical of scalper bots.

Scrutinizing device parameters and user agents provides further insight into the nature of incoming connections, helping to distinguish between genuine customers and bots. With device fingerprinting, the use of attributes like browser type, screen size, operating system, and timezone – combined into a single identifier – provides a unique ‘fingerprint’ for each device, effectively detecting and blocking bad bot traffic.

How to stop scalper bots at the door

To stop scalper bots, businesses often turn to bot mitigation via stronger authentication tools. These solutions include deploying CAPTCHAs, requiring multi-factor authentication, and implementing rate limiting on their websites. By adding these layers of security and bot protection, websites can make it more difficult for bots to execute their automated scripts successfully.

It’s important to remember that with authentication, you must hit the right balance between security and usability so as not to inconvenience legitimate users. This is where Stytch can help.

How Stytch can help

Stytch’s Device Fingerprinting (DFP) can protect against scalper bots, ticket bots, and automated attacks by aggregating various attributes of a user’s device into a unique identifier, ensuring a high degree of accuracy in distinguishing legitimate users from fraudulent actors. The use of attributes like browser type, screen size, operating system, and timezone, combined into a single identifier, provides a unique ‘fingerprint’ for each device, effectively detecting and blocking bad bot traffic.

A step beyond traditional CAPTCHA, Stytch’s Strong CAPTCHA uses complex challenges that are easy for humans but difficult for bots to solve, effectively distinguishing between legitimate users and automated systems.

Stytch also offers ‘unphishable’ multi-factor authentication (MFA) that require users to authenticate their identities using multiple factors, including something they know (like a password), something they have (like a hardware token or a registered device), and something they are (like a fingerprint or other biometric data) — making it challenging for bots and cybercriminals to gain access.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation, or get started on our platform for free today.







---


# Apply by API: Making job applications developer-focused
Source: https://stytch.com/blog/apply-by-api/

Apply to any job at Stytch by sending a simple cURL straight from your terminal.

“Developer focused” can mean a lot of things. For us here at Stytch, it means hiring folks that are passionate about making developers’ lives better.

We like this definition because, first and foremost, you don’t need to be a developer to make a developer’s life better. And second, it’s sufficiently broad enough to let us think holistically about every touchpoint a developer has with Stytch, including our careers page.

What tech recruiting feels like for developers

As a software engineer, you’re probably used to the wild west that is tech recruiting. Who hasn’t received messages on LinkedIn that start with, “Hello ${FIRST_NAME}, I love your background”? Or maybe an email looking for a “ninja rockstar DevOps SRE to join a rocketship”?

At Stytch, we’re an API company focused on building the smoothest developer experience around authentication. We want our recruiting process to feel like an extension of that mission.

What we decided to build

During our last hackathon, a few folks from our Recruiting and Developer Success teams wanted to experiment with ways to make our application process feel more like our API, frictionless, smooth, and easy. No re-entering your past experience line-by-line even though you attached your resume, no multipart forms with bad UI, no cover letters.

So we shipped a new API endpoint.



Apply to any job at Stytch by sending a simple cURL straight from your terminal.

Introducing Apply by API

Interested in applying for a job at Stytch and having a little fun at the same time? Let’s walk through how to apply for a role here at Stytch with a simple cURL request.

Step 1: Find a role that fits

Find a role that’s a good fit. Visit our careers page and find a role that you’re interested in. Read the job description and requirements carefully and note down the job’s full title. The title of the job is a required field in our API call.

Step 2: Build your API call

There are three required fields to Apply by API:

desired_role [string]: The full title of the role from Step 1.

name [string]: Your full name.

email_address [string]: Your preferred email address.

Additionally, there are several optional fields:

github_url [string]: Got coding projects you’d like to show off?

linkedin_url [string]: Your LinkedIn profile URL.

personal_website_url [string]: We love to see portfolios!

Gather all of the values you’d like to include above and build your cURL request:



Step 3: Send your cURL

Now just open your terminal, paste in the cURL request you built and send it! You can also use API tools like Postman or Insomnia to send the request.



Step 4: We’ll be in touch

Our team will review your application and reach out with next steps!

Apply by API

Are you passionate about making tools that developers love? We’d love to chat. Find an open role on our careers page that fits, then apply by API. 

We look forward to seeing your application 200 POST request!

---


# What is a reverse proxy?
Source: https://stytch.com/blog/what-is-a-reverse-proxy/

Explore the foundational role of reverse proxies in web security. Understand how they work in tandem with device fingerprinting to strengthen security and protect against advanced cyber threats while improving the user experience. Dive into the benefits and limitations, and learn how to integrate them into your security strategy.

A reverse proxy is an integral part of modern web architecture, often misunderstood due to its behind-the-scenes operation. Unlike a traditional proxy server, which serves a user seeking resources from the internet, a reverse proxy stands in front of web servers and intercepts requests directed to these servers. It is a type of proxy server that operates in the opposite direction of that which a forward proxy does.

In this article, we’ll peek behind the curtain for a more detailed view of the reverse proxy’s role in enhancing security, scalability, and load times – and why you might consider implementing them as part of a holistic security and UX strategy.

The role of reverse proxies in modern web architectures

The primary function of reverse proxies is to act as a gateway between the internet and backend web servers. By doing this, they efficiently manage and route incoming traffic and streamline communication between the user and the server. This mechanism not only improves performance but also enhances security, making reverse proxies a critical component in protecting web applications.

But what is a reverse proxy in the framework of modern web operations? In essence, a reverse proxy serves as an intermediary, or gatekeeper, for requests from clients (internet users) seeking resources from servers. When a request is made to a web application, the reverse proxy intercepts this request before it reaches the backend server, allowing it to perform load balancing, caching, and SSL encryption, among other functions, which are crucial for a streamlined user experience and enhanced security.

What is a reverse proxy vs. a forward proxy?

Understanding the distinction between reverse and forward proxies is crucial in comprehending their respective roles in network infrastructure. A reverse proxy server, as discussed earlier, is positioned between the client and backend servers. In contrast, a forward proxy server sits between the client and external servers on the internet.

The concept of a forward proxy

A forward proxy, also known as a proxy server, sits in front of client machines. Its primary function is to manage outgoing traffic from these clients to the internet. This setup is particularly useful in scenarios where multiple clients on an internal network need to access external resources. Forward proxies can also provide anonymity and content filtering for clients.

Contrasting a reverse proxy server and a forward proxy server

While a forward proxy serves as an intermediary for outgoing requests from a network to the internet, a reverse proxy deals with incoming requests from the internet to a web server. The reverse proxy makes decisions on how to handle these incoming requests, directing them to the appropriate backend server. This key difference underlines the distinct roles these two types of proxies play in network architecture.

Proxy servers in network security

Both forward and reverse proxies play pivotal roles in network security. Forward proxies protect client machines from direct exposure to the internet, while a reverse proxy safeguards backend servers from direct access by external threats. This dual-layered approach is fundamental in maintaining a secure and efficient network.

Key functions of a reverse proxy server



As mentioned, reverse proxies perform several essential functions that significantly improve the performance and security of web applications. Let’s look at each in a bit more detail.

Load balancing

One of the primary roles of a reverse proxy server is load balancing. Reverse proxies can distribute incoming traffic among multiple backend servers, allowing for better utilization of resources and improved performance. In an environment with multiple servers, the reverse proxy distributes incoming traffic among all the servers. This distribution ensures that no single server is overwhelmed, maintaining optimal performance and reducing load times. Load balancing is especially crucial for high-traffic websites, as it prevents server crashes and ensures high availability.

Enhanced security

A reverse proxy server adds an extra layer of security to web applications. By masking the identity of backend servers, they protect against direct attacks. Additionally, a reverse proxy server can perform SSL encryption, ensuring that sensitive data transferred between the client and the server is secure. This encryption is vital for protecting against security risks such as data breaches and DDoS attacks. Reverse proxies can also filter and block suspicious requests, preventing malicious attacks from reaching the server.

SSL encryption

Reverse proxies can handle SSL encryption/decryption, relieving the backend servers from this computationally intensive task. This not only improves performance but also allows for easier management of security certificates. SSL encryption also adds an extra layer of security by encrypting data in transit, which protects sensitive information from potential threats.

Web acceleration and caching

A reverse proxy significantly improves website performance through caching. They store copies of frequently accessed web pages, allowing these pages to be served quickly to users without overburdening the backend servers. This caching mechanism, known as web acceleration, is instrumental in reducing load times, thereby enhancing the overall user experience. A reverse proxy can also compress data, further enhancing performance by reducing the amount of data that needs to be transmitted.

Content filtering

Content filtering is when a reverse proxy inspects and manages data passing through the server, filtering out harmful or inappropriate elements. This helps block potentially harmful requests, protecting the server and network from security risks. Content filtering also allows blocking or permitting traffic based on various factors to enhance security and ensure data integrity.

Technical capabilities of reverse proxies

Reverse proxy servers are uniquely versatile in handling web traffic. In order to perform load balancing, caching, SSL offloading, and more of the benefits they offer, there are several key technical features that come into play within modern web architectures.

Handling client IP addresses

One such feature involves managing client IP addresses. By intercepting incoming requests, the reverse proxy can either forward or mask the client’s IP address, depending on the configured settings. This ability is crucial for addressing both privacy concerns and appropriately routing traffic. It allows for granular control over access to specific resources, as well as identifying and blocking potential threats.

Communication with multiple origin servers

A reverse proxy is capable of communicating with multiple origin servers, enabling it to distribute incoming requests across several servers and ensure that no single server is overwhelmed. This distribution not only balances the load but also provides redundancy, contributing to high availability and reliability of the web application. A reverse proxy can also act as a failover mechanism by routing traffic to backup servers in case of server failures.

Traffic routing and server responses

Traffic routing is another standout capability. It evaluates incoming requests and determines the most appropriate server to handle each request. After the backend server processes the request, the reverse proxy then forwards the server’s response back to the client. This process is seamless, and from the client’s perspective, it appears as if they are communicating directly with the server. This not only helps to improve the performance of the web application but also enhances security by keeping the backend server hidden from direct communication with the client.

Limitations of reverse proxies

While the benefits are compelling, reverse proxies are not a catch-all solution for every security and performance challenge – particularly in dealing with specific types of threats. The below are some of their most noticeable shortcomings.

Inadequate bot detection and fraud protection

Reverse proxies, while effective for basic traffic management and security, fall short in detecting sophisticated bot and fraud activities. They typically analyze surface-level traffic attributes such as IP addresses and request counts, which are not sufficient to identify advanced threats that mimic legitimate user behavior (more on how to target these in the next section).

Vulnerability to a single point of failure

If a reverse proxy server fails, it can bring down the entire web application. To avoid this issue, redundancy measures such as using multiple reverse proxies or implementing failover mechanisms need to be in place. Regular maintenance and updates are crucial to ensure that reverse proxies are functioning properly and securely.

Limited visibility into encrypted traffic

As more and more websites use encryption (HTTPS) for enhanced security, reverse proxies may have limited visibility into the encrypted traffic, making it difficult to detect and mitigate potential threats. This limitation highlights the need for additional security measures that can decrypt and inspect encrypted traffic without compromising privacy.

Complexity in configuration and maintenance

Troubleshooting and maintaining a large number of reverse proxies can be challenging, especially in distributed environments. Their configuration and maintenance can be complex, requiring specialized knowledge and resources, and incorrect configuration can lead to vulnerabilities or performance issues, underscoring the importance of proper setup and ongoing management.

Potential performance impact

While reverse proxies generally improve performance, they can become bottlenecks if not scaled appropriately. As a single point of entry and exit for traffic, a reverse proxy must be capable of handling the volume of requests it receives. Failure to scale the reverse proxy in line with traffic demands can lead to reduced performance and increased load times. This challenge can be addressed by using load balancers or implementing distributed reverse proxy systems.

Furthermore, while reverse proxies can improve the performance of a web application by caching frequently accessed content, they may not be effective for websites that have constantly changing content. In such cases, other optimization techniques like minification and compression should be utilized to improve response time.

Reverse proxies and device fingerprinting





While reverse proxies provide clear foundational web security and performance enhancements, they are not a complete solution. Their effectiveness is greatly amplified when paired with advanced auth solutions like device fingerprinting. This synergy is crucial for a comprehensive defense against sophisticated cyber threats, especially in the context of dynamic web content.

The one-two punch

Because advanced persistent threats and targeted authentication-level attacks may require additional security measures, merging reverse proxies with device fingerprinting can be a smart way to embed more nuanced security policies into your apps.This potent security combo enables real-time, detailed traffic analysis, improving the detection and response to specific bot behaviors and fraud tactics not captured by reverse proxies alone.

Device fingerprint insights go beyond limited pieces of traffic information such as IP addresses, number of requests and request headers to catch and thwart fraudsters or bots attempting to mimic the actions of real users.

How Stytch can help

As is now clear, reverse proxies should only be part of your broader security strategy. Stytch offers a holistic fraud prevention toolset to augment reverse proxies by shoring up your authentication defenses – including device fingerprinting.

Stytch Device Fingerprinting identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP addresses, helping safeguard against different types of attacks and potential breaches. By combining these elements into an identifier, there’s enough entropy to ensure that the identifier is unique to each device.

A step beyond traditional CAPTCHA, Stytch’s Strong CAPTCHA uses complex challenges that are easy for humans but difficult for bots and fraudsters to solve, effectively distinguishing between legitimate users and automated systems. Strong CAPTCHA works by loading an incredibly thin remote client that allows your user to solve the CAPTCHA, but ensures that bot farms are incapable of attacking your app.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation or get started on our platform for free today.







---


# How to securely implement M2M authentication and authorization in Node.js using Stytch
Source: https://stytch.com/blog/how-to-implement-m2m-authentication-and-authorization-in-node-js-using-stytch/

Step-by-step guide: Implementing M2M authentication and authorization in Node.js, using Stytch as OAuth 2.0 server and IDP.

The growing adoption of open APIs, microservices, and modular monolith architectures is transforming how we communicate, both between humans and machines and between machines. M2M applications and services now communicate exclusively with each other to execute core business functions across multiple servers and networks, making it easier to deliver frictionless product experiences for today’s users.

However, to protect these services, APIs, or applications, and maintain the integrity of your resources, you must implement a secure machine-to-machine (M2M) authentication and access control strategy that is built on the OAuth 2.0 open standard.

For instance, you may require one of your cronjobs, APIs, or backend services (known as the Client) to communicate with another service (known as the Resource) without any human user entering a username and password. This is where OAuth 2.0 machine authorization with Stytch comes into play.

Machine-to-machine (M2M) authentication and authorization is the process of verifying a machine’s identity before granting it the necessary permission to communicate with another machine. In today’s age of distributed systems, you can securely communicate between your APIs and services by verifying the client credentials (client ID and client secret) and scopes of each M2M application to ensure they have the required permission before granting access to specific resources.

In this tutorial, we’ll walk you through a step-by-step implementation of M2M authentication and authorization between two internal backend services in a hypothetical neobank using Stytch as our OAuth 2.0 authorization server and identity provider.

We’ll implement Stytch’s robust suite of M2M REST endpoints that make it easy for you to securely create and manage M2M clients, their credentials, and authorization tokens (JSON Web Tokens (JWTs)).

We’ve outlined each implementation step in this tutorial, but if you’d like to get a working copy of the final code, you can find it on GitHub.

How OAuth 2.0 M2M authorization works on Stytch

Stytch is a modern identity platform that makes it easy for developers, startups, and enterprises to build end-to-end authentication and user management for any application and architecture. Stytch also offers a machine-to-machine solution for securing APIs and services using dedicated machine-to-machine (M2M) applications.

Stytch lets you create multiple M2M applications and clients, each with its unique client credentials (client ID and client secret). These M2M clients can securely access your protected resources by providing their client credentials and the specified read/write permissions, to obtain authorization tokens from Stytch. In essence, Stytch acts as your OAuth 2.0 authorization server.

Stytch’s M2M product is built on the OAuth 2.0 RFC 6749 protocol, which is the industry-wide open authorization standard for managing access and permissions between APIs, services, and other machines. This framework defines the steps that a client must follow to securely gain access to specific protected resources from a resource server, using the Client Credentials grant flow.

Client Credentials grant flow

The OAuth 2.0 Client Credentials grant type is the ideal flow for securing communication between machine-to-machine (M2M) applications, such as backend services, servers, APIs, background processes, or command line interfaces (CLIs) that don’t require human interaction.

Client applications must provide their client credentials, such as a client ID and client secret, and an array of scopes to obtain an OAuth access token that authorizes the client to communicate with the resource server. The client application must authenticate its credentials with an OAuth 2.0 authorization server, typically powered by an identity provider that supports the OAuth 2.0 standard. In this tutorial, our authorization server will be powered by Stytch.



Our M2M example app: what we’ll build

We’ll use Stytch’s M2M authentication service to enable secure communication between two backend services in a hypothetical fintech neobank: the Payment Management Service and the Wallet Management Service. For the purpose of this tutorial, we’ll assume that our hypothetical fintech neobank is PayPal.

In our hypothetical PayPal scenario, the Payment Service (the Client), which is responsible for processing outward debits from a PayPal customer’s wallet, needs to securely communicate with the Wallet Service (the Resource) to access a customer’s current “walletBalance”. The Payment Service requires the customer’s current wallet balance to determine whether they have sufficient funds to successfully process a pending outward debit of $769 from their PayPal wallet.

We’ll make this happen using the endpoints and tools that Stytch provides, and we’ll occasionally refer to the Payment Service as “payment-server” and the Wallet Service as “wallet-server”.



In our example app, both services are internal backend services within a microservices architecture. As such, we manage our Stytch implementation for handling M2M client requests from the payment-server, while we handle token authorization via Stytch on the resource server (wallet-server).

However, if this were to be the case of a client server communicating with an external resource server, the client wouldn’t handle the creation of M2M clients or the issuance of credentials. Instead, both the creation of clients and issuance of credentials, as well as the authorization of access tokens would all be handled by the external resource’s authorization server, depending on the identity provider that must have been implemented.

Now, let’s get right into it.

You can find the full sample code on Github.

Setting up the developer environment

Prerequisites

If you want to run the example application on your machine, make sure you have the following set up:

A Stytch developer account with API keys. If you don’t have one, sign up to get yours.

A Stytch Consumer Authentication project.

Postman.

Node.js dev environment.

Getting started

To get started, you have to clone the example application. Run the following command in the terminal to clone it. The example app is an Express app.



Next, navigate to the root of both the payment-server and wallet-server directories and run the following commands to install the dependencies for each directory:



Get your Stytch API credentials

If you don’t have a Consumer Authentication project already, log in to your Stytch account and create one. Stytch also supports M2M auth in B2B SaaS Authentication projects, but for this guide, we’ll be using the consumer auth project.



In the Dashboard, click API Keys under the Configuration section of the sidenav. For the sake of this tutorial, we’ll be using the Project’s Test environment, so copy your Project’s credentials: the “project_id” and “secret”.



In the root of both the payment-server and wallet-server directories, create a .env file and populate the fields with your Project’s credentials following the key/value format below:



Running the example app locally

After completing all the previous steps, you can run each of the servers with the following command:



The payment-server (the Client) will be available at http://localhost:6000, and the wallet-server (the Resource) will be available at http://localhost:4000 when you run them locally on your machine.

Breaking down the Node app structure

Now that you have the app up and running, let’s take a look at the high-level architecture and build of the code.

The example application has two main directories: a payment-server that’s responsible for processing outgoing debits from a PayPal customer’s wallet, and a wallet-server that holds the protected resource (“walletInfo”) that the payment-server needs to access.

The payment-server (Client)

The payment-server directory contains a helper directory that holds the stytch.js file with our Stytch implementation, except for authorizing access tokens.

The payment-server also houses a server.js file that serves as the directory’s entry point, mounts the “/initiate-payment” route to process outward payments, and handles M2M client requests via stytch.js.



The wallet-server (Resource)

The wallet-server directory holds a middleware directory that contains an authorizeToken.js file. This file authorizes access tokens with the necessary scopes before granting access to the protected resource.

The wallet-server also contains a server.js file that holds the protected resource (“walletInfo”) and mounts the “/api/check-balance” route to return a requested customer’s wallet details, specifically their “walletId” and “walletBalance”.



Initializing Stytch on both servers

Next, in the root of the payment-server directory, find the stytch.js file in the helper directory, and initialize Stytch with your “project_id” and “secret”.

You can find these values in your Stytch Dashboard, under the Configuration section, after clicking on API Keys. In this case, you only need to fill out the STYTCH_PROJECT_ID and STYTCH_SECRET env variables with these values.



Also, in the root of the wallet-server directory, find the authorizeToken.js file in the middleware directory and initialize Stytch with your “project_id” and “secret” just as you did above. Fill out the STYTCH_PROJECT_ID and STYTCH_SECRET env variables with these values.



Creating your M2M client

After initializing Stytch on both servers, you have to create your M2M client application directly from your Stytch project dashboard. Stytch also provides a Create M2M Client endpoint that you can use to programmatically create M2M clients. However, for the sake of this tutorial, we’ll be manually provisioning our M2M client and storing the client credentials as env variables. 

On the dashboard, navigate to M2M Clients under the Management section of the sidenav and click the “Create” button. Then, enter a name for your M2M client (payment-service) and add a new scope (read:user).



Afterward, copy the current client_secret and hit the “Save” button to save the M2M client you just created.



This is the only time the client_secret will be available to you because Stytch only saves a hash of this client_secret for security and credibility reasons. You can choose to store the client_secret in a secure vault or secrets manager, depending on your security requirements in production.

Now, go to the .env file you created in the root of the payment-server directory and populate the client_id and client_secret fields with your M2M client credentials following the key/value format below



Obtaining an M2M access token on the payment-server

Once you’ve created your M2M client, the next step is to obtain an M2M access token. The client must make a call to the authorization server, sending along their client secret, client ID, and specified scopes, and the authorization server must validate these credentials before returning a signed JWT token.

This JWT token will be used to authenticate your client (payment-server) when requesting access to a customer’s wallet information like “walletId” and “walletBalance” from the wallet-server. In our case, this token is obtained by calling Stytch’s Get Access Token endpoint with the following parameters provided in the body of the request: client_id, client_secret, scopes, and grant_type.

After the authorization server validates your request, you’ll receive a response that includes the “access_token” and the “expires_in” parameter, which will define the validity period and lifespan of the access token. You need to securely store the access_token in memory (node-cache) so that you can provide it for authentication whenever you send a request to the wallet-server, or request for a new token from Stytch if the current expires_in date has passed.



Sending requests from the payment-server to the wallet-server

Now, with the available access token, the next step is for you to make a secure call to the wallet-server requesting access to the customer’s “walletInfo”. The “paymentInfo” object of the debit transaction you are attempting to process must be included in the body of the request, along with the “access_token” within the header.

The wallet-server must authenticate and authorize your request from the payment-server by validating the access_token before granting access to the specified wallet details. We’ll demonstrate how this happens in a moment.

If your request is successful, you’ll receive a response from the wallet-server that includes the customer’s current “walletBalance”. And if the wallet balance is sufficient to complete the pending debit of the specified “debitAmount” in the “paymentInfo” object, the transaction will be processed successfully by the payment-server.




Authorizing the JWT access token via authorizeToken.js on the wallet-server

Before you receive a successful response to your client request in the step above, Stytch’s Node SDK must first validate the access_token you provided in the request.

As such, you have to implement a middleware function that will intercept all requests made to the wallet-server and authorize the provided access_token, alongside the required scope. Your middleware (authorizeToken.js) handles authorization using Stytch’s SDK by calling the Authenticate Access Token method with the provided “access_token” and the “required_scope” that the token must contain to be valid.

A successful response will include the M2M client’s client_id, scopes, and custom claims. At this point, the payment-server is considered authorized and is granted access to the customer’s wallet details (“walletInfo”).





Rotating client secrets via stytch.js

For security reasons and compliance with industry best practices, Stytch allows you to regularly rotate your client secrets. By rotating your secrets at scheduled intervals, you can prevent compromised credentials from being used by attackers for extended periods without notice.

Navigate to the payment-sever and find your stytch.js file. The next step would be to start a secret rotation by calling Stytch’s Start Secret Rotation endpoint, providing the “client_id” of your M2M client. A successful response will include all the details of your M2M client. But at this point, both the “client_secret” and “next_client_secret” in the provided response will be active.

Now, you’ll have to update the CLIENT_SECRET stored in your env variable by changing the previous “client_secret” to the “next_client_secret” gotten from your response. This is the only time that the “next_client_secret” will be made available to you.



Complete secret rotation via stytch.js

Now that you have a “next_client_secret” from successfully starting the secret rotation, the next step would be to complete the secret rotation process so that the “next_client_secret” becomes the active “client_secret”, and the old “client_secret” becomes inactive. After starting a secret rotation, both the client_secret and the next_client_secret become active until you complete the rotation.

To complete the rotation you’ll have to call Stytch’s Rotate M2M Client Secret endpoint, providing the “client_id” of your M2M client. A successful response will include the details of your M2M client. At this point, the old client_secret will become inactive and the new one will be active.



Managing M2M clients (search and update)

Managing the M2M clients you create within a Stytch project is very straightforward from your dashboard. However, Stytch also provides REST endpoints that allow you to search for your M2M clients and update these clients as needed.

Search for M2M clients via stytch.js

Back to your stytch.js file in the payment-server, you have to call out to Stytch’s Search M2M Client endpoint to search for the M2M clients in your Stytch project.

In the query parameter, you have to optionally provide the limit attribute which specifies the number of results you want Stytch to provide you per page. You also have to provide an operator in the query object (AND, OR) and the operands that will filter your result.



Update M2M clients via stytch.js

Still in your stytch.js file, you have to call out to Stytch’s Update M2M Client endpoint to update details of the M2M clients that are within your project. Stytch allows you to update details like “client_name”, “client_description”, “scopes”, “trusted_metadata”, and “status”.

The next step will be to update the status of your M2M client to “inactive”. This will deactivate the M2M client from being able to request new access tokens until it is reactivated by updating the status back to “active”. However, deactivating the M2M client doesn’t deactivate any existing tokens. It only prevents the client from requesting new ones.

You can call out to the Update M2M Client endpoint by providing the “client_id” in the request param and including the “status” string in the body of your request. A successful response should include the details of your M2M client, with the status field value now changed to “inactive”.



Machine-to-machine authentication and authorization best practices

OAuth 2.0 is a solid M2M authentication and authorization framework, but the security of your systems depends heavily on how you implement the protocol. If there are flaws or oversights during implementation, it can introduce vulnerabilities that expose your services or APIs to risks. 

However, by following industry-proven best practices, adhering to security standards, and staying on top of emerging threats, you can build and maintain a secure architecture that only authorized machines can access.

Whether you need to manage access control for internal or external services, here are some M2M authentication best practices that will help protect your resources from unauthorized access:

Implement an OAuth 2.0 authorization server that strictly follows the client credentials grant flow, such as Stytch. We provide all the REST APIs required for creating secure M2M applications, requesting and authenticating JWT access tokens, and defining granular permissions with scopes.

Avoid using the same client credentials for multiple services. It is best to create and use unique client IDs and client secrets for each service. This will help to isolate any potential damage if one service is compromised.

Implement a credential rotation policy to govern the frequency at which you rotate your client credentials for different services. When creating this policy, consider the purpose of each service, identify any other services or applications that may need to communicate with it, and the cascading level of security required for the service.

When granting access to sensitive resources, always adhere to the principle of least privilege and implement proper access controls. Only grant each service or entity the permissions it needs to perform its specific function.

Encrypt every communication channel between your servers, API gateway, and intermediary services using digital certificates, such as Transport Layer Security (TLS). You can also use Mutual TLS (mTLS) if you require mutual authentication from both services.

Wrapping up

At this point, you should have been able to successfully:

Set up a developer account and a consumer authentication project on Stytch.

Create two servers (payment-server and wallet-server) demonstrating a typical M2M authentication and authorization flow, using Stytch as the OAuth2.0 authorization server.

Gain a clear understanding of how machines securely authenticate each other’s identities and grant authorized access to protected resources, without human involvement.

Ready to implement M2M authentication in your project? Check out our Docs and start coding.

If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our team.












---


# Keycloak alternatives for enterprise authentication and identity management
Source: https://stytch.com/blog/keycloak-alternatives/

In this article, we’ll briefly overview the benefits and challenges of open-source auth solutions like Keycloak, then dive into the world of closed-source alternatives offering more user-friendliness, support, and maintenance features.

Open-source identity and access management (IAM) systems are designed to securely authenticate and authorize individuals, providing them with the appropriate level of access to resources within an organization. Keycloak is one of the most reputable open-source IAMs, with comprehensive features including single sign on (SSO), catering to the diverse needs of modern applications across web apps, mobile apps, and even SaaS apps.

Yet, despite its open-source nature and single sign-on advantages, Keycloak isn’t perfect for every developer and business use case. For instance, it requires significant expertise and effort to set up and maintain, making it less user-friendly for smaller organizations with limited resources.

This limitation has paved the way for several “closed-source” alternatives that offer a more streamlined, low-lift approach to IAM. In this article, we’ll briefly overview the benefits and challenges of open-source auth solutions like Keycloak, then dive into the world of closed-source alternatives offering more user-friendliness, support, and maintenance features.

Keycloak and the pros and cons of open-source IAM

Keycloak is an open-source identity and access management solution developed by Red Hat. It primarily focuses on providing robust, customizable, and scalable user authentication and authorization. Keycloak not only supports standard protocols like OpenID Connect, OAuth 2.0, and SAML but also enables businesses to manage their users’ access to different resources, applications, and services.

Additional benefits of Keycloak include:

Single sign-on: Users can securely access multiple applications with a single set of login credentials. Single sign on eliminates the need to remember multiple passwords, making it convenient for users and reducing the risk of password-related security breaches.

Identity brokering (social identity providers): Keycloak allows users to log in using their existing social media accounts like Google, Facebook, or GitHub. This feature simplifies the registration and login process for users, reducing user friction and increasing convenience.

User federation: Keycloak can integrate with various user stores and directory services, making it easier to control access and manage users across different systems. Additionally, Keycloak’s support for various programming languages and frameworks makes it easy to integrate with different technology stacks.

Despite its capabilities in managing identities and user provisioning, Keycloak’s complexity, heavyweight architecture, and not-so-user-friendly API have been points of contention for developers leading some to seek alternatives. Moreover, recent security vulnerabilities have exposed some cracks beneath the surface, underscoring the need for more rigorous and time-consuming maintenance, especially in a self-hosted setup. Let’s drill into these a bit further.

Complexity and expertise

Open-source identity solutions like Keycloak offer extensive flexibility and customization, essential for modern applications and web apps. However, this often leads to complexity, presenting a challenge for many smaller businesses lacking an IT team specializing in identity and access management (IAM). Implementing and maintaining these solutions demands a deep technical understanding as well as continuous upkeep outside the realm of smaller team capabilities.

Self-hosting

Keycloak’s open-source nature necessitates self-hosting, meaning businesses are responsible for managing servers, databases, and network infrastructure for their access management system. In addition to continuous system operation and regular backups, businesses must also scale their internal resources to meet their growth needs. For companies with restricted IT resources, this can be both time-consuming, expensive, or flat-out infeasible.

Security vulnerabilities

Self-hosting also requires vigilant security management, and without the appropriate skill sets in this area, organizations can become vulnerable to breaches. With Keycloak, addressing security vulnerabilities relies heavily on the user community. When a vulnerability is identified, it’s critical for organizations to promptly update or patch their systems themselves (contrast this with closed-source solutions where security updates and fixes are typically managed by the provider).

Recently, a substantial security vulnerability was discovered in Keycloak that allowed a malicious actor to create nefarious Keycloak authorization request URLs to circumvent the redirect URI validation. Depending on the client configuration, an attacker could exploit this vulnerability to steal a victim’s authorization code or access token. This vulnerability highlighted one of the notable drawbacks of Keycloak – the burden of security management is often shouldered by the user minus a dedicated security team.

Aside: Stytch makes it easy for B2B SaaS businesses to build secure Enterprise-grade multi-tenant SSO, with support for OIDC and SAML. Plus, Stytch offers responsive support, and a hosted solution that’s easy to maintain as your company scales, making it a great alternative to Keycloak. But there are lots of options…more on that below.

Closed-source alternatives

Closed-source identity and access management (IAM) solutions represent a model where the source code is proprietary, held and maintained by the company that develops it. Unlike open-source options, these solutions do not provide the end-user with the ability to view, modify, or distribute the original code. In return, businesses and users get the comfort of ‘outsourcing’ the most complex aspects of IAM.

Advantages of closed-source IAM

Closed-source IAM solutions bring their own unique set of advantages. At a high level, these benefits often involve:

Seamless updates: With a dedicated team of developers, closed-source IAM solutions often provide timely updates to fix bugs and improve functionality. In contrast, open-source solutions may rely on community support for updates, which can sometimes lead to delays in addressing issues.

Comprehensive customer support: Closed-source identity access management providers often offer robust customer support, helping businesses navigate any challenges quickly and effectively. This can be especially useful for troubleshooting technical issues or receiving guidance on utilizing the features of the solution effectively.

Hosted/cloud support: All the infrastructure is taken care of in the cloud and will auto-scale as your business / application grows. This eliminates the need for businesses to invest in their own infrastructure and IT resources, reducing overall costs. Additionally, hosted/cloud support allows for easier access to the solution from anywhere with an internet connection.

Early closed-source IAM systems were often rigid and focused solely on securing access, but modern closed-source IAM solutions are designed with flexibility and integration in mind. They have adapted to include features like single sign-on (SSO), multi-factor authentication (MFA), and federated identity management, catering to a wide range of business requirements and user scenarios.

Developer experience

Closed-source IAM solutions provide a significant boost to the developer experience by offering customized authentication systems tailored to specific needs. They recognize the diverse requirements across various development environments, be it mobile, frontend, or backend. With their user-centric API designs, these solutions offer intuitive and easily integrable APIs, ensuring seamless implementation of authentication mechanisms. This attention to API design reduces the complexity and time involved in integrating IAM functionalities into various applications.

Furthermore, these IAM solutions support multiple programming languages and offer comprehensive SDKs, catering to a wide range of development platforms. This versatility allows developers to work in their preferred language and environment, enhancing productivity and ease of use. Whether it’s handling complex security protocols for enterprise applications or integrating social login features for mobile apps, closed-source IAM providers equip developers with the tools and support needed to create secure, efficient, and user-friendly authentication experiences.

Greater reliability and security

A closed-source identity access management solution is often seen as more reliable and secure – and for good reason. Closed-source IAM solutions are often built and maintained by teams with a dedicated focus on security. This means that additional measures, such as regular security audits and vulnerability testing, might be in place to ensure the system’s integrity. The controlled development environment ensures that any changes or updates to the system undergo rigorous testing before release. This contrasts with open-source solutions, where updates can be contributed by a broad community, potentially introducing instability or security risks.

Advanced authentication methods that uplevel security practices further add to the appeal of closed-source solutions. They include biometric authentication, risk-based (or step-up) authentication, and adaptive authentication techniques that verify user identity with factors such as location, device status, and behavior. These methods not only enhance security but also improve the user experience by offering convenient yet secure access to applications and services – increasingly table stakes in today’s CX-driven world.

Adherence to compliance and industry standards

Closed-source solutions, given their controlled nature, are naturally a good fit within the guardrails of industry compliance standards and therefore tend to appeal to businesses operating in particularly stringent industries. Many closed-source IAM providers design their solutions to comply with industry standards and regulations. This is crucial for sectors like finance, healthcare, or government, where compliance with data protection and privacy regulations is non-negotiable. Closed-source IAM solutions ensure that their products adhere to these standards, instilling peace of mind for businesses in these industries.

Future proof by design

So as not to be outsmarted by the tricksters and scammers lurking within application ecosystems, closed-source IAM providers invest heavily in research and development, ensuring their solutions are equipped to handle emerging security threats and evolving business needs. This forward-looking approach means that businesses using closed-source IAM can be more confident in their ability to adapt to future challenges in the digital landscape and prepared to tackle threats head-on. With their regular updates and support, closed-source IAM solutions provide a long-term solution for managing identity and access within an organization and a notable stability in weathering change.

Finding the right closed-source access management system

With numerous closed-source IAM providers in the market, it can be challenging to find the right one for your organization. When evaluating different solutions, consider factors like cost, functionality, scalability, and support services, as well as how the solution integrates with existing systems and whether it aligns with your organization’s security requirements. The below is an overview of some top choices with pros and cons to help guide you.

Auth0



Auth0 has emerged as an adaptable identity provider, catering to a diverse array of applications, including web apps, mobile platforms, and federated systems. Their solution provides a flexible and scalable approach to managing identity and access, making it a potentially good choice for businesses of various sizes. Auth0’s extensive support for different protocols and integrations with popular platforms like AWS, Azure, Google Cloud, and Salesforce makes it a versatile option for organizations operating in various sectors.

Pros:

Wide application support: Auth0 excels in its support for various applications, from web-based to mobile environments. It also offers integration with popular identity protocols like SAML, OAuth, and OpenID Connect.

Scalability: With an extensive set of features and integrations, Auth0 can handle the needs of growing organizations without compromising on performance. It has various pricing plans to suit the needs of businesses at different stages of growth.

Developer resources: Auth0’s extensive documentation makes it easy for developers to find resources on the technology they’re looking for. It includes SDKs for various programming languages, making it accessible for developers of all backgrounds.

Cons:

User-first data model: Auth0’s data model is user-first by design, meaning individual user records are simply associated with organizations. This multi-tenant architecture is limiting and inflexible as it makes it difficult to deduplicate user accounts safely, enforce org-specific auth requirements, and selectively authenticate into one organization and not another.

Cost: While Auth0 has a free trial and flexible pricing plans, its services may be too expensive for smaller businesses or startups. It may require additional costs for certain features and integrations.

Complexity: Auth0’s extensive set of features and customization options can be overwhelming for organizations with limited IT resources or technical expertise.

Security challenges: Unfortunately, in the past few months, Auth0’s parent company Okta has had some heavily publicized security breaches, casting doubt on the solutions overall reliability.

Amazon/AWS Cognito



Part of the Amazon Web Services suite, Amazon & AWS’ Cognito offers a convenient identity management and access control solution, especially for those already within the AWS ecosystem. Overall, AWS Cognito is a strong choice for businesses already utilizing AWS services and looking for a comprehensive IAM solution with strong security features and cost-effectiveness.

Pros:

Seamless AWS integration: Offers tight integration with other AWS services, ensuring a smooth operation within the AWS environment.

Scalable and flexible: Provides scalability and flexibility to support a wide range of business needs, from small startups to large enterprises.

Simple setup process: Easy-to-follow setup process makes it accessible for users with varying levels of technical expertise.

User-friendly interface: Intuitive interface makes managing identities and access control simple and straightforward.

Cost-efficient: Offers a pay-per-use pricing model, making it cost-efficient for businesses of any size.

Cons:

Limited features & customization: May not have as many features compared to other IAM solutions in the market. Some advanced customization options may not be available for certain use cases.

Learning curve: Users may need some time to familiarize themselves with AWS Cognito’s specific terminology and capabilities.

Dependency on AWS ecosystem: Being tightly integrated with AWS means it may not be the best option for businesses using a mix of different cloud services.

Security concerns: As with any cloud-based solution, there is always a risk of security breaches and vulnerabilities.

Google Firebase



Google Firebase is a popular choice among mobile app developers, offering a suite of tools that include robust user authentication capabilities. Firebase not only provides user authentication capabilities but also offers a variety of tools that simplify the development process, enhancing efficiency and productivity. Developers are drawn to Firebase for its real-time database, analytics, crash reporting, and plethora of other features, all wrapped up in to one intuitive package.

Pros:

Easy integration: Seamless integration with other Google services like Analytics and Cloud Functions.

Real-time database: Firebase’s real-time database allows for efficient data syncing across devices.

Scalability: Firebase can handle large amounts of data and traffic, making it a great choice for apps with high user engagement.

Cloud messaging: Firebase’s Cloud Messaging service allows developers to send notifications and messages to users across multiple platforms.

App development tools: Firebase provides a plethora of tools for app development, including machine learning, cloud storage, and A/B testing.

Cost-efficient: Firebase’s free tier is quite generous, and the pay-as-you-go pricing model allows for cost control based on usage.

Cons:

Limited control over server-side code: Firebase is a backend-as-a-service (BaaS), so developers have limited control over server-side code.

Limited query capabilities: Firebase’s database querying capabilities are limited compared to traditional databases, which may be a drawback for more complex apps.

Data migration challenges: Transitioning to or from Firebase can be a daunting task due to the unique structure of its NoSQL database. This can pose challenges in data migration and may require substantial effort and resources.

Pricing model: While Firebase’s free tier is generous, the cost can quickly escalate once the application starts scaling or requires more advanced features. This could potentially make Firebase an expensive choice for startups or small businesses on a tight budget.

Stytch: a growing force in CIAM and IAM



Stytch has a distinctively modern and flexible approach to identity management, providing a seamless user experience with features like passwordless logins and two-factor authentication across multiple devices. Its focus on simplifying user access while ensuring security makes it one of the strongest contenders in the IAM landscape.

Stytch’s highly intuitive user interface makes it easier for businesses to implement and manage identity solutions. Additionally, its customer support is noteworthy, providing timely assistance, which is a significant advantage over open-source options.

Why Stytch stands out



Stytch offers distinct B2B and B2C authentication solutions that cater to the unique requirements of each business & application model. Within the B2B SaaS authentication space, Stych stands out for its unique data model that, unlike open-source models such as Keycloak, focuses on organizations rather than individual users. 

This organization-first approach streamlines authentication management, offering a more intuitive system for B2B SaaS applications. It enhances flexibility and customization with per-organization auth settings, allowing seamless integration with various single sign-on (SSO) providers, including OIDC and SAML, and identity management controls like RBAC and JIT Provisioning. This results in a more efficient, business-aligned authentication process, significantly improving the developer experience in multi-tenant environments.

Stytch is the only auth provider with a true API-first architecture that enables you to build the exact end-to-end auth flow you need, whatever your stack. Stytch supports multiple standalone and modular options for how to integrate authentication — directly with Stytch’s APIs, leveraging Stytch’s frontend, backend, and mobile SDKs, or using out-of-the-box pre-built UI components. With a comprehensive set of powerful auth and identity primitives, Stytch offers the most composable toolset for developers to build enterprise auth systems for their SaaS applications.

Stytch also offers native fraud detection tools like Device Fingerprinting, which identifies unique characteristics of a user’s device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP addresses, helping safeguard against different types of attacks and potential breaches. By combining these elements into an identifier, there’s enough entropy to ensure that the identifier is unique to each device. The Device Fingerprinting Dashboard allows you to deep dive into individual fingerprints to understand the various devices that are querying your service.

To learn more about how these or other Stytch fraud prevention solutions work, reach out to an auth expert to start a conversation or get started on our platform for free today.

Build auth with StytchRead the Docs










---


# What is role-based access control (RBAC)?
Source: https://stytch.com/blog/what-is-rbac/

Discover RBAC: Learn how role-based permissions bolster security and streamline access management in organizations of all sizes.

When it comes to assigning user permissions based on who should have the rights to do what and why, RBAC is a flexible way to enforce access control and security according to designated roles.

With RBAC, you can categorize users as administrators or restricted users at varying levels of hierarchy. Administrators have unlimited access to all resources and can perform any action on them. While restricted users have limited access and can only perform restricted actions on specific resources.

Administrators can easily reassign users between different roles in response to security threats and changing business requirements. They can also add new users to roles as required within the system, and also revoke permissions from users who no longer belong to certain roles.

In RBAC architectures, roles are a collection of permissions that are assigned to a user or group of users, whether human users or service accounts. While permissions determine the actions these users are allowed to perform on resources.

In other words, permissions aren’t assigned to users directly. Rather, system administrators create roles and map specific permissions to those roles. Users are then assigned to roles based on the functions they’re required to perform within the system. This way, authorized users gain access by inheriting the permissions of the roles to which they belong.

Roles can be organized hierarchically, such that if a Beneficial Owner role is higher than a Bookkeeper role in the hierarchy, the Beneficial Owner will inherit the permissions of the Bookkeeper role. However, the Bookkeeper role will not inherit the permissions of the Beneficial Owner role which is senior in hierarchy.

This hierarchical structure of RBAC, as well as other implementation structures within RBAC, make it an ideal access control architecture for managing security in all types of software resources, including applications, computer networks, APIs, virtual machines, and microservices. We will discuss these implementation structures in detail later in this article.

RBAC authorization is widely used by organizations of all sizes, from small and medium-sized businesses to large, multi-tenant SaaS companies. These SaaS providers typically manage access rights and permissions for large user bases across multiple tenants. As such, managing the multitude of relationships between roles and permissions in multi-tenant SaaS architectures can be quite complex.

Roles and permissions in SaaS

To illustrate, let’s consider a project management SaaS that’s designed to enable teams to collaborate on projects — for example, Asana, Jira, Monday, Basecamp, Linear, or any other alternative that emphasizes the point. Users in this multi-tenant SaaS can assume roles such as project managers, team members, or workspace administrators, each requiring distinct access rights.

Project managers need to be able to create and assign tasks, view and edit project timelines, and communicate with team members. Team members need to be able to view and edit their tasks, as well as communicate with project managers and other team members. While Administrators need to be able to view and edit all workspace data, as well as manage user permissions.

Now, even for the same role, permissions can differ across tenants. A particular role may have varying privileges in one tenant compared to another tenant, granting it unique access rights in each context.

For instance, project managers in one tenant might have the ability to create and assign tasks, while those in another tenant may only be allowed to create tasks by their workspace administrator. This dynamic scenario highlights one of the intricate challenges involved in managing RBAC within a typical multi-tenant SaaS architecture.

That is why SaaS engineering teams typically rely on identity providers like Stytch to implement robust role-based access control (RBAC) architectures in weeks. It eliminates the security risks and development resources involved with managing an in-house RBAC solution, allowing teams to go to market faster.

In this article, we’ll explore role-based access control (RBAC), how it works, its core tenets and principles, practical applications of the RBAC model, implementation challenges and best practices, and how all of this might fit within a typical B2B SaaS application.

Why RBAC?

RBAC is a flexible security architecture. It doesn’t impose any specific security policies on organizations that adopt the model. Rather, it provides a framework for organizations to build access control systems that align with their internal security policies and requirements. This flexibility is probably one of the reasons why RBAC is so popular.

Role-based access control (RBAC) is based upon several industry-wide security principles, including data abstraction, least privilege, and separation of duties. These principles are not mutually exclusive; they work together synergistically to deliver robust and secure access control architectures.

Data abstraction: Instead of assigning permissions directly to users, RBAC uses roles to group related permissions together. These roles act as abstractions, hiding the underlying intricacies of individual permissions and access rights. This abstraction helps in creating a more organized structure for understanding what each user can do, making it easier to manage access control within organizations of any size.

Least privilege: In RBAC, users are assigned only the roles that grant them the least amount of permissions necessary to perform their designated functions. This least-privilege approach reduces your attack surface in the event of a potential security breach by limiting the amount of access an attacker can potentially have.

Separation of duties: RBAC leverages the principle of separation of duties to ensure that no single user has complete control over critical parts of an RBAC system. Sensitive functions are assigned to different roles, and approval requires the consent of multiple users. This provides an extra layer of security and accountability, and is consistent with regulatory and statutory requirements/best practices.

Discretionary and mandatory access control strategies

RBAC is well-known for its centralized and non-discretionary (NDAC) approach to access management, which sets it apart from discretionary access control (DAC) and even mandatory access control (MAC).

In non-discretionary access control (NDAC), authorization decisions are generally made by a system administrator or security policies that govern the system. As such, control is not left to the discretion or preferences of individual resource owners. Users don’t have authority over the resources they are allowed to access and are unable to transfer rights or resources to other users.

In contrast to NDAC, access control is decentralized in DAC. Resource owners have full discretion and control over who is granted access to a resource and what level of access they should have. A resource owner can decide whether to have the sole right to grant access to any particular resource or delegate that right to other users.

DAC uses access control lists (ACLs) to restrict access to resources, such as computer networks, files, and databases. ACLs define which users have access to a resource and what privileges they have for that resource. ACLs such as filesystem ACLs can be used to manage access to files, directories, or databases while networking ACLs can be used to restrict network access and what activities are allowed.

Principles of the RBAC model



So far, we’ve explored three industry-wide security principles that RBAC is based upon: (i) Data abstraction (ii) Least privilege (iii) Separation of duties. When it comes to RBAC specifically, the framework is built on three other fundamental principles that serve as its core tenets.

Different engineering, IT, and security teams may implement these principles in varying ways depending on their specific use cases. However, these underlying principles remain consistent across these organizations:

Role assignment: In an RBAC system, users must be assigned roles that align with the sets of permissions required for their specific functions within that system.

Permission assignment: The system administrator must verify that a user has the necessary permissions to perform an operation or access a particular resource, as determined by their assigned role. Users can only be authorized to exercise permissions that have been assigned to their active role within the system.

Role authorization: To prevent conflicts of interest or unauthorized elevation of privileges, the system administrator must authorize a user’s active role within the system. Users should not be able to assign roles to themselves.

How do roles and permissions work within RBAC?

By now, you should be familiar with the concept of roles and permissions in RBAC. Essentially, roles determine authorization within an RBAC system, so it’s important to define them properly.

Roles in RBAC are very different from conventional cohorts or groups. While groups are a collection or cohort of users who share common attributes, roles embody permissions and can vary widely in scope.

A role is a collection of permissions that define the operations that can be performed on specific resources within a system. Permissions determine the actions that a user can perform, as dictated by their assigned role. These permissions typically include read, write, or delete operations, and roles can be assigned to users or groups of users who require similar permissions.

For instance, roles can range from high-level designations such as a workspace administrator, to more specific roles that can inherited by multiple users, such as a bookkeeper role.

By assigning permissions to roles rather than individual users, administrators can efficiently manage how they grant or revoke access without manually configuring permissions for each user. Over time, roles become increasingly valuable as your user base grows and technical requirements evolve.

Overlapping roles and permissions

When a user is assigned multiple roles with similar or overlapping permissions in an RBAC system, they effectively inherit a combination of all the permissions associated with each role. In other words, the user gains a comprehensive set of permissions drawn from all the roles they’ve been assigned.

For example, let’s consider a content management system (CMS) where a single user is assigned two distinct roles: “Content Manager” and “Publisher.” If the “Content Manager” role grants the user permission to manage CMS settings, while the “Publisher” role allows them to publish article drafts, they would effectively possess these combined user privileges. In essence, the user would have the ability to manage the CMS and also publish drafts directly, reflecting their expanded set of permissions granted by the overlapping roles.

However, it’s important to note that RBAC restricts users from activating all of their assigned roles simultaneously. Users can only activate a subset of their roles during a single session. This approach provides flexibility, allowing users to choose and activate only the roles relevant to the specific operations they need to perform in a particular session.

The National Institute of Standards and Technology (NIST) model for role-based access control (RBAC) outlines four incremental implementation levels for RBAC. These levels guide the incorporation of roles, permissions, sessions, and other components within RBAC architectures. Each level builds upon the requirements of the previous level, offering increased functionality and complexity:

Flat RBAC

Hierarchical RBAC

Constrained RBAC

Symmetric RBAC

Level 1: Flat RBAC

Flat RBAC is the most basic level of RBAC implementation. At this level, roles are assigned permissions, and users are subsequently assigned those roles. There is no hierarchical structure for roles, and users gain the necessary permissions solely by acquiring roles within the system.

Flat RBAC acknowledges the many-to-many relationships that can exist between users and roles, allowing a single user to be assigned multiple roles and, as a result, multiple permissions. Similarly, multiple users can be assigned to the same role.

Level 2: Hierarchical RBAC

Hierarchical RBAC adds hierarchy to the role structure in flat RBAC. Roles are defined based on hierarchical levels, such that higher-level roles inherit the permissions of lower-level roles, in addition to their privileges. However, the permissions of a higher-level role cannot be inherited by any of its child roles.

In hierarchical RBAC, access control can be implemented via three main relationship structures: (i) Tree structure (ii) Inverted-tree (iii) Partial order.

In the tree-like relationship structure, roles are organized in a rigid hierarchical structure, resembling a tree. Each role has one parent (except for the top role) and can potentially have multiple child roles. This parent-child relationship establishes a strict hierarchy between roles, which may not accurately reflect complex organizational structures where roles may overlap or have conflicting interests.

In partial order, the role structure is not strictly hierarchical. While roles can have relationships, they are not confined to a strict parent-child structure. Some roles might have a partial order relationship, indicating a level of precedence or association, but not every role is required to have a direct predecessor or successor. This allows for a more flexible arrangement of roles based on the contextual relationships within organizations of different sizes.

Level 3: Constrained RBAC

Constrained RBAC extends the hierarchical model by incorporating constraints, such as separation of duties (SoD) enforced during user/role assignment and role authorization in user sessions. The separation of duties (SoD) principle is implemented within the constrained RBAC model to mitigate the risks associated with overprivileged users and potential conflicts of interest. It can be enforced in two primary modes: Static SoD (SSoD) and Dynamic SoD (DSoD).

In SSoD, a user cannot simultaneously hold roles with overlapping principles, ensuring that no single user possesses mutually exclusive roles. In contrast, DSoD permits a user to be a member of conflicting roles, but they cannot exercise both roles during the same session.

Level 4: Symmetric RBAC

Symmetric RBAC extends the other three RBAC implementation levels by incorporating the ability to review permissions associated with roles. In this way, security administrators can identify roles with more privileges than required, or roles lacking the necessary permissions to fulfill their designated functions.

Example applications of role-based access control (RBAC)

Implementing RBAC at Slack

Slack is the workplace messaging platform that enables teams to send files and instant messages about work, and was acquired by Salesforce for ~$28 billion.

Several years ago at Slack, the engineering team discovered that their predefined user roles were overly broad. This led to users having excessive privileges and power, particularly in large enterprise organizations.

At the time, assigning the Admin role to non-administrators led to complications when they had to carry out their specialized functions originally associated with the Admin role. This role granted them administrative-level capabilities, enabling lower-ranking users to perform actions beyond their seniority level within a Slack workspace.

For instance, if you assigned the Admin role to a member to have them manage a channel, they were able to perform other admin-level actions that were beyond the typical job function of a channel/community manager.

To tackle this problem of overprivileged users, Slack’s engineering team first conducted a thorough review of their roles and permissions structure, as it were. Their primary goal was to break down the extensive capabilities of the Admin role into three specialized and manageable system roles within a new RBAC system, namely: Roles admin, Users admin, and Channels admin.

Initially, the Admin role could perform a wide range of administrative functions within Slack, including inviting new users, configuring preferences, installing external applications, managing channels, and overseeing various parts of the workspace.

However, after the Admin role was broken down, newer admin roles were introduced, each with a unique set of permissions and responsibilities within Slack:

Roles admin: Users assigned to this role can manage and administer roles within an organization on Slack. They can assign users to different roles, modify role permissions, and ensure that the appropriate level of access is granted to each individual.

Users admin: Users assigned to this role can add and remove users from the Slack workspace. They can also manage user groups, which are collections of users with similar roles or responsibilities within the organization.

Channels admin: This admin is responsible for managing channels within the organization. They can edit channels, archive channels, create private channels, and switch public channels into private ones.

In Slack’s revamped RBAC architecture, when a user authenticates to a role, the RBAC service checks their permissions by querying their role information from the data store. This interaction between Slack’s web app and the RBAC service is facilitated by a dedicated remote procedure call (RPC) protocol.

By decoupling the RBAC service from the web app, Slack was able to manage permissions more efficiently, even at scale. Engineering and security teams could seamlessly add new roles and permissions, reducing the risk of inadvertently altering business logic or compromising the application’s performance and availability.

RBAC alternatives: Implementing hybrid access control in multi-tenant SaaS architectures



In multi-tenant architectural models, multiple organizations (tenants) concurrently share the same software instance or cloud compute. However, in such scenarios, coarse-grained access control (CGAC) models like RBAC may not guarantee complete isolation of tenant data, especially at scale.

SaaS applications are designed to efficiently serve large user bases by sharing resources such as infrastructure, code, and databases across multiple tenants. This multi-tenancy approach allows SaaS engineering teams to build scalable pipelines without having to dedicate extensive resources to each tenant.

To illustrate multi-tenancy, let’s consider a shared office building where multiple businesses operate independently. Each business leases its own space within the office building, but they all have to share common facilities like elevators, security services, and lounges. While they share the same physical infrastructure, these businesses operate in isolation, maintaining strict separation and autonomy.

They have distinct offices, confidential files, business models, and operations. Employees from one business don’t have access to the sensitive information or secrets of another, and each business operates in isolation.

This office building scenario closely resembles a typical multi-tenant SaaS architecture. In a multi-tenant SaaS architecture, each customer or tenant has their own dedicated and isolated portion of shared resources. This segregation ensures that each tenant’s data remains confidential and isolated, and that the actions of one tenant do not affect the operations of another tenant.

While tenants can’t access each other’s data, all tenant data is stored in the same database, and the same codebases/clusters process all the shared code and functionality. Nonetheless, each tenant can individually configure their portions of the application according to their unique requirements.

On the other hand, as multi-tenant applications grow in size and complexity, it becomes increasingly difficult to meet the unique requirements of each organization. Similar to our Slack example, SaaS applications typically provision a set of predefined roles that can be assigned to users, but these roles can become too rigid to accommodate the varying requirements within each organization.

As customers make specialized feature requests tailored to their unique use cases, SaaS engineering teams often try to accommodate them by creating highly specific roles for these individual tenants.

However, this approach can be problematic because RBAC roles are static and have a fixed set of permissions. Over time, this will inevitably lead to role explosion, where the substantial number of roles makes it highly complex to manage authorization logic across all tenants.

To implement dynamic access control without having to create specialized or specific roles, SaaS companies typically utilize fine-grained access control (FGAC) models such as ABAC (based on attributes) and PBAC (based on policies). By leveraging these models, SaaS companies can build hybrid security architectures that accommodate granular use cases, providing more flexibility and control across multiple tenants.

Unlike RBAC architectures that solely grant or deny user access based on the permissions within predefined roles, attribute-based access control (ABAC) leverages a combination of attributes to determine access decisions, and roles can be one of these attributes.

In hybrid architectures, ABAC attributes can be used in conjunction with RBAC to implement dynamic access control, without having to create additional roles. These attributes can be user attributes (e.g., user ID, role, organization, country), resource attributes (e.g., the date a resource was created), or environment attributes (e.g., the device from which a user request is originating).

To implement RBAC + ABAC, you have to incorporate your RBAC role as a user attribute within ABAC. In this way, you can use RBAC to enforce fundamental access control rules like role hierarchy, separation of duties, and least privilege. Then, you can use attributes within ABAC to further restrict access permissions based on your specific requirements.

For example, let’s consider an RBAC “Manager” role that has been assigned to perform CRUD operations on system resources. We can incorporate ABAC in this scenario by using department attributes to restrict users in the “Manager” role who also belong to the “Engineering” department to only manage engineering-related resources.

Alternatively, multi-tenant companies with more complex access control requirements can choose to implement an RBAC + ABAC + PBAC hybrid architecture. Instead of relying solely on user roles or attributes, policy-based access control (PBAC) leverages predefined policies and rules to dynamically grant or deny access to protected resources.

However, to successfully implement a hybrid architecture, your team must have a comprehensive understanding of your organization’s security policies and regulatory framework. This kind of endeavor typically requires active collaboration from a wide range of stakeholders across the organization, including DevSecOps, data teams, IT administrators, engineering teams, and even product teams.

Implementing RBAC using Stytch



Stytch provides a flexible RBAC product that’s designed to accommodate complex authorization requirements within multi-tenant architectures. Whether you’re looking to enforce robust access control in B2B, B2B2C, or B2B2B SaaS applications, we built our RBAC solution with your use case in mind.

With Stytch’s API, you can programmatically assign roles and orchestrate access control, eliminating the need to manually grant permissions one by one. Each role carries predefined permissions that members inherit and retain unless their role is explicitly revoked within the Stytch platform.

Stytch also supports implicit role assignment, where members are automatically assigned roles based on specific criteria or attributes. This mechanism allows you to define rules for automatically assigning roles to multiple members at once.

Want to see how you can implement RBAC with Stytch? Check out our documentation and sign up for a free developer account to start building with our easy-to-integrate APIs today. If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our team.







---


# What is attribute-based access control (ABAC)
Source: https://stytch.com/blog/what-is-abac/

Explore attribute-based access control (ABAC) in our post: understand its architecture, core principles, use cases, and challenges.

SaaS applications typically employ role-based access control (RBAC) to establish access permissions, enforce authorization rules, and manage relationships across multiple tenants and entities. Each user is assigned a unique role within the system, and this role is associated with a specific set of permissions and restrictions that determine what the user is allowed to access or do with resources.

However, as large microservices or multi-tenant applications scale, access control extends beyond the basic roles and permissions that RBAC provides. Instead, these kinds of systems rely on a multitude of granular attributes and conditions sourced from various data stores. This is where fine-grained access control (FGAC) models like ABAC and PBAC come into play.

For example, let’s consider the intricacies of implementing access control in a microservices-based e-commerce application similar to Amazon. Each service in such an architecture may expose its own set of resources and operations, and the access policies for each service may vary, depending on the scenario.

Assuming we have the following services:

User management service: Manages user accounts, including registration, authentication, and profile settings.

Product catalog service: Exposes APIs for managing product information, such as adding new products, updating product details, and retrieving product listings.

Order management Service: Handles order placement, payment processing, and shipping.

For a customer to successfully place an order and for it to be shipped, each service has its unique set of access policies that must be strictly met. For instance:

The User management service might allow users to authenticate and view their account information but restrict them from accessing other users’ accounts.

The Product catalog service might allow anonymous users to browse product listings but require users to be authenticated to add products to cart, strictly based on the SKUs that are legally permitted to be sold in their location.

The Order management service might require users to be authenticated and have a valid payment method on file to complete an order.

In such systems, you can’t rely on RBAC to implement these complex access requirements. These kinds of systems tend to grow exponentially, and introducing more roles as a solution to granular access requirements ultimately leads to role explosion, where it becomes almost impossible to manage large numbers of roles and permissions.

Attribute-based access control (ABAC) empowers engineering teams to implement granular and contextual access management policies by incorporating a wide range of attributes and conditions. This flexibility complements the static roles and permissions offered by RBAC and enables systems to enforce access control decisions based on a comprehensive understanding of the user or service making a request, the resource being accessed, and the context surrounding the request.

Permission leakage in RBAC

In RBAC, there’s an inherent risk that users may be able to unintentionally acquire elevated permissions beyond their designated scope. This complexity arises when different roles have similar responsibilities, leading to potential overlaps in their access privileges.

These overlaps can be intentional, allowing for more granular permissions, or they can be an unintentional consequence of poor RBAC design. Regardless of how it happens, these overlaps create the risk of users in one role having access to resources or performing actions intended for another role.

When users in different roles end up with similar or identical permissions, it undermines the fundamental principle of least privilege and attackers could exploit this permission leak to execute unauthorized actions that they would not have been able to do otherwise.

For example, let’s consider two predefined roles at Github, the version control and collaborative software development platform: (i) Organization Owner and (ii) Member.

These roles have overlapping permissions in that:

The Owner role has full control over all repositories within the organization. Owners can create new repositories, clone any repository, push changes to any repository, and delete existing repositories.

But at the same time, we also want to grant the Member role the right to create new repositories, clone repositories, push changes to these repositories, and delete these repositories.

If we decide to leverage RBAC alone to grant the Member role these privileges to be able to manage repositories, then it means the Member role will be able to manage all the repositories in the organization, just as the Owner role.

However, if we want to limit the Member role to only clone and push changes to repositories they own or have been granted access to by the repository owner, we’d have to leverage ABAC attributes to implement this kind of granular permissions.

The actions that can be performed on a repository are attributes of that repository. As such, we can use this resource attribute, alongside user attributes like predefined roles, and even contextual attributes if necessary, to determine the actions that any Member can perform on a repository.

This allows the Organization Owner to retain unlimited control over all repositories, while Members’ permissions are limited to cloning and pushing changes only to repositories they own or have been granted access to.

In essence, GitHub’s ABAC empowers organizations (tenants) to tailor access control based on their unique requirements. This granular control allows organizations to define permissions based on factors such as code sensitivity, user roles, experience level, or even team structure. This helps to ensure that code changes and deployments are properly reviewed and approved, which in turn helps to maintain code quality and alignment with organizational workflows and security policies.

Why ABAC?

Contrary to popular assumptions, ABAC isn’t a replacement for RBAC. Rather, ABAC reinforces the traditional security standards and principles, such as data abstraction, least privilege, and separation of duties, which you must have already implemented or enforced via RBAC.

Your RBAC framework uses the principle of least privilege to ensure that roles and permissions only grant the minimum level of access required to complete a specific function within the system. On the other hand, the principle of separation of duties enforces restrictions on critical parts or functions of your system, ensuring that no single user has complete control over sensitive operations.

ABAC then extends the capabilities of these existing roles and permissions by introducing attributes to how your system makes contextual and smart access restrictions/decisions. This eliminates the need for overly broad and inflexible roles and provides more scalable control over who can access what, when, where, and why.

Policies are defined by attributes, so administrators don’t need to create a separate policy for each role. Instead, a single policy can be defined using multiple attributes and then applied to any role that requires it.

Administrators can modify a user’s access permissions without having to reassign new roles to that user. They can do this by updating the user attribute values of any policy with the relevant attributes associated with the user. This way, when next the user makes a matching request, the necessary policies will be automatically applied to that user based on the updated attribute values. This makes it easy for engineering and/or DevSecOps teams to keep policies up-to-date and ensure that they’re aligned with evolving business requirements.

How does attribute-based access control (ABAC) work?

At its core, ABAC policies use dynamic boolean functions to reference attributes that determine whether a user or NPE is authorized to perform an action, as defined by the organization’s security policies.

Extensible access control markup language (XACML) is used to write the conditions, rules, and policies that govern access decisions in ABAC architectures, as specified by OASIS (Organization for the Advancement of Structured Information Standards).

XACML policies are made up of rules that define how a given request should be authorized or denied. These rules are composed of conditions and actions — the conditions specify the criteria that must be met for the action to be taken, and the actions specify what should happen if the conditions are met.

Rules in XACML are organized into policies, and policies are further organized into policy sets. Each policy and policy set within a policy configuration includes a target condition. The target condition is built using attribute names and values, and functions as a basic conditional statement, determining whether the policy or policy set can be evaluated for a specific request.

If the target of a policy or policy set evaluates to true, the policy or policy set is said to apply to that request, and subsequent policy rules will be evaluated in the order they are listed in the policy configuration. By carefully crafting the target condition, administrators can ensure that policies are only applied to the requests that they are intended for. The security of an ABAC system relies heavily on proper attribute management.

XACML, however, is quite verbose, and writing policies in it can be boring and hard to debug for most developers. While XML has historically been the standard format for XACML policies due to its defined structure and support for complex data types, JSON is gaining traction as an attractive alternative thanks to its lighter weight and performance benefits, especially in modern web applications. The latest version of XACML (3.0) now officially supports both XML and JSON as request and policy formats.

While XACML is still the most widely used ABAC standard, newer ABAC architectures are now relying on simpler languages and formats that are similar to XACML to write policies within a newer framework that’s now commonly referred to as policy-based access control (PBAC).

How do attributes work within ABAC architectures?

Attributes are sets of labels, properties, or key-value pairs that can be used to identify all the entities that must be considered for an ABAC authorization decision. These entities include the Subject (who is requesting access), the Object (what is being accessed), the Action (what is being done to the object), and the Environment (the context in which the request is being made).

In ABAC, administrators create access control policies using a combination of attributes. These policies define the allowable operations for specific combinations of subject, object, action, and environment attributes. If the attributes associated with a request satisfy the predefined conditions of a policy, the request is granted. However, if there are no matching attributes, access is denied.

Subject

Subject or user attributes describe the human user or autonomous entity that’s attempting to access a resource within an ABAC system. These subject attributes can include user ID, role, username, department, or any other relevant attributes that can be used to identify the requesting entity. For example, a user’s role might be “billing manager,” “employee,” or “contractor,” while their department could be “Engineering” or “Business Operations”, you get the gist.

In any ABAC system, each subject must be assigned specific attributes that will characterize it during authorization. However, system administrators must be the sole entity responsible for assigning or asserting attribute values to these subjects. Also, subjects must not be allowed to alter their security clearance, as clearance attributes dictate the level of access rights granted to a subject.

Object

Object or resource attributes define the characteristics of the target entities that a subject seeks to access. These attributes could include properties associated with different kinds of resources such as tables, databases, networks, servers, tenants, or microservices, where data storage or retrieval happens.

All objects within an ABAC system must be assigned specific attributes that characterize them during decision-making. These object attributes can include the creation date of a resource, its directory path, owner, format, or even sensitivity level. To maintain integrity, object attributes must not be modifiable by the subject, as this could potentially be used to manipulate the authorization decision.

Also, every object must have at least one policy that outlines the access rules for authorized subjects, permissible operations, and relevant environmental conditions for applicable requests.

Action

Action attributes define the operation that a subject intends to perform on a resource or object. These actions can include read, write, modify, or delete operations, and can be used individually or in combination with each other to define operations in more complex scenarios.

Environment

Environment attributes capture the underlying context of a subject’s request within ABAC. These attributes are independent of subject or object attributes and can include conditions like the time of a request, the device type from where the access attempt is originating, or even the encryption protocol that’s securing the connection.

Unlike subject and object attributes, environment attributes aren’t assigned administratively. Rather, they are inherently detectable by the ABAC system.

Standard ABAC architecture



The XACML standard extends beyond defining the policy language for ABAC alone. It also defines the specifications of a standard ABAC architecture, detailing how requests, policies, rules, and attributes collectively operate within a given environment. In such an environment, these components must function together to ensure seamless decision-making and policy enforcement.

A typical ABAC architecture that follows the XACML standard has five main components that must function together:

Policy enforcement point (PEP): Responsible for enforcing access control decisions and ensuring compliance with policies.

Policy decision point (PDP): Evaluates attributes, policies, and rules to make access control decisions.

Policy information point (PIP): Gathers and provides the attributes required for access control decisions.

Policy retrieval point (PRP): Retrieves relevant policies based on the request context.

Policy administration point (PAP): Manages the lifecycle of policies, including creation, modification, and deletion.

It’s worth noting that in ABAC systems where policies are written in custom policy languages like OPA (Rego), certain components like the PRP and PDP may be absent as the policy agent directly handles those functions.

Policy enforcement point (PEP)

The policy enforcement point (PEP) intercepts and evaluates requests made by subjects to access protected resources (objects) within an ABAC system. When a subject attempts such an access, the PEP captures this request and transforms it into an XACML request.

The XACML request generated by the PEP encapsulates various attributes, including those of the subject, the resource, the intended action, and any relevant contextual attributes. Once the XACML request is constructed, the PEP forwards this request to the PDP for evaluation and waits for it to make a decision before enforcing it.

The PEP enforces the PDP’s decision by either granting or denying the subject’s access to the requested object.

Policy decision point (PDP)

The PDP acts as the central decision-maker within an ABAC system. It evaluates requests from the PEP and determines if the requesting subject has the necessary permissions to access a desired resource and perform the intended action.

Whenever the PEP forwards an XACML request, the PDP evaluates the attributes associated with that request. If all the required attributes and policies are available and the request aligns with these policies, the PDP issues a “permit” decision, authorizing the subject to proceed with the requested action.

However, if the PDP identifies any missing attributes or policies critical for determining the response, it initiates additional steps to obtain the required information. In such cases, the PDP may invoke the policy retrieval point (PRP) to retrieve the missing policies or the policy information point (PIP) to obtain the missing attributes. These components work together to ensure that the PDP has all the necessary data to make an accurate and informed authorization decision.

Once the PDP has evaluated all the relevant factors and obtained the necessary information, it returns a final decision to the PEP. This decision can either be a “permit” or “deny” response. The PEP, upon receiving the PDP’s decision, enforces it by granting or denying access to the requested resource accordingly.

Policy information point (PIP)

The policy information point (PIP) functions as a centralized hub for retrieving attributes that are necessary for the evaluation of a policy.

For the PDP to make informed decisions, it calls out to the PIP to gather the subject and context attributes that are relevant to a particular request. In cases where the attribute store lacks the necessary attributes for evaluation, the PIP can connect to other data sources to retrieve the required attributes, depending on the system’s design.

However, the PIP may need to map or convert these attributes into compatible formats that can be understood and utilized by the PDP.

Policy retrieval point (PRP)

The policy retrieval point (PRP) serves as the centralized repository where all policies are stored within ABAC. This consolidation provides a single source of truth for PDPs to retrieve policy information when making authorization decisions.

As policies change to align with evolving business needs or regulatory requirements, the PRP seamlessly integrates and updates the latest policy versions that it receives from the policy administration point (PAP). This ensures that PDPs consistently have access to only the most up-to-date policy information every time.

Policy administration point (PAP)

The policy administration point (PAP) is responsible for deploying policies to the PRP for storage or directly to the PDP for decision-making, depending on the architecture. Notably, some architectures may merge PAP and PRP functionalities to streamline their policy deployment process.

The PAP empowers administrators or policy authors to define new ABAC policies, modify existing ones, and even delete redundant policies when necessary. It also manages policy versioning by providing administrators with a comprehensive audit trail of all modifications made to policies. This historical context enables administrators to understand the evolution of all policies within a system, identify trends, and pinpoint the source of any underlying errors that may arise. Administrators can choose to revert to older policy versions when necessary.

The PAP performs rigorous testing and debugging to identify syntactic or semantic inconsistencies within policies. This ensures that all policies are well-defined and adhere to XACML standards. The PAP also tests policy interactions to detect potential conflicts that may arise when multiple policies are applied simultaneously.

Real-world applications of attribute-based access control (ABAC)

Implementing ABAC at Uber

Before now, Uber relied on a hybrid PBAC + RBAC setup to secure its microservices architecture. While this system was functional, it lacked the flexibility and granularity required to handle Uber’s evolving authorization requirements.

In the previous PBAC architecture, access control policies were managed centrally by a policy service. This service assumed the combined roles of a policy administration point (PAP) and a policy retrieval point (PRP) as defined in traditional XACML-ABAC architectures. Administrators could define policies within this centralized policy service in YAML format, and this same service was responsible for distributing relevant policies to the various microservices.

In this same PBAC architecture, there was no centralized decision-making engine or service like the policy decision point (PDP) found in XACML-ABAC. Instead, each microservice independently assessed and applied authorization policies by invoking authorization APIs from a local authorization library, which essentially served as their PDP.

While this basic policy framework was adequate for straightforward use cases, it fell short in nuanced scenarios that required a more fine-grained authorization. For instance, if an Uber customer service rep needed to retrieve payment-related information of customers residing in a specific country or city, their existing YAML policy syntax couldn’t provide additional information beyond the payment profile identifier (UUID).

As such, the engineering challenge was to build a dynamic and context-aware access policy system. This new infrastructure needed to be able to evaluate access requests based on attributes from diverse information systems, instead of relying solely on roles or identifiers.

To address this challenge, Uber’s engineering team adopted Google’s Common Expression Language (CEL) to write policy conditions based on attributes. These policy conditions were then stored in an expression engine. CEL is an open-source language that can be used as an alternative to XML for writing ABAC policies.

They also introduced an attribute store to house all the attributes referenced in the expression engine and implemented a policy information point (PIP) to manage attribute retrieval from the store. This attribute store serves as a repository where consumer services can access and retrieve attributes tailored to their unique business use cases.

In Uber’s revamped ABAC architecture, the authorization engine must obtain attribute values from the attribute store based on the conditions specified in a particular policy. Subsequently, the conditions and attribute values are then forwarded to the expression engine, which evaluates them and returns a boolean result.

Uber currently uses this ABAC architecture to orchestrate authorization for more than 70 microservices. This architecture also secures other critical infrastructure components, such as Kafka, which plays a crucial role in managing distributed communication among these services within Uber.

The problem with implementing ABAC

ABAC architectures can be complex to design and maintain, especially for small engineering teams with limited resources and experience. While ABAC allows for more dynamic and contextual decision-making, this flexibility comes at the cost of a more complex implementation when compared to RBAC.

To implement ABAC, organizations have to manually define attributes, assign them to each entity, and map these attributes to specific rules and policies within the system. This ABAC mapping process can be very time-consuming and error-prone, especially for large organizations with complex development environments and business models.

On the other hand, XACML policies are complicated to write. Orchestrating these policies requires converting every possible access request into XML, which is highly sensitive to syntax. As such, making future modifications to attributes, rules, policies, or policy sets can turn into a painful task.

Implementing ABAC truly requires significant time and resources. However, considering the authorization flexibility it provides, particularly within large architectures, the investment is worthwhile in the long run.

Implementing access control using Stytch



We’ve successfully explored the good and granular parts of ABAC. However, ABAC isn’t a “must-have” framework. It’s what you implement as your infrastructure scales and the authorization need arises.

For new engineering teams, you’ll almost always have to deploy a set of roles and permissions in a typical RBAC architecture and test these roles in production with live users, before leveraging ABAC to cover up the loopholes that RBAC can’t fill.

Moreover, even multi-tenant SaaS applications that may need to implement hybrid architectures from the get-go still have to implement RBAC, before going ahead to use these RBAC roles as attributes in ABAC.

Want to see how you can implement RBAC with Stytch? Check out our documentation and sign up for a free developer account to start building with our easy-to-integrate APIs today. If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our team.







---


# RBAC vs PBAC vs ABAC
Source: https://stytch.com/blog/rbac-vs-pbac-vs-abac/

Compare RBAC, PBAC, and ABAC in our blog post: key differences, strengths, use-cases, and decide which is best for your security needs.

Choosing the right access control model is a tough nut to crack for engineering and DevSecOps teams, particularly in modern architectures that leverage multi-tenancy, cloud repositories, microservices, or APIs to deliver product experiences.

Without the requisite level of access control safeguarding a system, attackers can always exploit security loopholes to perform unauthorized operations within that system. This explains why organizations dedicate significant time and resources to continuously refine their access control systems to align with evolving security requirements and best practices.

Now, you might be wondering which access control framework is the most secure or superior.

The thing is, there’s no one-size-fits-all approach when it comes to authentication and authorization. The right access control model — whether it is RBAC, PBAC, ABAC, or a hybrid approach — heavily depends on the specific context and prevailing circumstances of your organization at the time. It depends on the size of the business, the complexity of operations and business model, the sensitivity of data and resources being protected, or even industry regulatory requirements.

RBAC is an excellent choice for small to medium-sized organizations, engineering teams, or IT departments with straightforward access control requirements. However, PBAC and ABAC are better suited to large organizations with complex workflows and relationships, and the necessary engineering, IT, and DevSecOps resources to effectively manage this complexity.

In this article, we’ll explore the key differences and applications of three access control architectures — RBAC, PBAC, and ABAC. We’ll unravel their distinctive characteristics and potential similarities to arm you with the requisite knowledge to make an informed decision when selecting the most suitable model for your use case.

The static parts of role-based access control (RBAC)



Role-based access control (RBAC) is a widely adopted model for restricting access to system resources based on assigned roles, rather than individual identities.

Roles are a set of permissions that can be assigned to individuals or groups of users, including human users or non-person entities (NPEs) such as applications or services. Permissions, in turn, define the specific actions that these users are allowed to perform on various resources within the system.

However, it’s important to note that permissions are not directly assigned to users in RBAC. Instead, administrators define roles and associate specific permissions with them. Users are then assigned to suitable roles based on their responsibilities and functions within the system.

RBAC stands out as a highly adaptable access control framework because it doesn’t impose any specific set of security rules or principles on organizations. Instead, RBAC can be implemented in four distinct incremental levels, each incorporating widely recognized security principles and policies.

These principles, such as the principle of least privileges, data abstraction, and separation of duties, are integrated at the different implementation levels, allowing organizations to tailor the framework to their unique access management requirements.

Nonetheless, if you consider how permissions are assigned to roles and roles to users, RBAC is a highly rigid and static framework. Both roles and assigned permissions are predefined and inflexible.

Roles are strictly associated with permission sets and users are confined to these roles unless administrators initiate any changes. This static nature of RBAC can be limiting for complex architectures that frequently require adjustments to responsibilities, data sensitivity, or even security requirements. In such scenarios, organizations might opt for more dynamic access control models, such as PBAC or ABAC, to gain finer control and make granular decisions.

To provide finer-grained access permissions via RBAC, the model allows users to be assigned to multiple roles with overlapping permissions, and higher-level roles can inherit permissions from lower-level roles. However, this approach also introduces inherent security weaknesses.

Overlaps, whether intentional or unintentional, can grant users access to resources or allow them to perform actions intended for other roles. Consequently, this compromises the security principles that RBAC aims to uphold in the first place.

We’ve written a comprehensive article that covers roles-based access control (RBAC) in depth. You can find it here.

The pseudo-granular parts of policy-based access control (PBAC)



While PBAC and ABAC are often used interchangeably, they’re distinct concepts that only share similarities. All ABAC architectures can be considered as PBAC, but not all PBAC architectures qualify as ABAC.

Policy-based access control (PBAC) is an overarching term that refers to any access control system that uses policies to determine access permissions. In contrast, ABAC is a specific type of PBAC that employs attributes within its policies to make access control decisions.

Basic or traditional PBAC introduces more flexibility to the static roles and permissions in RBAC by incorporating predefined rules within its policies. These rules enable conditional relationships between requesting subjects or users (defined by role or group), the objects or resources being accessed (specified by resource type, path, or identifier), and the actions being performed on these resources (create, read, write, or delete operations).

While PBAC extends the capabilities of RBAC, it doesn’t match the fine-grained access control provided by ABAC. For example, Uber initially ran their microservices architecture on a basic PBAC with YAML policies centrally managed by a policy service. These YAML policies contained predefined rules that didn’t directly use attributes but referenced predefined roles, resource types, and actions.

While this basic PBAC system was functional in straightforward scenarios, it lacked the flexibility and granularity required to handle Uber’s evolving authorization requirements. For instance, customer service reps couldn’t retrieve payment-related information beyond the payment profile identifier (UUID) for customers in a specific country or city.

To address this problem, Uber migrated to an ABAC architecture and adopted dynamic policies based on attributes rather than rule-based policies. They leveraged Google’s Common Expression Language (CEL) to write policy conditions drawing upon different attribute sources within Uber and stored these conditions in an expression engine. They also introduced an attribute store to centralize all attributes referenced in the expression engine and implemented an attribute retrieval system that consumer services could use to retrieve attributes relevant to their unique business domains and operations.

For a more comprehensive exploration of Uber’s revamped ABAC architecture, refer to our “What is attribute-based access control (ABAC)?” article.

The choice of policy language (whether it’s XML, ALFA, OPA, OPAL, or CEL) might seem like a defining factor in categorizing an architecture as ABAC or PBAC. However, the key distinguishing feature lies elsewhere. What truly sets these architectures apart is whether they rely on attributes or rules and adhere, even loosely, to the standard ABAC-XACML architecture, which consists of PEP, PDP, PRP, PAP, and PIP components.

The fine-grained parts of attribute-based access control (ABAC)



Unlike RBAC’s static roles and PBAC’s predefined rules, attribute-based access control (ABAC) empowers organizations to implement contextual access management policies by incorporating a wide range of dynamic attributes and conditions.

Think of these attributes as unique labels or properties attached to users, resources, actions, and even the environment where an interaction occurs. Much like a human’s fingerprint, the combination of these attributes creates a detailed and distinctive profile for each access request, enabling highly precise and context-aware access control.

For instance, a user might possess the attribute “seniorEngineer,” a resource could have the attribute “confidential,” an action might be labeled as “edit,” and an environmental condition might be “deviceType.” If the attributes associated with a request align with the predefined conditions of a policy, access is granted; otherwise, it’s denied.

This flexibility enables systems to enforce access control decisions based on a granular understanding of the user or service making a request, the resource being accessed, and the context surrounding the request.

ABAC architectures leverage XACML (Extensible Access Control Markup Language), as specified by OASIS (Organization for the Advancement of Structured Information Standards), to define the conditions, rules, and policies that govern access decisions. However, modern organizations are increasingly embracing more user-friendly open-source policy languages to craft ABAC policies.

While XACML remains the standard for expressing ABAC policies, its complexity and debugging challenges have led to the development of alternative policy languages. These languages streamline the policy-writing process, making it more accessible to developers.

ABAC rules, irrespective of whether they’re written in XACML or other policy languages, significantly differ from the basic PBAC rules we observed in the Uber example. ABAC rules are constructed using attributes and function as conditional statements that determine whether a policy or policy set can be evaluated for a specific request. This approach eliminates the need for broad and inflexible roles, providing more granular control over who can access what, when, where, and why.

The XACML standard is not just a policy language for ABAC, but also an architectural guide. It defines how requests, policies, rules, and attributes should interact within ABAC systems, ensuring seamless decision-making and policy enforcement. This architecture functions as a well-coordinated system, with each component playing a crucial role.

A typical ABAC architecture that adheres to the XACML standard consists of five primary components that work in tandem:

Policy enforcement point (PEP): Oversees compliance with established policies and enforces decisions that must have been made by the PDP.

Policy decision point (PDP): Serves as the central evaluator and decision-maker, assessing attributes, policies, and rules to grant or deny access permissions.

Policy information point (PIP): Functions as a data provider, retrieving and supplying the necessary attributes required by the PDP.

Policy retrieval point (PRP): Acts as the policy retriever, fetching relevant policies based on the specific context of the request.

Policy administration point (PAP): Manages the entire policy lifecycle, including the creation, modification, and deletion of policies.

It’s essential to acknowledge that not all ABAC systems strictly conform to this standard structure. In ABAC systems that employ custom policy languages, certain components, such as the retrieval and decision points may be absent since the policy agent directly manages these functions. Despite these variations, becoming acquainted with the XACML architecture provides a valuable framework for understanding the overall flow and interactions within an ABAC system.

How to choose the right access control model for your use case?

Choosing the right access control model is a highly contextual decision. Different models provide distinct advantages and drawbacks, depending on your specific requirements and context.

For example, RBAC is commonly preferred for its simplicity and straightforward implementation, particularly suitable for CRUD applications. However, RBAC’s static nature can be restrictive in dynamic development environments where access decisions are fluid or context-dependent.

ABAC, on the other hand, is highly suitable for architectures that require flexibility and granular control. ABAC’s fine-grained approach makes it particularly valuable for managing complex relationships within dynamic or highly regulated environments. However, this flexibility comes at the cost of increased complexity and administrative burden.

The right access control model extends beyond comparing RBAC, ABAC, and PBAC. Your specific infrastructure and applications play the most vital role.

For instance, SaaS applications introduce multi-tenancy and shared responsibility models that necessitate tailored access control strategies in a hybrid model. Microservices architectures, with their distributed nature and dynamic scaling, also require consistent and dynamic security across multiple services and components simultaneously.

Ultimately, your decision hinges on finding the right balance between security, usability, and scalability:

Security: How sensitive is the data you’re protecting? What level of granularity and control do you need to enforce?

Usability: How easy should it be for authorized users to access resources? How will/do users feel about the experience?

Scalability: Can the chosen model adapt to your organization’s growth and evolving requirements? Will it remain manageable as systems and user bases expand? Can the complexity of ABAC be justified by the granular control?

By carefully assessing your requirements and constraints, you can navigate the inherent complexities of these access control models and choose the approach that best protects your systems from unauthorized access. Remember, it’s not just about choosing a model alone, it’s about finding the right balance for your specific use case.

You should choose RBAC if……

For many organizations, simplicity and ease of management is highly important when it comes to access control. This is where RBAC shines. It’s an excellent solution for straightforward scenarios, such as:

Small and medium-sized businesses: Ideal for small businesses with well-defined user groups, roles, and limited data sensitivity. Imagine an e-commerce platform with clearly defined roles for customers, editors, and administrators. Each role has distinct permissions, making access control straightforward to maintain.

Internal corporate applications: Many internal business applications have predictable user roles and access requirements. For example, a CRM system used by a sales team might only require a handful of roles, each with specific permissions for viewing, editing, or managing customer data.

Simple CRUD applications: RBAC excels in managing access to basic data operations like create, read, update, and delete. Consider a blog platform where users have clearly defined roles (author, editor, reader) with corresponding permissions for managing content.

In these kinds of applications, many users perform the same function, and their responsibilities rarely change. As such, only a handful of roles are needed, which can be assigned to as many users. In this case, RBAC effectively restricts system access and enforces the necessary level of control without imposing excessive administrative burdens.

You should choose PBAC if……

For organizations looking to move beyond the limitations of RBAC without dealing with the full complexity of ABAC, PBAC can be a strategic middle ground. It offers more granular control than static RBAC roles while remaining less resource-intensive and complex than ABAC’s dynamic attributes. Here are scenarios where PBAC excels:

Transitioning from RBAC to ABAC: If your organization has outgrown RBAC’s rigidity but lacks the resources or infrastructure for a full-fledged ABAC implementation, PBAC can serve as a stepping stone. You can leverage existing RBAC roles as a foundation and add PBAC policies for finer-grained access control based on predefined conditions, such as time of day, location, or specific actions. This hybrid approach allows you to gradually evolve your access control without a complete overhaul.

Addressing specific limitations in RBAC: Perhaps you need more nuanced access control within specific areas of your system, say controlling access to sensitive data. You can address these limitations without modifying your entire RBAC structure by implementing PBAC policies alongside your existing RBAC roles. For example, you can create PBAC policies that require additional authorization for accessing highly confidential files, even for users within specific RBAC roles.

You should choose ABAC if……

For organizations that require dynamic and context-aware access control mechanisms beyond traditional policies or roles, ABAC is the most suitable approach. Unlike RBAC’s static roles and PBAC’s pre-defined rules, ABAC leverages dynamic attributes and conditions to identify every single request. Here are scenarios where ABAC excels:

Dynamic business models and environments: Organizations adopting cloud deployments, microservices architectures, or multi-tenancy encounter highly dynamic access control challenges. However, ABAC’s flexibility empowers these organizations to seamlessly manage access control across diverse systems, dynamically determining access permissions based on set policies and evolving business requirements.

Complex compliance requirements: In heavily regulated industries like healthcare or government, stringent data access regulations demand granular control. ABAC excels in meeting these requirements by leveraging attributes like user certifications, data classification, and even device location to enforce fine-grained access policies.

Implementing RBAC using Stytch



Contrary to popular misconceptions, RBAC, ABAC, and PBAC aren’t features of any particular identity provider (IDP). Rather, they are distinct architectural patterns for governing access to system resources.

For multi-tenant Saas applications that require dynamic RBAC, our robust B2B authentication product has been designed to effortlessly handle diverse multi-tenancy requirements, including per-organization settings, memberships, and both self-serve and enterprise onboarding.

With Stytch, you gain precise control and customization capabilities. You can conveniently store application-specific or business-specific attributes within both the organization and member objects. This empowers you to tailor the authentication experience to your unique requirements, ensuring a seamless and personalized journey for your customers and their end users.

To learn more about RBAC using Stytch, check out our documentation and sign up for a free developer account to start building with our robust APIs. If you have any questions, please reach out to an auth expert to start a conversation or send us a message at support@stytch.com.







---


# What is SaaS integration and why should developers consider it?
Source: https://stytch.com/blog/what-is-saas-integration/

This article delves into the capabilities, use cases and challenges of SaaS integration and what to look for in SaaS providers when building your own business or applications – especially for complex B2B and SaaS-centric projects leveraging many different SaaS solutions at scale.

In an era where agility and operational efficiency are paramount, Software as a Service (SaaS) has become an unparalleled driver of innovation and transformation for many organizations. Central to this evolution is SaaS integration, a critical aspect that streamlines application interactions, data sharing, and processes.

This article delves into the capabilities, use cases and challenges of SaaS integration and what to look for in SaaS providers when building your own business or applications – especially for complex B2B and SaaS-centric projects leveraging many different SaaS solutions at scale.

SaaS applications: tools of many trades

SaaS applications have witnessed exponential adoption driven by their scalability, cost-effectiveness, and user-centric design. Today, almost every modern business or developer team in any industry engages with a wide spectrum of SaaS solutions, such as tools that enhance customer engagement like advanced Customer Relationship Management (CRM) systems, Enterprise Resource Planning (ERP) solutions, and developer productivity-focused apps like Jira, Github, Datadog or Sentry. Security and authentication solutions like Stytch also provide scalable, low-lift options for many different use cases.

These applications have become the cornerstone of growth and productivity in the digital age, enabling businesses to navigate market dynamics, scale operations efficiently, and elevate service delivery without significant capital investment in engineering.

When to consider a SaaS service

So when should a developer or business consider using SaaS services for their apps? A great example is for the deployment of Customer Identity Access Management (CIAM). A SaaS Customer Identity Access Management (CIAM) service provides businesses with crucial up-to-date security and functionality without extensive in-house maintenance or technical expertise. Closed-source SaaS CIAM solutions, maintained by dedicated developer teams, ensure your system regularly receives critical updates and feature enhancements, alleviating the burden on your engineering and IT staff and keeping your security measures robust.

Moreover, as your business grows, the scalability and support offered by a SaaS CIAM become invaluable. These solutions automatically adjust to your expanding needs while providing comprehensive customer support to swiftly address any issues. This combination of flexibility and expert assistance makes a SaaS CIAM a no-brainer budget item for many businesses and developer teams.

Aside: Stytch stands out in the CIAM space with its innovative and adaptable strategies, offering users a frictionless experience through passwordless access and multi-device two-factor authentication. By prioritizing ease of access alongside proven security measures, Stytch could be your ideal partner in SaaS integration for CIAM. Learn more.

Core benefits of SaaS integration

Simple SaaS integration refers to the process of connecting different applications and services together to create a unified ecosystem, improving efficiency, productivity, and ultimately, creating better customer experiences.

A SaaS app integration strategy serves as the linchpin in this process, providing the necessary frameworks to bridge several applications, thereby amplifying the benefits of SaaS integration.

API Integrations

API integration is the cornerstone of effective SaaS connectivity, enabling disparate applications to communicate, share data, and function in unison. Through well-defined Application Programming Interfaces (APIs), enterprises can establish secure, reliable, and efficient data exchanges between SaaS applications regardless of the individual software architectures.

An API-centric approach to integration is fundamental in creating a connected enterprise ecosystem where business apps sharing data can drive enhanced operational efficiency and agility.

Despite the ease with which APIs can help SaaS solutions integrate and interact with one another, various complexities often thwart (or substantially slow down) the most ambitious integration roadmaps.

Overcoming integration challenges

To tackle the technical complexities of SaaS integration, businesses must navigate certain challenges inherent in their organization. The payoff is well worth it for many organizations seeking to unleash the full potential of their growing SaaS ecosystem.

Data security and compliance

As businesses integrate SaaS applications to share data and streamline workflows, ensuring the security and compliance of cloud data becomes paramount. This involves navigating the complexities of cloud service agreements with SaaS vendors, understanding the terms of SaaS integration, and ensuring that data transfer protocols meet stringent security standards.

Additionally, with the increasing focus on data privacy regulations such as GDPR and CCPA, businesses must also ensure that their SaaS integrations comply with these regulations to avoid costly fines and reputational damage.

To address these concerns, many organizations are turning to specialist SaaS integration tools that offer advanced security features such as encryption and access control, as well as compliance monitoring and reporting capabilities.

High-friction, tedious authentication methods have long dominated the B2B security landscape. Stytch’s GDPR-compliant B2B SaaS auth platform doesn’t sacrifice usability for security, making it easy to build enterprise features like SSO and MFA in minutes rather than months. With Stytch, you could save resources and convert more prospects. Learn more.

Technical compatibility and integration complexity

One of the foremost challenges in SaaS integrations is ensuring technical compatibility across diverse platforms. SaaS integration of applications like CRM systems, ERP solutions, and business intelligence tools with existing internal systems often involves complex technical work that, given the size and global distribution of an organization, can be a deterrent.

In the average enterprise organization, many SaaS apps and legacy systems must coexist and share data freely, necessitating sophisticated SaaS integration flows and custom integration solutions or a bespoke integration platform. Tying them all together is no easy feat, often requiring a meticulous process of untethering old solutions while introducing new information management processes to scores of employees across siloed departments.

Data silos and manual data entry

It’s clear to many modern organizations that data and department silos obstruct the free flow of information across the business ecosystem where integration is key to grow, scale, and thrive. These silos not only impede business operations but also lead to increased manual data entry, a time-consuming process prone to human error.

Effective SaaS integrations aim to break down these silos, enabling business apps to share data seamlessly and automate processes while mitigating human error. In the future, an interconnected system will be even more crucial as AI algorithms take the reins on routing data across departments with greater efficiency than ever before,

What to look for in SaaS companies



While integrating with SaaS providers can be an organizational challenge, the right approach can also be transformative. Here are a few crucial things to consider when assessing SaaS solutions.

Robust API integration platform capabilities

A SaaS provider that offers robust API integration capabilities can significantly accelerate integration development. APIs are the connective tissue that enable different software systems to communicate, facilitating seamless data flows between SaaS platforms and internal systems. These capabilities ensure that data is synchronized in real time, reducing the risk of outdated or conflicting information.

Businesses should look for SaaS solutions that offer the flexibility for both custom and native SaaS integration. Custom integration allows businesses to tailor the integration according to their unique workflows and business processes, while native integrations provide out-of-the-box connectivity with popular business tools, reducing the technical work involved. A combination of both options provides the best of both worlds, ensuring maximum flexibility and efficiency in data sharing. Don’t short sell yourself on anything less.

Scalability and cloud-based services

The ideal SaaS integration solution should be scalable, capable of growing with the business. Cloud-based services offer this scalability, allowing businesses to adjust their usage based on current needs without significant upfront investment in physical infrastructure. This also allows for easier and quicker deployment of new integrations as the business expands or changes. Additionally, cloud-based services often offer higher levels of reliability and uptime compared to on-premise solutions.

Data mapping and transformation

Another crucial aspect of data integration is data mapping and transformation. The ideal SaaS solution should have robust data mapping capabilities that allow for easy translation between different formats and systems, such as converting data types, aggregating information, and filtering datasets to meet the specific requirements of different systems and applications. It should also provide options for data transformation, allowing businesses to manipulate data before it is integrated into the target system. This level of data manipulation ensures that the information being shared between systems is accurate and consistent.

Effective data mapping tools should facilitate seamless communication between disparate software, eliminating the potential for data silos and ensuring that all systems are operating with the current and correct data.

Customizable integration flows

A SaaS solution should offer the versatility to accommodate various types of integrations and support different application architectures, such as backend systems, frontend interfaces, mobile platforms, and various web frameworks. This flexibility enables businesses to tailor their integration strategies to their specific needs, streamlining the connectivity between SaaS applications and internal systems, and thus enhancing the cohesion within the enterprise.

SaaS apps and solutions that provide a comprehensive library of pre-configured integration templates for widely-used applications significantly simplify the integration process. This approach not only reduces the initial setup time and complexity but also facilitates ongoing management and seamless updates in line with the latest application releases, ensuring that integrations remain robust and effective over time.

Authentication and identity management in SaaS application integration



The role of authentication and identity management systems in these highly complex digital ecosystems cannot be understated. There is a steadfast and growing need for secure, seamless connectivity, and a key aspect of successful SaaS integration is ensuring that authentication processes are both efficient and impenetrable.

Stytch’s SaaS authentication solutions

Stytch offers tailored SaaS authentication solutions that streamline the user onboarding process and help bolster conversion rates. You can quickly implement sophisticated features such as Single Sign-On (SSO) and Multi-Factor Authentication (MFA), transforming a months-long project into a task that can be completed in minutes. Our API and SDKs help conserve valuable resources while optimizing your user experience, leading to higher conversion rates and a more secure authentication framework.

Stytch’s fraud prevention solutions

Stytch also offers fraud prevention tools that form a powerful additional layer of security against fraud, provisioning scalable, secure access to systems within enterprises and businesses of all sizes.

Stytch’s Device Fingerprinting (DFP) can protect against automated attacks by aggregating various attributes of a user’s device into a unique identifier, ensuring a high degree of accuracy in distinguishing legitimate users from fraudulent actors. The use of attributes like browser type, screen size, operating system, and timezone, combined into a single identifier, provides a unique ‘fingerprint’ for each device, effectively detecting and blocking bad bot traffic.

A step beyond traditional CAPTCHA, Stytch’s Strong CAPTCHA uses complex challenges that are easy for humans but difficult for bots to solve, effectively distinguishing between legitimate users and automated systems.

Through working with Stytch, businesses can significantly improve their authentication processes, leading to a more securely connected, efficient, and harmonious SaaS environment that fuels an exceptional customer experience for their end users.

To learn more about how these or other solutions work, reach out to an auth expert to start a conversation.







---


# B2B SaaS applications: A comprehensive overview
Source: https://stytch.com/blog/b2b-saas-applications-a-comprehensive-overview/

Explore the intricacies of building B2B SaaS applications with a focus on the essential technologies like cloud services, APIs, and DevOps strategies that drive scalable, secure solutions. This comprehensive guide delves into overcoming development challenges and harnessing trends like AI and serverless computing to innovate in the B2B SaaS space.

The B2B SaaS (Business-to-Business Software as a Service) sector is a dynamic field that is reshaping the way applications operate at scale with security and organizational efficiency. These solutions are designed to meet the diverse and evolving needs of applications across various use cases and technologies. Increasingly, they have become table-stakes in an always-on, internet and cloud-native business world, where borders blur and information freely flows.

This article aims to provide developers with an in-depth understanding of the modern complexities involved in creating best-in-class B2B SaaS platforms, with a focus on the foundational technologies that enable advanced systems to flourish and gain a competitive edge, such as cloud computing services, APIs, CI/CD pipelines, DevOps strategies, multi-tenancy and scalability, and SaaS authentication.

Foundational technologies in business to business software

Cloud computing, APIs, and technologies facilitating efficient, agile development are the bedrock of the B2B SaaS industry, enabling SaaS companies to offer cloud-based software that is both scalable and flexible. To the great benefit of countless businesses, many of these solutions and practices have effectively eliminated the high upfront costs and maintenance challenges associated with traditional self-hosted software solutions. It’s a new era of lower overhead and higher potential.

Popular global cloud services providers like AWS, Azure, and Google Cloud not only supply the necessary infrastructure but also offer comprehensive suites of tools that enhance the development, deployment, and management of SaaS applications. These capabilities make cloud-based solutions an ideal choice for applications of all kinds, ensuring they have the resources to scale and adapt in a fast-paced (and constantly accelerating) digital market.

The cloud: a global app enabler

The adoption of cloud computing in the B2B SaaS industry has paved the way for more efficient application development, allowing companies to focus on their core competencies rather than IT infrastructure management – a particularly strong benefit for businesses with a global footprint.

Among other benefits to application development for B2B SaaS, cloud platforms reliably provide:

Ready-to-use infrastructure, enabling developers to bypass the lengthy setup and configuration of physical servers, significantly speeding up the initiation of projects.

Quick prototyping, allowing developers to test and iterate on their ideas swiftly and get products to market faster.

Dynamic scaling that adjusts resources to meet application demands, ensuring optimal performance without manual intervention, even during unexpected surges in usage.

Global high availability and reduced latency, offering a consistent user experience worldwide through global cloud infrastructure providers.

These high level benefits enable B2B SaaS companies to focus on innovation and delivering value rather than time-consuming infrastructure management and scalability challenges.

APIs: Building blocks of B2B SaaS solutions

APIs serve as crucial connectors in the developer’s toolkit, particularly within the B2B SaaS landscape. They enable fluid communication and integration between various software applications, including essential developer tools like GitHub and Jira. By bridging SaaS platforms with these developer-centric applications, APIs not only streamline the development workflow but also enhance collaboration and project management capabilities.

This seamless integration is key to automating workflows, from code commits and version control in GitHub to task tracking and sprint planning in Jira, making the development process more efficient and cohesive. Through APIs, developers can effectively link their SaaS solutions with a broad array of enterprise and productivity tools, transforming their ecosystem into a comprehensive operational nexus.

Interoperability and data sharing

Interoperability plays a crucial role in creating a cohesive software ecosystem, especially when facilitated through APIs, SDKs, and various protocols that developers work with. This interconnectedness enables the seamless exchange of data across a multitude of applications, enhancing the functionality and efficiency of development tools.

For instance, integrating a B2B SaaS solution with version control systems like GitHub or project management tools like Jira through APIs can streamline the development process, providing real-time insights into code changes, issue tracking, and team collaboration. This level of data sharing and interoperability allows developers to synchronize workflows, automate processes, and ultimately, optimize the development lifecycle, leading to more efficient project completion and resource allocation.

The pivotal role of CI/CD

Continuous Integration and Continuous Deployment (CI/CD) pipelines are crucial for maintaining the agility and quality of B2B SaaS solutions. By automating the integration, testing, and deployment processes, CI/CD pipelines ensure that updates, whether they are new features, enhancements, or bug fixes, are seamlessly and efficiently rolled out without impacting normal business operations. This continuous delivery model is well suited to the fast-paced SaaS market, where the ability to quickly adapt and respond to customer feedback provides a competitive edge.

CI/CD practices also significantly reduce the overall customer acquisition cost for SaaS companies. By enabling faster deployment cycles and ensuring high-quality releases, CI/CD pipelines help SaaS providers quickly address market demands and customer needs. Furthermore, the automation of testing and deployment processes reduces the risk of errors and downtime, ensuring that SaaS solutions remain reliable and accessible.

DevOps: Streamlining improvements in B2B SaaS

The integration of DevOps practices within the B2B SaaS development process marks a significant advancement in how cloud-based software is delivered and maintained. DevOps methodologies emphasize collaboration, automation, and continuous improvement, bridging the gap between development and operations teams. The DevOps approach prioritizes speed of innovation, time to market, and stable operations – critical for success in SaaS.

In the context of B2B SaaS, DevOps strategies streamline the delivery of cloud-based solutions and enable SaaS companies and their developer teams to rapidly iterate on their products, responding effectively to the evolving needs of their customers and end users.

Designing for scalability, security and collaboration





So what really is at the core of a successful B2B SaaS solution? With more data and value moving online and myriad possibilities for storage and sharing, few would disagree that scalability, security, and seamless collaboration represent the foundational pillars of SaaS now and into the future.

The future of scalability and microservices

Scalability is crucial for B2B SaaS solutions to ensure that platforms can effortlessly manage the often exponential growth in user base and workload. Fortunately, cloud-based solutions have the unique ability to dynamically scale resources as demand fluctuates, allowing SaaS platforms to efficiently handle peak loads and accommodate business growth.

The adoption of a microservices architecture plays a vital role in the current cloud environment. By structuring applications as a collection of loosely coupled services, each can be scaled independently, enhancing the system’s overall flexibility and resilience. This architectural style is particularly beneficial for B2B SaaS providers, as it aligns with the software distribution model that emphasizes reliability and performance under varying loads. For more on microservices, see trends shaping the future of B2B SaaS below.

Prioritizing Security in the SaaS Ecosystem

Security is a critical concern in the B2B SaaS sector, especially given the handling of sensitive business data such as financial records and personal employee information. Implementing robust security protocols is non-negotiable, but not often easy in complex, distributed organizations. At the very least, a secure approach to B2B SaaS must include end-to-end data encryption to safeguard data in transit and at rest, as well as secure API gateways to manage safe interactions between different components of the SaaS platform.

Adherence to industry-standard security frameworks and regular security audits are also essential practices for B2B SaaS providers. These measures not only help in identifying and mitigating vulnerabilities but also reinforce the platform’s credibility and reliability.

Authentication and identity systems

While in-house solutioning for B2B SaaS can save money and effectively utilize resources in some cases, developing an in-house authentication and identity management system for a B2B SaaS solution is a particularly complex endeavor. Creating such a system from scratch demands a deep understanding of security principles, as well as significant time and resources to implement features like multi-factor authentication and single sign-on capabilities. These features are crucial for ensuring that the system can protect sensitive data and withstand a wide array of security threats.

Additionally, developers must ensure the system is scalable to accommodate growing user bases without compromising performance or user experience, requiring substantial development work plus continuous monitoring and updating.

As your B2B SaaS solution grows, Stytch offers a scalable solution tailored for complex organizational structures, simplifying authentication across your application. With customizable UIs, APIs, and SDKs that adapt to your unique requirements, Stytch provides reliable and seamless identity management for complex B2B SaaS environments. Learn more.

B2B SaaS development challenges

Given the high expectations we’ve covered for a seamless and reliable experience in B2B SaaS, the task for developers in building best-in-class B2B SaaS ecosystems is multifaceted and complex. It’s crucial that developers feel well-equipped to deliver solutions that not only meet but exceed the evolving expectations of business clients in an internet and cloud-native era.

The B2B SaaS pillars of multi-tenancy, scalability, modular design, and customization comprise a few of the more prominent technical challenges that are crucial for developers to understand and work with.

Multi-tenancy and scalability

Multi-tenancy involves creating a SaaS platform where a single instance of the software serves multiple client organizations (tenants), while keeping their data separate and secure. The challenge lies in ensuring robust data isolation, efficient resource utilization, and consistent performance across all tenants. Developers must design the architecture in a way that updates, maintenance, and new feature deployments can be rolled out seamlessly to all tenants without disruption, ensuring data privacy and security for each tenant’s environment.

As B2B SaaS platforms grow in multi-tenant environments, they must be able to handle an increasing number of users, data volume, and transactional demands without compromising performance. Scalability challenges that developers face include maintaining fast response times, managing larger datasets, and ensuring reliable uptime as the user base expands. Cloud-based solutions and microservices architectures allow resources to be dynamically allocated and scaled according to demand, ensuring the platform can grow with the business needs of clients.

Modular design

Embracing a modular design, or a development approach for B2B SaaS platforms where the software is constructed using distinct, independent modules or components. allows for flexibility in development, making it easier to update and maintain different parts of the application without affecting the whole system.

In a modular design, each module serves a specific function and can be developed, tested, and updated independently of the others. This design strategy allows developers to make changes or add new features to one module without impacting the entire system, simplifying maintenance and updates as each module can be addressed separately. For B2B SaaS ecosystems, this means being able to tailor and extend functionalities to meet diverse business requirements without overhauling the core application, ensuring the platform remains adaptable and resilient to changing business needs.

Customization

B2B clients often have specific, varied and bespoke requirements that demand high levels of customization in the SaaS solutions they use. The challenge developers face is to design a platform flexible enough to allow significant customization in terms of features, workflows, and user interfaces, while still maintaining the core integrity and upgradability of the software. This requires the modular design approach as mentioned, where components can be tailored or extended without affecting the overall system. But beyond such technical considerations, and given the consequential nature of handling business data, a degree of open-mindedness and the ability to listen to, learn from, and respond to client needs on an ongoing basis cannot be overlooked.

Trends shaping the future of B2B SaaS

B2B SaaS companies are at the forefront of digital innovation, redefining how businesses operate. The integration of AI and machine learning and the rise of microservices and serverless computing are pivotal trends shaping the future of B2B SaaS platforms.

AI and machine learning

AI and Machine Learning are revolutionizing the way developers create and build B2B SaaS products by automating repetitive tasks, enhancing code quality, and providing insightful analytics. These technologies enable predictive modeling to foresee user behavior and system performance, allowing for proactive adjustments and feature enhancements. AI-driven tools can also assist in debugging and testing, identifying potential issues more efficiently than traditional methods.

Furthermore, machine learning algorithms can analyze vast amounts of data to uncover patterns and insights, informing more data-driven decision-making in product development. This not only accelerates the development process but also leads to more intelligent, adaptive, and user-centric B2B SaaS solutions.

Microservices and serverless computing

Microservices and serverless computing are revolutionizing the way B2B SaaS applications are developed and deployed. By breaking down applications into smaller, independently deployable services, B2B SaaS companies can achieve incredible flexibility and efficiency. This architectural shift allows for quicker updates, better scalability, and more cost-effective solutions since resources are consumed only when the services are in use.

For small businesses and startups, this means accessing powerful software solutions without the burden of significant upfront costs. This approach aligns perfectly with the needs of online stores and other digital businesses that require the ability to scale rapidly in response to fluctuating demand. The adoption of these architectures signifies a move away from traditional monolithic structures towards a more dynamic, modular approach in building SaaS platforms.

The future of B2B SaaS authentication



Building scalable, secure, and user-centric platforms is critical to meet the evolving needs of businesses, as is creating effective digital and cloud-based inbound marketing strategies that fuel demand. By leveraging AI, machine learning, microservices, and serverless computing, B2B SaaS companies are raising the bar for what’s possible with agile software environments.

Stytch offers a comprehensive, future-ready suite of features tailored to optimizing the B2B SaaS authentication experience – a crucial component to a stable, productive SaaS ecosystem – including:

Robust multi-tenancy: Stytch streamlines the management of diverse organizational structures, from sprawling enterprises to compact teams, by offering a comprehensive set of auth controls and settings that ensure flexibility across the board.

Authorization: With an advanced RBAC system, Stytch centralizes user identities, providing granular control over access and enhancing security within multi-tenant environments.

Effortless integration and onboarding: Stytch’s platform makes integrating with existing identity providers seamless and supports JIT provisioning, simplifying the onboarding process and enhancing user experience.

Enhanced user experience : The Discovery feature improves user navigation across memberships, while supporting a variety of onboarding processes, from manual to self-service, catering to different enterprise needs.

Diverse and secure authentication options: Offering multiple authentication methods like Email Magic Links, SSO, and OTP, along with Multi-Factor Authentication, Stytch ensures a balance between security and user convenience.

Unparalleled developer experience: Stytch offers a full-stack suite of developer tools, API and SDKs, that can be integrated with any stack or architecture.

Through working with Stytch, businesses can significantly improve their authentication processes, leading to a more securely connected, efficient, and harmonious SaaS environment that fuels an exceptional customer experience for their end users.

Interested in seeing how Stytch can accelerate your B2B product? Check out our docs and start building for free today. Or, to learn more about how these or other solutions work, reach out to an auth expert to start a conversation.







---


# Understanding JWKS: JSON Web Key Set Explained
Source: https://stytch.com/blog/understanding-jwks/

In this article, we explore the role of JWKSs in signing and managing JWTs for secure sessions and API communication.

When it comes to safeguarding sensitive resources such as APIs, M2M applications, and other software workloads, cryptographic keys are a more secure option than traditional cookies or API keys.

Unlike symmetric cryptography which employs a single secret key for both data encryption and decryption, public-key (asymmetric) cryptography leverages a pair of mathematically related keys that are generated by a specific cryptographic algorithm. These key pairs consist of a publicly accessible key and a corresponding private key, which remains strictly confidential.

As such, any authorization server can use private keys to sign tokens, but only the holder of the corresponding (paired) public key can verify the signature’s authenticity. The security of this asymmetric cryptographic system rests on the secrecy and protection of the private key, which must not be disclosed or leaked to any unauthorized parties.

More specifically, cryptographic keys are commonly used in modern applications to sign and verify the authenticity of identity and access tokens (JWTs) during the stateless authentication and authorization of human users or machines.

JSON Web Tokens (JWTs) are access tokens used to identify authenticated users and determine their appropriate level of privileges or permissions. However, to validate the integrity of a JWT and the encoded data, we have to leverage a pair of public and private cryptographic keys. This is where JSON Web Key Set (JWKS) comes into play.

As defined by the IETF RFC7517 standard, JSON Web Key (JWK) is a JSON data structure that provides the standardized format for representing public and private cryptographic keys. JSON Web Key Set (JWKS), on the other hand, serves as a secure repository or vault that stores the collection of public keys necessary for verifying and decoding specific JWTs.

In this article, we’ll explore the role of JSON Web Key Sets (JWKSs) in signing and managing JWTs for secure sessions and API communication. We’ll clarify the distinction between JWK and JWKS, unpack the JWKS data structure, and illustrate their practical application using real-world examples.

JWK vs JWKS

Imagine a secure building that has multiple doors, each protected by a lock that requires a unique key to open. In this analogy, each JWK would represent the specific key for a particular door/lock, while the JWKS is analogous to the keyring that holds all the keys used in the building.

Just as you wouldn’t hand over the entire keyring to every visitor, JWKS ensures that only authorized clients access the specific JWK necessary for their designated operations within a system.

A JWK is a JSON object representing a single cryptographic key. It holds vital identification data, such as the key type, key identifier, the cryptographic algorithm used to sign it, usage restrictions, and other additional details for verifying a JWT signature and decoding it to plaintext. Think of a JWK as the individual key in our building example, but only the public key value is accessible within the JWK, ensuring that the private key stays confidential and secure.

A JWKS is also a JSON object notation, but it contains an array or collection of individual JWK objects. Put simply, JWKS is a set of public keys that can be used to verify the JWTs issued by a specific authorization server.

Think of JWKS as the keyring that holds all the public keys used within a system. It allows clients to retrieve the necessary keys for validating JWTs depending on their specific function or business domain.

Structure of a JWKS

The structure of a JWK is defined by a set of key-value pairs, where each pair plays a specific role in representing the cryptographic key. Each JWK, whether it’s an individual key or part of a JSON Web Key Set (JWKS), contains various properties depending on the cryptographic algorithm that has been used to sign the key.

Some common characteristics of a JSON Web Key (JWK) include:

Key type (“kty”): This attribute specifies the particular family of cryptographic algorithms used to sign the key. Popular values include “RSA” for RSA keys, “EC” for Elliptic Curve keys, or HMAC.

Signature algorithm (“alg”): This identifies the particular algorithm that has been used to sign the key. For example, RS256, ES256, PS256, etc.

Key operations (“key_ops”): This attribute defines the operations that a key is allowed to perform. It’s an array of strings specifying which cryptographic operations the key is intended to be used for.

Key identifier (“kid”): This is the unique identifier for a key. It aids in key matching and retrieval within a JWKS.

Key use (“use”): The “use” property indicates the intended use or purpose of the key, whether it’s for signing (“sig”), wrapping other keys (“wrap”), or encryption (“enc”).

X.509 certificate chain (“X5C”): This optional attribute specifies the chain of PKI certificates used to sign the JWT. The x5c and x5t parameters are especially relevant in scenarios where public key infrastructure (PKI) is employed for secure communication, and they help convey information about the X.509 certificate associated with a key.

X.509 certificate thumbprint (“X5t”): This optional property contains the SHA-1 thumbprint of the X.509 certificate used to sign the token. The thumbprint is a unique identifier calculated from the certificate’s data.

Additional properties: Depending on the key type (“kty”) and signature algorithm (“alg”), additional properties can be found in a JWK. For instance, an RSA key-type JWK would have “n” (public key modulus) and “e” (exponent) parameters, while EC keys typically contain the “crv” (curve type) property and “x” and “y” coordinates.

Structure of a JWK signed using an RSA algorithm



Structure of a JWK signed using an EC algorithm



What is a JWK endpoint?

A JWKS endpoint is a designated HTTPS endpoint typically exposed at a well-known location on the authorization server (or any server managing the cryptographic keys), such as “https://<server_domain>/.well-known/jwks.json”.

This endpoint is a read-only URL that responds to GET requests by returning JWKSs as JSON objects. The primary purpose of a JWKS endpoint is to provide applications with the public keys necessary to verify the signatures of JWTs issued by an authorization server.

Identity providers like Stytch typically offer JWKS endpoints that allow your servers to retrieve JWKSs which can be used to verify the authenticity of JWTs issued by our authorization server at any time.



Cryptographic signature algorithms

Signing algorithms are integral to safeguarding the authenticity and integrity of JWKs. They generate digital signatures that verify the sender’s identity and ensure the exchanged data remains unaltered during transmission.

Common signature algorithms:

RS256: This is the most widely used signature algorithm when it comes to signing JWTs. It relies on the RSA public-key cryptosystem, where a pair of public and private keys is used for encryption and decryption.

RS384 and RS512: These are variations of RS256 that employ stronger SHA hashes, specifically SHA-384 and SHA-512, respectively. However, increasing the hash length comes at the cost of higher computational overhead.

PS256: PS256, or RSA signature with SHA-256 and MGF1 padding, is another RSA-based algorithm that combines RSA with SHA-256 hashing. Security-wise, PS256 is generally less recommended than RS256 due to potential vulnerabilities associated with this padding mechanism.

HS256: This is a symmetric signature algorithm that combines HMAC with the SHA-256 hash function. Unlike asymmetric algorithms like RS256, HS256 uses a single shared secret key for both signing and verifying signatures.

ES256, ES384, ES512: These algorithms utilize the elliptic curve digital signature algorithm (ECDSA) with different curve sizes (P-256, P-384, P-521) respectively. ECDSA offers several advantages over RSA, including smaller key sizes, faster signing and verification operations, and comparable security levels.

When selecting a signature algorithm, factors such as security requirements, computational efficiency, compatibility with existing systems, and the size of the keys need to be considered. Each algorithm has its strengths and weaknesses, and your choice should be based on the unique needs and constraints of your architecture.

Example applications of JWKS

Authentication and social logins

When a user attempts to log into an application using a social login, the application must request authentication of the user’s identity from the specific social media platform, whether it’s Facebook, GitHub, Google, etc.

The social media platform responds to the application by sending a login token that has been encrypted with its private key. Upon receiving the login token, the app has to verify its authenticity using a public key obtained from the social media platform’s JWK endpoint. If the decryption is successful, it confirms that the token was indeed encrypted by the social media platform’s private key, ensuring the user’s authenticity.

The private key is securely stored on the social media platform’s servers, while the public key is shared openly for verifying information encrypted by the private key. This setup prevents imposters from creating valid login tokens, as they lack access to the social media platform’s private key, making it exceedingly difficult to produce a token that can be successfully verified with the public key.

Securing backend communication

Whenever you use your favorite app, it communicates with various servers and services behind the scenes. Mobile and web apps constantly talk to their backend servers, and JWKS ensures communication stays private.

The backend server, which houses sensitive data and user information, employs a pair of cryptographic keys: a private key and a corresponding public key. The private key is securely retained within the backend server, while the public key is designated for sharing.

JWKS acts as a secret tunnel, allowing the backend to securely share its public key with the frontend. This verifies that only authorized requests get through, protecting the app’s data and user information from unauthorized access. JWKS can also be used to secure communication in both internal and open APIs, and even a microservices architecture.

Aside: with a powerful suite of API primitives for authentication, Stytch enables developers to use JWTs and JWKS seamlessly to build their login flows, manage their user sessions, and authenticate M2M clients. Learn more.

Why JWKS?

Key rotation and revocation

Using JWKS eliminates the need to manually update keys across all connected clients or systems. When a key needs to be rotated, the authorization server updates the new key to the JWKS endpoint and marks the old one as inactive. In this way, resource servers can automatically retrieve the new public key when next they need to verify a token.

On the other hand, rotating keys at specific intervals help to reduce an application’s attack surface area in the event of a leakage. If one key is compromised, the attacker’s access is limited to the set time-to-live period, thereby minimizing the impact of the breach.

Scalable key management

As your application scales, JWKS can seamlessly accommodate the growing number of keys and clients, eliminating the need for significant infrastructure changes. JWKS simplifies key administration by allowing you to store multiple public keys for various purposes in a centralized location.

Going back to our keyring analogy, each JWK can serve a specific purpose, just like the different keys on a physical keyring. Whenever a server needs to verify a JWT, it can retrieve the appropriate public key from the JWKS endpoint based on the intended use. This eliminates the need for maintaining separate key management systems, reducing complexity and improving security.

Managing JWKS via Stytch

Within Stytch, all JWTs, whether they are session JWTs or machine-to-machine (M2M) JWTs, are signed with a specific JWKS associated with your Stytch project. These signatures are available at a project-specific URL and can be validated locally using any Stytch client library or with any library that supports JWT signature validation.



If you’re using your own JWT validation library, many have built-in support for JWKS rotation. In such cases, you’ll need to supply our Get JWKS endpoint from which the library can fetch the updated JWKS.

To get started, check out our documentation and sign up for a developer account. If you have any questions, please don’t hesitate to contact us at support@stytch.com.









---


# Managing user sessions: localStorage vs sessionStorage vs cookies
Source: https://stytch.com/blog/localstorage-vs-sessionstorage-vs-cookies/

In this article, we explore the differences, benefits, and drawbacks of using web storage and cookies to store auth data like sessions and tokens.

To deliver consistent and frictionless user experiences on the browser, web applications leverage several storage options to persist user preferences and authentication data across multiple sessions.

While HTTPS adds a layer of encryption to the communication between your browser and web servers, it doesn’t inherently maintain state. This means that each HTTP request is handled independently, and the server doesn’t track or store data from previous interactions with your browser.

This statelessness is important for scalability and performance reasons, as it allows the protocol to handle large numbers of concurrent requests without the burden of retaining information about each request or user. However, from a UX perspective, it presents a challenge, as users would have to re-enter their credentials and preferences every time they visit a site.

To overcome this limitation, web developers rely on sessions or tokens to retain auth information across multiple requests and sessions. Both session IDs and access and/or refresh tokens can potentially be stored as a cookie or in web storage. The major difference lies in the level of security and storage space they offer, depending on your use case.

These session identifiers and tokens (either JWT or opaque) are typically generated by the backend and issued to the frontend where they are stored for the duration of the user’s login session. As such, if these tokens are compromised, an attacker could gain unauthorized access to the breached account and its associated privileges or data.

In this article, we explore the differences, benefits, and drawbacks of using web storage and cookies to store auth data like sessions and tokens. We cover best practices and security considerations for handling user sessions on the client side, with particular emphasis on end-user experience.

Handling authentication data on the browser

So far, we’ve established sessions and tokens as the most popular means of persisting authentication data on the browser.

In the case of sessions, whenever a user logs in to a website using their credentials, the server generates a unique session ID. This ID is stored in the server’s database and a copy is sent back to the user’s browser for storage. With each subsequent request, the browser includes the stored session ID, enabling the server to identify the user and access their associated session data. By using session IDs, a server can determine the state of a user, such as whether they are logged in or out, and maintain a stateful connection between the client and server.

While session IDs are a popular way of managing authentication state on the web, they do come with several drawbacks. One significant concern is their vulnerability to cross-site request forgery (CSRF). In a CSRF attack, an attacker can trick a logged-in user into performing unintended actions on a website by manipulating their browser to send requests with valid session IDs.

Another disadvantage of session IDs is the need to store them in a database or retain them in memory on the server. This can create a significant bottleneck in production environments due to the high volume of browser-server requests required to deliver a consistent user experience across sessions.

This is why many web applications now leverage token-based authentication as an augment or alternative to session IDs. These tokens are cryptographically signed and contain information about a user and their permissions. The server generates these tokens using a private key and sends them to the client for storage in the browser.

During subsequent requests, the client only needs to include the access token in the authorization header, prefixed with the bearer, and the server can validate the signature of the token without needing to perform a database lookup.

It’s very common for microservices architectures to leverage JWTs over traditional session identifiers because each microservice can independently verify JWTs without relying on a central database or authorization logic.

Session management using local storage

Local storage is a type of browser storage that enables web applications to store and retrieve data in key-value pairs within a user’s browser. It can be accessed via the Web Storage API using the global localStorage object in Javascript.



Most modern web browsers provide a local storage capacity of around 5–10MB per domain or origin accessed by the user. This dedicated storage space can be utilized to store user-specific data, such as preferences, temporary files, or even settings.

One key advantage of local storage is that data is persistent across browser tabs and sessions. This eliminates the need for constant communication with the server to retrieve the same data, resulting in reduced network latency and faster page load times.

Additionally, data stored in local storage remains accessible even when the user is offline or has a poor internet connection. This enables web applications to provide limited yet valuable functionality in offline mode, enhancing the user’s experience and ensuring uninterrupted usage.

In this way, storing authentication data in local storage might appear to be a logical option for newbie web developers. However, this practice will expose your application to potential XSS attacks.

In cross-site scripting (XSS) attacks, hackers inject malicious code, typically Javascript, into an app or website. The attacker’s goal is to trick users into executing this harmful code when they load the malicious content in their browser. If an attacker successfully runs this malicious script within your application, they could steal your tokens from local storage and initiate authentication requests directly.

A successful XSS attack can give the attacker access to a user’s authentication token or credentials, allowing them to hijack the user’s account, remotely control their browser, or spread malware on the host system. To mitigate the risk of XSS attacks, it’s not advisable to store plain authorization tokens in local storage.

Storing authentication data in session storage

Session storage is another storage mechanism provided by the Web Storage API. Unlike local storage, session storage is tied to a specific browser session and is deleted once the session ends. This makes it ideal for storing temporary data that needs to be accessible within a single session but doesn’t need to persist across multiple sessions or browser restarts.

In terms of security, session storage is commonly deemed more secure than local storage because it automatically deletes data when the browser or tab is closed. However, similar to local storage, session storage is susceptible to XSS attacks. Attackers can steal your tokens from the storage and use them to impersonate users. As such, it’s also not advisable to store session tokens and other sensitive data in session storage.

Aside: using Stytch’s JSON Web Tokens (JWTs), developers can locally verify user sessions without having to contact Stytch’s servers on every request. You can set custom expiration times, revoke tokens as needed, and implement additional security measures to protect user accounts, both manually and programmatically. Explore our docs to learn more.

Using cookies to manage user sessions

Cookies are tiny pieces of data that are sent from a server to a user’s browser, where they are stored in a text file. Each time the browser requests content from the server, the cookie is usually transmitted, allowing the server to recognize the user and tailor their experience.



Cookies are relatively lightweight (4 KB per domain), making them ideal for storing short-lived data such as session IDs, JWTs, and other sensitive information that needs to be temporarily accessed by the web server. 

The lifespan of a cookie is determined by its time-to-live (TTL) or expiration time, which essentially dictates the duration of an active session. When a cookie expires, the associated session information in the database becomes outdated, prompting the user to re-authenticate to establish a new session.

By default, browsers automatically transmit all cookies, including authentication cookies, whenever they make requests to any website. This behavior can be exploited by malicious websites disguised as legitimate sites, leading to cross-site request forgery (CSRF) attacks.

This means that if a user is logged into a legitimate website (such as an online banking platform) and then visits a malicious website that is disguised as legitimate, the malicious website can exploit the browser’s default behavior. The malicious website can create a request that appears to come from the user, and this request can trigger an action on the legitimate website that the user is already logged in to.

Nonetheless, cookies possess attributes that can mitigate this risk and improve their overall security. One example is the SameSite attribute, which reduces the risk of cross-site request forgery (CSRF) attacks. When the SameSite attribute is set to “Strict,” the browser includes the cookie only in requests that originate from and target the same site as the cookie’s origin.

Another security feature is the HTTP-only flag. When enabled, modern browsers prevent JavaScript and other malicious CDN scripts from accessing the cookie’s value, thereby mitigating data leakage through cross-site scripting (XSS) attacks. On the other hand, the Secure attribute ensures that cookies are only transmitted over HTTPS connections, safeguarding against cookie leakage through man-in-the-middle attacks and session hijacking.

Handling sessions and JWTs: local storage vs session storage vs cookie?

Choosing the right storage option for your web application depends on your unique security requirements and constraints. For instance, cookies are best suited for storing data that needs to be readable by the server, making them ideal for handling sessions and tokens. Session storage is designed for storing data within a single session, making it suitable for temporary and tab-specific data. localStorage is the recommended choice for data that needs to be retained across multiple sessions, as it provides persistent data storage.

When it comes to handling JWTs, most modern applications store their access tokens in memory, rather than local storage or cookies. This is because storing the access token in memory makes it inherently inaccessible to JavaScript and potential attackers. However, storing tokens in memory does come with some drawbacks—if a user refreshes their page or closes the tab, any stored data will be lost.

To address this issue, many modern applications leverage refresh tokens. By performing a silent or background refresh just before the access token expires, applications can seamlessly keep users logged in without any noticeable disruptions.



Refresh tokens are typically stored in cookies, allowing users to obtain new access tokens when the old ones expire. However, to ensure security, the server issuing tokens must have appropriate cross-origin resource sharing (CORS) configuration to restrict refresh token requests only from authorized origins. Additionally, cookies used for storing refresh tokens should have the httpOnly, Secure, and SameSite attributes to protect against theft.

The thing is, always avoid storing your access or refresh tokens in non-memory or non-cookie locations. When configured appropriately, browsers effectively prevent the leakage of both tokens via cookies.

Session management via Stytch

On Stytch, user sessions are identified using either a session token (session_token) or session JWT (session_jwt). These are typically stored on the client-side, often within a browser cookie, and are used for authentication on each request.

The session token is a unique 44-character string and the session JWT is a string that follows standard JWT protocols. Both are returned on every API response and can be used interchangeably. The session JWT is a signed snapshot of a session at the time it was issued and is valid even after the session is revoked in the Stytch API.



With Stytch, developers can create and manage custom claims within their JWTs, providing a flexible and secure way to store additional user-specific information.

Stytch signs all JWTs with project-specific signing keys. The verification keys for those signatures are available at a project-specific URL, which is publicly accessible. This allows other JWT consumers outside of your app to verify JWTs from your project.

To get started, check out our documentation and sign up for a developer account. If you have any questions, please don’t hesitate to contact us at support@stytch.com.









---


# Unpacking MACH architecture: The future of SaaS development
Source: https://stytch.com/blog/mach-architecture/

Learn about the components of MACH architecture—Microservices, API-first, Cloud-native, Headless—and their impact on SaaS applications. Read how to create agile, scalable, and composable software environments fit for the digital age. Discover the challenges and strategic approaches to MACH adoption, and see how Stytch's authentication platform exemplifies MACH's innovative ethos.

It goes without saying that successful modern software development necessitates an easily adaptable approach to changing business needs and customer expectations.

Enter MACH architecture, a set of principles advocated by the MACH alliance that is reshaping how developers build, deploy, and manage applications. This article explains the MACH architecture, breaking down its components – Microservices, API-first, Cloud-native, and Headless – while exploring its benefits, challenges, and the best practices in applying MACH principles to SaaS applications.

The essence of MACH architecture

Founded in 2020, the MACH Alliance is a collective of tech companies advocating for MACH architecture development and MACH principles in digital solutions, and includes notable members like Adobe, AWS, Google Cloud, and Contentstack. Together, the alliance sets standards and shares best practices towards creating interoperability and open technology frameworks that are the backbone of MACH architecture.

Modularity, agility, scalability

MACH architecture is increasingly recognized as a transformative framework that offers a modular, agile, and scalable foundation for crafting software applications. The framework aims to develop adaptable, forward-thinking systems capable of navigating the ever-evolving demands of today’s businesses and consumers. To evaluate MACH architecture as successful, it must facilitate rapid innovation and continuous development so that businesses can seamlessly integrate new technologies and trends to stay competitive.

The essence of MACH architecture lies in its ability to foster a composable development environment, where businesses can easily assemble, tweak, and reassemble various services to create tailored digital experiences that are by and large the expectations of today.

Microservices: Building blocks of agility

At the heart of MACH architecture is the microservices architecture, which advocates for deconstructing the software architecture into small, independently developed services, each dedicated to a specific business functionality. This approach aligns perfectly with the principles of agile development, as it allows individual teams to focus on their areas of expertise, deploying updates and new features without impacting the broader application. By compartmentalizing the various components of an application, businesses can ensure that a failure in one area doesn’t lead to a cascading effect across the entire system. This resilience is particularly important in commerce service platforms, where uptime and performance directly impact customer satisfaction and revenue.

A microservices-based structure is crucial for achieving continuous delivery and scalability, hallmark features of MACH architecture that make it an ideal choice for businesses looking to enhance their software development lifecycle.

API-first: The connectivity glue

The API-first approach, a core tenet of MACH architecture, prioritizes the development of APIs as the fundamental connectors between microservices and the external world. This strategy ensures seamless interaction among the disparate components of a software system, facilitating a cohesive and integrated architecture. In the context of composable development, an API-first methodology enables businesses to swiftly integrate various services, enhancing their ability to bolster their technical infrastructure and offer a rich and seamless customer experience across multiple touchpoints.

Adopting an API-first strategy also simplifies the integration of third-party services and solutions, a common practice in the MACH alliance, where interoperability and collaboration in the broader ecosystem are key. By designing robust and well-documented APIs from the outset, organizations can create a flexible and extensible software architecture that readily adapts to new business needs and opportunities.

Cloud-native: The scalable backbone

Cloud-native development in MACH architecture leverages the full potential of cloud infrastructure to build applications that are inherently scalable, resilient, and easy to manage. This focus on cloud-native apps equips organizations to utilize the cloud’s dynamic resources for optimal performance and cost-efficiency. The principles of cloud-native development, including microservices, containers, and continuous innovation/continuous deployment (CI/CD), are vital for businesses that demand agility and scalability in their digital services.

The cloud-native component of MACH architecture also improves application resilience. By distributing services across cloud environments, businesses can mitigate the impact of system failures for continuous operation and a consistent user experience.

Headless architecture: Freedom to innovate

The headless component of MACH architecture separates the backend logic and data management from the frontend presentation layer to increase flexibility for developers in how content and services are delivered to users. This separation allows developers to innovate on the front end without being constrained by backend complexities, so they can focus on creating bespoke user interfaces tailored to the unique needs of different channels and devices. Whether it’s a web application, mobile app, IoT device, or any other digital touchpoint, the headless approach in MACH architecture supports the development of consistently engaging digital experiences across all platforms.

Headless architecture in MACH technology not only facilitates a more agile and responsive design process but also allows organizations to future-proof their applications by making it easier to adopt new frontend technologies as they emerge. As customer expectations continue to rise, the flexibility and adaptability of the headless approach become increasingly valuable, supporting faster iteration and deployment of new user experiences.

Aside: Stytch’s easy-to-integrate APIs and headless SDKs allow you to build your authentication flows with the agility required to evolve in a MACH architecture environment. Together, these tools make it easier for software developers to innovate and position their products for success in today’s fluid digital environment. Learn more.

The complexities of adopting MACH architecture



While there are many benefits to MACH architecture in meeting the exceptionally high digital experience bar of today’s applications, implementation challenges remain in harnessing the architecture’s full potential. When adopting MACH technology principles, organizations should look at these initial hurdles as necessary strategic challenges paving the way to substantial long-term benefits.

Integration challenges

As discussed, adopting a MACH architecture means embracing a composable service architecture made up of independent components, each responsible for discrete business functionalities. While this modular approach offers enhanced flexibility and scalability, it also introduces complexity in integrating these disparate factors into a cohesive system that MACH technologies support.

The key challenge is ensuring seamless communication and interoperability between microservices, APIs, and headless systems, driven by a well-thought-out strategy for API management and service orchestration. To start, development teams must carefully evaluate MACH technologies to ensure they align with the organization’s technical capabilities and business objectives, ensuring a smooth transition and effective integration once they pull the trigger.

Managing a microservices-based architecture

The shift to a microservices-based architecture involves decomposing traditional monolithic systems into smaller, independently deployable services. This transition enables organizations to enhance agility and speed up time to market. However, it also introduces complexity in managing and orchestrating numerous services, demanding a significant shift in the operational and cultural mindset of development teams.

Adopting a strong DevOps culture and investing in automation for continuous integration and delivery are critical best practices to introduce microservices and mitigate these challenges using MACH architecture. They are not always intuitive and require significant internal resource investments – a barrier for some.

Finally, organizations must ensure their cloud-native infrastructure is robust enough to support the dynamic nature of microservices, facilitating the efficient deployment and scaling of MACH technologies and services.

UX challenges of headless applications

A seamless user experience in headless development requires meticulous planning and execution in designing APIs and selecting front-end technologies that can support diverse presentation requirements.

The detachment of the front-end from the back-end in headless environments, while beneficial for customization and agility, places a greater onus on developers to maintain consistency in user experience (UX). They are challenged with creating a cohesive UX that aligns with the brand across myriad devices and platforms, which requires adeptness in working with APIs and a deep understanding of the end user’s environment. Careful coordination between teams is critical, as even small discrepancies in front-end application behavior can lead to significant inconsistencies in UX.

Additionally, developers must stay abreast of advancements in front-end technologies to ensure that the experience is seamless, responsive, and engaging on all devices. Ensuring the flexibility of the UX without sacrificing performance requires meticulous design and ongoing testing to adapt to the varied ways consumers interact with digital platforms.

The big lift from legacy to composable

The transition to a MACH architecture often involves integrating or replacing legacy infrastructure, which can be a significant hurdle for many organizations. Legacy systems are typically tightly integrated and may not support the modular, API-first approach that MACH architecture advocates. This challenge necessitates a strategic approach to digital transformation, where legacy systems are incrementally refactored or replaced with MACH-compliant solutions. Ensuring a smooth transition requires careful planning and execution, with a focus on minimizing disruption to existing operations while laying the foundation for a future-proof, composable enterprise.

By addressing these challenges with strategic planning and best practices, organizations can successfully navigate the complexities of adopting MACH architecture, ultimately reaping the long-term benefits of enhanced flexibility, scalability, and market responsiveness.

The benefits of MACH-compliant authentication



Perhaps the last, yet equally important, piece of a perfectly defined MACH architecture is secure authentication. An auth platform built on MACH principles is essential in supporting the core tenets of modularity, agility, and scalability that comprise a best-in-class MACH architecture.

Stytch enables developers to implement secure, scalable, and customizable MACH-compliant SaaS authentication services that enhance the user experience and meet evolving business needs with a focus and competency in supporting each core component.

Microservices

Stytch allows for independent development and deployment of authentication features in a microservices environment, using a low-level composable API and a suite of auth primitives designed for maximum flexibility and code control. Such an environment helps your organization rapidly iterate on and deploy new features to meet the intense demands of modern software applications. A microservice architecture also allows for greater scalability and reliability by isolating failures and preventing downtime, creating a resilient and reliable authentication platform for developers and organizations.

API-first

Stytch’s modular API-first design allows developers to easily integrate authentication services into their applications. By following RESTful principles, Stytch’s APIs are intuitive, easy to use, and seamless to integrate. Stytch’s API exposes a comprehensive suite of resource-oriented endpoints that power your application’s identity management and authentication flows. This includes functionality and features like login and signup, invites, user management, session management, and more.

With Stytch, developers and organizations can enjoy the flexibility to choose how they want to implement and manage their authentication services.

Cloud-native

Stytch’s cloud-native architecture provides organizations with the flexibility, scalability, and cost-effectiveness needed to support modern application environments. By leveraging cloud services, Stytch can easily handle spikes in traffic and scale resources as needed, ensuring a seamless user experience and rapid business growth. This also allows for a pay-as-you-go model, reducing infrastructure costs and enabling organizations to only pay for the resources they use.

Headless

Stytch enables front-end and back-end developers to work more efficiently by separating user interfaces from back-end processes. To support headless development, applications can integrate with Stytch’s authentication services via front or backend SDKs without being tied to any specific frontend framework or platform. This results in a more streamlined development process, faster go-to-market, and the ability to design the frontend to meet specific user demands – all while maintaining high-security standards.

Through working with Stytch, businesses can significantly improve their authentication processes, leading to a more securely connected, efficient, and MACH-compliant SaaS environment that fuels an exceptional customer experience for their end users. Get started building today or reach out to an auth expert to learn more.







---


# Session management best practices
Source: https://stytch.com/blog/session-management-best-practices/

In this article, we explore how web developers can effectively create and manage user sessions on the client and server-side, as well as in typical monolithic and microservices environments, without compromising user experience and security.

Sessions are used to uniquely identify users, determine access privileges, and maintain their login state within an application. This relieves authenticated users from having to repeatedly enter their login credentials, ensuring a seamless and personalized user experience.

In monolithic applications, these user sessions are stored in server memory or a centralized session store/database. As such, whenever a user successfully authenticates their identity, the server generates a unique session on the server-side and sends the associated session ID to the client. This session ID must then be included in all subsequent client requests made to the server, allowing the server to associate each request with the corresponding user session.

However, in stateless microservices architectures, where multiple services are running concurrently on separate servers or containers, session management becomes more complicated than in simple monolithic web apps running on a single server.

This is why microservices leverage token-based authorization mechanisms like JSON Web Tokens (JWTs) to manage session data. These self-contained tokens can be used to manage user privileges and session information across multiple servers and services, without having to make frequent requests to a central server or session store.

In this article, we’ll explore how web developers can effectively create and manage user sessions on the client and server-side, as well as in typical monolithic and microservices environments, without compromising user experience, security, performance, and scalability of the system. We’ll cover five key session management best practices, and common session vulnerabilities, and show you how Stytch makes it easy for web developers to manage both traditional sessions and session JWTs.

Stateful (sessions-based) session management



In stateful (sessions-based) session management, the server maintains user information and state throughout multiple requests within a single session. As we mentioned before now, user data and session information are typically stored on the server, often in a database or memory. This unique session ID is exchanged between the client (browser) and the server with each request, either via cookies or by embedding it in the request URL (though the latter is considered less secure).

Throughout a user’s interaction with an application, session data remains on the server, persisting even if the user closes the browser and returns later, as long as the session is valid. However, once the session expires, the associated session information is invalidated by the server. Active sessions can be terminated due to user inactivity, security-related timeouts, or user actions, such as logging out.

Stateful session management is generally considered more secure against client-side attacks like cross-site scripting (XSS), since sensitive session information resides on the server, making it less susceptible to manipulation on the frontend. However, session data can also be stored on the client-side, typically using cookies.

Cookies are small text files sent by the server and stored in the user’s browser. They are then included in subsequent requests, allowing the server to identify the user and their session. However, cookies can also be vulnerable to attacks like session hijacking, XSS, and cross-site request forgery (CSRF) if not attributed properly or stored in insecure web storage locations.

Stateless (token-based) session management



In stateless (token-based) session management, the server doesn’t store session information between requests. Each client request is independent, containing all the necessary session and auth information, usually in a compact JSON Web Token (JWT).

For example, when a user logs into a web application that leverages tokens, the server authenticates their credentials and creates a signed JWT containing the user’s session information, known as claims. This signed JWT (also referred to as access token) is then sent back to the user’s browser, where it’s usually stored in a secure cookie for subsequent client requests.

However, there are more secure ways to handle JWTs. A safer method is to store access tokens in memory rather than in local storage or cookies, but this comes with a caveat. If a user refreshes the page or closes the browser tab/window, all data stored in memory, including the access token, will be erased.

This is why web applications use a combination of access tokens and refresh tokens. To maintain seamless user experiences without compromising security, refresh tokens are securely stored in client-side cookies, while access tokens are retained on the server. Before an access token expires, the refresh token is used to silently refresh it, preventing any noticeable disruptions to the user.

Managing sessions in monoliths vs microservices

In monoliths, session data is typically stored in a centralized session store, such as a database or an in-memory cache, which is accessible by all components of the application. However, in a microservice architecture, each service is designed to be independent and self-contained, making it challenging to share session data across multiple services.

In a monolithic app, authentication and authorization are handled by a single module or middleware, which can grant or deny access to various parts of the application based on the user’s session data. However, in a microservice architecture, where each service is running on separate servers or containers and may have its own auth framework, this approach isn’t practical, as services can’t communicate or exchange data locally.

To address this challenge, microservices architectures often rely heavily on token-based authentication mechanisms, such as JSON Web Tokens (JWTs). JWTs are self-contained tokens that can encapsulate the necessary user information and can be propagated across multiple services, eliminating the need for back-and-forth requests to a centralized session store.

Nonetheless, managing token lifecycles, including issuance, revocation, and ensuring consistent validation across all services can be complex. This often requires a central authorization server that can be shared by multiple services or instances.

While there are some drawbacks to this kind of centralized authorization, such as the increased complexity and risk of a single point of failure, the performance and scalability benefits often outweigh these risks.

Many microservices architectures use a sidecar decoupling pattern in which supporting functions of the main service, such as session management and auth, are provided by sidecars attached to this main service.

Auth sidecars are co-located with their associated microservice, sharing the same server, pod, or container. This ensures that any failures or restarts are isolated to that service. This approach shifts authorization responsibilities from the main service to the auth sidecars, which communicate directly with the centralized auth service.

Aside: on Stytch, session tokens and session JWTs are completely interoperable, and both are returned on every API response so that developers can use whichever option is best for their application. Explore our docs to learn more.

Common session vulnerabilities

Session hijacking

An attacker can unlawfully gain control over a legitimate user’s active session by stealing their session identifier or token after the user has successfully logged in.

In situations where the attacker and the victim share the same network, such as a public Wi-Fi connection, the attacker can eavesdrop on unencrypted network traffic. This makes it possible for the attacker to intercept communication between the victim’s device (client) and the targeted server, potentially compromising the integrity and confidentiality of the session ID or token. Armed with this stolen token, the attacker can then impersonate the legitimate user and perform actions on their behalf, effectively hijacking their session.

Furthermore, storing session IDs or tokens in local storage or insecure cookies on the client-side can also make applications vulnerable to attackers. In such a scenario, a cross-site scripting (XSS) attack can introduce malicious code that extracts the user’s session information from the frontend and transmits it to the attacker.

To prevent session hijacking, always employ secure communication protocols like HTTPS and TLS/SSL to encrypt data transmission between clients and servers. Furthermore, to mitigate XSS attacks, always implement secure cookie flags, enforce automated session timeouts and expiration, and mandate user re-authentication when users perform sensitive actions within the app.

Session fixation

Session fixation vulnerabilities occur when web applications fail to properly generate or validate session IDs before authorizing access. Attackers can exploit these vulnerabilities by tricking the victim into adopting a predetermined identifier, often through phishing or malicious links. Once a user interacts with a link or email containing this attacker-determined session ID, the attacker can impersonate the user, control their account, perform actions on their behalf, or gain access to sensitive information.

To protect against session fixation, web applications leverage strong cryptographic algorithms and entropy sources to generate random and unpredictable session IDs. This significantly reduces the chances of an attacker successfully guessing or predicting a valid session ID, even if they have access to an old one.

The most secure web applications always enforce strict server-side validation for each request. This ensures that session IDs are legitimate and linked to the correct user before granting access. Furthermore, implementing short session durations that automatically expire when the user is inactive effectively minimizes potential vulnerabilities and exposure, even in the event of a session compromise.

Man-in-the-Middle attacks

In man-in-the-middle attacks, attackers use an intermediate server to sniff and intercept HTTP requests between a user’s device (client) and a web server. This allows attackers to potentially steal sensitive data like passwords, credit card information, or even session IDs.

To ensure secure data transmission and prevent MitM attacks, it’s important to use HTTPS connections for the entire web session. HTTPS encrypts all communication between a user’s device and the server, making it unreadable to attackers, even if they intercept it.

Cross-site request forgery (CSRF)

Cross-site request forgery (CSRF) exploits a user’s existing login session to trick their browser into performing unauthorized actions. Unlike session hijacking, CSRF attackers don’t steal session IDs or tokens. Instead, they create malicious links, forms, or scripts that a user may interact with on a seemingly legitimate website. The browser unknowingly leverages the user’s active session to run these malicious scripts and execute the attacker’s commands, which could include stealing funds, changing account settings, or even sending emails, all without the user’s knowledge or consent.

Nonetheless, web applications can implement several security measures to protect against CSRF attacks. One approach is to use anti-CSRF tokens. These are unique, unpredictable values that are embedded within forms and validated on the server-side. This ensures that the submitted form originates from a legitimate user and not an attacker.

Additionally, when using cookies, setting the SameSite attribute as either ‘Strict’ or ‘Lax’ can further mitigate CSRF risks by restricting the context in which cookies are sent during cross-origin requests. This makes it harder for attackers to intercept the user’s cookies (which might contain a session ID) to perform unauthorized actions on the targeted website.

5 session management best practices



Exclusively store authorization data on the server-side

Never store sensitive authorization data, such as session IDs, tokens (JWTs), user credentials, or roles and permissions, on the client-side (e.g., in browser storage or insecure cookies). This information should always be stored and managed on the server-side, where it can be properly secured and protected from potential client-side vulnerabilities and unauthorized access.

Implement secure cookie flags and attributes

When using cookies for session management, it’s important to set the appropriate flags and attributes to enhance their security. The following are some of the most important flags and attributes to consider:

HttpOnly: This flag instructs the browser to prevent client-side scripts, including malicious scripts from accessing the cookie. This can help protect against cross-site scripting (XSS) attacks.

Secure: This flag ensures that the cookie is only transmitted over secure (HTTPS) connections. This helps to protect against eavesdropping and man-in-the-middle attacks, that could potentially capture session IDs from insecure browser traffic.

SameSite: This attribute restricts cross-site cookie sharing, thereby mitigating the risk of CSRF attacks. To prevent unauthorized cross-site requests from accessing or modifying session cookies, you can set the SameSite cookie attribute to “Strict” or “Lax” based on your application’s requirements.

Expires/Max-Age: These attributes define the lifespan of a cookie. When set, the cookie will remain persistently stored on the browser until the specified expiration time or max age.

Domain: This attribute instructs the browser to only send the cookie to a specific domain and its subdomains. It prevents cookies from being sent to unintended destinations.

Path: This attribute instructs the browser to only send the cookie to a specific directory or subdirectory within a domain.

Avoid predictable session IDs

To mitigate the risk of unauthorized access and brute-force attacks, it’s important to use cryptographically secure random number generators (CSRNGs) or strong cryptographic algorithms with sufficient entropy to generate highly secure session IDs. These algorithms are designed to produce truly random and unpredictable output, reducing the likelihood of collisions or patterns that could be exploited by attackers.

Always generate session IDs with a length of at least 128 bits (or 32 characters for Base64-encoded IDs). Using longer session IDs significantly increases the complexity and computational effort required for brute-force attacks, making them practically infeasible for attackers to guess or deduce. Avoid using predictable patterns or sequential numbering to generate session IDs, as these weaknesses can be easily exploited by attackers.

Implement manual session expiration (logout functionality)

Always provide users with a clear and accessible way to manually terminate their sessions, such as a “Logout” button or link in a prominent location on the user interface. This ensures that users can securely end their sessions when they are finished, preventing unauthorized access to their accounts or data.

Upon logging out, the application must invalidate the user’s session, clear any session-related data stored on the server or client-side, and redirect the user to a secure location, such as the login page or a dedicated logged-out page.

Enforce automatic session expiration and timeouts

To protect user accounts and data from unauthorized access, it’s important to implement automatic session expiration and timeouts.

In addition to manual session expiration, setting reasonable session timeouts based on the sensitivity of the application and the expected usage patterns can help mitigate the risk of session hijacking. After a predetermined period of inactivity, the application should automatically invalidate the current session and prompt the user to re-authenticate, thereby preventing the extended and/or expired session from being exploited.

How session management works on Stytch

On Stytch, user sessions are identified by session tokens and JSON Web Tokens (JWTs) that are authenticated on each request. To initiate a session, developers can call the authenticate magic link or authenticate OTP endpoint, specifying the desired session_duration_minutes to set the session’s lifespan.

Stytch returns both a session_token, which is a static value that remains valid for the duration of a session, and a session_jwt that has a shorter expiration time of 5 minutes. However, when JWTs expire, you can pass them to our session API to retrieve newer JWTs. Our servers ensure that the underlying session is still active before issuing a new JWT.



To extend a session’s validity, you can call the authenticate session endpoint with the desired session_duration_minutes parameter to set a new expiration time without modifying the session_token or session_jwt. On the other hand, you can also revoke an active session by passing the corresponding session ID or JWT to the revoke session endpoint.

To get started, check out our documentation and sign up for a developer account. If you have any questions, please don’t hesitate to contact us at support@stytch.com.







---


# Account Abuse Prevention in 2024
Source: https://stytch.com/blog/account-abuse-prevention-in-2024/

Multi-account abuse is a form of account abuse where attackers create multiple new accounts for free to exploit resources that are available to logged in users.

In 2024, free pricing tiers and trials are a common part of the app onboarding experience for new users, whether it’s a B2B SaaS app or the latest consumer app. This move is designed to cater to the fleeting intent of potential customers, eliminating the friction of traditional sales conversations and thereby reducing the likelihood of early-stage evaluation drop-offs.

However, this open-door policy for account creation, while enhancing customer experiences and potentially boosting paid conversions, inadvertently opens up a Pandora’s box of abuse vectors. Among these associated risks, multi-account abuse stands out as a significant threat.

Multi-account abuse, the basics

Multi-account abuse is a form of account abuse where attackers create multiple new accounts for free to exploit resources that are available to logged in users. Companies may offer this as:

Free self-service subscription tier

Free time-based (eg. 30-day) trial

Free credits for new accounts

Promotional offers

While intended as a commercial incentive for real customers, these can open access to bad actors and fraudulent users, providing access to valuable and otherwise costly resources; including traditional and AI compute capabilities, particularly if these are client-side accessible.



Multi-account abuse

While fake accounts are often associated with consumer-based threats such as credit card fraud and posting spam or malicious content, multi-account abuse can be far more costly for companies. Some examples include:

Cryptomining

In the realm of B2B products aimed at developers or data engineers that offer compute access, attackers often exploit these resources for unauthorized purposes by attempting to proxy cryptomining activities through freely available accounts in order to monetize the compute that the unsuspecting application is paying for.

AI Compute Abuse

The issue of AI compute abuse has become increasingly prominent, driven by the surge in companies integrating interactive AI features into their platforms over the recent period. Similar to regular compute, AI compute is costly and, when exposed in a fungible manner, allows attackers to access the compute without having to foot the bill themselves.

Consider a tool like GPT4Free, which is an open-source project that makes it easy for fraudsters to steal AI compute from apps that expose this client-side.



Impact of reverse engineering on AI API costs

Toll Fraud

Many applications offer access to infrastructure services like telephony that can be manipulated for profit and fraudulent transactions. In the case of toll fraud, bad actors abuse free accounts that expose SMS or voice dialing services to collude in profit sharing with a mobile network operator or carrier.

Drivers for free account abuse

This type of free account abuse, also known as multi-accounting, where multiple accounts are created on a platform or application with the intention of exploiting resources or services, is done for a variety of nefarious purposes.

Financial gain: Users may create many new accounts to take advantage of promotional offers, free trials, or credits, which can lead to significant financial losses for businesses.

Market manipulation: In e-commerce environments, multi-accounting can be used to manipulate product ratings, reviews, or prices, resulting in an unfair advantage for the abuser and damaging the integrity of the platform.

Manipulation of online contests, polls, or voting: Multi-accounting can be employed to skew the outcomes of online events, undermining the democratic process and eroding trust in the platform.

Fraudulent activities: In some cases, multi-accounting can be used for more serious criminal activities, such as money laundering, identity theft, or other forms of financial fraud.

Types of free account abuse

There are two primary categories of free account abuse that you need to be aware of:

Manual free account abuse: this does not involve bots and instead involves a human-in-the-loop to actually create the multiple free accounts

Automated free account abuse: this is where an attacker uses a script (e.g. python, node, or headless browser) to automate mass account creation to take advantage of your application’s resources. With generative AI, almost anyone can now build a script and get step-by-step instructions to automate this workflow.



Automated account creation script from ChatGPT

Conventional ways to defend against multiple account abuse

To effectively mitigate the risks associated with multi-account abuse and deter both automated and manual fraudulent account creation, it is imperative for application developers to implement robust security measures for fraud prevention.

Conventional account protection methods to combat free account abuse have been employed by developers for years, with varying degrees of success.

These methods include:

Rate limits: Implementing a limit on the number of account creations or actions per unit of time to prevent excessive sign-ups or activity. This is often used in conjunction with other traits (e.g. IP address, user agent, email domain, etc.).

IP tracking: Monitoring and tracking IP addresses to identify suspicious activity or multiple customer accounts originating from the same source.

User verification: Verifying identity through various methods, such as email, phone number, or social media account linking.

CAPTCHA: Implementing a challenge-response test to determine whether a user is human or a bot.

While the combination of these methods can be effective for new account abuse, in some cases, they are not foolproof and can be circumvented by sophisticated attackers. For example, anti-captcha.com and similar services exist that can solve CAPTCHA challenges automatically, rendering them ineffective. Additionally, attackers can rotate IP addresses to avoid detection, and they can create infinite permutations of email addresses or fake phone numbers for verification.



CAPTCHA types and prices

More powerful modern methods for account abuse prevention

Instead, product teams need to consider newer approaches to safeguard their platforms against the myriad of abuse vectors that threaten the integrity and reputation of their applications.

Stytch’s device fingerprinting product offers a more foolproof way to curb free account abuse by providing three powerful primitives to developers

1. A verdict object

A verdict object will frictionlessly detect and assess every piece of traffic on your site as a true human (an ALLOW verdict) or a bot/headless browser (a BLOCK verdict which comes with the detailed reasons for the block such as `HEADLESS_BROWSER_AUTOMATION`) .

Unlike products that provide a confusing risk score that requires endless trial and error, this makes it simple to detect and eliminate unwanted programmatic activity in your app.

2. Multi-vector fingerprinting and threat analysis

Stytch offers a unique and stable set of device, browser, hardware, and network fingerprints for identifying each user.

Particularly useful for preventing ban circumvention from malicious, manual abusers, these identifiers are derived from various attributes of the user’s physical device, browser software, and user characteristics. By aggregating these attributes into a single identifier, Stytch ensures that the identifier is unique to each device, offering enough entropy to prevent fraudulent actors from creating multiple accounts or exploiting resources.

3. Custom fingerprint rules

An ability to set custom rules on individual fingerprints, so that you can allow any wanted programmatic traffic (e.g. end-to-end tests) while setting explicit ban rules for any human abuse you’re seeing (e.g. permanently ban a specific browser_fingerprint or visitor_fingerprint).

A complete, API-first solution

Stytch Device Fingerprinting provides full API-based programmatic access for easily integrating fraud prevention into your application. Here’s an example JSON response from the API:



In addition to actively mitigating fraudulent activity, and full API access to customize and monitor activity, Stytch offers a Device Fingerprinting Dashboard with real-time and historical data of the fingerprints, verdicts, and verdict reasons your application experiences.



Device fingerprinting real-time monitoring

Innovations in device fingerprinting

Stytch’s approach to device fingerprinting is designed specifically to be tamper-resistant, making it difficult for attackers to reverse engineer or spoof the fingerprinting process. The product’s stability is maintained across incognito browsing, webviews, VPNs, changes to user agent or IP addresses, and other potential manipulations.

Compared to conventional methods, such as rate limits, IP tracking, user verification, and CAPTCHA, Stytch’s device fingerprinting product offers several advantages:

Stability: Stytch’s device fingerprints remain stable across various conditions, ensuring that the same identifier is associated with the same device, even when the user switches browsers or IP addresses.

Resilience: Stytch’s fingerprinting process is obfuscated, making it difficult for attackers to reverse engineer or spoof the fingerprint.

Customizable tools: Stytch’s product provides a set of customizable tools for businesses to accurately identify users by device and take appropriate actions based on the fingerprint review.

By utilizing Stytch’s device fingerprinting product, app developers can effectively combat free account abuse, including both automated and manual recurring abuse. This solution addresses the shortcomings of conventional methods, such as the ability of attackers to circumvent rate limits, IP tracking, and user verification, as well as the emergence of anti-captcha services. By providing a more robust and reliable method of device identification, Stytch’s device fingerprinting product improves application security to prevent abuse and safeguard against a poor customer experience.







---


# Why Switch to Stytch?
Source: https://stytch.com/blog/why-switch-to-stytch/

Switch to Stytch for authentication, authorization, and fraud prevention. APIs, SDKs, UI components for both consumer and B2B use cases.

So, switch to Stytch? You might be thinking, “Well, what even is Stytch, how is it different, and THEN why should I switch?” This post is intended to answer all of those questions, plus a few more! 

Stytch in a nutshell

Stytch is infrastructure for developers to build auth into applications. Stytch provides a suite of dev tools, including APIs, SDKs, UI components, tailored to support user & org management for a wide range of architectures & use cases.

There are a few things that make Stytch’s approach unique:

Auth and security in one — so your team spends less time integrating different solutions

Authentication: Login and user management with user linking and SMS/email sending built in (no provider setup required). Plus robust multi-tenancy for B2B apps.

Authorization: Role-based access control for B2B apps. AuthZ with Stytch starts simple, but comes equipped with out-of-the-box enterprise SCIM integrations.

Fraud Prevention: Low-friction bot & spam protections (with as few CAPTCHAs as possible). Standalone or combined with Stytch’s authentication products.

Machine-to-Machine Auth: Because sometimes humans aren’t necessary

Purpose-built products for B2B and B2C – so your team isn’t writing logic adapting a universal solution

Consumer and B2B apps have different needs!

Adding B2B features to a B2C data model leads to rough edges for users and internal glue code. And consumer companies don’t want the bloat that comes with a more complex B2B auth model.

Stytch offers two different auth products, with different data models and features that are custom to each business model.

Implementation flexibility– so your code is streamlined and you can make your auth flow UX your own.

Rather than a ‘Universal’ or one-size-fits-all model, Stytch offers a range of ways to integrate for both consumer and B2B apps:

SDKs with pre-built components

Headless SDKs

Calling the API directly (for those who want total control)

There’s a trend here: Stytch means less work and less code for your engineering team.



Ok, but why does this matter enough for me to switch?

Well, only you can answer that question. Here’s what we’ll say:

There are really two main reasons that we see engineering teams switch. Either auth is starting to drain engineering resources or it’s limiting your growth.

Losing engineering time

Something we see particularly from in-house auth builds or open-source auth solution users is that authentication maintenance starts to take up a lot of time! Or writing a lot of middleware to make “universal” 3rd party tooling fit use cases that it isn’t designed for.

Engineers find themselves constantly battling bugs, handling downtime & support issues, or writing glue code and if-statements to meet the requirements for one Enterprise customer after another. If auth has started to get in the way of your roadmap, the dev time that switching to Stytch could free up is probably worth it.

Limiting your growth

This takes a lot of forms:

For a consumer (B2C) app, it might look like losing purchases because the Auth0 hosted redirect makes login slow and decreases conversion. Or spending valuable support time troubleshooting with users who can’t log in.

For a multi-tenant (B2B) app, you might miss out on growth because you don’t offer SSO as a Sales lever, or can’t support a company that uses two different Identity Providers (e.g. Okta & Microsoft Entra), or aren’t able to enforce MFA for only one customer like the IT team is demanding.

Or from a fraud/bot perspective, it may be because bots are abusing your compute resources or your AI endpoints and you can’t stop it. Instead of making it easier for users to get up and running, or building exciting new features, your engineers are playing whack-a-mole with fraudsters, with no end in sight.

If any of the above sounds familiar, switching to Stytch is probably worth it.



Table of Contents

A quick guide to the rest of the post, so you can jump around to the most relevant sections.

Why Stytch, by use case?

Why Stytch for multi-tenant (B2B) auth?

Why Stytch for consumer (B2C) auth?

Why Stytch for fraud prevention?

Why Stytch, vs. alternatives?

Why Stytch vs. building auth in house?

Why Stytch vs. open-source solutions? (think: Keycloak, NextAuth/Auth.js)

Why Stytch vs. platforms that also include auth? (think: Cognito, Firebase)

Why Stytch vs. other 3rd party auth providers? (think: Auth0 and a growing list of smaller lookalikes)

How can I switch to Stytch?

Why Stytch, by use case?

Why Stytch for multi-tenant (B2B) auth?

We have more detail at stytch.com/b2b, but there are really three key reasons why Stytch is the best choice for B2B authentication:

Architected for multi-tenancy: Stytch’s B2B data model treats organizations as the top-level object, unlike other providers. Stytch supports setting custom authentication settings by organization, and adjusting them with just an API call. Better architecture = more flexibility and less time spent writing middleware, compared to other auth providers with a user-first data model.

Full-featured authentication and authorization: In other words, Stytch supports all the acronyms: OIDC and SAML SSO, RBAC, SCIM, enforced MFA, JIT provisioning, and more.

Device intelligence: Someone will always find a new way to abuse your app. This is a harsh reality – even for B2B. Stytch has built-in support for device intelligence, which helps you protect AI resources, compute, and customer data, and keep better track of threat exposure at login.

We’ll go deeper on each of these.

Architected for multi-tenancy

The key differentiator between Stytch and other B2B auth providers is that since B2B is a separate product from the Stytch B2C auth product, we designed it from the ground up for multi-tenant use cases (by comparison, Auth0 Organizations was launched in 2021 as an add-on that B2B teams need to use alongside and integrate with the Auth0 core product.

As part of building explicitly for B2B, Stytch intentionally chose to use a different data model for B2B, where organizations, not users, are the top-level tenant in the data model. We often refer to this as our ‘org-first’ data model, where organizations are the companies that buy and use your product.



If you’re a B2B SaaS app, your customers are companies – and each of those companies wants full control of who can access their instance of your app, how those users must authenticate, and what they can do once they’re logged in. Without a data model that reflects this organization-driven ownership and control, you’ll quickly run into massive roadblocks preventing you from meeting the security and compliance requirements of your customers.

These roadblocks can start early. A common early pain point is around enforcing the appropriate authentication requirements for each Organization that the end user belongs to.

Example roadblock: Variable MFA settings by organization

We’ll go through a specific example to make it tangible. Imagine you have four customers, Organization A, B, and C, and some users (for example – agencies) need to switch between them regularly.



If one Organization, like Organization B, wants to start enforcing MFA – do you require the user to complete MFA before logging into any of their Organizations? What happens if different Organizations require different MFA methods? If the user loses access to their MFA method, who is allowed to reset it for them? Will they be blocked from logging into their other Organizations, too?

In practice, configuring authentication settings by organization

So how would you solve this? Well, it depends on what auth provider you use.

Auth0’s official docs for enforcing org-specific MFA control require writing additional if-else glue code. Vs. with Stytch, you make a single auth method change.



Because of Stytch’s unique data model, this functionality – and the ability to support fully custom authentication settings by organization – is available out of the box.

While this example looked at MFA, the same is also true of setting up just-in-time (JIT) provisioning, or adding SSO – including with more than one Identity Provider (IdP) and both SAML & OIDC.



It’s that easy, because the data model allows for it.

As you move upmarket, there are more and more of these situations where this fundamental mismatch between your data model and who actually owns the account can derail enterprise deals or require complicated refactors and migrations. Organization-first sets you up with the necessary foundation to easily satisfy the requirements of both the smallest self-serve startups, all the way to enterprise Fortune 100 companies – with just a single API call.

You can read more about this and see sample code in the Stytch docs.



Full featured authentication and authorization

Enterprise customers request a lot of authentication and authorization features. Stytch has broad coverage – broader than many other players who offer point solutions for SAML SSO, for example – to meet a wide array of Enterprise needs.







Device intelligence

Authentication security hinges on both ensuring that users are who they say they are, and that actors with malicious intent can be blocked swiftly and reliably. By building device intelligence directly into our frontend SDKs, Stytch provides reliable fingerprinting at the point of login. Alternatively, you can deploy Stytch device fingerprinting independently, to protect specific customer data, compute resources, or a free offer. You can learn more by reading ‘Why Stytch for fraud prevention?’

Stytch also applies device intelligence in other unique ways that benefit B2B customers, beyond explicitly reducing fraud. For example, Stytch magic links use device fingerprinting to ensure that when magic links are scanned for security, such as Microsoft Outlook’s Safe Links, they aren’t then followed – and invalidated – by the bot traffic. By applying device intelligence, Stytch ensures the magic link token remains valid and ready to be clicked by a user when the time is right. 

This allows you to decrease friction for real, good users, and increase friction for everyone (and everything) else.

Why Stytch for consumer (B2C) auth?

A non-exhaustive list of reasons to pick Stytch for B2C auth:

Stytch’s separation of consumer and B2B auth avoids overcomplicating B2C; no bloat and no workarounds to support organization multi-tenancy that you don’t need!

Stytch’s B2C product includes a wide-range of consumer-focused auth factors – such as WhatsApp OTPs, or login with Facebook, Yahoo, and TikTok. All of these are consumer friendly, high converting, and not broadly supported by other auth providers.

One of the most powerful is support for Google One-Tap, which can increase signup conversion by 10X for consumer-facing companies (and which providers like Auth0 don’t offer)

Stytch’s solution is not hosted (so no redirect), and offers granular control – including the option to use the API directly. As a result, you have the option to use Stytch’s built-in UIs, but you can also create whatever customization or flow you dream of. Plus, removing the hosted redirect is a boon to conversions.

Stytch has provider failover for email and SMS OTPs built-in, which means higher deliverability rates and fewer customers who can’t log in and contact support

Stytch offers secure account deduplication by default so fewer users get locked out, or confused, and you write less (dangerous) spaghetti code to try to link accounts yourself



The issue with a Universal Login, is that login isn’t really universal – every app has different needs. Stytch understands that, and is built for it.



Why Stytch for fraud prevention?

Authentication and authorization are the mechanisms by which you get into an app and get access, but they’re also the tools that keep people out and prevent access. 

So your authentication flow needs to strike a delicate balance: it needs to let legitimate users in with as little friction as possible, while also defending your app from bad actors who want to access your precious resources – user data, credit card info, API endpoints, AI credits, compute, or something else entirely.

Conventional tools that companies use to address this, like CAPTCHAs, are outdated and ineffective at stopping bots. And there are thriving services that exist to solve and bypass CAPTCHAs at scale.



Most auth providers don’t recognize this, and expect you to rely on 3rd party providers to protect your auth flow, or offer limited tooling that treats fraud prevention as a secondary consideration. If you switch to Stytch, the opposite is true: account security and fraud prevention are baked into our auth model. And the tools we’ve built are so effective that we also sell them separately.

Stytch’s approach to fraud prevention is threefold:

Protect end users from account takeover (ATO) by offering customizable password strength detection and built-in breach detection

Use device fingerprinting to better distinguish real people and bots, to show CAPTCHAs to fewer users

Make CAPTCHAs more effective by ensuring they’re solved where they’re shown – not by a bot, or by an outsourced service

Protect end users from account takeover (ATO)

Stytch passwords come with (customizable) security protections built in: support for password strength strategies like LUDS or zxcvbn, as well as breach detection powered by Troy Hunt’s HaveIBeenPwnd.

This allows you to require users to create secure passwords, and to alert them and require a reset if their passwords have been exposed on the web to limit account takeovers and reduce fraud risk. More info in our consumer docs, B2B Saas docs & on the Stytch blog.

Use device fingerprinting to distinguish humans from bots

Device fingerprinting (sometimes called browser fingerprinting) uses a large number of signals from a visitor’s device and browser (think: IP address, device type, operating system, and more) to distinguish real users from bots or web scrapers. Stytch’s device fingerprinting solution returns a set of unique identifiers for the visitor, device, and network, as well as a recommended action (Allow, Block, or Challenge), to reduce the need to add friction for real users, while preventing abuse by bots or bad actors.

We also very intentionally don’t make our Device Fingerprinting product self-serve, because self-serve fraud prevention products very easily become testing playgrounds for bad actors. 

Stytch device fingerprinting can be used as an integrated solution with our frontend SDKs, or deployed standalone. More in our fraud prevention docs, in our Stytch vs. Fingerprint page, and on the Stytch blog.



Make CAPTCHAs more effective

When you do choose to challenge a user, traditional CAPTCHAs are not particularly effective solutions. Not only do users find them frustrating, it’s been well established that bots are better at solving CAPTCHAs than humans, that modern AI agents can easily be tricked into solving CAPTCHAs, and – absent that – that a wide array of CAPTCHA solving services take advantage of the public keys that CAPTCHAs expose to outsource CAPTCHA solving at low cost. 

Stytch’s Strong CAPTCHA solution works with Google reCAPTCHA to encrypt the payload with proprietary signals specific to the device, network, and user to whom the CAPTCHA was shown. This prevents CAPTCHA solving services or bots from easily manipulating CAPTCHAs at scale, as any CAPTCHA-solver except the original user will have different identifiers from the ones used for encryption.

Paired with device fingerprinting, this means Stytch allows you to show CAPTCHAs only when absolutely necessary, and to ensure those CAPTCHAs can’t be easily solved by bad actors, effectively deterring a wide range of attack mechanisms like credential stuffing. More in our Strong CAPTCHA docs and on the Stytch blog.



To summarize, Stytch offers low-friction fraud prevention tools – both built into our authentication suite and separately – to offer secure login flows without sacrificing on user experience.

Why Stytch, vs. alternatives?

We know you have options! But Stytch offers a level of flexibility and control that many 3rd party providers lack, without the hassle – and security risk – of building and maintaining auth yourself. And we’ll support you every step of the way. Read on for how we compare to specific options – in-house, open-source, cloud/database platforms, and other 3rd party solutions.

Why Stytch vs. building auth in-house?

Please don’t roll your own auth.

If you don’t believe us, pick any web-dev-adjacent Reddit or a CTO Slack Group and make a post declaring that you’re going to build auth yourself. See what you get back 🙂.

Why Stytch vs. open-source auth solutions? (think Keycloak, Nextauth/Auth.js)

At Stytch, we’re big advocates of open source. And the good news about open source auth options is that they’re free and you have full control over the code and the hosting.

The bad news is that you have full responsibility over the code and the hosting, which ends up being a lot of work. Part of the motivation to start Stytch for our CTO, Julianna Lamb, was actually based on her experience working with Keycloak and how challenging it was to manage and scale.

Stytch also handles a lot of the best practices and secondary requirements that these solutions don’t (for example – Stytch will send email and SMS for you (no additional config necessary), complete with backup providers as failover in the case of an outage from Twilio, MessageBird, or similar), and offers broader product coverage – including a wide range of auth methods and fraud prevention tools – so your login flow can evolve more easily over time.

Further, Stytch is built to scale and we invest heavily in our infrastructure, which is why we’re the only auth platform that offers a 99.999% uptime SLA to our Enterprise customers.

As with everything in engineering, though, it depends on your needs! Lucia is a great example of a dead-simple and highly functional auth provider that works really nicely for a Typescript project; but it’s probably not the best choice for Enterprise-grade multi-tenant auth. (hint: the best choice for that is Stytch).

Why Stytch vs. ‘platforms that also include auth’? (think: Cognito, Firebase, Supabase)

The good news about these options is that they’re very cheap, and can be easy to choose if you’re already using other products from that provider.

The bad news is that the reason they’re cheaper is that you’re saving on (1) Caliber of support; and (2) R&D / development focus.

Support: If you have an issue with AWS Cognito, you will have a very, very hard time talking to a human. If you have an issue with Stytch, ask in our Slack, on our Forum, or via email, and a real human from our team will get back to you promptly (unless a helpful Stytch customer beats us to it). We pride ourselves on high-quality, responsive support; and believe this is an invaluable resource, since every auth implementation is different.

R&D / development focus: To put it simply, auth is not the primary product for these platforms. It’s an auxiliary offering and a ‘check the box’ rather than how they’re making money. And so the investment in pushing the product forward – fixing bugs, adding new features like Passkeys, ensuring customers can add multi-tenancy without having the ‘development and operation effort… [be] high’ just isn’t there like it is with a dedicated provider.

That said, if you have straightforward auth needs & are using one of these stacks already, the products might be a good choice for your specific use case. And if your needs get more complex, you can always switch to Stytch later (consumer; B2B) 🙂

We offer comparison pages on our website for AWS Cognito & Firebase (aka Google Identity Platform) if you want to go deeper here.

Why Stytch vs. other 3rd party auth providers? (think: Auth0 and a growing list of smaller lookalikes)

This one is more complex to summarize, since every third party auth provider has a different flavor or approach. We have a dedicated page to compare Stytch vs. Auth0 specifically.

That said, a few differentiators about Stytch apply when comparing against almost any other dedicated 3rd party auth provider:

Stytch splits out B2B and consumer auth to make products tailored to each use case. And Stytch’s unique B2B SaaS data model makes it much easier to build low-friction multi-tenant auth with organization-level customizations.

Stytch has robust fraud prevention tools, including device intelligence, built into our auth products. This helps to secure your app and mitigate bot attacks, account takeovers, and more, while also reducing friction and 2FA checks for real users. It’s like having a better version of FingerprintJS fully integrated across your auth platform.

Stytch’s range of implementation options (API, headless SDK, SDK with UI) and broad range of SDKs (Go, Java, Node, Ruby / Vanilla JS, React, Next.js / Android, iOS, React Native) support wide ranges of stacks and implementations, without the restrictions (or redirect!) of a hosted or component-based auth library.

Stytch includes advanced API primitives to simplify processes like account deduplication and SMS- and email-sending (with provider failover) out of the box. This means easier setup, less glue code, and fewer vendors to maintain.

With Stytch, you get the pace of development and innovation of a startup, but with funding for the long haul, and Enterprise-grade customer credentials.

We’re also happy to share specific thoughts on a particular Stytch vs. x comparison if you have one in mind. Feel free to join our Slack if you have quick technical questions, or talk to a Solutions Engineer if you’re interested in learning more about Stytch’s Enterprise offerings.



How can I switch to Stytch?

Switching to Stytch doesn’t have to seem intimidating. We’ve done this before, and can guide you through it.

Here’s one of our favorite customer quotes from Tome, because it just about sums it up:



A few resources that are worth checking out from the Stytch docs:

Stytch Consumer Migration Guides

Stytch B2B SaaS Migration Guides

But most importantly, consider reaching out to our team, either by requesting a demo or dropping us a note in our developer Slack.

We have a lot of migration experience – from Auth0, Firebase, Cognito, in-house, you name it – and are happy to help think through how to make switching to Stytch as easy as possible.







---


# Out-of-the-box: User linking and provider failover with Stytch
Source: https://stytch.com/blog/user-linking-and-provider-failover-with-stytch/

Learn how Stytch supports secure linking of user accounts and offers built-in providers for SMS- and email-sending for authentication.

Many of our engineers built authentication systems elsewhere before joining (or, in Julianna’s case, starting) Stytch. And as a result, our team knows firsthand the pain and frustration of many of the hidden steps you have to take to get set up and then to ensure a secure and reliable auth setup going forward.

In this post, we’ll walk through two of the common hassles of auth setup that Stytch takes care of for you:

Secure User Account Linking & Deduplication

SMS/Email: Sending and Provider Failover

Secure User Account Linking & Deduplication

Another important infrastructure consideration that Stytch handles for you out of the box – with no additional setup required – is secure account deduplication.

In other words – Stytch ensures that if a user signs up with username and password, but then tries to login with Google OAuth, they don’t accidentally create two separate unlinked accounts. And, the linking happens securely and requires email verification – since insecure account linking can lead to account takeovers.

If you use another solution like Auth0, this functionality does not exist out of the box, leaving you with three options:

Option 1: Allow users to create a new account with each factor

For example, a user could create one account by logging in with username and password, and then create a separate account by logging in with Google OAuth..

This is a great way to get an influx of support requests where confused users think all their account data has disappeared (and also, a good way to get a lot of duplicate / phantom accounts that will never be used).

Here’s an example where a company opted to not link accounts, but instead wrote out a support help article as a resource for users who were confused and struggling to log in. It’s a solution, but it’s not a particularly graceful one.



Option 2: Block users from logging in with any factor except the original one they used

This prevents duplicate accounts, but is a bad user experience. No one wants to hit a screen like this, and users may get frustrated and drop off (or, contact support, which is expensive).



Fun fact: there are now so many users asking questions online about why they can’t log into OpenAI account with a different authentication method that competitors are using it as SEO-bait.

Option 3: Write glue code to link accounts

For Auth0, this means either adding an extension, writing a custom Auth0 Action or Auth0 Rule, and availability may vary based on your Auth0 implementation. Linking accounts is not to be taken lightly, as it has meaningful security implications.

Option 4: Use Stytch (aka none of the above)

With Stytch, none of these workarounds are necessary. Account linking happens automatically, but with consideration to the many nuances of what information is shared and verified by each login method.

For example, since Microsoft OAuth doesn’t verify email ownership, Stytch does not merge Microsoft OAuth logins with, for example, magic link logins, automatically without an additional verification step. These behaviors are outlined in the Stytch docs by provider for reference. 

You can try this out on stytch.com/start-now; magic links and Google OAuth both verify your email, and both take you to the same place.

SMS & Email: Sending and Provider Failover

Unlike a lot of other auth providers, Stytch handles sending emails and SMS messages for you, sending one-time passcodes and magic links directly through 3rd party services like Twilio, MessageBird, SendGrid, and more.

Emails and US/Canada OTPs are offered at no cost; international OTP costs are passed through at the costs incurred from 3rd party providers. In practice, this means huge time savings in setup and negotiation – rather than configuring multiple providers, grabbing API keys, drafting custom templates and optimizing them for deliverability, Stytch allows you to immediately start sending messages to users.

And perhaps even more importantly, Stytch also handles provider failover – ensuring that multiple SMS and email providers are available, so if one is experiencing an outage or latency, your critical login emails and one-time passcodes are still getting delivered.

This allows you to spend less time worrying about deliverability issues, or optimizing your email or SMS templates to avoid being marked as spam (there’s more to this than you might expect!).

Email delivery from third party providers is also included in Stytch’s event logs for observability purposes; you can learn more about message deliverability at Stytch in the docs.



The bottom line: time savings

In summary, by handling key configuration steps, like SMS/email delivery and account linking, Stytch allows you to more quickly and easily get up and running, and then ensures your users can log in reliably as you scale.

If you want to try it for yourself, you can get started with Stytch free today!







---


# Stytch multi-tenant example apps
Source: https://stytch.com/blog/stytch-multi-tenant-example-apps/

Use Stytch's multi-tenant example apps to see how to add flexible B2B auth and RBAC to a site built with Node, React, Express, and Astro.

We recently open-sourced two versions of a multi-tenant B2B example application. The first version leverages Stytch’s pre-built UI components on the frontend and our powerful Node SDK on the backend, while the second version utilizes Stytch’s SDKs in both the frontend and backend, along with a headless UI approach for login and B2B scenarios.

Featured in the example apps: Multi-tenant auth, RBAC, and more

One of the key advantages of using Stytch is flexibility of integration options. Some developers will prefer using an off-the-shelf UI and frontend SDKs with headless options to build more quickly. Others will need the full composability of backend SDKs and a well documented API to have full control over their authentication flows. These example apps are geared toward demonstrating the power and flexibility of Stytch in B2B multi-tenant authentication scenarios from a frontend-focused and backend-focused approach. These include:

Multi-tenancy in Stytch's data model

Role-Based Access Control (RBAC)

Stytch Organization and Member settings management via your own UI

Supporting multiple authentication methods (Email Magic Link (EML) and OAuth implemented)

Note that Stytch’s platform supports a full-suite of features including advanced auth methods like Google One-Tap, user provisioning features like SCIM, and unique device intelligence features to improve delivery performance of auth-related emails and prevent fraudulent signups. These apps are intended to showcase a common set of authentication and authorization features, but check out Stytch B2B docs and Stytch Fraud Prevention docs to see all of the supported functionality.



Diving into the example app stack

The example apps have two components:

A client built as a single-page app (SPA) React dashboard embedded in an Astro site

A server built as a Node Express API.

While focused on either frontend with Stytch pre-built UI components or backend with direct calls to the Stytch Backend API, both are full stack implementations of the same application and provide pre-built and custom frontend and backend scenarios. Each implementation of the application contains custom and integrated full-stack B2B authentication and authorization scenarios that developers face when building real world applications. With these B2B example apps, we aimed to accomplish and demonstrate:

Leveraging Stytch pre-built UI components to move quickly and abstract away authentication implementation details

Hooking into authentication lifecycle methods to perform custom tasks

After successful login, an api call is made to the backend to create a user account in the database

Utilizing Stytch Frontend SDKs for developing and managing a custom authentication UI

Allowing Stytch Frontend SDKs to automatically manage the storage of session tokens using browser cookies or mobile storage

Custom UI and a backend API for switching users between organizations 

Frontend uses Stytch Frontend SDKs to render custom UI for organizations the user is apart of

User selects new organization

Frontend calls custom backend API with server-side logic which calls the Stytch Backend API directly to log the user out of one organization and into the other

Getting started with the example apps

We hope you find these projects useful for learning and integrating Stytch. Get started with these apps today, on GitHub:

Stytch B2B Example App - Pre-built UI

Stytch B2B Example App - Headless

If you prefer to start from scratch, you can also watch Stytch’s CTO, Julianna Lamb, and Jason Lengstorf from Learn with Jason integrate multi-tenant auth and RBAC into a React + Express app here. If you have any questions as you’re getting started, feel free to join the Stytch Developer Slack to get quick help from our team, or contact us at support@stytch.com.

---


# Introducing major updates to Stytch B2B authentication
Source: https://stytch.com/blog/major-updates-to-stytch-b2b-authentication/

Introducing major updates to Stytch B2B authentication, including RBAC, SCIM, pre-built UIs for MFA, Google One-Tap, and more.

We launched our B2B authentication solution nearly a year ago because we realized that building and managing authentication for multi-tenant applications was painful for developers.

The product has evolved a lot since that launch, and we’ve seen incredible engineering teams ranging from Zapier, Hubspot, and Cisco make the switch to Stytch. Today we’re incredibly excited to announce a long list of new capabilities that make integrating authN, authZ and fraud prevention into multi-tenant apps an even better experience for developers.

What’s different about Stytch B2B auth

What makes Stytch B2B auth so unique is the underlying architecture. Other authentication solutions simply tack on elements of B2B authentication to a consumer authentication offering. This pushes all of the complexity of organization tenancy (also known as multi-tenancy) to your development team, who then have to write and maintain significant amounts of custom code in their backend systems to handle authentication. The complexity of this code only increases as your app scales and as new authentication methods and configurations are required. Doing something as simple as changing an organization’s auth settings requires a messy 40+ line if-else and array comparator function. 

At Stytch, we took a different approach and chose to build a B2B authentication solution with built-in multi-tenancy and “Organizations” as a first class entity in our data models. By building a solution from the ground up that’s specifically tailored for the needs and requirements of multi-tenant applications, Stytch’s platform cuts the engineering lift to build and scale auth so teams can focus on building their core products. Adding or updating SSO, MFA, SCIM, RBAC and more is just a simple API call away.

What’s new in Stytch’s B2B solution

Since the initial launch of our B2B solution, the Stytch team has continued to improve our B2B auth solution, adding new features and capabilities that help developers implement and scale enterprise-grade authentication in their apps.

Today, we’re excited to announce a whole host of updates to Stytch’s B2B solution, including:

Zero downtime session migration: You can now migrate from your existing auth provider to Stytch without requiring your users to log out of their existing session. This means that a migration is effectively invisible for your end-users, so there’s no friction when you switch to Stytch as your authentication provider. See the docs.

Google One-Tap: We now support Google One-Tap for B2B authentication via our SDKs. Compared to the standard “login with Gmail” auth method this provides a frictionless user experience that automatically detects a user’s logged-in Chrome or Gmail session. See the docs.

Pre-built UI for OTP & TOTP MFA: We now provide pre-built UI elements for both OTP and TOTP MFA in our front-end SDKs, so you can easily set up MFA with security and UX best practices in a fraction of the time. See the docs.

Role-based access control (RBAC): RBAC enables organizations to streamline the management and enforcement of user roles and permissions. With RBAC, Stytch allows you to handle both authentication (authN) and authorization (authZ) in a single platform. See the docs.

System for Cross-domain Identity Management (SCIM): Enables any changes made to a user identity in an IdP (e.g. provisioning, deprovisioning, profile updates) to be automatically synced with your application. See the docs.

Protected email magic links: Ensures the successful, secure delivery of email magic links, as our built-in device fingerprinting detects enterprise security scanners and prevents consumption of the single-use token. See the docs.

And many more!

If you’re interested in learning more about our B2B offering, feel free to check out our docs or chat with a member of our team.

New B2B Example Apps

We’ve recently released two different versions of a multi-tenant B2B example application built on Stytch’s SDKs that developers can leverage to better understand Stytch’s B2B solution. One version leverages Stytch’s pre-built UI components on the frontend, while the other uses a headless UI. This showcases another advantage of Stytch – the flexibility of developer tools to use pre-built UI components, SDKs for headless implementation, and/or backend SDKs and APIs.





Check out our blog post to get access and learn more.

Learn how others integrated Stytch

We also have new case studies highlighting two different B2B applications that are leveraging Stytch for authentication.

Tome: Tome is an AI-powered storytelling platform that migrated millions of users and organizations from Auth0 to Stytch B2B in weeks. 

Orb: Orb is a comprehensive billing platform that migrated from Auth0 to Stytch’s SSO offering in one week.

At Tome, we care deeply about delivering a great UX across the board, and auth is no exception. By leveraging Stytch's B2B product, we have successfully reallocated 2-3 engineers to core product development and new features. 

Archana Sankaranarayanan - Director of Engineering

Learn With Jason Livestream: Auth and RBAC in multi-tenant React apps

Want to learn how to build authN and authZ into an application?

Follow along in this recording where our CTO, Julianna Lamb appeared on a Twitch livestream with LearnWithJason. Julianna and Jason used Stytch and our pre-built UI components to add authentication and authorization to a React + Express app in a 90 minute livestream.



Get started with Stytch

Want to learn more about Stytch’s B2B solution? Check out our docs and start building for free today. 

If you have any questions, feel free to contact us at support@stytch.com or schedule a chat with a member of our team. 








---


# What are webhooks?
Source: https://stytch.com/blog/what-are-webhooks/

In this article, we explore webhook architectures and their real-world use cases, potential security best practices, and demonstrate how you can use webhooks to build efficient, event-driven systems.

Webhooks are a simple but efficient way for applications to communicate with each other in real-time, without having to make multiple API calls. Whenever an independent system needs to make decisions or trigger certain internal actions based on disparate events in another system, it can create a unique URL where it receives payloads in either JSON or XML format.

In this article, we’ll explore webhook architectures and their real-world use cases, discuss best practices and potential security considerations, and demonstrate how you can use webhooks to build efficient, event-driven systems.

How do webhook architectures work?

All webhook architectures typically have two primary components: the webhook provider and the webhook consumer.

A webhook provider could be an application, platform, or service that exposes an interface for other systems to subscribe to specific events and receive real-time updates. It’s solely responsible for generating and sending webhook notifications to the consumer.

On the other hand, a webhook consumer is the system that receives and processes webhook notifications from the provider. It could be an application, function, microservice, or any other system capable of handling incoming HTTP requests.



Webhook subscription

To establish a webhook connection, the consumer application must first subscribe to the desired events offered by the provider. This process typically involves the following steps:

The consumer application registers a unique URL (webhook endpoint) with the provider, specifying where it wants to receive the event payloads.

The provider stores the webhook endpoint URL and associates it with the selected events.

Whenever a subscribed event is triggered, the provider sends an HTTP request containing the event data to the registered webhook endpoint.

Webhook request methods

Webhook requests can be sent using various HTTP methods, but POST and GET are the most commonly used request methods.

In POST requests, the event payload is contained in the request body and may include additional information, such as authentication tokens in the header. POST requests are not idempotent, so sending the same request multiple times may result in duplicate data or actions.

In GET requests, the event payload is included as query parameters appended to the webhook URL. These requests are idempotent, meaning that sending multiple identical GET requests will produce the same result without side effects. It’s important to note that GET requests are mostly used to verify if a webhook endpoint exists.

While POST is the most widely used method for webhooks, other HTTP methods like PUT, PATCH, and DELETE may be employed in specific scenarios, such as modifying or deleting data.

Webhook POST requests follow the typical HTTP request structure with a start line, header, and payload.



When would I use this in the real world?

To think about how this might work in a real-world example, let’s imagine your engineering team uses a version control system like GitHub and would like to receive notifications in Slack when certain events, such as pull requests or commits, occur on GitHub. Slack, which is the consumer application, would have to provide a webhook URL where GitHub can send real-time notifications whenever any of the specified GitHub events take place. Instead of Slack having to continuously poll GitHub for new events, it’s much more efficient for GitHub to send a notification to Slack only when a relevant event occurs.

Whenever a Slack admin successfully installs the GitHub app via an OAuth verification code exchange, Slack automatically sends an OAuth response to GitHub. This response typically includes an “incoming_webhook” object containing a pre-generated “URL” field where the GitHub app can post data in real-time.

In this way, whenever a subscribed event triggers in the connected GitHub repository, GitHub will send a POST request containing the event details to Slack’s webhook URL. Slack then parses the requested data, formats it into a message, and sends it to the specified Slack channel, ensuring users stay up-to-date with the latest activity in their GitHub repositories.



If roles were reversed and we wanted to perform certain actions on GitHub right from Slack without having to visit GitHub directly, the implementation would follow a similar process. However, in this case, GitHub has to provide a webhook URL for Slack to send data to.

Webhook responses and error handling

When a webhook consumer receives a request, it typically acknowledges receipt by sending an appropriate HTTP status code (e.g., 200 OK) and may optionally include a response body. If the consumer encounters an error while processing the webhook, it usually responds with an error status code (e.g., 400 Bad Request) and provides details about the error in the response body.

Webhook providers also implement retry mechanisms to handle these kinds of cases where the consumer application is unavailable or fails to process the webhook. This ensures that no events are lost due to temporary issues and maintains the reliability of the integration.

Examples and use cases of webhooks

Beyond the basic GitHub/Slack notification example described above, webhooks can be incredibly useful in other software development settings. Let’s look at a couple here.

Enterprise user provisioning via SCIM

To centrally manage employee identity and access permissions across internal systems and external applications, most enterprise companies rely on the SCIM protocol, or System for Cross-domain Identity Management. SCIM is an HTTP-based protocol that leverages REST APIs to facilitate onboarding new users, setting their permissions, managing role changes, and offboarding users across multiple domains.

In a typical SCIM setup, the company’s IAM system or identity provider (SCIM IdP) such as Okta or Microsoft Entra ID acts as the “client” and is responsible for storing and managing the identities and permissions required by service providers. The SaaS applications employees use for work within the company (i.e., Slack, GitHub) are known as “service providers.”

Whenever an administrator makes CRUD changes to a user account on the IdP, SCIM automatically propagates these changes to all connected service providers, ensuring that all systems remain in sync without admins having to manually effect the same changes across every SaaS app.

However, for enterprise applications and their connected service providers to receive this kind of automatic updates from their IdP via SCIM, they need to provide a SCIM connector base URL which will act as a SCIM endpoint.

The options they have are either to build a native SCIM connector within their application, which can be complex and time-consuming, or leverage auth platforms like Stytch. By leveraging the SCIM base URL provided by these auth providers, enterprise apps can easily configure their IdP to send updates without the need for a custom SCIM implementation.



Now, the important thing is that, once the IdP events start syncing to Stytch, these enterprise apps have to ensure their application reacts appropriately to user and group changes. For instance, if an employee’s account is de-provisioned from the IdP (e.g., Okta), all internal systems and service providers that the employee had access to must immediately terminate their session and deny access on their next request.

The only way to achieve this is by setting up a webhook endpoint within the enterprise application and configuring Stytch to send all directory sync events to that endpoint.



In this way, we can be sure that the user in question has been automatically de-provisioned not just on the enterprise application alone, but across all the connected SaaS applications they use within the company. While webhooks are not a mandatory part of the SCIM specification, they must be used in conjunction with SCIM to enhance the functionality and real-time capabilities of the system in this kind of scenario.

Automating IaC workflows

Instead of manually configuring networks and servers for every deployment, IaC (Infrastructure as code) enables DevOps teams to define their entire infrastructure using code. This makes it easier for companies to provision and manage their infrastructure resources in a consistent and repeatable manner.

Popular IaC tools like Terraform, AWS CloudFormation, Azure Resource Manager, and Ansible enable these teams to create and deploy infrastructure components such as virtual machines and load balancers using declarative programming.

Now, you may be wondering how webhooks come into play. Webhooks can be used to reduce the steps required to implement and manage git-centric deployment pipelines and also to launch end-to-end IaC workflows automatically.

In GitOps workflows, the Git repository serves as the single source of truth for infrastructure configuration. As such, when a change is made to the infrastructure code in the Git repository, webhooks can automatically trigger the necessary actions to ensure that the actual state of the infrastructure always matches the desired state defined in the code.

The webhook is typically set up to notify the desired state engine whenever a change is pushed to the Git repository, which then executes the necessary IaC workflows to provision, update, or delete infrastructure resources accordingly. For example, let’s assume a developer pushes a code change to the Git repository that modifies the configuration of a virtual machine. The webhook will detect this change and send the updated code to the desired state engine. The desired state engine then uses an IaC tool like Terraform to apply the changes to the virtual machine, ensuring it matches the desired state defined in the code.

Webhooks can also be used to trigger other types of automation beyond infrastructure provisioning. For instance, webhooks can be integrated with CI/CD pipelines to automatically run tests, build artifacts, and deploy applications whenever code changes are pushed to the Git repository. This enables a fully automated workflow where code changes trigger the entire pipeline, from infrastructure provisioning to application deployment.

Common webhook vulnerabilities

If you’re thinking about using webhooks for your application or within your dev team, there are a few common vulnerabilities you’ll need to plan for, the most significant of which are server-side request forgery and replay attacks.

Server-side request forgery (SSRF)

Server-side request forgery (SSRF) is a critical security vulnerability that allows attackers to manipulate web applications or APIs into performing unauthorized actions on their behalf. SSRF attacks can be particularly dangerous because they allow attackers to access internal systems and services that aren’t directly exposed to the internet in order to exfiltrate data or launch denial-of-service attacks.

Webhooks are susceptible to SSRF attacks because they allow consumers to specify custom URLs where they want to receive event notifications. If not properly secured, attackers can manipulate these webhook URLs to point to internal services or resources, effectively using the webhook system as a proxy to perform unauthorized actions.

For example, if a web application allows users to enter custom webhook URLs without proper validation, an attacker could input a URL pointing to an internal service instead of a legitimate external endpoint. As such, when the webhook is triggered, the server will send a request to the specified internal URL, potentially exposing sensitive information or enabling the attacker to interact with internal services.

To prevent SSRF attacks when dealing with webhooks and other server-side requests, one effective approach is to use a proxy server that filters out requests to internal IP addresses and restricts access to sensitive resources. By placing this proxy server between the webhook system and the external network, we can prevent webhooks from directly communicating with internal services.

Additionally, implementing strict input validation and whitelisting for webhook URLs can help mitigate the risk of SSRF attacks. By maintaining a whitelist of trusted domains and IP addresses from which the consumer should accept webhook requests, you can automatically reject any requests from domains or IPs that aren’t on this whitelist.

Replay attacks

Replay attacks happen when a malicious actor intercepts a legitimate webhook request and then resends it to the consumer server at a later time, attempting to trick the server into executing the same action multiple times. This can occur even when the original webhook payload is encrypted or signed, as the attacker doesn’t need to modify the request to cause harm.

This vulnerability arises when webhooks are not designed to be idempotent, meaning that processing the same request multiple times can lead to unintended consequences. For example, if a webhook is used to process a purchase event, a replay attack could result in the purchase being duplicated, leading to incorrect inventory levels, balance discrepancies, or other issues.

To protect webhooks against replay attacks, a common best practice is to include a timestamp in the signature of the webhook payload. The timestamp is typically hashed together with a secret key and the request body, creating a unique signature for each request. When the receiving application processes the webhook, it can compare the timestamp in the signature to the current time. If the timestamp is too old (beyond a predefined threshold), the application can safely reject the request, knowing it’s likely a replayed message.

This approach fortifies against replay attacks because the timestamp cannot be manipulated without invalidating the entire signature. Even if an attacker intercepts a valid webhook request, they cannot modify the timestamp to make it appear current without possessing the secret key used in the signing process.

Wrapping up

We’ve successfully explored the fundamentals of webhook architectures, their real-world use cases, and the most critical security risks and vulnerabilities. However, these vulnerabilities in no way diminish how useful webhooks can be.

To start building auth with Stytch, check out our documentation and sign up for a developer account. If you have any questions, please don’t hesitate to contact us at support@stytch.com.







---


# Webhooks vs APIs
Source: https://stytch.com/blog/webhooks-vs-apis/

In this article, you’ll learn the differences between APIs and webhooks, their respective use cases, implementation patterns, and best practices for leveraging both communication architectures.

When it comes to building applications today, engineering teams no longer have to build every feature from scratch. Instead, they can leverage pre-existing libraries and packages from external systems.

This is only possible because we now have multiple communication architectures to streamline data sharing between independent systems, and two of the most common options are webhooks and APIs.

In this article, you’ll learn the differences between APIs and webhooks, their respective use cases, implementation patterns, and best practices for leveraging both communication architectures.

What are webhooks and how do they work?



Webhooks are HTTP callbacks triggered by events that happen on a source system (the provider) and are sent to another system’s predetermined webhook URL (the destination). This one-way communication flow, initiated by the provider, is why webhooks are often referred to as “reverse APIs.”

To set up a webhook integration, the consumer app (the destination) must first provide a unique URL to the source server and specify which event(s) it wants to be notified about. This webhook URL then acts as a listening endpoint on the destination server, ready to receive incoming webhook payloads from the provider.

Once the webhook is set up, the consumer doesn’t need to continuously poll the provider server for updates. Instead, whenever the specified event occurs on the provider system, it automatically sends a payload in an HTTP POST request to the consumer’s designated webhook URL.

The payload typically includes information about the event that occurred and any relevant data associated with it. For example, if the event is a new user signing up on the provider’s platform, the payload might include the user’s name, email address, ID, and other relevant details.

Upon receiving the HTTP POST request, the consumer app can then process the webhook payload and take appropriate actions based on the data received. This can involve updating databases, triggering specific workflows, sending notifications, or performing other necessary tasks.

After successfully processing the payload, the consumer application may choose to send a response back to the provider to acknowledge that the webhook was received and handled properly. This step is optional and depends on the specific webhook implementation, but it can be particularly useful in scenarios where the consumer encounters an error while handling the webhook.

For instance, if the consumer server was unavailable and the payload delivery was unsuccessful, sending a response back to the provider allows it to retry sending the webhook at a later time. This ensures important data isn’t lost and communication between the two systems remains reliable.

​​What are APIs and how do they work?



An API, or application programming interface, is a set of rules and protocols that can be exposed by a module, service, or application to enable independent systems to interface with it directly. They define the methods and data formats disparate client applications must follow when requesting or sharing information with a server.

Unlike webhooks that trigger real-time notifications from server to server, APIs allow applications to directly access and exchange data with each other through a request-then-response flow where the client app initiates a request and receives a response from the server.

In essence, APIs provide a programmatic interface that allows developers to access the functionalities and data of an application or service without needing to understand the underlying implementation or infrastructure complexities.

The way APIs work is quite straightforward. When a client needs to interact with a server, the client app has to send a request specifying the desired action, data, or functionality that it requires. Once the API receives the request and processes it, the server then generates a response based on the request and returns it to the client. This response could contain the requested data, the result of the operation, or any relevant error messages.

APIs can be implemented using several architectural patterns, each with its set of principles and standardized conventions. The four most common API architectural patterns are REST, SOAP, RPC, and GraphQL.

These API architectures define an API’s data model, URI structure, and the standard formats in which it provides and receives data. However, REST is the most popular architectural style for building public-facing APIs, due to their simplicity and compatibility with the web. Depending on how they’ve been implemented, APIs typically use JSON or XML data formats for sending requests and responses.

Pushing vs pulling: difference in a nutshell



Perhaps the most helpful way to conceptualize the difference between webhooks and APIs is a pull vs. push approach: At their core, webhooks follow a server-to-server “push” architecture, while APIs follow a client-to-server “pull” architecture, also known as the request-then-response flow.

With webhooks, the source server proactively pushes relevant data to a predetermined destination URL (webhook endpoint) whenever a specific event is triggered. This push model eliminates the need for the destination system to repeatedly request updates, making webhooks particularly useful in cases when disparate systems need to perform follow-on actions as soon as data changes on a source system.

In contrast, APIs leverage a “pull” architecture, where the client application must send a request to the server and wait for a response. The client is responsible for querying the server if there is any new or updated data available, and the server is responsible for processing the request, retrieving the relevant information, and sending a response back to the client.

API polling is a common practice in the pull model, where clients repeatedly send requests at regular intervals to check for new data. Since the client app doesn’t run on the same port as the server app, it doesn’t know when data is updated, so it has to poll the server’s API for an update—sending multiple requests until the specific event occurs. However, this approach can be inefficient and resource-intensive, especially if the data in question doesn’t change frequently. The client may end up making numerous unnecessary requests, consuming bandwidth and processing cycles, even when no updates are available.

Webhook vs API: when to use which

Despite the similarities between webhooks and APIs, they’re designed to solve different problems and excel in unique scenarios.

If you need to expose your application’s data or functionality while handling volumes of requests from multiple clients, building an API is the way to go. APIs allow you to provide a programmatic interface that clients can use to specify the endpoints they need to access, the CRUD operations to perform, and the exact data they expect to receive. This level of control and flexibility makes APIs ideal for complex interactions and data manipulation.

The decision between webhooks and APIs often boils down to whether the data you’re working with is frequently updated or not. If your application relies on real-time updates and needs to trigger follow-on actions based on specific events occurring in an external system, webhooks are the preferred choice. They eliminate the need for constant API polling, which can introduce latency and unnecessary overhead.

Another factor to consider is the management overhead associated with APIs. Any changes made to an API’s structure or parameters require updating all the client applications that are integrated with it. This tight coupling can lead to increased development and maintenance efforts.

Webhooks, on the other hand, offer a more loosely coupled approach, as the consumer application only needs to know how to handle the incoming data rather than being tightly integrated into the provider’s infrastructure.

It’s important to note that webhooks also have some limitations compared to APIs. They are unidirectional, meaning they can only send data from the source system to a destination and can’t perform complex operations like retrieving, manipulating, and updating data.

A real-world example

To think about when you’d use webhooks vs. APIs within your application, let’s consider the case of a hypothetical e-commerce startup that wants to accept card payments or bank transfers from customers scattered across multiple countries.

As a smaller or newer and insignificant business, this startup can’t directly partner with the major card networks like MasterCard or Visa, or even go directly to the banks to access their banking or payments infrastructure. They’re just not a “big enough” customer for these providers to pay attention to.

The only way to piggyback off the functionalities of these card networks or banks is to integrate a payment gateway like Stripe or Adyen. These gateways already have established relationships with several payment and banking providers that anyone can utilize via APIs without having to deal with these providers directly.

As such, our early-stage startup can integrate Stripe or Adyen’s prebuilt checkout UI to accept customer payments without having to build any custom finance infrastructure in-house. We only need to implement a server-side route or function to receive and validate payment requests from our client-side code, then communicate with Stripe or Adyen’s API to process the payment.

However, if this app needs to message customers about the status of their transactions, we’ll have to rely on webhooks instead of APIs. As long as our app supports incoming webhooks, we can set up a webhook endpoint to listen for events from the payment gateway.

This way, whenever a relevant event occurs, such as a successful payment or a card decline, the payment gateway can send a real-time notification to our registered webhook endpoint. Our application can then process this notification and trigger the appropriate follow-on actions, like sending an email update to the customer using an email service provider. In essence, webhooks aren’t an alternative to APIs or vice versa. They’re complementary communication architectures that serve unique purposes.

Potential use cases for webhooks

As we’ve established so far, webhooks are particularly useful when you need to send real-time events across applications to trigger follow-on actions and automate third-party workflows.

Whether you’re syncing apps using automation middlewares like IFTTT or Zapier, or automating software deployments using tools like Jenkins, webhooks are the most reliable and efficient way to receive instant updates from independent servers. We’ve covered in-depth examples and real-world use cases of webhooks in a separate article and you can find it here.

Potential use cases for APIs

Leveraging third-party auth

When it comes to integrating third-party functionality without having to build every feature from scratch, leveraging authentication and authorization APIs is a prime example.

One common challenge engineering teams face when leveraging in-house or open-source authentication solutions is the significant time and effort required to continually maintain and customize their infrastructure.

Trying to tailor universal auth providers to fit your specific use cases often involves writing extensive middleware and conditional logic that will consume valuable engineering resources. Your team may end up spending substantial time building custom implementations to meet the ever-changing auth requirements of different enterprise customers.

If your current authentication and authorization setup has started to impede your team’s ability to deliver on your key roadmap initiatives, you should consider a dedicated auth solution like Stytch.

Using Stytch, both startups and large enterprises can build robust auth functionalities into their apps using our APIs. We’re the only auth provider offering a comprehensive set of APIs, SDKs, and pre-built UI components that dev teams can use to build the exact end-to-end auth experience they need, regardless of the stack they’re building in.

Our APIs are available across multiple programming languages and frameworks, including JavaScript, Python, Go, Ruby, Java, Next.js, React, and more. As such, developers can integrate essential features like passwordless auth, multi-factor auth (MFA), social logins, single sign-on (SSO), and even role-based access control (RBAC) within days, rather than weeks or months.

We also support industry-wide protocols like SAML, OIDC, SCIM, and OAuth, making it easy for organizations with complex security requirements to adopt industry standards in no time.

Microservices and event-driven systems

In a microservices architecture, applications are divided into small, independent services that perform specific business functions. However, APIs enable these services to communicate with each other, allowing them to exchange data and coordinate their separate functions. Each microservice exposes a set of APIs that define the functionality it provides and the data it requires or returns.

For example, if a user service needs to grant an end-user access to their dashboard, it may have to send a request to an API endpoint exposed by the authentication service to verify the user’s credentials, before granting or denying access. This decoupling allows development teams to deploy and scale multiple services autonomously, without impacting the overall system architecture.

Event-driven systems also leverage APIs to facilitate asynchronous communication between separate components and services. Each service uses APIs to publish events to a central message broker or event bus, and independent services that need to react to these events can subscribe to them and perform their designated actions.

When a specific event occurs, such as a new user registration or a payment being processed, the service responsible for that event publishes it to the message broker through an API. As such, services that have subscribed to that particular event can then consume the published event and perform their respective operations, like sending a welcome email or updating a user’s balance.

Get started with Stytch

Want to learn more about Stytch’s B2B/B2C APIs and SDKs and how we fit your tech stack? You can check our docs and sign up for a developer account to start building for free today.

Feel free to join our developer Slack if you have any technical implementation questions, or you can schedule a chat with a Solutions Engineer if you’re interested in learning more about our Enterprise features and pricing.










---


# How to Enforce Multi-Factor Authentication with Node.js and Stytch
Source: https://stytch.com/blog/how-to-enforce-multi-factor-authentication-with-node-js/

In this article, you’ll learn how to set up MFA in your own Node.js-based app using Stytch, a popular identity platform for developers.

In modern cybersecurity, using a single authentication factor alone like passwords is rarely able to prevent attackers from gaining unauthorized access to personal data. That’s why multifactor authentication (MFA) is so important. MFA adds additional layers of security to your existing authentication methods by requiring users to verify their identity a second, third, or any number of times using additional methods of authentication.

The additional methods of authentication often include keys that are hard to forge, such as a one-time code through an authenticator app or text message, or an on-device verification using the device’s primary login methods, which may include biometric sensors. This makes the authentication process more difficult to crack.

MFA is used in all sorts of scenarios, ranging from financial transactions and accessing sensitive data, like medical records and business documents, to securing online accounts, such as social media, email, and shopping, as well as accessing cloud applications and services.

In this article, you’ll learn how to set up MFA in your own Node.js-based app using Stytch, a popular identity platform for developers.

Enforcing Multifactor Authentication

MFA isn’t simply a security add-on; it’s a paradigm shift in access control. This approach significantly reduces the risk of unauthorized access, safeguarding sensitive data and mitigating security breaches.

Data breaches are one of the prime reasons organizations should choose to enforce MFA as they often inflict financial losses, diminish trust, and damage reputations. MFA significantly reduces this risk, transforming the login process into a multistep verification procedure, deterring even the most equipped attackers.

Enforcing MFA requires careful planning. Organizations often choose to make MFA adoption mandatory for all members to ensure everyone benefits from enhanced security. However, individual user preferences can cause issues. Some users might prefer an opt-in approach for specific accounts, like financial platforms or sensitive internal systems. This enables employees to customize their security posture based on their needs and risk tolerance.

That’s why you should consider implementing MFA and an opt-in approach based on your specific business needs. You can come up with an arrangement that makes the best use of both of these approaches, such as requiring executives (who have elevated access to organization data and resources) to have mandatory MFA for all accounts, while other employees can choose to opt-in for specific sensitive applications. You’ll learn how to implement both of these approaches here.

Enforcing MFA in Node.js

In this tutorial, you’ll implement an MFA setup in a Node.js-based backend using Stytch. Email is used as the first authentication method, and SMS-based one-time passwords (OTP) are used as the second authentication method. However, the use of SMS-based OTPs for the second factor of authentication is conditional depending on whether an organization enforces it or a user opts into it.

This tutorial utilizes Stytch’s Discovery login feature, which allows users to view all their memberships and associated organizations upon logging in. Users can then choose the specific organization they wish to authenticate into.

Here’s what the user flow looks like:



To keep primary authentication straightforward and passwordless, you’ll use email links to sign in users. Once the user clicks on the email link and its integrity is verified, Stytch returns a list of all organizations that the user is a part of, along with an intermediate session token. At this point, the user can either choose to sign into an organization that they’re already a part of or create a new organization as part of a new sign-up.

Those signing into an existing organization need to exchange their intermediate session token to complete the authentication within their organization. If their chosen organization requires MFA, they receive the intermediate session token back and carry out SMS verification. The intermediate session token is consumed as part of the SMS code verification step, and the user receives a session token upon successful completion of the two-step authentication process.

Those creating a new organization can use the intermediate session token to create the new organization. They are designated as the administrators of the newly created organization, and they can choose to enforce MFA for all members before creating the organization. Should they choose to enforce MFA, they’ll be redirected through the MFA code sending and verification process before finally completing the login process. Any new user added to the organization is required to go through the MFA step every time they try to log in.

For organizations that do not enforce MFA for all members, the logged-in members have the option to opt in for MFA from the dashboard. Once they do, they need to carry out MFA verification the next time they log in.

Prerequisites

To build this app, you need Node.js and npm installed on your system. To keep things simple, you’ll clone a prebuilt project from GitHub, which has the frontend for the app already built in React. Then you’ll learn how to create the necessary endpoints in the Node.js app to develop user flows.

Start by cloning the GitHub repo by running the following command:



Switch to the starter branch, which only has the frontend code and an empty backend folder where you’ll write your Node.js app.



Create a Node.js app

To build the backend, you need to create two files: app.jsx and session.jsx. The app.jsx file contains the code for your server, and the session.jsx file contains a few helper functions to manage user sessions.

You’ll develop the backend server using Express. You’ll also use CORS for cross-origin requests, dotenv for accessing Stytch credentials stored in a .env file, cookie-parser for managing cookies, and the Stytch Node.js library for implementing the authentication flows.

Start by creating app.jsx and session.jsx, and installing the dependencies by running the following commands:



Once these run, create a .env file in the backend folder and save the following contents in it:




You’ll populate these values after you create a free Stytch account.

Set Up Stytch

Head over to the Stytch website and sign up for a free account. Once you’ve created an account, you’ll be asked to create your first organization. Click on the Create an organization button to create one:



You’ll be redirected to a form where you need to provide your name and your organization’s name:



You also need to choose the authentication type for your first project: consumer authentication or B2B SaaS authentication. The main differentiator is that projects with B2B SaaS authentication let you create organizations that your users can sign up for while those with consumer authentication type do not allow this.

For this tutorial, choose the B2B SaaS authentication type and click on Get started. This creates the project in your new Stytch account.

Next, go to the API keys page and retrieve the Project ID and Secret:



You’ll notice two tabs on this page: Test environment and Live environment. Stytch provides you with two separate environments (with their own sets of credentials) to help keep development and production isolated. Make sure to retrieve the keys from the Test environment tab for this tutorial.

Store these values in the .env file you just created. Now, you’re ready to set up the Express app and use these values to initialize the Stytch SDK.

Finally, you’ll need to set up a Redirect URL in the Dashboard to redirect users back to your application when clicking the magic link. To do that, navigate to the Redirect URLs page on the Stytch dashboard. Make sure you’ve selected the Test environment on the top of the page:



On this page, click on the white + Create new redirect URL button. In the form that opens up, enter http://localhost:5173/auth/callback as the URL and check the box next to Discovery to set this URL for redirects originating from Discovery API calls. This is what the form will look like before you submit it:



Click on the white Ok button to save the new redirect URL. Now, you’re ready to start writing the code!

Develop the App

To start developing the app, store the following contents in the session.js file:



This file contains a list of methods that help you store and manage the tokens for your auth sessions and intermediate sessions. You’ll use them later when writing the endpoints.

Next, open up the app.js file and add the following to it:



This code imports the necessary packages, configures dotenv to load the environment variables from the .env file, and initializes the Stytch client.

Next, add the following lines of code to initialize an Express app and configure the necessary middlewares:



Additionally, define the following helper function to help you extract the domain from an email:



This comes in handy when using the email address of the user to determine the domain name of their organization.

Write the Endpoints

Now, you’re ready to write the endpoints.

There are a total of nine endpoints. Here’s a quick overview of what they’ll do:

/api/discovery/start starts the discovery flow by sending an email magic link to the user.

/api/auth/callback receives the callback from Stytch when someone clicks on a magic link.

/api/discovery/create creates a new organization.

/api/discovery/get-organization retrieves the details of an organization.

/api/discovery/select-organization selects an existing organization and completes the authentication process according to its MFA policy.

/api/mfa/send sends a OTP to the phone number of the current user for MFA.

/api/mfa/authenticate authenticates if the OTP provided by the user is correct to complete MFA.

/api/mfa/update allows users to update their MFA preference (if the chosen organization allows).

/api/auth/logout logs out the current user.

Now, you can write the code for each of these endpoints.

Paste the following code in the app.js file for the /api/discovery/start endpoint:



This endpoint retrieves the user’s email from the request body and makes use of the frontendDomain you already defined in the file to send a magic link to the user with the redirect link that brings them back into the app when the authentication is complete.

Paste the following code in the app.js file for the /api/auth/callback endpoint:



This endpoint is called by the frontend when a user clicks the magic link in their email and opens the app. It collects the token generated as part of the email magic link process and authenticates the user with it. It also saves the intermediate session token in the cookies for use in later auth process steps.

Paste the following code in the app.js file for the /api/discovery/create endpoint:



This endpoint lets users create a new organization. It collects the intermediate session token from the cookies and the organization name and MFA policy from the request. Then it creates the organization using the stytchClient.discovery.organizations.create method and makes the organization accessible to other users with emails on the same domain. It also marks the current user as an admin in the organization.

Next, the endpoint proceeds to log the current user in. Ideally, the user should automatically be logged in if the organization doesn’t enforce MFA. If the user is not logged in automatically (ie the session_jwt is empty), it redirects the frontend to the SMS verification page.

Paste the following code in the app.js file for the /api/discovery/get-organization endpoint:




This endpoint retrieves the details of an organization and the currently logged-in member using the organization ID and the member’s email to populate details in the dashboard.

Paste the following code in the app.js file for the /api/discovery/select-organization endpoint:



This endpoint allows users to select one organization and log into it. It starts by verifying if an intermediate token exists and then uses the organization ID to authenticate the user (using the stytchClient.discovery.intermediateSessions.exchange call). If the organization does not enforce MFA and the user hasn’t opted into MFA, the user is directly authenticated and redirected to the dashboard. Otherwise, the user is redirected to the SMS verification page for MFA.

Paste the following code in the app.js file for the /api/mfa/send endpoint:



This endpoint retrieves the organization ID, member ID, and the user’s phone number in E.164 format (eg “+12223334444”) to send them an OTP on their phone for verification. Make sure that you understand how Stytch bills you for sending international OTPs and that your users don’t fall in one of the unsupported countries. The next step would be to authenticate the users using the code that they received.

Paste the following code in the app.js file for the /api/mfa/authenticate endpoint:



This endpoint authenticates a user using their intermediate session token, organization ID, member ID, and the code that they received on their phone. Once done, the authentication process is complete, and the user can now be redirected to the dashboard. Now, the only major task left is to allow users to change their MFA opt-in status.

Paste the following code in the app.js file for the /api/mfa/update endpoint:



This endpoint allows users to update their MFA opt-in status.

Please note that this is applicable only for organizations that allow users to enroll for MFA optionally. So you need to verify that your organization has an OPTIONAL MFA policy. In this demo app, this has been done on the frontend in the dashboard.jsx file to avoid unnecessary backend calls:



The use of a conditional expression ensures that the option to change the MFA opt-in is only available to users whose current organization has an OPTIONAL MFA policy.

Finally, add an endpoint that allows users to log out. For that, paste the following code in the app.js file for the /api/auth/logout endpoint:



At this point, you’ve finished setting up your endpoints. You can refer to the complete code of this file on the GitHub repo for reference. It’s time to see the app in action!

Watch the App in Action

To see your project in action, you need to start both the backend and the frontend apps in separate terminal windows.

For the backend app, you can use the following command:



For the frontend app, use this command:



To try out the various authentication scenarios, you need to create two organizations in your Stytch project and set the MFA policy of one of the organizations as OPTIONAL and the other one as REQUIRED_FOR_ALL. To do that, head over to the Organizations page on your Stytch dashboard and click on the white + Create new organization button on the top right:



On the New Org page, enter the name of your organization along with a slug that you can use in your app to create customized URLs (ie org-1.yourapp.com and org-2.yourapp.com) for the organizations. You also need to choose whether you want to enforce MFA for all users by turning on the Require MFA option:



When creating a new organization, you can also configure other options, such as allowed authentication and MFA methods, email domain settings, and just-in-time (JIT) provisioning. When done, make sure you save your changes.

Following a similar process, create another organization that enforces MFA for all its members. When you’ve finished, it’s time to test out the authentication flows you developed in your project.

For an organization that doesn’t enforce MFA (and the member hasn’t opted in), the authentication flow looks like this:



When the MFA is either enforced or opted in, your authentication flow looks like this:



And finally, this is how you can toggle your MFA opt-in status if your organization allows it:



This organization allows users to opt in for MFA. Initially, the user had opted in for MFA and had to go through the complete authentication process. However, after opting out, the user didn’t need to complete SMS verification anymore.

The Stytch SDK allows you to do so much more than just MFA. You can also provision users through single sign-on (SSO) or JIT and configure granular roles and permissions for your users as well. Make sure to explore their other guides to learn about everything that Stytch offers!

Conclusion

MFA is no longer an option—it’s imperative. In this article, you learned all about MFA and its use cases, from finance to personal accounts, and the crucial distinction between enforced (organizational mandate) and enrolled (individual opt-in) approaches.

You also saw how Stytch shines when it comes to implementing MFA. With support across platforms, including Node.js, Go, Python, and Ruby, and frontend platforms, including React, React Native, iOS, and Android, Stytch can help you quickly get started with MFA. If you’re interested in learning more, check out the Stytch official docs.







---


# CAPTCHA vs. reCAPTCHA: What’s the difference?
Source: https://stytch.com/blog/captcha-vs-recaptcha-whats-the-difference/

This article delves into the nuances of CAPTCHA and reCAPTCHA, explaining their shared functionality as well as their distinctions, shortcomings and evolution to combat sophisticated threats in the AI era.

As virtual worlds continue to expand, online interactions are increasingly replacing their in-person counterparts. As such, safeguarding websites and apps against fraudsters seeking to impersonate our digital identities is more crucial than ever.

CAPTCHA and reCAPTCHA are popular authentication technologies for such protection against automated spam and malicious bots – two of the most pernicious forms of digital fraud. These internet identity defense mechanisms can distinguish between human users and malicious bots to halt the growing threat of identity theft and account takeovers.

This article delves into the nuances of CAPTCHA and reCAPTCHA, explaining their shared functionality as well as their distinctions, shortcomings and evolution to combat sophisticated threats in the AI era.

From CAPTCHA to reCAPTCHA: History and evolution

CAPTCHA stands for “Completely Automated Public Turing test to tell Computers and Humans Apart.” At its core, it’s a system designed to prove that a user of a web service is human and not a bot. CAPTCHAs challenge users to complete tests that are usually simple for humans but complicated for automated bots, effectively blocking many types of bot attacks.

A step beyond CAPTCHA, reCAPTCHA is an enhanced iteration of traditional CAPTCHA technology that improves accuracy and the user experience while maintaining robust bot protection. Originally created by researchers at Carnegie Mellon University and later acquired by Google, reCAPTCHA is a ‘smarter’ and more user-friendly form of its predecessor that leverages advanced risk analysis techniques to present challenges that adapt based on user interaction with a web page or app.

There are various CAPTCHA services available, such as hCAPTCHA, Cloudflare Turnstile, and Friendly Captcha, each offering different approaches to user interaction and privacy. For the purposes of this article, we’ll focus specifically on the differences between CAPTCHA and reCAPTCHA.

How CAPTCHA Works

The central idea of CAPTCHA involves presenting a cognitive or sensory CAPTCHA challenge that humans can pass with little effort but poses a significant hurdle for bots. Visual challenges, like identifying specific objects in images and manual image recognition tasks, are commonly used to distinguish between human and bot traffic. The idea is simple – if a bot can’t read or interpret distorted text, it will not be able to pass the test.

These challenges often include:

Visual puzzles (e.g. recognizing distorted text)



Identifying objects in images



Solving simple math problems



For example, users may be asked to identify a sequence of letters and numbers from an image that is intentionally distorted with noise and lines. Humans can easily recognize the characters despite the distortion, whereas many bots were not historically programmed to be able to do this.

Beyond text and image recognition challenges, CAPTCHAs have expanded to include a variety of challenges like audio CAPTCHAs, which are crucial for accessibility, allowing users with visual impairments to authenticate themselves via sound tests. Additionally, unlike reCAPTCHA, CAPTCHA can include puzzles that require users to match objects or identify patterns in images.

CAPTCHA’s fallibility and the birth of reCAPTCHA

The original CAPTCHA was created in the year 2000. Its evolution to the more advanced and user-friendly Google reCAPTCHA, starting in 2007, is a story of the natural growth in complexity of the internet.

The reCAPTCHA system was developed as an attempt to improve traditional CAPTCHAs in the face of more sophisticated threats. While CAPTCHAs have proven effective at blocking bots from filling out forms and spamming websites, they can still be bypassed by more advanced bots. For example, attackers have been able to use machine learning algorithms to train their bots to solve common types of CAPTCHAs, leading to an environment where each side must continually outsmart the other.

As expected, this constant arms race between the new methods of attackers and new forms of CAPTCHA technologies have led to more complex challenges, resulting in frustration and friction for users. This pain point is especially significant for users with disabilities or those using assistive technologies, for whom extensive and complex CAPTCHAs have made it difficult to easily access and use websites.

A bot blocker with better UX

First introduced in 2007, Google’s reCAPTCHA was a true game-changer. It not only enhanced the bot detection algorithms but also significantly improved user experience by reducing the complexity of challenges for most users. In fact, in 2012, Google’s reCAPTCHA was updated to entirely eliminate the need for users to type text, deploying a simple “I’m not a robot” checkbox (thanks, Googlers!).



As far as bot detection, the new reCAPTCHA system was far more intuitive, analyzing user interactions and other data with machine learning algorithms to determine whether a human or bot was attempting to access the webpage. In step-up authentication fashion, additional challenges such as image recognition tasks were presented when necessary if suspicious or bot-like behavior was present.

reCAPTCHA’s advanced algorithms are designed to combat sophisticated bots that can bypass traditional CAPTCHA challenges during bot attacks. It was designed to provide an unobtrusive user experience for most genuine users and only escalate to more challenging tasks when necessary.

As a result, reCAPTCHA was able to achieve an improved bot detection rate of 99.9% while maintaining an impressive user approval rate of over 97%, according to Google.

Aside: Stytch Strong CAPTCHA improves upon reCAPTCHA technology by taking anti-fraud technology even further. It removes the public site key entirely from the end user’s browser environment making it architecturally impossible for CAPTCHA farms to solve, providing robust protection against automated bots and third-party solving services. Learn more, here.

Invisible reCAPTCHA

While the “I’m not a robot” checkbox may have been a significant improvement in terms of user experience, it still required some level of user attention and interaction. In response in 2017 (in typical Google fashion), the company removed this arguably minimal user friction altogether with an update called “Invisible reCAPTCHA”. This enhancement eliminated the need for any user interaction at all, providing a completely frictionless experience for human users while still effectively detecting bots.

Since then, there have been even further advancements in CAPTCHA technology, including biometric-based challenges such as voice and face recognition, making the process even more seamless for human users. Undeniably, this shift towards invisible and biometric-based CAPTCHA systems highlights the importance of user experience in modern CAPTCHA solutions.

CAPTCHA vs. reCAPTCHA: Breakdown of notable differences



reCAPTCHA privacy concerns and future outlook

The evolution from CAPTCHA to reCAPTCHA hasn’t been without certain drawbacks. While reCAPTCHA is effective in enhancing security and UX, it has raised concerns regarding privacy due to the amount of data it can collect. This includes IP addresses, cookies, and site interaction specifics, which, while used primarily for security purposes, can lead to privacy issues – particularly under stringent regulations like the GDPR in the EU.

The various CAPTCHA services handle privacy and data collection in different ways, with some like hCAPTCHA and Friendly Captcha emphasizing privacy compliance and minimal data collection. Google reCAPTCHA on the other hand sits at the higher end of data collection and aggregation to provide an optimal experience. Google has made efforts to minimize the amount of data collected through reCAPTCHA, including implementing a new version called “reCAPTCHA Enterprise” that does not collect any personal data. Nevertheless, it’s still important for website owners to carefully consider and disclose the use of reCAPTCHA on their sites to ensure compliance with privacy regulations.

reCAPTCHA at an inflection point?

Google has had to continually reinvent reCAPTCHA to stay apace. As mentioned, Google’s original reCAPTCHA, released in 2007, used distorted text images as challenges to differentiate between humans and bots. In 2014, reCAPTCHA v2 introduced the “I am not a robot” checkbox, followed by image recognition tasks if further verification is needed. V2 became widely used due to its simplicity and effectiveness in distinguishing between human users and bots based on their interactions with the checkbox and subsequent challenges. Nevertheless, there were still concerns regarding user privacy and a cumbersome experience, as well as the amount of data being collected.

Overall, the evolution of reCAPTCHA shows an ongoing effort by Google to provide effective bot protection while also considering user experience and privacy concerns. As technology continues to advance, it is likely that reCAPTCHA will continue to evolve in order to stay ahead of the ever-evolving tactics used by bots.

With invisible reCAPTCHA and beyond, as well as impending advancements in machine learning and artificial intelligence, it is possible that future versions of reCAPTCHA shipped by Google will be even more efficient – and, fortunately, Googlers aren’t the only ones leading the charge.

Stytch Strong CAPTCHA

Google’s reCAPTCHA has undoubtedly set the bar high for what’s possible with CAPTCHA in reducing and preventing malicious traffic on the web. But what’s become clear in an increasingly mobile, multi-device world is that fraudsters will stop at nothing to find the latest loophole.

Stytch Strong CAPTCHA takes the security measures of modern reCAPTCHA further by making it architecturally impossible for CAPTCHA farms to solve or directly generate solutions using attacker preferred, easy-to-use API pathways. Strong CAPTCHA is functionally incompatible with how most image captcha solver services work today because we have removed the public site key entirely from the end user’s browser environment. Without direct public-key access, malicious bots can no longer use these services to easily get through CAPTCHA challenges, strengthening the line of defense between a given site and bad actors.

Stytch Device Fingerprinting

Stytch Device Fingerprinting (DFP) adds an innovative layer of security to Strong CAPTCHA by analyzing unique device characteristics during login or any sensitive web action. By detecting anomalies in device behavior that deviate from typical user patterns, Stytch DFP can identify potential bot activity. When suspicious indicators are detected, Stytch DFP can selectively trigger CAPTCHA, reCAPTCHA, or Strong CAPTCHA challenges, thereby adding an additional measure of security. This selective triggering not only enhances security by preventing automated access but also improves the user experience by not burdening legitimate users with unnecessary challenges.

Stytch DFP ensures that security measures are adaptive and specifically targeted, making the defenses more dynamic and efficient. This approach helps maintain the balance between robust security and user convenience, effectively safeguarding against bots without disrupting the user experience.

To learn more about how Stytch Strong CAPTCHA, DFP or other authentication solutions can work for you, reach out to an auth expert to start a conversation.







---


# What is SCIM and how does it work?
Source: https://stytch.com/blog/what-is-scim-and-how-does-it-work/

In this article, you’ll learn about the SCIM protocol and how SCIM auto-provisioning works. We’ll explore some examples and use cases of the protocol, and discuss how you can implement SCIM as an enterprise SaaS provider without wasting valuable engineering time and resources.

SCIM (System for Cross-domain Identity Management) is an open HTTP–based protocol that specifies a standard schema and architecture for managing identity resources across multiple domains.

At its core, SCIM simplifies the bidirectional exchange of user and group resources between identity providers (IdPs) and cloud-based service providers (SaaS applications) by providing a RESTful SCIM API that can be used to perform CRUD operations on these resources.

In this article, you’ll learn about the SCIM protocol and how SCIM auto-provisioning works. We’ll explore some examples and use cases of the protocol, and discuss how you can implement SCIM as an enterprise SaaS provider without wasting valuable engineering time and resources.

What is SCIM provisioning?

In enterprise organizations that don’t use SCIM, managing user and employee access can be a very manual and herculean task. When a new employee joins the company, HR and IT administrators have to manually assign their roles and access permissions across a multitude of tools and platforms.

This process becomes increasingly complex as the number of internal and external systems grows, often reaching hundreds or even thousands in larger enterprises. To further complicate things, each employee typically needs to maintain separate login credentials for each tool they access.

This not only creates a poor and cumbersome onboarding experience for new joiners but also poses security risks when employees leave the organization. IT departments have to invest significant time and effort into revoking access rights and removing user data from every single platform to ensure the off-boarded employee can no longer gain entry.

SCIM addresses these challenges by enabling organizations to maintain a centralized repository or single source of truth for all identity resources. Using the SCIM protocol, IT administrators can automatically provision, update, and de-provision employee resources using JSON formatted payloads that are communicated between SCIM clients and service providers.



Whether it’s onboarding a new team member, updating an existing employee’s email address or role, or offboarding a departing employee, SCIM makes it possible to handle these tasks programmatically, saving valuable time and reducing the risk of errors.

The SCIM provisioning process is straightforward: when a user is provisioned onto an application, the identity provider (IdP) exchanges key attributes such as the user’s name, email and a unique identifier with the respective service provider(s) over the SCIM API. The same process applies when a user’s identity is updated or de-provisioned, ensuring that all connected systems remain in sync with the central identity repository.

How does the SCIM protocol work?



The SCIM protocol, as defined by the IETF RFC 7644 standard specification, revolves around two main resources — Users and Groups. The Users resource stores identity data for each user, while the Groups resource defines the access groups, departments, or tenants a user belongs to, along with their corresponding level of authorization access.

To ensure consistency and interoperability in the way identity resources are described and maintained across different systems within the protocol, the SCIM schema defines the standard structure and attributes for “Users” and “Groups” resources. Each resource must adhere to a set of three required attributes (id, externalId and meta attributes) typically stored as name/value pairs in a JSON object.

SCIM also provides URL endpoints that identity providers (IdPs) and service providers can use to perform CRUD API operations on these resources and other entities defined within the protocol. These endpoints serve as the communication channels through which identity data is exchanged, enabling seamless synchronization across multiple domains.

In a typical SCIM setup, an organization’s identity provider (SCIM IdP), such as Microsoft Entra ID, Google Workspace, or Okta, acts as the SCIM client. These IdPs are responsible for storing and managing user identities, access permissions, and other relevant information within their respective identity directories.

On the other hand, the SaaS applications or internal systems that employees use to perform their daily tasks, such as Notion or Linear, are known as SCIM service providers. These applications consume user identity data provided by the SCIM client to ensure employees have the appropriate access and privileges within their respective environments.

When CRUD updates are made to a user’s identity, such as updating their department or role, the SCIM client (IdP) automatically synchronizes these changes to the connected service providers according to the SCIM protocol. In the same way, IdPs can also read user identity information from service providers and incorporate updates into their identity directory, ensuring both systems remain in sync and up-to-date.

Is SCIM a SAML or SSO alternative?

SAML (Security Assertion Markup Language) and SCIM are both open standardized protocols, but they serve unique purposes and are used in different scenarios.

SAML is primarily used for implementing single sign-on (SSO), enabling users to access multiple applications with a single set of credentials and eliminating the need to re-enter login information for each application.

SAML achieves this by exchanging authentication assertions between the identity provider (IdP) used within the company and the various service providers (SPs) used for work. The thing is, SAML SSO focuses on user authentication and doesn’t inherently require SCIM to function, as long as user identities are provisioned manually.

SAML can also be used to pass authorization data within security assertions, however, identity lifecycles would still need to be managed manually, because SAML doesn’t offer the same level of real-time identity synchronization and consistency as the SCIM protocol.

SCIM, on the other hand, doesn’t directly support authentication or SSO. Instead, it complements SAML by ensuring that multiple applications always have the most up-to-date information for each user who needs to gain access. For example, when a new user is added to the identity provider, SCIM can automatically propagate this information to all service providers that support SAML SSO, ensuring the user has the necessary access and permission levels whenever they need to authenticate.

When SCIM is implemented in an environment where SAML SSO is used, it can automate user provisioning, de-provisioning, and synchronization of user attributes across all connected applications that users access via SAML SSO.

By using SCIM to programmatically manage identity resources, while leveraging SAML for user authentication, organizations can maintain a centralized identity management system that not only simplifies user logins via SSO but also ensures that user attributes are securely and consistently managed throughout their lifecycle.

Why and when should you implement SCIM?

As we have seen thus far, the most compelling reason to adopt SCIM as a large enterprise is that it enables your IT and security departments to maintain accurate and up-to-date identity resources across all connected systems. This reduces the risk of data inconsistencies and potential security breaches, without the need for unnecessary manual work.

As such, if you’re a SaaS provider catering to large enterprises, providing out-of-the-box support for the SCIM protocol is mostly non-negotiable. It eliminates stress for the IT administrators who would otherwise need to manually onboard hundreds or even thousands of users onto your application.

For newer B2B SaaS startups, supporting SCIM can significantly increase your chances of closing deals with large enterprise clients. This can also drive early adoption and product usage because these large companies can automatically onboard their employee base in one go, thereby encouraging widespread use very early on.

Building SCIM in-house vs using Stytch

When implementing the SCIM protocol, engineering teams can choose to build a custom SCIM connector in-house or leverage an out-of-the-box SCIM connector like Stytch.

The downside with building a custom SCIM implementation is that it’s never worth the resources and time your team will expend, especially if you don’t have the size or scale of a Google or Microsoft.

If you choose to implement SCIM in-house, you must be prepared to handle the complexities of integrating with all the identity providers that your current and potential customers may be using within their companies.

The reality is that every IdP has a different implementation approach to how they map attributes and integrate with the SCIM protocol. As such, you’ll need to figure out how IdPs like Okta, OneLogin, Entra ID, JumpCloud, and Google Workspace all map resource attributes and perform CRUD operations using the SCIM API, and also ensure your application can securely handle each provider.

By leveraging the SCIM base connector URL provided by Stytch, enterprise applications can effortlessly configure their IdP and connected service providers to send and receive SCIM updates without the need for an in-house SCIM implementation.



We can also receive SCIM requests from your IdP, and immediately effect the requested updates on our end, whether it’s to revoke an active session, assign a new RBAC role, or even update a Member object.

Another compelling reason to use a SCIM provider like Stytch is that we support other open industry protocols such as SAML, OIDC, and OAuth. With Stytch, these protocols can be implemented in a matter of days, as opposed to the months or even years it would take for an in-house implementation.

Want to learn more about Stytch’s APIs and SDKs? You can check our docs and sign up for a free developer account to start building today.

If you want to learn more about our Enterprise features and pricing, feel free to schedule a call with any of our Solutions Engineers.







---


# Application security in the age of artificial intelligence: adapting to new challenges and opportunities
Source: https://stytch.com/blog/application-security-in-the-age-of-ai/

Recent leaps in AI technology may be exciting for consumers, but they're equally exciting for hackers. Learn how to protect your product.

Introduction

As AI continues to transform the digital landscape, organizations must remain vigilant and adapt their application security strategies to address new threats and opportunities. By understanding the implications of AI on identity and access management (IAM) and taking proactive measures, businesses can stay ahead of the curve and protect their digital assets in an increasingly interconnected world.

AI-fueled risks include more sophisticated bot traffic, more believable phishing attacks, and the rise of legitimate AI agents accessing customers’ online accounts on behalf of users. In effect, applications will need to gain confidence in their ability to do the following:

Accurately discern human vs. bot traffic (made more difficult in a world where CAPTCHA and JA3 for TLS fingerprinting are effectively broken)

Detect whether bot traffic is malicious or user-directed via an autonomous AI agent

In this article we’ll take a look at the main threats to cybersecurity posed by recent advances in AI, and provide concrete actions companies can take today to protect their applications and customers.

Table of contents

AI today - what’s so different now?
Threat I - Reverse engineering
Threat II - More sophisticated phishing attacks
Threat III - Outdated access management models
What you can do

AI today - what’s so different now?

Even if you’ve heard of or even tried ChatGPT, it can be hard to sift through the media chatter to understand the real risks and real promises of this technology. At a CIAM company like Stytch, we’re far less concerned about a possible Hal or Blade Runner scenario, and much more concerned about what happens as the advances of AI become available to human beings already in the business of fraud and hacking.

While there’s quite a bit of nuance to how different kinds of AI tech are improving today, the crux of the issue from a cybersecurity perspective comes down to developments in sophistication and availability. 

Sophistication

If you’ve caught the pope sporting some pretty pricey threads or gotten a strange voicemail from a close friend or relative, this larger point may be self-evident. But the past decade has given AI scientists both the time and resources to sharpen their deep learning models, paired with vastly greater computer power. As a result, AI has gotten, well, impressively good. While there are of course areas where AI still has room to improve, the gap between the output a computer and a human can generate has gotten much smaller. 

Availability

AI technology is more widely and openly available for anyone to try than it ever was before. This is true on two fronts: both that there are more consumer AI products on the market (think ChatGPT) that anyone can try using, and with the advances in this technology there’s been a proliferation of startups and companies that rely on or advertise AI as a core differentiator. As of 2023, the number of AI companies in the world has doubled.

Like with other technological developments, if you see legitimate industry leaders getting excited about a new development, you can be sure hackers and fraudsters are paying attention too.

Let’s look closer at what precisely the risks are, and why they’re so urgent to address.

Threat I - Reverse engineering

While a lot of the initial discussion around AI and cybersecurity focused on how hackers may use AI tools to better imitate human behavior, many are also interested in the sheer computing power exposed by legitimate AI applications that make their resources publicly available.

How this works

Historically, whenever a resource has been made available online, cybercriminals will seek methods to exploit it if there are sufficient financial incentives. Namely, hackers reverse engineer sites to piggyback on open resources, allowing them to automate and scale the reach of their attacks or fraudulent activity quickly and easily.

Past resources hackers have exploited include:

Credit Card + Bank Credentials
Stripe and Plaid offer API endpoints that validate credit card numbers and bank account details, which are then targeted by attackers to conduct account validation attacks so that the accounts can ultimately be taken over and drained of their funds.

SMS messaging
In Twilio’s case, cybercriminals engage in SMS toll fraud to send costly SMS traffic via partner mobile network operators (MNOs) internationally and split the earnings with them. Customers using Twilio’s services outside of North America are at particularly high risk of seeing an eye-popping bill when this takes place, and Twilio goes so far as providing docs on how customers should protect their apps. 

Compute resources
Companies like Replit, AWS, Github, Railway, and Heroku deliberately expose valuable compute resources as part of their product offerings to developers, but this also makes them prime targets for attackers looking to steal free computational power. To quote the Railway CEO, it’s “frankly outrageous number of bad actors trying to spam free compute from our service.”



A Twilio diagram describing the fraud ring involved in SMS toll fraud (aka “sms pumping”).

Increased risk for AI

With the rise of open AI resources over the past couple of years, this last kind of compute resource attack has become especially profitable. In this model, bots piggyback on an application’s AI resources using a man-in-the-middle approach. Attackers then sell access to the API outputs to a third party while leveraging a legitimate application’s API pathways to avoid paying for the AI APIs.

There are four main aspects to AI specifically that make this compute resource exploitation so attractive:

Cost of resource: AI APIs are costly, making them valuable targets for attackers seeking to exploit their output.

Fungible output: The output from AI API requests is both fungible and accessible client-side, allowing attackers to use reverse-engineered AI endpoints to complete custom tasks and collect responses from the abused application. This differs from other APIs like SMS messaging or financial credential validation.

Rolling availability: The latest large language model (LLM) APIs are released on a rolling basis, incentivizing reverse engineering for early access. For example, GPT-4 API access is limited, encouraging those without access to reverse engineer it via a company granted early access by OpenAI or other providers of similar LLM APIs.

Higher monetization potential: AI endpoints have a higher total monetization potential for fraudsters compared to compute, financial validation APIs, or SMS messaging. They share a unique combination of valuable elements from each API attack surface: as fungible as compute, soon-to-be exposed by as many apps as SMS endpoints or payment APIs, and as defenseless as SMS endpoints (since AI APIs are integrated directly via the backend, lacking large company client-side protection against bots).

In other words, the same computing power that makes a search engine like You.com impressive or a productivity tool like Tome so helpful for a non-malicious user is equally available and perhaps more attractive for illicit purposes.

If you doubt the temptation of open AI resources, just look into GPT4Free. Just last week, this GitHub project dedicated to reverse engineering sites to piggyback on GPT resources accumulated 15,000+ stars on GitHub in just a few days. If over 15,000 developers saved this repository in just a few days, it’s daunting to imagine how many fraudsters might attempt to use it in the course of the coming months or year.



GPT4Free is an open-source project that reverse engineers LLM APIs in order to provide users with free access to AI capabilities by piggybacking on sites that pay for their usage.

Threat II - More sophisticated phishing attacks

If you find it uncanny how human-like AI can seem, either with audio, visuals, or text, you can be sure those imitative capabilities have also caught the eye of hackers. Namely, AI today accelerates three major “developments” along the phishing attack vector: believability, efficiency, and scale.

1. Complexity and believability

Aided by AI, phishing is already becoming much more complex and believable when it comes to the linguistics and visual interfaces generated by attackers to deceive users. Cybersecurity firm Darktrace saw the linguistic complexity jump in phishing emails nearly 20% in Q1 2023. Additionally, 37% of organizations reported deep fake voice fraud attacks and 29% reported deep fake videos being used for phishing. 

As the cost of building a fake landing page and login portal plummets ever lower, security experts expect attackers’ sophistication in spinning up convincing sites to continue to rise.

2. Efficiency and affordability

Fraudsters are continuing to chase efficiency and scalability in their attacks. In the case of phishing, this means turning to programmatic ways to bypass MFA defenses.

In addition to generating phishing campaigns and sending them programmatically, attackers are also employing bots more frequently to automate the actual validation of phished 2FA codes (e.g. OTP, TOTP) in real-time. To achieve this, attackers operate low-volume bots that appear normal traffic-wise to applications (after all, there’s a real user on the other end) and submit the stolen codes to the phished application. Doing so eliminates the need for fraudsters to employ humans to perform this action and ensures stolen credentials aren’t stale.



As an example, Microsoft Threat Intelligence researchers recently discovered a phishing kit that is behind more than 1 million malicious emails daily and can bypass multi-factor authentication (MFA) systems using time-based one-time passwords (TOTPs). The kit, which sells for $300 (standard) or $1,000 (VIP), includes advanced features for deploying phishing campaigns and evading anti-phishing defenses. The technique, known as Adversary in the Middle (AitM), places a phishing site between the targeted user and the site they are attempting to log in to, capturing TOTPs in real time. The phishing kit also uses features such as CAPTCHA and URL redirection to bypass automated defenses and block lists. 



Diagram courtesy of Microsoft's Threat Intelligence team and their research on phishing kits

Security experts have long lauded MFA methods like OTP and CAPTCHA is important prophylactics against phishing attacks, so the ability of fraudsters to get around these blockers proves that greater protection will soon be needed on a global scale.

3. Scale and ROI

As phishing attacks become both trivial to generate with AI and much more believable, this also changes the cost-benefit analysis behind how attackers choose who to target.

We often mock the errors found in phishing schemes because they seem obvious to the discerning user. However, these typos have traditionally been a feature (not a bug) for attackers – they’re intentional and designed to weed out more intelligent targets so that attackers are more likely to hear back from only the most gullible of victims. 

This design choice derives from phishing’s historically manual and human labor-intensive architecture: historically, hackers have needed real people to continue the conversation with potential victims to convince them to forward their password or MFA passcode. With this very real labor constraint, attackers have been forced to find clever ways to increase their probability of success, and focus their efforts only on targets they feel like both offer a high probability of success and offer sufficient reward. 

Unfortunately, conversational-level AI like ChatGPT changes this cost benefit analysis drastically. Without human labor as a constraint, we can expect a sharp uptick in the number of phishing attempts and the sophistication of those conversations, as fraudsters may abandon the typo strategy and generally target a much wider audience with far more believable attacks.

Threat III - Outdated access management models

The last major change we’re seeing from AI is the most nascent but also potentially the most fundamental shift for every application’s authentication strategies: the emergence of AI agents.

AI agents are designed to browse the web and perform tasks on behalf of users. In terms of benefits, these agents promise to eliminate tedious tasks in users’ personal and professional lives. In some ways, they’re like a more intelligent form of robotic process automation (RPA). But instead of requiring specific instructions, users can provide general directions, and the AI agent can problem-solve to fulfill the request.

This not only increases efficiency for end users but also brings significant advantages for businesses. AI agents can become adept at navigating unfamiliar user interfaces, reduce the customer support load for apps, and as a result, increase the likelihood of consumer or organizational adoption because users don’t have to learn the nooks and crannies of every app’s UI that they want to use. It’s no wonder agents like AutoGPT have been growing in popularity over the past couple of months.



The AutoGPT project is one of the fastest Github projects to 100k+ stars in history, and it has the potential to dramatically change how users and businesses interact with applications.

At the same time, AI agents also introduce an entirely new set of risks for applications to manage. Most consumers and businesses may not want these agents to have unrestricted access to all their application settings due to their autonomous nature. An AI agent could mistakenly delete crucial profile information, sign up for a more expensive subscription than intended, expose sensitive account access data, or take any other number of self-directed actions that harm the user, the application, or both parties. As of today, companies’ authentication and authorization models still have to catch up to these new kinds of divisions of labor.



ChatGPT now has a version with browsing capabilities in alpha access

What’s to be done

With the pace of AI advancement showing no signs of slowing down, it may feel daunting to think about the implications for your individual product. 

Fortunately, there are already tools out there that can help combat fraudulent use of AI – devs just have to know what capabilities to prioritize. To prepare their application’s security model in the age of artificial intelligence, engineers should consider the following:

Invest in advanced fraud and bot mitigation tools that can detect reverse engineering to protect AI APIs from unauthorized access and abuse.

Prioritize phishing-resistant authentication methods, such as biometrics or YubiKeys, to safeguard against more sophisticated and believable phishing attacks.

Modernize their authorization logic and data models to accommodate the rise of AI agents, differentiating between actions that require human intervention and those that can be executed autonomously.

1. Invest in advanced fraud and bot mitigation

To mitigate these risks, organizations should invest in advanced fraud and bot mitigation tools to prevent reverse engineering of AI APIs. Common anti-bot methods like CAPTCHA, rate limiting, and JA3 (a form of TLS fingerprinting) can be valuable in defeating run-of-the-mill bots that have little incentive to invest in evading these protections. But for more sophisticated bot problems like those facing AI endpoints, these common methods are easily defeated. Attackers with any moderate sophistication can defeat these methods:


Defeating CAPTCHA: Attackers use services like https://anti-captcha.com/ to cheaply outsource the solving of CAPTCHA challenges via a mechanical turk style system.

Defeating rate limits: Attackers route traffic through residential IPs via services like Bright Data, churn their user agents, and leverage less detectable headless browsing techniques

Defeating TLS fingerprinting (JA3): Chrome’s latest changes make this significantly less valuable for defending your app against bots

Protecting against reverse engineering requires more sophisticated tooling. More advanced options include custom CAPTCHAs via Arkose or javascript fingerprinting tools like FingerprintJS.

There are of course many device fingerprinting solutions to choose from, but there are a few differentiators we’ve invested in at Stytch that are particularly effective at mitigating AI-driven attacks:

Our DF solution combines hardware, network, and browser-level fingerprinting with the massive volumes of authentication data we have visibility into as a CIAM platform.

While other fingerprinting tools use native javascript, which is itself more susceptible to being reverse engineered and defeated by those abusing your site, we use web assembly for a best-in-class approach to prevent reverse engineering.

We use full at-rest encryption internally with on-the-fly runtime decryption on payload execution for all critical collection logic. We have also built a significant amount of tamper-resistant and tamper-evident features into our solution via cryptographic signing, which ensures that if our payload internals are tampered with, the results won’t be accepted by Stytch servers for access.

Our tool was built from the ground up by professional reverse-engineers who used to build and sell commercial reverse-engineering tools in their previous roles. They’ve designed our product to be painful and vexing in ways they know from prior experience would have made them throw their hands up had encountered it in a reverse engineering attempt.

Whether you invest in Stytch’s product or decide on a competitor, the most important takeaway here is that organizations that prioritize detecting and stopping reverse engineering will be better equipped to protect their AI-powered applications against malicious actors.

2. Prioritize phishing-resistant authentication methods

The best way to counter these types of account takeover attacks is to invest in phishing-resistant MFA. Unlike one-time and time-based passcodes, phishing-resistant methods like WebAuthn can’t be accidentally forwarded along to an attacker, making it a valuable security measure in the face of AI-generated phishing emails and websites. WebAuthn includes two distinct categories of device-based authentication factors that help confirm a user’s identity:

Device-based biometrics, such as TouchID and FaceID, belong to the “something-you-are” category.

External hardware keys, like Yubikey, belong to the “something-you-have” category. These authentication factors involve a physical security key that is connected to the user’s device for verification purposes.

With the increasing sophistication of phishing attacks, organizations should prioritize integrating phishing-resistant authentication methods. And if your organization isn’t yet ready to adopt to these more advanced MFA methods, the best defense is a fine-grained bot detection layer. In the above diagram, steps 2 and 6 require fraudsters to proxy user inputs from a fake application to the phished application and can be thwarted by investing in a fingerprinting approach (like Stytch’s) that can detect proxied traffic that otherwise appears to be normal.

3. Modernize their authorization logic and data models

To address these challenges, companies must adapt their permission and access control models to accommodate these well-intentioned bots. It’s crucial to establish fine-grained role-based access controls (RBAC) to mitigate security concerns arising from autonomous AI conducting tasks unsupervised on behalf of real users. Businesses may need to require human-in-the-loop MFA for certain actions initiated by AI agents or restrict some access entirely to strike the right balance between convenience and security.

Want to chat about how AI might affect your customers?

Whether you’re building an AI company or reevaluating AI-driven attack vectors that might affect your application, we’d love to chat. Let’s talk about how Stytch can secure your product. 

---


# Webhooks security best practices
Source: https://stytch.com/blog/webhooks-security-best-practices/

In this article, we’ll explore the most common webhook security best practices for handling webhooks in production.

There are several reasons why webhook deliveries fail. It could be due to request timeouts, server errors from the receiver’s end, or even an expired SSL certificate.

There are also numerous reasons why webhook requests can be intercepted, or a webhook provider can be impersonated. The thing is, if you've ever handled webhooks at scale, whether on the provider or consumer side, you’re likely familiar with the complexities and potential cost of poor and insecure webhook implementations.

In this article, we’ll explore the most common webhook security best practices for handling webhooks in production. We’ll also explore our webhooks setup at Stytch, demonstrating how we use webhooks to provide a seamless auth experience for our customers.

Best practices for sending and receiving webhooks

If you're new to using webhooks, we have a separate article that covers the most common webhook vulnerabilities you need to plan for and the best ways to mitigate these security risks. You can find it here.

Now, let’s dive into the other best practices here.

SSL/TLS/mTLS encryption

Since webhook requests are transmitted over HTTP, which is a plain-text protocol, all data sent between the source and destination is easily readable by default. Attackers can intercept these messages and exploit any sensitive information they contain, such as authentication data or the payload data itself.

To mitigate this risk, it’s important to ensure that all webhook communication occurs over HTTPS, the secure version of HTTP. HTTPS encrypts all data transferred between the client and the server, making it much harder for attackers to interpret the information.

As the receiving web server (webhook consumer), you must install a valid SSL/TLS certificate to establish secure connections. This certificate provides security at the transport layer, ensuring all communication is encrypted and protected against various attacks, such as DDoS and Man-in-the-Middle attacks. Moreover, most webhook providers will only connect to secure HTTPS URLs with valid SSL/TLS certificates signed by a globally trusted certificate authority.

While SSL/TLS secures the communication from the webhook consumer’s end, mutual TLS (mTLS) takes security a step further by ensuring that traffic is secure and trusted in both directions.



With mTLS, both the webhook provider and the consumer must authenticate each other using their respective TLS certificates before a webhook message is sent. If either party fails to present a valid certificate, the authentication will fail, preventing unauthorized access and ensuring that sensitive information only reaches the intended recipient.

However, it’s important to note that mTLS can be challenging to configure and maintain, especially as your webhook infrastructure grows. Managing mTLS certificates and keys for multiple clients and webhook endpoints can become a significant burden, and lead to potential misconfigurations or certificate expirations.

For most use cases, signing the webhook payload is a more suitable alternative to mTLS because webhook signatures are simpler to implement and maintain. This approach involves creating a unique signature for each payload using a shared secret key. By including this signature in the webhook request, the consumer can verify the authenticity of the payload without having to deal with complex mTLS certificates.

Enforce secret and signature validation

To ensure the authenticity and integrity of requests, webhook consumers need to verify the sender’s identity before processing any request. Since webhooks are essentially HTTP POST requests, attackers can easily impersonate legitimate providers by sending fraudulent webhooks.

Most webhook providers mitigate this risk by signing each payload with a secret key and including the resulting signature in the request header. This signature allows the webhook consumer to verify the origin of a request before processing it or not.



This signature validation process typically involves the following steps:

When subscribing to a webhook on the provider’s dashboard, some providers allow the consumer to enter a custom secret token, as long as it’s a random string with high entropy. Alternatively, other providers allow the webhook consumer to automatically generate secret keys directly from their dashboard.

The webhook provider then uses this secret token to create an HMAC (Hash-based Message Authentication Code) signature of the payload using a hashing algorithm like SHA-256, and also includes this signature in the request header (“X-Provider-Signature”).

Upon receiving the webhook request, the consumer has to calculate the HMAC of the payload using the same hashing algorithm and the shared secret token. Afterward, they can then compare the calculated HMAC with the one received in the header. If the signatures match, the payload is considered legitimate and untampered.

Using HMAC signatures ensures the integrity of every webhook request and prevents unauthorized parties from sending legitimate requests without having access to the shared secret key. It’s more secure than using basic authentication methods because the shared secret is not transported with the request, offering an extra layer of security. However, webhook consumers have to securely store their secret keys and regularly rotate them to maintain integrity.

In addition to HMAC signatures, some webhook providers may use standard protocols like OAuth 2.0 (JWTs and JWKs) to protect the identity of their webhooks. In this approach, the webhook provider authorizes itself against an OAuth authorization server to issue access tokens, which must be validated by the consumer to ensure the request is legitimate.

Logging requests, failures and errors

Whether you’re a webhook provider or consumer, having a robust logging and monitoring system is the only way to find and fix webhook errors in real-time, especially in production. Logging webhook requests and responses create an audit trail that allows you to easily detect what must have gone wrong, where it happened, and make informed decisions on how to debug or investigate the incident.

A comprehensive logging system should record the most important information about each webhook request and response, such as the timestamps for each event, identity information (e.g., IP addresses, hostnames), HTTP status codes, and even error messages.

However, when logging sensitive requests, it's important to limit your log exposure by only showing HTTP status codes in user-facing logs and avoid displaying headers or body content that may contain confidential data.

On the other hand, webhook consumers must be prepared to handle scenarios where incoming webhooks fail, whether it’s due to malformed requests, invalid webhook URLs, or unexpected exceptions. When a webhook consumer encounters an error while processing a request, it's important to return the appropriate status code because providers rely on this status code to determine whether a webhook has been successfully processed or not.

For example, if a consumer returns a 2xx status code (which indicates success) instead of a 4xx or 5xx status code (which indicates an error), the provider may assume that the request was successfully processed and move on to the next webhook, and this can lead to data inconsistencies and missing events.

To mitigate webhook failures, most webhook providers have robust retry systems that can detect failures based on the status code received in the response and resend the failed webhooks according to a predefined retry schedule. By implementing proper error handling, robust retry systems, and comprehensive logging, webhook providers and consumers can ensure the reliability and integrity of their webhook infrastructure, even as the volume of webhook requests scales.

Using message queues and horizontal scaling

When you consume large volumes of webhooks in production, it's easy to exceed your server's capacity if you try to process all the requests simultaneously. If your server receives too many requests at once, it might shut down, and you won't be able to process any more webhooks that your core functionalities may rely on.

To avoid this problem, you can use a message queue that sits between the webhook provider and your server, acting as a buffer. It stores all incoming webhooks and sends them to your server at a rate that won't overload it.



You can set up message queues using tools like RabbitMQ, Apache Kafka, or Google PubSub. These tools allow you to create a robust and scalable queuing system that can handle high volumes of webhook requests. However, it's important to note that implementing a message queue adds an extra layer of complexity to your architecture. As traffic levels increase, you may need to scale your message queue infrastructure to avoid potential bottlenecks and ensure reliable delivery of webhook requests.

In addition to using message queues, horizontal scaling is another effective strategy for handling high webhook traffic. Horizontal scaling involves distributing your incoming webhook requests across multiple copies of your server. By placing a load balancer between the webhook provider and your server pool, you can evenly distribute webhook traffic using various load balancing algorithms, whether it’s round-robin, least connection, or weighted round-robin algos depending on your use case. This approach reduces the burden on any single server and allows you to process a larger volume of webhook requests concurrently.

While it's possible to build and maintain this infrastructure in-house, leveraging webhooks-as-a-service providers like Hookdeck or Svix can greatly simplify this process without you having to worry about writing code or maintaining the architecture. These services sit between your webhook provider and your processing server, queuing up requests and delivering them based on the load your API can handle. They also offer extra features such as request tracing, logging, webhook retries, and error handling, all accessible through an intuitive dashboard and APIs. By using a webhooks-as-a-service provider, you can benefit from a highly performing and scalable webhook infrastructure without the need to maintain complex queuing systems yourself.

How we use webhooks at Stytch

At Stytch, developers leverage our webhook functionality to keep their internal systems up to date with all the changes that occur in their Stytch accounts. As such, when you set up a webhook URL in your Stytch Dashboard, you can choose to receive all events or filter down to the specific events you need at any given time.



We've designed the naming convention of our webhook event types to be straightforward and informative, making it easy for development teams to understand the context and nature of the events they receive. Our webhook event types are composed of three segments: the origin of the trigger (source), the type of entity being acted upon (object_type), and the type of action taken (action).

These three segments combine to form our standard event type identifier that follows this structure: source.object_type.action. For example, direct.organization.create means an organization was created using our API or SDK, while dashboard.update.member means a member was updated using the Stytch Dashboard.



To start receiving webhooks, you need to navigate to the webhooks section in the Stytch Dashboard and click on "Add Endpoint." This is where you'll provide the endpoint URL that Stytch will use to send webhook events to your app. The endpoint you specify should be set up on your server to receive POST requests, as this is how Stytch will send the event payload. However, this feature is only available to Stytch customers who are on the B2B Pro tier or above.

Each webhook event sent by Stytch comes with a payload that contains all the necessary information that will help development teams process and act upon events effectively. The payload includes the Stytch ProjectID associated with the event, a unique UUID for the event itself, the type of action taken, the type of entity affected, the origin or source of the trigger, the UUID of the entity the action was performed on, and an ISO 8601 timestamp indicating when the event was sent by Stytch.

To start building authentication with Stytch, check out our documentation and sign up for a developer account. If you have any questions, please don't hesitate to contact us at support@stytch.com.





---


# Identity security: The key to access, compliance and trust in the digital era
Source: https://stytch.com/blog/what-is-identity-security/

Learn all about identity security, and how to leverage it to protect your app from malicious actors.

Identity security in practice involves deploying the technologies, policies, and procedures designed to protect digital identities—essentially, the digital representation of individuals or machines within a system. It ensures that only authorized users or the right entities have the appropriate access to technology resources at the right times and for the right reasons. This security domain encompasses various elements, including authentication, authorization, identity verification, and compliance with regulatory requirements​.

In this article, we'll cover the basics of identity security, its importance, and some best practices for implementing it in your organization.

What is identity security and why is it important?

Cybercriminals and fraudsters are constantly finding new ways to impersonate us. As our digital identity increasingly becomes our primary point of access to our most valuable assets and services, it’s essential for the applications we rely on to have strong identity threat detection security controls in place. At a base level, an effective identity security protocol must:

Support the integrity of our digital identities. Without protective measures to ensure someone is who they say they are online, collective chaos and rampant fraud would render our online ecosystems useless (and dangerous).

Protect organization and user data. Concurrently, for applications and organizations to thrive, business-critical information must only be available to the authorized individuals equipped and permitted to handle it safely. This helps prevent data breaches, insider threats, and other malicious activities.

Ensure regulatory compliance. Many industries, such as healthcare and finance, are subject to strict regulatory requirements for protecting sensitive data. Implementing effective identity security measures helps organizations comply with regulations within industries where it’s particularly needed.

Build trust with users. With the rise of online services and transactions, users need to have confidence that their personal information is safe and secure. Identity security helps maintain this trust by protecting user identities from cyber threats.

As virtual threats evolve, investing in an identity security solution that can adapt and scale is more crucial than ever. In the next section, we’ll cover the foundations of building and growing an identity security practice that can stand the test of time.

The foundations of identity security

To build effective identity security, SaaS companies should consider the following pillars as essential components of an enterprise identity solution.

Identity verification

Identity verification is a crucial component of the "know your customer" concept, focusing on confirming the authenticity of identity documents, histories, or attributes linked to the owner of an account, such as date of birth, address, passport, driver's license, social security number, or employee number. This process aims to strengthen security measures by verifying that individuals accessing a system are indeed who they claim to be, thereby minimizing the risk of unauthorized access to sensitive data and improving the dependability of the security protocol.

Authentication and access management

Authentication is the process of verifying a user's identity when they attempt to gain unauthorized access to a system. This is typically the first line of defense in identity security and can include methods like passwords, one-time passcodes, passkeys, and biometric scans. Multi-factor authentication (MFA), which requires two or more verification methods, is becoming a standard practice due to its enhanced security benefits​, and is increasingly a requirement for regulatory compliance across modern agile organizations.

Authorization

Once authenticated, authorization plays a crucial role in determining what resources a user can access and what they can do with those resources. This process involves setting and enforcing policies that define user permissions based on their role within the organization. Techniques such as role based access control re-based access control (RBAC) and attribute-based access control (ABAC) are commonly used to manage these permissions efficiently​.

Compliance

Regulations such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), and California Consumer Privacy Act (CCPA) mandate the protection of personal and sensitive data. Organizations must implement stringent identity security measures to ensure compliance with these laws, which often include guidelines on data encryption, user consent, and access privileges and timely breach notifications. Failure to comply can result in significant financial penalties and loss of trust from customers and stakeholders​.



Federated identity and access management

Federated identity management allows users to access multiple systems and applications across different organizational boundaries with a single set of credentials. This approach not only enhances user convenience but also simplifies the management of identities and reduces the risk of password reuse, which can lead to security breaches and identity theft​.

Federated identity management relies on trust between parties and uses standard protocols such as Security Assertion Markup Language (SAML) and OpenID Connect to enable secure communication between different systems. By implementing federated and identity management systems, organizations can improve security and identity related access risks, reduce administrative overheads, and support a seamless user experience​.

Identity providers (IdPs)

Identity Providers (IdPs) are services that create, maintain, and manage identity information while providing authentication services to multiple applications. By centralizing user access and authentication, IdPs help reduce the complexity of managing separate credentials for each service, thereby enhancing overall security posture​. Examples of IdPs include companies like Okta, Azure, Ping, Auth0, OneLogin, etc., and in more recent years also includes social media platforms such as Google, Facebook, and LinkedIn.. Organizations can also choose to set up their own IdP using tools like Active Directory or open-source solutions such as Keycloak or Shibboleth​ (IBM).

Identity security in the context of CIAM

Customer Identity and Access Management (CIAM) solutions are designed to securely manage the identities of customers accessing various online services. CIAM systems provide features such as session management, user management, authentication, authorization, multi-tenant SSO, and in Stytch’s case, fraud prevention. These identity and access management services are essential for enhancing customer experiences and complying with data protection regulations, and are critical for keeping your company and customer data safe​.

They’re also a pain to build on your own.

In the context of CIAM, what makes identity security important is that it plays a crucial role in an organizations ability to store and process sensitive information about their customers. Having a reliable and user-friendly CIAM provider has spillover benefits beyond just security, which is why so many companies choose to outsource these services to a third party.

1. CIAM builds customer trust

Effective CIAM solutions not only enhance security but also contribute to building trust with customers. By protecting against security threats and providing a seamless and secure user experience, organizations can demonstrate their commitment to protecting customer data. According to research from Gartner, this builds confidence among customers, resulting in increased trust and loyalty towards the brand​.

Furthermore, through features such as consent management, CIAM solutions empower customers to have more control over managing digital identities and their personal data, strengthening the ties between organizations and their customers.

2. CIAM helps maintain regulatory compliance

CIAM systems play a crucial role in enabling compliance with regulations by providing features such as privacy management, access controls and consent management. These capabilities allow organizations to meet the requirements set by laws such as GDPR and CCPA, thereby avoiding potential legal consequences. CIAM solutions also help with auditing and reporting, making it easier for organizations to track and monitor compliance efforts.

3. CIAM providers can evolve to meet changing consumer behavior

Consumer behavior and expectations are constantly evolving, especially when it comes to their digital lives. As customers become more technologically savvy, they expect a seamless and personalized experience across all touchpoints, including the login process. CIAM solutions have evolved to cater to these changing behaviors and expectations by offering features such as social login, single sign-on, and personalization, improving UX and increasing customer satisfaction and loyalty.

Aside: Developing a CIAM solution in-house involves significant investments in time, budget, and expertise – particularly in staying abreast of evolving customer identity trends. Partnering with third-party providers like Stytch can offer a quicker, more cost-effective route to secure customer identity management, offering a ready-to-go suite of developer tools (such as OAuth social logins and Single Sign-On), backed by industry-leading compliance. Learn more about CIAM with Stych.

Technology and tools to consider

Implementing identity security successfully begins with strong authentication measures, adopting a zero trust security model, and leveraging artificial intelligence (AI) and machine learning (ML) for better threat detection and response. Using a third party vendor to enhance authentication processes can speed time to market and potentially avoid any risks incurred during the building and rolling out of an internal security solution itself – an option that appeals to many developers and businesses.

Stytch authentication for B2C and B2B applications

Stytch's authentication solutions are designed to bolster identity security and streamline the authentication process for an application's end users and the business-to-business (B2B) cloud environments in which they operate.

Breach-resistant password-based and passwordless authentication such as Stytch Passkeys for passwordless login using cryptographically secure keys on the user's device for easier, secure access.

OAuth that enables logins using a single credential set, such as an existing user social account, leveraging secure, token-based authentication.

Single sign-on auth capabilities for any B2B company looking to support larger customers and sell upmarket as well as Role-Based Access Control (RBAC) tailored for complex B2B environments to assign roles by job function, boost security, streamline management, and mitigate access risks.

System for Cross-Domain Identity Management (SCIM), a critical feature for large enterprises, who rely on this protocol as a way to centrally and securely manage employee identity and access the thousands of SaaS tools companies use at scale.

Email Magic Links that enhance login ease by providing authentication via an emailed link, eliminating passwords and reducing a fraudster's ability to gain access.

Multi-factor authentication (MFA) that improves security by requiring users to provide two or more verification factors prior to accessing their account, greatly reducing the likelihood of account compromise.

Fraud and risk prevention like Device Fingerprinting that identifies unique characteristics of a user's device, such as the operating system, browser version, screen resolution, and even unique identifiers like IP address, helping distinguish between human and machine to safeguard against OTP bot attacks and other potential automated breaches.

To learn more about how Stytch end-user and B2B authentication solutions can support you in securing, scaling and growing your applications, check out our docs and start building for free today. Or, to learn more about how these or other solutions work, reach out to an auth expert to start a conversation.

---


# What is whaling phishing and how to prevent whaling attacks
Source: https://stytch.com/blog/whaling-phishing-attacks/

An intro to whaling phishing attacks – who they target, what's at risk, and how to prevent them.

While many fraud attempts are indiscriminate in nature (think brute force attacks like password spraying), fraudsters can also be more discerning in an attempt to reap bigger rewards. In the case of whaling phishing, their goal is to stick it to the person at the top.

Whaling phishing is a type of cyberattack that targets high-level executives like CEOs and CFOs. The primary objective of a whaling phishing attack is to steal sensitive information or execute financial transfers. Unlike regular phishing, it uses personalized tactics to trick these individuals into revealing this information or making unauthorized transactions.

In this article, we’ll explain what whaling phishing is in more detail, how it works, and how you can protect your organization from these sophisticated, exec-level attacks.

Whaling phishing attacks explained

Unlike a general spear phishing attack which targets a specific person, group, or organization, whaling phishing attacks are a type of spear phishing attack that’s even more specific to who they target: high-level executives such as CEOs and CFOs. The goal of a whaling attack is to trick said power players into believing the communication is legitimate, often through means like email spoofing and content manipulation.

How do whaling phishing attacks work?

Whaling phishing attacks are meticulously crafted, involving cybercriminals pretending to be trusted contacts to manipulate these executives into revealing confidential information or authorizing financial transactions. In a whale phishing attack, the attackers use sophisticated social engineering tactics, email spoofing, content spoofing, and even voice spoofing to create emails, texts or calls that seem legitimate, often leading to phishing attempts. These attempts can include:

Impersonation of a trusted contact through the sharing of personal details or references to ongoing projects to enhance their credibility.

Fake urgent payment requests requiring immediate attention.

Less commonly, links to spoofed websites that look real designed to collect sensitive information. These are more prevalent in general spear phishing due to the flags they raise at the executive level.

Whaling phishing is more of a theatrical art than science: Like an actor studying his character, a cybercriminal will invest considerable time and effort in researching their target to understand their behavior and online presence. They gather information from social media, corporate websites, and press releases to understand the target’s role, responsibilities and professional history. This extensive research enables them to craft convincing messages that appear to come from trusted sources within the organization.

Who's at risk?

Unlike broad-spectrum phishing attacks, whaling targets specific individuals with significant access to valuable data and resources – the very top of the pecking order at any given organization. In addition to C-suite executives, senior managers, finance and IT personnel, as well as HR staff are common targets of whaling attacks if the access to sensitive information warrants the attempt. These individuals have elevated privileges to access critical business systems, making them lucrative targets for attackers seeking financial gain, data theft, or other malicious purposes.

Recognizing a whaling phishing attack



One of the most common pathways to a successful whaling attack is via business email compromise of sensitive data to trick whaling attack victims. As with phishing and spear phishing attacks, recognizing whaling emails can be challenging due to their sophisticated nature, but certain red flags can help identify them. These emails often reference specific events, projects, or personal details to make them appear legitimate. They might come from a sender address that is slightly altered, such as changing a single letter in the domain name, making it look almost identical to the legitimate address.

The path to business email compromise is often achieved through alarmist and urgent language, compelling the target to take immediate action, such as transferring funds or providing confidential information. An executive might see terms like “Request,” “Follow Up,” or “Fwd:” to create a sense of familiarity and urgency. Subtle errors like slight misspellings or odd phrasing can also be indicators of a whaling email.

Differences between whaling and other phishing attacks

Unlike some spear phishing attacks, whaling attacks usually avoid using malicious URLs or attachments, making them harder to detect compared to standard phishing attacks. The lack of obvious red flags like malicious links or attachments allows whaling emails to bypass traditional security measures, making them a more effective and dangerous form of social engineering attack in many cases.

Because whaling attacks specifically target high-profile individuals such as CEOs, CFOs, and other executives within an organization, they are highly personalized and crafted with detailed information about the target, with subtle details often gathered from social media profiles, company websites, and other publicly available sources. This level of 'personalization' distinct from more broad-based phishing attacks increases the credibility of the attacker and the likelihood of the target (generally a highly experienced and competent individual) falling for the scam.



Consequences of whaling phishing attacks

The consequences of whaling phishing attacks can be severe and far-reaching. Financial loss is one of the most immediate and tangible impacts with large sums of money at stake. In addition to financial losses, whaling attacks can lead to data theft, severely compromising an organization’s data security and putting sensitive information at risk.

Operational disruption is another significant consequence as these attacks can impact the continuity of business operations, causing substantial downtime. The ensuing ripple effects can lead to loss of customer trust and potential legal liabilities.

Examples of successful whaling attacks

Over the past decade, several high-profile companies have fallen victim to successful whaling attacks, resulting in substantial financial and data losses. Here are a few noteworthy examples:

In 2016, FACC’s CEO, Walter Stephan, was deceived into wiring $56 million to fraudsters through a sophisticated whaling attack.

Similarly, in 2016, Belgian bank Crelan suffered a $75 million loss after cybercriminals targeted its CEO.

Snapchat experienced a whaling attack in 2016 from a high-level employee disclosing employee payroll information due to a CEO fraud email.

It's important to note that in today's multi-device, AI-enhanced digital landscape, fraudsters don't rely solely on one method such as email and are increasingly deploying newer, more technologically savvy methods. A prime example of this occurred in 2019 when a UK energy company’s CEO was tricked into transferring $243,000 by a deepfake call mimicking his boss’s voice. And that was 2019 - imagine how easy it is now for fraudsters to utilize free or publicly available AI tools to conduct deepfake whaling attacks.

Rising sophistication in all forms of fraud must beget evermore savvy authentication solutions. As we move deeper into an AI-driven future, organizations must prepare for whaling attacks hiding in new digital disguises we can’t yet predict.

How to prevent whaling phishing attacks

With the knowledge that fraudsters will continuously evolve their methods, successfully preventing whaling phishing attacks requires, first and foremost, an executive team in the C-suite that is educated and aware of the current threats at play. Combining this awareness with strong anti-fraud and authentication measures for the executive team’s inner circle and most frequent collaborators can pack a powerful one-two punch against whaling phishing.

At a base level, a strong authentication and anti-fraud posture should include:

Implementing authentication methods like multi-factor authentication (MFA), and more unique authentication methods (like passkeys or TOTPs) to add an extra layer of security.

Enforcing strict password policies to ensure strong and unique passwords, or better yet going passwordless!

In European setting, using Strong Customer Authentication (SCA) to further protect sensitive information in financial transactions is advised.

Staying current with software and hardware updates to address security gaps.

Regularly applying security patches to prevent unauthorized access.

Often, working with a 3rd-party provider that natively specializes in the above solutions is the easiest, most resource-efficient path with the lowest risk to business continuity.

Stytch fraud prevention solutions

Stytch offers a range of fraud and risk prevention tools designed to protect companies against various attacks, including whaling phishing, with strong authentication that encompasses an executive’s closest contacts and all employees below them. Two of these solutions, Device Fingerprinting and multi-factor authentication, can help enhance your organization’s overall security posture and earn customer trust.

Multi-factor authentication

As hackers develop more sophisticated social engineering techniques, phishing-resistant MFA in particular is becoming a crucial investment. Stytch’s ‘unphishable’ multi-factor authentication enhances protection against phishing, spear phishing and whaling phishing by requiring users (including those adjacent to executives) to verify their identity using multiple elements. This phishing-resistant MFA is built upon reliable WebAuthn measures like device-based biometrics and hardware keys.

Device Fingerprinting

Stytch Device Fingerprinting (DFP) creates unique identifiers for each user’s device, improving security and reducing whaling phishing attempts by distinguishing between legitimate users and potential threats. This technology aggregates various attributes such as: browser type, operating system, IP address, and other device-specific details to detect and block fraudulent activity. If a user posing as a company VIP is coming in with any suspicious device or browser characteristics, you can block them or force them to complete additional challenges, making it harder to spoof. 

DFP integrates directly into your current setup, providing an additional security layer that is tamper-resistant to reverse engineering and spoofing attempts. By utilizing both industry-standard and proprietary signals, DFP ensures reliable identification across various scenarios, including incognito browsing and VPN usage.

Interested in learning more? Get in touch with an expert to see how Stytch fraud prevention solutions can help you navigate the stormy seas of whaling attacks and improve your organization's security from top to bottom.

---


# SCIM API: Your comprehensive guide and introduction
Source: https://stytch.com/blog/scim-api-your-comprehensive-guide-and-introduction/

The SCIM (System for Cross-domain Identity Management) API is an open RESTful specification that supports standard CRUD operations which can be used to synchronize identity resources across multiple independent systems or domains.

The SCIM (System for Cross-domain Identity Management) API is an open RESTful specification that supports standard CRUD operations which can be used to synchronize identity resources across multiple independent systems or domains. These operations are typically performed using common HTTP methods such as POST, GET, PUT, PATCH, and DELETE.

However, the SCIM protocol doesn’t just define programmatic API endpoints but also specifies an interoperable JSON-based schema that any SCIM-compliant Client (identity providers) and cloud-based Service Provider (SaaS applications) can use to provision and de-provision user/employee accounts and attributes, ensuring identity data remains consistent and up-to-date across both systems.

Let’s consider a large enterprise organization that probably uses hundreds of SaaS applications for work and needs to manage different access levels and permissions for thousands or even millions of users and employees across these tools.

Without SCIM, the IT department would need to manually create and update user accounts in each application whenever there is a new hire, a role change, or a departure. The thing is, this kind of manual provisioning is time-consuming and almost always prone to errors and data inconsistencies.



In this article, you’ll learn about the SCIM API as defined by the IETF RFC 7644 standard specification. We’ll explore the SCIM schema and data model, and discuss all the REST endpoints and HTTP operations/methods that can be used to exchange data between SCIM clients and SaaS applications. As an enterprise SaaS provider, you’ll learn how to support SCIM without expending valuable engineering time on a custom SCIM setup that may take months or even years to implement.

Core components of the SCIM architecture

Every SCIM setup relies on a bidirectional client-server architecture where an identity provider (IdP) typically serves as the SCIM Client and a SaaS application or intranet system serves as the SCIM Service Provider (or vice versa), depending on the data flow per request.



SCIM Clients

SCIM Clients are typically identity providers like Okta, Entra ID, or Google Workspace that centrally manage user/employee identities within an organization. They can connect to the SCIM protocol to synchronize these user identity attributes with the Service Providers (SPs) that require this data to provision new user accounts and manage access permissions.



SCIM Clients perform CRUD operations on user and group resources by sending HTTP requests to Service Providers via standardized SCIM API endpoints. However, in cases where a Service Provider needs to initiate a SCIM request to an IdP, it will act as the SCIM Client while the IdP functions as the SCIM server.

SCIM Service Providers

In a standard SCIM architecture, a Service Provider acts as the SCIM server because it’s responsible for exposing RESTful API endpoints and processing HTTP requests from the SCIM Client. Service Providers could be SaaS applications such as Vercel, Notion, GitHub, or Linear which are capable of consuming and responding to CRUD requests, ensuring users/employees have the appropriate account privileges within their respective systems.

The SCIM data model

The SCIM data model defines a standardized structure for representing core SCIM resources and their associated attributes.



SCIM resources are categorized into two main resource types such as "User" and "Group" which are maintained by service providers. These resource types define the resource name, endpoint URL, schema, and other metadata that describe where a resource is located and how it is managed.

User resource type: In the SCIM data model, “User” represents an individual user account or entity, such as an employee or customer. This resource is associated with attributes such as userName, name, emails, addresses, and other user-related information.

Group resource type: This represents a collection of user accounts or entities that share common identities that are unique and separate from individual “User” attributes. The “Group” resource includes attributes such as displayName, members (a list of user IDs), and other metadata about the group.

These resource types, whether User, Group, or any custom/extended resource type, are represented by JSON objects that can be accessed and managed via the SCIM protocol, either individually or in bulk.

On the other hand, resource attributes are the individual pieces of information that describe the properties or characteristics of a resource in the SCIM data model. They can have a single value or contain multiple or complex values, depending on the attribute's definition and data type.

For example, the userName attribute of a User resource is typically a single string value representing the user's unique identifier. Other examples of single-valued attributes include displayName, externalId, and boolean flags like active.

However, some resource attributes are designed to hold multiple values which are represented as arrays or lists. These attributes are often used to store collections of related data. For example, the emails attribute of a User resource can contain multiple email addresses associated with a particular user. Similarly, the members attribute of a Group resource is a list of user IDs representing the group’s members.

Here's an example of how a multi-valued attribute might be represented in a SCIM resource:



In this example, the emails attribute is a multi-valued attribute, represented as an array of email objects, each containing a value and a type.

The SCIM data model is designed to be extensible, allowing service providers to define and use their custom resources or attributes, while maintaining interoperability with other SCIM-compliant systems. As such, service providers can define their custom resource attributes to extend the SCIM schema and include additional information relevant to their specific use cases.

The SCIM schema

While Users and Groups are resources within the SCIM data model, schemas are a collection of the attributes associated with these resources. In essence, the SCIM schema is a standardized JSON-based structure that represents the attributes and data types (e.g., string or boolean) that are associated with a resource. As we’ve seen thus far, the schema also specifies whether an attribute can hold a single value, multiple values, complex values, and other metadata.

The SCIM data model defines three sets of predefined schemas that describe the structure and attributes of user and group resources, such as the User schema, Group schema, and Enterprise User schema.

The User schema is a predefined schema that describes the standard set of attributes for representing a user resource across different systems. The Group schema is another core schema that describes the standard set of attributes for representing a group resource (collections of users).



On the other hand, the Enterprise User schema is an example of how the SCIM data model can be extended to include additional attributes that are relevant to specific use cases or environments. It’s an extension schema that builds upon the core User schema by including additional attributes commonly used in enterprise environments. It includes attributes related to organizational information, such as employeeNumber, costCenter, organization, division, and others.





The use of standardized SCIM schemas promotes interoperability by providing a common language for describing and validating user and group data across different systems and domains. It allows SCIM clients and service providers to exchange and interpret identity data in a consistent manner while allowing for extensibility and customization as needed.

The SCIM protocol

The SCIM protocol is a standardized set of RESTful APIs and associated specifications that define how SCIM clients and service providers communicate and exchange identity data based on the SCIM data model and schemas. The protocol is designed to be lightweight and easily consumable by different systems and programming languages.



It utilizes JSON payloads to share identity resources via SCIM messages that contain an HTTP header, schemas attribute, and URI. These components convey protocol-specific parameters that are related to any SCIM request or response.

SCIM endpoints and HTTP methods

According to the IETF RFC 7644 open specification, the SCIM protocol defines a set of RESTful endpoints (URLs) that support standard HTTP methods (GET, POST, PUT, PATCH, DELETE) for performing CRUD operations on user and group resources.

SCIM clients typically use GET requests to retrieve data from a service provider, while POST requests are used for creating resource objects or attributes, making bulk modifications to resources, and searching for resource types within a resource endpoint. PUT requests are used to replace attributes within resources, PATCH requests are used to update attributes, and DELETE requests are used to remove resources permanently.

We’ve compiled a comprehensive table that outlines the RESTful endpoints defined by the SCIM protocol and the kind of HTTP operations that can be performed against them. You can find the table below.



Common SCIM operations

Creating resources

To create new resources via the SCIM protocol, such as users or groups, the SCIM client has to send an HTTP POST request to the appropriate resource endpoint (e.g., /Users or /Groups). The request body must contain a JSON representation of the resource according to the relevant SCIM schema.



When the service provider successfully creates the new resource, it has to return an HTTP 201 Created response with the newly created resource in the response body. The HTTP Location header typically contains the URI of the new resource and the service provider may include the JSON representation of the meta.location attribute in the response body.

Retrieving resources

To retrieve an existing resource, the SCIM client has to send an HTTP GET request to the specific resource endpoint (e.g., "/Users/{id}", "/Groups/{id}", or "/Schemas/{id}", where the portion after the resource name ("{id}") represents the resource’s unique identifier).



If the resource is found, the service provider typically responds with an HTTP 200 OK status code and includes the JSON representation of the requested resource in the response body. By default, the service provider will only return resource attributes that have their “returned” setting as "always" or "default".



Querying resources

To query resources, the SCIM client has to send an HTTP GET request to the appropriate resource endpoint, appending query parameters to the request URL to filter or search for specific resources.

Upon receiving the request, the service provider has to process the query parameters and return the matching resources in the response body. The response typically includes an HTTP 200 OK status code and a JSON representation of the filtered resource list, adhering to the relevant SCIM schema. However, if no resources match the specified query parameters in the request, the service provider will return an HTTP 200 OK response with an empty resource list in the response body.

You can also use query parameters to filter resources based on attribute values, resource metadata, or any other criteria supported by the ServiceProviderConfig endpoint. For example, the client can write a filter query parameter to retrieve all users with a specific email domain (e.g., /Users?filter=emails.value+sw+"%40example.com"), or to search for groups that contain a specific string in their display name (e.g., /Groups?filter=displayName+co+"Marketing").





Security of the SCIM protocol

The security of a SCIM setup heavily depends on the specific implementation in question. While the SCIM protocol doesn’t inherently define standard security mechanisms, it provides guidelines and recommendations for securing the communication between SCIM clients and service providers.

Authentication - The SCIM protocol doesn’t mandate a SCIM-specific authentication mechanism, but it recommends using industry-standard authentication protocols such as OAuth 2.0 or HTTP Basic Authentication. As such, service providers are responsible for implementing the appropriate authentication measures to ensure that only authorized SCIM clients can access and manage identity resources.

Authorization - The SCIM protocol can be integrated with existing access control mechanisms that enforce fine-grained permissions on user and group resources. Service providers can leverage fine-grained authorization frameworks such as ABAC or PBAC to ensure SCIM clients have the appropriate rights to perform specific operations on SCIM identity resources.

Data encryption - SCIM recommends using HTTPS with TLS for secure communication between clients and service providers, ensuring that data in transit is encrypted and protected against eavesdropping and man-in-the-middle attacks. However, it doesn’t inherently provide end-to-end encryption of identity data. As such, service providers may still have to implement additional security measures to encrypt data at rest and throughout its lifecycle.

In essence, the overall security of a SCIM implementation doesn’t necessarily depend on the protocol itself, but on the security practices and measures implemented by SCIM clients and service providers.

Implementing SCIM in-house vs using Stytch




Deciding to implement SCIM in-house or utilize a SCIM connector like Stytch depends on several factors such as your organization's specific security and compliance requirements, available engineering resources, and risk tolerance profile.



However, the reality is that building SCIM from scratch requires significant development effort, as you need to handle all aspects of implementing the protocol, including resource management, authentication, authorization, error handling, and more.



Your engineering team will be responsible for maintaining and scaling your SCIM setup as the protocol evolves or your requirements change, which can be resource-intensive. Mind you, your current and even prospective customers may be using different identity providers (SCIM clients) within their companies, and you must be prepared to handle the complexities of integrating with them.



As a SaaS provider, if you plan to offer support for IdPs like Okta, Microsoft Entra ID, Google Workspace, JumpCloud, and OneLogin, you'll need to deeply understand how each provider maps resource attributes and performs SCIM operations, and also ensure your system can handle each provider securely.



If you need a reliable, scalable, and quick-to-deploy solution with zero-to-minimal development and maintenance overhead, leveraging Stytch’s SCIM base connector is likely the better choice. Using Stytch's SCIM base connector URL, enterprise applications can easily connect their IdPs and service providers to exchange SCIM updates in real-time. We provide the relevant SCIM APIs and can process any scale of SCIM requests and responses without any failovers or data loss.

Get started with Stytch

Ready to implement the SCIM protocol using Stytch? Check out our SCIM Docs and start building. If you want to learn more about our extensive auth APIs and SDKs you can check our B2B and B2C docs and sign up for a free developer account.

If you have any questions, please reach out to us at support@stytch.com or schedule a chat with a member of our Solutions Engineering team.





---


# Stopping an account takeover before it takes a toll
Source: https://stytch.com/blog/account-takeover/

Learn how to prevent and detect account takeover (ATO) attacks, a serious cyber threat where criminals gain unauthorized access to user credentials. This blog explores the evolution of ATO attacks in the AI era, details common techniques like phishing and malware, and offers solutions like multi-factor authentication and strong password policies to enhance security.

There are few things worse than waking to the realization that your organization’s defenses have been breached. An account takeover attack, where cybercriminals gain access to login credentials to steal funds or information, is a serious threat to businesses and individuals. These attacks often lead to fraudulent transactions, unauthorized shopping from compromised accounts, financial loss, stolen personal information, and reputational damage.

This article delves into how these attacks occur, their evolution in the AI era, and how developers and organizations can protect themselves and their end users from the consequences.

Understanding account takeover fraud

Account takeover (ATO) fraud is a type of cybercrime where attackers gain unauthorized access to a user’s online account and carry out harmful activities. With every breach, the ramifications are not just financial; they extend to identity theft and a host of other malicious activities that permeate our online and offline lives.

Account takeover attacks can have a significant impact on both businesses and consumers, leading to financial losses, reputational damage, and loss of customer trust. Preventive measures, such as constant vigilance, comprehensive security strategies, and adaptive cybersecurity approaches, are crucial to mitigate these risks.

As we increasingly shift everything online, the threat of ATO has grown exponentially. The evolution of these attacks in the AI era has made them even more sophisticated and harder to detect. Cybercriminals now have a plethora of tools at their disposal, enabling them to execute large-scale attacks with unprecedented ease. Let’s dig a bit deeper into how they work.

The anatomy of an account takeover

As mentioned, the genesis of a successful account takeover starts with stolen or compromised user credentials due to the prevailing problem of weak passwords. Account takeover techniques such as credential stuffing, phishing, and malware are commonly used by cyber attackers to gain control of legitimate accounts. When cybercriminals gain unauthorized access by means of exploiting these weak passwords, it can lead to a cascade of malicious activities, including identity theft, fraudulent transactions, and even blackmail. Hint: We don’t actually need passwords anymore. Curious about going passwordless? Learn more here.

Attackers have multiple means of obtaining user credentials through data breaches, phishing attacks, or purchasing them on the dark web. Once inside a compromised account, the potential for damage multiplies as attackers can access sensitive information such as personal details, credit card numbers, and social security numbers. The core of an ATO attack lies in the unauthorized access to sensitive user data and the subsequent exploitation of this access for various malicious purposes.

The challenge of detecting account takeovers

Identifying account takeovers isn’t easy. For one, fraudsters often hide behind a customer’s positive history and mimic normal login behavior, using techniques including phishing, credential stuffing, and malware, making it difficult for traditional security measures to identify the threat. Unfortunately, the shift of our lives online and the widespread reuse of passwords has made the account takeover a lucrative method for cybercriminals.

Compromised accounts can lead to significant consequences for businesses, including financial losses, additional security measures, and reputation damage.

Fortunately, studying the modus operandi of cybercriminals in executing account takeovers as well as the hurdles in identifying such attacks can inform the development of effective counter-strategies.

Common methods used in account takeover attacks

Phishing remains one of the most common methods used in ATO attacks. Cybercriminals trick victims into providing their login details through scams executed via channels such as SMS, emails, scam websites, chat conversations, malicious phone applications, and phone calls.

Cyber attackers gain unauthorized access to a legitimate bank account to steal funds or information, using techniques like phishing, malware attacks, and bot-driven automation.

These attacks often involve legitimate yet rigged web pages containing malicious code to harvest user credentials, including login credentials, to aid the attacker in gaining unauthorized access.

Other methods include credential stuffing, where cybercriminals use breached credentials from one site on multiple other sites to gain unauthorized access. Malware-based ATO attacks involve infecting the user’s device with malicious software that can capture keystrokes and intercept user credentials. Comprehending these methods forms the foundation for devising strong countermeasures against ATO attacks.

Aside: As hackers develop more sophisticated social engineering techniques, breach-resistant passwords can provide a crucial guardrail. What’s breach resistant? A strong, secure password that’s hard for bots to guess. Stytch’s built-in zxcvbn strength assessment tool is a simple way to ensure that passwords created adhere to NIST password guidelines. Plus Stytch integrates with HaveIBeenPwned to track compromised credentials and trigger a password reset if needed. Learn more.

Account takeovers in the AI era

AI and machine learning now play a substantial role in facilitating ATO attacks. They have enabled more sophisticated techniques for compromising user credentials, increasing the prevalence of account takeovers, which skyrocketed globally by 155% in 2023. Cybercriminals often purchase stolen credentials on the dark web to carry out account takeover fraud. Let’s take a look at how AI can make ATO attacks more potent and harder to stop.

AI and machine learning in ATO attacks

Fraudsters now use automated technologies to test millions of credentials on thousands of websites. Automated password cracking systems have replaced traditional ‘brute force’ attacks with more sophisticated methods. For instance, machine learning algorithms can now analyze vast datasets to generate accurate variations of passwords, greatly increasing the success rate of ATO attempts.

Generative AI can also create convincing written text that mimics human language patterns. The sophistication of the technology now infuses messages with the appropriate jargon, tone, and structure that align with the targeted individual's expectations. For example, an AI can generate emails that appear to come from a bank, employer, or family member, including personalized details that increase the credibility of the message.

AI hasn't only created more convincing phishing emails and texts – deepfake technology is also being employed to manipulate voices and visuals, enabling cybercriminals to impersonate individuals and authorize fraudulent transactions using voice or video. On social media, AI-powered bots mimic human behavior more convincingly, leading to the creation of fake accounts en masse and automated social engineering attacks.

Modern ATO attacks in action

In late 2020, a major Account Takeover (ATO) attack using credential stuffing and phishing targeted high-profile Twitter accounts of celebrities and corporations. Cybercriminals used credentials from previous data breaches and phishing tactics to deceive Twitter employees and gain access. They tweeted links to fraudulent cryptocurrency sites, promising to double the money sent to a Bitcoin address. Within hours, they collected over $100,000 from victims. This incident highlighted the severe risks of credential stuffing and phishing on social media.

Undoubtedly, the growing sophistication and severity of modern ATO attacks emphasizes the need for advanced protection measures.

Taking charge: Solutions to detect and prevent ATO

As a first (and cost-effective) step in mitigating the frequency and impact of account takeovers, implementing a strong password policy is essential. At a base level, Stytch recommends the following:

Encourage users to create passwords that are long and memorable rather than focusing solely on complexity. Length provides more entropy, making passwords harder to crack.

Discourage the use of easily guessable patterns or common words, and instead, promote the use of passphrases composed of random words.

Instead of regularly prompting users to change their passwords, which can lead to weaker password choices, emphasize the creation of strong, unique passwords from the start.

Encouraging the use of password managers can help users generate and store complex passwords securely. A strong password policy should also avoid forcing users to remember too many different passwords, reducing the likelihood of unsafe practices like password reuse.

Educating users about common attack methods and implementing security measures are crucial steps to prevent account takeover. This includes promoting strong password hygiene, cautioning against sharing sensitive information, and providing guidance on recognizing and reporting suspicious activities.

Beyond instilling strong password policies, Stytch offers several solutions to reinforce authentication at the organizational level, along with proven fraud prevention tools that can meaningfully shift your account security from reactive to proactive.

Multi-Factor Authentication (MFA)

Multi-factor authentication (MFA) adds an extra layer of security by requiring additional verification beyond the password. MFA often uses a combination of something you know (like a password) and something you have (like a phone) to verify identity, increasing security for user accounts. Time-based one-time passwords (TOTP) are a common MFA method that requires a new code for each login session.

Implementing MFA can prevent a successful account takeover attack, which involves the theft of login information leading to fraudulent transactions and unauthorized shopping from compromised financial accounts.

Stytch’s ‘unphishable’ MFA provides enhanced security beyond traditional MFA by ensuring multifactor authentication can’t be bypassed or phished. MFA can include biometric verification methods such as fingerprint or facial recognition, adding an extra layer of security. Stytch provides a flexible MFA suite, incorporating best-in-class methods like SMS one-time passcodes and email verification. These solutions ensure that user credentials remain secure and prevent unauthorized access.

Strong CAPTCHA

Strong CAPTCHA uses device- and user-specific signals to ensure CAPTCHAs are solved where they’re shown - not by a bot, or by an outsourced service - blocking bot activity by challenging suspicious users to verify they are human. By implementing Strong CAPTCHA, you can maintain legitimate user access while thwarting automated attacks. Additionally, CAPTCHA can help protect user's account credentials from being compromised by automated attack tools.

Device Fingerprinting

Behavioral analytics establishes a baseline of ‘normal’ user behavior to detect deviations that may indicate a potential account takeover (ATO) attack, such as irregular login times or unusual transaction patterns. AI-driven algorithms analyze these anomalies in real-time, helping to detect potential threats early. A robust, real-time fraud detection solution is crucial for identifying emerging attacks and sophisticated fraud techniques, swiftly alerting users to suspicious activities like unfamiliar login attempts or unauthorized changes to account settings.

Stytch’s Device Fingerprinting (DFP) tags unique characteristics of devices and behaviors that are hard to reverse engineer to make it easier to distinguish humans from bots. The feature assigns a globally unique identifier for each device, enabling granular control over individual user device responses. Stytch’s device fingerprinting helps block bot activity by distinguishing it from legitimate traffic and using Strong CAPTCHA for validation.

Device classification in Stytch automatically categorizes devices based on trust levels and authorization status, allowing you to customize the actions your organization wants to take. DFP also offers stable identification across incognito browsing, VPNs, and changes to user agents or IP addresses.

To start implementing Stytch authentication and fraud prevention, check out our docs and start building for free today. Or, to learn more about how these or other solutions work, reach out to an auth expert anytime.




---


# Integrating SAML Single Sign-On with Python, Okta, and Stytch
Source: https://stytch.com/blog/integrating-saml-sso-with-python-okta-stytch/

This article will teach you how to set up a SAML SSO login flow using Python with Flask and Stytch.

Security Assertion Markup Language Single Sign-On (SAML SSO) enables seamless communication between various websites or applications. This communication eliminates the need for repeated password entry by securely sharing user identity information. It's like having a master key that grants you access to multiple rooms in a building without needing to unlock each door separately.

SAML uses Extensible Markup Language (XML) to exchange information between websites. Rather than relying on secret keys or passwords to identify users, SAML uses assertions.

SAML SSO is commonly used for seamless authentication and authorization across multiple web applications, particularly in enterprise environments. It's also used in scenarios involving federated identity management, such as when organizations collaborate or share resources securely.

This article will teach you how to set up a Flask  application that uses a SAML SSO login flow with Stytch as the B2B authentication provider and Okta as the identity provider (IdP).

What Is SAML SSO

SAML SSO typically consists of three main components:

The service provider (SP) is the application or service that users want to access. It consumes SAML assertions from the IdP to grant access.

The identity provider (IdP) authenticates users and generates SAML assertions containing identity information. The B2B customers represent the companies or businesses that are using the service provider's app and trying to log in using SSO.

User agents are web browsers or client applications that users utilize to interact with both the IdP and SP to facilitate SSO login.

As the authentication provider, Stytch coordinates and manages the auth flow between all parties (SP, IdP, and user agents) by providing developers with tools such as APIs and SDKs to build the full SSO flow.

At a high-level, when a user logs into their account on their IdP via SSO, their identity details are passed on to Stytch. Stytch then handles all the work needed to validate their identity by communicating between the IdP and your app (the SP) through the SAML protocol. 



Aside: If you want to learn more about B2B authentication and how SAML SSO works, check out Stytch's B2B Auth School.

What You'll Build

In this article, you'll implement a Flask web application that uses Stytch to enable SAML SSO login with Okta as the IdP. The example app consists of two primary components:

A Flask web server that uses the Stytch Python SDK to handle the SSO auth flow on the server-side. 

A React UI that renders the login form and logged-in page, which utilizes the Stytch React SDK to manage the session post-login. 

Once running, the example app will enable the following auth flow for users: 

The user opens the login page for their company or organization, and then prompted to log in with Single Sign-On. 

The user authenticates into their Okta account and is redirected back to the application. 

The user logs into the application with an authenticated session. 

You can visit the repo and explore the source code here on Github.

Implementing SAML SSO with Python and Flask

Before you start, make sure you have the following:

Python 3.8+ installed on your machine.

An Okta account. You can register for a free thirty-day trial account.

A Stytch account. Make sure you register for Stytch's B2B SaaS authentication product.

Node.js v20.10.0+ installed on your machine.

Setting Up Your Project

To get started, open your terminal or shell and run the following command to clone the existing repository, which has both the frontend and backend setup:



Creating a New SAML SSO Connection

Before you get into the code, you need to configure a few settings in Stytch to create a new SAML SSO Connection. 

The first step is to sign up for a Stytch account and create a B2B Authentication Project. Navigate to Redirect URLs in the sidenav and add http://localhost:3000/authenticate for both login and signup. This URL is already be added by default for newly created Stytch B2B Projects. 



Next, navigate to Organizations in the sidenav and select Create new organization. Enter a name and a slug before saving. This is the organization the user will log into.



Once your organization is created, scroll down to the Configure SSO Connections section and click + Add new. Give the SSO Connection a name and select Okta SAML as the identity provider.



Click Create. Your new Stytch SSO Connection will auto-generate several SSO values that you'll need to input into your identity provider, which is Okta in this case. 



The last few steps are to configure Okta as your identity provider, which mostly involves copying over your new SSO Connection values. Please refer to Step 4: Setup workforce IdP application in this Stytch guide that includes detailed instructions and screenshots on how to complete the setup with Okta. 



Once you've finished the Okta set up, go back to the Stytch Dashboard and confirm that your Organization's new SSO Connection shows as active under your organization. You should also see the Default connection ID automatically set to the SSO connection you just made with Okta.

The last step is to change the Who can join the organization via JIT provisioning? setting to Anyone. 



The Just-In-Time (JIT) provisioning setting is a convenient feature that automatically creates a user account in your application the first time a user logs in through Single Sign-On (SSO). This means that you don't have to manually create Stytch user accounts in advance; instead, they are created the exact moment when users authenticate through the identity provider, Okta. 

Setting Up the Flask Server

Now that your Stytch Project and identity provider are ready, you need to set up the Flask backend APIs. 

You'll start by creating a virtual environment, and then install the necessary packages. Open your terminal or shell, navigate to the api folder, and run the following:



This command creates the virtual environment, but you still need to activate it. The activation commands differ depending on your operating system.

If you're using Windows, you can use the following:



If you're on macOS/Linux, use the following:



Once the virtual environment is activated, you can install the packages with pip:



This command installs Flask to build your backend APIs, flask-cors to handle the cross-origin resource sharing (CORS), stytch as the Python client library for Stytch API, requests to make HTTP requests, and python-dot-env to handle environment variables.

Next, copy the api/.env-TEMPLATE file to your own .env file. 



In the .env file, set the environment variables with your Project's credentials from the Stytch Dashboard, which you'll find in API Keys.



Creating the API routes

Open app.py under the api folder which consists of two primary API endpoints.

On line 58, you'll see an API route which returns the data needed for an organization login page. This route starts the SSO login process for end users associated with a specific organization. When a user wants to log in, they navigate to a URL that includes the organization's unique identifier (e.g. /org/company-name).



The API GET endpoint has a parameterized URL /org/<string:slug>, where slug is a dynamic value that represents the organization's unique identifier. You already specified the slug identifier when creating the organization in an earlier step.  

The API endpoint then uses the Stytch Python SDK, stytch_client, to fetch the organization using the provided slug, constructing a query to search through organizations. 



If the organization is found, it retrieves the organization's details, including the connection_id for SSO. The API route then constructs a Stytch SSO start URL and returns it back to the client along with the organization's name. 

This SSO URL is used to start the SSO authentication flow on the client-side and redirects the user to the Identity Provider (IdP) with all the required information. Refer to our documentation for more details. 

On line 42, you'll see the /authenticate API route which handles the redirect after the user authenticates with Okta.  



The endpoint extracts the stytch_token_type and token query params from the URL. If it's an SSO token, it uses the Stytch Python SDK to authenticate the token. If the authentication is successful, it sets a cookie with the session token returned by Stytch before sending the response back to the client. 

This completes the server-side setup for handling SSO login with Stytch and Okta. Next, you can proceed with the client-side UI implementation and final touches to complete your SSO integration.

Setting Up the UI with React

To start with the frontend application, run the following command using your terminal or shell in the ui directory to install the necessary packages:



This command installs the libraries @mui/material , @emotion/react and @emotion/styled to style Material UI components. You'll also use react-router-dom to handle navigation and URLs in your app. Most importantly, you'll install the stytch-react SDK to manage the logged-in session. 

Next, copy the api/.env-TEMPLATE file to your own .env file. 



In the .env file, set the environment variables with your Project's public token credentials from the Stytch Dashboard, which you'll find in API Keys.



Next, open the main.jsx file in the src directory to see how the overall front-end app structure is organized. 



In this React application setup, the file configures the BrowserRouter, which handles client-side routing and manages navigation between pages, and the StytchB2BHeadlessClient, which is used to interact with Stytch’s authentication services. The StytchB2BProvider wrapped around the <App /> component makes this client available throughout the app. 

The App component serves as the root of the UI, rendering the main interface of the application. Open the App.jsx file to see the main component of the application: 



The App component primarily performs two functions.

Session management: The Stytch SDK's useStytchMemberSession hook automatically retrieves the current authenticated session if detected in the cookies and validates it. If the user is logged in, then a logout button is rendered which calls a function tiggers Stytch's session.revoke method. 

Route rendering: The /org/:orgId route renders the SSOLogin component for organization-specific login, while the / route conditionally renders either the ProductsList component if a session exists and the user is logged in, or the Home component if there is no session and the user is logged out.

This structure ensures that unauthenticated users can access their organization's specific SSO login page, while authenticated users are directed to the product list page for a logged-in view. 

Running and Testing the Code

From your terminal or shell in your api directory, run the following command:



Then from your ui directory, run the following command to run the React application:



In the broswer, visit localhost:5173/org/:orgSlug in the browser to load the organization's login page. Replace :orgSlug with the slug identifier you defined when creating the organization. 



Click the Continue with SAML SSO button, which links to the Stytch SSO Start URL that was constructed server-side from the organization's SSO connection. 

Log into Okta with the user's credentials and you'll be redirected back to the application's logged in view of a private products list. Here's the entire SSO login flow in action: 



Users can also log in to the application directly from Okta for an IdP-initiated SSO login flow. To do this, navigate to your Okta dashboard and open the application. 



All the code for this tutorial is available in this GitHub repo.

Conclusion

In this article, you learned how to implement SAML SSO into your app using Python and Flask for the backend, React for the frontend. Okta as the IdP, and Stytch as the auth provider to build the SSO flow. 

Stytch offers a variety of authentication methods and dev tools to integrate robust authentication systems alongside your application. Check out Stytch's docs if you're looking for a feature-rich, scalable, and enterprise-ready solution to build B2B SaaS authentication.



---


# SAML vs OAuth: Key Differences Explained
Source: https://stytch.com/blog/saml-vs-oauth/

The choice between SAML and OAuth isn’t a “this” or “that” conversation. While SAML and OAuth may appear to be alternatives or interchangeable at face value, they serve distinct use cases.

The choice between SAML and OAuth isn’t a “this” or “that” conversation. While SAML and OAuth may appear to be alternatives or interchangeable at face value, they serve distinct use cases.

If your engineering or IT team needs to centralize how employees access multiple internal and SaaS applications using a single set of credentials, SAML is what you need to implement. On the other hand, if you need to manage and secure how your APIs, service accounts, machine-to-machine (M2M) applications, microservices, or IoT devices interact, you should implement OAuth 2.0.

In this article, we’ll cover the fundamentals of SAML and OAuth, including their architectures, data structures, auth flows, applications, and use cases. Whether you're a senior developer or just starting out, this guide will provide the clarity you need to confidently work with either of these protocols.

Understanding SAML and OAuth

At a high level, SAML (Security Assertion Markup Language) is an enterprise SSO protocol, while Open Authorization (OAuth) is a delegated authorization protocol.

What is SAML (Security Assertion Markup Language)

SAML is designed to support single sign-on (SSO) in enterprise and highly-regulated environments. It enables the exchange of authentication and authorization data between a dedicated identity provider (IdP) and multiple service providers (SPs). In this way, users and employees don’t have to maintain individual login credentials across all the systems they need to access for work.

Instead, these enterprise users only need to own a single set of credentials with the IdP used within their organization to manage user profiles and identity data (e.g., Okta, Entra ID, One Login, Google, etc.). These IdP-provisioned credentials can then be used to access multiple SPs (e.g., GitHub, Vercel, Slack, Figma, etc.) via SSO.

What is OAuth (Open Authorization)

OAuth is an open delegation standard for granting secure access to resources without sharing user credentials. It enables clients or third-party applications to request permission from a resource owner (a user) via a resource server in order to gain access to a protected resource on the owner’s behalf.

The resource owner is the delegating party and is typically an end-user on whose behalf the client intends to act. The owner maintains control over which resources the client can access, the permissions or actions it can perform, and can also revoke this access at any time.

On the other hand, the client or third-party application is the delegated party and could be an API, microservice, or any kind of system capable of requesting access. While the protected resource could be data, permissions, or actions that can be performed on an API, an application, or even a database.

The resource server is any server that hosts the protected resource and is capable of validating the access tokens issued by an OAuth 2.0 Authorization Server. The client must obtain a client ID and secret from the authorization server before sending requests to the endpoints specified by the server.

It’s important to note that client authorization via OAuth 2.0 is very different from impersonation because the requesting client must verify their identity and also request permission from the authorization server in the form of an access token.



For example, let’s assume you intend to link your USD bank account to a wallet service like PayPal, Cash App, or Zelle using an open banking provider like Plaid. When you initiate the connection, Plaid authenticates your bank credentials to ensure you own the account, then uses OAuth 2.0 to issue an access token to the wallet service. This token allows the wallet service to securely access your bank information, such as your account balance and transaction history, without needing your login credentials. In this scenario, Plaid acts as the authorization server between your bank and the wallet service—you’re the resource owner, your bank is the resource server, and the wallet service is the client requesting access.

Authentication and authorization in SAML vs. OAuth

SAML is primarily a user authentication protocol, but it can also support authorization because user roles and permissions can be included in SAML assertions as attribute and authorization statements. These SAML statements can be used to indicate whether a user is permitted to access a particular resource and the actions they’re allowed to perform.

However, this doesn’t mean SAML can replace traditional authorization and access control frameworks such as RBAC, ABAC, and PBAC. This clarification is important because it's easy to confuse SAML for a typical user authorization framework.

For example, the user attributes included in a SAML assertion can be used as input attributes by ABAC systems that need to make access control decisions. However, these SAML attributes can’t replace the policies, conditions, and other components like the decision points, enforcement points, and retrieval points that form the core of a full-fledged ABAC authorization system.

On the other hand, while OAuth is primarily a client authorization protocol, it also performs client authentication. This means a client that needs to access a protected resource via an OAuth 2.0 server must first verify its identity using a client ID and secret (client authentication) before it can be granted access to the resource using access tokens (client authorization).

However, unlike SAML, OAuth doesn’t directly support user authentication. Instead, OpenID Connect (OIDC) was built on the core tenets of OAuth 2.0 to support user authentication using tokens. OIDC is an open identity standard that enables users to log into multiple OIDC-compliant systems using a single set of credentials that must have been provisioned on an OpenID provider.

Can SAML and OAuth be used together?

SAML and OAuth can indeed be integrated within the same system, but they serve different purposes and are not interchangeable. At best, SAML can be used to authenticate a client’s identity within an OAuth 2.0 authorization flow, as defined by the official IETF RFC 7522 specification.

This means client applications can exchange valid SAML assertions with an OAuth 2.0 server in order to obtain access tokens and perform actions on a user’s behalf. This approach is particularly useful in scenarios where SAML handles user authentication, and OAuth secures access to internal services or APIs. However, it’s important to note that this kind of SAML and OAuth integration only works in web-based scenarios, because SAML isn’t compatible with the wide range of application types and use cases that OAuth supports.

SAML architecture vs. OAuth architecture

SAML’s architecture is based on a request-response model, where a service provider (SP) sends a user authentication request (AuthnRequest) to an identity provider (IdP), which then sends the SP a response containing assertions about the authenticated user. These SAML requests and responses are digitally signed, encrypted, and communicated over secure HTTP POST and HTTP Redirect bindings.

In contrast, OAuth’s architecture follows a grant-token model. Here, the requesting client must obtain a permission grant from the end user before being issued an access token by the OAuth 2.0 authorization server. This token can then be used to gain access to the protected resource hosted on a resource server. While OAuth 2.0 doesn’t inherently encrypt requests and tokens, it mandates the use of opaque tokens and ensures all client-server interactions occur over secure HTTPS/TLS channels.

SAML data structure vs. OAuth data structure

SAML’s XML-based data structure

SAML requests, responses, and assertions are structured using XML (Extensive Markup Language). This XML-based format allows for the transmission of complex and detailed information, including nested elements, signatures, and attribute statements that define the authentication and authorization status of a user. While XML enables rich, hierarchical data representation, it can be verbose and complex to parse, especially for resource-constrained devices or lightweight applications.

Here's a simplified example of a SAML assertion structure:



This sample SAML assertion includes basic elements such as the issuer, subject, conditions, authentication statement, and attribute statement. In reality, SAML assertions often include additional elements and are typically much longer, especially when including digital signatures and encryption. However, SAML's detailed XML structure is what makes it suitable in enterprise SSO scenarios that usually deal with rich identity data.

OAuth’s JSON-based data structure

Unlike SAML, OAuth uses a much simpler data structure centered around tokens—primarily the access token and optionally the refresh token. These tokens are typically compact strings, often in the form of JSON Web Tokens (JWTs), which are more lightweight compared to SAML assertions. OAuth tokens contain minimal information, usually just an identifier or a set of claims, and are meant to be opaque to the client. The actual user information and additional metadata are typically stored on the server side and retrieved as needed using the token.

Here's an example of a decoded JWT structure used as an OAuth access token:



This lightweight structure makes OAuth tokens easier to transmit and process, particularly in mobile and web applications, and APIs. The JWT can be easily encoded into a compact, URL-safe string for transmission.

SAML authentication flows vs. OAuth grant types

SAML authentication flows are primarily designed for web-based SSO scenarios and involve two main flows—SP-initiated SSO and IdP-initiated SSO. In the SP-initiated SSO flow, the user requests access to some protected resource from the service provider (SP) and is redirected to the identity provider (IdP) with an AuthnRequest. The IdP then authenticates the user’s identity and sends them back to the SP with a SAML response containing an assertion.

In contrast, the IdP-initiated SSO flow starts at the IdP, where the user authenticates their credentials and selects the SP they intend to access. The IdP then sends the user to their chosen SP with a SAML response and assertion, eliminating the need for an initial AuthnRequest from the SP. We’ve covered the key differences between the SP-initiated and IdP-initiated SSO flows in more detail here.



OAuth, on the other hand, provides several grant types/flows that cater to different use cases and applications, including web apps, SPAs, mobile apps, and APIs. The Authorization Code Grant is commonly used for server-side applications, where the client exchanges an authorization code for an access token. The Implicit Grant is used for browser-based applications, where the access token is directly returned to the client. Other grant types include the Client Credentials Grant, which is used for machine-to-machine communication, and the Resource Owner Password Credentials Grant. You can read more about these OAuth 2.0 grant types in our “What is OAuth 2.0?” article.

How SAML and OAuth approach security

SAML relies on XML signatures and X.509 certificates to secure messages exchanged between SPs and IdPs. Both SAML requests and responses can be digitally signed, enabling the receiver to verify that the message hasn’t been altered and originates from a trusted source. To achieve this, SAML uses XML Digital Signatures (XML-DSig) and applies cryptographic algorithms such as RSA combined with SHA-1 or SHA-256 for signing SAML messages.

Additionally, SAML assertions contain validity periods defined by NotBefore and NotOnOrAfter attributes. These attributes help mitigate replay attacks by ensuring assertions can’t be reused outside their designated time frame.

In contrast, OAuth ensures security primarily through the use of secure transport channels (HTTPS/TLS) and opaque tokens. When a client requests an access token from an authorization server, the communication must occur over HTTPS to protect the confidentiality and integrity of the data exchanged.

On the other hand, access tokens/JWTs are signed using algorithms like HMAC-SHA256 or RSA-SHA256 that ensure their integrity. These tokens are also designed to be short-lived and carry minimal information, usually just an identifier or a set of claims that specify the token’s scope and expiration, limiting the potential damage if tokens are intercepted.

Additionally, OAuth supports token expiration and refresh tokens that also help to enhance the security of the protocol. For example, when an access token expires, the client can use a refresh token to obtain a new access token without re-authenticating the user. OAuth also supports token revocation, which allows authorization servers to invalidate tokens if they are compromised or if the user's permissions change, thereby providing an extra layer of security.

To mitigate against common vulnerabilities, OAuth uses state parameters to prevent Cross-Site Request Forgery (CSRF) attacks, and implements strict redirect URI validation to mitigate open redirect vulnerabilities. For public clients, such as single-page applications, OAuth 2.0 recommends the use of Proof Key for Code Exchange (PKCE) which helps to prevent authorization code interception attacks.

Implementing SAML and OAuth using Stytch

Ready to implement SAML and/or OAuth in your project? Our documentation can guide you all the way from implementation to live.

Feel free to check out our SAML SSO docs to learn how to support SAML across multiple IdPs such as Google Workspace, Okta, and Microsoft Entra ID.

To protect your APIs and service accounts using the OAuth 2.0 Client Credentials Grant flow with Stytch as your OAuth provider, refer to our M2M docs.

If you have any questions about our features and pricing, please reach out to us at support@stytch.com or schedule a call with a member of our Solutions Engineering team.



---


# SAML vs LDAP: What's the difference?
Source: https://stytch.com/blog/saml-vs-ldap/

SAML (Security Assertion Markup Language) and LDAP (Lightweight Directory Access Protocol) are both user authentication protocols, but their application and use cases are largely different.

SAML (Security Assertion Markup Language) and LDAP (Lightweight Directory Access Protocol) are both user authentication protocols, but their application and use cases are largely different.

SAML is an open identity standard used for exchanging authentication data in cross-domain scenarios, while the LDAP protocol is used for managing access to directory services within closed networks.

For organizations with distributed employees who need to access multiple intranet systems and SaaS applications without managing separate credentials for each system, you need to implement SAML to enable single sign-on (SSO).

For organizations with a complex on-premise infrastructure, and an overworked IT/Security team that has to manually delegate access and permissions across multiple internal resources (whether servers, intranet systems, computers, or printers), you need to implement LDAP to centralize authentication and directory services.

What is SAML, and how does it work?

SAML is a federated identity protocol used to implement single sign-on (SSO) in enterprise environments. It relies on XML (Extensible Markup Language) to exchange authentication and authorization data about employees in the form of SAML requests and responses.

SAML-enabled applications (also known as service providers in SAML speak) use the protocol to send authentication requests (AuthnRequests) to SAML-enabled identity providers, which then send back responses that contain XML assertions about an authentication decision.

Service providers (SPs) are typically SaaS applications such as Slack, Notion, or GitHub that employees need to access for work, while identity providers (IdPs) could be platforms like Okta, Microsoft Entra ID, Google Workspace, or One Login that are responsible for managing centralized user identities within an organization.

At its core, SAML enables end users to authenticate once with a central identity provider and access all integrated cloud applications without needing to log in separately for each service. For more detailed information about how SAML works, see our "What is SAML?" article, and for a comparison with another industry-wide SSO protocol, see our "SAML vs OIDC" article.

What is LDAP, and how does it work?

LDAP is an open protocol for maintaining and modifying directory resources or entries over a network. It enables organizations to manage employee accounts, group memberships, files, intranet applications, physical devices, and other corporate network resources, all within a centralized directory service.

The protocol defines the language and methods for interacting with a directory, but it doesn’t specify how data is stored internally. This means that LDAP doesn’t inherently provide a database, rather, it provides a method to query information stored in a directory service.

The directory service itself (often referred to as an LDAP server) is responsible for storing and organizing the data. Examples of directory services include Microsoft Active Directory, OpenLDAP, RedHat Directory Server, IBM Security Directory Server, Oracle Enterprise Directory Server, Apache Directory Server, and others.

In LDAP, the identity and authentication process involves verifying a user's information by binding their credentials (typically a username and password) to an entry in the directory. If the credentials match the stored attributes, the user is then authenticated. Authorization, on the other hand, determines what resources the authenticated user can access, based on their attributes and group memberships within the directory.

LDAP’s architecture

Unlike traditional relational databases that store information in tables with rows and columns, LDAP directory services store data using an attribute-value pair model. Each entry in the directory is a collection of attributes that can contain one or more values. For example, a user entry might have attributes like ‘cn’ (common name), ‘mail’ (email address), and ‘uid’ (user ID), each with corresponding values.

LDAP directories are typically organized hierarchically, much like a file system, with entries arranged in a tree structure according to nodes that represent different levels in the hierarchy. This hierarchical nature makes it well-suited for storing organizational information, which can be structured from the root according to geography (country, state, city), organizations (company, division, department), units (specific teams or workgroups), roles (job titles or positions), individual persons or employees, and even resources (computers, printers, servers).




Additionally, groups can be created to manage collections of users or other entries for access control and permissions, independent of the hierarchical structure. At its core, LDAP’s architecture is based on a client-server model, where an LDAP client has to make requests (queries) to an LDAP server in order to access information.

LDAP queries involve constructing search operations based on attributes in order to locate specific entries within the directory structure. The search operation typically specifies a base DN (Distinguished Name) to define the starting point of the entire search path, a scope to define the extent of the search (whether base, one-level, or subtree), a filter to refine the search criteria (e.g., (uid=jdoe)), and the attributes to return in the results. The LDAP server then processes the query, navigates the directory tree, and returns matching entries based on the specified filters and scope.

Cloud-based SSO vs. on-premise SSO

As we’ve established so far, SAML enables cloud-based SSO (single sign-on) across domains by exchanging XML messages between identity providers (IdPs) and service providers (SPs).

The way this works is quite straightforward: When a user attempts to access a SaaS application/service provider via SAML SSO, the application typically generates an authentication request (AuthnRequest) and routes the user to the IdP used to manage identity profiles within their organization. The user then logs into the IdP using their IdP-provisioned credentials.

If the credentials are valid, the IdP has to generate a SAML response containing XML assertions about the user’s authentication and authorization status, and route the user back to the application that made the initial AuthnRequest. The application then parses the SAML assertion and grants the user access to their system without requesting any credentials. This approach eliminates the need for users to maintain and remember multiple usernames and passwords across different cloud applications.




However, when it comes to authenticating users into multiple on-prem resources using a single set of credentials, it’s impossible to rely solely on LDAP. While LDAP doesn't inherently provide SSO functionality, it can be a key component within an on-premise SSO system. LDAP alone provides directory services and authentication, but when implemented alongside other protocols like SAML and Kerberos, it can be used to support on-premise SSO.

On-premise SSO using Kerberos and LDAP

In Windows environments, Kerberos authentication can be combined with LDAP directory services to provide an SSO-like experience within a domain. In this setup, LDAP is used for directory services and user management, while Kerberos provides the single sign-on (SSO) functionality.

Here’s how this works: When a user logs into their Windows computer, the device communicates with their domain controller using Kerberos. The domain controller authenticates the user’s credentials against an LDAP server and issues a Kerberos ticket-granting ticket (TGT) which serves as proof of the user’s identity.

As the user accesses various resources within the domain (like file servers, intranet applications, or printers), their computer uses the TGT to request specific service tickets from the domain controller, without requiring the user to re-enter credentials across these resources.

This approach allows users to access multiple internal resources seamlessly after their initial login, creating an SSO-like experience within the Windows domain. However, it's important to note that this SSO experience is typically limited to resources within the same domain or trusted domains, unlike SAML which can work across disparate systems and domains.

On-premise SSO using SAML and LDAP

In this scenario, identity providers (IdP) like Okta, Entra ID, One Login, and Google Workspace can be used to implement SAML in an on-premise environment because they offer lightweight LDAP agents and/or virtual LDAP interfaces that can connect to on-prem LDAP servers.

Here’s how this would typically work: When a user attempts to access an application, they’re redirected to the IdP, which must have been deployed on the organization’s network and interfaces with the LDAP directory. The IdP then authenticates the user by validating their credentials against the LDAP directory using the IdP’s installed agent, without replicating these credentials with the IdP. Once authenticated, the IdP generates the appropriate SAML assertions and redirects the user back to the application, which then grants access to the user without requiring any credentials.

This approach combines the best of both worlds: It allows organizations to maintain their existing LDAP infrastructure for user management while providing a modern SSO experience that works across applications and environments, including on-premise and the cloud.

Is SAML an LDAP alternative, or vice versa?

As we’ve seen so far, SAML and LDAP are not direct alternatives, as they serve different purposes and use cases. LDAP is a directory access protocol used primarily for storing and retrieving user information within on-premise environments, while SAML is an XML-based authentication protocol designed for web-based single sign-on (SSO) across multiple domains and applications.

Can SAML and LDAP be used together?

Yes, SAML and LDAP can be used to complement each other in modern IT environments that maintain both cloud-based and on-prem resources. LDAP enables authentication to on-prem resources, while SAML enables authentication to cloud-based applications via SSO. In this setup, identity providers act as the bridge between LDAP directories and SAML-enabled service providers, combining the strengths of on-prem user management with flexible, cross-domain authentication.

Getting started with Stytch

In this article, we've been able to successfully compare SAML vs LDAP as authentication and authorization protocols that can be used to authenticate users, and grant them access to both on-prem and off-prem company resources.

Ready to support SAML and other open protocols such as OIDC, OAuth, and SCIM using Stytch? Check out our docs and sign up for a free developer account to start building.



---


# What are SAML assertions?
Source: https://stytch.com/blog/saml-assertions/

In this article, we explore the XML structure and lifecycle of SAML assertions and how they’re used in authentication and authorization scenarios. You’ll also learn about the possible errors you might encounter when working with SAML assertions, and how to debug and troubleshoot these errors.

A SAML assertion is an XML-based data structure that conveys authentication and authorization information between an identity provider (IdP) and a service provider (SP) within a SAML SSO authentication flow. SAML assertions typically contain statements and nested attributes about a user that an IdP must have authenticated, and other relevant details about the authentication event.

These statements contain attributes that define the user’s identity, their authentication status, the time and method of authentication, conditions that specify when and where the assertion is valid, and other relevant user-specific attributes like role or department affiliations. This way, service providers can rely on assertions to make access control decisions within their systems, without directly authenticating any user.

In this article, we’ll explore the XML structure and lifecycle of SAML assertions and analyze how they’re used in authentication and authorization scenarios. You’ll also learn about the possible errors you might encounter when working with SAML assertions, and how to debug and troubleshoot these errors.

What are SAML responses, and how are they different from SAML assertions?

A SAML response is an XML document that delivers one or more SAML assertions from an identity provider (IdP) to a service provider (SP), along with other necessary protocol-related information. To understand this relationship, think of a SAML response as an envelope containing a letter—the envelope (response) holds and delivers the letter (assertion), which contains the actual information being sent.

While the SAML assertion is the core message containing authentication and authorization details, the SAML response provides the overall structure and context for the assertion(s). In addition to the assertion(s), SAML responses typically include:

A unique ID for the response.

The issue instant (timestamp).

The destination URL.

Status information (success or error messages).

A digital signature that verifies the integrity and authenticity of the entire response.

Here’s an example XML structure of a signed SAML response, but without a SAML assertion:



This structure makes it possible for the SAML response to handle multiple assertions if needed, provide status messages, and add an extra layer of security and context to the communication between the IdP and SP.

The XML structure of a SAML assertion

SAML assertions are built upon a well-defined XML structure that’s designed to be flexible and extensible. This structure makes it possible for assertions to carry all the authentication and authorization details required by a service provider to make informed access control decisions about users.



The key elements that make up a SAML assertion include:

Assertion ID: A unique identifier for the assertion.

Issuer: Information about the identity provider that created the assertion.

Signature: A digital signature to ensure the integrity and authenticity of the assertion.

Subject: Details about the authenticated user which the assertion is about.

Conditions: Criteria that must be met for the assertion to be considered valid.

Statements: The core content of the assertion, including authentication, attribute, and authorization decision information.

These elements collectively provide a detailed description of the user and the context of their authentication, ensuring that the assertion is secure, properly structured, and parsable by service providers.

Assertion ID

The Assertion ID is a unique identifier assigned to each SAML assertion by the issuing IdP. It ensures that each assertion can be distinctly referenced, which helps to differentiate it from other assertions when parsed by an SP. This unique ID also plays a crucial role in preventing replay attacks by ensuring that the same assertion cannot be reused maliciously.

For example, if an attacker attempts to intercept and reuse a particular assertion, an SP would be able to detect that the assertion ID has already been used if it checks against its record of previously processed assertions. This prevents the attacker from successfully reusing the assertion to gain unauthorized access.



Issuer

The Issuer element specifies the identity provider that generated and issued the SAML assertion. This element helps service providers verify the source of an assertion and ensure it originates from an IdP with which it has an established relationship.



Signature

The Signature element ensures the integrity and authenticity of a SAML assertion. It contains cryptographic information, including a digital signature, which allows the service provider to verify that the assertion hasn’t been altered and that it indeed originates from the specified Issuer (IdP). The signature typically covers the entire assertion and includes components such as the SignatureMethod, SignatureValue, DigestValue, KeyInfo, and more, all of which are specified using XML signature standards (XML-DSig).



Subject

The Subject element contains information about the authenticated user. It typically includes a unique identifier for the user (represented by a NameID) and may also contain additional information that specifies the method of confirmation (represented by the SubjectConfirmation element).



Conditions

The Conditions element specifies the constraints or circumstances under which the assertion is considered valid. This can include a validity period (NotBefore and NotOnOrAfter timestamps) and other constraints such as the intended audience for the assertion. This ensures the assertion is only used according to the intended context and timeframe.



Statements

SAML assertions contain one or more statement elements that provide specific information about the authenticated user. These include authentication statements, attribute statements, and authorization decision statements.

AuthenticationStatement: Affirm that a user has been authenticated and provide details about the authentication method used.

AttributeStatement: Contains attributes about the user, such as their name, email, role, and department.

AuthorizationDecisionStatement: Specifies the actions or resources that the user has been authorized to access.

Types of SAML assertion statements

Authentication assertion statements

Service providers use the AuthenticationStatement to verify that a user has been authenticated by the SAML identity provider. They also use this statement to determine the strength of the authentication method in order to make informed decisions about whether to grant access or require additional authentication. The key elements contained in an authentication statement include:

AuthnInstant: Specifies the exact time when the user authentication took place.

AuthnContext: Describes the authentication mechanism used (e.g., password, biometrics, token, magic links).

SessionIndex: Is an optional attribute that references the specific authentication session.



Attribute assertion statements

AttributeStatements contain one or more attribute elements, which are essentially name-value pairs that describe specific characteristics or properties of the user. These attributes are used to convey additional information about the user that may be relevant to the service provider for authorization decisions or other purposes.



Authorization decision statements

AuthorizationDecisionStatements determine whether an authenticated user is allowed to access specific resources and the kind of actions they’re authorized to perform. An AuthorizationDecisionStatement typically includes the following key elements:

Resource: The URI of the resource that an authenticated user is allowed to access.

Decision: The authorization decision (e.g., Permit, Deny, or Indeterminate).

Action: The action that the user can perform on the resource.

Evidence: Optional information supporting the user authorization decision.

However, it's important to note that AuthorizationDecisionStatements may not be as frequently used in SAML compared to Authentication and AttributeStatements. Most service providers would prefer to handle authorization decisions locally rather than relying on pre-determined decisions from an identity provider.



Comprehensive XML structure of a SAML assertion

As we’ve established so far, a comprehensive SAML assertion could contain all the key elements we just went over, including the Assertion ID, Signature, Issuer, Subject, Conditions, and the three types of assertion statements (Authentication, Attribute, and Authorization Decision Statements).

These components collectively form the structure of a SAML assertion, providing a secure and extensible way to communicate identity and authorization data between IdPs and SPs in SAML SSO authentication flows.

Here’s a comprehensive structure of a SAML assertion in XML, combining all the elements:



The lifecycle of a SAML assertion

There are five distinct stages that a SAML assertion must undergo, right from when it’s generated by an identity provider (IdP) to when it’s consumed by a service provider (SP), or even considered expired or invalidated.

Stage 1: Generating a SAML assertion

SAML assertions are generated by an IdP after a user successfully authenticates their IdP-provisioned credentials via the SP-initiated SAML SSO flow, or selects the SP from a list of SAML-configured apps provided by the IdP via the IdP-initiated SAML SSO flow. The IdP constructs the assertion’s XML structure by encapsulating attributes about the user and the authentication event. It also signs the assertion to ensure its integrity using XML signatures. Once generated, the assertion is ready for transmission to the SP.

Stage 2: Transporting the assertion

Once a SAML assertion is generated, it has to be transmitted from the IdP to the SP that needs it to make a decision. This transmission often occurs via an HTTP Redirect or POST binding, where the assertion is securely sent in a browser response or directly through an HTTP request. The assertion is typically included in a SAML response message that the identity provider sends to the SP’s Assertion Consumer Service (ACS) URL.

Stage 3: Validating the assertion

Upon receiving the SAML assertion, the service provider has to perform a series of validation checks to ensure its authenticity and integrity. This involves verifying the digital signature of the assertion to confirm it was issued by a legitimate IdP, and that it hasn’t been tampered with during transmission. The SP also checks the assertion’s validity period, ensuring it falls within the specified time range and hasn’t expired.

Stage 4: Consuming the assertion

At this point, the SP proceeds to consume the assertion after it passes all validation checks. This involves extracting the user’s attributes and any additional information contained within the assertion. The SP then utilizes this information to make authorization decisions, such as granting user access to protected resources or personalizing the user’s experience. Once an assertion has been consumed, it’s typically logged and then discarded to prevent reuse and replay attacks.

Stage 5: Expiration and revocation of the assertion

Every SAML assertion has a predefined validity period, which is defined by the NotOnOrAfter condition and specified in the assertion itself. Once this validity period expires, the assertion is automatically considered invalid. However, in certain scenarios, an assertion might need to be invalidated or revoked before its expiration time. This could happen due to security breaches or changes in user permissions. The IdP can invalidate an assertion by updating its status or issuing a revocation notification to the SP.

Dealing with SAML assertion errors?

SAML assertion errors can be a pain, but they’re an important security feature. These are issues that can occur during the processing or validation of a SAML assertion. They indicate problems such as expired assertions, invalid signatures, mismatched recipient information, or violations of assertion conditions.

As such, when a service provider encounters these errors, it typically rejects the assertion and denies access to the user. These errors are crucial for maintaining the integrity and security of the authentication process, preventing unauthorized access attempts, and helping system administrators identify and resolve configuration issues in both identity providers and service providers.

Common SAML assertion errors include:

Format and schema errors: This error can occur if an assertion doesn’t conform to the SAML XML schema or if required elements are missing or incorrectly formatted.

Incorrect assertion issuer: This error occurs when the Issuer of the assertion doesn't match the expected identity provider. This could indicate an IdP configuration issue or a potential IdP impersonation.

Signature validation errors: This error occurs when the signature on a SAML assertion can’t be verified. This can be due to an invalid or missing signature, or if the certificate used to sign the assertion isn’t trusted or has expired.

Missing or invalid subject: This error can occur if the assertion doesn't properly identify the user. This means that the Subject element is missing or doesn't contain the expected user information.

Subject confirmation errors: This error can occur if the Recipient attribute in the SubjectConfirmationData doesn't match the SP's endpoint URL, if the InResponseTo attribute doesn't match the ID of the original SAML request sent by the SP, or if the Method attribute specifies a confirmation method that isn’t supported by the SP.

Expired assertion errors: Assertions have specific validity periods defined by the NotBefore and NotOnOrAfter conditions they contain. If the assertion is used outside this time frame, it will be rejected due to expiration.

Audience restriction errors: SAML assertions contain an AudienceRestriction element that specifies the service provider that can accept the assertion. If the audience restriction doesn’t match the expected entity ID of the service provider, the assertion will be rejected. This error prevents assertions from being used by unintended recipients.

Best practices for debugging and troubleshooting SAML assertion errors

1. Double-check metadata configuration: Incorrect or mismatched metadata configuration can cause communication failures between an IdP and SP. It’s important to regularly verify that the metadata for both the IdP and SP is up-to-date and correctly configured. This includes checking entity IDs, endpoints, certificates, and supported bindings.

2. Verify time synchronization between IdP and SP: Time-related issues are another common source of assertion validation errors. You have to ensure that the clocks on your IdP and SP servers are synchronized using a reliable time source, such as an NTP server. This is highly important because SAML assertions often contain time-based validity conditions, and even small time discrepancies can lead to rejected assertions. As such, always confirm that the assertion’s IssueInstant, NotBefore, and NotOnOrAfter timestamps are correct and within the expected range.

3. Use SAML-tracer or similar browser extensions: Browser extensions like SAML-tracer can capture and decode SAML messages (both requests and responses) in real-time. This allows you to inspect the raw SAML assertions and responses as they’re being sent, making it easier to identify issues with formatting, missing attributes, or incorrect values, whether it’s via an SP-initiated or IdP-initiated SAML flow.

4. Implement proper error handling and logging: Ensure your application has implemented robust error handling that captures and logs SAML-related errors in detail. This should include the full error message, stack trace, and relevant SAML message contents (with sensitive information properly masked). Proper error-logging practices make it much easier to diagnose issues when they occur in production environments.

5. Verify assertion signature: Always ensure that the certificates used to sign an assertion are valid, trusted, and not expired. You can also verify if the signature matches the assertion content using XML signature validation tools.

6. Use a SAML validator tool: There are several online SAML validation tools that can help you verify the structure, signature, and content of your SAML assertions for free. These tools can check for XML validity, proper formatting, and adherence to SAML standards. By pasting your SAML assertion into a validator, you can quickly identify syntax errors or required elements that are missing.

7. Use network analysis tools: Tools like Wireshark can help you analyze the network traffic between an IdP and SP. This can be particularly useful for identifying issues with SSL/TLS connections, HTTP redirects, or other network-level problems that might be interfering with the SAML authentication process. As such, examining raw network traffic can reveal issues that might not be captured in application-level logs.

Implementing SAML SSO using Stytch

Building a custom SAML implementation from scratch is a Herculean task. It requires a deep understanding of the SAML protocol, and we've only scratched the surface in this article.

Based on feedback from our customers who have migrated off in-house implementations of the SAML protocol, we strongly caution against building SAML all by yourself. The SAML protocol is complex, and as such, it’s easy to overlook security vulnerabilities that could potentially compromise your infrastructure in production.

At Stytch, we offer robust APIs and SDKs that make it super easy to support SAML SSO in your SaaS applications, often within weeks or even days. We act as an intermediary that standardizes the SAML authentication process across multiple identity providers.



These IdPs are responsible for authenticating users and issuing SAML assertions, while Stytch facilitates the connection between the IdPs and SPs, forwarding XML requests and assertions between both parties.

As a B2B SaaS provider, you can easily configure SAML for your enterprise customers, regardless of the identity provider they use within their organization. We handle the complexities of routing AuthnRequests to the appropriate IdP and relaying SAML responses back to your application, allowing you to focus on your core business logic.

Ready to implement SAML SSO in your SaaS app using Stytch? Check out our SAML Docs and sign up for a free developer account.

If you have any questions regarding our features or pricing, feel free to reach out to us at support@stytch.com or schedule a call with one of our Solutions Engineers.



---


# Spotting the spoof: User agent spoofing unmasked
Source: https://stytch.com/blog/user-agent-spoofing/

This article will focus on user agent spoofing and how it can be a particular threat to individuals and businesses in the hands of fraudsters. We’ll dive into what user agents are, how spoofing works, the common ways in which this type of fraud is carried out, and how to prevent user agent spoofing using the latest fraud and authentication technology.

Spotting the spoof: User agent spoofing unmasked

The dark web didn’t get its name by chance – the guise of secrecy is often the preferred route for fraudsters to carry out malicious activities online. On the open web, however, some fraudsters find successful cover via user agent spoofing, also known as browser spoofing.

This article will focus on user agent spoofing and how it can be a particular threat to individuals and businesses in the hands of fraudsters. We’ll dive into what user agents are, how spoofing works, the common ways in which this type of fraud is carried out, and how to prevent user agent spoofing using the latest fraud and authentication technology.

Understanding user agent spoofing

At its core, user agent spoofing involves altering the user agent string to disguise a browser’s identity. In non-fraudulent online transactions, the user string is a set of characters that lets servers and network peers identify the application, operating system, vendor, and/or version of the requesting user agent. For the purposes of this article, we’ll focus on the more nefarious purposes like ad fraud, click farms, web scraping, and bypassing content restrictions.

What is a user agent string?

A user agent is like a digital passport that provides websites with essential information about the visitor’s browser, application, and operating system. When a browser sends a request to a server, it includes a user agent string in the user agent header of the HTTP request, which helps the server present the correct version of the website.

The user agent string contains details such as the browser type and version, the operating system, and sometimes the device type. User-Agent strings can be complex due to historical reasons, but they generally follow this pattern of providing browser, operating system, and rendering engine details. Here’s an example with each component explained:



Mozilla/5.0: This part of the string is a legacy identifier. Many browsers, including Chrome, include this for compatibility reasons, but it doesn't mean the browser is Mozilla.

Windows NT 10.0; Win64; x64: This indicates the operating system (Windows 10), the architecture (64-bit), and the platform (x64).

AppleWebKit/537.36: This specifies the rendering engine being used, which in this case is Apple’s WebKit engine (commonly used by Chrome and Safari). The version number (537.36) indicates the WebKit version.

(KHTML, like Gecko): KHTML is the engine that WebKit is based on, and "like Gecko" means the browser behaves similarly to Firefox (which uses the Gecko engine).

Chrome/116.0.5845.111: This is the version of Chrome (v116.0.5845.111).

Safari/537.36: Even though this is Chrome, it includes "Safari" in the string for compatibility purposes, showing the version of WebKit, which is shared with Safari.

This information, also known as the browser’s user agent, enables websites to tailor their content and functionality to provide the best user experience. It can also be used for device fingerprinting to help identify devices by various attributes unique to them for the purposes of fraud prevention, or to ensure compatibility.

By understanding user agents and strings, developers can optimize their websites for various devices, operating systems and browsers.

User agent spoofing as a useful tool

User agent spoofing or browser spoofing works by presenting a false user agent string using various tools and techniques. Developers use user agent spoofing to test websites across different devices, altering the user agent string through browser settings or through browser extensions, like User-Agent Switcher and Manager. This lets them test how websites behave on different devices without actually changing the physical device.

Commonly altered signals in developer user agent spoofing include the user agent strings, JavaScript capabilities, screen resolution, language preferences, and time zone settings.

Malicious user agent spoofing

While user agent spoofing can be a versatile tool with a wide range of positive applications such as web development and developer testing, it’s also useful for certain forms of fraud such as ad fraud, click farms, website scraping, and bypassing authentication for fraudulent purposes. The negative implications of these activities should interest any developer team or business seeking to shore up its security posture.

Ad fraud and click farms

In ad fraud, or advertising fraud, fraudsters present a custom user agent string to make a hidden or outdated browser appear as a legitimate user, with the malicious intent of generating fake traffic on paid ads. This fake traffic can trick advertising platforms into believing they are reaching real, unique visitors.

Click farms, often located in regions with low-cost labor, use outdated smartphones and other devices to generate ad clicks. By employing user agent spoofing, these operations can mask their true identity and make their devices appear modern and located within desirable locations. This practice has successfully deceived ad platforms like Google and Facebook, leading to significant financial losses for advertisers.

For example, the Terracotta click farm was a sophisticated ad fraud operation discovered by authorities in 2020, notable for its scale and the advanced methods it used to evade detection. Terracotta used emulators to mimic a wide range of devices and user behaviors, making it difficult for ad platforms like Google and Facebook to detect the fraud.

Bypassing content restrictions

User agent spoofing is commonly used for bypassing content restrictions imposed by geo-blocks, i.e., accessing content that is otherwise unavailable in a specific region. These can range from streaming services, news websites, and sporting events (Premier League football fans understand this desperation!).

While bypassing geo-blocks might seem harmless at the hands of the casual content-consumer, it can have broader implications for many businesses. Unfortunately, in many cases, it undermines the efforts of content providers to control the distribution of their material based on regional licensing agreements. Additionally, it can expose users to legal risks if they violate the terms of service of the platforms they are accessing.Web scraping and web exploits

By altering the user-agent string, fraudsters can evade primitive bans based on IP and user-agent combinations. This tactic is particularly effective against systems without a Device Fingerprinting (DFP) solution (more on how this can help in the next section), which are unable to accurately identify and block malicious activity.

Fraudsters often pair user-agent spoofing with proxies or VPNs to mask the true origin of their traffic, making it appear as though requests are coming from different devices or locations. This method is used for various malicious purposes, including large-scale web scraping, bypassing rate limits or bans, and exploiting the soft limits of free-tier services that allocate credits based on weak factors like IP or user-agent. By continually changing their user-agent, fraudsters can fly under the radar, maintain persistent access, and maximize the benefits they extract from these services.

Spotting the spoof with Stytch Device Fingerprinting

So how might businesses unmask these attempts to prevent user and organizational harm? Given the multitude of ways in which a user agent can be spoofed, a best-in-class solution should go beyond a free traffic audit to look at many more subtle indicators and signs of foul-play.

Stytch Device Fingerprinting (DFP) deploys one of the industry's strongest user-agent deception detection engines that looks at a wide range of signals to ultimately determine if a user's request was legitimately made by the claimed browser or if data from the user agent has been spoofed and is operating from different browsers. Even under challenging scenarios such as incognito browsing and VPN use, Stytch’s Device Fingerprinting solution merges industry-standard and proprietary signals to guarantee stable and unique identifiers.

The core of Stytch’s Device Fingerprinting product is a JavaScript library that gathers various device attributes and sends them to Stytch’s backend for processing. This approach creates a telemetry ID that can be used to identify and block fraudulent actors with precision.

To learn more, chat with an authentication expert today or get started to see how Stytch can help you spot and stave off digital deception before any serious harm is done.



---


# SAML certificates explained
Source: https://stytch.com/blog/saml-certificates/

In this article, you’ll learn about SAML certificates and how identity providers and service providers use them to maintain the integrity and authenticity of SAML messages. We’ll also explore the structure of SAML certificates to show you how signing certificates may differ from encryption certificates based on key usage.

SAML certificates are digital certificates used within the SAML (Security Assertion Markup Language) protocol to establish trust and secure connections between identity providers (IdPs) and service providers (SPs).

These certificates are typically X.509 certificates which contain a public key, a digital signature from a trusted certificate authority (CA), and metadata about the certificate holder. Within SAML SSO (single sign-on) flows, they can be used to either sign, encrypt, or decrypt SAML messages (mostly responses and assertions).

In this article, you’ll learn about SAML certificates and how identity providers and service providers use them to maintain the integrity and authenticity of SAML messages. We’ll also explore the structure of SAML certificates to show you how signing certificates may differ from encryption certificates based on key usage. Finally, we’ll discuss some of the most common SAML certificate errors and provide best practices for dealing with these errors in both test and production environments.

The X.509 certificate standard

The X.509 certificate standard is a public key infrastructure (PKI) framework that defines the format, structure, and content of public key certificates used to verify the authenticity of digital identities over networks. It was first introduced by the International Telecommunication Union (ITU) in 1988 and has since become the most widely used standard for issuing digital certificates.

At its core, an X.509 certificate binds a public key with a specific identity that could belong to an organization or individual, and this binding must be verified by a trusted third party known as a certificate authority (CA). X.509 is used in SAML because the authentication flows between disparate SAML entities (IdPs and SPs) rely heavily on trust relationships, and X.509 certificates provide a standardized and secure way to establish and maintain these trust relationships.

How do SAML (X.509) certificates work?

There are two main types of SAML certificates—signing certificates and encryption certificates—and each type plays a unique role in securing the authentication and authorization data transmitted within SAML authentication flows. IdPs typically use signing certificates to sign the responses and assertions they send to SPs in order to certify their origin and integrity, while encryption certificates are used to encrypt sensitive elements within these assertions, ensuring that only the intended SPs can decrypt and access them.



What are SAML signing certificates, and how do they work?

When an SP sends a SAML authentication request (AuthnRequest) to an IdP via an SP-initiated SAML SSO flow, or when a user directly selects an SP via an IdP-initiated SAML SSO flow, the IdP typically responds by sending a digitally signed SAML response containing assertions about the user.

To sign these SAML responses and assertions, IdPs use signing certificates that contain a public and private key pair. The IdP uses the private key to create a digital signature by generating a cryptographic hash of the assertion’s content and then encrypting this hash. This digital signature is attached to the SAML response and/or assertion, and the corresponding public key (commonly referred to as the verification certificate) is embedded in the signing certificate and shared with the SP, so that it can verify the signature.

When an SP receives a SAML assertion, it uses the public key from the IdP's signing certificate to decrypt the signature and compares the resulting hash with a freshly computed hash of the received assertion. If the hashes match, it confirms to the SP that the assertion hasn’t been altered and is from a trusted IdP with which it has an existing relationship.

While signing certificates are commonly used by IdPs to sign responses and assertions, SPs can also use them to sign the authentication requests they send to IdPs. In such cases, the IdP will extract the SP’s public key from the SAML signing certificate to verify that the request originated from a legitimate SP and not an impersonator.

What are SAML encryption certificates, and how do they work?

When an IdP generates a SAML assertion that contains user attributes or other sensitive data, it often needs to encrypt this data to ensure that only the intended SP can access it. To perform this encryption, the IdP has to use the SP’s encryption certificate, which contains a public key and is provided in the SP’s metadata document.

The IdP typically uses this public key to encrypt sensitive portions of an assertion, such as the attribute and authorization statements. Once encrypted, this data can only be decrypted by the corresponding private key, which is securely held by the SP. This ensures that even if the assertion is intercepted during transmission, its sensitive elements will remain inaccessible to unauthorized parties.

Upon receiving the encrypted SAML assertion, the SP can then use its private key to decrypt the encoded elements, which may be necessary for making authentication and authorization decisions about the user.

While encryption certificates are primarily used by IdPs to encrypt SAML assertions, SPs may also use them to protect any sensitive data they send to IdPs. However, this is less common in standard SAML flows.

It's also important to note that in some SAML implementations, the same certificate may be used for both signing and encryption functions. However, the decision to use separate certificates or a single certificate for both purposes often depends on the specific security requirements and policies of the organizations implementing SAML.

Structure of SAML certificates

Both signing and encryption certificates follow the standard structure of X.509 certificates, even though they serve different functions within a SAML authentication flow. Here’s an example structure of a single SAML certificate that can be used for both signing and encryption due to its key usage extension:



This example structure represents a decoded, human-readable format of an X.509 certificate—it's not the raw certificate data itself (which would be in binary or Base64 format).

Here’s an example of how this SAML certificate will typically look like when encoded in Base64 format:



Now, let’s explore the key elements that make up this X.509-based structure of a SAML certificate in more detail:

Version

This element specifies the version of the X.509 standard a certificate adheres to. This is highly important because the different versions of the X.509 standard define the features and functionalities that can be included in a certificate.

For example, most SAML certificates use version 3, which allows for the inclusion of additional data and functionalities via extensions. These extensions can be used to specify policies, constraints, or additional identity data, and they can be designated as critical or non-critical.

Serial number

The serial number element is a unique identifier assigned to each SAML certificate by the certificate authority (CA) that issued it. This number helps the CA to track and manage all issued certificates.

For example, if a certificate expires or is compromised, the CA uses this number to mark it as invalid. In essence, the serial number is used in certificate revocation lists (CRLs) and other status checks to ensure that compromised or expired certificates are properly handled and don’t remain active or in circulation.

Issuer

This specifies the name of the certificate authority (CA) that issued the SAML certificate. The issuer element is usually presented in the distinguished name (DN) format and includes additional details such as the organization name, unit, country, and more. Service providers use this element to verify that a certificate originates from a trusted CA, which is important for maintaining trust and security in SAML authentication flows.

Signature algorithm

This element specifies the cryptographic algorithm the certificate authority (CA) used to sign the SAML certificate. It details how the signature must have been generated, including the specific algorithm such as RSA or ECDSA, and the associated hash function like SHA-256. This information is essential for verifying that the certificate has been properly signed by a recognized algorithm that meets the required security standards for SAML authentication.

Validity period

​​This element defines the timeframe during which a SAML certificate is considered valid, specified by two dates—the “Not Before” and “Not After” date attributes. These dates ensure that the certificate can only be used within a specific period, preventing the use of inactive or expired certificates, which could otherwise compromise the security of a SAML authentication flow.

Subject

The subject element specifies the entity to which a SAML certificate is issued, typically an identity provider (IdP) or a service provider (SP). This element includes details such as the subject’s distinguished name (DN) or domain name, which helps identify the entity within SAML authentication flows. Additionally, the subject may include other identifiers like the organization name, organizational unit, or even an email address, depending on the certificate's intended use and the issuing authority’s policies.

Subject public key info

This element contains the public key associated with a SAML certificate and the algorithm used to generate it. The public key is a cryptographic key that serves two primary functions in SAML: for verifying digital signatures in the case of a signing certificate, or for encrypting sensitive data in the case of an encryption certificate. It’s part of a key pair, where the corresponding private key (held securely by the certificate owner) is used for signing or decryption, depending on the type of certificate.

Extensions

Extensions are additional fields in a SAML certificate that support extra information or functionality beyond the standard certificate attributes. Common extensions include key usage, which specifies how the key can be used (e.g., whether it’s for creating digital signatures or encrypting data), subject alternative names, which list additional identities for the subject, and extended key usage, which further defines the key's intended purposes (e.g., client or server authentication). These extensions make the certificate more flexible, ensuring it can meet specific requirements and constraints within various SAML SSO use cases.

Signature

The Signature element is the actual digital signature attached to the SAML assertion or response. It's created using the private key associated with the certificate and is a cryptographic hash of the assertion's content, which is then encrypted. This digital signature is used by the service provider (SP) to verify that a SAML response or assertion hasn't been tampered with and that it originates from a trusted identity provider (IdP). During verification, the SP typically uses the IdP's public key to decrypt this signature and compare it with a freshly computed hash of the received assertion.

Certificate authority (CA)-signed certificates vs self-signed certificates in SAML

Choosing between certificate authority (CA)-signed certificates and self-signed certificates is an important decision that defines the level of security and trust between SAML entities.

CA-signed certificates are issued and validated by a trusted third-party authority, making them the preferred choice for most production SAML environments. By relying on a CA, both the IdP and SP can be confident that a SAML certificate has been thoroughly vetted and is less likely to be involved with malicious activity.

On the other hand, self-signed certificates are generated and signed by the same entity that intends to use them, without requiring third-party verification. While they offer the same cryptographic capabilities as CA-signed certificates, they don’t provide the same level of trust because they lack external validation.

Self-signed certificates are typically used in development or tightly controlled production environments such as corporate intranet systems where functionality is the primary concern, rather than security. They allow developers to quickly establish SAML connections without needing an external CA.

Common SAML certificate errors

There are several certificate-related issues that can disrupt SAML SSO flows and cause authentication errors. Knowing how to identify these certificate errors is the only way to troubleshoot and fix them in no time.

Here are some of the most frequent certificate errors you may experience, whether you’re working with SAML certificates in development or production:

1. Certificate mismatch: A certificate mismatch error typically occurs when the certificate presented by the sending entity, whether it’s an IdP or SP, doesn’t match the one expected by the intended recipient. This could happen if the IdP or SP updates its certificate but fails to update the corresponding metadata or notify the other party of the change.

2. Certificate revocation: When a sending party uses a certificate that has been revoked by the CA (usually due to compromise or key loss) without checking its status on Certificate Revocation Lists (CRLs) or the Online Certificate Status Protocol (OCSP), it will result in a revocation error.

3. Invalid certificate signature: This error occurs when the intended recipient is unable to verify the certificate’s digital signature with the associated public key. This might be due to a data mismatch, but could also indicate that the certificate was tampered with or corrupted during transmission, possibly signifying a security breach or an attempted man-in-the-middle attack.

4. Self-signed certificate rejection: This error occurs when a self-signed certificate is presented in a SAML environment configured to accept only CA-signed certificates. While self-signed certificates can be used in high-trust SAML scenarios, most systems will reject them by default for security reasons.

5. Incomplete certificate chain: This error occurs when a SAML recipient is unable to fully validate the certificate chain, which usually consists of the end-entity certificate, intermediate certificate, and root certificate. If any part of this chain is missing or incorrect, the recipient won't be able to trust the SAML message.

6. Incorrect key usage: As we’ve seen so far, version 3 SAML certificates have specific key usage extensions that define their intended purpose (e.g., digital signature, key encipherment). If a recipient attempts to use a certificate for a purpose not specified in its key usage extension, they will encounter this error.

7. Untrusted certificate authority: This error happens when a certificate is signed by a CA that isn’t trusted or recognized by the intended recipient. This could occur if the sending party uses certificates from lesser-known CAs or if the CA’s root certificate isn’t installed in the recipient’s trust store.

Best practices for managing SAML certificates

To effectively manage both encryption and signing SAML certificates in production, we’ve outlined the most common best practices for certificate holders and recipients:

1. Use separate certificates for signing and encryption

While it’s possible to use a single certificate for both signing and encryption in SAML, it's best to use separate certificates for these functions. This separation reduces the risk of a single point of failure and minimizes the potential impact if either of the certificates is compromised.

Also, using distinct certificates simplifies how you manage the lifecycle of each certificate and handle key rotation. If you need to make changes to one certificate (e.g., for signing), you can do so without affecting the other certificate meant for encryption.

2. Maintain accurate and up-to-date metadata

When updating or replacing certificates, it’s best practice to ensure the associated metadata is updated and correctly distributed to all relevant SAML entities, whether IdPs or SPs. Failing to update metadata files can lead to certificate mismatch errors, where entities attempt to validate a SAML message against an outdated or incorrect certificate.

3. Avoid using self-signed certificates in production

While self-signed certificates might be convenient for development or controlled environments, they’re generally not recommended for production. Self-signed certificates lack the external validation that CA-signed certificates provide, making them less secure.

4. Use trusted Certificate Authorities (CAs)

Only use certificates issued by reputable and well-established certificate authorities (CAs) that are trusted by your recipients (IdPs or SPs). Trusted CAs have undergone rigorous vetting and follow industry-standard security practices, which adds a layer of confidence in the validity and integrity of your certificates.

5. Use strong cryptographic algorithms and key lengths

Always ensure that the certificates you send or receive are issued by a CA that employs robust cryptographic algorithms (e.g., RSA with SHA-256) and adequate key lengths (at least 2048 bits for RSA). Avoid deprecated algorithms like SHA-1 or MD5, which are no longer secure and may lead to vulnerabilities in your SAML authentication flows.

6. Establish proper certificate lifecycle management

As a certificate holder, you should establish clear policies and procedures for managing your SAML certificates, including issuing, renewing, revoking, and replacing certificates. The only way to prevent unexpected authentication failures for SPs or any other recipient of SAML messages is for certificate holders to implement a proper certificate lifecycle management process.

Also, both sending and receiving parties should keep a detailed inventory of all certificates used within their SAML environment, including details such as the issuing CA, expiration dates, key usage, and the systems or applications where each certificate is deployed.

Getting started with Stytch SAML SSO

Ready to implement SAML SSO in your B2B SaaS app? Stytch has done all the heavy lifting for you.

We make it super easy for your engineering team to go live with SAML without worrying about all the certificate errors and best practices we just discussed. You can check our SAML SSO docs and sign up for a free developer account to get started.

For questions about our features or pricing, contact us at support@stytch.com or schedule a call with one of our Solutions Engineers.



---


# Adaptive MFA: A smarter approach to authentication security
Source: https://stytch.com/blog/adaptive-mfa/

Adaptive Multi-Factor Authentication (MFA) is an advanced security method that uses contextual information and business rules to determine which authentication factors to apply to a user in a given situation. This article explains what adaptive MFA is, how adaptive authentication works, why it’s vital for strong identity security, and what comprises a best-in-class adaptive MFA solution in the rapidly evolving AI-powered era.

In today's busy digital ecosystems where both UX and security are paramount, it's crucial to match your security responses to the appropriate threat levels at play so as not to disturb the user experience.

Adaptive Multi-Factor Authentication (MFA) is an advanced security method that uses contextual information and business rules to determine which authentication factors to apply to a user in a given situation. This article explains what adaptive MFA is, how adaptive authentication works, why it’s vital for strong identity security, and what comprises a best-in-class adaptive MFA solution in the rapidly evolving AI-powered era.

Understanding adaptive MFA

Adaptive MFA dynamically adjusts authentication requirements based on contextual factors like device type, IP address, and user behavior to balance strong security with a seamless user experience. By stepping up (increasing) or stepping down (reducing) the authentication process depending on the user's context, adaptive MFA allows trusted devices to log in with minimal friction, while adding extra layers of security for unfamiliar or suspicious activity. This flexibility lets organizations tailor authentication strategies to each device that attempts to log into their applications, ensuring robust protection while enhancing the user experience.

The shortcomings of traditional MFA

Traditional MFA can create unnecessary friction through enforcing the same security requirements for all users, regardless of their individual risk profiles. Every user must complete a secondary authentication step, such as entering a code from a mobile app or receiving a one-time password (OTP) via SMS. While this approach adds a layer of security, it can frustrate legitimate users by requiring them to perform extra steps during each login, even if they are using a familiar device or logging in from a trusted location.The blanket approach of traditional MFA also fails to account for varying levels of risk and can frustrate users who face repetitive and unnecessary challenges, leading to a poor user experience. Moreover, traditional MFA can be less effective at stopping more modern, advanced attack vectors, as it doesn’t adapt to emerging risks in real-time. If an attacker manages to compromise a user’s credentials and obtain access to their second factor (e.g., through phishing or SIM swapping), traditional MFA might not provide adequate protection, as it doesn't dynamically adjust based on suspicious behavior or unusual login contexts. Ultimately, the rigid, one-size-fits-all approach of traditional MFA can undermine both security and UX.

Adaptive MFA in action

Here’s a few examples of the types of user behaviors or indicators that might be interpreted as a trusted user vs a suspicious user in the eyes of adaptive MFA when logging into an app:



Trusted user: A user logs in from their home device during regular business hours. The system recognizes the device and location as consistent with their previous login patterns. Because the risk is low, adaptive MFA allows the user to access the app with just their password, streamlining the login process and reducing unnecessary friction. The user enjoys a smooth and efficient experience, quickly accessing the application without additional authentication steps.



Suspicious user: A login attempt is made with the correct username and password but using an unfamiliar device with a different operating system than the user typically uses. The adaptive MFA system detects that the login attempt is from a new device and that the browser's or device’s characteristics doesn’t match the user’s usual profile, such as indicating an outdated browser version or an operating system they have never logged in from before. These inconsistencies trigger a higher risk score. In response, the system steps up the authentication requirements, prompting the user to verify their identity through a second factor, such as entering a one-time password (OTP) sent to their email or performing biometric verification. If the user fails to complete these additional steps through consecutive login failures, consecutive login attempts, or if the system detects further anomalies (e.g., the browser environment appears manipulated or tampered with), access is denied.

How adaptive MFA works

Adaptive MFA is about creating rules that use contextual data to determine when to challenge a user with additional authentication steps. These rules can be as simple as a denylist of forbidden attributes (e.g., certain countries, device types, or public IP addresses) or as complex as a dynamic risk matrix that evaluates multiple factors in real time. Developers have the flexibility to define the "adaptive" mechanism based on their security needs, whether through a decision flow chart, cumulative risk scoring, or hard coded allow/deny lists.

The system continuously assesses various factors, such as geographical or physical location, registered devices, user roles, IP address, browser type, software versions, time of login, attempted action, and operating system. Each login attempt is evaluated against these criteria, with decisions made based on predefined rules or real-time risk assessments.

Here are a few examples of adaptive MFA rules:

If a login attempt comes from an unusual location or an unrecognized device, prompt the user for additional verification.

A user logging in from a trusted device or secure corporate network might only need to enter their password, while a login attempt from a public Wi-Fi network triggers an MFA challenge.

If the system detects high-risk behavior, such as an unusual browser version or an inconsistent device fingerprint, it requires additional authentication steps like a one-time password (OTP) or biometric verification.

By allowing developers to tailor these rules to their specific security needs, adaptive MFA can provide a more flexible and efficient approach than traditional MFA. It can seamlessly adjust to each unique login scenario, offering strong protection without unnecessary friction.

Key benefits of adaptive MFA

Ultimately, adaptive MFA leverages contextual insights to deliver a secure, user-friendly authentication experience that adapts in real-time, keeping both security and usability in balance. It improves an organization's security posture while also supporting user productivity.

Improved security: Adaptive MFA enhances enterprise security by continuously assessing risks during login attempts and adjusting authentication requirements accordingly. This dynamic approach adds layers of protection based on real-time risk assessments, making it difficult for attackers to gain unauthorized access, even with compromised credentials. By customizing security measures to the assessed risk level, Adaptive MFA ensures that high-risk scenarios are met with stronger defenses, protecting business applications and data effectively.

Better productivity: Adaptive MFA improves productivity by reducing the friction of traditional MFA systems. Users logging in from recognized devices or during regular hours face fewer authentication challenges, allowing faster access to applications and data. By intelligently assessing login risks, adaptive MFA minimizes unnecessary authentication steps, enhancing user convenience and streamlining workflows, which boosts overall efficiency within the organization.

These benefits are further amplified by advances in AI and machine learning, which enable systems to make real-time decisions and respond rapidly with the required step up or down to increase, or reduce, login friction.

Best practices in modern Adaptive MFA

Effective adaptive MFA starts with a strong baseline MFA solution that uses a combination of authentication factors, such as something you know (password), something you have (passkey), and something you are (biometric). If one factor is compromised, the overall security remains intact.Best-in-class adaptive authentication solutions monitor user behavior over time, establish baseline profiles, and flag anomalies. This allows the system to assign risk scores to suspicious events and adjust authentication factors in real-time.

Dynamic access policies

To establish baseline profiles for users, dynamic access policies are created using contextual information to determine user access and access management authentication factors. Each time a user attempts to authenticate, the request is evaluated and assigned a risk score based on the established user profile, which includes information such as location, registered devices, and user role. This dynamic assessment allows the system to adapt in real-time, supporting seamless, secure authentication that can evolve with a business’ changing needs.

Single sign-on

Integrating Single Sign-On (SSO) with adaptive MFA further helps streamline authentication. SSO allows users to access multiple applications with a single set of credentials, simplifying the login process and reducing the need to remember multiple passwords. When combined with adaptive MFA, it adds an additional layer of security by vetting each login attempt before granting access. Adaptive MFA can be easily integrated with existing SSO solutions.

MFA and Device Fingerprinting from Stytch

Adaptive MFA is only as effective as the quality of its data. Without accurate, comprehensive information about users, devices, and environments, even the most sophisticated adaptive MFA rules can fall short. Poor data quality can lead to false positives, unnecessary friction, or, worse, security gaps.

Stytch Device Fingerprinting (DFP) collects fine-grained device-related data, allowing you to build more accurate user profiles and confidently distinguish between legitimate users and potential threats. The solution enhances adaptive MFA by offering precise and reliable returning user identification. For developers and businesses alike, this combination results in a more seamless user experience without sacrificing security. By utilizing Stytch's DFP as part of your MFA flow, you can confidently reduce friction for legitimate returning users while dynamically increasing friction for potential bad actors.

This approach not only minimizes the drop-off that can occur when users face unnecessary MFA challenges but also ensures that unauthorized users cannot gain access, even with stolen credentials, unless their device passes the DFP check. For developers focused on growth and user conversion, adaptive MFA with Stytch’s DFP can help retain users by providing a login experience that feels secure yet unobtrusive.

Stytch's advanced browser deception detection capabilities provide a strong foundation for future security enhancements, with AI and ML at the backbone. With this combination of cutting-edge technology and seamless integration in to your existing systems, we can confidently claim we have one of the most powerful adaptive MFA solutions around.

Open-source example app with adaptive MFA



For developers, we have an open-source example app that demonstrates how to leverage Stytch's Device Fingerprinting (DFP) product to power adaptive MFA, where users are only required to complete MFA if they are logging in on a new device. 

Clone the repo on GitHub to see the code in action.

To learn more about Stytch's Fraud & Risk Prevention solutions, get in touch with an auth expert today, or create an account to get started.



---


# Auth0 2024 Pricing Update: What They’re Hiding About the Real Cost
Source: https://stytch.com/blog/auth0-2024-pricing-update/

Learn about Auth0’s recent 2024 pricing changes and how they impact enterprise and startup customers. Despite some promising updates, the new terms reveal several hidden costs and restrictions that could lead to significant price increases as your usage grows.

Today, several pricing changes were announced for Auth0. Since Okta acquired Auth0 in 2021, most adjustments have resulted in rate increases for enterprise and startup customers. However, today’s changes deserve more attention as they appear, on the surface, to provide significant value.



The changes are described as a benefit to the customer. Specifically, they’ve raised the number of included monthly active users (MAUs), provide access to passwordless features, and claim to now include “unlimited” Okta SSO Connections". But a closer examination of these changes and their pricing terms reveal that a lot of the bait-and-switch tactics Auth0 has become notorious for are even more egregious.

Let’s evaluate some of these claims further to see what you’re actually getting with Auth0’s new pricing.

Does Auth0 really offer Unlimited Okta Connections?

Auth0's promotion of Okta Connections—a type of Enterprise SSO connection—as 'unlimited' seems too good to be true. And unfortunately it is. If you look closer at the terminology and what’s defined as an "Okta Connection," you'll find that the only connection type with unlimited usage is a specific variation of Okta OIDC connection configured via an "Okta Workforce" setup.



This matters because, if you're supporting SSO for your B2B SaaS application, there are two key elements not included that actually make up the bulk of your costs:

1. Okta SAML connections are an additional, undisclosed amount

The offer only covers Okta OIDC connections, which, according to our data, typically represent less than 10% of all SSO connections. In other words, when a customer requests Enterprise SSO support, they are more likely to require a SAML connection, which is not covered by this offer. You’ll still need to pay for SAML connections with Auth0, but they won’t tell you how much those connections cost unless you speak directly with sales. Pricing isn’t disclosed on their site.

2. OIDC and non-Okta SAML connections are also an additional, undisclosed amount

This offer does not include connections for providers like Google, Ping, or Azure. Once again, Auth0 does not disclose the pricing for these connections, making it difficult to estimate the actual cost of using them.



In other words, 'Unlimited Okta Connections' really means something more like "a trivial discount on some of your Enterprise SSO connections in order to hide the costs of your other primary SSO connections. And we'd rather not share what those cost are unless you talk to us live."

What’s hiding behind the increase in “free” MAUs?

Another key update from Auth0’s pricing changes is the increase in monthly active users (MAUs) included in the Free plan, from 7,500 to 25,000.



This is a 3X increase, which might seem generous at first glance. However, what they don’t tell you is that you can’t actually use that plan if any of the following conditions apply:

You want to use your own domain (rather than something like myapp.auth0.com)

You need multi-factor authentication (MFA)

You need roles & permissions (RBAC)

You need performant bot protection

You want support beyond their community forum

You want more than 5 organizations

You want more than 5 SSO connections that aren’t Okta OIDC

And more than a dozen other exceptions…

If you’re just testing Auth0 and don’t need any of these additional features, the increase in free MAUs is a welcome improvement. However, if you’re building a production app or even validating a proof of concept, then the Free plan is likely off the table and these changes won't matter to you.

Unfortunately, the caveats don’t end there. You also need to consider the following:

There are hard caps on MAUs in Auth0's self-service plans: If you look closer at Auth0’s pricing plans, you’ll find a hard cap of 30,000 MAUs for B2C and 10,000 MAUs for B2B. That’s a pretty low limit for a growing app. At Stytch, we’ve seen engineering teams that were with Auth0 face large unexpected surges in annual costs—sometimes from around $3k to high five-figures or low six-figures—when they hit these limits. Worse, they often feel completely blindsided by these hidden pricing details, finding themselves forced into expensive enterprise agreements just as their app gains traction, with neither the time nor resources to migrate away.

MAU pricing gets very expensive beyond Auth0's Free plan: Auth0’s MAU pricing becomes quite expense once you move beyond the Free plan. For example:

B2C Pricing: You’ll pay 7 cents per MAU on the Essentials plan and it shoots up to 16 cents per MAU on the Professional plan.

B2B Pricing: You’ll pay a whopping 23 cents per MAU on the Essentials plan and 24 cents per MAU on the Professional plan.

When you exceed the 30,000 MAU threshold for B2C or 10,000 MAUs for B2B, quotes typically rise to 30 cents or more per MAU.

Conclusion: More of the same obfuscation

Auth0’s latest pricing changes are positioned as offering more value and flexibility, but this really only applies to simple starter apps using the Free plan. Any actual improvements to pricing are overshadowed by what seems to be a continuation of their strategy to obscure the true costs and the various ways you’ll outgrow the Free plan’s limits. It feels like a classic bait-and-switch, where engineers are lured into investing heavily in Auth0 before realizing that much of the terminology (e.g., "Unlimited Okta Connections") is designed to make them think they’re getting a better deal than they actually are. This approach often leaves developers stuck with Auth0, facing significant unexpected costs at a time when migration has become too expensive and difficult.

We had hoped this pricing overhaul would address some of Auth0’s price transparency issues that have historically misled developers, but instead, they seem to have doubled down with this latest revision.





---


# Top strategies to prevent web scraping and protect your data
Source: https://stytch.com/blog/web-scraping/

In this article, we'll go over what web scraping is, its legitimate uses, as well as how it's used for fraud and the top strategies you can implement to safeguard your data from these automated threats.

Top strategies to prevent web scraping and protect your data

Web scraping is the automated process of collecting and extracting data from websites. This technique typically involves the use of software tools or scripts, bots, or headless browsers that navigate web pages and gather information, which can then be stored and analyzed for various purposes, such as market research, content aggregation, or competitive analysis.

As with many useful tools and techniques, fraudulent actors often take advantage of web scraping to expose private data by scraping it from various websites. As a result, more businesses and organizations are taking measures to prevent web scraping and protect their data.

In this article, we'll go over what web scraping is, its legitimate uses, as well as how it's used for fraud and the top strategies you can implement to safeguard your data from these automated threats.

Understanding web scraping

Web scraping is automated web data extraction from websites, a process that has become increasingly sophisticated over time. Initially, web scrapers used simple bots to extract data, but modern techniques now include the use of AI-driven tools that employ machine learning to interpret and adapt to dynamic web environments. This evolution makes the task of distinguishing between legitimate users and malicious bots more challenging than ever.

Scripts, bots and browsers

The core of web scraping involves programming bots to mimic user interactions with websites. These bots use technologies such as automated scripts, headless browsers, and HTTP requests to extract data by impersonating legitimate (human) users. For instance, a web scraper might simulate a user browsing through pages and clicking on links to gather information. This can be particularly problematic for websites that rely on user engagement and interaction for their business models as such undesirable traffic not only threatens security but heavily skews engagement metrics

To the credit of how the technology has evolved, web scrapers are often indistinguishable from real users. They can load the initial HTML web page, parse the content, and extract data such as product prices and stock levels to user reviews and contact information with ease. The scraped data is then stored and used for various purposes such as useful competitive analysis or malicious data theft. We'll cover the former benign utility of web scraping first to better understand how the technique came to be so prevalent .

Legitimate uses of web scraping

Web scraping is a powerful tool employed by developers for various legitimate purposes across multiple industries, such as:

QA testing for web apps: Developers can use web scraping to automate testing processes, ensuring that web applications perform consistently across different environments and updates. Scraping tools can simulate user interactions, helping to identify bugs or issues in user-facing features.

API development and verification: Web scraping helps developers ensure that APIs are working correctly by extracting data and verifying responses. This is particularly useful when testing integrations between web applications and external services or APIs.

Data pipeline creation: Developers use web scraping to gather and structure large datasets from different sources as part of data pipeline creation. Scraped data can be used for machine learning models, analytics, or other data-driven applications.

Continuous integration/continuous deployment (CI/CD) verification: During CI/CD processes, developers can use web scraping to verify that updates to a web application do not break existing functionality. Automated scripts can scrape content after deployments to confirm that changes are successfully integrated.

Automated workflows and form submissions: Scraping tools can automate repetitive tasks such as filling out forms or navigating through workflows, which is particularly useful for internal testing or operational automation. Developers use this technique to streamline processes like user onboarding or data entry validation.

Malicious Web Scraping

Web scraping's darker side is perpetrated by individuals and organizations who misuse the technology for harmful purposes. Here are some of the most common forms of malicious web scraping:

Data harvesting: Collecting personal information such as emails, phone numbers, and social profiles to sell to third parties, infringing on user privacy.

Click fraud: Automated bots click on online advertisements to generate false revenue, leading to financial losses for advertisers.

Price scraping: Competitors scrape pricing data to undercut legitimate businesses, disrupting fair market practices.

Content theft: Copying content from websites without permission, potentially damaging the original creator's brand and search engine rankings.

API Abuse/Resource Abuse: Automated scraping tools excessively call APIs or abuse server resources, overwhelming infrastructure and leading to increased costs or degraded performance for legitimate users. This abuse can result in higher operational costs and potential service outages for businesses.

A strong awareness of the above methods can help organizations, developers and their teams implement effective strategies to combat harmful scraping activities. Historically, this has been a difficult challenge, requiring strong bot and automated browser detection alongside refined, well-rehearsed mitigation techniques.

Technology and techniques to prevent web scraping

Preventing web scraping is challenging due to the broad targeting capabilities of scrapers, which can access any public-facing application within a domain. Scrapers often mimic real user behavior, such as browsing pages and interacting with forms, and most scraping attacks use simple HTTP GET requests that are hard to differentiate from normal traffic, complicating detection.

Despite these challenges, implementing a combination of best practices and advanced techniques is crucial to protect valuable data, maintain website performance, and ensure fair use of online resources. These methods, while not foolproof, provide a solid foundation for protecting your data.

IP Blocking

IP blocking restricts access based on a user’s IP address to prevent web scraping, effectively blocking known malicious IPs. While useful, it has limitations, as scrapers often rotate IP addresses and use proxy servers or VPNs, complicating detection. Geographic restrictions can enhance its effectiveness, but IP blocking should be combined with other security measures to ensure comprehensive protection.

CAPTCHA

CAPTCHA challenges help distinguish between humans and bots by requiring users to complete puzzles or tasks. Adaptive CAPTCHAs adjust their difficulty based on user behavior, making them effective against scrapers. However, they can frustrate users and be bypassed by sophisticated scripts. Despite these drawbacks, CAPTCHAs provide an additional layer of security when combined with other methods like IP blocking and firewalls.

Firewalls

Firewalls, especially Web Application Firewalls (WAF), filter traffic and block requests that exhibit scraping behavior. They can identify patterns like repeated access from the same IP or traffic spikes and prevent scrapers from extracting data. Proper configuration and regular updates are essential to avoid blocking legitimate users, and firewalls should be part of a multi-layered defense strategy alongside IP blocking and CAPTCHA. 

Rate limiting and request throttling

Rate limiting controls the number of requests a single IP or user agent can make within a specific timeframe, slowing down scrapers and protecting server resources. Request throttling complements this by controlling the speed at which requests can be made, reducing the overall traffic pace without fully blocking access. Together, these methods can temporarily block or slow down IPs that exceed set thresholds, making them effective in mitigating the impact of high-volume scrapers.

Obfuscation and dynamic content loading

Obfuscation and dynamic content loading are advanced techniques that make data extraction harder for scrapers. Obfuscation involves altering HTML structures, IDs, and classes, or using JavaScript to dynamically load content, complicating scraper efforts. Dynamic content loading, such as lazy loading or AJAX requests, delays content display, making it harder for basic HTML parsers to access data. However, these techniques can also hinder real users and complicate legitimate access, so balancing them with user experience is essential.

Stytch Device Fingerprinting

Stytch's Fraud & Risk Prevention solution offers major improvements over all traditional anti-web scraping technologies by leveraging Device Fingerprinting (DFP), which uniquely identifies devices accessing a website by collecting various attributes from user devices. This includes details like network, screen resolution, operating system, and active plugins, which are combined to create a unique identifier for each device. Accurately identifying devices through DFP aids in the precise detection of scraping activities. 



With device fingerprinting, Stycth's Fraud & Risk solution enables developers to use features such as: 

Invisible CAPTCHAs: Deliver stronger, invisible CAPTCHAs that use Stytch fingerprinting to ensure the device solving them is the same one that received them, not a CAPTCHA farm or an AI agent.

Intelligent Rate Limiting: Dynamically rate limit anomalous traffic based on analysis of device, user & traffic sub-signals.

Security Rules Engine: Programmatically define access rules for different types of traffic visiting your app

ML-Powered Device Detection: Gain zero-day threat detection and protect your app with Stytch's supervised ML model to detect and categorize new threats in real time.

Stytch Device Fingerprinting creates unique identifiers and leverages advanced techniques to combine various device attributes, such as browser type, screen size, and operating system, to create a robust and tamper-resistant fingerprint. The solution provides clear action recommendations, such as ALLOW, BLOCK, and CHALLENGE, based on the detected device’s behavior.

By employing Stytch Device Fingerprinting, businesses can enhance their detection capabilities against web scraping attempts, ensuring comprehensive data protection and maintaining the integrity of their online resources.

To learn more about Stytch DFP and it’s powerful ability to identify devices across your web traffic to prevent web scraping, get in touch with an auth expert, or get started using Stytch, today.





---


# Anti-spoofing tools and techniques 
Source: https://stytch.com/blog/anti-spoofing/

In this article, we’ll overview preventative anti-spoofing measures, their role in data security, as well as recommend some practical solutions to help you combat them.

Anti-spoofing tools and techniques 

Catching and/or preventing user agent spoofing these days is harder than ever in our high-tech digital environments. Despite the challenge, making investments towards stronger anti-spoofing measures to protect your applications and data will pay enormous dividends in the overall security of your application's business systems.

When spoofing is being used with emails, some authentication protocols can help with anti-spoofing by validating the legitimacy of the email sender. Examples include Sender Policy Framework (SPF), Domainkeys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC), which play a crucial role in anti-spoofing efforts by validating the legitimacy of email senders and safeguarding users' credentials.

But how can you better spot fake data packets, manipulated user agent properties, and unauthorized access attempts before they find a way into your application? In this article, we’ll overview preventative anti-spoofing measures, their role in security, as well as recommend some practical solutions to help you combat them.

Understanding anti-spoofing

Anti-spoofing technology should be part of any modern, sophisticated security solution. It is specifically designed to identify and block spoofing campaigns online, which can take various forms (and are always evolving). Attackers often use spoofing techniques, such as IP address masking via VPNs, proxies, and botnets, to gain access to business networks, circumventing security measures and posing serious threats to sensitive information. The primary goal of anti-spoofing technologies is to prevent unauthorized access by confirming the legitimacy of incoming data and separating the welcome from the wicked.

On a technical level, anti-spoofing technology protects networks by identifying the techniques malicious actors use to impersonate requests made by legitimate devices. 

Common types of spoofing attacks

Spoofing attacks seek to replicate trusted sources to deceive victims and access sensitive information. Recognizing various spoofing attacks is crucial to understanding the anti-spoofing measures needed to combat them.

IP spoofing is a common technique where bad actors send packets from multiple different IP addresses to mask their identity and location. This technique is often used in Denial-of-Service (DoS) attacks to overwhelm a target system with traffic, causing disruptions. This also can be in the form of IP address masking via VPNs, Proxies, or compromised machines in a botnet.

User agent spoofing is a technique where attackers change the User-Agent header in HTTP requests to disguise the type of client they are using (e.g., making a bot appear as a legitimate browser).

Header spoofing is a technique that involves manipulating HTTP headers to fake different aspects of the request, such as language preferences, encoding, or security headers.

Session token spoofing is a technique where an attacker steals or forges session tokens to gain unauthorized access to an application.

Easily-integrated, holistic solutions are necessary to protect against various spoofing attacks, combining anti-spoofing measures to safeguard organizations from unauthorized access on multiple fronts and maintain the integrity of their systems.

How anti-spoofing technology works

In anti-spoofing, filtering mechanisms are employed to detect spoofed packets or device attributes. These mechanisms often utilize rules set on network gateways like firewalls or routers to identify and block malicious data by examining incoming packets. Ingress filtering is a common method used to check packets with conflicting source IP addresses, ensuring that incoming packet traffic is legitimate. Source address validation ensures incoming IP packets match legitimate network ranges.

Packets originating from the internal network are automatically dropped if they present conflicting source IP addresses, illustrating how rules at network gateways like firewalls or routers are used to enhance security. Packets can also be filtered out by passive request properties leaked by the senders machine using more advanced techniques like TLS fingerprinting

Modern anti-spoofing technology implements packet blocking by recognizing and blocking code that matches known spoofing patterns. Device fingerprinting technology, an increasingly powerful tool in fraud prevention, plays a vital role in this process by collecting various device attributes to create a unique identifier, which helps in recognizing and blocking fraudulent activities.

As noted, spoofing tactics are constantly evolving. These days, AI and machine learning are increasingly used to process complex data and adapt to new spoofing tactics. A layered strategy to identify and stop spoofing attempts early should combine multiple methods to enhance effectiveness.

Anti-spoofing for network security

Continuous monitoring and auditing of network traffic and user activities help identify potential spoofing attacks. Intrusion detection and prevention systems look for unusual patterns in network traffic that might indicate a spoofing attempt, while device and browser fingerprinting enable businesses to detect and respond to potential threats effectively, even when users try to conceal their identities.

Implementing these measures often involves a trade-off between security and user experience, making it challenging to achieve high security without inconveniencing users. However, the benefits of enhanced privacy and protection often outweigh these challenges. A solution like Stytch that can easily integrate into your existing system through modular APIs and SDKs makes the most sense for many businesses looking to streamline resources.

Stytch fraud prevention solutions for anti-spoofing

Stytch offers one of the industry’s strongest user-agent deception detection engines, capable of spotting automated attacks and spoofing attempts. 

Stytch Device Fingerprinting (DFP) is designed to provide robust protection against identity spoofing by creating stable, consistently repeatable identifiers for each user device. At its core, DFP employs a heavily obfuscated JavaScript fingerprinting script to gather and analyze device signals securely. This allows for the precise creation of telemetry IDs that can identify and block fraudulent actors. It ensures that requests are genuinely made by the claimed browser, maintaining integrity and security. This combination of industry-standard and proprietary signals means that each device can be accurately identified and monitored.



Stytch Device Fingerprinting solution also leverages ML-Powered Device Detection to detect and categorize new threats, device types, and spoofed attributes in real time.

By employing Stytch Device Fingerprinting, applications can enhance their detection capabilities against any spoofing techniques, ensuring comprehensive security measures and a seamless user experience.

To learn more about Stytch DFP and it’s powerful ability to identify devices across your web traffic to prevent spoofing, get in touch with an auth expert, or get started using Stytch, today.





---


# Top techniques for effective API rate limiting
Source: https://stytch.com/blog/api-rate-limiting/

Learn top techniques for effective API rate limiting to enhance performance and security. Explore strategies like token bucket, sliding window, and Stytch Device Fingerprinting.

API rate limiting is a critical mechanism that governs the number of requests a client can make to an API within a specific time frame. For developers, it acts as a safeguard against certain types of attacks and excessive use of resources, preventing potential server overloads that can lead to degraded performance or downtime.

This article will walk you through what API rate limiting is, its importance in protecting against attacks, and some best practices to effectively implement rate limiting strategies.

Understanding API rate limiting

API rate limiting is a set of rules or logic that limits how often a user or application can interact with an API. This practice serves multiple purposes, including preventing server overload, safeguarding the API, ensuring stability, security, and fairness, and ultimately improving user experience. API rate limits are typically expressed as the maximum number of requests allowed within a defined time frame.

Rate limiting supports fair usage by preventing resource monopolization and allowing equal access for all users. With no api rate limit exceeded, no single user or application can consume all resources, maintaining a balanced and efficient API service for all users.

Why does API rate limiting exist?

API rate limiting as a concept did not have a single inventor but rather evolved over time as the need for more reliable and scalable web services grew. Rate limiting techniques began to be more formally defined and implemented by major companies during the mid-2000s. One of the early adopters was Twitter, which introduced rate limiting to manage the massive influx of requests from third-party developers building on its API. Google and other tech giants soon followed, realizing that without such measures, their APIs could be overwhelmed, leading to service outages or degraded performance for all users.

Protecting against bot attacks

One of the most significant benefits of API rate limiting is its ability to serve as a frontline defense against various forms of abuse, particularly denial-of-service (DoS) attacks. In a DoS attack, an attacker attempts to overwhelm a server with a massive volume of requests using a network of bots and machines, with the goal of exhausting the server's resources and rendering the service unavailable to legitimate users. 

Beyond DDoS attacks, bad actors also leverage bots to abuse APIs for  other malicious activities like scraping data, attempting brute-force login attempts, or abusing rate-limited resources. This makes bots a persistent threat to any API.

API rate limiting is a crucial protective measure that helps mitigate such attacks by controlling the volume of requests that can reach the server within a given time period.

Prevent free account abuse 

Implementing rate limits is crucial to ensure that legitimate users can access the API without disruptions incurred from abusive or excessive requests. A common example of abuse occurs with free-tier accounts, where users may create multiple accounts or use automated scripts to exceed the allotted limits, exploiting the system for unauthorized gains.

By preventing the misuse of API resources, rate limiting allows legitimate users to utilize the services without facing interruptions. This ensures a fair distribution of resources, preventing any single user from monopolizing the API.

Device fingerprinting (DFP) technology further enhances rate limiting by uniquely identifying devices, which allows for intelligent and dynamic rate limiting strategies. By accurately identifying individual devices, DFP helps enforce fair usage and improve overall API performance and security. More on Stytch DFP below.

Stopping accidental misuse

Not all high-traffic scenarios are the result of malicious intent. Sometimes, well-meaning developers can accidentally misuse an API by sending too many requests, perhaps due to a bug in their code or a misunderstanding of the API's expected usage patterns. Rate limiting helps to protect your infrastructure from these accidental bursts of traffic. By setting clear limits, you can mitigate rate limit errors by ensuring that your API remains stable even when clients inadvertently exceed intended usage levels.

Improving API performance

Rate limiting is essential for balancing customer access and server stability. Regulating incoming requests significantly enhances overall system responsiveness, boosts customer satisfaction, and manages network traffic. Think of it as driving on the highway during rush hour—without control, the traffic would come to a standstill.

Managing the flow of API requests prevents slow performance and ensures that high-volume requests do not overwhelm the system. This results in a more efficient and memory-efficient API service, benefiting both the API providers and the users.

Rate limiting in practice

Understanding real-world examples of how some major platforms implement API rate limiting can provide valuable insights into best practices and rate limiting challenges. We’ll look at GitHub, LinkedIn, and Google Maps, each employing unique strategies to manage their api calls and API traffic.

GitHub

GitHub’s API rate limits allow up to 5,000 requests per hour for each user access token or OAuth-authorized application. Users can check their current rate limit status on GitHub by sending a GET request to the /rate_limit endpoint. The response provides details such as the user’s limit, the number of used requests, and the remaining requests categorized around each endpoint.

This approach ensures that developers can monitor their API usage and avoid disruptions by staying within their rate limits.

LinkedIn

LinkedIn employs a tiered rate limiting strategy that varies based on the type of API and the user’s access level. For example, LinkedIn's API imposes a different API rate limit for various endpoints, such as profile requests, company lookups, and messaging. The platform provides developers with detailed rate limit headers in API responses, which include information on the current usage and the time until the rate limit resets. LinkedIn’s approach helps balance the need for access to vast amounts of professional data with the necessity of maintaining system stability and preventing misuse. Additionally, LinkedIn may impose stricter rate limits or quotas on specific high-impact endpoints to protect user privacy and data integrity.

Google Maps

Google Maps uses a combination of rate limiting and quota management to ensure fair and efficient usage of its services. Developers can track their API usage through Google Cloud’s console, which provides detailed usage reports and alerts when usage approaches predefined limits. Rate limiting helps manage server load, particularly during peak times or when multiple applications access high-demand services like geocoding or directions.

Google Maps also offers flexible pricing plans that adjust rate limits based on the developer’s chosen tier, allowing for scalability and optimized performance according to the application's needs.

Best techniques for implementing rate limiting

Effective rate limiting requires a balance between enforcing limits to prevent abuse and ensuring that legitimate users can access your services without unnecessary disruption.

API throttling, or throttle control in APIs, restricts requests temporarily and is more aggressive than rate limiting, which focuses on overall request count. While throttle control is effective in preventing immediate overloads, it can be too blunt an instrument when it comes to balancing customer access and maintaining server stability.

For a more balanced approach, API rate limiting methods such as Token Bucket, Fixed Window Counter, and Sliding Window Algorithm, are often used to manage api request traffic in different ways, helping ensure that API services remain stable and responsive under varying load conditions.

Token Bucket Algorithm

The Token Bucket Algorithm manages API requests by using tokens to control allowed requests. Tokens are placed into a bucket at a fixed rate, and each request consumes one token. If there are enough tokens in the bucket, the request is processed; otherwise, it is denied.

This method allows for bursts of requests while ensuring that the overall rate does not exceed the predefined limit. Tokens are replenished at a fixed rate, allowing for a maximum number of requests to be processed over time. This approach is highly effective for managing variable traffic patterns, such as those you might see in e-commerce platforms during flash sales, social media sites experiencing viral content spikes, or streaming services during peak viewing times.

Fixed Window Counter

The Fixed Window Counter method uses an incremental counter to track requests within a defined time frame. This method limits the requests a user can make in a predetermined time frame, resetting after the period ends. If the user exceeds the request limit, additional requests are discarded.

While simple to implement, the Fixed Window Counter method can lead to spikes in traffic at the boundary of the time frame, which may cause instability. However, it remains a popular choice for its straightforward implementation and effectiveness in managing request rates within fixed intervals, and is used commonly for scenarios where predictable, evenly distributed traffic is expected, such as in scheduled data synchronizations, batch processing tasks, or APIs with steady, low-variability workloads.

Sliding Window Algorithm

The Sliding Window Algorithm manages request limits dynamically based on traffic patterns. Unlike the Fixed Window Counter, the sliding window method updates request limits based on a continuously shifting time frame. It uses a cumulative counter for a set period, assessing the previous window to smooth out traffic bursts.

This mechanism protects against rapid bursts that could overwhelm the system by managing the request pace, such as with APIs handling real-time data streams, online gaming platforms, or financial services where transactions occur frequently and unpredictably. When a request exceeds the limit threshold, requests are queued to maintain orderly processing. This dynamic approach helps avoid stampeding issues, ensuring a more stable API service.

Stytch Device Fingerprinting: Intelligent API rate limiting

Despite the many best practices available today, optimizing API rate limiting remains a challenge without the incorporation of highly granular device intelligence. 

This is where Stytch Device Fingerprinting (DFP) comes into play. By leveraging Stytch DFP, you can confidently identify every device within your web traffic, allowing you to create smarter, more effective, and dynamic API rate limits. Stytch's fingerprinting technology offers industry-leading accuracy in bot detection, device intelligence, and fraud prevention.



Device Fingerprinting (DFP) technology empowers you to go beyond traditional rate limiting by tailoring limits to specific individual devices. This approach enhances both the performance and security of your API by allowing more nuanced control over traffic. Rather than applying blanket limits across all users, Stytch DFP enables you to adjust rate limits dynamically, based on the unique characteristics and patterns of each device like the hardware, browser, TLS and network. 

Stytch’s Device Fingerprinting product offers the capability to precisely identify and track devices, ensuring that API resources are allocated fairly and abuse is minimized. By implementing DFP, you can protect your API from malicious activities while optimizing the user experience for legitimate users. This advanced level of device intelligence allows for the creation of adaptive rate limits that respond to real-time traffic conditions, providing a more robust and resilient API infrastructure.



---


# Auth0's Security Incidents: How JWT Vulnerabilities Have Repeatedly Impacted the Platform
Source: https://stytch.com/blog/auth0-security-incidents/

Auth0, a well-known authentication and authorization platform, has experienced its fair share of security incidents, one of the most significant being the alg:nonE re-bug.

Background

In the realm of cybersecurity, even the most sophisticated, high-profile companies can find themselves vulnerable to security incidents. Auth0, a well-known authentication and authorization platform, has experienced its fair share of such incidents, one of the most significant being the alg:nonE re-bug.

The repeated vulnerabilities reveal troubling element’s in Auth0’s security culture and have also come with additional product trade-offs for customers. In addition to the security headache this has posed to customers, this has also pushed Auth0 to limit the flexibility & customization of their platform to try to mitigate the recurring issues they’ve exposed themselves to historically.

For developers who are evaluating Auth0 as an authentication provider, continue reading to learn how these issues could compromise your authentication systems and overall security posture.

The Infamous alg:nonE Recurring Bug

To understand the impact of the alg:nonE recurring bug, it's important to understand what it was and how it exploited Auth0's security systems. Essentially, this vulnerability lay in Auth0's Authentication API and how it handled JSON Web Tokens (JWTs), which are a popular method for securely transmitting information between parties as a JSON object.

The problem surfaced when the Authentication API did not adequately validate a user’s JWT, which is provided in the response upon successful login. Attackers could forge a JWT for any user by creating a JWT with an algorithm of 'none' (i.e. alg: none) and no signature. Auth0’s API would mistakenly validate these forged tokens as legitimate, and return 200 response codes back to the malicious actors.

While Auth0’s Authentication API prevented the user of the lower-case alg:none, it was a case sensitive filter, which meant simply capitalizing any letter (e.g. alg: None or alg: nonE) allowed attackers to forge tokens – this was discovered by Insomnia Security [4]. 



Notably, this wasn't the first time that Auth0 had dealt with this vulnerability - it was a recurrence of an earlier issue that Auth0 had claimed to resolve less than a year prior. This repeat incident raised eyebrows in the cybersecurity community, as the recurrence of such a fundamental flaw pointed to a deeper issue within Auth0's security culture [3]. 

Many questioned how the same vulnerability could appear twice, suggesting a lack of rigorous security practices. Stytch works very closely with Latacora, a renowned security consultancy. Security researchers have pointed to the alg:nonE re-bug’s repeat occurrences as a key indicator of a broken security culture at Auth0.

The Impact

The implications of the alg:nonE recurring bug were far-reaching. It allowed attackers to do two things:

They could bypass multi-factor authentication (MFA) when enabled on the user's account. With a forged JWT, an attacker could exploit Auth0’s API to register secondary factors to their own devices instead of the rightful account owner.

They could fully bypass authentication in instances where the client application did not also independently validate the token itself. Relying on an auth provider’s token inspection API should be an acceptable method for verifying a token’s validity, but Auth0 was totally compromised in this regard.

Pivot in Product Strategy: Restricting Developer Control and Flexibility

In response to the vulnerabilities and the aftermath of the alg:nonE re-bug, Auth0 made a decisive pivot in their product strategy. To attempt to reduce the impact & time to remediation for future Auth0 vulnerabilities, they introduced an inflexible integration option known as Universal Login.

Universal Login is a mechanism that transfers authentication to Auth0's servers instead of in-app authentication, forcing all user logins to occur on Auth0’s domain. This approach effectively strips the developers of any native code control over the auth flow, placing complete reliance on the external provider to manage the entire process.

By significantly restricting the integration flexibility for developers, this strategy has some security benefits particularly for a company with a history of multiple core vulnerabilities [11] [12] [13], as it centralizes user authentication. By mandating the use of Universal Login, Auth0 could streamline updates to its service, ensuring that security patches and updates are immediately implemented across its customer base. However, this shift has not prevented the recurrence of authentication bypass vulnerabilities on the Auth0 platform.

In other words, Auth0’s inability to create a security culture that could consistently avoid these types of major vulnerabilities led the company to make far-reaching changes to how customers are allowed to build authentication into their applications.

Recent Vulnerability: Authentication Bypass

Additionally, a recent security flaw in Auth0, highlighted by Sentor Security, involved an authentication bypass vulnerability due to session [1]. This issue allowed unauthorized access to protected resources by exploiting weaknesses in Auth0's token validation process.

The vulnerability stemmed from improper validation of certain token parameters within Auth0's authentication flow. Attackers could manipulate these parameters to bypass authentication checks, gaining unauthorized access to sensitive data or services.

This flaw significantly compromised user account security and raised concerns about the overall effectiveness of Auth0’s authentication mechanisms.

Conclusion

The repeated occurrence of vulnerabilities like the alg:nonE re-bug and the recent authentication bypass indicates a persistent issue in Auth0’s security culture. These incidents underline the need for a more robust and proactive approach to security, as recurring vulnerabilities suggest underlying weaknesses in the company's security practices.

The shift towards Universal Login illustrates that a significant strategy pivot is sometimes necessary to manage security risks, but it also highlights the trade-off between security and flexibility.

Auth0’s universal login approach isn’t just a design choice; it reflects an inherent weakness in their ability to deliver secure embedded authentication for developers that require flexible and customized in-app control over their auth flows.

For companies seeking more adaptable solutions, this underscores the value of security vendors who prioritize both robust security measures and flexibility, avoiding the pitfalls of inflexible integration options.

Citations & Sources

[1] https://sentorsecurity.com/blog/vulnerability-disclosure-session-fixation-in-auth0/
[2] https://auth0.com/blog/improving-the-way-you-configure-security-settings-in-the-dashboard/
[3] https://www.bleepingcomputer.com/news/security/auth0-warns-that-some-source-code-repos-may-have-been-stolen/
[4] https://cybercx.co.nz/blog/json-web-token-validation-bypass-in-auth0-authentication-api/
[5] https://auth0.com/blog/auth0-response-to-security-report/
[6] https://news.ycombinator.com/item?id=22890604
[7] https://auth0.com/blog/common-threats-in-web-app-security/
[8] https://news.ycombinator.com/item?id=24346317
[9] https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/
[10] https://www.akto.io/blog/jwt-none-algorithm-test
[11] https://www.cvedetails.com/cve/CVE-2019-7644/
[12] https://www.cvedetails.com/cve/CVE-2015-9235/
[13] https://www.cvedetails.com/cve/CVE-2015-9235/
[14] https://www.rfc-editor.org/rfc/rfc8725






---


# Stytch Embedded Auth vs. Auth0 Universal Login
Source: https://stytch.com/blog/embedded-auth-vs-universal-login/

Designing an effective authentication experience is crucial for ensuring both security and a seamless user journey. One of the key implementation decisions you'll make is choosing between an embedded authentication or universal login architecture.

Designing an effective authentication experience is crucial for ensuring both security and a seamless user journey. One of the key implementation decisions you'll make is choosing between an embedded authentication or universal login architecture.

In this article, we'll explore what each method entails, highlight the key differences, and help you determine which approach is best suited for your needs.

Let's dive in.

What is Universal Login?

Universal login, also known as hosted login or authentication, is an approach that redirects users away from your site or application. Users are taken to the authentication provider’s domain in order to complete authentication flows like login, signup, or password resets. Once the user has successfully authenticated, they are redirected back to your site, the original domain.

This approach relies heavily on the external auth provider to handle the entire authentication flow and for security. While this works for some who need a simplified or an “out-of-the-box” setup, universal login often sacrifices user and developer experience by design since it effectively strips developers of any native in-app code control over the auth flow.

Auth providers like Auth0 encourage developers to implement universal login as their primary solution for authentication.

What is Embedded Authentication?

Embedded authentication, on the other hand, allows users to authenticate directly within your application without being directed. Users can complete the login, signup, or password reset process from your application or website. The authentication logic and components are embedded natively, providing an authentication experience where users never leave your site.

Unlike universal login, embedded authentication gives developers more control over the entire process by keeping the auth process and logic within your application’s domain. This approach provides greater flexibility and customization over the user interface, business logic, and event flow while interfacing with the the auth provider via SDK or API to handle secure authentication protocols.

Auth providers like Stytch offer client-side, server-side, and hybrid integrations options for embedded authentication, allowing you to tailor authentication to your application's specific codebase.

Pros and Cons: Side-by-Side

When deciding between embedded authentication and universal login, it’s important to evaluate how each approach impacts your application’s user experience, development process, and security posture.

The table below highlights the key pros and cons of both approaches, providing a high-level comparison across various technical aspects to help illustrate their differences.



Why Embedded Authentication Provides More Benefits

When choosing between embedded authentication and universal login, it's crucial to understand the aspects of each approach offers in-depth. Below, we’ll explore why embedded authentication stands out as the option with more benefits and why companies seeking optimal user experience, security, and developer flexibility should prioritize it over universal login.

Control Over the User Experience

For companies that value brand consistency, embedded authentication offers a significant advantage. By customizing the entire auth flow, you ensure that every interaction—whether it’s logging in, resetting a password, or signing up—stays within the familiar environment of your application. This results in a more seamless and tailored experience. In contrast, when configuring universal login, Auth0 forces you to use their external login pages, limiting your ability to fully customize the universal login experience.



A great example is Stytch’s customer, Apartment Therapy, who saw a 10x increase in user registrations after switching from a universal login provider to Stytch, an embedded auth provider. This demonstrates one of the key advantages of embedded authentication—users can complete the login flow without being redirected away from the app’s web pages, which results in a smoother experience and higher conversion rates for end users.

We moved from Auth0 to Stytch and implemented the Google OneTap method. Within a month, we saw a 10x increase in user registration and are now rolling this out across our other digital properties.

Development Control, Flexibility, & Customization

When it comes to development, Stytch embedded authentication provides a much greater degree of flexibility and code control. You can choose between client-side, server-side, or hybrid integrations to best fit your application’s architecture. Whether you're building web apps, mobile apps, single page applications, or more complex backend systems, Stytch’s SDKs and APIs give you full native code control over authentication logic, features, and security measures.

On the other hand, Auth0 universal login is largely controlled by a hosted dashboard-driven code builder known as “actions”, similar to lambdas or edge functions, which simplifies setup but severely limits the level of customization. Developers are constrained to using Auth0’s hosted rules, actions and configurations, making it harder to implement advanced use cases or extend custom logic specific to your application’s needs without workarounds.



By deliberately housing custom logic solely within an external dashboard platform, Auth0 subjects developers to experience the following drawbacks:

Limited code reusability - Auth0 actions are isolated and disparate functions, complicating code reuse and maintenance across your application.

Fragmented version control - Actions can’t be managed within the main codebase, leading to version control inconsistencies and difficult application level changes.

Auth0-specific limitations - Developers must navigate several Auth0-specific restrictions, such as limited runtime configurations, capped execution time, Node.js only, constraints on external API calls, and more.



Security and Visibility

Another major consideration for any authentication solution is security, and Stytch embedded authentication offers full visibility and control over security events, monitoring, and data protection. This is crucial for businesses that require transparency in how authentication flows are managed, especially when dealing with sensitive data or compliance requirements.

With Auth0 universal login, much of the security is outsourced to the provider. While this simplifies management, it also means you have little to no insight into critical security measures, relying on event log integrations with filtered data to monitor auth, including token handling, fraud detection, session management, and encryption protocols. This "black box" approach can be problematic for organizations that need granular control over their security posture and insight into how their user data is protected.

In contrast, with Stytch, your application logs are also your auth logs, providing direct, granular insight into every aspect of user security within your own environment.



Universal login providers like Auth0 often push users toward their solutions, not just for convenience but out of necessity. Recurring vulnerabilities, such as the "alg: nonE" bug and recent authentication bypasses, reveal deeper issues in their security practices. These incidents highlight the need for a more proactive approach to safeguarding data.

While universal login might seem like a smart way to manage risks, it often sacrifices flexibility. Companies need security vendors that offer both strong protection and adaptable integration options, avoiding the rigidity of one-size-fits-all solutions.

Frequently Asked Questions about Embedded Authentication

How does embedded auth handle cross-origin requests?

Modern web applications provide effective solutions to mitigate the risks of cross-origin requests. By implementing Cross-Origin Resource Sharing (CORS) policies, you can control which domains are allowed to interact with your embedded authentication service. These policies ensure that only trusted domains are permitted to interact with the authentication service, significantly reducing the risk of unauthorized access.

How does embedded auth mitigate phishing attacks?

Embedded authentication can effectively mitigate the risk of phishing attacks with the right security measures in place. While some believe that using embedded login may expose applications to phishing risks due to multiple login pages across different sites, most businesses use a unified login page for their applications, which significantly reduces the number of sites this concern applies to.

But for applications with multiple login pages, a number of different strategies can mitigate this risk:

Implementing a strong Content Security Policy (CSP): By explicitly defining trusted sources, you can block unapproved scripts and significantly reduce the chances of phishing attacks.

Additional security measure: By integrating multi-factor authentication (MFA) or Device Fingerprinting Protected Authentication (DFP) into your authentication flow, you can greatly enhance security. These measures make it much more challenging for malicious actors to access accounts through phishing, social engineering, or other attack vectors, even when a user's password is compromised.

Stytch's SDKs also have many guardrails and javascript controls in place, such as trusted domains and trusted redirect URLs to protect the flow of information between your client and Stytch. With an embedded authentication provider, you also have the flexibility to integrate via backend APIs and SDKs, eliminating the cross-origin aspect entirely.

Does embedded auth add complexity to feature rollouts?

A key component of a universal login is a heavy reliance on dashboard-driven management for custom code and business logic. One perceived benefit of managing things like authentication methods and post-login logic through a dashboard is the ability to make changes in production quickly without a code release. However, this ease of use often comes at the expense of flexibility and the safety of robust version control.

Embedded authentication, on the other hand, typically offers a mix of in-code and dashboard configuration options, depending on where in your application stack authentication was integrated (e.g. backend or frontend). There are several advantages to this approach, namely:

Version control for major changes: By managing configuration changes through in-code configs, your team will have a better grasp on version management and audit trails. This eliminates the possibility of a team member accidentally turning off a feature in production with the click of a mouse, with no ability to audit log how the incident occurred (we have heard of this happening many times from our customers!)

More granular feature implementations: With embedded auth, you retain control over how you’d like to roll out a new feature when leveraging embedded authentication. Take for example enabling MFA. When auth settings are confined to a dashboard UI solution like with universal login, you may have access to “turn on” and “turn off” MFA, and potentially configure some additional settings. However, embedded authentication allows for much greater precision. You can define which user account you’d like to trigger MFA for or when it should be forced—whether at initial login or as step-up authentication when a user performs a sensitive action. This level of customization ensures that auth settings are tailored to your specific feature needs.

With embedded authentication, you can integrate advanced security protocols such as MFA and bot detection from the start within your codebase, preventing reactive disruptions that can negatively impact user experience.



Ultimately, embedded authentication provides a balance between flexibility, security, and control, allowing you to roll out features in a way that aligns with your application’s specific integration work without compromising the user experience.

Does embedded auth support cross-domain sessions with OAuth 2.0?

Embedded authentication can indeed support cross-domain session sharing with OAuth 2.0 and OIDC redirects, making shareable access tokens across applications to prove a user's identity.

Stytch, as an embedded authentication provider, is currently testing its "Be the IdP" feature in a private beta. This feature enables a centralized login for all your applications, similar to social login, while preserving the core advantages of embedded authentication, such as a seamless user experience and full control over the UX. With this approach, you can enjoy the benefits of both centralized login and flexible, customized authentication.

Final Thoughts

Choosing between Stytch embedded authentication and Auth0 universal login boils down to your priorities in user experience, security, and control. Universal login is appealing for its simplicity and one-size-fits-all setup, but it imposes limitations on developer customization and control. Applications that adopt universal login often find themselves constrained by the lack of flexibility of hosted auth and dashboard-driven development.

Stytch's embedded authentication offers more benefits with more investment—seamless integration, full control, and proactive security measures that empower you to design the auth systems native to your application’s architecture. By keeping the authentication process embedded within your app, you not only improve conversion rates and user satisfaction, but also gain full control over security practices and business logic within your codebase.

Learn More

Learn more about how to migrate and integrate with an embedded authentication provider:

Migrate from Auth0 Universal Auth to Stytch Embedded Auth

Integration Patterns with Stytch







---


# Canvas fingerprinting: Explained and illustrated
Source: https://stytch.com/blog/canvas-fingerprinting/

Researchers have studied the canvas element and its usefulness in identification as early as 2014. One of the key security applications of the canvas element today is canvas fingerprinting.

When the canvas element was originally introduced by Apple in WebKit and then picked up by other browsers, it gave web pages a welcome splash of 2D graphics and even OpenGL-powered 3D rendering. While it is still mainly used for web graphics today, other use cases have developed.



Researchers have studied the canvas element and its usefulness in identification as early as 2014. One of the key security applications of the canvas element today is canvas fingerprinting.

What is canvas fingerprinting?

Modern web browsers support an HTML5 canvas tag, which renders as a rectangular box on which graphics can be drawn. A developer can write simple HTML to create this box and then use JavaScript to paint shapes and colors, write text, and render images on the canvas. What was unique at the time of canvas introduction was that it not only supported CPU graphics, but GPU ones as well. This opened up performance opportunities and, later, characteristics for identification.

When a user’s browser renders an image or text on the HTML5 canvas element, it produces a unique result based on all the computational factors and inputs mentioned before. These combined variations create a “fingerprint” distinct enough to accurately differentiate one device or browser from another.

Canvas fingerprinting is a device-fingerprinting or browser-fingerprinting technique that uses the characteristics of a browser’s canvas implementation to create a unique identifier.

The role of fingerprinting in security

Device fingerprinting is used to capture unique information about a user’s device, from operating system versions to the configured timezone, browser versions, and more. The way this device fingerprint can be used is similar to fingerprints in the traditional sense: You take an impression of the unique characteristics and pattern of a finger and store it. That impression can then be recalled in the future to identify that person.

In security, device fingerprinting information can be used to connect events to devices. For example, if a malicious user creates multiple online merchant accounts from the same machine — using different digital identities — and engages in fraud, it may be difficult to block that user as they “say” they are someone else every time. By augmenting behavioral information with device fingerprint information, the merchant may understand more clearly that the various identities are connected to the same desktop device likely being used for fraud operations, and so they have more information to address that activity.

Let’s look in more detail at how canvas fingerprinting works.

The process of fingerprinting a browser canvas

There’s more than one way to generate a canvas fingerprint. In fact, fingerprinting providers typically keep the algorithms they use, the datasets they rely on, and the other security tools and techniques they combine with them confidential.

Here’s a simplified example of how canvas fingerprinting can be done.

Create a (hidden) HTML5 canvas. The process starts with an HTML canvas element already on the page or created via JavaScript. While visible to JavaScript, this element doesn’t need to be visible on the webpage, or even in the DOM.

Paint background items. A shape, such as a rectangle, can be drawn on the canvas with a color gradient fill. The exact pixel size and location of the rectangle and how that particular browser renders the gradient will be different depending on the hardware used, operating system version, browser version, and other factors. This adds identifying information.

Write text. A string of text can then be written to the canvas without specifying any additional settings. The developer may then request a font class for this text, apply an outline and/or shadow as well. The font requested, the font used, and how the text effects are rendered again provide further identifying details for that browser.

Extract the image. With JavaScript, we can export everything drawn on the canvas as a binary file, such as a PNG, or as encoded text, like base64 text.

Hash the extracted image and data. Run the extracted image plus all other data obtained about the elements in canvas through a hashing algorithm such as sha265. The result is a purposefully sized fingerprint that can be used to identify this browser in the future.



The accuracy of this fingerprint is how likely we are to generate the same fingerprint for a different user. The example above is only a suggestion of the steps that a fingerprinting process may use. The more sophisticated the above steps are and the more they are tailored to identify differences in user devices, the higher the accuracy of the fingerprint will be.

Canvas fingerprinting use cases

While canvas fingerprinting is being used for security purposes, it can also be used for the following:

Personalization

Canvas fingerprinting can be used to personalize users' web experiences through custom welcome messages, themes, suggested content, and ads. Unlike cookies, however, a fingerprint generated from the canvas element doesn’t expire after 30 days or when the browser closes — this positions canvas fingerprinting as a more durable alternative to browser cookies.

Fraud Detection & Prevention

The cleverness behind canvas fingerprinting and its ability to resist attempts by a user to circumvent it makes it a powerful tool for detecting malicious users and bots. Generating fingerprints for incoming connections and storing them for analysis enables the following security scenarios:

Detecting an active intrusion due to the same fingerprint attempting to access multiple unrelated accounts in a system.

Blocking a known malicious user after they changed IP addresses.

Reducing captcha friction for legitimate users while maintaining a high level of security.

In an era where malicious actors can evolve and mutate to disguise themselves, canvas fingerprinting is one security tool that can help identify them.

Limitations and shortcomings of canvas fingerprinting

For security, canvas fingerprinting may not be the complete solution because its reliability is limited. You cannot guarantee that you’ll be able to generate the exact same fingerprint twice in a row on the same device — and canvas elements are not a replacement for cookie storage.

A canvas fingerprint is also difficult to use to identify unique devices without the assistance of other measures. Different devices may produce the same canvas fingerprint.

Another limitation of canvas fingerprinting is that it is still done on the side of the end user, and sophisticated actors can reverse-engineer your fingerprinting approach or tamper with it. Thus, it’s not possible to rely 100% on the device fingerprint information for sensitive operations.

Some users also use anti-device-fingerprinting plugins and extensions, limiting your ability to use it with every user.

Given the limitations, a best practice is to combine multiple approaches, such as cookies as well as device-fingerprint-based user identification, for optimal certainty and convenience.

How Stytch uses advanced fingerprinting for fraud prevention

Stytch provides full-fledged fraud APIs and SDKs to integrate authentication and security into your app.

Stytch's advanced fingerprinting API allows developers to create authentication flows, from signup and login forms to complex permissions controls, in a way that blocks fraud and bots without creating friction for regular users. To achieve this experience, Stytch integrates device fingerprinting into the auth flow, identifies every visitor and detects bad auth requests, like headless browser automation. 

The Stytch’s device fingerprinting uses multiple signals, including canvas fingerprinting but also a number of other techniques, in order to identify visitors with industry-leading accuracy. 

These signals include:

Software stack and OS version

Browser sub-signals and capabilities

Passive network TLS fingerprinting

Active Javascript code

User attributes

Hardware architecture and resources

Proprietary signals





Getting started with Stytch fingerprinting

Compared to DIY canvas fingerprinting, Stytch offers a convenient and speedy way to start identifying website visitors. Here’s what you need to do to start using Stytch’s device fingerprints:

Step 1: Include Stytch telemetry script on your website via a <script> HTML snippet.



Step 2: In the body of your site, call the GetTelemetryID function to get a unique identifier associated with a user.



Step 3: Call the Stytch Fingerprint Lookup API to get a suggested action for a particular device. For example, the API call may look like this if you use curl:



In the API response, Stytch will include a number of fingerprint IDs as well as one of the suggested actions, ALLOW, BLOCK, or CHALLENGE:



Step 4: Use the action suggested in the verdict in your application flow. For example, for requests with the BLOCK verdict, you may choose to completely block a request, or to return a basic “Your request has been blocked” page. And for the CHALLENGE verdict, you may want to send an additional MFA code to a user’s device or present a CAPTCHA for them to solve.

Conclusion

In summary, while canvas fingerprinting is a useful technique, it’s not sufficient to reliably identify users in production web traffic unless it’s used together with other approaches.

Stytch makes it simple to integrate production-grade device fingerprinting into your authentication process and block or challenge malicious users right away.

Learn more about how Stytch helps prevent fraud and reduce risk in the docs.



---


# Announcing Stytch’s new Self-serve pricing: No feature gating, no hard caps, no surprises
Source: https://stytch.com/blog/stytch-self-serve-pricing/

Today, we are thrilled to announce new self-serve pricing. Stytch is moving away from complicated tiers and feature gating to a simpler model: access all of our features and only pay for what you use. 

Every day, our Slack channel #alerts-competitor-calls lights up with unfiltered frustrations from sales prospects who’ve struggled with legacy auth providers. We see the same pain points on repeat: feature restrictions, unexpected caps, and hidden fees that force costly upgrades. 

Here’s a look at what customers have said in recent weeks about our most common competitor (Auth0):



Clearly, customers don’t want gotchas, gimmicks, or gating from their authentication provider. Hearing these frustrations motivated us to overhaul pricing, and today, we’re thrilled to announce these changes. At a basic level, our new pricing enables transparent, unrestricted access from day one. But on a deeper level, we simply do what’s right for the customer. 

Because authentication is core infrastructure, we partner with our customers for the long haul.

Behind Stytch’s new pricing

The core pillars of our new pricing are:

No feature gating: Most competitors restrict critical functionality behind higher-cost plans. Stytch is different - we’ve removed all feature gates. From day one, every Stytch user has access to MFA, SSO, RBAC, SCIM, social logins, OTPs, passwordless auth, and more – if it’s an authentication acronym, it’s available in our free tier! We’re doing this because even small businesses deserve top-notch security.

No caps or cliffs: Auth0 and other vendors have hard caps. Customers cannot add a 9th SSO connection without talking to sales. Or, your 5,001st monthly active user (MAU) forces you into a tier that costs twice as much. Stytch offers a “pay for what you use” model with no hard caps. If you have 17,700 MAUs in a month, you’ll only get charged for 17,700 MAUs. If you surpass the amount of MAUs or SSO Connections included in the free tier, you’ll only pay for what you use, at transparent rates and without having to talk to sales.

No gotchas or gimmicks: We’re committed to clear, upfront pricing. Competitors like Auth0 present deceptively affordable starter plans that later pile on hidden fees or restrictive usage limits. What starts as a free plan can quickly balloon to tens of thousands of dollars simply because your user base grows or you need a feature like MFA. Our pricing structure is simple and transparent: you get access to all features, only pay for what you use, with no hidden fees.

Generous free tier: Our free tier offers significantly more than Auth0’s, and should be enough to fully support your business’s first few years of growth. Or, take advantage of our startup program: don’t pay a cent until your series A or three years of incorporation, whichever comes first.

Stytch vs. Auth0 pricing: A comparison at every stage

Here’s a comparison of what you’d pay with Stytch vs. Auth0. Whether you’re just getting started or starting to hit your groove, we’re committed to being the more scalable & transparent provider.







You can calculate your costs on Stytch and find more information about our pricing model here.

What’s wrong with auth pricing today

In our view, the incumbent models of authentication pricing are broken for a few key reasons. We wanted to call out two specific examples of pricing tactics Auth0 uses - and how Stytch is different.

1. Auth0's feature gating

First, on the feature gating front. Let’s say you’re building a B2B app and were just accepted to YC. Initially, the Auth0 offering looks suitable. Right at the top of the page - there’s a free tier. Great. Then, 25,000 monthly active users, that’s awesome. And even if I did need some additional features, their first tier starts at only $150 a month, that seems reasonable. 

But, as you dig deeper, you realize that MFA with OTP, a common authentication method you’ll definitely need, is buried as the last bullet in the Professional tier. Unfortunately, you’ll have to pay a minimum of $9,600 annually, and that’s only for 500 users 😢.

With Stytch, you get all features for free and won’t pay a cent in usage fees until you’ve reached 10,000 monthly active users. Importantly, the “gotcha” here with Auth0 is buried at the bottom of the page and you have to scour over hundreds of words in small font to parse out this information. It’s more likely you’ll miss this and later get saddled with a large bill unknowingly, which brings us to our next point.



2. How Auth0 obfuscates pricing to mislead developers

Our second example concerns SSO Connections. In September, Auth0 published a splashy blog that promotes, among other benefits, “Unlimited Okta Connections”.



This sounds generous, but unfortunately, this blog post is smoke and mirrors. The “Unlimited Okta Connections” only cover a specific, less-common OIDC setup that, according to our data, only make up 10% of enterprise connections. SAML connections, the much more common SSO type, are not included. And to figure out how much these more common SAML connections cost, you have to talk to sales! 

Customers who don’t diligently fight through Auth0’s duplicitous advertising will end up with hidden fees and surprise bills. More information on this specific issue can be found here.

Growing with Stytch

We’re excited to redefine what pricing transparency means in authentication. At Stytch, we believe in empowering developers with straightforward, flexible pricing that grows with you: no locked-away features, no hard caps, and no hidden fees. We want to be an upfront and trustworthy partner to all developers, whether you are just starting out or scaling. With Stytch, you get access to all our features and only pay for what you use.

We’re here to make authentication simple, scalable, and headache-free.

Visit our pricing page for more details.





---


# What Is Anonymous Visitor Identification? How to Identify Visitors to your Website or App
Source: https://stytch.com/blog/what-is-anonymous-visitor-identification/

This article explains why it is important to identify website users and explores the processes and technologies you need to implement to make sure that as many visitors as possible are correctly identified. This will let you take the right actions to protect your online assets from hacking attempts, fraud, account abuse, and other malicious activity — without disrupting your regular users.

An anonymous (unidentified) visitor to your website could be a regular user with legitimate interest, but hiding behind that same anonymity are also malicious actors and bots. Anonymous visitor identification is the process of associating traffic to your website or app to a particular entity, classifying what kind of visitor it is, and identifying its intent.

This article explains why it is important to identify website users and explores the processes and technologies you need to implement to make sure that as many visitors as possible are correctly identified. This will let you take the right actions to protect your online assets from hacking attempts, fraud, account abuse, and other malicious activity — without disrupting your regular users.

Good traffic or bad traffic? The importance of identifying anonymous website visitors

The first thing that usually comes to mind when "anonymous user identification" is mentioned is online marketing. Ad platforms rely heavily on classifying and identifying users to target ads at the most relevant audience and track potential customers. However, while capturing sales leads is important, the stakes are much higher when it comes to fraud prevention and protecting your app from malicious web traffic and multiple attack vectors.

Every CAPTCHA you encounter when browsing the internet is just the tip of the iceberg of determining whether you are a real user. Significant technical efforts are undertaken in the background to figure out where you are located, what browser you’re using, what pages are you likely to view and in what order, and more.

Website owners are also interested in all this information because it’s costing them money to keep their service online. While a simple static web page may cost a fraction of a cent to serve to the end user, the cost is much higher for more complex pages with lots of assets. If your service includes AI-powered features or other kinds of resource-intensive functionality, the cost you incur for every website visit increases dramatically. 

This makes anonymous visitor identification — and more specifically, the blocking of unwanted users — an important strategy for making app security and resource-intensive services viable.

Mitigating risk by blocking malicious actors

Another reason for blocking malicious actors and bots is the additional risk that they bring. The more malicious actors can see and understand about your service, the more likely they are to find a way in and potentially cause issues. Here are some examples of fraudulent and risky activity that malicious users may engage in:

Account hijacking: Using stolen credentials or brute-force attacks to take over another user's account. This can be done manually, but it is more often performed by automated bots. This can then lead to further exploits, such as laterally moving through your infrastructure using privileged accounts, or using the details of the stolen account to further defraud the owner.

Trial and product abuse: Human users will often try to hide or change their online identity to sign up for multiple product trials or extend the period they can access a website for free. For example, they may use multiple email addresses to sign up for new trial subscription periods or new browser sessions to get past article limits on a news website.

Attack vector research: Malicious users will generally try out new exploits in different ways to see if they can cause a breach and then take advantage of it.

Differentiating between valuable and harmful traffic

Determining whether traffic is "bad" or "good" isn't just about identifying synthetic users; not all bots are bad, and not all humans are virtuous. Some bots are welcome, such as those for search engines and other indexes that make your website discoverable to others online. Blocking access to these bots would be detrimental to your website, as it would effectively make it invisible to the greater internet.

Conversely, some malicious activity in your app will come from real people; for example, fraudulent activity as part of a phishing campaign; and while it's important that offenders are identified and blocked, the mechanism that does so cannot be too sensitive and risk causing trouble for real users.

For these reasons, anonymous visitor identification must be a multi-stage process to make sure it is as accurate as possible. It should also be part of a larger authentication and security process to prevent data breaches and protect your product reputation.

Methods of online anonymity



There are legitimate reasons why privacy-conscious users will want to limit their digital footprint. However, these methods of online anonymity are also used by bad actors, creating an ever-evolving balancing act of thwarting your visitors' online privacy measures (in the name of protecting your infrastructure) while respecting the wishes of your real users and not driving them away with invasive identification practices.

Common ways that visitors may mask their traffic to your website or app include:

Throw-away email addresses: Single-use email addresses are used to create multiple accounts, but they may be used legitimately by privacy-aware users who do not want to share their actual details with every service they sign up for.

Private web browsers/incognito mode: Web browsers that provide disposable sessions that do not record the browsing history or share data and cookies have become standard across all operating systems, and they are commonly used by regular users.

Burner/virtual devices: Virtual machines can be used to further anonymize users by isolating activity, and malicious users may employ multiple devices to defeat security measures or impersonate multiple users. However, there are legitimate reasons to use virtualization or own multiple devices, particularly in the sought-after software development space.

Public WiFi or hijacked networks: Public WiFi networks (like the one at your local coffee shop) or hijacked networks (where a hacker may have gained unauthorized access to a business’s private WiFi network) can be used to perform malicious activity, hiding it amongst the legitimate traffic of other users on the network and making it hard to determine the source.

Privacy VPNs, proxies, and TOR: These methods all mask the source of traffic by routing it through a shared service. While all of these methods can be used to mask the source of malicious traffic, privacy VPNs in particular are often used by legitimate users to secure their connections while using public networks.

Increasingly, consumer-focused web browsers are integrating technologies such as VPNs, private web browsing, and virtualization as part of their value proposition. This is creating an arms race between privacy features and website and app owners who want to know who their visitors are and what their intentions are. Significantly, the proliferation of privacy features in web browsers means that anonymized traffic is becoming the majority.

How can anonymous visitors be identified?

This constant push for privacy makes confident identification a long complicated checklist to determine whether a visitor is a human or bot and whether they've previously been identified as a potential threat. These determining factors include:

The visitor’s IP address: IP addresses are no longer a reliable way to identify individual users, since they can be spoofed. And many legitimate users connect using public WiFi or cellular service. However, in some egregious cases, traffic from some IP addresses may be 100% illegitimate and can be outright blocked.

Device and browser fingerprinting: Device and browser fingerprinting technologies exploit various web browser features (including canvas fingerprinting) that can identify a specific user. However, these can usually be blocked at the cost of reduced browser functionality for the end-user.

Sessions, cookies, and tracking pixels: Browsing sessions can be uniquely identified using cookies or other unique identifiers embedded in the session. These methods can be easily mitigated using private browsing settings.

Visitor behavior: A user's behavior when using your app or website can quickly give away whether they are a bot (especially if your site is protected using CAPTCHA or ReCAPTCHA). It can also uniquely identify the user based on their usage patterns.

Login and email tracking: A logged-in user, or a user following a unique link from an email, can be readily identified.

Geolocation: A user's location can be used in conjunction with other information to narrow down the source. However, this can be easily spoofed by the web browser, and geolocation based on IP address can be unreliable.

Anonymous visitor identification is an ever-evolving space, and new ways to identify anonymous visitors are constantly being devised (and circumvented). This makes developing your own visitor identification solution a monumental and ongoing task. Usually, reliable and effective anonymous visitor identification requires the combination of multiple data points.

Why WAFs aren’t enough for anonymous visitor identification

Traditionally, web application firewalls (WAF) have been the bulwark against bot attacks. These security gateways block visitors based on rigidly defined conditions like IP address ranges of known VPN providers, browser version strings, location data, request frequency, and other factors.

Popular platforms that provide WAF functionality include open-appsec, AWS WAF, Imperva WAF, and Cloudflare. Unfortunately, these tools do not provide the mechanism for actually identifying anonymous visitors. This impacts security and accessibility: relying solely on WAFs to protect your application means continually tweaking firewall rules that are not specific enough to exclude advanced programmatic attacks, and may block real users from accessing your products.

Intelligent tools that can adapt in real-time are required to precisely detect and block malicious traffic down to the individual device.

Stytch: advanced device fingerprinting for anonymous visitor identification

Device fingerprinting is the most effective tool for anonymous visitor identification — but it is a complex process that must leverage an ever-broadening array of technologies to keep up with new anonymization techniques. Implementing your own device fingerprinting involves designing and implementing a secure, automated system that complies with evolving regulations in different regions, and committing to the ongoing maintenance and security patching of your system.

Stytch Fraud and Risk Prevention combines device fingerprinting with machine learning, providing highly accurate anonymous visitor identification. Our device fingerprinting solution integrates directly with your applications, detecting the source of anonymous traffic, and detecting bots (both good and bad) as well as malicious users.



Once a visitor is identified, you can programmatically define access rules, filtering out unwanted visitors while ensuring that real, valuable users are not turned away at your doorstep.



Everything in Stytch is reported on and observable, so you are always aware of any ongoing risks, and able to respond to maintain a strong security posture.

You can learn more about anonymous visitor identification with Stytch by contacting our auth experts — or jump right in and start integrating Stytch in your app.





---


# Bot Detection 101: How to Detect (and Beat) Bot Traffic
Source: https://stytch.com/blog/bot-detection-how-to-detect-bot-traffic/

This article explains the top methods you can use to identify and block bots from your websites, apps, APIs, and other online services, ensuring the security and integrity of your applications and their associated data.

Bot detection is crucial for protecting websites and apps from malicious activities. With bots accounting for almost half of internet traffic, distinguishing between legitimate users and automated bots can be murky and challenging — but the impact on the security, cost-effectiveness, and ongoing viability of your applications is substantial.

This article explains the top methods you can use to identify and block bots from your websites, apps, APIs, and other online services, ensuring the security and integrity of your applications and their associated data.

Why bot detection, and why now?

Whenever a financial opportunity presents itself, a fraudster will be there to exploit it. This will likely never change no matter how much we advance our machine learning or how well we study the dark web's elusive tricks.

Bots, some of the most technically advanced tools in a fraudster’s disposal, are widely used in fast-evolving attacks on websites, mobile apps, and APIs. As such, the importance of bot detection and the need to block bad bots is greater than ever. Today, developers and organizations must have a strategy for blocking increasingly intelligent and elusive bots in order to safeguard sensitive customer and business data from the hands of fraudsters.

Defending your application from a bot-driven internet

Bot detection is not merely a defensive or reactive strategy; it’s an ongoing practice in maintaining the integrity of web interactions. By identifying patterns and signals that indicate bot activity, businesses and developers can distinguish between actual human users and automated bots.

By some estimates, about half of the nearly 50% of internet bot traffic is malicious. The other half is made up of benign or “good” bot activity, making it tricky for modern technology to discern the subtle clues that distinguish between not just humans and bots, but good and bad bots.





While good bots serve useful purposes (for example, web indexing done by search engine bots), you must protect your customers from malicious bots: data breaches, scraping, spamming, account takeovers, DDoS attacks, carding, and inventory hoarding are just some of the harmful outcomes of unmitigated bot access for your users. Your business also suffers: your reputation can be tarnished if there is an increased risk of fraud caused by using your product, and you may see an increase in infrastructure costs if you are providing services to synthetic users or fall victim to compute abuse.

Bot detection and the rise of AI agents

If they haven’t already, applications will also soon see the arrival of AI agents. These are "good bots" that act autonomously on behalf of real users and may actually spend real money — for example, by automatically booking plane tickets when a user buys conference tickets in another city, or making a regular purchase when a customer's inventory is low.

This will result in a huge increase of bot traffic, and make it even more difficult to identify whether a user is performing legitimate actions or attempting to engage in malicious behavior. This must be factored into application security and bot detection: good bots must be identified as such and treated with the same respect as real users while they perform their programmatic duties.

How do you detect bot traffic on the modern web?

With the increasingly widespread use of privacy tools like VPNs and TOR, identifying the egress point of traffic is not enough to identify a unique visitor or for the purpose of bot detection. Simple detection methods like watching for abnormally high request rates are also well known to bot authors, and they only provide basic protection.

Bots adapt quickly and use multiple techniques to mask their traffic and blend in, including regularly changing their IP address, manipulating request rates, and using JavaScript to spoof properties such as their device attributes, user agent and request headers. To address this, modern bot detection examines various signals across user and device behavior to solve the puzzle where each piece — whether it be a click, a scroll, or an IP address — reveals the bigger picture of who (or what) that visitor is, and flags markers of potential fraud.

For example, traffic from an evasive botnet may be detected due to it occurring at an unusual time or from an unusual location; if your application sees thousands of users arrive from Rendville, Ohio (population 28) at 3 a.m., there's a good chance that it's not coming from legitimate users.

Bot detection techniques and technologies



Successful bot detection is reliant on precise, rapid data ingestion that paints a holistic view of web traffic online. The following bot detection techniques should be considered as central to creating an accurate profile of a user:

IP and request frequency analysis

IP analysis monitors traffic to discern patterns that indicate bots, scrutinizing the origin, frequency, and volume of IP requests to identify potential threats. This detection method can also check if traffic comes from known data centers or IP addresses or ranges associated with bots. Abnormal traffic spikes or repeated access attempts from specific IPs can also be used to identify and halt DDoS attacks. Additionally, IP analysis supports geolocation-based strategies for blocking bots, restricting access from regions frequently tied to malicious activities.

Behavioral analysis

Behavioral analysis is the science of studying user patterns across web and app activity, scrutinizing every click, scroll, and keystroke for telltale signs of bad bots. By examining the cadence of user interactions, this technique can detect bot traffic by discerning the erratic nature of human activity from the more predictable, programmatic nature of bots. As the AI tools behind modern bots continue to improve, behavioral analysis must constantly evolve in its ability to detect the increasingly minute, subtle discrepancies that will define highly capable modern bots.

JavaScript tagging

JavaScript tagging is a behavioral analysis technique that tracks user activities on websites by embedding a snippet of code into web pages. It captures real-time behaviors like mouse movements and keystrokes to provide insights into user interactions and distinguish genuine engagement from automated patterns. When behaviors deviate from typical human interactions (such as unusually fast keystrokes or repetitive mouse movements) JavaScript tagging quickly flags these anomalies as potential bot activity.

CAPTCHA and reCAPTCHA challenges

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is the friendly, somewhat funky request you may occasionally stumble across that asks you to type a blurry string of characters or words into a text box or simply mark a box stating that you're not a robot. CAPTCHA challenges like these separate human ability from a would-be bot attack or bad bot traffic.



Device fingerprinting

Device fingerprinting (DFP) looks at the unique characteristics of user devices, such as browser type, screen size, operating system, or time zone to unearth subtle clues that betray a bot’s presence. By cataloging the intricate details of a device’s configuration, DFP creates a profile for a user device that is as distinctive as a human fingerprint. Inconsistencies in these profiles can be the red flags that signal a bot’s attempt to infiltrate a website or app under the guise of legitimacy.

Aside: Many DFP solutions available today can be reverse-engineered by attackers, leaving your site exposed. Stytch Device Fingerprinting employs an in-depth strategy that obfuscates the fingerprinting process, making it resistant to tampering and spoofing. This approach ensures robust protection against even the most advanced attackers, combining industry-standard and proprietary signals into stable identifiers, fortified with multiple security layers to thwart reverse-engineering.

Machine learning algorithms

Machine learning (ML) algorithms can analyze far larger volumes of data on user behavior than a single person (or even a team) can. Bot detection tools that utilize ML can track the evolution of bot and human behavior in real-time, identify new behavior patterns that fall outside what is "normal" for your application, and assist with the bot detection process.

Implementing effective bot detection tools

Developers building a bot detection solution fit for modern application ecosystems should ensure that they are:

Adaptable and robust, capable of scaling with web traffic and evolving as fraudsters’ techniques change

Flexible to the unique demands of different digital environments

Seamlessly integrated and customizable

Invisible, so as to reduce user friction and imitability from fraudsters as much as possible

With the right tools configured to fit the intricacies of their domains, developers can create an ecosystem where bots are reliably detected and neutralized. This supports a secure environment for the business to transact and scale without the fear of multi-faceted attacks from bad bots of all kinds.

Poorly implemented bot detection negatively impacts real users

One of the problems with implementing your own bot detection through custom code or web application firewall (WAF) rules is when it locks real users out as well as the bots.

The broad traffic management rules made available by most WAF platforms are unsuitable for effectively blocking bad bots (and only bad bots). It's like using a hammer where surgical precision is required. Blocking by IP range or broad geographic region or using rigid access control lists (ACLs) puts out fires by quickly blocking access to large swathes of traffic, but this also inevitably blocks real users. These users will then either be turned away from your product or be forced to contact your support channels to resolve the issue.



This is made more difficult by hybrid attacks, in which real people solve CAPTCHAs for bots and then hand the session over to a bot to continue their automated activities. Rather than broad and overreaching WAF rules or ineffective custom code that can't keep up with new bot behaviors, stable identifiers for every device and visitor to your app are required for the best possible bot detection coverage that won't frustrate your customers.

Beating bad bots with Stytch Device Fingerprinting

Businesses and developer teams who need to scale quickly can see huge security and efficiency benefits from third-party bot detection solutions. Stytch Device Fingerprinting (DFP) seamlessly integrates production-grade DFP with your applications, enabled by well documented and flexible APIs and SDKs for real-time bot detection that doesn't impact real users.

Stytch's Device Fingerprinting utilizes every bot detection technique explained above, including IP fingerprinting with intelligent rate limiting, and a sophisticated JavaScript library and Web Assembly binary that collects signal data and hardware and browser information.

This information is evaluated and consolidated to generate highly stable device identifiers that remain consistent in the face of anonymization measures such as incognito browsing, VPNs, and changes in user agent or IP address. These bot detection technologies are supplemented by a supervised ML model, ensuring reliable bot detection that is much more accurate than solutions that rely solely on CAPTCHA/reCAPTCHA.



Additionally, Stytch offers customizable recommendations to allow, block, or challenge device access based on risk assessments. This flexibility is crucial for dynamically responding to potential security threats, ensuring robust security while maintaining user experience. Precise traffic management and tailored security can also be implemented with granular control based on device classification, trust levels, and authorization status.

For more information on how Stytch's Device Fingerprinting can help you block bad bots, check out our docs section or learn how to bootstrap Stytch DFP in just a few minutes.

Need additional help getting started? Reach out to a Stytch authentication expert.






---


# Why email verification is crucial for B2B applications
Source: https://stytch.com/blog/why-email-verification-is-crucial-for-b2b-apps/

Email varification protects businesses, their customers, and their sensitive data from a myriad of potential security threats. We will explore those threats and key considerations on how to verify email addresses in this article.

In the dynamic world of B2B and multi-tenant applications, email verification during signup is not just a best practice—it’s a cornerstone of secure application design. It’s one of the simplest and most proactive steps any engineering team can take to prevent fraud.

Some may worry that introducing up-front verification could impact sign-up conversion rates. However, the benefits of email verification far outweigh the manageable UX challenges. Email verification protects businesses, their customers, and their sensitive data from a myriad of potential security threats. 

We will explore those threats and key considerations on how to verify email addresses in this article.

Why email verification matters for B2B apps

For B2B applications, where users often represent entire organizations, the stakes are even higher. A compromised account or an unchecked fraud attempt could impact multiple users not only within the same tenant but also across tenants.

B2B applications often deal with highly sensitive company data. In multi-tenant environments, where multiple companies share the same infrastructure, email verification becomes vital. Without it, unauthorized users could exploit vulnerabilities in tenant segregation, potentially leading to data leaks or unauthorized access to another tenant's environment. 

For example, imagine a SaaS platform like Workday, Gusto, or Rippling, where multiple companies manage their payroll and HR data. Without email verification, an attacker could register using a domain they don't own (e.g., tim@gusto.com) to impersonate a legitimate user from Gusto. This could allow bad actors to manipulate or steal data intended for actual employees.

Non-verification will also result in an influx of fake signups, trial repeaters, spammers from disposable emails and bots—polluting the integrity of your user base and business. The downside of not verifying emails is costly.

Preventing account takeovers, breaches and, abuse

If your application doesn’t require email verification, malicious actors can exploit this gap to register accounts with email addresses they don’t control, opening the door to several risks. Here are several attack vectors you should be aware of.

Pre-hijacking accounts and invites

Without email verification, a bad actor can preemptively create an account under another user's email address ahead of time. Once the real owner of the email signs up or logs into the site using a passwordless method, the attacker now retains backdoor access to the account with a password they previously set up.

Attackers might create thousands of accounts using legitimate email addresses, and then wait for the real owners of these emails to sign up or log into these apps using alternative authentication methods. 

This also creates the risk of app invitations being hijacked through spoofed email addresses. For example, if your application allows user invitations via email, an attacker could preemptively register with the email before the legitimate employee does. 



These types of attacks could have severe consequences for both B2C and B2B applications, particularly if your authentication provider or service deduplicates accounts based on different auth methods rather than intelligently linking legitimate profiles. With Stytch, however, all authentication methods, regardless of the method a user initially signs up with, point to the same user profile because we strictly enforce email verification as early as possible.

Honeypot organizations

Honeypot Organizations or organization spoofing occurs when an attacker impersonates a legitimate company to gain unauthorized access. Attackers may create fake organizations using convincing but illegitimate email domains (e.g., hr@realcompany.com) to trick employees of the real organization into joining. 

If your B2B app doesn’t enforce email verification, attackers can easily trick employees into joining fraudulent organizations, either by sending deceptive user invitations or sophisticated social engineering scams. Once infiltrated, attackers could steal confidential information, manipulate internal workflows, or even launch phishing attacks within the organization.

Slack faced a huge surge of invite spam, where attackers exploited its user invitation flow to impersonate organizations and send deceptive user invites. 

Free tier and trial abuse

One of the most common methods of free trial abuse is using temporary or disposable email addresses to set up fake user accounts on SaaS apps that don’t verify email ownership. For companies that offer free trials or credits as part of a PLG strategy, attackers may sign up for infinite accounts in order to continuously abuse free resources. 

Fraudulent users often use these fake accounts to exhaust system or compute resources (like AI compute, storage space, processing speed, API calls, etc.) which are typically capped for legitimate free users.

Aside: At Stytch, we’ve seen how combining email verification with intelligent and advanced device fingerprinting creates a strong defense against free trial and freemium abuse. By using our fingerprint APIs and SDKs to detect and block fraudulent authentication attempts from the same device or network, you can significantly limit resource abuse for any app.

Email verification is still the industry standard

The importance of verifying email addresses upfront isn’t just a best practice—it’s the standard among leading companies. An analysis of the AI Auth Landscape reveals that top companies in the space require email verification during signup:



These companies handle highly sensitive data, making email verification a critical security measure. The takeaway? Email verification isn’t just a security enhancement—it’s an expected part of interacting with your application.

Implementing email verification

Robust email verification doesn’t have to disrupt the user experience. By implementing user-friendly, secure methods, applications can achieve a balance between security and convenience. 

Fortunately, there are now multiple auth conventions and methods that engineering teams can rely on to verify email ownership without disrupting the standard user experience, and Stytch supports them all.

Email Magic Links and One-Time Passcodes (OTP)

In traditional email + password authentication flows, the easiest way to verify that a user owns a particular email address is to send a unique magic link or one-time passcode (OTP) to the email they must have provided. At Stytch, we’ve built our email verification products to provide an even more seamless auth experience, so much so that your users may not need to store or remember any passwords.



Stytch handles the delivery of all your Email Magic Links and OTPs. With Stytch's APIs, you can also build out your sign-up, sign-in, and password reset flows using OTPs across email, SMS, and WhatsApp, ultimately relieving your engineering team from the overhead cost of building and managing these messaging services.

OAuth with reputable providers

Another reliable method for verifying user identity and email ownership is OAuth and OpenID Connect (OIDC). By allowing users to sign up or sign in through trusted third-party identity providers like Google and Microsoft, your app offloads the burden of identity verification to established industry providers.



Regardless of whether you’re a B2B or B2C app, Stytch offers out-of-the-box OIDC support for over 14 identity providers, including GitHub, Salesforce, Slack, Hubspot, Apple, Facebook (Meta), and more. 

Single Sign-On (SSO) for Enterprise Clients

For enterprise-focused B2B applications, SSO is a must-have authentication method for integrating with identity providers that house and manage corporate email addresses.

Identity providers (IdPs) such as Google, Okta, and Microsoft Entra ID, OneLogin often manage their identity profiles for corporate users in XML format. These can only be accessed by building intricate configurations and assertion flows according to complex identity protocols (SAML or OIDC). 



With Stytch, you don’t need to build support for the SSO from scratch. Instead, you can easily configure SSO for your enterprise customers, regardless of the IdP where their user identity data is stored. Stytch facilitates the exchange of SAML and OIDC requests and assertions between the IdPs and your B2B app.

Stytch: seamless and secure B2B auth

When it comes to B2B authentication, balancing security and user experience is crucial. Here's more detail on how Stytch leverages email verification to deliver a modern, frictionless approach to B2B authentication: 

Stytch’s B2B platform always requires email verification through a trusted factor (OAuth, Email magic links, Email OTPs, or Enterprise SSO) in order to sign up for an account in any organization.

Stytch’s Discovery Flow allows users to see and accept pending invites, or Just In Time Provision into their team’s workspaces based on email domain after verifying their email address



Stytch supports Google One Tap, a very popular, low-friction implementation of login with Google that enables end users to select their account and login/signup with a single tap.

Stytch has built in ergonomics to ensure that conversion remains high with email based methods, such as built in failover email providers and protection against email security scanners.

Stytch automatically deduplicates accounts safely on email address to provide a seamless experience where users can log in through any method and gain access to the same account. We address the pre-hijacking vulnerability in our B2B product by always requiring email address validation on sign up. 

Product and engineering considerations

Introducing email verification into applications is often a decision driven by product teams. While engineering may hesitate to advocate for changes due to concerns about added complexity, product teams typically focus on the broader impact on user activation and security. 

Here's how to align the teams:

Highlight UX Benefits: Alternative login options like Google OAuth, email magic links, or one-time passwords (OTPs) can actually improve activation rates rather than slow them down (one example: 7% uplift with Google One Tap for Zapier) while ensuring security. See more literature on how passwordless login methods impact user conversion here.

Mitigate Engineering Concerns: Many teams will opt to migrate to a provider like Stytch as opposed to investing the engineering resources to build solutions to these problems in-house. Teams like Orb have successfully migrated millions of users to Stytch in just one week and were able to implement these security and UX improvements very quickly thereafter.

Emphasize the high cost of skipping verification: Skipping email verification may seem like a shortcut to streamline the signup process, but the risks far outweigh the temporary benefits:

Data Breaches: Unauthorized access to sensitive data can result in costly breaches, regulatory fines, and customer loss.

Free Usage Costs: Increased cost associated with free credit usage, ultimately increasing your total COGS.

Reputation Damage: Security incidents undermine user trust, potentially leading to churn and lost business opportunities.

Legal Liabilities: Regulations like GDPR, HIPAA, and CCPA require businesses to take adequate measures to protect user data. Failure to verify email addresses could result in non-compliance and steep penalties.

By winning over cross functional teams with this framing, you’ll make it easier to secure buy-in for email verification initiatives.

Conclusion

In B2B and multi-tenant application landscapes, email verification is not optional—it’s a fundamental requirement for security, reliability, and user trust. By implementing robust verification methods, you protect your users, their organizations, and your own platform from a wide range of threats.

Ready to implement enterprise-grade auth? Stytch offers a comprehensive suite of auth and fraud preventions methods, whether it's email magic links, email OTPs, OIDC SSO, SAML SSO, or even our device fingerprinting product.

If you have questions about our features, pricing, customer support, or anything at all, feel free to schedule a call with an auth expert. 





---


# The age of agent experience
Source: https://stytch.com/blog/the-age-of-agent-experience/

AI agents are here—from ChatGPT Operator to coding tools like Devin and Lovable, there’s a rapid growth of products that can interact with websites on our behalf. It’s time to start building for a new persona: the autonomous agent. Instead of just designing experiences for human users, we need to think carefully about how machines will access data and perform actions securely, with transparency and user consent.

Designing for the agent experience

AI agents—from ChatGPT Operator to coding tools like Devin and Lovable, are transforming how we interact with apps. Agents are capable of navigating interfaces, making requests, and executing tasks on behalf of users, and they’re taking over navigating the web for humans. It’s time to start building for a new persona: the autonomous agent. Instead of just designing experiences for human users, we need to think carefully about how machines will access data and perform actions securely, with transparency and user consent.

At a high level:

Agents need the ability to “log in” or otherwise prove they have permission to act on a user’s behalf.

Users need confidence that these agents are only doing what they explicitly allow (and have a way to revoke access if something changes).

Service providers need robust ways to authenticate and authorize agents, confirm user consent, and manage risk.

The good news is that we already have a robust standard for delegating secure, scoped, and revocable access: OAuth. Rather than giving your password to every new application or agent, OAuth is designed to give the right party the right permissions in a safe, standardized way.

AX: The next frontier after UX and DX

In a recent post, Introducing AX: Why Agent Experience Matters, Netlify Co-Founder and CEO Mathias Biilmann argues that agent experience (AX) will be as big a deal as user experience (UX) and developer experience (DX) once were. Historically:

UX (coined by Don Norman in 1993) transformed how we think about the human interface—covering everything from visuals to workflows to how a product “feels” for real people.

DX (popularized in 2011) recognized that developers were an equally important audience. Platforms that offered better docs, better APIs, and less friction saw massive growth and adoption.

Now, we have agents—powered by large language models, multi-modal inputs, and the ability to handle tasks in an “autonomous” way. According to Biilmann, “we need to start focusing on AX or ‘agent experience’—the holistic experience AI agents will have as the user of a product or platform.”

Agents as a driving force

Investing in agent experience will be table stakes as more and more companies launch agents and users shift to using other products via those agents instead of directly interfacing with the UI.

Agents are more than generative—they have “agency,” meaning they can initiate actions and transactions rather than simply responding to user queries.

Tools or platforms poorly suited for LLMs will quickly fall behind, because humans will lean on the AI that best orchestrates their tasks.

Open Ecosystems will likely outperform closed “vertical” integrations in the long run. If you welcome any agent a user prefers—complete with easy onboarding, open APIs, and secure authentication flows—your product becomes more powerful and “agent-friendly.”

As we’ll discuss later, making your system accessible via OAuth is one of the biggest steps you can take to ensure a high-quality agent experience.

Building a great agent experience

Many of the principles that have been foundational to UX and DX will apply to AX as well, but some things won’t carry over. We have UIs because humans are incredible at deriving meaning from icons and visuals; humans communicated with pictures long before we invented written language. 

In contrast, AI’s native language is numerical embeddings – both text and images need to be translated, but images don’t have the same “natural” tokenization that text does, and can be far more computationally expensive. Therefore, we should orient AX around methods of communication that computers are best at and optimized for their consumption – browsers are slow, client code takes time to render. Key principles for great AX include:

Clean, Well-Defined API: An API originally designed with good DX in mind is a solid starting point for agents. Many apps that have never needed APIs before will need to invest in building them or investing in more comprehensive APIs to ensure agents have access to complete functionality. Focus on clear documentation, well-structured data, and stable endpoints to give agents a reliable way to interact with your product.

Easy User Onboarding: Ideally, both the human user and the agent can get started with minimal friction. Providing a streamlined flow—like a single command or a concise OAuth handshake—ensures that agents can operate quickly while users stay in control.

Frictionless Agent Operations: Once granted the right permissions, agents should be able to do their work without cumbersome manual steps. Whether it’s spinning up a new instance, managing resources, or analyzing data, the experience should be as automated and efficient as possible—maximizing both agent productivity.

Step-Up Authentication: There will be some scenarios where an agent shouldn’t be able to continue without a human in the loop approval. For example, when moving large amounts of money, executing on a write action that impacts your production code, or similar, there should be an approval workflow that requires the human user’s input.

When you take these steps—offering secure APIs, simplifying onboarding, and removing bottlenecks in the agent workflow—you ensure a better experience not only for AI-driven agents but also for your human users. In many cases, the same design choices that improve AX end up improving user satisfaction and adoption overall.

Why OAuth is perfect for agent auth



For years, OAuth has let you “Log In with [provider]” and then give an application or service permission to access your data. This typically involves short-lived access tokens, refresh tokens, and specific scopes that define exactly what the third party can do.

When an AI agent is your third party, the underlying security needs aren’t all that different:

Secure User Consent: Don’t give your agent your username and password. OAuth provides a secure flow ensuring the user explicitly approves which data or actions the agent can access.

Token-Based Authorization: The agent receives tokens that can be scoped and revoked. This protects your core credentials and allows granular permissioning.

Long-Term Agent Use with Revocation: Agents might need ongoing access to your account. With OAuth, you can revoke their access at any time without resetting your main password.

Step-Up Authentication for Extra Security: For sensitive actions, agents will need to require a human in the loop approval to proceed.

There’s no need to reinvent the wheel here, OAuth is a battle tested standard that brings a familiar experience to this new world of agents. But this does mean that all applications will need to become OAuth providers in order to allow for easy and secure access for agents.

Leveraging existing OAuth flows for agents



When you think “OAuth,” you might picture a user in a browser clicking a “Consent” button. In some cases, this will be practical for agent auth as well. But for some agent scenarios—where the AI may not have a graphical interface—there are specialized flows that handle these interactions elegantly:

Device Authorization Grant (Device Flow): Often used when the application is running on a separate device from the user’s smartphone or laptop, like a TV. The agent notifies the user and shares a link to visit, the user follows the link to consent on their main device, and the agent obtains an OAuth token.

CIBA (Client-Initiated Backchannel Authentication): This OpenID Connect flow is handy for high-risk actions (e.g., making large stock trades) because it ensures the user must explicitly confirm. The service (e.g., a brokerage) can notify the user directly, rather than relying on the agent to ask permission.

Choosing which flow to use depends on how you want to handle user notifications, scope approvals, and risk. But the bottom line is the same: OAuth has already solved the core delegation problem for third-party actors—human or agent.

Everyone needs to be an OAuth provider



If your product doesn’t work seamlessly with other agents that your users might be leveraging, eventually, you risk losing out to competitor platforms that welcome every agent and provide a smooth AX.

Being an OAuth provider is part of building that open ecosystem. With OAuth, your app can:

Offer standardized flows for token-based authentication.

Empower users to pick whichever AI agent they trust.

Define scopes for read-only vs. read-write, normal actions vs. high-stakes actions.

Provide revocation or additional user checks for truly sensitive operations.

In short, everyone needs to become an OAuth provider if they want to attract or even allow AI agents to operate in their ecosystem and maintain a competitive advantage.

Don’t reinvent OAuth

There are a lot of ideas out there about what the future of agents might look like. Many agent demos are basically letting an AI browse your site like a slow, not-so-smart human—and ignoring that OAuth flows already exist for secure, user-centric delegation. Here are a few takeaways on why we shouldn’t be trying to reinvent the wheel with agent auth:

On agent authentication: Don’t give the agent a username and password, it’s annoying for users and a security risk.

On frictionless interactions: If your product is friendly to bots (i.e., it has an API and an OAuth flow), you don’t need complex RPA to simulate a human user.

On tightly scoped access: Agents won’t necessarily need access to everything a human user can do, and in many cases, it might be a non-starter to give them that kind of unscoped permission. That’s the whole point of scopes.

On user consent: For big actions, require device flow or something that ensures the human is in the loop. Making human-in-the-loop approval a core product flow will make it easier for users to trust agents with your application.

Ultimately, adopting these OAuth-driven best practices is how you deliver a top-notch agent experience and avoid reinventing the wheel every time a new AI tool emerges.

Architecting for agent experience

Moving from an app built “just for humans” to an agent-friendly design doesn’t need to be a huge overhaul. Consider these recommendations:

Expose Clear, Machine-Friendly APIs: As Biilmann notes, “Platforms or frameworks that are hard for LLMs and agents to use will start feeling less powerful.” Provide stable endpoints, well-structured data, and documentation that an agent can parse.

Scope Your Permissions Thoughtfully: Don’t rely on a single monolithic permission that grants total control. Break it down: “read account data,” “post new content,” “initiate high-value transactions.”

Plan for Token Storage and Rotation: Agents may store tokens long-term. Make sure these are limited in scope, easily refreshed, and promptly revocable.

Have a Strategy for High-Risk Actions: For big or irreversible actions, consider a second layer of user confirmation. This can be a device flow or a backchannel (CIBA).

Aim for an Open AX Ecosystem: Follow the principle that your users might bring any agent. Offer a standard OAuth interface that any agent can plug into, without a ton of custom code or guesswork.

The future of agent auth

Designing your systems to be agent-friendly might sound futuristic, but as Mathias Biilmann’s post outlines, AX is already here, just like UX and DX once were. Platforms that invite AI agents, empower them with secure APIs, and let users choose (and limit) agent permissions will likely outcompete those stuck in closed or manual approaches.

At Stytch, we’re excited about this agent-driven future and are committed to making it simple for everyone to implement secure agent access. By leveraging OAuth flows, we can make it simple for you to power best-in-class authentication and authorization experiences that scale from human users to the agents they trust.

That's why we built Connected Apps—a powerful feature that makes it easy for your application to be integrated with AI agents, third-party apps, and multi-app ecosystems. With Connected Apps, your application can become an OAuth 2.0 identity provider, delegating access and permissions to build seamless integrations with other first-party and third-party applications.

Check out our step-by-step guide in the developer docs.




---


# Detecting AI agent use & abuse
Source: https://stytch.com/blog/detecting-ai-agent-use-abuse/

The key question is: Can you detect AI agent traffic on your application today? We tested multiple AI agent toolkits across high-traffic consumer sites, and the results were clear—legacy detection techniques (CAPTCHAs, IP blocking, user-agent filtering) are largely ineffective. Here’s what we found.

AI agents aren’t just indexing your content anymore. With tools like OpenAI’s Operator, Anthropic’s Computer Use API, and BrowserBase’s Open Operator, these agents can navigate the web, mimic real users, and even take actions at scale. The challenge? Knowing whether they’re enhancing your user experience—or opening the door to abuse.

In some scenarios, apps might encourage agent use if it improves usability and adoption, but in other cases, it could present unacceptable risks for application developers or be used as a method for malicious attacks (e.g. credential stuffing or fake account creation).

In either scenario, observability is paramount. Applications need to know what traffic is on their site (is this a human? A bot? A good bot or a bad one?) in order to make intelligent decisions about how to shape traffic and enforce desired usage patterns. AI agents add an additional wrinkle as users are already sharing their credentials with tools like Operator, meaning even a well-intentioned agent creates potential risk for these applications and their users.

The key question is: Can you detect AI agent traffic on your application today?

We tested multiple AI agent toolkits across high-traffic consumer sites, and the results were clear—legacy detection techniques (CAPTCHAs, IP blocking, user-agent filtering) are largely ineffective. Here’s what we found.

The new reality of bot traffic: What AI agent traffic looks like

Traditionally, bot detection relied on CAPTCHAs, IP blocking, and user-agent filtering. But modern AI agents are engineered to look like actual users:

Realistic fingerprints: They use genuine IP addresses, user agents, and even simulate mouse movements.

Headless browsing at human speeds: Their interactions mimic natural browsing behavior, evading rate-limit triggers.

Datacenter origins—but not always: While some (like OpenAI’s Operator) come from known Azure datacenters, others (like Anthropic’s API) can run locally, borrowing your machine’s properties.



On the surface level, AI agent traffic can look quite similar to regular human user traffic. Here are examples of browser & network properties across different AI agents:



Both OpenAI’s Operator and BrowserBase’s Open Operator spin up remote datacenter or container‑hosted Chromium instances, rather than installing any software on your local machine. Because these solutions originate from a cloud‑hosted environment (with IP addresses and other signatures tied to the provider’s infrastructure), they can be easier to detect via methods like ASN lookups if the provider’s IP ranges are well known.

By contrast, Anthropic’s “Computer Use” functionality is available only through its API as of now, and you can choose how to run that API (e.g., directly on your own machine vs. inside a VM or container). If you run it locally, it inherits your local system’s properties like IP and ASN; if you host it in the cloud, it uses whichever environment that provider offers. Each approach has its own implications for fingerprinting and detection.

Currently, Anthropic provides two options for using their agent:

Direct use of your computer environment (not recommended due to security concerns around unrestricted access).

Setting up a virtual machine or container with minimal privileges to run the API. You can either run this locally or deploy to a cloud provider using Docker, in which case it won’t inherit the user’s network properties.

Whereas stricter sites like Reddit block OpenAI and BrowserBase outright, Anthropic’s approach allows it to successfully bypass even these strict sites when run locally:



And with tools like BrowserBase, there are also now open-sourced options for building browsing AI agents that allow potential attackers to increase the stealth of their headless browsing setup. This means we should expect continued, quick iteration on some agent use cases that will make them even more difficult to detect. As an example, BrowserBase offers premium plans with more advanced stealth to bypass CAPTCHA and other detection techniques:



Today, most sites are allowing agent traffic to navigate freely – whether these sites are detecting the abnormalities of this traffic (and choosing not to take action) is hard to say. For some like Reddit & Youtube, their block on OpenAI Operator indicates they want to lock down agentic traffic. When these AI Agents bypass their restrictions (as detailed below), it’s a good signal those tools are actually flying below their radar today versus being officially sanctioned.

For others that allow this traffic, they may actually encourage it for user convenience or potentially have perverse incentives in some cases to allow a certain amount of bot traffic (Ticketmaster is a potential example of this given they can benefit from some level of bot activity increasing ticket purchase rates). Many more sites, however, simply don’t have the traffic intelligence to detect these AI agents, which explains why they can operate freely.

In testing the three primary AI Agent browsing toolkits on a set of high traffic consumer sites, we found that Youtube and Reddit were the only ones that consistently blocked this traffic:



Few websites are blocking popular AI Agents today – indicating either a lack of detection, ambivalence towards enforcement, or both. Reddit & Youtube are a couple of key outliers that block this traffic when they can discern it.

Still, the differences are interesting. It’s worth understanding why Anthropic or BrowserBase are sometimes able to bypass sites that otherwise are blocking this traffic. In BrowserBase’s case, they generate a slightly different user-agent each session, which sometimes aligns with the underlying chromium runtime but sometimes attempts to be deceptive by claiming to be a different version, which leads to more inconsistency in whether companies detect it correctly.

Companies like LinkedIn and X are particularly sensitive to scraping on their sites, so the lack of enforcement is surprising. This suggests they’re not currently able to confidently discern this is programmatic traffic.

How to tell an agent from a human

The obvious question here is: shouldn't this be easy to detect by using just an IP or user agent?

And the answer is yes and no. For OpenAI Operator, it’s pretty straightforward to detect given its stability & origin point. For Anthropic and BrowserBase (and the new agents entering the market), it’s a bit more complicated.



Some key elements worth knowing:

OpenAI & BrowserBase both operate on top of chromium – being able to discern chromium browsers vs. true chrome is key for detecting the latter since BrowserBase modifies things like IP, user agent, etc for increased stealth.

OpenAI originates out of a known Azure datacenter while BrowserBase originates from a known AWS datacenter.

OpenAI hands off non-invisible CAPTCHAs to the end user to complete, while BrowserBase offers options for automatically solving.

Ideally, you want to detect this traffic beyond more coarse identifiers like known datacenter IPs so that your detection is fully resistant to adjustments agentic traffic will make in the future. And core to that is having high confidence in whether a browser interacting with your site is a real browser or a headless instrumentation.

This is where we’ve personally found Machine Learning to be incredibly useful by building a browser lie detector. We look at a very wide range of browser signals & we have downloaded the entire historical archives of every browser version that has been released that we can find and trained our model on what authentic browsers look like vs. anomalous or deceitful browsers. 

To provide this visibility, we’ve automated additions of new legitimate browser signatures upon new releases, we fingerprint it, run it past the model to establish an authentic set of signals for the current browser version, allowing us to detect anyone trying to emulate that version inorganically. With that fingerprinted dataset, machine learning can be used to detect anomalies with high accuracy. It’s this signal collection that has allowed us to see that OpenAI & BrowserBase are full chromium builds, while Anthropic’s Firefox browser fails to emulate certain characteristics that would be present on a real user’s Firefox instance.

Charting your path forward

Whether you choose to block, restrict, or harness AI agent traffic, effective observability is non-negotiable. Here’s our current playbook:

Monitor actively: Start by detecting and monitoring AI agent fingerprints. Learn from their behavior before enforcing hard limits.

Embrace legitimate use cases: Some users may leverage AI agents to streamline workflows (e.g., automating reporting on your dashboard). Recognize these opportunities while safeguarding against abuse.

Iterate quickly: As AI agents evolve, so must your detection strategies. Invest in ML-based solutions that adapt alongside new agent behaviors.

AI agents are rewriting the rules of web interaction. They offer exciting UX advancements—but also present new security challenges. The race is on: evolve your detection or risk being outpaced by bad actors and unintended misuse.

If you’re interested in learning more about how to detect these agents & enforce certain behaviors, reach out to us to chat more (or take a look at the fingerprinting techniques we’re using to detect them).







---


# Rebranding Stytch: A new look for the future of auth and security
Source: https://stytch.com/blog/rebranding-stytch/

Rebranding is much more than just a fresh coat of paint or a shiny new logo—it’s a reflection of where a company has been, where it’s going, and most importantly, how it wants to connect with the people it serves. For Stytch, our recent rebrand represents a step forward not just in design, but in our mission to make authentication simple, secure, and more scalable for everyone. Here’s a look behind the scenes of our rebranding journey and why we believe it’s a milestone worth sharing.

Rebranding is much more than just a fresh coat of paint or a shiny new logo—it’s a reflection of where a company has been, where it’s going, and most importantly, how it wants to connect with the people it serves. For Stytch, our recent rebrand represents a step forward not just in design, but in our mission to make authentication simple, secure, and more scalable for everyone. Here’s a look behind the scenes of our rebranding journey and why we believe it’s a milestone worth sharing.

Why rebrand, and why now?



Since our founding in 2020, Stytch has evolved from a startup tackling core authentication challenges to a platform powering critical infrastructure for some of the world’s most innovative companies. As our products, customers, and ambitions have grown, it became clear that our brand needed to capture the breadth of what Stytch has become and the bold vision we have for the future.

We’ve since launched a multi-tenant B2B auth platform with features like SCIM and SSO, an advanced bot and fraud prevention suite, and granular authorization. Our customer base now ranges from startups to enterprise-scale companies like HubSpot, Calendly, Groq, Workday, and Zapier.

Our rebrand comes at a pivotal time in the industry. Businesses and developers are demanding more flexible, user-friendly authentication solutions, while users are increasingly wary of security risks and data privacy concerns. As AI and the rise of agentic workflows reshape our industry and the threat landscape, we’re preparing for even more rapid change. Over the coming week (and year), you’ll see us launch exciting new technologies to help developers address evolving security requirements and scale their applications with ease amidst this technological evolution.

Our new brand is designed to reflect our commitment to meeting these challenges head-on, with clarity, confidence, and care.

Defining the core of Stytch’s identity

Before diving into colors, fonts, or logos, we started with the most important question: What does Stytch stand for? Through workshops, interviews, and feedback sessions with our team and branding agency, Fuzzco, we distilled our brand essence into three key values:

Empowering engineering excellence: Stytch provides software engineers with the infrastructure to secure applications with the expertise of the world’s best authentication specialists, offering tools that are straightforward to integrate while abstracting away complexity.

Redefining expectations for identity solutions: We aim to set a new benchmark for authentication infrastructure by eliminating engineering frustrations and technical debt, enabling teams to focus on building innovative applications and exceptional user experiences without having to worry about protecting their users and accounts.

Adaptable and evolving solutions: Stytch delivers an authentication experience that feels like having a dedicated group of identity and security experts embedded on your team—solutions that adapt and scale with your needs while ensuring you remain ahead in a rapidly evolving threat landscape.

These values guided every decision we made during the rebranding process, ensuring the final result was authentic and aligned with our purpose.

The creative journey

At Stytch, design is central to our mission to make auth and security simpler and more scalable. From structuring APIs to guiding workflows in our Dashboard and simplifying technical concepts in our docs, every element is crafted to make authentication and security more intuitive for developers.

Our new identity reflects our evolution into a comprehensive security platform capable of handling mission-critical needs while fostering innovation and a stellar developer experience. We explored numerous directions before finalizing a visual and verbal identity that feels distinctly “Stytch.”

Icon and wordmark: Embodying security and seamless integration



Icon: When we launched Stytch, we intentionally omitted an icon to focus on building brand recognition around the name "Stytch." However, as we’ve grown, the need for a distinct symbol has become clear—particularly for small visual spaces where the full wordmark isn’t practical.

Our new icon draws directly from the forms in the wordmark, creating a cohesive connection between the two. The interlocking shapes embody trust, security, and adaptability while also serving as a versatile framing device for content.

Wordmark: We refined the wordmark by reverting to title case and tightening the kerning, bringing the letters closer together. This design choice emphasizes the idea of seamlessness and reflects our commitment to delivering tools that integrate effortlessly into developers’ workflows. 

Typography: Balancing boldness and functionality



When selecting Booton and Chivo as our brand typefaces, we aimed to strike a balance between sophistication, boldness, and approachability. Booton, a refined sans-serif, serves as the cornerstone for headlines and body copy, ensuring clarity and impact. To complement it, we chose a monospace font—a subtle nod to our developer audience—that adds interest and character in smaller text moments, reflecting the technical precision at the heart of Stytch.

Colors and pattern: Stitching together sophistication, innovation, and 8-bit



Our new color palette strikes a balance between sophistication and innovation. Anchored in black, white, and blues, it communicates technical expertise, polish, and security. To complement this foundation, we introduced a vibrant secondary palette that adds energy and optimism when needed. This duality captures the essence of Stytch—serious and secure, yet fresh and forward-thinking.

Our pixel pattern incorporates the full palette, creating dynamic, branded backgrounds for marketing materials. It’s not just a design element but a reflection of our approach: adaptable, structured, and uniquely Stytch.

Framing device: protection at every corner



As part of our new identity, we developed a framing device derived from our icon, embodying the protective essence of Stytch. The framing device serves dual purposes, functioning dynamically in motion and statically for content framing.

In motion, the frame guides attention by drawing content on and off the screen, creating fluid transitions that feel deliberate and seamless. In static applications, it acts as a structured border, ideal for highlighting content in social media and out-of-home (OOH) marketing. This versatile element reinforces our commitment to security and adaptability, providing a visually distinct and cohesive design language that ties back to our core identity.

Icons and illustrations: Blending past and present



To complement our pixel pattern, we’ve designed a suite of pixel icons that seamlessly integrate across our marketing site and documentation. These icons create a cohesive visual bridge between our product and marketing materials, ensuring a unified experience.

Our illustrations take a modern, technical approach, resembling schematic blueprints that highlight precision and clarity. The balance between the bold, structured pixel icons and the lighter, line-based illustrations introduces an intentional contrast that reflects our brand's duality—grounded in technical expertise yet innovative and forward-looking. This visual tension enhances the cohesiveness of our design system, embodying Stytch’s commitment to blending the functional with the creative.

Beyond aesthetic: What this means for our customers

While the visual refresh is exciting, the most important aspect of our rebrand is what it enables for our users. Here’s what you can expect:

Enhanced clarity: Our new website and documentation are designed to make it easier than ever to explore, understand, and implement Stytch’s solutions.

A unified experience: From our developer Dashboard to our customer support interactions, the new brand creates a cohesive and intuitive experience at every touchpoint.

Reinforced trust: Our updated messaging and design emphasize our commitment to security and reliability, giving users greater confidence in choosing Stytch.

Looking ahead

Rebranding is just the beginning. As we continue to innovate and expand our offerings, our new identity will serve as a foundation for growth and a reminder of our mission. We’re incredibly proud of how far we’ve come, and we’re even more excited for what’s ahead. Thank you to our customers, partners, and team for being a part of this journey.

Explore our new website and docs. Or sign in to see our new Dashboard.

Stay tuned for Launch Week starting Feb 18, where we’ll unveil exciting new features to help you build the future of authentication and security. Follow us on X for daily product announcements.





---


# Stytch Fraud & Risk Prevention: Intelligent Rate Limiting, real-time monitoring, and more
Source: https://stytch.com/blog/stytch-fraud-and-risk-prevention-major-enhancements/

To kick off Launch Week, we’re excited to announce several major enhancements to Stytch’s Fraud and Risk Prevention solution, providing even stronger security for your app and users while making the platform easier to use. These new features improve on what is already the most accurate and sophisticated fraud and risk prevention platform available. 

To kick off Launch Week, we’re excited to announce several major enhancements to Stytch’s Fraud and Risk Prevention solution, providing even stronger security for your app and users while making the platform easier to use. These new features improve on what is already the most accurate and sophisticated fraud and risk prevention platform available.

New features include:

Intelligent Rate Limiting: Adaptively protect against automated threats using dynamically weighted traffic signals.

Enhanced data visualization: Gain deeper insights and monitor real-time fraud patterns.

Event log filtering: Analyze traffic trends in your dashboard.

Streamlined rule creation: Create an authorization rule from an existing fingerprint directly from the dashboard.

Backend SDK support: Integrate across more languages.

External metadata support: Link fingerprints to your identifiers for better risk assessment.

The Most Reliable Way to Stop Attacks and Detect AI Abuse

With AI driving a surge in bot-driven fraud and abuse—from account takeover to phishing and compute abuse—Stytch’s Fraud and Risk Prevention gives you a powerful, proactive defense. That’s why teams from Replit to Calendly already trust Stytch to keep their applications secure.

Our solution combines deterministic identifiers with supervised machine learning for a highly accurate and immutable fingerprint that identifies every visitor to your application, while preserving user privacy and resisting reverse engineering. With new features like Intelligent Rate Limiting, our platform can evaluate the security risk in real time and return an authorization verdict that recommends you ALLOW, BLOCK, or CHALLENGE any visitor device, ensuring bad actors are kept out while real users face zero friction.



Stytch’s advanced fingerprinting technology has proven uniquely effective at detecting AI agent use from emerging tools like OpenAI's Operator and Anthropic's Computer Computer Use API. As AI agents gain more access and permissions to perform actions on digital platforms, they pose new security risks and challenges. Stytch helps your application stay ahead of the fraud curve by identifying any bot-driven or AI-driven traffic with precision.

Fraud and Risk Dashboard Upgrades

The first changes you’ll notice are the ones we've made to improve your dashboard experience. These upgrades were designed to help make the dashboard easier to navigate and use for workflows such as pulse checks on traffic shaping and investigations into false positives/negatives. A large part of fraud prevention is analysis of past data, so we wanted to make that experience even more powerful.

Enhanced Data Visualization

The first key dashboard improvement is added data visualization for dashboard activity. Most notably, a new live chart view gives you a quick understanding of traffic health.



Filters can be applied based on a range of parameters to get insight into traffic trends. The dashboard can display verdict actions, reasons, and detected device types for filtered sets of traffic. This will help you find trends on attack vectors based on characteristics such as common browser fingerprints, network fingerprints, and hardware fingerprints.

Being able to see common attributes of traffic can inform you about events like bot attacks that can be easily correlated with potential abuse and other useful insights for account safety. These new features make it easier to get a quick snapshot of your traffic shaping and drill down quickly into specific fingerprints to identify and prevent abuse.

Event Log Filtering

We have upgraded our device fingerprinting logs to be easier to navigate and filter by time frame or other parameters. This makes it so you no longer have to know the specific telemetry ID to view a particular verdict.



This is also improved by the inclusion of additional filterable parameters: “ExternalID”, “OrganizationID”, and “UserAction”, that can be synced from your own logging systems,letting you better associate external identifiers to the existing Device Fingerprinting logs.

All of these improvements are designed to improve your ability to investigate and associate your logs between different sources, giving you the tools to handle data and own your entire flow.

Streamlined Rule Creation

We’ve also made creating custom rules easier and more intuitive. You can now use an existing fingerprint to easily create an authorization rule. You can initiate the rule creation process directly from the dashboard, selecting an action and expiration for the targeted parameter without losing context.



The rules will then apply for all future fingerprints within the selected duration, clearly visible in the response payload. This addition makes it easier and faster to fix any false positives or negatives that may occur with a quick rule override.



Dynamically Weighted Intelligent Rate Limiting

Intelligent Rate Limiting (IntRL) has been improved under the hood to provide better accuracy on detecting low-volume traffic. As a quick overview, Intelligent Rate Limiting is a feature that automatically rate limits attacks on applications by leveraging a dynamic set of device and traffic sub-signals that more accurately predicts fraudulent traffic than traditional rate limiting strategies like IP addresses.

By refining our internal parameters used to determine when and who to rate limit, we've improved precision in detecting low-profile fraudulent activity, not just high-velocity attacks. This helps defend against more sophisticated attacks that are more targeted, which is common for bad actors who are attempting to take over specific accounts or deploy a small number of advanced bots.

This feature also excels at detecting and limiting automated browser activity by leveraging the full breadth of our device fingerprinting capabilities combined with our Intelligent Rate Limiting system. Our solution identifies common tools like Puppeteer, Selenium, Anthropic’s Computer Use API, and OpenAI’s Operator, even as they rotate through new IPs or known proxy providers.

Intelligent Rate Limiting applies an extra layer of defense, preventing abuse before it reaches critical volumes. Crucially, our approach doesn’t rely on blanket IP bans; instead, we can block on more granular attributes, like the browser version, preserving legitimate traffic while thwarting high-volume scraping and account generation attempts.

Other Notable Improvements

CNAME Support for Telemetry.js has been added, making it harder to detect Stytch is being used and block scripts.

IPGEO decisioning is in closed beta, which allows you to set rules to make BLOCK/ALLOW decisions based on IP addresses, ASNs, and country codes.

Proxy and VPN Information are now included in fingerprint lookups as is_proxy and is_vpn in the API response.

Getting Started

Our Fraud and Risk Prevention improvements and endpoints are now available in all of our backend SDKs, including Node, Go, Python, Ruby, Kotlin, Java and Rust, and can be used with both the B2C and B2B clients. Visit our docs for more details.

We are hard at work to ensure that Stytch Fraud and Risk Prevention is the most robust and accurate tool in the world to keep your product and users secure. Ensuring the best user experience and ease of access to data remains a priority, and we invite you to try it out for yourself.

Tell us how you want to use Stytch Fraud and Risk Prevention, and our team will help you start building!

Stay tuned tomorrow for the next product in Launch Week. And follow us on X for daily product announcements.





---


# Stytch Connected Apps: Make any app an OAuth provider for integrations and AI agents
Source: https://stytch.com/blog/stytch-connected-apps/

Today we’re introducing Connected Apps—a powerful new feature that makes it easy for your application to integrate with AI agents, third-party apps, and multi-app ecosystems. With Connected Apps, your application can become an OAuth 2.0 identity provider and delegate access and permissions to build seamless integrations with other first-party and third-party applications.

Today, we’re introducing Connected Apps—a powerful new feature that makes it easy for your application to be integrated with AI agents, third-party apps, and multi-app ecosystems. With Connected Apps, your application can become an OAuth 2.0 identity provider, delegating access and permissions to build seamless integrations with other first-party and third-party applications.

Whether you’re building AI-driven workflows or an enterprise integration, Connected Apps makes it easy for you to authenticate users, grant scoped permissions, and share data with other applications. With your app as the identity provider, Stytch brings all your connected applications into one place, making it easier to scale, control access, and manage permissions across all your integrations.



What once required months of engineering work can now be accomplished in minutes with Stytch. Let’s take a closer look.

OAuth: Powering the future of integrations

As AI agents become more widespread and data connectivity becomes even more essential for modern workflows, applications must carefully consider how external access to their data and actions are managed. The good news is that we already have a robust standard for delegating secure, scoped, and revocable access with user consent: OAuth.

At its core, Connected Apps is built on OAuth 2.0 and OIDC, providing a trusted, industry-standard way to authenticate and authorize users across applications. But we’ve taken it further, abstracting away complexity so developers can focus on building new integrations quickly.

With Connected Apps, Stytch handles all the heavy lifting for you by:

Implementing OAuth 2.0/OIDC flows end-to-end.

Managing token issuance, validation, and revocation.

Ensuring strict compliance with RFC 6749, security best practices, and session integrity.

What is Connected Apps exactly?

Connected Apps is a Stytch OAuth feature that enables you to configure any app as a fully compliant OAuth 2.0/OIDC Identity Provider with just a few steps in the dashboard and a few lines of code using the frontend SDK component.

You can follow our getting started guide for step-by-step instructions on how to configure your first Connected App.



For each integration, you create a Connected App and configure their settings:

Client types: Categorize each Connected App as a first or third-party application to align end-user consent flows with appropriate trust levels.

Custom scopes: Set granular permissions by defining the exact levels of access each Connected App Client can request within issued access tokens.

Custom claims: Define specific claims to include in the access token.

Secret rotation and PKCE: Manage client secrets or implement PKCE to create a secure exchange.

Redirect URLs: Specify allowed callback URLs for OAuth flow completions.

Once configured, you can leverage Connected Apps to:

Issue access tokens to third-party apps.

Transfer authentication state from browsers to extensions, plugins, and desktop apps without having to force users to re-enter credentials.

Enable seamless cross-domain navigation between distinct domains without terminating a user’s session (e.g. moving from Gmail to YouTube to Google Docs).

Authenticate AI agents that can perform delegated tasks across all the apps a user is registered with.

Building with Connected Apps

Connected Apps unlocks a whole new set of possibilities for developers, limited only by what data sources can be integrated. These examples highlight just a few of its use cases.

AI agents and workflows

From Anthropic’s Computer Use to OpenAI’s Operator to DeepSeek’s OSS models, AI agents are redefining what’s possible with end-to-end workflows by leveraging the same authentication protocols as Connected Apps.



For example, take coding agents like Devin.ai and Lovable.dev, who act like AI engineers embedded across your codebase and tool stack. When Devin wants repo access, it acts as an OAuth client, requesting permissions and access from GitHub as the identity provider. When it connects to Slack, another identity provider, it’s also an OAuth flow, scoped to channels and permissions. But what if you want AI agents like Devin to interact with your app?

That’s where Connected Apps comes in.



Stytch’s Connected Apps makes your app an identity provider, enabling the next-wave of AI agents to interact with your platform securely, and with the right permissions in place within the OAuth framework.



AI agents are reshaping sales, marketing, support, even everyday consumer experiences. Whether it’s an AI-powered sales agent optimizing B2B operations or a smart home AI assistant automating daily routines, Stytch provides the secure authentication and authorization layer needed to orchestrate all these operations on your platform.

Connected Apps helps your app become a foundation for AI-powered integrations.

Third-party data sharing and integrations

Connected Apps also enables foundational OAuth use cases like cross-application logins and integrations—allowing your application to authenticate users and facilitate secure data sharing between third-party apps. These cross-app integrations are essential for automating key workflows like in finance and payments with services like Plaid Exchange.





Let’s consider another example, Zapier, a platform that automates workflows across countless apps. With Stytch, your application can leverage Connected Apps to act as the identity provider and issue access tokens to third-party applications like Zapier to securely interact with your app’s API with read and write access.

This same flow could also be utilized to enable users to log into Zapier using your application, without creating new credentials.

A user visiting Zapier would select the “Log in with [your app]” on the login page.

Zapier redirects the user to your application who would forward the OAuth login request to Stytch Connected Apps for authentication.

Upon successful authentication and authorization code exchange, Stytch redirects the user back to Zapier with an access token on your application's behalf.

Sharing sessions across devices and domains

Additionally, Connected Apps can transfer and secure authentication across multiple first-party apps—ensuring a frictionless user experience across your entire product ecosystem.

Take Google and YouTube as an example. A user signed into Google (google.com) can seamlessly access YouTube (youtube.com) without logging in again because Google acts as the identity provider, managing authentication across both platforms.

Or Netflix and logging in between multiple devices.



With Connected Apps, your application as the identity provider is capable of sharing auth state across:

Domains: Authenticate users across multiple web properties, yourapp.com vs. yourapp.test.

Applications: Maintain authentication across distinct services and products, just like Google and YouTube.

Devices and platforms: Enable users to stay signed in across mobile, TV, desktop, web browsers, and even CLI applications.

Getting started

Ready to explore Connected Apps? Check out our step-by-step guide in the developer docs and sign up for a free developer account if you don’t have one already.

Happy building and stay tuned for the rest of Launch Week!

Follow us on X for daily product announcements.



---


# Stytch Admin Portal: Self-serve management for organizations and enterprise auth
Source: https://stytch.com/blog/stytch-admin-portal/

The Admin Portal is an embeddable and fully customizable suite of UI components within our frontend SDKs, providing out-of-the-box support for everything your customers would need to self-serve manage their account—from configuring a mandatory MFA policy, to setting up their SSO Connection, to automating role assignments for their SCIM Groups. 
Stytch’s Admin Portal components are powered by the Stytch API and protected via our RBAC product, allowing you to securely offer the full breadth of Stytch’s B2B product suite to your customers.

Today, we’re officially launching the Stytch Admin Portal, giving your customers the ability to manage auth and security settings directly within your application, with just a few lines of code.

The Admin Portal is an embeddable and fully customizable suite of UI components within our frontend SDKs, providing out-of-the-box support for everything your customers would need to self-serve manage their account—from configuring a mandatory MFA policy, to setting up their SSO Connection, to automating role assignments for their SCIM Groups.

Stytch’s Admin Portal components are powered by the Stytch API and protected via our RBAC product, allowing you to securely offer the full breadth of Stytch’s B2B product suite to your customers.

Managing Enterprise Auth, Without the Engineering Lift

Onboarding customers and setting up enterprise auth features like SSO and SCIM are never-ending and thankless tasks. Each new customer potentially demands valuable engineering and technical support resources, with back-and-forth troubleshooting between your team and theirs. It’s a time-consuming process that’s prone to errors and a drain on your resources.

That’s why we built the Stytch Admin Portal: to eliminate these pain points by offering a fully featured, drop-in dashboard experience that lets your customers take control of their auth setup directly within your app. Use only the components you need and style them to fit your brand.



What is the Admin Portal?

The Stytch Admin Portal itself consists of a library of components within our frontend JavaScript SDKs, available in Next.js, React, and Vanilla JS.



These SDK components interact directly with the Stytch API empowering your team to:

Enable self-serve workflows: Your customers can independently manage authentication and authorization settings, eliminating the burden on your support or engineering teams.

Add enterprise authN and authZ features on demand: Each Admin Portal component functions independently, so you can pick and choose what to integrate. Add new features like SSO, SCIM, and JIT provisioning as your business scales.

Customize for a native experience: All components support custom styling, ensuring the Admin Portal seamlessly matches your application’s unique UX and branding. If you're already using Stytch’s prebuilt login UI, you can reuse the same style object.

Strengthen security posture: All components enforce built-in RBAC policies, verifying that only authorized users have access to certain settings and perform sensitive actions.

Build headlessly: You can also leverage our headless SDK methods to customize and extend any Admin Portal functionality if you need more control.

Modular Components, Native Look and Feel

At the heart of our Admin Portal’s design are modular, embeddable UI components. These independent components give developers the freedom to build a native admin experience that seamlessly integrates into their applications. Whether you need to manage members, configure authentication policies, or set up SSO, each component is designed to function autonomously or as part of a cohesive frontend management system.

This modular approach ensures that regardless of your application’s frontend architecture the Admin Portal UI fits right in. No iframes, no externally hosted screens, no links or redirects—just your app, built the way you want it.



Essential Auth Features for Enterprise Applications

RBAC Awareness and Enforcement

Every component is fully RBAC-aware, enforcing authorization at the UI and API levels. This ensures that critical functions such as SSO configuration, deletions, or role assignments are accessible only to the users that should have access to them.

Organization Settings



The <AdminPortalOrgSettings> component gives your admin users control over their tenant-specific auth settings. This includes the ability to safely configure, update, and manage essential policies and features such as:

Authentication settings: Admin users can define and update allowed authentication methods (e.g., single-sign on, passwords, email magic links, OAuth, etc.)

Multi-Factor Authentication: Admins can configure MFA settings to enforce compliance and security standards.

JIT provisioning and invites: Admin users can manage invites and configure automatic JIT provisioning flows based on SSO credentials, email domains, and specified OAuth tenants like a specific Slack workspace or GitHub organization.

RBAC assignments: Admin users can manage role assignments manually or automate them based on email domains or SSO connections.

Member Management



The <AdminPortalMemberManagement> component grants admin users the ability to directly manage individual users and their memberships, including features such as:

Updating, inviting, or deactivating members.

Resetting passwords, MFA, or session tokens.

Assigning RBAC roles and permissions.

Single Sign-On (SSO)



The <AdminPortalSSO> component simplifies SSO configuration by supporting both SAML and OIDC-compliant identity providers like Microsoft Entra, Google Workspace, Okta, and more. Key features include:

SSO configuration: Admins can easily add, update, or remove SSO connections directly from the portal.

Support for External SSO Connections: Admins can configure shared SSO connections that can be used across multiple organizations, streamlining setup across identity providers.

Certificate rotation: Admins can ensure uninterrupted service and enhanced security by handling certificate updates through the portal.

SCIM Integration



The <AdminPortalSCIM> component streamlines role assignments with SCIM group mapping, automating updates to role assignment based on the identity provider’s groups and your SCIM Connection.

Getting Started

Visit out our SDK docs to get started with the Admin PortaI.

And to see it in action, watch our video to see how the Admin Portal streamlines organization and enterprise management.

Check back tomorrow for more Launch Week! And follow us on X for daily product announcements.

---


# Stytch User Impersonation: Fast, secure troubleshooting
Source: https://stytch.com/blog/stytch-user-impersonation/

Today, we’re excited to announce User Impersonation, allowing you to log in to your applications as a specific end user account to help you troubleshoot and debug securely. 

It's often challenging to reproduce complex customer issues, and sharing screenshots only gets you so far — now, with a click, you can securely log in as any user and directly interact with your application as them, giving your support teams a powerful tool for troubleshooting. User Impersonation also comes with granular access controls, including audit logs and a limited session length to ensure you can conduct investigations into bugs with secure safeguards. 


We’re excited to introduce User Impersonation, a feature that lets you log in to your application as a specific end user account to help you troubleshoot and debug securely.

It's often challenging to reproduce complex customer issues, and sharing screenshots only gets you so far — now, with a click, you can securely log in as any user and directly interact with your application as them, giving your support teams a powerful tool for troubleshooting. User Impersonation also comes with granular access controls, including audit logs and a limited session length to ensure you can conduct investigations into bugs with secure safeguards.

User Impersonation is configurable from within the Stytch dashboard, making it straightforward to implement. This feature is now available to all Stytch B2B and B2C customers on their existing plans.

The Fast, Secure Path to Pinpointing User Issues

When a user reaches out for help, they've most likely already exhausted the self-service resources available to them and hit the limits of their technical understanding. Support staff, in turn, have to attempt to try and communicate with these frustrated users and talk them through potentially complicated steps for diagnosing and resolving issues (“How do I take a screenshot?!”), hampered by miscommunication and slow, asynchronous responses.

While remote access tools go some way to help, this too requires the user to follow confusing instructions. Asking the user to share their credentials is out of the question in any context, meaning that users and support staff both have to be online and available.

Stytch’s User Impersonation eliminates these support bottlenecks and security concerns, by allowing you to log into your app directly as a user and troubleshoot issues in real-time with strong security and compliance controls.



Key benefits:

Faster support resolution: Log in as an end user with a single click to diagnose and resolve issues in real-time.

No credential sharing: Securely access user accounts without sharing or exposing login credentials.

Seamless experience: Perform actions exactly as the user would, ensuring an accurate troubleshooting and debugging process.

Security safeguards:

Audit logging: Every impersonated session is logged for compliance and security monitoring.

Enforced RBAC: Only authorized support managers can initiate impersonation based on auto-enforced RBAC policies.

Limited session duration: Impersonated sessions can be revoked and automatically expire after 60 minutes to reduce security risks.

Mandatory reason: Every impersonated session requires the support manager to write and submit a reason, ensuring transparency and accountability.

How Do You Implement User Impersonation with Stytch?

User Impersonation is available now to our Stytch B2B and B2C customers on their existing plans, and it can be enabled on a per-project basis by users with the admin role.

Navigate to Project details in the Stytch dashboard and toggle on Allow user impersonation. Once you've explicitly opted into this functionality, anyone with the support manager role can then select a user to impersonate.



The support manager is then prompted to provide a reason (and they must provide a reason for the audit log) and then clicks Launch in new tab to create the impersonated session.



This initiates the User Impersonation flow in a new browser tab at your project’s default login redirect URL with an impersonation token appended to the query parameters. Here’s an example:



Your application then takes the impersonation token from the redirect URL’s query params and authenticates it with Stytch using either the frontend SDK or backend API and SDKs. Here's what the authenticate request looks like:



Once your application has successfully authenticated the token, we return a full, impersonated Stytch session for the target user. Here's an example of a successful response from the User Impersonation API endpoint:



Every impersonated session is flagged by an impersonated authentication factor that includes the impersonator's email address and workspace ID, so you can display a banner to ensure the impersonator is aware of who they are logged in as, keep their purpose clear, and remind them to log out when they're done. This can also be used to redact information in impersonated sessions to protect users and comply with privacy regulations.

As impersonated sessions are easily identifiable, the client application can revoke access as it would a typical session. To assist with the implementation of secure user impersonation in your apps, impersonated sessions are limited to a duration of 60 minutes and cannot be exchanged between organizations.

We also provide audit logging so you can track who initiated any impersonated session: these event logs are kept by default for 30 days. Additionally, a webhook is emitted at the start of each session that can be used to notify users, or for your own internal notification and auditing purposes.



Getting Started

User Impersonation is available in your Stytch dashboard right now. Navigate to your Stytch settings under Project details and toggle on Allow user impersonation. Then it's just a single click from the user management or members page to start an impersonated session in your app. 

Visit our API docs for more details.

This feature is a part of Stytch Launch Week—see what else is new!



---


# Stytch Terraform: Now generally available
Source: https://stytch.com/blog/stytch-terraform/

Our Terraform Provider is now v1.0 and officially in GA. This launch makes it easy for teams to automate and scale their identity infrastructure with greater control and flexibility.

These features allow you to programmatically manage your Stytch projects via Hashicorp’s Terraform so you don’t have to manually rely on the Stytch Dashboard. You can create new projects, set project password configs, manage public tokens and secrets, or even update your RBAC policy.

Stytch Terraform Provider is now v1.0 and officially in GA. This launch makes it easy for teams to automate and scale their identity infrastructure with greater control and flexibility.

These features allow you to programmatically manage your Stytch projects via Hashicorp’s Terraform so you don’t have to manually rely on the Stytch Dashboard. You can create new projects, set project password configs, manage public tokens and secrets, or even update your RBAC policy.

Automating with Programmatic Workspace Actions

In the past, configuration tasks like creating a Redirect URL required logging into the dashboard and manually completing a series of steps. While this worked fine for new users running their initial setup, it quickly became a limitation for developers who manage multiple Stytch projects or perform bulk operations. We needed a way for Stytch developers to automate their workflows.

That’s why we released Programmatic Workspace Actions, our Management API, which is designed to programmatically control all aspects of a Stytch project. With this API, you can:

Create new Stytch auth projects

Configure SDK settings

Manage public tokens and secrets

Define RBAC policies

Set redirect URLs

Update email templates

And more

But in order to truly enable scalable infrastructure, we took it one step further.

Scaling with Stytch Terraform Provider

We’re proud to announce the v1 release of our official Terraform Provider. Built on top of Programmatic Workspace Actions, Stytch Terraform Provider enables you to provision, manage, and automate Stytch projects with declarative code.

Our Terraform Provider leverages the official Stytch Management Go SDK under the hood, acting as a bridge between Terraform’s configuration language (HCL) and Programmatic Workspace Actions. It translates your Terraform config files into the corresponding Stytch Management API calls.



Infrastructure-as-Code has become the gold standard for engineering teams to programmatically manage and scale their core infrastructure. With Stytch Terraform, you now have the power to control and orchestrate authentication systems at any scale.

How to Programmatically Manage Your Stytch Resources Using Terraform

You can get started with Terraform in just minutes, it’s available for anyone to use. Let’s dive in.

Creating Your Workspace Management Key

To create a new Workspace Management Key, log in to your Stytch dashboard, navigate to Workspace Settings > Management API, and click Add New to create a new Workspace Management Key.

Make sure to securely store the secret, as it won’t be visible again after this step. These keys have high-level access to your Stytch workspace, so treat them with care and only share them with those authorized to perform these privileged actions.



Calling the Management API

To interact with the Stytch Management API, you can use the Stytch Management Go SDK, the Stytch Terraform Provider, or any HTTP client of your choice, such as cURL or Postman or Insomnia. When making requests, you have to use HTTP Basic Authentication to authenticate your requests, using the Key ID as your user ID and the Secret as your password.

Here's an example cURL POST request to help you create a project and get started:



Setting Up Your Stytch Terraform Provider

The Stytch Terraform Provider can only communicate with our Management API using the Workspace Management Keys you copied earlier. So the first thing we need to do is to set the Key ID and Secret as our environment variables.

If you already have a working Terraform directory locally, create a variable.tf file in the root and paste the code block below to define your environment variables:



Next, create a terraform.tfvars file and store the values of your workspace_key_id and workspace_key_secret according to the key-value pairs specified below (ensure this file is added to .gitignore if you use version control):



Then, run the following command to initialize the Stytch provider:



Validate the configuration to check for errors:



Generate and review the execution plan:



Apply the configuration:



Managing Stytch Projects

Once you've initialized the Provider, you can start creating B2B and B2C projects within your Stytch workspace using Terraform’s HCL. You can create a stytch.tf file in your directory to contain all the config you’ll create to manage Stytch resources.

For example, if you want to create a new B2B project, your config might look like this:



Once the configuration is in place, you can run the terraform plan and terraform apply commands to create the project within your workspace. The Terraform provider will automatically make the necessary API calls to Stytch to set up the project, and you can verify that it was successfully created in your Stytch dashboard.

Managing SDK Config

With the stytch_consumer_sdk_config and stytch_b2b_sdk_config resources, you can manage SDK configurations for your B2B and B2C projects. These resources enable you to define basic authentication settings like sessions, cookies, time-based OTPs, and even our DFP-protected CAPTCHA.



Managing Roles and Permissions within Your RBAC Policies

The stytch_rbac_policy Terraform resource allows you to define and manage RBAC policies for your B2B project. By specifying a unique project_id, you can define custom_resources with associated actions (e.g., create, read, update, delete). You can also define custom_roles with specific permissions that link the resources and actions you created earlier to these roles.



Managing Redirect URLs

With the stytch_redirect_url resource, you can manage redirect URLs for both Consumer and B2B projects. You can assign multiple valid types to each URL, such as LOGIN, SIGNUP, INVITE, and DISCOVERY, and specify whether a type is the default for that URL. Redirect URLs define where users are sent after completing actions initiated by Stytch, allowing you to tailor login and signup UX.



Getting Started

There’s much more you can do with the Stytch Terraform Provider. Visit the official release on the Terraform Registry, where you’ll find detailed documentation to guide you through configuring and using each resource.

If you’re interested in using Programmatic Workspace Actions directly, you can check our docs or use the stytch-management-go library.

That wraps up Launch Week! Thank you for joining us and exploring all the exciting new features we’ve shared.



---


# Stytch Event Log Streaming: Send auth & risk insights to your observability tools
Source: https://stytch.com/blog/stytch-log-streaming/

Today, we're incredibly excited to announce Event Log Streaming which allows you to ingest Stytch authentication, authorization, and security events in your log management tooling, starting with Datadog but available for other vendors upon request. 

This is particularly helpful if you are already using tools or vendors for analysis, investigation, and retention of observability data. Previously Stytch logs were only available through the Stytch dashboard, but with Event Log Streaming, you can stream your Stytch event logs into other services. This allows you to easily correlate Stytch logs with other existing telemetry, and more easily monitor for anomalies. 

We’re excited to announce Event Log Streaming, a feature that allows you to ingest Stytch authentication, authorization, and security events into your log management tools. Support for Datadog and Grafana is available now at launch, and we’re exploring support for additional vendors.

This feature is particularly helpful if you are already using tools or vendors for analysis, investigation, and retention of observability data. Previously Stytch logs were only available through the Stytch dashboard, but with Event Log Streaming, you can stream your Stytch event logs into other services. This allows you to easily correlate Stytch logs with other existing telemetry, and more easily monitor for anomalies.

Event Log Streaming is in beta and free to use on all Stytch plans today—contact us to get access.

Why Use Event Log Streaming?

While we have put in a lot of effort to make the Stytch Dashboard as useful and informative as possible, one limitation it has is that it only hosts your Stytch related logs. Adding more tools creates more friction, requiring you to constantly context switch between your observability tooling and our Dashboard. Client side logging is a solution some teams use to observe a user’s authentication flow, but it also has some downsides and limitations. Instead, we make it easy to stream Stytch’s existing logs to your observability tools.

Event Log Streaming natively integrates Stytch logs into your observability stack, allowing you to use existing tools, unify insights, and customize analytics—while maintaining full control over log storage and retention.

Streaming Event Logs to Datadog

Datadog is a commonly used tool for companies to manage logs, metrics, traces, and other events in one central platform. Today, you can pipe event logs directly from Stytch into Datadog to associate with any other logs, traces, or events that live in your Datadog environment. This will make it easier not only to store, but to investigate any potential issues or suspicious activity from multiple vectors.



Streaming Event Logs to Grafana Loki

Grafana Loki is another popular tool used for observability and log collection, known for its greater focus on open-source, compatibility with Prometheus, and self-hosting capabilities. Our Grafana Loki integration is currently in beta, allowing you to pipe your event logs from Stytch into Loki and correlate them with other metrics, traces, and events in your Grafana ecosystem. 

Similar to Datadog, streaming your Stytch event logs into Loki helps you analyze errors and detect potential threats, offering a more comprehensive view of your application's activity. 

The Future of Event Log Streaming

This is only the beginning with our journey in streaming event logs out of Stytch. Here’s a quick look into our roadmap for the near future.

Self-Serve Capabilities

We expect to let you begin setting up the event log streaming integration without contacting us soon! We will let you configure your integration using the new Stytch Terraform Provider, our Programmatic Workspace Actions SDK, or directly in the Stytch dashboard.

Future Integrations

We’re working hard to enable even more destinations to stream your logs. Let us know what your favorite observability or monitoring tool is by contacting our team, and we will let you know once we have support! Prefer to pipe your logs to a storage provider? Let us know, and which ones you prefer.

Getting Started

Event Log Streaming is free on all Stytch pricing plans. To get started, reach out to our team to enroll in our beta.

Our goal is to make your experience on Stytch as frictionless as possible, and hope that this feature serves as a step forward by letting you have better control and flexibility in managing your authentication and authorization data.

Check out some of the other products we showed off this Launch Week!



---


# Connecting AI agents to every app
Source: https://stytch.com/blog/connecting-ai-agents-to-every-app/

In a world increasingly driven by AI, applications are no longer just tools—they’re becoming platforms. Platforms that empower users, other apps, and now AI agents to collaborate seamlessly in ways we’re only beginning to understand. 

At Stytch, we’ve been thinking deeply about what it means for an app to open itself up as an Identity Provider (IdP), enabling AI agents to act on behalf of users in a secure, permissioned, and programmatic way. This vision is embodied in our Connected Apps product, a powerful and easy way for any application to become its own IdP and unleash new possibilities, both agentic and non-agentic.

In a world increasingly driven by AI, applications are no longer just tools—they’re becoming platforms. Platforms that empower users, other apps, and now AI agents to collaborate seamlessly in ways we’re only beginning to understand. 

At Stytch, we’ve been thinking deeply about what it means for an app to open itself up as an Identity Provider (IdP), enabling AI agents to act on behalf of users in a secure, permissioned, and programmatic way. This vision is embodied in our Connected Apps product, a powerful and easy way for any application to become its own IdP and unleash new possibilities, both agentic and non-agentic.

Supabase’s integration approach: A blueprint for modern apps

A perfect real-world example of an agentic use case being powered by an app acting as its own IdP is Supabase and its approach to integrations with popular AI tools like Lovable. The way Supabase, a powerful open-source Firebase competitor, enables permissioned access for both agentic and non-agentic workflows demonstrates exactly the kind of capability we’re excited to help every company build.

Because Supabase acts as their own IdP, it enables developers to build powerful integrations on top of the Supabase platform. By doing so, apps like Lovable (a popular AI coding agent that makes it easy to quickly prototype and build full-stack applications) can programmatically connect, access, and interact with Supabase data on behalf of users via their AI agent. 



Supabase provides a simple and powerful framework for developers to build integrations. By using their OAuth2.0 supported authorization flow and management API, developers can:

Allow end users to authenticate their Supabase account securely & with proper consent.

Access user data via APIs.

Take programmatic actions, such as reading or writing data, with permissioned scopes (e.g. update the RLS policies on my project).

This functionality lays the groundwork for AI agents like Lovable’s to access Supabase resources on behalf of users. Here is an example of Lovable using these permissions to ask me to confirm changes to the RLS (row level security) policies on my Supabase project for an example app I’m building:




By simply “applying changes”, Lovable is able to move beyond being simply a generative coding agent (i.e. it generates code that I use elsewhere) and actually able to become a full interactive coding agent by taking those suggested, but reviewable, actions on my behalf in my Supabase project.

Moving beyond the Supabase example, imagine an AI agent that could:

Draft reports by querying project data in real-time.

Update tasks or sync workflows based on user commands.

Enhance user productivity by automating repetitive actions, all while ensuring security and control.

This is all made possible because Supabase can act as an IdP. The OAuth flow makes it developer-friendly, secure, and simple for any agentic or non-agentic app to leverage the full power of Supabase’s platform on behalf of their users. 

With Connected Apps, we’re taking this concept even further.

Stytch Connected Apps: Supercharging the IdP model for AI agents

Connected Apps is Stytch’s answer to the growing need for applications to become their own IdPs. It allows any app to:

Expose secure APIs for programmatic access.

Manage fine-grained permissions with read/write scopes for users and AI agents.

Authenticate seamlessly with OAuth2.0 and OpenID Connect (OIDC) standards.

Track and audit actions taken by AI agents, providing transparency and accountability.

For example, a company like Vercel could use Connected Apps to allow external apps like Lovable, Devin.ai, and Bolt.new to have users connect their Vercel accounts, so that these tools can fully manage deploys on the user’s behalf. 

With Connected Apps, any app—from CRMs to productivity tools—can achieve all this with best-in-class consent management and fine-grained scope/role authorization so that end users can feel secure in connecting AI agents to their other apps.



Connected Apps not only enhances your app’s utility but also positions it as an integral part of an AI-driven ecosystem. Companies adopting Connected Apps can seamlessly integrate with third-party platforms, empower AI agents, and ultimately provide greater value to their users.

The future of apps in 2025 and beyond

We believe that in 2025, it will be commonplace for apps to:

Act as IdPs: Every app will need to provide a way for users (and their AI agents) to securely authenticate and access data programmatically.

Support AI agents: AI will evolve beyond being reactive tools and become proactive collaborators. These agents will require robust permissioning and secure access to user data across multiple apps. Consent management is critical in this new world.

Enable seamless integrations: The app ecosystem will increasingly rely on interoperability, with APIs and integrations becoming table stakes for growth.

Connected Apps is our vision for making this future accessible to every company. Whether you’re building a niche productivity tool, a cutting-edge CRM, or an AI-powered analytics platform, we provide the infrastructure to make your app the foundation for the next generation of AI-driven workflows.

Why this matters

The AI revolution is here, but without the right infrastructure, its potential will remain unrealized. Apps that embrace their role as IdPs unlock unprecedented opportunities for innovation, growth, and user engagement. With Connected Apps, we’re making it easier than ever for companies to:

Enable secure, permissioned AI workflows.

Empower developers with simple integration capabilities.

Deliver better, faster, and more valuable experiences for their users.

It’s not just about keeping up with the future—it’s about leading the way. If Supabase’s approach inspires you, imagine what your app could achieve with the added power of Stytch’s Connected Apps.

Ready to turn your app into an identity provider?

Explore Connected Apps today and check out the getting started guide to discover how your app can become the foundation of AI-driven workflows. 

Let’s build the future together.






---


# How to create a closed source Objective-C++ framework for Swift Package Manager
Source: https://stytch.com/blog/creating-a-closed-source-framework-for-spm/

By default the SPM publishes your code open source, but there may be reasons why you would want to distribute your code in a closed source manner as well.
In this article, we’ll explain and show you how. 

The Swift Package Manager (SPM) is a simple dependency manager, and unlike its predecessors and alternatives like Cocapods, it’s integrated directly in Xcode. With it you can easily add dependencies to your app or own Swift Package.

Publishing your package definition and code to a public repository makes it accessible for other developers to include as dependencies in their projects. You can search for available Swift Packages via the Swift Package Index.

By default the SPM publishes your code open source, but there may be reasons why you would want to distribute your code in a closed source manner as well.

In this article, we’ll explain and show you how. And if you want the code, here's the GitHub repo.

Table of contents

Why we wanted a closed source package on SPM

TL;DR how it all works

GOTCHAS and lessons learned

The tutorial

Final thoughts

Why we needed a closed source package on SPM

For our purposes at Stytch, we wanted to make some proprietary commercial code for our Fraud & Risk Prevention product, an advanced device fingerprinting solution written in Objective-C++ / C++ / C, available on SPM. This approach would allow us to include it in our public, open source iOS SDK and enable our developer community to integrate it directly into their Swift projects as a separate dependency that was independent of the full Stytch iOS SDK.

By keeping the package closed source, we could protect our intellectual property while still allowing the developers to use it easily in their Swift applications.

TL;DR how it all works

Objective-C++

Objective-C++ is a programming language variant that allows you to mix C / C++ and Objective-C code within the same source file. Objective-C has the file extension .m whereas Objective-C++ has the file extension .mm.

XCFramework

An XCFramework is a package format introduced by Apple to simplify the distribution of binary libraries by bundling multiple versions of a library into a single framework. Created using Xcode, an XCFramework includes the necessary frameworks, libraries, and headers to build for multiple platforms such as iOS, macOS, visionOS, tvOS, watchOS, and DriverKit, including Simulator builds. These frameworks can be static or dynamic and include headers. 

XCFrameworks address the limitations of traditional frameworks by streamlining development across platforms.

High-level overview

To create a closed source Objective-C++ framework in SPM, we decided to use a XCFramework in a private repo written in Objective-C++. Once compiled, the XCFramework is completely available to Swift code through the interface defined by the Objective-C++ files and their corresponding public headers. We then added the XCFramework to a publicly available Swift package and added that package as a dependency of our Stytch iOS SDK.



GOTCHAs and lessons learned

The tutorial below will demonstrate that this is a relatively simple process, however it required some trial and error for us to figure out.

At first I created a static library file (.a), which I wasted a few hours trying to compile a universal binary for, only to then determine that you could only add a XCFramework to a Swift package. In my initial implementation of the static library, I had a bridging header for what I hoped would be a Swift file talking directly to the C++ code, which worked in that context. 

But when I realized I had to port this over to a XCFramework, I found that XCFramework files do not support bridging headers. I had to remove the Swift layer and make the framework only Objective-C, C++, and Objective-C++.

This was fine in the end since everything we could implement in Swift we could also achieve in Objective-C. The framework could have Swift files in it, but they would not be able to communicate with the Objective-C files and would simply provide a parallel set of functionality (there is a chance that you can fix this with a .moudlemap file but I did not investigate further).

The tutorial

If you'd like to follow the tutorial with the code side-by-side, check out the GitHub repo where we've uploaded all the files you'll need to create a closed source framework. 

Part 1: Commit to private repo A

In Xcode click File->New->Project and select Framework and click Next.



Add a name under the Product Name field and click Next. For this example I chose “StytchFoo.”



A new empty project should look like this:



Add the follow files based on your naming convention:



Implementation of StytchFooPrivate.hpp

This implementation demonstrates two functions; one that will return a String defined in C++ and another one that we will be able to call from Swift with a String parameter type that will modify that String in C++ and return a new one.



Implementation of StytchFooPrivate.cpp

Here is the implementation of those functions described above.



Implementation of StytchFooWrapper.h

This will be the publicly visible interface to Swift, I named the files StytchFooWrapper, but named the actual Objective-C object only StytchFoo because I could not have a StytchFoo.h file as that would have collided with the public header for the framework. Therefore StytchFoo will be the name of the object we refer to in Swift code. 

Here we will define a parallel interface as the StytchFooPrivate.hpp file.



Implementation of StytchFooWrapper.mm

Here in the implementation file we hold a private reference to the StytchFooPrivate C++ object. A standard Objective-C file will have the extension .m but notice that the file extension for this file is .mm, which makes it a Objective-C++ file where we can write both Objective-C and C++ in one file.



Next we need to make sure the right header files are public to the framework. 

Select the project file in the left hand menu called the project navigator. Make sure your framework target is selected under the TARGETS section, here its highlight with a yellow toolbox icon. Then from the top menu select Build Phases. 

Unfold the Headers section and you will see that the StytchFooWrapper.h is not under the Public section.



Drag the StytchFooWrapper.h file into the public section.



Delete the Copy Bundle Resources section by clicking the trash can icon on the right to prevent source files from being copied into the final XCFramework for distribution. Your build phases should only include the following sections.



Then open the StytchFoo.h header file and add  #import <StytchFoo/StytchFooWrapper.h> .



Now let's add a script that will build the framework for distribution.

Right click on the project file and select New Empty File.



Create a script called BuildXCFramework.sh, this will create a universal binary .XCFramework that can be run on device and simulator.



Implementation of BuildXCFramework.sh 

Adjust the values as needed for your naming scheme.



Navigate to your project directory and type the following commands in the terminal:



To modify permissions on the script to run it, you only need to run it once.



To run the script each time you want to build the framework, run this:



After you run the BuildXCFramework.sh script you can check your project directory and you should see a Product directory with the built .xcframework in it. We will need to copy it into the Swift package for step 2.



Part 2: Commit to public repo B

Create a public repo and navigate to the empty repo and type:



This will create a new Swift package named stytch-foo.

In my case I named the directory StytchFooPackage.

Copy your .xcframework file generated in the private repo in step 1 and copy it into the stytch-foo directory of your newly created package. It should look like this:



You can double click on the Package.swift file to open the package in Xcode.

Modify your Package.swift file to follow this example file given. We must add a .binaryTarget to the package for the .xcframework.



There must be an empty Swift file matching the package name, I could not figure out why.



Commit these changes to your public repo and your Swift package is live!

Part 3: Commit to repo C, your application repo

In Xcode click File->New->Project and select App and click Next.



Add a name under the Product Name field and click Next. For this example I chose “StytchFooDemo.”



The default project at creation should look like this:



In Xcode click File->New->Add Package Dependencies.

Once the window opens add the url to the repo to the top left of the below window and it will come up as an option to select. Select the package as seen below and click Add Package.



Click Add Package again.



Here is where we tie it all together!

Now we can add the import statement import StytchFoo and use our StytchFoo object defined in part 1 of the tutorial in StytchFooWrapper.h and StytchFooWrapper.mm.

If you look in the console in the attached image you will see the log statements that match the implementation of StytchFooPrivate.cpp from step 1. Therefore this demonstrates that this Swift code is calling into C++ code.



Final thoughts

Building a closed source Objective-C++ framework for Swift Package Manager provides a practical way to distribute proprietary functionality securely and efficiently. By leveraging XCFrameworks, we encapsulated our code in a robust, reusable package that integrates seamlessly into Swift projects while protecting our intellectual property. There are many potential approaches to solving this problem, and this article outlines just one path. 

If solving problems and reading topics like this interest you, check out our careers page.

Happy coding!





---


# Authentication bypass vulnerabilities in node-saml
Source: https://stytch.com/blog/authentication-bypass-in-node-saml/

Authentication bypass in node-saml vulnerability post mortem

Table of contents

Overview

Timeline

Problem

Remediation

Conclusion

Overview

TLDR;

Stytch customers are safe and not impacted

Stytch customers and end users were protected against these vulnerabilities prior to public disclosure

Stytch reviewed internal logs and has not identified any indicators of compromise; Stytch continues to monitor the situation

Stytch services did not experience any downtime nor degraded service

On March 4th, 2025, the Stytch team was made aware of an authentication bypass vulnerability in the node-saml library. The exploit is possible because of improper validation in the xml-crypto library, used by node-saml for verifying signatures. A missing validation check enabled a signature wrap attack to forge an SAML assertion to enable login as an arbitrary user. A second authentication bypass vulnerability was later identified, also in the xml-crypto library, that allowed for multiple SignedInfo nodes to be parsed for any SignatureValue block.

Timeline

All times in the postmortem are in PT.

3/4/25

9:43 PM - Security researcher contacts security@stytch.com with the reported vulnerability

9:58 PM - Initial triage of the issue occurs and the team starts work on verifying the report and reproducibility

3/5/25

3:05 AM - Legitimacy of vulnerability is confirmed; investigation to Stytch’s specific use case and other mitigating factors continued

7:59 AM - Confirmed reproducibility with node-saml v4.0.5, the version of the library running in production at Stytch

11:06 AM - The team identifies two viable options for patching (see remediation for more details)

11:47 AM - Additional logging is deployed to identify potential exploits and safety of deploying one of the patching options

12:56 PM - Decision is made on which patch to move forward with

2:08 PM - Patch is deployed to production; Stytch continues monitoring service activity

3/13/25

5:11 PM - We were made aware of an additional authentication bypass vulnerability with multiple SignedInfo nodes

7:58 PM - Patch to block any SAML requests with multiple SignedInfo nodes is deployed to production. In parallel we investigate to confirm that this vulnerability has not been exploited

Problem

The node-saml library relies on the xml-crypto library for XML signature verification in SAML responses. Due to improper cryptographic verification, comments can be arbitrarily contained in the XML payload used for SAML assertion.



In the node-saml library, the following process occurs:

The xml-crypto library is used to load the SignatureValue block into separate classes such as SignedInfo

The node-saml library verification process happens but does not correctly verify the SignatureValue block

This signature verification process starts with the signer verifying the SignedInfo block is properly signed, but during the process a canonicalized version is created where the comments are stripped from the SignedInfo block, allowing for an attacker to put arbitrary data in the comments that don’t impact the signature

The SignedInfo block contains a DigestValue block that the verifier uses to compute the digest of the SAML assertion. This is designed to prevent an attacker from modifying the assertion

However, the xml-crypto library wasn’t using the canonicalized version of the SignedInfo block when extracting the digest to compare the signature against and so could be influenced by the presence of comments

In the node-saml library, the firstChild method is called on nodes[0] to get the DigestValue

The DigestValue block is internally parsed as a sequence of nodes in the xml-crypto library meaning calling firstChild on the DigestValue block will return the comments, which can contain arbitrary data from an attacker

This arbitrary data then becomes the actual DigestValue that xml-crypto uses during verification. Since xml-crypto compares this attacker-provided DigestValue against the canonicalized digest of the modified (attacker-controlled) assertion, the verification incorrectly passes

In order for the attacker to create the right payload, they simply need a valid DigestValue and SignatureValue pair, this can be obtained from any XML document that has been signed by the IdP to create a properly signed XML payload to create a forged SAML assertion. The key pieces needed to create a SAML assertion for an arbitrary user are:

Service provider data: NameID, ACS, and EntityID

Username of the victim account

Consequently, the attacker successfully authenticates as any arbitrary user

Multiple SignedInfo nodes

The xml-crypto library allowed for multiple SignedInfo nodes to be passed within the SignatureValue block. This means that an attacker can pass an additional SignedInfo node containing arbitrary data.



The validation works by applying the SignatureValue to the DigestValue not the whole document. So an attacker can:

Take a valid XML payload and its SignatureValue and DigestValue and inject that into another, malicious payload

When the XML payload is parsed and verified, one parser pass validates that the malicious DigestValue matches the malicious payload and a second parser pass validates that the good DigestValue matches the SignatureValue

The malicious payload is then trusted because both verifications passed

Remediation

The comment wrapping attack works via smuggling comments in the SignedInfo node, so to patch this there are a couple options.

Strip all comments from the XML

Fail any request with comments in the XML



Both are viable solutions to prevent this attack. Stytch implemented the second option out of an abundance of caution. We verified that legitimate requests do not contain, and should never contain, comments. Therefore taking this approach was the most thorough remediation, would not impact real traffic, as well as protecting Stytch and Stytch users from this entire class of attacks.



The multiple SignedInfo nodes attack works because there is no validation on those nodes and their legitimacy. Since there is no legitimate reason for multiple SignedInfo nodes, a viable solution is to block any XML payloads that contain more than one SignedInfo per SignatureValue block. We implemented checks to ensure that exactly one SignedInfo node is present per SignatureValue block.

Conclusion

We engaged an independent third party to assist in completing an analysis to identify if this had been exploited on our systems and were able to conclude with a high degree of confidence that it has not. We’ve added additional monitoring and alerting to ensure any attempts at an exploit will be immediately identified (though the response will fail as the implemented changes are designed to do). In addition to updating to the patched version of xml-crypto, we’ve also introduced a number of hardening features to preventatively protect against variants of this attack.



As of 3/14/25, CVEs for both vulnerabilities, XML Signature Verification Bypass via DigestValue Comment and XML Signature Verification Bypass via Multiple SignedInfo References, and a patched version of xml-crypto have been released. We’d like to thank Alexander Tan for the responsible disclosure of these vulnerabilities.



If you have any questions or concerns regarding this vulnerability or Stytch's security practices, please do not hesitate to contact our security team at security[at]stytch[dot]com.




---


# Auth0 reviews: Why developers migrate from Auth0 to Stytch
Source: https://stytch.com/blog/auth0-reviews/

In this article, we’ve compiled some of the most common reasons why developers migrate from Auth0 to Stytch for authentication. We’ve collected and cited comments from blog posts, Reddit, Twitter, Hacker News, G2, StackOverflow, and Auth0’s community forum to bring you unfiltered opinions from actual Auth0 developers on why they made the switch—in their own words.

Across forums, blogs, and community threads, developers regularly share their experiences with authentication—what works, what breaks, and what drives them to switch solutions. One authentication provider that frequently comes up in these conversations? Auth0.

At Stytch, we’ve listened closely to developers migrating from Auth0, and we’ve noticed a set of recurring themes behind their decisions.

In this article, we’ve compiled some of the most common reasons why developers migrate from Auth0 to Stytch for authentication. We’ve collected and cited comments from blog posts, Reddit, Twitter, Hacker News, G2, StackOverflow, and Auth0’s community forum to bring you unfiltered opinions from actual Auth0 developers on why they made the switch—in their own words.



Let’s dive in.

Auth0 pricing: You shouldn’t have to pay a fortune for auth

What drives an engineer to be frustrated enough to write an entire article warning other devs away from a vendor? Not a quick angry tweet. Not a comment. But an entire article!

Michael Bruniaux’s story is unfortunately a common one. Their company’s Auth0 bill exploded by 15.54x (from $240/month to $3,729/month) despite modest user growth and no new feature usage. In his article he details how Auth0’s pricing felt like a scheme to trap their company into a costly enterprise plan.



Auth0 pricing has always been one of their most unpopular qualities as an auth provider. Every day we see online comments complaining about the same pain points: feature restrictions, unexpected caps, and hidden fees that force costly upgrades.



As you can see from the reviews above, one of the major frustrations many companies face once they’re locked in with Auth0 is the unpredictable price increases. It’s clear that their customers don’t want surprises or restrictions from their authentication provider that punishes growth with unreasonably high bills.

And despite their most recent pricing update to their free plan, Auth0’s pricing is still designed to feel like a classic bait-and-switch once applications outgrow the free plan’s limits.



Auth0 customer support: Can we get some help?

For many developers, effective customer support is just as critical as the product itself. Unfortunately, Auth0's customer support has often left developers feeling frustrated and unsupported with reports of unresponsiveness and unresolved issues piling up. Authentication is a critical part of infrastructure, and poor support from an auth provider can quickly become a dealbreaker.



Developers describe waiting multiple weeks for a reply only to receive a generic templated response that didn’t address their specific issue. Some even claim unresolved issues are being closed and then ignored for several months.

Unlike Auth0, Stytch offers direct support starting even with the free plan, available through our official developer Slack, forum, and email. Our commitment is to be your trusted authentication partner for the long haul.



Auth0 developer experience: Falling short where it matters most

The heart of a dev-focused tool is in the quality of development experience it provides, and this is what has been slowly declining with Auth0, especially since it was acquired by Okta.

Spending weeks building around deliberate restrictions and wrestling with an authentication platform that’s supposed to save you time is a losing battle. Wasting engineering hours to workarounds, manual processes, and support tickets isn’t just an inconvenience—its a direct hit to your team’s productivity and codebase quality.



We stumbled upon several developers and engineering teams voicing their concerns about the Auth0’s usability (both APIs and SDKs) and highlighted key sticking points with their Auth0 integrations.

Auth0’s uncustomizable Universal Login

Auth0’s Universal Login is their “out-of-the-box” login product that developers are compelled to use, whether it’s SAML, OIDC, Passwords, Passwordless, or even multi-tenant organization flows.

The problem? Auth0’s Universal Login is a one-size-fits-all approach that fits almost no one perfectly. The most enforced pain point with Auth0’s Universal Login is the mandatory redirect during authentication: your users will be redirected away from your app to an Auth0-hosted domain before they’re sent back to your app.

Universal login sacrifices user and developer experience by design since it effectively strips developers of any native in-app code control over the auth flow. Customization options are limited and restrictive, and the auth experience almost always feels separate from your app rather than part of it.



Take passwordless authentication, for example. You’d naturally expect Auth0’s Universal Login to support email magic links or OTP during signup or sign-in without requiring Auth0’s Actions/Rules, which are similar to lambdas or edge functions. With so many workarounds, implementing basic auth capabilities feels like building from scratch. 

But as Frederick points out, shouldn’t Universal Login handle everything?



Stytch takes a completely different integration approach with embedded authentication, keeping users entirely within your application’s domain. Unlike universal login, embedded authentication gives developers maximum control over the entire UX by keeping the auth code and logic natively within your app.

Learn more about the differences between Stytch Embedded Auth vs. Auth0 Universal Login.

Auth0’s multi-tenancy is tightly coupled with Universal Login

To manage multi-tenant auth in your B2B SaaS, you’re once again forced to use Auth0’s Universal Login.

Imagine building a multi-tenant SaaS app where new users can’t create accounts under their tenants because they signed up via an invitation link instead of directly through Universal Login. This is just one of the side effects of Auth0’s Universal Login controlling everything. Others include clunky multi-factor authentication policies, no switching between organizations, and a lack of flexibility where it matters most.

Auth0 users like Timon have run into this exact issue.



Stytch takes a fundamentally different multi-tenant approach by making organizations the foundation of our B2B data model. This org-first architecture makes it possible for your enterprise customers to be able to customize everything—member invitations, organization-specific auth factors, approved domains, SSO, JIT provisioning —without building temporary hooks or refactoring their auth systems.

Duplicate Auth0 users

Another major flaw in in Auth0's authentication is its handling of data duplication and user management.

When a user authenticates through OAuth (e.g. Google or Microsoft) and later logs in with email and password, Auth0 creates two separate user records, even if both accounts share the same email and belong to the same person. With Auth0, simply offering multiple options for login and signup creates significant problems for your app.

This data duplication forces engineering teams to write middleware or scripts to clean up to merge user accounts, and, in the worst cases, users may need to reset passwords or re-authenticate based on the auth method they initially used. The founder of Syften, a popular social monitoring tool, wrote a blog post detailing how Auth0 wasted two weeks of development due to user duplication before deciding to migrate.



With Stytch, user records are automatically deduplicated if they share an email address. If a user signs up with an email and password, and then later logs in through Google OAuth, we securely verify their identity and link the two accounts on your behalf. We ensure one unified account for every user, regardless of the authentication method they use at any time.

Searching for an Auth0 alternative

When developers feel compelled to publicly voice their frustrations, it’s usually a sign of widespread, prolonged issues with the tool they’re using. Posting on forums, blogs, and social media is an effective outlet to ensure feedback is taken seriously. But Auth0’s continued harsh pricing, unresponsive customer support, and restrictive developer experience has left developers looking for alternatives for authentication.

At Stytch, we’ve listened to these frustrations and built our platform to address them directly. Transparent pricing, flexible embedded authentication, and dedicated developer support are core to what we offer. Engineering teams at companies like Orb, Clearbit, and Mintlify, are picking Stytch over Auth0, so they can deliver a smoother auth experience for their developers and users.

If you’re ready to leave the headaches of Auth0 behind, we’re here to help every step of the way. Schedule a call with an auth expert or join our developer Slack community to see how Stytch can transform authentication for your team.



Citations

[1] https://www.reddit.com/r/nextjs/comments/1dfme38/another_auth_thread_running_away_from_auth0_but/

[2] https://medium.com/@michael_93843/draft-wip-ff4366a63658

[3] https://community.auth0.com/t/why-i-wont-use-auth0/48879

[4] https://www.g2.com/products/auth0-by-okta/reviews/auth0-by-okta-review-8975677

[5] https://twitter.com/theo/status/1652220166460276737

[6] https://www.reddit.com/r/webdev/comments/18d6hcd/auth0_increases_price_by_300/

[7] https://news.ycombinator.com/item?id=32320571

[8] https://x.com/AmitTaylor/status/1732530584524615995

[9] https://www.g2.com/products/auth0-by-okta/reviews/auth0-by-okta-review-8975677

[10] https://www.reddit.com/r/webdev/comments/wdqqq0/comment/iijwv45/

[11] https://community.auth0.com/t/why-is-auth0-support-so-bad/46861

[12] https://community.auth0.com/t/your-support-is-awful-non-existent/6363

[13] https://community.auth0.com/t/terrible-auth0-support/113015

[14] https://www.g2.com/products/auth0-by-okta/reviews/auth0-by-okta-review-9795599

[15] https://www.g2.com/products/auth0-by-okta/reviews/auth0-by-okta-review-5438992

[16] https://www.reddit.com/r/okta/comments/1cuso7d/why_has_auth0s_customer_support_gotten_so_bad/

[17] https://community.auth0.com/t/email-verification-as-part-of-new-universal-login-sign-up-process/76432/7

[18] https://blog.publiccomps.com/adding-stytch-to-our-login/

[19] https://community.auth0.com/t/new-universal-login-allow-sign-up-to-be-disabled-but-still-allow-invitation-acceptance/117899/5

[20] https://community.auth0.com/t/organizations-feature-missing-lots-of-functionalities/77504

[21] https://www.reddit.com/r/nextjs/comments/1eifqs8/implement_auth0_with_nextjs_14_without_universal/

[22] https://community.auth0.com/t/email-verification-as-part-of-new-universal-login-sign-up-process/76432

[23] https://www.reddit.com/r/reactjs/comments/12du21l/comment/k54a4vv/

[24] https://syften.com/blog/how_not_to_do_auth/

[25] https://www.reddit.com/r/reactjs/comments/12du21l/comment/jf8g4an/

[26] https://www.reddit.com/r/reactjs/comments/12du21l/comment/k5whr9s/

[27] https://community.auth0.com/t/account-duplicated-check/118260

---


# Multi-factor authentication solutions: Choosing the best MFA provider for your use case
Source: https://stytch.com/blog/mfa-solutions-and-providers/

Multi-factor authentication solutions protect your public and private applications from abuse by adding an extra layer of security to protect against account hijacking.

This guide explains the factors you should consider when choosing a multi-factor authentication provider, explaining the features you may need for your use case or specific project requirements, as well as future-proofing your authentication systems.

Multi-factor authentication solutions protect your public and private applications from abuse by adding an extra layer of security to protect against account hijacking.

This guide explains the factors you should consider when choosing a multi-factor authentication provider, explaining the features you may need for your use case or specific project requirements, as well as future-proofing your authentication systems.

What multi-factor authentication solutions protect against

Multi-factor authentication (MFA) is the requirement that users provide multiple methods of authentication to log in to a system, rather than just a username and password. It is most commonly encountered when a two-factor authentication app generates a one-time password and emails or texts it to you.

Multi-factor authentication providers add extra protection for both users’ accounts and the data in them, as well as your organization's internal tools and infrastructure. This includes protecting against attacks including phishing, enumeration attacks and social engineering, password spraying/brute forcing, and credential stuffing using credentials sourced from password leaks and data breaches.

MFA is an essential component for all modern applications, and its absence is often a sign of a poorly secured application that does not respect the importance of its users’ security and privacy and protecting them from fraudulent activity.

Types of multi-factor authentication

With MFA, the weaknesses in each authentication factor are mitigated by the additional layer of security provided by the other additional factors. Some factors are more secure than others, while some offer greater familiarity and convenience to users.

Knowledge factors: Usernames and passwords, PIN numbers, and security questions — these are all unique secrets that you can memorize to prove your identity. However, knowledge-based factors can be easily defeated if a password is leaked, disclosed, guessed, or brute-forced.

Possession factors: One-time password (OTP), time-based one-time passwords (TOTP) authenticator apps, SMS/email verification, and hardware tokens (such as smart cards or passkeys like Yubikeys) are based on something you own or have access to that others don't. Combining possession-based factors with a username and password is a popular way to provide users with a familiar MFA method; however, authentication codes provided by SMS and email can be intercepted, and there are sophisticated attacks that can defeat OTP and other possession-based methods.

Inheritance factors: Biometrics such as your fingerprint, face scan, or voice can be used in inheritance-based authentication. While these measures offer strong protection technologically, inheritance factors are also not infallible (and may be defeated by simply forcing the user to physically interact with a device while under duress). Inheritance factors based on physical characteristics also cannot be altered: if your biometric data is compromised, you cannot easily (or painlessly) change it.

Location, temporal, and behavioral factors: More common in enterprise authentication solutions, location- and temporal-based factors verify users by their location, the time they are trying to perform actions, and their behavior. Employees attempting to log in from an unexpected IP address or at an unusual hour and then trying to immediately access sensitive information that they do not usually interact with may end the user's session and force them to re-authenticate.

Passwordless authentication can also combine with MFA factors (some that are even transparent to the user) to entirely remove the need for inherently insecure usernames and passwords as part of the authentication process.

What to look for in an MFA provider



When choosing a multi-factor authentication provider for your application, you should first consider your use case. Do you require a simple login from a popular authentication provider (such as Google or Apple) for a public app, or are you building tools for enterprises that require features such as single sign on and integration with permissions-based access control? Answering this question will help you immediately narrow down your selection of MFA providers based on their advertised features.

From there, you can assess:

Your users’ needs: The harder your multi-factor authentication is to set up and use, the less effective it will be. Your MFA solution should support the MFA methods your users have ready access to with the devices they already use or that your organization supplies to them.

Developer features: Your MFA providers APIs/SDKs will need to be compatible with your existing platforms and technologies. Multi-factor authentication platforms should also be reputable, with helpful support resources and extensive documentation.

Multi-factor authentication technologies: Are the multiple authentication factors you require supported? External factors like company policy or privacy regulations might dictate this.

Future proofing: Support for standards such as WebAuthn and Passkeys and high customizability ensure that MFA solutions are flexible and able to adapt to evolving use cases and scaling deployments.

Scalability: A cloud-based multi-factor authentication provider takes care of all of the infrastructure for you, including the security of the platform and ensuring it can scale limitlessly as traffic increases.

Organization settings: In B2B SaaS applications, you may also require customizable MFA policies by organizations; for example, requiring certain employees or groups that have access to highly sensitive data to log in with MFA every time, while being less restrictive for users who do not have access to privileged resources and need quick access to basic functions. Without the flexibility to enforce MFA policies at both the team and individual user levels, multi-factor authentication can become a source of frustration and a security concern—potentially driving both users and admins to seek workarounds.

MFA provider for consumer and user-driven apps

When building consumer-facing applications, securing accounts without adding unnecessary friction is a delicate balance. Many apps default to letting users log in with just a username and password, which is fraught with security risks and threat vectors like account takeover. Even using OAuth to authenticate with social identity providers like Google, Facebook, or Apple has its drawbacks: users may not want to share data from those accounts, or may not have them at all, especially in regions where certain platforms aren't widely used.

To serve a diverse user base, consumer apps should support multiple sign-in methods—and make multi-factor authentication (MFA) a core part of their security posture. MFA isn't just a best practice; it's increasingly expected by users and often required by regulators. A missing or misconfigured second factor can become a liability in the event of a security breach.

Different use cases call for different approaches to MFA:

Social or media apps may want a lighter approach like email-based one-time passcodes.

International audiences benefit from other delivery methods like one-time passcodes using SMS or WhatsApp, since coverage for certain providers may vary by region.

Financial apps with high fraud risk may require strong device-bound factors like TOTP and authenticator apps or biometric second factors using protocols like WebAuthn or Passkeys.

Stytch offers a comprehensive set of developer-friendly APIs and SDKs that let you implement a variety of MFA strategies—from SMS and email passcodes to biometrics and WebAuthn—tailored to your app’s unique security and user experience needs.

MFA solutions for B2B SaaS applications 

In B2B applications, multi-tenancy presents challenges that can change MFA requirements significantly. Authentication needs to adapt not just to individual users but also to the policies of each organization you serve. Unlike consumer apps with a single login experience, B2B SaaS applications and platforms must support multi-tenant environments where each tenant can define and enforce its own security standards.

Multi-factor authentication (MFA) is a core requirement for many organizations, but enforcement often varies:

Some organizations may mandate MFA for all their members.

Certain organizations may even restrict which secondary auth factors—like TOTP, WebAuthn, or SMS—are considered acceptable.

Other organizations may allow members to opt in individually.

And for B2B SaaS applications especially, MFA is usually just the tip of the iceberg. 

Enterprise organizations will also require that these MFA policies be strictly governed by a robust permissions and authorization framework like role-based access control (RBAC). Combining multi-factor authentication with features like SSO and SCIM is becoming non-negotiable for enterprises that need full coverage and control of their authentication and authorization for compliance reasons.



Stytch makes it easy to support these varying requirements with per-tenant MFA configuration in addition to several customizable enterprise auth features. Stytch’s API-driven platform gives each organization control over:

MFA policies: Enforce that all members perform MFA in order to log into the Organization, and specify which MFA methods are allowed (e.g. TOTP only).

Approved auth methods: Allows an Organization to specify which primary auth method(s) their members can use to log in (e.g. SSO only, or either Google OAuth and Email Magic Link)

Just-in-Time (JIT) Provisioning: Optionally allow end users who meet the Organization's JIT Provisioning sources (email domain, SSO, or OAuth tenant) to automatically create an account without being explicitly added

Invites: Option to allow invites to any email domain, restrict to just Allowed Domains, or to disable entirely

SSO connections: Configure multiple SSO connections to have members authenticate via their workforce IdPs, with JIT Provisioning and automatic role assignment per-Connection.

RBAC assignment: Assign roles and permissions to members either directly or automatically, based on SCIM Group membership, SSO Connection, or email domain.

Custom metadata: Store application or business-specific attributes on the Organization object.

Is multi-factor authentication enough for security?

Multi-factor authentication is essential, but on its own, it’s not always enough.

And in addition to MFA as a security measure, Stytch also provides Fraud & Risk Prevention solutions like bot detection and device fingerprinting to help block malicious traffic and automated attempts to access user accounts. Intelligent monitoring can assess location- and time-based factors for anomalies, to further protect against malicious activity from unexpected sources.

Stytch combines these technologies to create an adaptive multi-factor authentication solution. This adaptive MFA solution uses AI technology to dynamically adjust its requirements based on the context of a login attempt by factoring the source, location, time, and other complex signals including user behavior. This allows trusted users and devices to log in frictionlessly, while users logging in under unusual circumstances will have to provide additional information to prove their identity.

Stytch can integrate with any app, and any enterprise system to provide a single, robust multi-factor authentication solution that spans multiple use cases and projects. 

Sign up to get started with MFA and other enterprise auth features.





---


# Authentication as a service: Launch faster with stronger security
Source: https://stytch.com/blog/authentication-as-a-service/

Authentication as a service (AaaS) is an authentication platform that you can build on, providing an evolving toolkit of industry-standard, best-practices security technologies that are developed, tested, and maintained by teams of authentication, security, and identity management experts.

Secure authentication is essential for any modern user-driven app or B2B SaaS tool. Authentication is difficult to build securely and quickly without putting user data and your infrastructure at risk; and when you start growing and have to factor scalability, the challenges of maintaining authentication developed in-house can become even more complex.

That's where authentication as a service (AaaS) comes in: it's an authentication platform that you can build on, providing an evolving toolkit of industry-standard, best-practices security technologies that are developed, tested, and maintained by teams of authentication, security, and identity management experts.

What is authentication as a service (AaaS)?

Authentication as a service provides identity-related technologies for your applications which includes a whole suite of features like user registration, login methods, session management, user management, authorizations, and more. Many AaaS platforms also provide additional management and security features such abuse and fraud prevention and bot detection to protect your applications and services, further reducing the development overheads required to fully secure your applications.

These solutions are cloud-based, providing highly available and secure login systems for many popular applications. Many AaaS solutions can also be integrated with an organization's identity and access management (IAM) systems like Microsoft Entra ID, Google Workspace, and Okta.

What are the benefits of authentication as a service?

Authentication as a service greatly reduces the development time and effort it takes to implement user registration and login functionality in your applications by providing strong security technologies that are designed, coded, and maintained by experts.

When choosing an AaaS provider, it is important that you assess whether it includes features that benefit both your development team, your business, and your end-users.

A better developer experience

AaaS platforms equip your engineering teams with a comprehensive set of tools to accelerate their development of auth and identity features. With APIs, SDKs, and pre-built UI components, developers can implement best-practices authentication with just a few lines of code.



This allows you to focus on building the bespoke functionality of your apps, rather than trying to solve sensitive security issues.

Support for a wide variety of auth methods

AaaS platforms integrate with popular identity providers (such as Google, Apple, and Microsoft ), and provide a wide variety of auth methods for login like passwords, magic links, and OAuth — in addition to multi-factor authentication options like using one-time passwords (OTPs), authenticator apps, and biometrics like WebAuthn/passkeys.

This ensures that your users have a convenient, familiar login experience that discourages poor security practices like password sharing and weak passwords, without adding friction to your signup and login flows.

Enterprise features

Enterprise-grade authentication as a service also provide developers with tools and features such as:

Multi-tenancy, enabling you to securely build SaaS platforms or add authentication to B2B applications with isolated org-level access and configuration.

Single sign-on (SSO) for seamless authentication across different services and internal business tools

System for cross-domain identity management (SCIM) for maintaining identity and access information.

Role-based access control (RBAC) for applying identity and access information to secure data and resources.

Machine-to-machine (M2M) authentication, to enable secure service-to-service communication without human involvement.



Other essential features such as support for protocols like SAML, OIDC, and JIT provisioning are also often included in enterprise AaaS plans. Enterprise-ready authentication will also have a proven history of security and disclosure, along with additional developer support and  service level agreements (SLAs).

Compliance and regulations

Authentication as a service helps you stay compliant with data privacy regulations such as GDPR, CCPA, and HIPAA, as well as more stringent certifications like ISO 27001 and SOC2 for highly sensitive user and financial data.

AaaS platforms that comply with these standards and regulations are critical in enterprise environments, as they are incredibly difficult to implement without dedicated security professionals.

Scalable infrastructure and availability

The reduced infrastructure requirements of AaaS results in lower costs and higher scalability of your applications. When unexpected growth happens, your application won't fall over due to an influx of user registrations or run up your cloud hosting bills

Fraud and risk prevention

Improved security reduces the risk of your apps exposing users to fraudulent activity, maintaining and enhancing your business's reputation for respecting the safety and privacy of your users.

AaaS platforms should provide fraud and risk prevention solutions to detect bots, prevent abuse, and defend against emerging threats—including AI-driven fraud, helping secure your users with new technologies at zero development costs.

How does authentication as a service help developers?

Secure user authentication can no longer rely on basic username and password pairs, and it is becoming increasingly complex to implement security measures that provide adequate security.

Authentication as a service provides an evolving set of developer tools for building scalable, complex identity systems for their products. With AaaS, you can add sophisticated authentication and security protection to your applications without additional development burden to your projects.

The APIs and SDKs provided by AaaS platforms include everything you need to interact with their authentication services, handling everything from front- and back-end implementation to embeddable admin portals, all while following programming and security best practices. 



For example, Stytch AaaS integrates with any software project using comprehensive SDKs, as well as directly through APIs and industry standard protocols OAUTH and SAML, immediately adding strong authentication and protection to any app or service.

Case study: Smooth user authentication and app protection with AaaS

AaaS is a proven force multiplier for development teams, increasing efficiency and providing better outcomes.

ClearBit, recently acquired by HubSpot, is a leading B2B AI provider who needed an authentication layer that would provide granular control of enterprise B2B authentication, self-serve onboarding for their growing user-base, and built-in device fingerprinting to combat account and trial abuse. They also required enterprise features like RBAC that would ensure their chosen solution was future-proof as their needs evolved.



Stytch met (and surpassed) every requirement, reducing the overheads of supporting complex in-house authentication systems and enabling a passwordless self-service onboarding process for their users.

Stytch’s multi-tenant architecture provided Clearbit with the infrastructure to easily build and manage key enterprise auth features such as SAML authentication, integration with OAuth providers, and auto-provisioning. Enabling different auth requirements and settings for different customers was simply an API call away via the Stytch platform.

Adding best-in-class authentication to your app



Authentication as a service makes building secure applications easier by abstracting the complexity and dangers of implementing authentication away from your developers, so that they can focus on creating functionality and content for your users.

Adding Stytch authentication and fraud prevention to your app is a straightforward process:

Sign up with Stytch.

Configure your identity providers, including popular social login providers like Google and Microsoft, or use your own in-house identity providers like Microsoft Entra ID, Google Workspace, and Okta.

Add Stytch to your app using our SDK and pre-built UI, or build your own with our headless implementation. Depending on your architecture, you can also implement Stytch using our backend SDKs.



4. Leave the complicated stuff to us and get on with building the rest of your application.

Full, working code examples and Stytch demos are available to help get you up and running quickly, and our thorough documentation is regularly updated as we add new features.

Authentication is hard. Leave it to the experts.

Along with being an ongoing security and privacy responsibility, designing and implementing authentications solutions is a significant undertaking for development teams of any size, distracting you from building your core value for your users.

Integrating Stytch into your consumer and B2B applications gives you immediate access to industry standard multi-factor authentication and compliance functionality, enterprise features such as RBAC and SCIM, as well as innovative technologies such as AI protection and intelligent bot detection.

This can all be achieved using our APIs and SDKs, significantly reducing development time, code complexity, and placing the responsibility for the security and maintenance of your login systems with Stytch cybersecurity experts. Contact Stytch to find out more, or get started yourself now for free.





---


# Model Context Protocol (MCP): A comprehensive introduction for developers 
Source: https://stytch.com/blog/model-context-protocol-introduction/

Model Context Protocol (MCP) is an open standard that bridges AI models with external data and services, allowing Large Language Models (LLMs) to make structured API calls in a consistent, secure way. This post will introduce MCP, explain why it’s valuable for connecting AI systems, compare it to existing approaches like ChatGPT plugins and manual API integrations, and dive into its recent support for OAuth-based authentication. We’ll also explore a bit of code to see MCP in action.

Executive summary

Model Context Protocol (MCP) is an open standard that bridges AI models with external data and services, allowing Large Language Models (LLMs) to make structured API calls in a consistent, secure way. This post will introduce MCP, explain why it’s valuable for connecting AI systems, compare it to existing approaches like ChatGPT plugins and manual API integrations, and dive into its recent support for OAuth-based authentication. We’ll also explore a bit of code to see MCP in action.

MCP acts as a universal adapter between AI tools and external services, eliminating the need for custom integration code for each tool or API. Much like USB-C simplifies connectivity across diverse devices, MCP provides a uniform method for AI models to invoke external functions, retrieve data, or use predefined prompts. At its core, MCP offers one interface that connects to many different systems.

What is Model Context Protocol MCP?

MCP is essentially a universal adapter between AI applications and external tools or data sources. It defines a common protocol (built on JSON-RPC 2.0) that lets an AI assistant invoke functions, fetch data, or use predefined prompts from external services in a structured manner. Instead of every LLM app needing custom code for each API or database, MCP provides one standardized “language” for all interactions. 

The MCP layer enables AI applications to securely access and interact with external data sources and tools. It serves as a bridge between large language models (LLMs) and various databases, applications, or APIs, facilitating seamless integration and functionality without the need for extensive custom coding.

MCP uses a client-server architecture to achieve this. The AI-powered application (e.g. a chatbot, IDE assistant, or agent) acts as the host and runs an MCP client component, while each external integration runs as an MCP server. The server exposes capabilities (like functions, data resources, or prompt templates) over the MCP protocol, and the client connects to it to utilize those capabilities. This separation means the AI model doesn’t talk to APIs directly; instead, it goes through the MCP client/server handshake, which structures the exchange.



Source

Why MCP is Valuable

In traditional setups, connecting an AI model to external data or actions was tedious and ad-hoc. Developers often had to write one-off integrations for each API or database they wanted the model to use, dealing with different auth, data formats, and error handling for each. MCP changes the game by standardizing these interactions. Key benefits include:

Rapid Tool Integration: With MCP, you can plug in new capabilities without custom-coding each from scratch. If an MCP server exists for, say, Google Drive or a SQL database, any MCP-compatible AI app can connect to it and immediately gain that ability. This is a huge win for automation—AI agents can fetch documents, query databases, or call APIs as needed, just by adding the appropriate server. It’s like having a library of ready-made “plugins” that all speak the same language. MCP servers serve as lightweight programs that expose specific capabilities through a standardized protocol, acting as intermediaries between the Cursor and various external tools or data sources.

Autonomous Agents: MCP empowers more autonomous AI behavior. Agents are not limited to their built-in knowledge; they can actively retrieve information or perform actions in multi-step workflows. For example, a sophisticated agent might use MCP to gather data from a CRM, then send an email via a communications tool, then log a record in a database – all in one seamless chain. By enabling fluid, context-aware, multi-step interactions, MCP helps AI agents move closer to true autonomous task execution. As one observer noted, MCP turns an AI from an isolated “brain” into a versatile “doer” by giving it standardized access to real-world tools and data.

Reduced Friction and Setup: Because MCP acts as a universal interface, developers avoid the fragmentation of maintaining separate integrations. Once an application supports MCP, it can connect to any number of services through a single mechanism . This dramatically reduces the manual setup required each time you want your AI to use a new API. Teams can focus on higher-level logic rather than reinventing connection code for the 10th time. As Anthropic put it, MCP replaces fragmented integrations with a simpler, more reliable single protocol for data access.

Consistency and Interoperability: MCP enforces a consistent request/response format across tools. This means your AI app doesn’t have to handle one HTTP response for Service A, another XML for Service B, etc. The model’s outputs (function calls) and the tool results are all passed in a uniform JSON structure. That consistency makes it easier to debug and scale. It also future-proofs your integration logic – even if you switch underlying model vendors, MCP’s interface to the tools remains the same.

Two-Way Context: Unlike simple API calls, MCP supports maintaining context and ongoing dialogue between the model and the tool. An MCP server can provide Prompts (predefined prompt templates for certain tasks) and Resources (data context like documents) in addition to tools. This means the AI can not only “call an API” but also ingest reference data or follow complex workflows guided by the server. The protocol was designed to support rich interactions, not just one-off queries. This is especially useful in applications like coding assistants (where an AI might iterate with a development environment via MCP) or complex decision-making tasks that require back-and-forth with various data sources.

In short, MCP brings a scalable, plug-and-play approach to enhancing LLMs. It lets AI systems securely tap into the “live” data and actions they need, without each developer having to reinvent the wheel. Early adopters of MCP have already built servers for tools like Google Drive, Slack, GitHub, databases, and more – showcasing how AI agents can use MCP to work with enterprise content repositories, dev ops tools, and other real-world systems.


The MCP architecture – How it works at-a-glance

Client-Server structure

MCP follows a clear client-server architecture:

MCP Client: Embedded in AI applications (chatbots, IDE assistants, automation agents).

MCP Server: Exposes external capabilities such as functions (tools), resources (data), and prompts (templates).

All interactions occur through standardized JSON-RPC messages, maintaining a secure, structured exchange:

Example JSON-RPC Request:

For example, to list available tools, an MCP client sends a request like this:



The server would reply with a structured JSON listing the tools (each with a name, description, and input schema). For instance, a server might advertise a get_weather tool and describe what inputs it needs.



Later, when the LLM decides to use a tool, the client invokes a call to do so. The MCP server executes the function and returns the result in a structured JSON response. The MCP client (within the host app) can then feed that result back into the model’s context or response. In practice, the host application mediates this process: it translates the LLM’s intent (often via the model’s function call output) into an MCP request, and then passes the server’s structured result back to the LLM . This two-way exchange is secure and controlled – the model can only call the specific tools the server exposes, and all data passing in/out goes through the defined protocol.

Building and deploying MCP servers

Building and deploying MCP servers is a crucial step in leveraging the Model Context Protocol (MCP) for AI integrations. MCP servers act as intermediaries between AI models and external data sources or tools, enabling seamless communication and data exchange. One of the standout features of MCP is its flexibility in server development. Developers can use any programming language that can print to stdout or serve an HTTP endpoint, allowing them to choose their preferred language and technology stack.

When building an MCP server, it’s essential to consider the architecture and design. MCP follows a client-server architecture, where a host application can connect to multiple servers. This architecture enables scalability and flexibility, allowing developers to design MCP servers that handle various tasks and functions, such as data processing, tool integration, or AI model management.

Deploying MCP servers can be done in various environments, including local development environments, cloud platforms, or on-premises infrastructure. For instance, Cloudflare provides a robust platform for building and deploying remote MCP servers, making it easier to manage and scale MCP deployments. This flexibility ensures that MCP servers can be tailored to meet the specific needs of different applications and environments, whether it’s a local setup for development or a cloud-based solution for production.

By focusing on a well-designed architecture and leveraging the flexibility of MCP, developers can create powerful and scalable MCP servers that enhance the capabilities of AI models, enabling them to interact seamlessly with external data sources and tools.

MCP clients and tools

MCP clients and tools are essential components of the Model Context Protocol ecosystem. MCP clients are applications that connect to MCP servers to access external data sources or tools. These clients can be built using various programming languages and frameworks, such as Python, JavaScript, or Java, providing developers with the flexibility to choose the best tools for their specific needs.

MCP tools, on the other hand, are software components that provide specific capabilities or functions to MCP clients. These tools can be integrated with MCP servers to enable features such as data processing, AI model management, or tool integration. Examples of MCP tools include Claude Desktop, which provides a chat interface for interacting with AI models, and Cursor, which offers a plugin system for extending AI capabilities.

Developers can build custom MCP clients and tools to meet specific use cases or requirements. This flexibility allows for innovation and experimentation in the MCP ecosystem, enabling developers to create new and exciting applications. Whether it’s a specialized tool for data analysis or a client application that integrates with multiple MCP servers, the possibilities are vast.

By leveraging MCP clients and tools, developers can create robust and versatile applications that harness the full potential of AI models, enabling them to interact with a wide range of external data sources and tools seamlessly.

Comparing MCP to other approaches



Let’s compare a few approaches that existed before or alongside MCP:

Custom Integrations & API Key Management: The most common traditional approach was to write custom code for each service and supply the LLM with credentials (API keys or tokens) to use those integrations. For example, you might write a Python function to query an API, give the LLM the ability to call that function, and manually handle the API key in your backend. This approach is labor-intensive and doesn’t scale – each new data source requires new code, and each environment must securely manage API keys. It often led to brittle systems, since every integration was unique. By contrast, MCP centralizes and standardizes these interactions: the AI agent just needs to handle the MCP protocol, and any MCP server (for any service) will work in a plug-and-play way. New servers can be added without changing the client’s code at all. Moreover, MCP provides a formal structure for authentication (discussed later) so that handing API keys to the AI isn’t done ad-hoc but through a secure protocol.

ChatGPT Plugins (OpenAI Plugins): In 2023, OpenAI introduced a plugins system for ChatGPT that allowed models to call external APIs defined by an OpenAPI spec. This was an early step toward standardized tool use, but it has limitations. Each plugin is essentially its own mini-integration (with its own API schema and authentication), and they need to be built/hosted individually. Only certain platforms (like ChatGPT or Bing Chat) can use those plugins, since it was a proprietary approach. Plugins also were mostly one-shot calls – the model would call an API and get info, without a persistent connection or ongoing exchange. MCP differs in that it’s open and universal (not tied to one provider or interface) and it supports rich two-way interactions and continuous context. Think of ChatGPT plugins as specialized tools in a closed toolbox, whereas MCP is an open-standard toolkit that any developer or AI platform can utilize. MCP’s standardized auth (especially OAuth) also means it can handle secure access to user data in a more uniform way than the plugin-by-plugin OAuth flows in ChatGPT’s system. In summary, ChatGPT plugins showed the value of standardizing API access for LLMs, but MCP takes it further by making it an open protocol and by enabling a persistent “conversation” between AI and services.

LLM Tool Frameworks (LangChain, Agentic libraries): Before MCP, many developers used frameworks like LangChain to give models tools. In these setups, you define a set of tool functions (with descriptions) and the agent’s prompting logic so the LLM can decide to use them. This works, but each tool still requires custom implementation behind the scenes – LangChain ended up with hundreds of tool integrations maintained in its library. Essentially, LangChain provided a developer-facing standard (a Python class interface) for integrating tools into an agent’s codebase, but nothing for the model to dynamically discover new tools at runtime. MCP is complementary to these frameworks, shifting the standardization to be model-facing. With MCP, an agent can discover and use any tool that an MCP server provides, even if the agent’s code didn’t explicitly include that tool ahead of time. In fact, LangChain has added support so it can treat MCP servers as just another tool source – meaning an agent built with LangChain can call MCP tools easily, leveraging the growing ecosystem of MCP servers. The difference is that MCP formalizes the interface over a protocol (JSON-RPC, with metadata, etc.), making it easier to plug into different environments, not just Python frameworks. Similarly, OpenAI’s native function calling feature can be seen as handling the formatting of a function call (the model outputs a JSON function call), whereas MCP handles the execution of that call in a standardized way . OpenAI’s function calling and MCP often work in tandem: the LLM produces a structured call, and the MCP client/server execute it and return the result, which together enables seamless tool use.

In essence, MCP isn’t the first attempt to connect LLMs with external APIs – but it learns from those past approaches (plugins, tool libraries, etc.) and unifies the solution. It provides an open, model-agnostic protocol that simplifies integration and authentication. Particularly around security and auth, MCP’s design (with OAuth support) avoids the patchwork of per-plugin keys or giving raw API keys to the model. Instead, authentication can be handled in a consistent, standardized flow as part of the protocol – a major step up from the status quo.

MCP in action: technical deep dive

Let’s walk through a typical MCP interaction step-by-step to solidify how it works, and look at a bit of code. Imagine we have an AI assistant that wants to use an MCP server providing a set of tools (say, for a hypothetical “Neon” database service). The high-level flow is:

1. Connect to the MCP Server – The host application (AI assistant) initializes an MCP client and establishes a connection to the server. Depending on the server location, this could be via a local process (stdio) or a remote HTTP stream (SSE). Under the hood, the client sends an initialize message to handshake protocol versions and capabilities.

2. Discover Available Tools/Resources – The client then queries what the server offers. As shown earlier, it might send {"method": "tools/list"} and get back a list of tool definitions. The assistant can use this to inform the LLM (for example, by including the tool list in a system prompt or via the model’s function schema, depending on implementation). For instance, using an SDK, this could be one line of code like:



which returns a structured list of tools. Each tool entry has a name, description, and JSON schema for inputs, so the AI knows what it can do.

3. LLM Chooses a Tool – When a user asks the AI something that requires external action, the LLM determines (often via prompt engineering or function calling capabilities) that a certain tool should be used. For example, user asks: “What’s the latest price of AAPL stock?” The LLM sees it should call get_current_stock_price(company="AAPL", format="USD"). The host application captures this intent (e.g., OpenAI’s function calling API would return a function name and arguments in JSON).

4. Invoke the Tool via MCP – The client now sends a tools/call request to the server with the chosen tool name and parameters. We saw an example JSON for this earlier. In code, using an SDK, it might look like:



This will cause the server to execute the tool’s handler on its side. The server might be calling an external API, performing a database query, or whatever logic that tool encapsulates. The result (could be a simple value or a complex JSON object) is sent back in a result field of the MCP response.

5. Return the Result to the LLM – The MCP client receives the tool’s output. Now the host application can integrate that back into the AI’s response. In many agent setups, the pattern is to inject the result into the conversation and ask the model to continue. For example, the assistant might then present: “The current stock price of AAPL is $173.22 (USD).” If using an automated loop, the result can be given to the model (perhaps appended to the conversation as a system message like “Result of get_current_stock_price: ...”) and the model can continue answering the user’s query with that information in mind.

Here’s a simplified illustration of calling a tool and using the result in a conversation using Anthropic’s Claude (which natively supports tool use):



In reality, frameworks handle a lot of this for you, but the above pseudo-code sketches how MCP fits into the loop. The key point is that MCP provides the standardized call/response layer for tool execution, which the AI agent code can hook into. Whether you’re using OpenAI, Anthropic, or another LLM, MCP stays the same – it’s the glue between the model’s intents and the external actions.

By using MCP, developers get a clear, structured pipeline for extending AI capabilities. The code becomes more maintainable (since you’re calling a generic mcpClient.request rather than service-specific code in each place) and the AI becomes more powerful (since it can tap into any MCP-connected service). Debugging is also easier – you can monitor the JSON-RPC messages to see exactly what was requested and returned, rather than parsing model-generated text for clues.

Early limitations (no built-in authentication)

When MCP first emerged (late 2024), it offered the core protocol for tool and data exchange, but it lacked a standardized authentication mechanism for connecting to remote servers. In practice, early MCP demos and implementations often required running the MCP server locally or in a trusted environment, where authentication wasn’t a big concern (since the AI and server ran on the same machine). For example, developers could run an MCP server for Google Drive on their localhost with a pre-obtained token, then point their AI app to it. But using MCP over the internet or with third-party services was tricky without a formal auth flow.

Many initial MCP servers assumed the user would manually provide credentials or API keys to the server at startup. As an example, Anthropic’s quickstart suggested running pre-built servers by supplying your own credentials (API keys, tokens) via config or command-line. That means the server itself had access to your keys and the MCP client just trusted that server. While this works for personal or single-user scenarios, it doesn’t scale well for multi-user applications or cloud-hosted agents. There was no standard handshake for an AI agent to say, “Hey, I’m allowed to access this service on behalf of User X; here are my credentials.”

Essentially, early MCP clients had no way to authenticate to an MCP server except by out-of-band means (like pre-sharing a token or running without auth). This was a notable limitation – MCP was designed to be open and internet-based, but without an auth standard, secure remote use was handicapped.

The lack of authentication standard meant that MCP clients couldn’t safely connect to arbitrary servers on their own. You either hard-coded a client ID/API key into the client (which is not ideal in distributed apps), or you had to run without auth and assume only authorized users could even reach the server (often by keeping it local). Clearly, for MCP to reach its full potential (e.g. connecting an AI agent to a cloud-hosted data source in a secure way), a better approach was needed. The good news is that the community recognized this, and work was done to bake OAuth-based authentication into MCP.

OAuth 2.0 authentication flow

To address the initial authentication limitations and enhance secure connectivity, MCP adopted OAuth 2.0, a widely-recognized and robust authentication standard. OAuth 2.0 provides a secure, scalable framework enabling MCP clients to interact safely with remote servers, cloud-hosted resources, and multi-user environments. The key components and benefits of integrating OAuth 2.0 into MCP include:

Dynamic Client Registration (DCR): Model Context Protocol supports Dynamic Client Registration, allowing clients to register automatically with OAuth servers. This removes the need for manual client setup or hard-coded credentials, significantly streamlining deployment for developers.

Automatic Endpoint Discovery: MCP utilizes standardized metadata URLs (following OAuth's discovery protocol) to allow clients to automatically discover OAuth endpoints. This reduces configuration overhead and makes MCP deployments easier and more flexible.

Secure Authorization and Token Management: Clients securely obtain OAuth tokens tailored precisely to user permissions and access scopes. This ensures that clients access only the resources explicitly permitted by the user, improving security and compliance, especially in multi-user and cloud environments.

Scalable and Secure Multi-User Support: OAuth 2.0's design inherently supports multiple concurrent users and services, addressing one of MCP's significant early limitations. Applications can now seamlessly handle authorization flows for numerous users simultaneously, critical for widespread cloud adoption.

Debugging and troubleshooting

Debugging and troubleshooting are critical aspects of working with MCP servers and clients. MCP provides various tools and techniques for debugging and troubleshooting, ensuring that developers can identify and resolve issues efficiently. One of the key tools in this process is the MCP Inspector, an interactive debugging tool for MCP servers.

The MCP Inspector allows developers to test and inspect MCP servers, identifying and resolving issues with MCP server integrations. This tool provides a detailed view of the interactions between MCP clients and servers, making it easier to pinpoint problems and understand the underlying causes. Additionally, MCP provides a comprehensive debugging guide that outlines common issues and solutions, helping developers to troubleshoot and resolve problems quickly.

When debugging MCP servers, it’s essential to consider the architecture and design of the system. Developers should identify the specific components or modules that are causing issues and use tools like the MCP Inspector to diagnose and resolve problems. By focusing on a systematic approach to debugging and leveraging the available tools, developers can ensure that their MCP integrations are robust and reliable.

Real-world applications of MCP

The Model Context Protocol (MCP) has various real-world applications across industries and domains. One of the primary use cases for MCP is in AI integrations, where MCP enables seamless communication and data exchange between AI models and external data sources or tools.

MCP can be used in various applications, such as:

Building AI-powered chatbots: These chatbots can access external data sources or tools, providing users with accurate and up-to-date information.

Creating AI-driven workflows: MCP enables the integration of AI models with external systems or data sources, automating complex workflows and improving efficiency.

Developing AI models: These models can interact with external tools or data sources, enhancing their capabilities and providing more accurate and relevant outputs.

Enabling AI-powered automation: In industries such as finance, healthcare, or manufacturing, MCP can automate tasks and processes, improving productivity and reducing errors.

MCP’s flexibility and adaptability make it an attractive solution for developers and organizations looking to leverage AI and machine learning in their applications. By providing a standardized interface for AI models to interact with data sources and tools, MCP enables innovation and experimentation in the AI ecosystem. This standardized approach not only simplifies the integration process but also ensures that AI models can access the data and tools they need to perform at their best.

In summary, MCP opens up a world of possibilities for AI applications, allowing developers to create more integrated, autonomous, and scalable solutions. Whether it’s enhancing customer service with AI-powered chatbots or automating complex workflows in industrial settings, MCP provides the tools and framework needed to bring these innovations to life.

Conclusion

Model Context Protocol (MCP) is an exciting development in AI development because it allows developers to safely and efficiently connect our increasingly intelligent language models to the extensive world of software and data previously difficult to connect with. By introducing a common protocol, MCP lets us build AI systems that are more integrated, autonomous, and easier to scale. Instead of writing one-off plugins or giving the model brittle instructions for each new tool, we have a coherent framework where AI agents can discover and use tools on the fly, with proper oversight and security.

While the protocol is still evolving (authentication was a recent addition, and more features like standardized server discovery are on the horizon, it’s clear that MCP or something like it will play a key role in the next generation of AI applications. For developers, now is a great time to familiarize yourself with MCP concepts. Whether you’re enhancing a chatbot with company-specific knowledge or building an AI agent that automates workflows, MCP can save you time and headaches by handling the “plumbing” of tool integration. And since it’s an open standard backed by a growing community (and companies like Anthropic), it’s likely to become a foundational piece of AI infrastructure moving forward.

In summary, Model Context Protocol enables a world where AI assistants are not siloed geniuses but well-equipped engineers and assistants – able to interface with many systems, follow procedures, and fetch or create information as needed, all through a unified, secure interface. That’s a powerful vision, and one that is quickly becoming reality with MCP.

At Stytch, we’re focused on easily solving the remote MCP server auth problem for customers, so they can easily stand up MCP servers for their applications to allow end users to provide permissioned access to MCP clients.





---


# A developer’s guide to RFC 7519, part 1: JWT structure and claims
Source: https://stytch.com/blog/rfc-7519-jwt-part-1/

This article series will cover everything you need to know about JWTs—from the foundational principles in RFC 7519 to example implementations in Node.js. In this first entry, we’ll break down what JWTs are, when to use them, and their data structure.

JSON Web Tokens (JWTs), defined by RFC 7519, are a compact and URL-safe way to transmit claims securely between parties. They’ve become the backbone of stateless authentication in modern applications—especially in web apps, mobile clients, and microservices architecture.

If you're building authentication and authorization in-house, it’s essential to understand how JWT implementations need to be built according to spec for security and compliance.

This article series will cover everything you need to know about JWTs as defined in RFC 7519, from the foundational principles to example implementations in Node.js. In this first entry, we’ll break down what JWTs are, when to use them, and their data structure.

Let’s dive in.

First, how do you pronounce JWT?

So is it “J-W-T”? According to the RFC 7519 spec, it’s pronounced “jot”.



What is a JWT

A JWT is a compact, URL-safe way of representing claims and transporting them securely between two parties. In essence, it's a JSON object that is encoded and digitally signed, allowing you to verify that the claims within it haven't been altered after issuance.



By encoding identity information and permissions directly within the token itself, JWTs allow systems to make authentication and authorization decisions.

Advantages of JWTs

JWTs offer several significant technical advantages for developers building systems:

Statelessness: Unlike session-based authentication, JWTs don't require server-side storage of session information, reducing database lookups and improving scalability.

Cross-domain and cross-service: JWTs can be issued by one service and verified by another, making them ideal for microservices architectures.

Compact: Their encoded format allows them to be sent through URLs, POST parameters, or HTTP headers efficiently.

Self-contained: All necessary information is contained within the token itself, reducing the need for additional database queries.

These benefits and advantages will become clearer as we dive deeper into the series and explore more JWT concepts in RFC 7519.

What are JWTs used for in authentication and authorization

Major platforms and services including Google and countless enterprise applications rely on JWTs as their token format of choice.

Their popularity stems from their versatility and efficiency. They eliminate the need for server-side session storage, reduce database lookups, and facilitate cross-domain authentication, making them ideal for scalable, distributed architectures where traditional session-based authentication would be impractical. They are widely used in various authentication scenarios like:

Session management for web applications

Single sign-on (SSO)

API authorization frameworks like OAuth 2.0

Machine-to-Machine (M2M) authentication

Let’s walk through a few use cases.

Session management for applications

JWTs enable fully stateless session management by eliminating the need for server-side session storage. Simply, JWTs are great for staying logged in to an app.

In web and mobile applications, the client can store the JWT—typically in an HttpOnly cookie or secure localStorage—and include it with each request to authenticate the user (e.g., bearer token). This removes the need for the server to look up session data in a database on every request. As long as the token is valid and properly signed, the server can verify it and trust the claims it contains, allowing the user to remain authenticated without a traditional session store.



Social login and single sign-on with OAuth and OIDC

JWTs are an ideal standard for representing access tokens in OAuth 2.0 and identity tokens in OpenID Connect (OIDC). When a client authenticates, the server issues a JWT containing the client's identity and permissions, which can then be used to authorize access for protected resources across multiple applications.

This enables powerful authentication flows such as social login (e.g., login via Google, Facebook, or Apple) and SSO to create secure, seamless access across multiple applications and domains using a verifiable token.



Delegated authorization across backend services and machine-to-machine authentication

Just like the previous use case, OAuth and JWTs are leveraged to secure autonomous interactions in M2M integrations, such as APIs, backend services, servers, background processes, or command line interfaces (CLIs) that don’t require human users. 



JWTs facilitate secure, convenient communication between machines to verify identity and permissions across multiple services.

The JWT structure

The JWT specification defines three distinct parts separated by periods in a JWT structure:



The JWT header contains metadata about the token, including the token type and the encryption algorithm used. The token type helps parsers or downstream systems identify the token format.



The payload contains the claims which are statements about an entity which are called claims (we’ll cover this in the next section).



The signature used to verify the token hasn't been altered or modified:



Each section is Base64URL encoded and concatenated with periods to form the complete JWT.



The JWT payload and claims

The payload section of a JWT contains its claims—pieces of information asserted about the token, the user, or the application. These claims typically fall into two primary categories: registered claims and custom claims.

Registered claims

RFC 7519 defines several predefined claims, which are not mandatory but are used to standardize meanings across systems to ensure consistency. These JWT claims are effectively reserved.

iss — Issuer of the token (e.g., https://your-auth.company.com)

sub — Subject of the token (e.g., a user ID)

aud — Audience the token is intended for (e.g., https://your-api.company.com)

exp — Expiration time (Unix timestamp)

nbf — Not valid before (Unix timestamp)

iat — Issued at time (Unix timestamp)

jti — JWT ID (unique identifier for the token)

Custom claims

These are user-defined claims that can be shared across systems. Because they are user-defined, these JWT claims can be customized to whatever your application’s context requires.



Custom claims will fall into two additional categories:

Public custom claims are designed to be shared across systems. To avoid naming conflicts, a public claim should be either registered with IANA or namespaced, typically using a URI as a prefix.

Private custom claims are intended for use only between parties that have an agreed-upon understanding of their meaning. Since these JWT claims aren't shared outside those systems, namespacing isn’t required.

JWT signatures and algorithms

The token signature is what makes a JWT trustworthy. It ensures the integrity of the token by signing the header and payload using the cryptographic algorithm specified in the JWT header. This prevents tampering—if any part of the token is altered, the signature check will fail.

The JWT spec supports multiple signing algorithms:

HMAC algorithms (HS256, HS384, HS512): Symmetric key algorithms that use the same secret key for signing and verification.

RSA algorithms (RS256, RS384, RS512): Asymmetric algorithms that use a private key for signing and a public key for verification.

ECDSA algorithms (ES256, ES384, ES512): Similar to RSA but using elliptic curve cryptography, offering the same security with smaller key sizes.

In order to create a JWT signature, the high level steps are to:

Encode the header and payload using Base64URL

Concatenate them with a dot: header.payload

Sign the string with a secret or private key using the algorithm specified by the header's alg 

Note: RFC 7519 also defines alg: none which disables signing entirely. This was included for unsecured JWTs, but should never be accepted in production. Always enforce cryptographic algorithm validation and signature verification when verifying tokens.

How to create and sign a JWT with Node.js

Now that we’ve covered the structure and components of a JWT, let’s put it all together. This code example shows how to create a JWT manually using Node.js and the built-in crypto module according to RFC 7519.

To construct a valid JWT, we’ll follow these steps:

Define the header and payload

Encode the header and payload using base64

Create a signature by cryptographically signing both parts with a secret and the header’s alg

Concatenate the header, payload, and signature separated by periods



For real-world use, you can use a standard library like jsonwebtoken, which abstracts all of this logic and makes it even easier to code.



If you want to decode the JWT to see the payload and verify the signature, you can use tools like token.dev and jwt.io to validate the JWT you created.



Conclusion

JWTs are built on a powerful, yet simple structure. Understanding the components defined in RFC 7519—header, payload, and signature—gives you the foundation to build secure, scalable auth flows powered by JWTs.

In the next entry, we’ll learn more about decoding JWTs and validating and verifying their claims.

​Ready to implement JWTs for sessions, single sign-on, or M2M? Sign up for a free Stytch developer account or visit our quickstart guides to start building secure, scalable authentication for your application. 





---


# AI agent security explained
Source: https://stytch.com/blog/ai-agent-security-explained/

Best practices for integrating AI agents into your project and securing against malicious agents

AI agent security explained

How to authenticate, authorize, and defend autonomous systems

AI agents are quickly becoming the new team members in our software stacks – they schedule meetings, answer support tickets, write code, and even make product recommendations. But as we hand more responsibilities to these AI-driven agents, we also open the door to new security risks, particularly around data privacy. How do we protect our applications from malicious or compromised AI agents, and how do we safely integrate AI agents within our systems?

Traditional security models assumed a human behind each action. With AI agents, that assumption breaks down quickly. 

For example, an agent might log in to your app at 3 AM, transfer funds, or change critical settings, all without direct human oversight. If done right (with proper controls), this can be incredibly powerful. If done wrong (say, by giving an agent unfettered access or sharing your password with it), the results could be disastrous. Imagine a poorly governed agent inadvertently deleting important data or an attacker hijacking an agent, potentially leading to data breaches or system disruption.

In this article, we’ll look at best practices for securing AI agents and user interactions, covering everything from authenticating agents, to authorizing them with least privilege, to defending your systems from both malicious bots and well-intentioned agents gone rogue.

Understanding the security challenges of agents

Before diving into solutions, it’s important to understand why AI agents change the security equation. In the past, “bots” were often simple scripts or scrapers with limited capabilities. They could have valid use cases but were typically seen as a security vulnerability. 

Today’s AI agents – powered by large language models and advanced automation – are far more sophisticated. They can mimic human interactions on websites, interpret complex instructions, and even make decisions based on context. Businesses are also doing a lot of experimentation with AI assistants—often employing multiple agents simultaneously— that autonomously log into dashboards, pull detailed reports, and carry out tasks without direct user oversight.

This all sounds futuristic and convenient, but it introduces unique risks:

Identity and authentication: Is a given request coming from a human user or is an AI agent acting on their behalf? If your system can’t tell, it may apply the wrong policies. An agent might legitimately log in for a user, but so might a malicious bot. You need reliable ways to identify which authorized party is behind a request.

Over-privileged access: If an agent logs in as you with full access, it can do anything you can do. That might include actions like deleting sensitive data, making purchases, or changing configurations. Since AI agents are software, they might execute actions much faster (or more often) than a human would, potentially amplifying damage from mistakes or malicious instructions. We need granular permissioning. If an agent only needs read access to a calendar, it shouldn’t get edit permissions elsewhere.

Lack of human judgment: Humans can (usually) spot when something looks wrong and stop what they're doing. An AI agent, on the other hand, will diligently carry out whatever task it’s given, even if the situation changes or if it misunderstands the goal. Without safeguards, an agent could, for instance, relentlessly retry an action that is failing.

Lack of accountability and auditing: When an agent acts, how do we trace what happened? If something goes wrong, we need logs and trails tied to the agent’s identity to audit its actions.

New attack vectors: Attackers can target AI agents directly – for example, by feeding them malicious data or prompts that cause them to misbehave and introduce new security risks (often called prompt injection or agent hijacking). If an attacker can manipulate an agent that has access to your system, they might trick it into leaking sensitive data or performing unauthorized actions. This means your defense strategy should extend to monitoring and validating agent behavior in ways it might not for a trusted human user.

Bottom line, it's important to treat AI agents as first-class entities in our security architecture. The good news is we don’t have to reinvent the wheel completely – we can extend tried-and-true concepts used for securing a human user’s account – like authentication, proper permissioning, and active monitoring.

Authenticating AI agents: giving them a secure identity

Authentication is about verifying identity: Who (or what) is this actor, and how can they prove it? 

In the context of AI agents, we actually have two identities to consider: the end-user (who ultimately owns the account/data), and the agent (a third-party application acting with the user’s permission). We need to ensure the agent can prove it’s authorized by the user without the user handing over their primary credentials.

API keys and tokens

The simplest form of agent authentication is an API key or static token, where the agent presents a secret on each request to identify itself. 

While easy to implement, static keys are risky. If the key leaks, anyone could act as the agent. They also don’t convey which user (if any) the agent is acting for, and are hard to granularly scope or revoke without affecting every instance of the agent.

Standard OAuth for delegation

A more robust approach is delegation through OAuth 2.0 and OIDC (OpenID Connect). OAuth was practically built for this scenario of third-party access. Instead of giving an agent your username and password, you can implement role based access control and have the agent go through an OAuth flow to get an access token for your account. 

That token represents delegated authority – it says “the user Alice has allowed Agent X to act on her behalf, within certain bounds.” The agent presents the token when calling your API, and your system can verify it and grant limited access. To execute this flow, your app needs to become an OAuth provider – essentially letting the AI agent “log in” to your service on behalf of the user.



In the image above, the user invokes an AI agent to perform a task—in this case, summarizing a document. To do this, the agent must access the user’s data in your app, so it initiates an OAuth flow requesting read-only access (documents.read). The user is redirected to approve this request, granting the agent a scoped access token. 

This illustrates the core of OAuth for agents: user-initiated actions, explicit consent, and limited, revocable permissions. The agent never sees the user’s credentials—only the token. If the token or agent is compromised, access can be revoked without requiring a password reset.

To summarize, if you're familiar with the typical “Login with Google/Facebook” OAuth flow then you'll notice the underlying  mechanics are very similar for AI agents. You have:

Secure user consent: OAuth requires the user to approve access via a consent screen. Instead of giving the agent a password, users see a clear list of requested permissions and decide whether to grant access.

Token-based credentials: Once approved, the agent receives a scoped access token — not a password. If compromised, the token can be revoked without affecting the user’s main credentials.

Granular access & revocation: OAuth tokens can be limited to specific scopes and revoked at any time. This allows for fine-grained control over what the agent can access, with support for refresh tokens when needed.

No passwords on autopilot: OAuth keeps user credentials out of the agent’s hands. Even if the agent is compromised, the damage is limited to a single token that can expire or be revoked.

Implementing OAuth for AI agents

So how do you actually implement this? If you have engineering resources, you could build an OAuth 2.0/OIDC layer for your product from scratch – but that’s non-trivial. The OAuth standard has a lot of detail (authorization code flows, redirect URIs, token refresh, PKCE, etc.), and doing it wrong can create security holes. Instead, you can leverage existing identity providers or libraries, or use services that abstract the heavy lifting.

One such service is Stytch’s Connected Apps, which is purpose-built to turn any application into an OAuth provider with minimal effort. Connected Apps handles all the OIDC flow details for you (authorization endpoints, token exchange, validation, etc.) and lets you define, in a dashboard, what scopes and permissions are available. By using a solution like this, you don’t have to become an OAuth expert overnight – you configure a few settings and, under the hood, the steps remain standard.

Authorizing AI agents: permissions and access control

This is where we apply the principle of least privilege: give the agent the minimum access necessary for its function, no more. 




This is all about defining permissions to enforce precise access controls for what an agent can do and preventing potential security violations.

Designing permission scopes for agents

A good first step is to audit your application’s functionality and categorize what an agent might do into buckets of permissions. Some categories might be:

Read-only data access: e.g. read profile info, read transaction history, fetch a list of files.

Standard write actions: e.g. post a comment, create an event, send a message (actions that are reversible or low-impact).

Sensitive actions: e.g. transfer money, delete data, change password, manage other users. These might be things you never want an agent doing autonomously without user oversight, or only specific trusted agents with additional checks.

Admin/privileged operations: likely off-limits to any agent acting as a user because these might include changing roles, accessing someone else’s data, etc.

With these in mind, you can define OAuth scopes or permissions. Using Stytch Connected Apps (or a similar solution), you can configure scopes for each connected application. For instance, Connected Apps lets you create scopes like transaction:read or transaction:transfer and tie them to what endpoints they allow.

Scope example: Let’s say you run a banking API, and you enable AI financial advisor agents. You might offer scopes: accounts.read, transactions.read, transactions.transfer, profile.write (for updating user profile). A budgeting agent might ask for accounts.read and transactions.read to analyze spending. It would not request transactions.transfer because it’s not meant to move money. If somehow it did, the user should see that and likely deny it. Even if granted, your API would later enforce that an agent with no transactions.transfer scope cannot perform a transfer.

Human-in-the-loop for sensitive actions

Even with well-scoped permissions, some agent actions — like transferring funds, sending emails, or modifying customer data — are too sensitive to happen without human review. Human-in-the-loop (HITL) controls provide a final layer of oversight when automation alone isn’t enough.



The challenge is doing this without overloading users. Interrupting them for every low-risk task isn’t scalable — especially as agents begin to chain together multiple steps across workflows. HITL needs to be flexible, context-aware, and designed for both usability and safety.

A modern approach to HITL might include:

Push-based approvals: When an agent attempts a high-risk action, trigger a user prompt (via email or in-app) to confirm before proceeding.

Workflow batching: Rather than prompting for every action individually, batch approvals so users can review and approve a sequence of agent steps in one place.

Tiered scope design: Assign elevated scopes that require explicit, per-action approval, while allowing routine operations to flow uninterrupted.

These patterns allow agents to operate autonomously most of the time, while still inserting a user when it matters. Platforms like Stytch Connected Apps support these workflows through API-triggered consent and push-based approval patterns — making it easier to add HITL controls without reinventing your auth stack.

The point is, autonomy doesn’t mean unchecked power. You can decide that some things an agent attempts must loop the user or another person back in. Many systems already do this for humans (eg. via 2FA code).

Don’t forget to educate the user and provide controls

When users start delegating to AI agents, they may not fully understand what powers they're giving away. A crucial part of authorization in this context is the user experience around consent and control:

Clear consent screens: As mentioned earlier, show clear descriptions for each scope the agent requests. Use plain language. Instead of “Scope: read_calendar”, say “Read your calendar events”. If possible, let the user choose scopes (maybe the agent can request optional ones and the user could grant some but not others).



Dashboard of connected agents: Provide users a settings page where they can see all 3rd-party agents/apps that are connected to their account. From there, allow them to revoke access easily. This is analogous to how you can see “Apps with access to your Google account” in Google’s security settings. If the user stops using an agent, they should disconnect it to clean up. If they suspect something fishy, they should be able to remove the tokens immediately.

Scoped down data access: In some cases, you might also want to limit data exposure. For example, maybe an agent is given a reports.generate scope. When it calls, you still might want to filter or sanitize the data it can retrieve (e.g. maybe only the last 3 months of data, not all history). This is more of an application logic consideration, but worth mentioning as part of authorization: not all data needs to be available to agents, even if they have a broad read scope. Consider segmenting or redacting sensitive fields if the agent truly doesn’t need them.

Audit trails: Make it visible to users (and admins) what actions agents have taken. “Your TwitterBotAgent posted 3 tweets on your behalf this week.” In logs, mark actions with an “via [AgentName]” tag. This transparency builds trust that, yes, the agent is doing what it was allowed to do and nothing more. If something appears that the user didn’t expect, they can investigate or revoke quickly.

By thoughtfully implementing authorization, we greatly reduce the risk of an AI agent causing havoc. But authorization alone isn’t the end – even within allowed actions, things can go wrong or be abused. That’s where defense and monitoring come into play, which we’ll tackle next.

Defending against rogue or malicious agent behavior

The job doesn’t end once an agent is authenticated and authorized. An agent might malfunction (bugs in its code or unexpected AI decisions), or an attacker might find a way to exploit it. Defending your systems means continuously validating that agent behavior stays within expected bounds — and catching issues quickly when it doesn’t.

Here’s how to build strong guardrails and real-time defenses that keep automation in check without breaking useful flows.

Know the difference: humans vs. agents

Start by making sure your system can distinguish between AI agents and human users. Tokens can carry a client ID or a flag to indicate the request origin. But you can also look at request-level signals like user-agent strings, IP ranges, or device fingerprints to classify traffic more accurately.

This matters because agents and humans behave very differently. An agent reading 1,000 messages in a second might be normal — the same behavior from a human user would be a red flag. Agents often run from cloud environments and exhibit consistent markers, while humans tend to use residential IPs and more varied browsers. These distinctions let you apply smarter risk scoring, tuning rate limits and policies based on context.

Monitor behavior, not just volume

You need to watch not just how much traffic an agent sends, but what it’s doing. If an agent suddenly accesses endpoints it never used before or behaves out of character — even if it stays within scope — that’s worth investigating.

Build behavioral baselines per agent. What data does it typically access? How often? In what patterns? Anomaly detection can be simple heuristics (“500 reads today when it usually does 5”) or more sophisticated ML models that learn usage norms over time and alert security teams proactively.

Rate limiting

Traditional rate limiting often applies the same static thresholds across the board — for example, allowing X requests per minute per token. But AI agents don’t behave like humans. They operate faster, often in bursts, and patterns can vary widely by task.

That’s where intelligent rate limiting and real time monitoring come in. Instead of looking only at volume, it examines the context of traffic: historical patterns, behavioral anomalies, device signals, and session-level information. If an agent normally makes 10 requests per minute and suddenly spikes to 100, intelligent rate limiting can spot the deviation and throttle or challenge the traffic accordingly.



This allows you to block abuse — or halt runaway agents — without breaking legitimate usage. Some providers, like Stytch, offer Intelligent Rate Limiting out of the box with support for behavioral baselines and dynamic thresholds.

Device fingerprinting

If the agent is interacting through a UI — for example, as a browser-based copilot or script — device fingerprinting (with tools like Stytch device fingerprinting) can catch abnormal access. Signals like IP, OS, and browser type help flag when a token is being reused from a suspicious environment.

Advanced fingerprinting methods like from Stytch can now leverage supervised machine learning models trained on global datasets to detect and assess new or suspicious device types. For example, when an unfamiliar browser identifies itself as Chrome, these ML models can automatically evaluate it against all known Chrome versions to determine its validity and risk potential.

If the fingerprint suddenly changes or demonstrates other suspicious behavior, you can prompt for additional verification or block the session entirely. 



In server-to-server contexts, where device fingerprinting isn't applicable, you can continue to use infrastructure-level signals like cloud provider metadata, IP allowlists, and environment attestation.

Log everything — and use it

You can’t defend what you can’t see. Log every agent request with as much detail as possible — the token used, the endpoint called, the IP, the fingerprint, the associated user or client ID. Distinguish between human and agent activity at the logging layer so you can easily trace incidents.

Set up alerts for:

Access to high-risk or rarely used endpoints

Sudden spikes in request rate

Requests coming from a new or unexpected fingerprint

Repeated token failures or malformed requests

These signals — especially when combined — help surface issues before they turn into broader incidents.

Build a layered response model

When issues arise, you want overlapping security measures and defenses. If a token is compromised and used from a new environment, fingerprinting might catch it. If that fails, behavioral detection flags the anomaly. If the usage spikes, rate limiting slows things down. Logs and alerts help you confirm and respond quickly — ideally by revoking access before any real damage occurs.

This same layered approach works for unintentional issues too. If an agent enters an infinite loop after a bad update, your monitoring stack can catch the spike and shut things down until it’s resolved.

Best Practices and Future Considerations

AI agent security is still evolving — but the fundamentals hold. By applying proven patterns from human identity management and adapting them to the agent context, you can stay ahead of both misuse and emerging threats. 

Here's a summarized set of principles to guide your strategy:

1. Don’t hard-code secrets

Agents should never store long-lived passwords or API keys in code or config. Use a secure secrets manager to prevent data leakage and rotate credentials regularly. Better yet, rely on OAuth flows to issue scoped, short-lived tokens on demand.

2. Use established OAuth and OIDC standards

These protocols are mature, widely supported, and well-understood. They allow you to delegate access safely and revoke it cleanly. Rather than inventing custom schemes, lean on open standards. Tools like Stytch’s Connected Apps can make implementing these flows significantly easier, especially if you're enabling user-granted agent access across many clients.

3. Monitor continuously

Treat AI agents as persistent service actors, not set-it-and-forget-it integrations. Log their actions, monitor behavioral baselines, and apply real-time anomaly detection. If you already operate a SOC or security monitoring stack, fold agent activity into it.

4. Build in emergency off-switches

Design your systems so that you can revoke access instantly. This might include an admin dashboard to revoke agent tokens, an automated response to detected anomalies, or a manual API endpoint that allows users or operators to cut access when things feel off.

5. Plan for threat evolution

Prompt injection and token theft are just the beginning. As agent capabilities grow, new risks will emerge —including malicious inputs, model manipulation, impersonation, and abuse of delegated authority. Keep up with security research and threat intelligence. Treat your agent security model as a living document, not a one-time setup. As AI systems become increasingly interconnected, securing the interactions between multiple autonomous agents will become even more critical.

6. Help users stay informed and in control

Give users visibility into their authorized AI agents and let them easily revoke access. Be clear about what an agent can do — both at consent time and in account settings. Offer guidance on best practices, like avoiding password sharing or limiting agent scope.

Conclusion

The rise of autonomous agents brings a mix of excitement and security concerns. As developers and engineers, our job is to harness the benefits of these agents without compromising on safety. The good news is we’re not starting from scratch – we can borrow many of the same concepts that secure human-to-app interactions and apply them to AI agent interactions. By authenticating agents with strong, delegated credentials (and features like Connected Apps for easy OAuth setup and management), authorizing them with careful scopes and limits, and vigilantly monitoring their behavior, with optionality for human intervention, we can enable autonomous systems and protect our applications and users.

In practice, implementing AI agent security can actually improve your overall security posture. It forces you to clarify access controls, audit trails, and data security practices, which benefits all users (human or AI). And it sends a message to your customers that you take security seriously, even as you embrace new technology.

AI agents will likely become even more capable in the coming years. By integrating them responsibly—with a solid security framework to manage risks—you’ll be better positioned to leverage their full potential.. So, go ahead and welcome our new AI helpers, but make sure to lock the doors, set the ground rules, and keep an eye on things. With the right approach, you can enjoy the productivity gains of autonomous agents while firmly keeping control of your agent systems' security.





---


# OAuth 2.1 vs 2.0: What developers need to know
Source: https://stytch.com/blog/oauth-2-1-vs-2-0/

Enter OAuth 2.1, an update that consolidates a decade of best practices and lessons learned from the soon-to-be outdated OAuth 2.0 protocol. In this guide, we’ll break down what OAuth 2.1 changes, why it matters, and how to implement its improvements in your own authentication and authorization flows.


Modern app development requires solid authentication and authorization strategies to keep user data safe and APIs secure. If you’ve worked with OAuth 2.0, you’ve probably experienced both its flexibility and its security pitfalls.

Enter OAuth 2.1, an update that consolidates a decade of best practices and lessons learned from the soon-to-be outdated OAuth 2.0 protocol.

While it's still in draft form as of April 2025, its core specifications are already being adopted by leading organizations like Anthropic, who have made OAuth 2.1 a foundational part of the Model Context Protocol (MCP) authorization spec.

In this guide, we’ll break down what OAuth 2.1 changes, why it matters, and what you need to implement in order to improve your own authentication and authorization flows.

What is OAuth 2.1 and why does it matter?

OAuth 2.1 is not a brand new standard; it's an incremental update that incorporates the security lessons learned since OAuth 2.0 was released in 2012. Believe it or not—iIt’s been over a decade since RFC 6749 and RFC 6750, the foundations of the OAuth 2.0 protocol, were published in 2012.

Rather than introducing new features, OAuth 2.1 removes insecure patterns and mandates security best practices that were previously optional. Think of OAuth 2.1 as a refinement or an improvement rather than a total rewrite.

Over the years, OAuth 2.0 became a patchwork of extensions and competing recommended implementations. This made it difficult for developers to know what “secure” actually looked like. Instead of forcing developers to cross-reference multiple RFCs (PKCE, JWT access tokens, DPoP ,etc.), OAuth 2.1 gives a single, unified source of truth for secure implementation.



Just like the jump from OAuth 1.0 to 2.0, the community felt like there was a need to address issues by consolidating years of best practices into a more secure, streamlined specification. That’s what OAuth 2.1 aims to deliver.

TL;DR What’s actually changing

If you take away anything from this article, it should be this quick side-by-side comparison of OAuth 2.0 and OAuth 2.1 so you can see what’s changed.



In the next few sections, we’ll walk through each change in more detail and how to implement them in practice.

Key differences between OAuth 2.0 and 2.1

1. PKCE is now required for all clients

In OAuth 2.0, PKCE (Proof Key for Code Exchange) was optional and only recommended for public clients like mobile apps.

In OAuth 2.1, PKCE is required for all clients. Why? It protects against authorization code interception attacks, especially in cases where the code could be intercepted during redirect handling or in misconfigured environments.

What this looks like in practice:



If the authorization server can't validate that the code_verifier matches the original code_challenge, the request is rejected. This prevents attackers from exchanging intercepted codes for tokens—even if they’ve tricked the user into logging in.

2. Implicit flow is removed

In OAuth 2.1, the implicit flow (response_type=token) has been officially removed.

This flow was originally designed for Single-Page Applications (SPAs) that couldn’t securely store client secrets or perform backend token exchanges. It allowed these apps to receive access tokens directly in the browser—without going through the authorization code exchange. While convenient at the time, it introduced serious security concerns like the following:

Token Exposure in URLs: Access tokens returned in the URL fragment can be inadvertently exposed through browser history, referrer headers, or logs, increasing the risk of leakage.​

Lack of Client Authentication: The Implicit Flow does not authenticate the client, making it easier for malicious applications to obtain tokens on behalf of users.​

Advancements in Browser Capabilities: Modern browsers now support Cross-Origin Resource Sharing (CORS), allowing SPAs to securely perform backchannel communication, which was a limitation when the Implicit Flow was introduced.

With the implicit flow, after user authentication and consent, the authorization server would redirect to something like:



Note how the access token is directly included in the URL fragment (after the #). This is the key security risk that led to the removal of this flow in OAuth 2.1.

OAuth 2.1 mandates SPAs use the authorization code flow with PKCE instead.

3. Resource Owner Password Credentials grant is removed

In OAuth 2.0, the Resource Owner Password Credentials (ROPC) grant allowed applications to collect a user's username and password directly and exchange them for tokens. In OAuth 2.1, this grant has been formally removed.

Why? Because ROPC breaks the core design philosophy of OAuth: delegated authorization without exposing credentials. Handing raw user credentials to an application—especially a third-party one—introduces major security risks, including phishing, keylogging, and insecure credential storage.

ROPC grant was susceptible to vulnerabilities like:

Direct Exposure of Credentials: Applications handling raw user credentials increase the risk of credential leakage and misuse.​

Bypassing Secure Delegation: The ROPC grant contradicts OAuth's core principle of delegated access, where applications should obtain tokens without directly accessing user credentials.​

Enhanced Security Practices: Modern security standards advocate for flows that minimize credential exposure, such as the Authorization Code Flow with PKCE.



The client application has full access to the user’s login credentials—introducing countless opportunities for abuse or compromise. This is especially important for confidential clients, which are expected to authenticate securely with the authorization server and avoid exposing user credentials directly.

In this scenario, OAuth 2.1 also mandates the use of Authorization Code flow with PKCE instead.

4. Exact redirect URI matching

OAuth 2.1 requires strict, exact redirect URI matching. This change closes a common security gap in OAuth 2.0, where fuzzy or wildcard matching made it easier for attackers to exploit misconfigured apps and intercept tokens.

In OAuth 2.0, developers often registered redirect URIs with loose patterns to support different environments—like development, staging, or production. For example:

https://website.com/callback​

https://*.website.com/callback (to match multiple subdomains)

While convenient, this flexibility introduced security risks. Attackers could exploit poorly validated redirect URIs to perform open redirect attacks, leading users to malicious sites that could capture sensitive information or tokens.​

OAuth 2.1 eliminates this risk by requiring that the redirect URI included in the authorization request exactly matches one of the pre-registered URIs. No wildcards. No partial matches. If it doesn’t match exactly, the request must be rejected.

5. No tokens in query parameters

In OAuth 2.1, access tokens must never be passed via query parameters. Instead, they should be sent using the Authorization header as a bearer token or, in some cases, the request body for POST requests.



On the other hand, query strings are easily exposed in server logs, browser history, analytics tools, and referrer headers—creating unnecessary risk of token leakage. OAuth 2.1 formalizes this as a prohibited pattern to reduce the attack surface and protect user data.



6. Sender-constrained or rotating refresh tokens

OAuth 2.1 introduces stronger requirements around refresh token usage, especially for public clients. These updates are designed to limit the damage that can be done if a refresh token is stolen or leaked.

To comply, your implementation must either:

Rotate refresh tokens on every use (invalidate the previous one),

Constrain tokens to the original sender, using cryptographic binding (e.g., DPoP or mTLS).

With rotation, every time a refresh token is used to obtain a new access token, the authorization server returns a new refresh token and invalidates the old one. This ensures that:

A stolen refresh token becomes useless after it's been used once.

The lifetime of any individual token is minimized.

Replay attacks using an old token are prevented.

This is the preferred approach for mobile apps, SPAs, and other public clients that can’t securely store long-lived secrets.



Sender-constrained tokens go a step further by cryptographically binding the token to the client that requested it. Even if the token is intercepted, it can’t be used by anyone else.

This can be implemented with:

DPoP (Demonstrating Proof-of-Possession): The client signs each request with a key it controls. The token is bound to this key, and every API call must include a signed DPoP proof.

Mutual TLS (mTLS): The client presents a certificate during the TLS handshake, and the token is bound to that certificate. The token is only valid when used over a TLS connection authenticated with the same cert.

For confidential clients, which can securely store secrets, OAuth 2.1 expects compliance with these refresh token protections, especially when used in server-to-server scenarios like the client credentials grant.

Whether you choose rotation or sender-constrained tokens, the goal is the same: make refresh tokens single-use or client-bound, so they’re useless to attackers if compromised. OAuth 2.1 turns this from an optional best practice into an expectation for secure systems.

A final implementation checklist for developers

If you're building an auth system, whether you're modernizing an existing OAuth 2.0 setup or starting with OAuth 2.1, these are the key implementation priorities to focus on:

Use authorization code + PKCE everywhere: Make PKCE the default for all clients—including web, mobile, and SPAs. It’s now required in OAuth 2.1 and significantly reduces the risk of authorization code interception.

Remove deprecated flows: Eliminate use of the Implicit and Resource Owner Password Credentials grants. Redirect users through the authorization code flow instead, which supports modern security features like MFA and consent screens.

Audit and lock down redirect URIs: Ensure every redirect URI is exact, HTTPS-only, and pre-registered with your authorization server. Wildcard or loosely matched URIs are no longer acceptable. URIs must be matched exactly.

Secure Token Transmission: Always transmit bearer tokens via headers or message bodies, avoiding query strings to reduce exposure. Make sure each access token expires within a short, predictable window to limit the risk if it’s ever leaked.

Rotate refresh tokens: If your app uses refresh tokens, implement rotation. Each token should be single-use, with the previous one invalidated after a new one is issued. This is especially important for public clients like SPAs and mobile apps.

How Stytch can help

Just like OAuth 2.0, implementing a secure OAuth 2.1-compliant flow from scratch is a steep technical challenge and investment to ensure secure authentication and authorization systems.

Stytch’s Connected Apps feature can offload that engineering work. It gives you:

A fully compliant OAuth and OIDC identity provider

The ability to create and authenticate third-party applications with issued access tokens

A unified management system for permissions, scopes, and consent flows

Built-in PKCE, token rotation, scope enforcement, and secure defaults

And more

If you're building an app that needs to integrate with AI agents or third-party apps, Stytch makes it easy. You configure a fully compliant OAuth server with your application in just a few steps.

Final thoughts

It’s time to upgrade. Embracing OAuth 2.1 now means fewer vulnerabilities, less complexity, and a more secure foundation for your authentication and authorization systems.

Implementing auth can be a heavy lift, but you don’t have to build it from scratch. Stytch offers a suite of APIs and SDKs for authentication, authorization, and fraud prevention, so you can implement OAuth quickly without compromising on security.

Sign up today and build OAuth.






---


# Stytch vs Auth0: Bot detection
Source: https://stytch.com/blog/stytch-vs-auth0-bot-detection/

This is where Stytch device fingerprinting not only outperforms bot detection but also surpasses other less persistent tech, like browser fingerprinting.

Several auth providers like Auth0 provide a generic bot detection feature that aims to detect automated traffic or activity. But assuming that fraud is exclusively perpetrated by bots ignores the more complex reality where both humans and bots are capable of executing sophisticated schemes.

Traditional bot detection focuses on identifying and blocking automated traffic, which might work for stopping spam bots, credential stuffing scripts, or DDoS attacks​. However, modern fraud prevention needs to go further than a simple yes/no on automation. Your application should also be capable of:

Recognizing AI agent use and abuse.

Persistently identifying a fraudster who switches devices or uses spoofing tactics.

Distinguishing between legitimate users and malicious actors who aren’t bots.

Preventing fraud like fake signups, account takeovers, payment fraud, and more.

Bot detection is no longer about blocking “just bots.” It’s about understanding behavioral context, usage patterns, and low-level signals from devices and networks. And that requires much more than what traditional bot detection solutions can deliver.

In this article, we’ll explore how Stytch’s Fraud & Risk Prevention solution—specifically our advanced Device Fingerprinting feature—goes far beyond basic offerings like Auth0 bot detection.

Auth0 bot detection: Limitations and challenges

Auth0 offers a bot detection feature, but its approach has significant limitations when it comes to comprehensive fraud prevention. This means it can flag obvious automated attacks like high-volume IPs, serve CAPTCHAs, and recognize simple automation patterns. But Auth0’s approach lacks the persistence, depth, and flexibility needed to detect more sophisticated fraud schemes.

Here are the main limitations when working with Auth0 bot detection.

A toggle, not a toolkit



One of the most critical shortcomings of Auth0’s bot detection feature is how rigid and opaque it is. At its core, it’s just a simple toggle—an on/off switch in the dashboard. You flip it on, and Auth0 begins applying generic detection logic behind the scenes. 

The only additional control is an opaque slider of the level of bot detection.



This kind of one-size-fits-all logic might catch a noisy bot, but it’s not equipped for real-world threats and complexity. By contrast, platforms like Stytch provide a fully configurable API, customizable Security Rules Engine, and rich device telemetry so your team can design risk-based authentication flows that respond in real time to evolving threats.

Session-based detection

Auth0 bot detection relies on ephemeral signals like IP addresses, user agents, and browser headers to evaluate traffic. These attributes reset at the end of each session and can be easily spoofed. Without persistent identifiers, Auth0 can’t track returning fraudsters or connect fraudulent behavior across sessions, devices, or networks—leaving serious blind spots in your security posture.

Basic rate limiting

Auth0’s rate limiting is largely tied to IP addresses. It can throttle requests from a specific IP, but attackers can easily rotate IPs to bypass this check. Worse, this blunt approach can backfire—blocking legitimate users on shared IPs, such as those behind corporate networks or mobile carriers.



Outdated CAPTCHA challenges

When Auth0 bot detection can’t confidently assess risk, it defaults to CAPTCHA challenges. In fact, CAPTCHAs form the backbone of Auth0’s bot mitigation strategy. But CAPTCHA-solving farms and automated solvers make this defense easy to bypass, while simultaneously adding friction and frustration for legitimate users.



Bots only, no human fraud detection

Auth0 bot detection models are designed to catch non-human behavior. If a fraudster mimics legitimate user actions—or if a real user simply behaves in an unusual way—Auth0 struggles to tell the difference. This binary lens means manual account takeovers, human-in-the-loop attacks, and social engineering tactics often go undetected.

Limited to Universal Login & no customizations

Auth0’s bot detection features are only fully supported in its Universal Login product. If your app uses custom authentication flows or embeds login directly into the UI, you will only have limited support unless you migrate to Universal Login—which comes with major drawbacks. That’s a significant integration constraint for modern applications seeking customizations and flexibility.

If you're serious about defending against today’s fraud landscape, you need more than point-in-time detection and CAPTCHAs. You need persistent identifiers, telemetry, and device-level intelligence—the kind that Auth0 bot detection doesn't provide.

Stytch Device Fingerprinting: A persistent, intelligent defense

Stytch takes a fundamentally different approach to fraud prevention—one that goes far beyond session-based bot detection. Instead of relying on ephemeral signals like IPs or headers, Stytch uses advanced device fingerprinting to uniquely and reliably identify users across sessions, devices, and behaviors.



Here are the core reasons why our approach to bot detection enables companies across high-risk industries like B2B SaaS, fintech, and e-commerce to use Stytch Device Fingerprinting to uncover sophisticated fraud patterns.

Flexible dev tools and integration

Stytch provides an API and multiple SDKs (Node, Go, Python, Ruby, Swift, Kotlin, etc.) that make it simple to embed device fingerprinting into any application architecture. Whether you use Stytch for authentication or not, our Device Fingerprinting platform is modular by design. You can integrate it:

As a standalone fraud prevention layer for any custom-built application

As part of Stytch’s auth flows (e.g. login, signup, session refresh)

With your existing security stack via our API and SDKs

Setup is fast. Just drop in the Stytch telemetry script or SDK, and start receiving telemetry-based verdicts in a matter of minutes.

Persistent identity, deep device intelligence

Stytch’s device fingerprinting engine creates stable, high-entropy identifiers for every user device, combining standard and proprietary telemetry across:

Browser sub-signals and rendering behavior

Passive TLS and network fingerprinting

Hardware architecture and OS resources

And more

The result is a unique and powerful set of fingerprint identifiers that’s persistent across sessions, and incredibly difficult to spoof—even with network switching, incognito mode, or user agent deception. These identifiers provide deep, context-aware device intelligence that gives you the power to make smarter, more targeted security decisions.



For example, our visitor_fingerprint is a cookie-less way to uniquely identify users across sessions, which is perfect for enforcing paywalls, because it remains consistent even in incognito mode. On the other hand, our hardware_fingerprint can be used to identify the operating system and architecture of a device, which is useful for detecting proxy or location spoofing.

These, along with the other fingerprints we provide, can be found in the table below.



Fraud Prevention beyond bots

Because each fingerprint is persistent and highly unique, Stytch can recognize when a device reappears under different identities—not just bots. This makes Stytch uniquely capable of identifying:

Phishing-based takeovers from unfamiliar devices

Subscription fraud, referral gaming, and toll fraud

Fake account generation from cloaked environments

Bypass attempts via incognito, VPNs, or TOR nodes

Stytch stops fraud: bots and humans alike.

Actions and reasons



Stytch’s Device Fingerprinting doesn’t just identify devices—it provides a robust actions and reasons framework that enables you to respond intelligently in real time. For every fingerprinted request, Stytch returns:

A clear verdict (ALLOW, CHALLENGE, or BLOCK)

A set of reasons explaining why the decision was made (e.g., new device, fingerprint mismatch, abnormal velocity, known fraudulent pattern)

This structure empowers you to tailor your fraud response strategy with precision. You can:

Trigger step-up authentication (like MFA) for suspicious but not confirmed threats

Introduce friction (CAPTCHA, rate limiting, re-verification) based on context

Block access outright when the fingerprint is known to be malicious or risky

Maintain a seamless experience for trusted, low-risk devices

Security rules engine



Stytch also provides a Security Rules Engine that gives you full control over how you programmatically respond to certain fingerprints and identifiers. You can configure rules:

Directly via the Stytch Dashboard

Programmatically via API

On a per-device, per-fingerprint basis

This gives you the control to trigger fraud prevention measures only where it’s needed.

Intelligent Rate Limiting

Instead of throttling broad IP ranges, Stytch uses granular, device-level rate limiting to pinpoint abuse. When our system detects anomalous velocity or behavior, it can:

Challenge or block specific offending devices

Return graduated verdicts (RATE_LIMIT_WARNING, RATE_LIMIT_EXCEEDED, RATE_LIMIT_BANNED)

Avoid false positives that punish legitimate users on shared networks (e.g. corporate or mobile carriers)

Stytch's Intelligent Rate Limiting feature is dynamically powered by real-time telemetry and reinforced by our fingerprinting data.

A side-by-side comparison



Getting started with Stytch’s Device Fingerprinting

Our DFP product suite is compatible with all web and native mobile authentication experiences, whether it’s built with another provider, in-house, or Stytch. The best part? You don’t need to write any custom code or actions for any of Stytch’s device fingerprinting features to work, and the setup process can have you up and running in just a few minutes.

Once you install Stytch’s telemetry script by including the <script> tag in the <head> section of your page, you just need to call the GetTelemetryID function to get a unique identifier for each user.



The telemetry ID serves as the foundation for calling our Fingerprint Lookup API, which provides unique insights into device activity and suggests actions for handling further interactions with that device.





Ready to talk to an auth expert about Stytch’s Fraud & Risk Prevention product suite? 

Feel free to schedule a chat with one of our experts. 





---


# Handling AI agent permissions
Source: https://stytch.com/blog/handling-ai-agent-permissions/

How do you ensure an AI agent doesn’t overstep its bounds? What happens if it tries to modify something it shouldn’t or accesses sensitive data unintentionally? This article explores how AI agent permissions can go wrong when mishandled using example scenarios and outlines key best practices developers should implement to prevent them.

How do you ensure an AI agent doesn’t overstep its bounds? What happens if it tries to modify something it shouldn’t or accesses sensitive data unintentionally?

This article explores how AI agent permissions can go wrong when mishandled using example scenarios and outlines key best practices developers should implement to prevent them.

AI Agent permissions: What's the worst that could happen?

Traditional software typically follows predictable, testable, and mostly pre-determined logic. AI agents, powered by LLMs, are different. They generate actions dynamically based on natural language inputs and infer intent from ambiguous context, which makes their behavior more flexible—and unpredictable. Without a robust authorization model to enforce permissions, the consequences can be severe.

Here’s why proper permission handling and securing AI agents are essential, and where things can go wrong:

1. Unpredictable autonomy

LLMs don’t follow rigid code paths or fixed executions. When granted broad and direct access to tools, APIs, databases, or internal systems, they can perform actions the developer or end user never intended, especially when safeguards like permission scoping or user confirmation are missing.

Consider an enterprise that deploys an AI-powered executive assistant with access to users’ inboxes to help manage scheduling and draft emails.



A manager asks the assistant, “Send a follow-up to Alex with the budget slide deck and key points from the leadership meeting.” The assistant looks through the contact list, selects the first match for “Alex”, an external contractor instead of the intended internal stakeholder, and sends the email with the confidential attachment. Because the assistant had full email-sending privileges, sensitive information was exposed with a single prompt.

Even worse, AI agents with overly permissive access can be exploited by malicious actors—not just through bugs, but through carefully crafted prompts. One of the most dangerous attack vectors is prompt injection, where a malicious prompt is embedded somewhere in the input, causing the AI to either override its original instructions or execute unintended commands.

For example, imagine an AI agent integrated with a plugin system and instructed to query data, encode it, and return a specific format. An attacker could engineer prompts that result in the agent executing a live SQL query, retrieving sensitive user data, encoding it into a URL, and outputting it exactly as requested:



source

This kind of behavior could easily result in the exfiltration of sensitive data, especially if combined with external tools, document plugins, or browser-based agents.

Whether accidental or adversarial, the lesson is the same: AI agents should never be given broad, unsupervised authority to act. Without strict permissions, well-defined scopes, and limited access, their ability to dynamically infer and act can quickly become a liability.

2. Acting on behalf of users

AI agents often operate using delegated credentials—such as OAuth tokens or service identities tied to the user initiating the request—which allows them to act on that user’s behalf.

While this model supports automation, it can introduce significant risks if the agent and user are not clearly distinguished. When the agent and the user are treated identically, it may execute actions that were never intended—even if those actions fall within the scope of the user’s technical permissions.

Consider a scenario where a DevOps AI agent is deployed to help engineers manage infrastructure. To simplify integration, the AI agent operates using the OAuth tokens of the requesting user—meaning it inherits the developer’s identity and permissions directly.



One day, a developer asks the assistant to “clean up old resources.” The assistant interprets this request too broadly and issues a DELETE command that removes a production database replica. Because the agent was treated as an extension of the user rather than a distinct client, there was no opportunity to apply additional safeguards, scope checks, or runtime reviews.

A more secure pattern is to treat the AI agent as its own independent client, with its own OAuth client ID and access token. This way, the agent’s permissions can be explicitly defined, audited, and limited—rather than inherited from whoever happened to prompt it. Without this separation, agents risk inheriting permissions that bypass enforcement layers entirely.

Had the agent instead been issued its own OAuth client ID and access token—separate from the user—it could have been explicitly constrained to perform only non-destructive operations, especially when agents are empowered to act within sensitive or production environments.

3. Security and compliance in regulated industries

In highly regulated industries like finance or healthcare, lax AI agent boundaries can lead to compliance violations, data leaks, or even legal repercussions. AI agents that are operating in multi-tenant systems don’t just need narrowly scoped credentials, they also may require strong runtime controls and execution boundaries to meet regulatory data protection standards like GDPR and HIPAA.

Imagine an AI assistant embedded within a CRM platform used by multiple enterprise customers. The assistant is scoped: it only retrieves data belonging to the currently authenticated tenant and operates under strict API-level access controls.

However, when asked to “generate a summary of common customer issues this month,” the AI agent accesses shared context or global memory and decides to aggregate and compare trends across multiple tenants in order to produce a more “insightful” response. It compiles this data into a report that references patterns seen in multiple client environments and displays it directly in the UI.



In this case, no permission was explicitly violated at the API level—but the runtime behavior of the AI agent violated the platform’s multi-tenant data isolation model. This happened not because of excessive access, but because there were no sandboxing or policy enforcement mechanisms to restrict how the AI processed data once retrieved.

This kind of failure is subtle but dangerous. It’s not a question of “who can access what,” but “what can the AI do with the data it’s allowed to see?”.

In regulated or enterprise environments, this can still constitute a serious compliance breach, despite correct authentication and authorization on paper.

Best practices for AI agent permissions

To safely deploy AI agents in real-world systems, here are some core principles every AI-integrated system should enforce for proper permission management:

Least privilege

AI agents should be granted only the minimum access required to perform their tasks—nothing more. Avoid providing unrestricted credentials, root API keys, or full administrative access. Instead, issue scoped tokens or read-only roles that tightly align with the agent’s intended behavior. For example, if an agent is assisting with support tickets, it shouldn’t have access to billing or administrative APIs.

OAuth scopes and consent

Leverage OAuth 2.0 to define granular access scopes and obtain explicit user consent. Rather than issuing a single token with wide-ranging privileges, define fine-grained scopes such as read_calendar, send_email, or view_contacts. This allows the user (or admin) to control precisely what the AI agent is authorized to do on their behalf.

Leading AI organizations like Anthropic have made OAuth 2.1 a foundational part of the Model Context Protocol (MCP) authorization spec.

Short-lived tokens and revocation

AI agents should never be issued long-lived credentials. Instead, use short-lived access tokens with built-in expiration and refresh mechanisms. In case of suspicious behavior, tokens can be revoked without disrupting the user’s primary session or credentials.

Importantly, tokens should never be exposed inside LLM prompts. The backend service—not the LLM—should handle credential attachment securely at runtime. Treat tokens as sensitive secrets and follow standard credential management best practices, such as storing them in encrypted vaults or using ephemeral session credentials.

Audit logging

Every action an AI agent takes should be logged and traceable, just as if a human user had performed it. Logs should include what was accessed, when, and under which identity and permissions. This provides an essential forensic trail in case of incidents or unexpected outcomes.

Comprehensive logging also supports compliance requirements (e.g., GDPR, HIPAA) and enables proactive monitoring—such as detecting out-of-pattern behaviors or unapproved cross-tenant data references.

Human oversight for sensitive actions

Users should always be able to see what an AI agent has permission to access and do. This can take the form of a consent screen, access dashboard, or detailed activity panel.

Additionally, agents should require confirmation for critical operations by only authorized users. Even the most well-designed AI agent should not operate entirely autonomously when it comes to destructive, irreversible, or sensitive actions.

Securely connecting your apps to AI agents

Implementing the right permission model for AI agents is critical, but actually enforcing those permissions across third-party tools, plugins, and AI models in the broader context of AI agent security can be challenging. Especially in multi-tenant environments or distributed systems, securely brokering access between your app and AI agents requires a lot of engineering infrastructure.



That’s where Stytch’s Connected Apps comes in. Connected Apps allows you to turn your application into a secure OAuth / OIDC identity provider, so you can delegate access to AI agents, external tools, or third-party apps using scoped tokens and consent-driven flows.

With Stytch Connected Apps, you can:

Issue access tokens for each AI agent with custom scopes and permissions, alongside role based access control.

Isolate agent identity from end-user identity, so that permissions are explicitly defined rather than inherited from whoever triggered the action.

Define and enforce consent flows, so users or admins can authorize what agents are allowed to access—down to the specific resource or API endpoint.

Monitor and revoke access, ensuring that every AI agent session is auditable and controllable.



Stytch handles the complexity of AI agent authentication and authorization flows, so you can focus on building secure AI-powered features without reinventing your auth layer.

Conclusion

AI agents are powerful, but the stakes are high. By following best practices like using OAuth scopes, you can unlock the full potential of AI agents without introducing unnecessary risk.

And if you need a foundation for connecting your applications to AI agents securely, Stytch Connected Apps offers the developer tools to integrate quickly and securely.

Ready to connect your app to AI agents, the right way? Get started with Stytch today.



---


# Secure agent access in Remote MCP with Stytch and Cloudflare
Source: https://stytch.com/blog/remote-mcp-stytch-cloudflare/

Stytch has partnered with Cloudflare to help make every application agent-accessible with today’s launch of Remote MCP Authorization in Stytch Connected Apps.

We’re excited to partner with Cloudflare to help make every application agent-accessible with today’s launch of Remote MCP Authorization in Stytch Connected Apps. With this launch, developers can easily add authorization to Remote MCP Servers built on Cloudflare Workers, and any other frameworks supporting MCP Servers.

Bringing MCP to the Internet

Model Context Protocol (MCP) is an open standard designed by Anthropic that defines how AI agents (the “Client”) can communicate with servers and discover their capabilities. Servers provide functionality that the agent’s underlying LLM doesn’t natively support—enabling the agent to interact with third-party applications and perform complex workflows without requiring bespoke, hardcoded integrations for each app.



Originally MCP servers could only run locally on your machine, but recent updates to the specification have defined support for Remote MCP, bringing MCP to the internet and making it possible for every web application to offer agents access in a way that is broadly accessible and easy for end users to use.

However, there are a number of challenges facing developers who want to build remote MCP servers:

Support for remote transport that supports bi-directional, real-time communication

Backwards compatibility with MCP clients designed for local MCP servers

State management to support multi-step workflows

Registering new MCP clients dynamically

Secure, tightly-scoped access controls for what MCP Clients can do on the user’s behalf

Cloudflare’s recent launch of their workers-mcp package offers developers out-of-the-box support for the core remote transport and state management challenges, as well as a foundational abstraction layer for adding in Client authorization via OAuth, solving most of the issues mentioned above.

While Cloudflare provides the foundation for Remote MCP servers, there are still several key challenges for handling Remote MCP authorization, namely in secure and robust authorization for these AI agents. With today’s launch, Stytch Connected Apps solves this last problem by enabling Remote MCP authorization via OAuth.

Agent authorization via OAuth 2.0

Bringing MCP to the internet requires robust MCP client authorization. At Stytch we’ve advocated using OAuth 2.0 for agent authorization and are excited to see this approach incorporated into last month’s revision to the MCP specification for Remote MCP.

OAuth 2.0 offers a well established protocol for authorizing clients to act on an end user’s behalf within an application, and its sister protocol OpenID Connect (OIDC) offers an established pattern for communicating the identity information of that end user. As such, OAuth is the standard being used to allow AI agents to authenticate with APIs. Cloudflare offers basic OAuth in their Getting Started guide as a proof of concept, but recommends more robust implementations, like Stytch, for production-level solutions that maintain core security features.

"If you want to allow people to grant an MCP Server permission to read or write data on their account, you’re going to need an OAuth provider. Stytch makes OAuth easy and has worked perfectly with the MCP Server support we’ve built into the Cloudflare Agents SDK. We continue to be amazed by just how quickly companies have been able to get up and running in production with remote MCP servers, and we’re excited to see what developers continue build with Stytch and Cloudflare together."

– Brendan Irvine-Broque, Director of Product, Cloudflare

While OAuth 2.0 specifications have been the standard for enabling 3rd party integrations that require end user consent and scoped permissions for over a decade, becoming a fully-fledged identity provider is a significant, ongoing lift. Identity standards are complex and ever-changing with over 30 published OAuth RFCs and a dozen active drafts. Developers not only need to think about implementing the specifications, they also need to think about everything the specifications don't cover, including:

Management of 3rd party clients

Application-specific scopes and permissions

End user and IT admin management of granted consent

Revoking access on end user deactivation or role change

Securing powerful credentials like private keys used to sign Access and ID tokens

Responding to new and novel attacks

As a result, this was typically only worthwhile for large companies with enough reach to incentivize 3rd party developers to build integrations for their platform. Remote MCP changes this.

Autonomous client registration

The real magic of Remote MCP is allowing clients and servers to communicate without human interaction.

In traditional OAuth 2.0, client registration is a manual setup process where the 3rd party developer creates a client in a GUI, provides their redirect URIs, and receives a Client ID and secret that can then be used to authenticate the client during the authorization flow.

In order to allow clients and servers to communicate without this manual setup process, the MCP specification encourages servers to implement the Dynamic Client Registration (DCR) and Authorization Server Metadata standards. These protocols allow each MCP client to autonomously discover information about the MCP server, self-register, and report their redirect URIs. In turn, this means MCP client developers don't need to maintain relationships with every MCP server that exists – democratizing the type of tools that can be leveraged by AI agents in complex workflows

While DCR is part of the OAuth 2.0 specification, adoption of DCR has been mostly non-existent for third-party applications – since without a smart client that can learn how to communicate with the server, there is very little value to removing the initial setup step.

As a result, there are a lot of open questions to figure out for developers who want to add DCR to their MCP server, including:

How should I manage dynamically created clients' lifecycles? How can I understand what MCP Clients are accessing my application?

How can IT Admins control access to dynamically created clients within their organization?

How can Dynamic Client Registration be implemented securely, avoiding common OAuth security issues like Client Impersonation?

Stytch addresses these concerns before they become problems. Using Stytch as your auth provider to handle OAuth for MCP, you get to take advantage of the already robust infrastructure, security, administrative tools, and built-in future-proofing. Moreover, Stytch Connected Apps goes beyond the minimum spec to let MCP be production-ready, instead of proof-of-concept software.

MCP servers as identity providers vs relying parties

At a high level, there are two key flows for building authorization into Remote MCP servers:

MCP servers that function as the Identity Provider in the OAuth exchange

MCP servers that function as a Relying Party in the OAuth exchange

Stytch provides a toolkit to create identity providers, which allows us to support either use case. If your MCP Server is more of a standalone application, Stytch enables you to turn the MCP server itself into an identity provider. If you want to expose your existing application to an MCP server, Stytch allows your application to serve as the identity provider – enabling end user authentication and client authorization across both your normal web app and your MCP server.



Regardless of your approach, Stytch Connected Apps provides everything you need to grant secure, well managed access to AI agents on behalf of your users, including:

Core OAuth 2.1 specification

Dynamic Client Registration

Authorization Server Metadata

Custom Scopes based on Resources/Actions granted as permissions to end users

Client Management with deduplication on ClientID for DCR Clients

End user and IT Admin management of granted consent

Organization controls on whether to allow DCR client authorization

Curious about how this might look in action? We’ve built a sample application showcasing how Stytch handles member, tenant, and client identity on a traditional full-stack application on a MCP Server. Or read our docs to build it yourself.



Shaping the agentic future

While the addition of Authorization to the Remote MCP specification is exciting, there are still gaps. For example, defining a clear pattern for discovering and requesting custom scopes, in order to ensure that MCP Clients can identify what access they need to perform the task at hand and limit their access request to those permissions.

Today’s launch of Stytch Connected Apps for MCP servers addresses this. It gives your apps and agents the power to authenticate with one another using best-in-class security practices and infrastructure. We’ll continue to help shape how authentication and authorization can and should behave for Remote MCP, and are excited to partner closely with Cloudflare to understand the evolving needs and use cases for Remote MCP Servers. Our engineers are even hard at work directly contributing to the open source specifications, establishing Stytch as a leader in the space.

Curious about how MCP fits into your product, or want to chat about your ideas? Continue the discussion with us by contacting us directly to get a demo. We’re always looking for interesting and unique use cases to make the Agentic Future a reality.

---


# MCP authentication and authorization servers
Source: https://stytch.com/blog/mcp-authentication-and-authorization-servers/

The Model Context Protocol (MCP) is an open standard that bridges LLM models with external data, API, and services. But how do we enable this kind of connectivity without compromising on security or proper authentication best practices?
In this post, we’ll cover how authentication works in MCP, the responsibilities of each component, and the key piece that often goes unnoticed—the authorization server.

The Model Context Protocol (MCP) is an open standard that bridges LLM models with external data, API, and services. But how do we enable this kind of connectivity without compromising on security or proper authentication best practices?

In this post, we’ll cover how authentication works in MCP, the responsibilities of each component, and the key piece that often goes unnoticed—the authorization server.

What is MCP?

If you’ve been following the AI agent space, you’ve probably heard of MCP already—but here’s a quick refresher.

MCP (Model Context Protocol) is an open standard developed by Anthropic that defines a consistent, structured interface between AI agents and external services like APIs, databases, and third-party tools. Instead of building bespoke integrations or writing custom glue code, developers can implement the MCP interface in a standardized way to expose external systems and tools to AI agents.

In MCP, there are three core roles:

MCP clients live inside AI agents. They're responsible for making requests to services via transport protocols like stdio or SSE.

MCP servers act as integration layers that expose tools and actions to MCP clients. These servers wrap external APIs or systems and translate incoming MCP calls into backend logic.

Third-party services are the external APIs or systems (e.g., GitHub, Notion, Google Calendar) that the MCP Server connects to. The server translates MCP requests into calls to these services.



An MCP client may request something like createToDo, and the MCP server fulfills the request by calling the appropriate third-party API.

But how do these MCP clients, MCP servers, and third-party services securely connect with each other?

How MCP authentication works

Authentication in the Model Context Protocol builds on a well-established and secure foundation: OAuth. This lets users log in, review requested permissions, and explicitly authorize agents to act on their behalf—all using familiar patterns from modern federated authentication and delegated authorization.



Here’s what a simplified OAuth flow might look like in the context of MCP:

MCP client initiates a request to an MCP server.

Server responds with a 401 Unauthorized and a redirect link to login to an OAuth provider.

User logs in to the OAuth provider, views a consent screen, and grants requested scopes.

Server returns an auth code to the client.

MCP Client exchanges the code for access + refresh tokens.

OAuth tokens are used for all subsequent MCP client requests.

MCP server calls the third-party service.

And within that flow, the latest MCP spec formalizes expectations around how OAuth authorization will operate with MCP servers. Specifically, it mandates or strongly recommends implementing:

PKCE: All MCP auth flows must adhere to the OAuth 2.1 specification, including mandatory use of PKCE to protect authorization code exchanges.

Authorization Server Metadata: MCP servers should expose standard metadata (per RFC 8414) to help clients discover supported endpoints and capabilities automatically.

Dynamic Client Registration: MCP servers should support dynamic client registration to simplify the process of onboarding new clients and agents.



At this point, you might wonder: who is responsible for handling all of these OAuth flows? Which component is acting as the OAuth identity provider, relying party, the resource server, or authorization server?

The answer isn’t obvious, because it depends on how your MCP server is architected. But even worse, most explanations of MCP forget to include a critical piece of the authentication flow.

MCP authorization server

What’s overlooked in the core of MCP architecture is the role of the authorization server, which is a core role within the OAuth flow responsible for issuing access tokens to the client after successful authentication. 

While we commonly talk about the three main components—MCP clients, MCP servers, and third-party services—there’s a critical fourth player that handles authentication and access control within the MCP flow.

MCP clients

MCP servers

Third-party services

Authorization server (OAuth handling)



The authorization server is what makes secure, user-consented OAuth flow possible in MCP. It’s responsible for:

Issuing signed access tokens with embedded claims

Supporting OAuth 2.1 flows (e.g., Authorization Code with PKCE) we mentioned before

Presenting consent screens

Enforcing token lifetime, refresh logic, and revocation

And more

But if the authorization server plays such a key role, why isn’t it shown in most standard MCP diagrams? There are a few reasons:

Most MCP servers are still local implementations using stdio without auth. This will change dramatically with the rise of remote MCP servers.

Authorization server implementations are not finalized in the MCP specification (here’s an active discussion among developers).

There’s more than one way to implement it.

Two architectures for MCP authorization servers

When designing an MCP server, one of the most important authentication decisions you’ll face is whether your server will act as an Identity Provider or a Relying Party in the OAuth exchange.

There are two primary ways to implement the authorization server within the MCP architecture:

Embed the authorization server within the MCP server, effectively making the MCP server an Identity Provider that handles login, consent, and token issuance directly. This is why most MCP explanations don’t mention the authorization server. They assume the MCP server is the authorization server.

Delegate to an external authorization server, which makes your MCP server a Relying Party in the OAuth exchange—consuming third-party tokens and mapping them to internally scoped permissions.

Both approaches are valid under the MCP specification and each comes with its own tradeoffs in complexity and integration effort. This choice influences how much OAuth infrastructure you need to manage within the MCP server itself.

Embedding the authorization server



In this architecture, the MCP server includes its own built-in authorization server. It acts as both the Identity Provider and Relying Party, managing the entire OAuth 2.1 flow internally.

The MCP server is effectively responsible for everything:

Handling incoming requests from the MCP client

Presenting login and consent screens

Issuing signed access tokens with embedded identity and scope claims

Validating tokens and enforcing access control policies

Supporting OAuth 2.1 features like Authorization Code with PKCE

Managing token lifetimes, refresh logic, and revocation

Some developers have raised concerns that requiring MCP servers to also be an authorization server is too much of a burden. For many use cases, this coupling may be unnecessary and costly to integrate.

Delegating to an external authorization server



Here, the MCP server delegates the entire OAuth flow to an external authorization server or service. The MCP server acts as a traditional OAuth Relying Party, consuming tokens issued by a separate Identity Provider.

Here, the MCP server is only responsible for:

Handling MCP client requests

Mapping identity claims and scopes to internal permissions

Validating external access tokens (this could also be handled by the external auth server)

This architecture follows the OAuth best practice of separating concerns between the authorization server and the resource server. It enables teams to reuse existing identity infrastructure or integrate auth providers like Stytch, while focusing solely on defining and enforcing tool-level access.

A quick glance side-by-side



An evolving specification

Keep in mind that the MCP specification is actively changing. Updates are being proposed and merged on a regular basis (like this open PR that outlines some upcoming authorization changes).

It’s a good idea to keep an eye on the latest pull requests and ongoing discussions in the official MCP repo to stay aligned with the direction of the protocol.

Stytch Connected Apps: Building secure auth for MCP

MCP gives us a powerful way to structure and standardize how agents interact with external services. But that power depends on a well-designed authentication and authorization layer.

No matter how you architect your MCP server, Stytch Connected Apps provides everything you need to deliver secure, OAuth compliant authorization sever.

For a hands-on look, check out our MCP to-do list example app or B2B MCP OKR manager example app see how the OAuth flow code is structured and executed between MCP client and server.



Stytch provides a toolkit to create OAuth compliant Identity Providers to support both use cases:

Is your MCP Server more of a standalone application? Stytch enables you to turn the MCP server itself into an Identity Provider.

Want to expose your existing application to an MCP server? Stytch allows your application to serve as the Identity Provider – enabling end user authentication and client authorization across both your normal web app and your MCP server.

With Connected Apps, you can offload the engineering work and hardest parts of building OAuth infrastructure. Stytch handles:

Core OAuth 2.1 specification

Dynamic Client Registration

Authorization Server Metadata

Custom Scopes based on Resources/Actions granted as permissions to end users

Client Management with deduplication on ClientID for DCR Clients

End user and IT Admin management of granted consent

Organization controls on whether to allow DCR client authorization

Curious how MCP fits into your stack? Interested in building secure agentic integrations without rebuilding your auth layer from scratch?

Contact us for a demo or sign up and check out our MCP quickstart guide.





---


# MCP and OAuth Dynamic Client Registration
Source: https://stytch.com/blog/mcp-oauth-dynamic-client-registration/

The Model Context Protocol (MCP) is quickly becoming the connective tissue between AI agents and the external tools or data they interact with. But with that flexibility comes a need for strong security: How do you make sure that any AI agent trying to connect to your MCP server is trustworthy? And how do you do this in a scalable way when new agents are constantly being created? That’s where OAuth 2.0’s Dynamic Client Registration comes in, which is officially supported in MCP authorization specification.

In this post, we’ll explain what Dynamic Client Registration is, how it works, and why it’s essential for authentication between MCP servers and AI agents.


The Model Context Protocol (MCP) is quickly becoming the connective tissue between AI agents and the external tools or data they interact with. But with that flexibility comes a need for strong security: How do you make sure that any AI agent trying to connect to your MCP server is trustworthy? And how do you do this in a scalable way when new agents are constantly being created?

That’s where OAuth 2.0’s Dynamic Client Registration comes in, which is officially supported in MCP authorization specification.

In this post, we’ll explain what Dynamic Client Registration is, how it works, and why it’s essential for authentication between MCP servers and AI agents.

Understanding the MCP authentication challenge

MCP defines a client-server architecture where AI agents act as clients and MCP servers provide access to tools and services. To ensure secure communication, AI agents need to authenticate using OAuth 2.0.



Traditionally, this involves manual client registration which is impractical at the scale of agentic AI. It’s not feasible or practical to require developers to manually register every MCP client with every MCP server. In particular:

AI agents must connect to numerous, unknown numbers of MCP servers

Manual registration introduces friction for developers and users

The number of potential client-server combinations grows exponentially

OAuth 2.0 Dynamic Client Registration solves this M × N problem by allowing AI agents to autonomously discover, register, and authenticate with MCP servers at runtime.

What is OAuth 2.0 Dynamic Client Registration?

Dynamic Client Registration is an extension to the OAuth 2.0 framework, defined in RFC 7591, that allows Relying Parties to register themselves programmatically with an OAuth2 Authorization Server.

Instead of pre-registering an application with a manual setup of credentials, Dynamic Client Registration allows the Relying Party to make a POST request with metadata (like redirect URIs and grant types) to a registration endpoint.



Dynamic Client Registration allows for self-service onboarding for applications without developer intervention, which makes it particularly valuable in large-scale OAuth ecosystems.

Why Dynamic Client Registration matters for MCP and AI agents

MCP is designed for a many-to-many world, where AI agents need to authenticate and connect to a wide range of independently operated MCP servers. Dynamic Client Registration solves this challenge by allowing AI agents to discover, register, and obtain credentials from MCP servers at runtime.

With Dynamic Client Registration, the MCP servers can:

Onboard AI agents dynamically: An AI agent encountering a new MCP server can register and get credentials without human intervention or prior coordination.

Scale securely: Each agent gets its own identity and credentials, preventing token reuse or spoofing.

Delegate permissions: Agents request scopes; users approve access; tokens encode both keeping permissions granular and user-approved.

Comply with OAuth2.1: The MCP spec leans heavily on OAuth 2.1, including support for PKCE and dynamic flows.



How Dynamic Client Registration works in MCP OAuth flow



Here’s how the flow typically works within the MCP OAuth flow:

Discovery: The AI agent retrieves metadata from the MCP server, discovering OAuth endpoints.

Registration*: The agent sends a registration request to the /register endpoint. This is where Dynamic Client Registration starts.

Client Creation*: The authorization server creates a new OAuth client and stores its details. This is where Dynamic Client Registration happens.

Credentials Return: The authorization server returns the client ID and secret (if required).

Authorization: The agent initiates the OAuth flow using the returned credentials.

Token Exchange: The agent exchanges the auth code for access and refresh tokens.

Authenticated Access: The agent uses these tokens to access tools via the MCP server.

For a hands-on look, check out our MCP to-do list example app or B2B MCP OKR manager example app see how the OAuth flow code is structured and executed between MCP client and server.

Scalable, secure auth for AI agents



OAuth 2.0 Dynamic Client Registration unlocks scalable, secure, and automated onboarding for AI agents in the MCP ecosystem. By enabling AI agents to register themselves at runtime and request delegated access via OAuth tokens, MCP servers can eliminate the bottlenecks of manual registration, gain strong OAuth security posture, and create a frictionless agent experience.

If you’re building an MCP server or AI integrations, Dynamic Client Registration, along with several other core OAuth flows, is a foundational requirement for secure, scalable agent authentication.

OAuth for your MCP servers

Stytch Connected Apps provides everything you need to make your MCP server OAuth-compliant and ready for secure agent registration out of the box, including full support for Dynamic Client Registration and OAuth 2.1 flows.



With Connected Apps, you don’t need to reinvent the wheel when it comes to OAuth infrastructure. Stytch takes care of the heavy lifting so you can focus on building great agentic experiences.



Here’s some of what Stytch provides out of the box:

Core OAuth 2.1 specification

Dynamic Client Registration

Authorization Server Metadata

Custom Scopes based on Resources/Actions granted as permissions to end users

End user and IT Admin management of granted consent

Thinking about integrating MCP into your stack? Want to build secure agentic experiences without owning every piece of auth infrastructure?

Contact us for a demo or sign up and check out our MCP quickstart guide.



---


# The best authentication services in 2025
Source: https://stytch.com/blog/best-authentication-services/

The best platforms today go beyond simple authentication methods — they need to offer multi-factor authentication as well as enterprise-ready features like Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), OAuth-based third-party app integrations and even fraud prevention technology like bot detection. 

This article will cover the key features and qualities to look for in a modern authentication service.

Authentication services provide a prebuilt set of tools that you can use to secure your websites, apps, and internal tools.

The best platforms today go beyond simple authentication methods — they need to offer multi-factor authentication as well as enterprise-ready features like Single Sign-On (SSO), System for Cross-domain Identity Management (SCIM), OAuth-based third-party app integrations and even fraud prevention technology like bot detection. 

This article will cover the key features and qualities to look for in a modern authentication service.

What makes an authentication service the "best"?

The best authentication service will balance developer experience with enterprise features, security, reliability, scalability and usability while meeting the unique requirements of your project. This may include additional enterprise features, integration with your existing tools and platforms, and legal compliance.

Developer experience

The developer experience (DX) of an authentication service can make or break its reputation. Services that are frustrating to use rarely do well when better choices exist.

A good authentication service will provide easy-to-use and well-documented APIs and SDKs, with developer-specific support channels like forums and helpdesks. Multiple integration options should be provided, including:

API-first architecture with REST  endpoints for full control over authentication logic and integration into any stack

Frontend and backend SDKs for the languages and frameworks you use (e.g. React, Next.js Python, Go, Node.js)

Headless options for customizing authentication flows

Pre-built UI components like customizable login forms or ready-made authentication flows

Infrastructure-as-code support with Terraform 

Event log streaming and integrations with observability tools like DataDog 

The more functionality an authentication service provides, the less you have to build, maintain, and audit.

Enterprise features

The best authentication services for enterprise use cases should include:

Single sign-on (SSO): Typically implemented using SAML (Security Assertion Markup Language).

Just-in-time (JIT) provisioning: When a user first logs in, a user account gets created on the fly.

System for cross-domain identity management (SCIM): A central Identity Platform (IdP) manages users. When a user is added or deleted from the IdP, accounts are created or removed/disabled across all applications.

Organization tenancy: Most enterprises require the ability to set different login methods or security policies for different organizations.

Machine-to-machine (M2M) authentication: An enterprise-grade authentication service needs to allow different services to communicate and authenticate with each other, not just users. This is usually done using OAuth or API keys.

Embeddable admin portal: Allow your customer's to self-manage their users auth settings and their roles directly within your application, rather than relying on your engineers to do it.

AI agent authentication: The explosion of AI agents doing tasks on behalf of users means that modern authentication services need to be able to authenticate agents and distinguish them from bots.

Role-based access control: This can include the ability to assign roles like administrator, user, or viewer, or to set rules based on things like department or region using custom permissions to limit who can access what resources.



Security

A secure authentication service should protect your users and your organization against attacks like brute forcing, man-in-the-middle attacks and social engineering. A secure authentication service should include:

Fraud prevention and bot detection

A secure authentication service will use logging and monitoring to record details on your users (such as common locations and devices), and require extra layers of MFA if the login looks suspicious.

It will also detect potential bots by rate-limiting logins from the same IP addresses or using CAPTCHAs. However, as fraud techniques have become more sophisticated, involving humans and bots working in tandem, basic bot detection is no longer enough to keep your application secure.



To solve this issue, more advanced techniques such as device fingerprinting are now required, to detect malicious actors who aren't bots. Device fingerprinting means generating a complex identifier for each device that interacts with your application that is stable and can persist across changing sessions and networks.

Multi-factor authentication (MFA)

Allows your users to verify themselves using multiple factors. Common examples are a password and a one-time password (OTP) or a time-based one-time password (TOTP) from an authenticator app.



Compliance and regulations

Your chosen authentication solution should also be compliant with regulations like GDPR, HIPAA, or CCPA. Adhering to one of the major cybersecurity frameworks (like ISO 27001 or SOC 2) is also a good way to show your users that you're committed to security and regulatory compliance.

Reliability and scalability

The performance of an authentication service is critical, and any latency it adds should be minimized. The availability of the service is also key, so check out the availability SLAs for each provider that you're considering. It should also be able to meet demand: scalability is a key benefit of adopting SaaS tools rather than hosting and maintaining your own infrastructure.

Many modern providers now offer transparency over their uptime and past incidents with a status page. You should also investigate their level of customer support, how well it can scale (or handle traffic spikes), and its approach to redundancy and failover protection.

User experience

Users may be driven away if your application is not intuitive to use, or if it makes them jump through too many hoops to sign up and log in. Inconvenient authentication can also encourage users to try workarounds. For example, forcing users to create an account for your site rather than using a social login can promote password reuse, or in enterprise environments, frustrated users may turn to account sharing. 



Authentication services with good UX should offer:

Customizable UX and auth flows: A full toolkit of APIs, SDKs, and pre-built UI components will make the process of building the ideal UX or authentication flow much easier.

Frictionless login options: such as single sign-on, OAuth, and passwordless authentication (including passkeys) makes your apps easier to use while encouraging security best practices from your users.

Seamless troubleshooting: You also want to be able to offer support to your users if they experience issues using your app. An authentication service that allows you or your support staff to securely impersonate a user will make handling any customer issues much smoother.



How to choose the best authentication service

To work out which authentication services will be best for your business or project requirements, you should make the following assessments:

Who are your users and how should your business and technical architecture support their expectations?

In addition to robust security and scalability, when choosing authentication solutions for customer-facing B2C apps, you should focus on features that make it as easy as possible for users to onboard and login. This includes social login methods using accounts your users already have (for example, Facebook and Google) and passwordless authentication.

For B2B and enterprise organizations, multi-tenant applications must support per-organization settings, so you can tailor your authentication policies to each tenant. For example, one customer might require SAML-based single sign-on, while another prefers a combo of passwords and TOTP for MFA, and yet another might want to restrict access by email domain.

An example of how Stytch allows authentication methods to be set on a per organization basis is shown below.



Role-based access control (RBAC) is also vital in enterprise, protecting sensitive resources by granting users and services access to only the data and functions they require to perform their roles. In order to stay compliant with regulations, you'll also need audit logs, and if you're dealing with sensitive data, you may need your authentication provider to offer an on-premises solution.

This should also be paired with fraud and risk prevention strategies. You'll need your authentication service to detect bots and malicious humans, by intelligently detecting devices and applying security rules and rate limits to anything deemed suspicious.

You may have a hybrid use case that spans both B2C and B2B (Slack, Figma, or Notion, for example), in which case your solution will need to provide a versatile feature set that can cover different user segments. If you have both a single-user tier and an enterprise tier, you may need to think about RBAC, or about different accounts for individual users vs organizations, or how a single user can be a member of multiple organizations, as below:



Do you need to comply with GDPR, HIPAA, or other data regulations?

On top of strong security measures such as encryption and MFA, you may need to implement specific security technologies and processes to comply with user privacy regulations such as GDPR, CCPA, and HIPAA. There are also industry-standard certifications that may need to be met, such as ISO 27001 or SOC 2. Some extra features that you may need in order to meet these standards include RBAC, audit logging, and data processing agreements (DPAs). It's worth noting that most major authentication providers offer pre-signed DPAs.

For industries that deal with highly sensitive data, you may need to be able to choose which region your data is hosted in, or be able to self-host your full software stack (either in your own private cloud or on site so that you can remain fully responsible for it). This is especially important with privacy frameworks that give users the rights to redact and correct their data, as you can ensure that their requests are met in full.

Do you need to self-host or do you prefer a solution managed by experts?

When answering this, consider:

Compliance and responsibility: Does your industry require that certain user data be stored on-premises, or within a specific geographic region?

Performance: Do you have specific, very low-latency performance needs that you'll need to manage yourself, or will a managed service be good enough?

Cost: You'll want to compare the infrastructure and maintenance costs that come with self-hosting with the annual subscription cost of a managed authentication service.

How much do you value your developers' time (and sanity)?

An auth service that's easy to integrate with clear documentation (ideally with code examples!) and good customer support channels will be faster and less frustrating for your developers, leading to a more reliable product.

An authentication service will be easier to integrate if it provides the different developer tools and integration methods your team needs. It's worth checking upfront which developer tools each provider offers (e.g., APIs and SDKs for your chosen languages, admin dashboards, or pre-built UI components), and which integration methods they offer (e.g., front-end, back-end, hybrid, mobile, or microservices). That way, you can choose one that covers all your needs.

You should also ask your development team whether they need maximum code control (in which case an API-driven solution with SDKs for their chosen languages will be a must), or whether they prefer to use plug-and-play login widgets (this choice might be more popular for teams with fewer engineers, or that want to release a prototype quickly).

Best authentication services for 2025

When comparing the top authentication services available in 2025, you should consider their target use cases, key features, user experience, and developer-friendliness. Below are some popular authentication services to consider:

Stytch

The Stytch authentication platform provides developers with the tools to build seamless authentication experiences across multiple devices and platforms for any kind of application including B2B and Consumer. It's developer-friendly and was designed with an API-first approach.

Stytch is scalable and quick to implement, and it has comprehensive documentation and examples for the API, including multiple back-end and front-end SDKs. Stytch can be integrated with any IAM solution that supports industry-standard protocols, making it highly flexible.

Key Stytch features

API-first approach with multiple integration options

Fraud & Risk Prevention features like bot detection and device fingerptining

High reliability and uptime

Purpose-built APIs for both B2B and Consumer auth

AI agent authentication with OAuth support

Developer support: First-class developer support with comprehensive documentation, SDKs for multiple languages and developer-focused tooling.

Auto-deduplication of users

Provider failover for highly available delivery of SMS and email



Auth0 by Okta

Auth0 by Okta offers pre-built solutions, such as its universal login to assist with implementation, and it offshores all auth flows onto Auth0 servers, meaning you don't have to manage any of it. It's easy to use, is highly configurable, and has a comprehensive dashboard. It also offers enterprise features like SCIM and M2M authentication; however, it can be expensive, and the cost scales rapidly as you add more users and features.

Features such as SSO, social logins, MFA, and M2M authentication are provided out-of-the-box, at the expense of flexibility, as you are unable to completely customize your own authentication logic. However, you do still have some level of control over parts of it (through its actions and other dashboard functions). The pre-built authentication flows can save time for under-resourced teams; however, they can also lead to issues like extra latency or vendor lock-in.

Key Auth0 features

Universal login across platforms

Social and enterprise logins

Single sign-on

RBAC

Secure API access using OAuth 2.0

Amazon Cognito

Amazon Cognito integrates well with other AWS services, such as Lambda, API Gateway, and S3. It's also the cheapest authentication service to get started with, being free for up to 50,000 monthly active users. It does, however, require a lot of work to implement, and it is heavily AWS centric, which may promote vendor lock-in.

Key Amazon Cognito features

User pools to manage users and authentication

Identity pools for managing authorization or granting temporary IAM roles

MFA

Social and enterprise logins

Customized authentication flows triggered by Lambda

Firebase 

Firebase Authentication is great if you want fast integration with mobile/web apps without having to manage authentication logic on the back end. It offers cross-platform support with iOS, Android, and Flutter, and it scales to millions of users since it's backed by Google Cloud's infrastructure. It offers a free tier, which is useful for startups and new projects with a lower initial budget.

However, Firebase Authentication is limited in scope and generally unsuitable for use cases outside of consumer mobile and web apps, such as server-to-server authentication or enterprise authentication, as it doesn't have built-in support for advanced identity management like SAML, or on-site directory sync.

Key Firebase Authentication features

Tightly integrated with the Firebase ecosystem

Designed to integrate into front-end projects easily

Offers multiple authentication methods

Uses automatic session handling to manage tokens and user state across sessions with minimal back-end setup

Clerk

Clerk is designed to work with Next.js (and includes fully pre-built UI components). It's easy to use with features like session management built-in, which includes robust session handling without any extra setup required. Due to its focus on Next.js and assisting front-end developers, it can be difficult to use with other frameworks (or back-end authentication), and it seems less well-designed for larger enterprise projects, offering fewer enterprise features than some other providers. It can also become quite expensive once you start scaling to larger numbers of users.

Key Clerk features

Next.js focused

Pre-built, customizable UI components for sign-up, sign-in, and account management

User management for consumer apps, including session management, user profiles, and RBAC

REST API support

Keycloak

Keycloak is a self-hosted, open-source authentication service, and it is highly scalable and customizable, giving you full control over data and configurations. It has Active Directory integration and can also act as an IAM in addition to being an authentication provider. Keycloak's biggest advantage is also its biggest weakness: for organizations that don't need full control of their infrastructure, self-hosting takes more time to implement and requires significant responsibility for the security of the system, as well as ongoing maintenance and hosting overheads.

Key Keycloak features

Open source

Self-hosted

Can act as an IAM, giving SSO, OAuth2, OpenID Connect, and SAML support

Offers fine-grained RBAC

Comparison of the best authentication services

The below table summarizes the authentication services compared above.



Ultimately, the best authentication service depends on your requirements, as well as your future requirements!

Future-proof authentication for your application

Stytch offers a developer-friendly, flexible, API-first authentication service that can be used to secure both customer-facing apps and enterprise services in a single platform.

Contact Stytch sales to talk about what kind of authentication is best for your use case, or sign up free and try Stytch now.



---


# What is a SAML service provider? How to integrate your app with enterprise Single Sign-On
Source: https://stytch.com/blog/what-is-a-saml-service-provider/

A SAML service provider is a key component of enterprise single sign-on authentication, allowing businesses to integrate your app into their existing authentication system. SAML enables the link between an identity provider and different service providers by sharing authentication information in a standardized format. 

Adding SAML support to your enterprise app or service can greatly broaden its potential user base, and it is a key requirement for many businesses seeking new SaaS tools. This article explains SAML and what you need to implement a SAML service provider.

A SAML service provider is a key component of enterprise single sign-on authentication, allowing businesses to integrate your app into their existing authentication system. SAML enables the link between an identity provider and different service providers by sharing authentication information in a standardized format.

Adding SAML support to your enterprise app or service can greatly broaden its potential user base, and it is a key requirement for many businesses seeking new SaaS tools. This article explains SAML and what you need to implement a SAML service provider.

What is SAML?

The SAML (Security Assertion Markup Language) standard defines how an identity provider (IdP) and a service provider (SP) communicate using XML markup. It is not a mechanism of authentication, but the language used to send and receive authentication information between systems.

By enforcing a standard of communication, SAML allows different services to exchange authentication and authorization data, which is used to implement enterprise single sign-on (SSO).

SAML Service Provider (SP) vs Identity Provider (IdP)

The two services that communicate using SAML are the identity provider and service provider:

A service provider is any app you are logging into using single sign-on where authentication is handled by an identity provider. They receive authentication and authorization information from the identity provider in the SAML format. Access control is performed by the service provider using information provided by the identity provider.

The identity provider handles the authentication of the user, storing their identity and login data and, having successfully authenticated it, communicating it to the service provider using SAML. It only supplies information to the service provider, and while this can include authorization decisions, it is generally up to the service provider whether a user authorized based on the SAML data.

To exchange data using SAML, both the service provider and identity provider must specifically support it. While SAML is a legacy standard, it is still widely used in modern authentication tools and systems.

If you are targeting a business use case, adding SAML service provider functionality to your software product is vital; many established organizations will already be using SAML-based single sign-on with a variety of other products, so being “plug and play” with their existing infrastructure will drive adoption.

When do you need SAML?

Organizations need their employees to be able to securely log in to a variety of services using SSO. To meet this requirement, your products can act as a SAML service provider so that they are able to connect to your clients' identity providers and integrate with their authentication infrastructure.

Popular enterprise identity providers that are used to manage access to different tools and platforms include Okta, Microsoft Entra (formerly Azure Active Directory), and Google Workspace.

Some example scenarios of using SAML for enterprise SSO include:

Salesforce (SP) + Okta (IdP): Employees at a company use their Okta credentials to log in to Salesforce so that they don't need to remember a separate password.

Slack (SP) + Azure AD (IdP): A global enterprise enables employees to access Slack using their Microsoft work accounts via Azure Active Directory, providing seamless logins across their Windows domain and mobile devices.

Your app (SP) + Your client’s SSO IdP: Your SaaS application needs to integrate with whichever IdP your clients are using. Implementing a SAML service provider accomplishes this, allowing their employees to log into your app using their existing work accounts.



You can implement SAML authentication in your application yourself; however, development teams are increasingly relying on authentication as a service (AaaS) to handle all of the authentication in their applications. This approach simplifies the process of making your application a SAML service provider while providing increased security and reducing development and hosting overheads.

Consumer-focused apps that don't target business use cases are less likely to require SAML, instead relying on social logins to authenticate users using their accounts from popular platforms (for example, Google or Facebook). Embedded logins are becoming increasingly popular for this, keeping users within your application and giving your full control of their login experience.

What happens when a user logs into a SAML service provider?



SAML is an open standard format based on XML that allows identity providers and service providers to exchange authentication info. It achieves this using the following elements:

Metadata: SAML metadata is exchanged to establish trust between service providers and an identity provider, and it includes information such as supported bindings, security certificates, and endpoint URLs.

Assertions: Messages from the identity provider containing the information the service provider needs to identify a user.

Bindings: The mechanism used to transmit messages; for example, HTTP POST requests/redirects, HTTP artifacts, and SOAP (a lightweight transfer protocol).

Protocols: The SAML standards being used to communicate data. There are several different protocols targeting different use cases (such as different authentication flows).

SAML profiles describe how all of the above are combined for a specific use case; for example, web-browser SSO. There are two authentication flows that can be implemented with SAML:

SP-initiated: The user accesses the service provider, and the application initiates the authentication flow, redirecting to the IdP.

IdP-initiated: The user logs into the identity provider service directly, which then navigates to the service provider once they are authenticated.



SAML service providers as part of an enterprise authentication solution

SAML-based authentication is usually mixed with other security technologies in enterprise environments. It is important to understand the different authentication and authorization technologies and their terminology so that you are clear on what you need to do to become a SAML service provider and how your customers will use this functionality.

SAML vs SSO

While SAML is often used to implement single sign-on, it is not synonymous with it and is not the only available SSO technology.

SAML vs OIDC

OICD (OpenID connect) is a modern alternative to SAML for transmitting authentication information. It uses JSON instead of XML and is less complex to configure. As SAML is still widely used in enterprise and supported in new tools, OIDC does not replace SAML — they are simply alternative technologies, and tools may support one or both.

SAML vs OAuth

SAML and OAuth (Open Authorization) serve separate purposes: While SAML is primarily concerned with authentication (though it does have limited scope for authorization data), OAUTH deals only with authorization and provides a more extensive mechanism for in-house and third-party software to authorize without having to exchange identity data. While OAuth and OIDC are often used in tandem, SAML and OAuth can also be used together in enterprise SSO where external tools also require authorization.

SAML vs LDAP

LDAP (lightweight directory access protocol) are different technologies for exchanging data with different purposes that can be used in conjunction. LDAP is a protocol for managing user information, which may be stored on a system acting as an identity provider in a SAML-based SSO solution.

SAML vs SCIM

SCIM (System for Cross-domain Identity Management) is a standard protocol for synchronizing information about users and groups between services providers and identity providers. SCIM does not perform authentication or authorization, but it can complement SAML by ensuring that user and group information is propagated between services whenever changes are made.

Turning your app into an SSO-ready SAML service provider

A SAML service provider and identity provider are not the only way to implement SSO. When choosing how you will build your SSO integrations, you should consider what your enterprise customers expect and how your app functions.

Your customers' identity providers: Assess which identity providers are already deployed for your target industry. Do the IdPs you need to integrate with (for example, Windows Active Directory) only support SAML, or do they support other authentication protocols that may be more suitable?

Your authentication solution: Is there a readily available way to add SAML support to your existing authentication? Does it support other protocols that may be required in the future (such as OIDC for authenticating third-party SaaS apps, or SCIM for synchronizing data)?

Once you have set requirements, you can work on implementing the SAML standard in your apps. Doing this in custom code is a significant undertaking that comes with security risks, and even leveraging libraries such as node-saml and python3-saml requires care, as even small mistakes can result in a significant security vulnerability.

Building your own authentication and authorization infrastructure means taking full responsibility for its ongoing maintenance and security. This is why many development teams are turning to authentication platforms that provide advanced security mechanisms that help to stop sophisticated attacks from bots and malicious users, without having to hire their own in-house security experts.

By building your app with the Stytch authentication platform, you get full support for SAML, OIDC, SCIM, and OAuth for SSO. Stytch bridges the gap between compatible authentication components and user-facing services, as well as machine-to-machine authentication, for a single, comprehensive solution for all of your internal and customer-facing authentication requirements.

Protecting this is an evolving array of protection features, including device fingerprinting, bot detection, and AI-powered behavior analysis. Stytch also includes additional functionality including a web-based management dashboard, audit logging, and a variety of log-in methods to streamline your authentication process.

Contact sales or get started to find out how Stytch can secure your enterprise platforms.






---


# Building an MCP server with OAuth and Cloudflare Workers
Source: https://stytch.com/blog/building-an-mcp-server-oauth-cloudflare-workers/

This article will guide you through how to secure a Model Context Protocol (MCP) server with OAuth for authentication. MCP builds on the robust and widely adopted OAuth standard, allowing users to log in, review requested permissions, and explicitly authorize agents to act on their behalf.

We’ll explore a full-stack app with a REST API and an MCP server that uses OAuth for authentication and dynamic client registration to connect to an MCP client—all powering a simple todo list application that’s accessible to both users and AI agents.

This article will guide you through how to secure a Model Context Protocol (MCP) server with OAuth for authentication. MCP builds on the robust and widely adopted OAuth standard, allowing users to log in, review requested permissions, and explicitly authorize agents to act on their behalf.

We’ll explore a full-stack app with a REST API and an MCP server that uses OAuth for authentication and dynamic client registration to connect to an MCP client—all powering a simple todo list application that’s accessible to both users and AI agents.



Want to explore the codebase first? You can check out the full repo on GitHub.

MCP authentication overview



In an MCP setup, AI agents and assistants (MCP clients) need access to the MCP server and the downstream 3rd party service. OAuth is what makes this work: users authenticate with an authorization server which issues tokens (JWTs) that your MCP clients and servers can use to handle the auth flow.

Specifically, the authorization server is what enables a secure, user-consented OAuth flow in MCP. It’s responsible for:

Acting as an Identity Provider

Issuing signed access tokens with embedded claims

Supporting OAuth 2.1 flows (like Authorization Code with PKCE)

Displaying consent screens to users

Dynamically registering MCP clients

Managing token lifetimes, refresh logic, and revocation

And more

For this example app, we’ll delegate authentication to Stytch as the authorization server to manage registered MCP clients and power the OAuth flows with the Connected Apps feature.

Application architecture

The full-stack application architecture consists of three main components:

Frontend: A single-page React app that serves as the todo list interface. It uses Stytch’s JavaScript SDK to render the login form and OAuth redirects.

Backend: A serverless backend that is organized into two layers:

REST API: Built with the Hono framework to handle standard CRUD operations for todo items.

MCP server: Handles requests from MCP clients and interacts with the todo API, using Cloudflare KV for storage and Durable Objects for persisting data.

OAuth authorization server: The MCP server delegates authentication to Stytch, an auth provider. Stytch acts as an external identity provider, powering the OAuth flow—handling login, consent, client registration, and token issuance with the Connected Apps feature.



Both the frontend and backend components of this application can be deployed together to Cloudflare Workers as a remote MCP server.

Before you start

If you want to run the example app on your machine, you’ll need:

Node.js installed

A free Stytch account

Setting up your Stytch account

First, create and configure your Stytch account:

Sign up at Stytch and select Consumer Authentication when prompted

In the Stytch dashboard, navigate to Frontend SDKs and enable the frontend SDK

Navigate to Connected Apps and enable Dynamic Client Registration

Go to Project Settings to retrieve your Project ID and Public Token

Installation

Let's create the project structure:



Update your .env.local file with:



Update your .dev.vars file with:



Start the local development server:



Your application will be running at http://localhost:3000.

Testing with the MCP Inspector

To test your MCP server, use the MCP Inspector as an MCP client:



This will start an interactive session where you can connect to your MCP server at http://localhost:3000/sse.

To run through the full end-to-end flow:

Click Connect to initiate the connection to your MCP server

Authenticate using an email one-time passcode

When prompted, review and Allow the OAuth consent screen

Open the Tools tab and create a todo list item.



Understanding the project structure

The project is organized into a modular structure that separates the auth layer as middleware that can be reused by both the API and MCP server. Let's examine the key directories and files:



The API routes

In api/index.ts, we define the core application routes. Each route is responsible for a distinct part of the app: the REST API, OAuth discovery, and the MCP server.



Key routing logic:

/api: Hosts the todo REST API. This route is protected by stytchSessionAuthMiddleware inside TodoAPI.ts to ensure only authenticated users can access it.

/.well-known/oauth-authorization-server: Serves OAuth 2.0 server metadata for AI agents and other OAuth clients. This is essential for enabling Dynamic Client Registration (DCR) and initiating Authorization Code flows.

/sse: Reserved for MCP client connections. We first apply stytchBearerTokenAuthMiddleware to enforce that all agent requests include a valid OAuth Bearer token. We then mount the TodoMCP Durable Object, which implements the MCP protocol and routes agent tool calls to the correct backend logic.

/: Serves the React frontend app.

Todo API with Hono

The Todo API at api/TodoAPI.ts is a small RESTful interface for managing the todo list, primarily used by the React frontend. It uses Hono, a minimalist web framework, to define routes.

Key routes and behavior in TodoAPI.ts:

GET /todos – Fetch the current list of todos for the user.

POST /todos – Create a new todo item.

POST /todos/:id/complete – Mark a specific todo as completed.

DELETE /todos/:id – Delete a specific todo.

Each route is protected by authentication middleware and then invokes the business logic via the Todo service. For example, the GET and POST routes look like:



As shown above, we attach stytchSessionAuthMiddleware to ensure only authenticated users can hit these endpoints (more on this middleware soon).

The Todo service api/TodoService.ts encapsulates all the logic for managing todos in storage. Both the REST API and the MCP server use TodoService under the hood, ensuring consistent behavior. For example, the add method loads existing todos then pushes a new item and saves back to KV:



MCP server

The MCP server api/TodoMCP.ts extends our app’s functionality to MCP clients with @modelcontextprotocol/sdk. MCP defines how an AI agent can discover a server’s capabilities and invoke “tools” or access “resources” on that server​, which in this case is managing todos.

Inside TodoMCP.ts, we define the MCP interface in terms of:

Resources – We expose the collection of todos as a resource called "Todos". This allows the agent to list all todo items and retrieve details of a specific item by URI.

Tools – Discrete actions the agent can perform, analogous to API endpoints. We define three tools using server.tool():

createTodo – Adds a new todo. Expects a todoText string as input.

markTodoComplete – Marks a todo as complete. Expects a todoID string.

deleteTodo – Deletes a todo by ID.



In the above code from, we see the resource named “Todos” being defined with a URI pattern todoapp://todos/{id} and two handlers: a list handler to enumerate all todo resources, and a resource handler to get a specific todo. This means an agent can ask “what resources do you have?” and discover each todo as a resource with a unique URI.

Then we define three tools: createTodo, markTodoComplete, and deleteTodo. Each tool includes a human-readable description (so agents can understand its purpose), an input schema (for validation), and an async handler that delegates to the TodoService. This tool-based interface lets the agent know exactly which actions it can perform on the user’s todos and how to structure those requests.

The call to this.todoService is important: it’s initialized using the authenticated user’s ID, derived from this.props.claims.sub. That claim comes from the verified Stytch OAuth JWT, and is also used to namespace keys in Cloudflare KV (e.g., user:abc123:todos) ensuring that data is scoped to the user who granted consent.

Auth middleware with Stytch

To ensure that only authorized users and agents can access the application, we define two Hono middleware functions in api/lib/auth.ts. Both rely on verifying JWTs issued by Stytch—one for browser-based sessions and one for OAuth-based agent access.

When a user logs in through the React app using Stytch, a session JWT is stored in a cookie called stytch_session_jwt. This token proves the user's identity in subsequent API requests.

The stytchSessionAuthMiddleware checks for this cookie and verifies the token:



If the token is valid, we store the user’s ID (sub) in the request context so it can be accessed later by the API. If it's missing or invalid, the request is rejected with a 401. The validateStytchJWT function (defined below in the file) does the heavy lifting of JWT verification.

When an AI agent connects to the MCP server, it authenticates using a Bearer token in the Authorization header. This token is issued by Stytch’s Connected Apps flow, after the user consents.

The stytchBearerTokenAuthMiddleware verifies the token like so:



The decoded claims (including the user ID) are stored in the Durable Object’s execution context. These claims are later accessed inside the MCP server as this.props.claims.

Both middleware functions rely on the shared validateStytchJWT function, which uses the jose library to validate JWTs using Stytch’s public keys:



This function ensures that:

The token was issued by Stytch for the correct project

The signature matches Stytch’s public key (fetched from their JWKS endpoint)

In api/index.ts, these middleware functions are applied to the appropriate routes:



This setup ensures that:

All REST API requests come from authenticated users

All MCP connections come from agents that have a valid access token (issued with the user’s consent)

OAuth flow in the codebase

Now that you’ve seen how the core backend components of the application are structured, let’s walk through how the OAuth flow is implemented with Stytch and MCP.

Here’s a high-level overview of how the MCP OAuth flow operates:

Discovery: The MCP client fetches the OAuth metadata to locate Stytch authorization server endpoints

Registration: MCP client dynamically registers itself with Stytch with Dynamic Client Registration

Authorization: Stytch redirects the user to the authorization endpoint for consent

Token exchange: After consent, the MCP client exchanges the authorization code for access and refresh tokens

MCP connection: MCP client connects to the MCP server using the OAuth access token as authentication

1. OAuth Metadata discovery

In api/index.ts, the app serves a discovery document which returns metadata about the OAuth authorization server at /.well-known/oauth-authorization-server, which tells MCP clients where to:

Redirect users for consent /oauth/authorize

Exchange codes for tokens {stytch-url}/oauth2/token

Register clients dynamically {stytch-url}/oauth2/register



2. OAuth consent screen and authorization

On the frontend, in src/Auth.tsx, the /oauth/authorize route is handled by Stytch’s <IdentityProvider /> component, wrapped with a login check:



When an MCP client initiates the OAuth flow, it redirects the user to this route with standard query parameters (client_id, scope, redirect_uri, code_challenge, etc.). The <IdentityProvider /> component reads these values and renders a consent screen, allowing the user to approve the MCP client’s access.



Behind the scenes, the MCP client registers itself as an OAuth client with Stytch Connected Apps at the Dynamic Client Registration endpoint {stytch-url}/oauth2/register.



Once the user grants consent, Stytch redirects back to the MCP client with an authorization code. The MCP client captures this code and exchanges it for access tokens by making a request to the endpoint {stytch-url}/oauth2/token.

3. MCP authentication via bearer token

The MCP server enforces bearer token authentication via middleware. When an MCP client connects, it must present a valid OAuth token in the Authorization header:



These tokens are used by the MCP client to authenticate future requests to the MCP server, enabling secure, delegated access.

Summary of the MCP OAuth flow

Below is a quick reference to where each part of the flow is implemented in the codebase:



OAuth for your MCP servers

In this walkthrough, you’ve seen how to secure a Model Context Protocol (MCP) server using OAuth 2.0—enabling AI agents to access user data in a structured, permissioned, and secure way.

While it’s possible to build this OAuth infrastructure from scratch, Stytch Connected Apps provides everything you need to make your MCP server OAuth-compliant out of the box.



With Connected Apps, you don’t need to reinvent the wheel when it comes to OAuth infrastructure. Stytch takes care of the heavy lifting so you can focus on building great agentic experiences.

Here’s some of what Stytch provides out of the box for MCP authentiaction:

Core OAuth 2.1 specification

Dynamic Client Registration

Authorization Server Metadata

Custom Scopes based on Resources/Actions granted as permissions to end users

End user and IT Admin management of granted consent

Thinking about integrating MCP into your stack? Want to build secure agentic experiences without owning every piece of auth infrastructure?

Contact us for a demo or sign up and check out our MCP quickstart guide.






---


# Home
Source: https://stytch.com/home

APIs and SDKs to integrate authentication and security into your app.



---


# Pricing
Source: https://stytch.com/pricing

Build modern authentication in minutes with simple and flexible pricing that scales with your business. Get rewarded as you grow with Stytch today!



---


# Contact
Source: https://stytch.com/contact

Contact Stytch



---


# Competitor page - Auth0
Source: https://stytch.com/stytch-vs-auth0

Build auth that feels native to your app and proactively removes fraud and abuse.



---


# Stopping fraudsters at signup
Source: https://stytch.com/customer-stories/replit

Learn how Replit stopped fake account creation thanks to fraud prevention from Stytch.

Replit is an AI-powered platform that is accelerating software development and deployment for millions of engineers. They make collaboration efficient, easy, and enjoyable, helping modern developer teams build, troubleshoot, and ship faster than ever before.

AI companies are a common target of fraud and abuse because of the valuable resources they provide, and Replit was no exception. When they came to Stytch, they faced a serious multiple account abuse problem, where they were constantly being hit by large waves of automated sign-ups.

But thanks to fraud prevention from Stytch, Replit can now identify and stop these bad actors before they even create accounts, stopping abuse at sign-up and protecting their platform from all kinds of fraud downstream.

Challenge

In addition to its paid tiers, Replit offers a free tier that provides some hosting/compute resources. While these resources are intended to give new Replit customers the chance to test out the platform, they are also common targets for bad actors to abuse in a number of ways, from crypto-mining to running phishing attacks. Replit’s anti-abuse engineering team realized that the most effective way to stop these various kinds of attacks was to stop them at signup.



Solution

Stytch impressed Replit with our customer support, our high fidelity fraud prevention solution, and Stytch’s clear willingness to work with Replit as a true collaborator. They needed a team that would be available for collaboration and open to suggestions for future evolutions – and Stytch delivered.

In addition to the support Replit received from Stytch’s Solutions Engineering and Developer Success teams, the efficacy and precision of the product have made a big difference in how the Anti-Abuse team spends their time. Because they can trust in Stytch’s recommended verdicts, and have access to additional insights about signup attempts, stopping a huge volume of fraud is now off their plates.



Results

With such a bulwark of fraudsters stopped before they can even access the app, Replit is able to focus on more gray areas of fraud that only grow in complexity and number as the company scales.

Reduced abuse: The first set of block verdicts immediately validated Replit’s investment in Stytch’s fraud prevention solution. With a sizable number of signup attempts blocked and trust in the precision of Stytch’s product, their anti-abuse team can prioritize their resources for tackling more challenging forms of abuse.

Easy integration: The anti-abuse team appreciated how easy it was to get fraud prevention up and running. By just following the docs, they were able to get up and running smoothly.

Room to grow: Replit was able to see a major impact on their fraudulent traffic. As they ramp up their anti-abuse efforts, they’re glad to know Stytch’s product can be leveraged at other key touchpoints that are vulnerable to attack.

The bottom line

As Replit has recently expanded their product to include more collaborative features like Teams, they appreciate having a fraud prevention solution that can grow and adapt with them. With Stytch guarding the front door, Replit can protect their resources while still delivering a safe, seamless user experience to their customers.

What can Stytch do for you?

Jump into the Stytch Docs to learn more about our B2B auth solution — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum, or email.

---


# SEM LP: Auth0
Source: https://stytch.com/lp/auth0

Build auth that feels native to your app and proactively removes fraud and abuse.



---


# B2B Authentication 
Source: https://stytch.com/b2b

Increase conversion, security, and usability with Stytch's authentication platform, SDKs, and API. Easy to use — get started in minutes.



---


# Clearbit accelerates development by replacing in-house auth with Stytch
Source: https://stytch.com/customer-stories/clearbit

Learn how Clearbit (acquired by HubSpot), a B2B data intelligence company, accelerated development by replacing in-house auth with Stytch.

Clearbit, acquired by HubSpot, is a data intelligence company that uses AI to provide B2B companies with powerful, contextual insights about their customers and prospects. Last year, Clearbit migrated from authentication infrastructure that was built and maintained in-house to Stytch’s B2B auth solution.



Auth evaluation criteria

As Clearbit grew, their in-house auth system struggled to keep up with the demands of their expanding business. It was requiring more and more engineering resources to maintain and support authentication against a growing list of requirements. Seeking alternatives, Clearbit had two main goals:

Enhance their onboarding flow to support a new product-led growth (PLG) motion, providing a secure mechanism for users to easily sign up, integrate their CRM, and collaborate with teammates, without also letting in an influx of spam

Support the increasingly complex demands of enterprise customers that their in-house system didn’t cover, including more robust single sign-on (SSO) capabilities, auto-provisioning of accounts, and custom settings per organization

They needed the control and flexibility of an in-house auth solution, but the cost-predictability, scale, and domain expertise of a third-party provider. Clearbit also wanted to ensure their next solution would cover their authentication and authorization needs not just in the near term, but for years to come.

In their vendor evaluation, Clearbit found that Stytch’s comprehensive solutions for enterprise-grade B2B multi-tenant auth were uniquely suited to tackle these goals. And when Clearbit was acquired by Hubspot mid-integration, causing priorities to shift rapidly, Stytch was able to ensure that Clearbit had the support they needed during the pivot, including adding Hubspot OAuth on a tight timeline.



Why Clearbit selected Stytch

Stytch not only met Clearbit’s core requirements for scale, operational support, and authentication methods, but it also stood apart by offering:

Native multi-tenant architecture for granular control of enterprise B2B auth settings

High-converting, passwordless self-serve onboarding for their new PLG motion

Close partnership and responsiveness from the Stytch team

Built-in device fingerprinting to prevent abuse of their PLG sign-up flow

Reduced engineering maintenance to support custom flows

A future-proof B2B auth flow, with additional features like RBAC built-in



Multi-tenant architecture for B2B auth

Stytch’s multi-tenant architecture provided Clearbit with the infrastructure to easily build and manage key enterprise auth features such as SAML authentication, integration with OAuth providers, and auto-provisioning. Enabling different auth requirements and settings for different customers was simply an API call away via the Stytch platform.

While Clearbit’s previous in-house system had supported basic implementation of features like SSO, Stytch’s B2B SaaS offering dramatically reduced the resources needed to manage these multi-org permissions and features across an increasingly diverse customer base.



Passwordless product-led onboarding

Previously, Clearbit had used traditional password-based auth and needed to deal with the persistent hassle of resets and customer support. Stytch’s support for passwordless organization creation and discovery made it easy for Clearbit to add a product-led onboarding motion to their B2B product.

New self-serve customers could sign up using magic links and CRM-based OAuth logins (e.g. ‘sign in with Hubspot’), and then either ‘discover’ existing an existing organization, or opt to create a new one. This change increased security compared to the previous password-based login flow while also letting customers integrate their CRMs and collaborate with teammates faster than ever before.



Close collaboration and partnership

Clearbit highlighted the Stytch team's responsiveness to their needs and continued support, both during and after integration, as a big win. This ranged in scale from quick one-off questions about user issues to the Stytch team quickly adding Hubspot OAuth capabilities following Clearbit’s acquisition.



Protection from self-serve abuse

In expanding from a more sales-driven motion to accommodate product-led growth, the Clearbit team knew that they would see a dramatic increase in the number of sign-ups. Removing barriers to entry in a PLG motion was an exciting potential source of growth, but it also opened up new avenues for spam and abuse that the Clearbit team wanted to proactively prevent.

Stytch’s device fingerprinting product allowed Clearbit to implement account abuse prevention into their authentication flow without adding user friction, ensuring the move to a product-led growth (PLG) model could be both high-converting and secure.



Reduced engineering maintenance

Stytch’s comprehensive solution and the ability to quickly integrate new authN and authZ features enabled Clearbit’s developers to easily upgrade their auth as needed instead of maintaining their in-house auth systems.

The Clearbit team also valued the additional confidence that came from working with a third-party authentication provider with deep expertise on authentication and security best practices. Rather than having to think through edge cases and security implications themselves each time they needed to make an auth change, the Clearbit team knew that they could rely on Stytch to help them handle every scenario.



Future-proofing support for new features

Clearbit went into their evaluation knowing that they wanted their next authentication provider to grow and scale with them. Stytch’s multi-tenant infrastructure and feature depth gave them the confidence they needed to pick Stytch as a partner for scalable and flexible B2B auth.

Clearbit also appreciated that Stytch’s platform covered additional features, like role-based access control (RBAC), that they may not need right now, but will likely need later. Rather than having to build new systems or add on an additional provider, Stytch will be there when their team is ready.



Relevant Stytch Products Used

B2B Authentication

OAuth Social Logins

Email Magic Links

Single sign-on (SSO)

Organization Discovery

Device Fingerprinting



The Bottom Line

Like any B2B SaaS company, Clearbit is continuously evolving. As Clearbit has grown their enterprise customer base, launched a new product-led growth motion, and now joined forces with Hubspot, change has yielded enormous challenges and opportunities alike.

Throughout these key transitions, Stytch's B2B authentication solutions, designed for multi-tenant environments, consistently helped Clearbit meet the diverse and growing needs of their expanding customer base with a fraction of the engineering resources.



What can Stytch do for you?

Jump into the Stytch Docs to learn more about our B2B auth solution — or sign up for a free account to try them out for yourself. Have questions? Reach out to our Developer Success team.

---


# Migrating millions of users and orgs from Auth0 to Stytch B2B
Source: https://stytch.com/customer-stories/tome

Learn how Tome migrated millions of users and thousands of organizations from Auth0 to Stytch's B2B authentication platform with no customer impact.

Migrating core infrastructure like authentication can feel daunting, especially when your product is celebrated for its UX and millions of users rely on it every single day.



This was the challenge facing Tome, an AI-powered storytelling platform that makes it easy and fast to create, collaborate on, and share engaging and customized presentations. Less than two years after launch, Tome had amassed more than 10 million users, ranging from individuals to large enterprises.



But Tome had a problem: their legacy auth provider, Auth0 was slowing them down.



Issues with Auth0’s documentation, unresponsive support, and unexpected product behavior had caused headaches – and even a production outage – for Tome's engineering team. Determined to find a more reliable and developer-friendly auth solution, Tome ran a comprehensive evaluation and ultimately decided to migrate to Stytch.



Decision criteria for modernizing authentication at Tome

The Tome team found themselves constantly struggling to work around Auth0’s one-size-fits-all product.

While they they needed parity with the core auth methods and features Auth0 provided, they had critical requirements for their next generation auth platform:

Proven infrastructure reliability, with a history of minimal downtime

Architectural alignment with Tome’s multi-tenant customer model

A DX-friendly way to integrate new, passwordless options

Improved customization of the Tome login page for better brand consistency

Address user account linking, which was causing support requests

Address the increasing problem of bots creating new accounts



Selecting Stytch

Stytch not only met all of Tome’s requirements, but was in a unique position to offer:

A zero downtime migration that would result in no user disruption

A developer- first approach with improved DX, documentation and, developer support

A native purpose-built multi-tenant architecture that matched Tome’s own data model

Visibility into changes and more intuitive troubleshooting

UX control that came from Stytch’s fully composable implementation model that offered pre-build UI, frontend headless and backend API and SDKs

Built-in support for secure user account linking

Integrated device fingerprinting to easily prevent spam account creation by bots.



Zero downtime migration

A top priority for Tome during the migration was to minimize user impact. To make that possible, the Tome and Stytch teams collaborated to “dark launch” Stytch sessions into production.

Here’s the concept:

Users login to the product using the existing Auth0 login flow

In the background, create a Stytch session for that user

Verify that downstream traffic to Stytch is working correctly without issues

Flip over to Stytch login flow

With this process, Tome was able to verify that their Stytch implementation was working smoothly, first with 1% of sessions, then 5%, and then have the confidence to scale to 100%, knowing it was all running smoothly. This meaningfully de-risked the migration process and allowed Tome to migrate millions of users in less than a month, with no downtime.

Developer-first approach

Auth0’s documentation and approach to development was often out of date, and delayed responses from Auth0 support was consistently slowing Tome down.

When Tome was launching internationalization support, Auth0 took so long to respond to a question about internationalizing Tome’s login pages that the launch almost had to be delayed. And on another occasion, an Auth0 API that didn’t work as documented caused a production outage. The Tome team was able to put a bandaid fix in place, but they quickly realized that it might be time for a new auth partner.



In contrast, with Stytch, Tome found both up-to-date documentation, and a responsive thought partner. Not only was it quick to get answers to ad-hoc questions in Slack, the Stytch solutions engineering team partnered closely with Tome on solution design and migration planning to ensure everything went smoothly from the start.



Purpose-built multi-tenant architecture

Many of Tome’s users are companies and large enterprises, who need to have shared workspaces to collaborate, with custom roles and permissions.

As a result, Tome constructed their project with a native understanding of organizations – but quickly found that Auth0’s Organizations feature wasn’t engineered to support the org-specific flexibility that the Tome engineering team had in mind.

In partnering with Stytch, Tome was excited to find a company with a similar multi-tenant native approach. This allowed them to streamline their code and eliminate their previous workarounds.

Secure user account linking

Prior to Stytch, Tome offered both Google OAuth (‘log in with Google’) and email/password as options for users. If a user forgot they had logged in with a password previously, then tried to use Google OAuth to log into Tome, they would hit an error page - even if they already had a Tome account with the same email. Users found this confusing and frustrating, but the fix with Auth0 wasn’t an easy one:



By switching to Stytch, Tome not only was able to ditch passwords for good, moving toward a more modern passwordless auth flow, but they also were able to use Stytch’s built-in account deduplication to securely link user accounts - for less user confusion and fewer support tickets, without any additional code.

Intuitive troubleshooting

The Tome team often struggled to understand what was happening under the hood when challenges arose with Auth0. In fact, they often avoided making changes or even adding new features involving auth because they would never know what the downstream effects might be.



With Stytch, it was very different: the docs were up to date, it was easy to ask questions, and Tome's backend integration approach made it easy to isolate outbound requests to Stytch in their observability platform, unlike the 'black box' created by the Auth0 redirect.



UX Control

They also wished they had more control over the login page’s look and feel. With Auth0’s Universal Login, their customization options were more limited.

With Stytch’s API-first approach, Tome had a range of integration options to choose from - all of which provided greater control and visibility.

Tome ultimately decided to use Stytch’s Node backend SDK with a custom front-end. The backend integration, as opposed to their hosted Auth0 modal, improved observability and made it easier for their team to isolate auth-related requests. And they were able to customize the login page to feel consistent with the Tome brand story - complete with their Privacy Policy and Terms of Service. This also allowed Tome to have full control over internationalization, both of their login UI and email templates – the same requirement that had previously delayed a launch when using Auth0.



Integrated device fingerprinting

Tome had growing concerns about the risks of account abuse prevention from bots creating fraudulent spam accounts. Stytch was the only vendor to offer a completely integrated fraud prevention product using advanced device fingerprinting, meaning that Tome would not have to integrate yet another platform.



The future of auth at Tome

Now that Tome has fully migrated to Stytch, they’ve already freed up engineering resources to accelerate their product roadmap.



From new auth methods to user and organization management configurations, it’s all just an API call away for Tome. They have an auth platform in Stytch that will innovate at the same pace as their product and support any future requirements.

And Stytch’s team is busy using Tome to share product features, share internal updates, and provide custom Sales pitches. Reach out to the Stytch team if you’re interested in a personalized Tome presentation on how Stytch can help your company offer flexible & scalable B2B auth.

---


# Competitor page - Cognito
Source: https://stytch.com/stytch-vs-cognito

Build auth that feels native to your app and proactively removes fraud and abuse.



---


# From Auth0 to Stytch in just one week
Source: https://stytch.com/customer-stories/orb

Learn how Orb, a developer platform that's revolutionizing billing, went from Auth0 to Stytch in just one week.

Orb is revolutionizing billing, one invoice at a time. With an end-to-end workflow that covers usage tracking, invoicing, and reporting, they offer a comprehensive platform to help RevOps and Product teams track and bill accurately, transparently, and smoothly.



With Stytch, Orb was able to offer their customers a more reliable and scalable SSO experience, one that could flex as the needs of their customer base evolves.



Orb migrated from Auth0 to Stytch SSO in just one week, all while achieving a higher standard of reliability and performance.



Partnership highlights

Simplicity: With SAML’s extensive list of footguns and vulnerabilities, along with the challenges of scalable SSO in general, Orb appreciated that Stytch abstracted away the tough stuff to make the migration and management easy on their eng team.

Smooth migration: With an auth solution already up and running, Orb needed to migrate off of Auth0 as quickly and painlessly as possible. With Stytch, they were able to migrate over in one week, without their customers any the wiser.

Developer support: Stytch’s documentation, SDKs and online support gave Orb the tools they needed to implement quickly and seamlessly, as well as confidence they were working with a team who understood the needs of their developers.



Stytch products

B2B authentication



Challenge

While Orb knew that Auth0 was no longer the right long-term auth partner for their product, they had a few core requirements as they evaluated alternatives:

Backwards compatibility: Whichever provider they went with Orb needed a smooth migration to make sure that no users would notice a difference. The last thing you need from your pricing and invoice platform is a disruption to access or services.

Session management: Many auth and SSO providers unfortunately still don’t offer session management. Orb needed an identity platform that could handle sessions for them. Building in-house was too resource-intensive, and they wanted the peace of mind that comes with knowing your sessions are managed by a dedicated, expert team.

Maximal simplicity: With a lot of SSO providers, organizations are not built into the authentication data models, requiring extra coding, customizing, and branching paths for the auth customer. Orb was looking for a partner that could effectively abstract any complexity away from the process, so that they could manage different auth SSO requirements for their various customers with minimal lift.



Stytch not only met these expectations, but exceeded them with the dev-centered approach we have taken to all of our resources, from docs to SDKs to our community Slack. It also helped that the way we handle SIEM audit logging and capacity for defining fine-grained role requirements aligned with where they hoped to take their enterprise tier next.



Solution

When it came time to migrate from Auth0 to Stytch, Orb was excited by the way Stytch’s API and SDK designed allowed them to home in on the aspects of auth they really wanted to customize for the sake of their customer base, while making a lot of the trickier configurations as simple as “flipping a bit.” Because of that balance between abstractions and flexibility in the right places, Orb was able to migrate to Stytch in just one week.



Additionally, Stytch doubled down on reliability so Orb could rest easy. After having navigated performance issues with their prior auth provider, Stytch’s guarantees around keeping up with identity providers gave them great peace of mind.



Results

Integrated UI: Stytch’s headless SDKs gave Orb complete control over their own UI, making SSO feel like a integrated part of their product.

Enterprise-ready: SAML SSO is a critical lever for Orb’s growth and upmarket appeal, and with Stytch’s SSO they’re well equipped to meet enterprise product requirements.

Conserved developer resources: No company wants to replace their auth provider – it can be time-consuming and potentially disruptive. But with Orb’s one-week migration and continual support from the Stytch team, they were able to move quickly and get back to building their core product.



The bottom line

When originally launched, Orb’s enterprise-level SAML SSO still required a ten minute onboarding call with the Orb team to configure. Orb is excited to be developing a self-serve experience within the Stytch dashboard, to make SSO and enterprise onboarding even easier on their customers.



What can Stytch do for you?

Jump into our Docs to learn more about our B2B auth solution — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum , or email.

---


# About
Source: https://stytch.com/about

Learn more about Stytch as a company, our team, leadership, mission, vision, values, and career opportunities.



---


# Consumer Authentication
Source: https://stytch.com/b2c

Build consumer authentication that feels like a seamless part of your app.



---


# Fraud
Source: https://stytch.com/fraud

Stop bots, fraud and abuse with industry-leading accuracy



---


# Startup program
Source: https://stytch.com/credits

Info on the deals and credits that Stytch offers for qualified startups hoping to get started with B2B or B2C authentication



---


# Delivered uncompromised UX and improved security with Stytch's backend SDKs
Source: https://stytch.com/customer-stories/delicious-simplicity

Delivered uncompromised UX and improved security with Stytch's backend SDKs.

Delicious Simplicity specializes in contemporary, elegant online assets – from websites to customer emails to applications. As a boutique consultancy, their customers look to them for bespoke, attentive, and beautiful products. But to deliver that, they require a backend stack that is as elegant and streamlined as their frontend designs.



With Stytch, Delicious Simplicity can now offer signup and login experiences as sophisticated and streamlined as the rest of their services, all with minimal time and effort required of their valuable engineering team.



Partnership highlights

Backend-driven tech stack: Combining Stytch’s backend Node.js SDK with their in-house preferred T3 stack (tRPC, Prisma, Next.js), Delicious Simplicity’s auth build was fully typesafe, modular, and resulted in uncannily concise code.

Fine-grained control: By working with Stytch’s backend SDK and API endpoints, Delicious Simplicity retained total code control over their auth events and integrations with other essential backend services like payment.

User management and security: Taking advantage of Stytch's user management, Delicious Simplicity offloaded all of their users' PII data onto Stytch's secure services — alleviating their responsibility of having to worry about data leaks and security.

Owning the UX: With Stytch's composability and flexibility, Delicious Simplicity fully customized the user experience with the signup and login experience without the limits of a drag-and-drop component.



Stytch products

Email and SMS OTP

Device Fingerprinting

Session Management



Challenge

Delicious Simplicity clients come to them for high-touch, tailored, and ultra-contemporary websites and applications. When DS was in charge of the codebase, this was no problem. But with auth, it always required more wrestling and wrangling than they felt should be necessary.



This extra work also bled into extra backend infrastructure. For many of their B2C clients, they found themselves building custom features like event listeners and triggers to keep their backend user data in sync, which they hoped an integration with something as critical as an auth provider would not require. Sure, they could use webhooks (which is the standard suggestion for a lot of auth providers), but again, this risked hurting the user experience: webhooks sometimes fail, and in those cases it required Delicious Simplicity even more developer resourcing to build in failsafes and backups to prevent hiccups for their clients.

Rather than saving time and developer resourcing, these services cut into time the DS team wanted to be spending building their clients’ projects.



Solution

After exploring a few of Stytch’s products and solutions, the Delicious Simplicity team’s eureka moment came when they found the Stytch Node.js SDK. By combining this backend SDK with some of the tools they already relied on to save time and money – T3, tRPC, Prisma – the Node SDK empowered them to build their backend flows in just a few lines of code, and then build the exact user experience they wanted without any compromises or hurdles.

Not only that, but Stytch also took care of the things that DS didn’t want to: simultaneous account and user creation? No problem. Stytch-side storage of personal identifiable information? Easy. Flexible metadata to store custom information for specific kinds of transactions or users? Done.

The best part? How intuitive and fast the Stytch SDK made the build.



Code highlights

Simulteanous account and user creation





Changing a login method

When a user needs to update their login method like a phone number or email, all DS needs are these twelve lines of code:





Authentication at the edge

Another bonus feature of Stytch’s code base is Delicious Simplicity’s ability to use it in middleware for certain routes they want to protect (account paths, certain subscribe paths, etc.) In these instances, the middleware at the edge accesses and authenticates the JWT with Stytch, without anything occurring client-side.





Results

Delighted clients: By freeing up developer time, Stytch gives time back to Delicious Simplicity that they used to take their client’s site to the next level – resulting in innovative features and UI bonbons that continue to delight their readers.

Risk reduction: Between Device Fingerprinting and Stytch-side storage of PII, Delicious Simplicity and their clients don’t have to worry about fraud.

Uncompromised user experience: By leveraging Stytch’s backend Node.js SDK, Delicious Simplicity can build the exact user experience they wanted, no wrangling or wrangling required.

Clean, maintainable, and future-proof code: With Stytch’s fine-grained control of auth, Delicious Simplicity’s codebase is built to last, can be easily updated, and a delight for engineering teams to work with.



The bottom line

With the flexibility and efficiency of Stytch’s Node SDK, Delicious Simplicity can spin up custom auth flows for their clients without sacrificing time or sophistication. In fact, with the time they save on auth, they can devote even more time to setting the standard for what contemporary web experiences can look and feel like.



What can Stytch do for you?

Jump into the Stytch Docs to learn more about our B2B auth solution — or sign up for a free account to try them out for yourself. Have questions? Reach out to our Developer Success team.

---


# Built B2B authentication into their platform in under 2 days
Source: https://stytch.com/customer-stories/mintlify

Built B2B authentication into their platform in under 2 days.

Mintlify is streamlining docs creation and maintenance for the 21st century. Like Stytch, they recognize how valuable developer resourcing is, and want to make it as easy and efficient as possible for their customers to create and maintain beautiful product documentation that drives conversion. A Y Combinator company, Mintlify (YC W22) now powers product documentation that’s seen by 100,000+ developers every month.

With Stytch, Mintlify was able to build B2B authentication into their platform in under two days, all while owning their customer experience end-to-end.

Partnership highlights

Speed: After struggling to build their own membership model with organization tenancy in-house, Mintlify was thrilled to build B2B auth with Stytch in less than two days.

Customizability: Mintlify was able to use Stytch’s SDKs to build the exact auth experience they knew was best for their customers, creating a seamless flow with the rest of their product.

Self-guided implementation: To build B2B auth, Mintlify relied almost exclusively on Stytch’s documentation, example code, SDKs, and guides. This allowed them to move quickly and build effectively, without getting bogged down in backtracking or troubleshooting.

Stytch products

B2B Authentication

Challenge

As a B2B product, organization tenancy, and organization membership were non-negotiables for Mintlify’s team. But when they tried to build it in-house, they realized that what seemed like a simple last-mile feature was actually the tip of the iceberg of very complicated and crucial infrastructure.



But when they looked at various third party providers, they were frustrated to find that every available option required sacrificing core parts of their desired user experience, whether it was the design and UI of the login page, or org-specific customizations. They were also frustrated to find that not a single third party auth provider offered built-in organization tenancy, requiring a great deal of extra work for their engineering team to build a organization/member model on their own.



Solution

Stytch’s organization-first solution and data model immediately removed the most complex and time-consuming parts of building B2B authentication, while our SDKs and documentation made it easy for the team to build exactly what they needed.



By delivering customizability alongside best-in-class developer resources, Mintlify was able to get the best of both worlds: lightning-speed time-to-value, with the dev-first experience their customers expect from a YC-backed developer platform.

Results

Decimated development time: Stytch’s developer tools, from their docs to their SDKs, allowed the Mintlify team to build B2B auth in 1/10 the time – so they could get back to focusing on their core product.

Fine-grained control: With developers for end users, Mintlify needed to be able to deliver a consistent experience across their platform. Stytch’s SDKs enabled them to build the exact controls and UI their customers expected, while Stytch handled the underlying logic and infrastructure that powered that experience.

A solution that scales: Stytch’s built-in org-first model provides Mintlify with the auth infrastructure they’ll need as their startup scales to take on larger, more enterprise customers. Any adjustments like invitation settings and adding new auth factors are quick and easy - without any significant overhead.



The bottom line

Mintlify has big ambitions to grow beyond documentation and build a comprehensive developer communication platform. With Stytch’s B2B auth solution, they can pursue their vision without ever worrying about their authentication architecture holding them back. We’re excited to fuel their growth as they take on powering the web’s documentation.

What can Stytch do for you?

Jump into our Docs to learn more about our B2B auth solution — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum , or email.

---


# Optimized their user (and developer) experience with simple one-click logins
Source: https://stytch.com/customer-stories/chessly

Learn how an online chess platform enhanced their user experience and reduced auth-related workloads with Stytch’s integrated product suite.

Chessly grew out of Gotham Chess, a popular YouTube channel and website featuring educational chess videos for beginners. Chessly expands this content into a comprehensive online platform with immersive courses and hands-on exercises that reflect the interactive nature of the game. Learning to play chess can be intimidating, but Chessly’s lessons make it easy and fun.

To keep their platform simple and inviting, Chessly needed to remove any roadblocks that might disrupt the user experience. That meant offering a variety of passwordless and password-based authentication options that meet users where they are. With Stytch, they get a full suite of flexible, frictionless auth solutions — including Google OAuth flows that log users in with a single click.

Partnership highlights

Flexible flows: Stytch’s all-in-one product suite lets Chessly expand and adjust their auth setup as needed to improve their users’ experience, with passwords and passwordless flows working seamlessly together.

Effortless scalability: Chessly didn’t want to be locked into a fixed auth flow. Stytch’s integrated product suite lets them choose which methods they implement and when.

Zero stress: Chessly trusts Stytch to manage security and access and to keep auth simple, so their three-man development team can focus on their business — not on password-reset tickets.

Stytch products

Email Magic Links

Passwords

OAuth Logins

One-Time Passcodes

Challenge

As a self-funded startup, Chessly relies on third-party services like Stripe to handle specialized functions like payment processing. That allows them to keep their team small, agile, and focused on their core product: chess. When it came to authentication, they needed an experienced partner they could count on to abstract away the heavy stakes and strains of cybersecurity.

“We knew we didn’t want to handle all of the nitty-gritty details of authentication ourselves,” said Omar Torres, Chessly’s co-founder and engineering manager. “Auth is easy to implement, but it’s very hard to get right.”

Chess is already a complex game, so for Chessly, the user experience comes first. They didn’t want to discourage users with the hassles of creating, confirming, remembering, and resetting credentials, and they knew passwordless options had to be front and center in their auth flow.

To strike the ideal balance between strong security and a frictionless UX, they turned to Stytch.

Solution

Chessly initially looked at four different auth providers, but they found Stytch’s documentation and integration process to be head and shoulders above the rest. Moreover, they liked that Stytch kept one eye on the future, adding new functionalities to their roadmap at every turn.



Chessly started with passwordless Email Magic Links, but they learned some users weren’t ready to let go of passwords altogether. Luckily, Stytch had an off-the-shelf, enhanced Passwords solution on deck, and adding it to Chessly’s auth flow was as easy as flipping a switch. Chessly soon added One-Time Passcodes and OAuth Logins to the mix, as well, allowing users to move seamlessly across devices and to sign in with a single touch.



Results

More people than ever are embracing virtual experiences for work and play, and online chess has surged in popularity. Working with Stytch has allowed Chessly to avoid the growing pains that often come with rapid scaling and to reward their users (and their developers) with a smooth auth experience.

What does that look like in practice?

4+ Login Options: Chessly currently offers four ways to sign up for and log in to an account, and they have access to many more through Stytch’s platform, giving users a choice and ultimately boosting their conversion, engagement, and retention rates.

More resources: With Stytch’s experts at their backs, Chessly’s team can unload the stress of keeping up with cybersecurity standards and the costs of hiring a specialized team to deal with auth issues in-house.

More time: When they worked on Gotham Chess, Chessly’s dev team used passwords alone, and they’d spend days sorting out broken password-reset tickets. With Stytch, most of their users opt for passwordless logins like Google OAuth, freeing up time and energy for higher-impact tasks.

The bottom line

With Stytch’s flexible, scalable auth solutions, Chessly not only provides users with a frictionless chess experience, they can channel their own engineers’ time and energy into improvement and innovation.

Case in point: They recently released a new subscription service called Chessly Plus with exclusive original content, and they’re excited to become the go-to resource for aspiring chess masters who are just beginning their journey.



What can Stytch do for you?

Jump into our Docs to learn more about our simple, seamless auth solutions — or sign up for a free account to try them out for yourself.

---


# Built a unified borrower experience with seamless, end-to-end auth
Source: https://stytch.com/customer-stories/flatiron

Learn how an alternative real-estate lender unified their borrower experience with Stytch’s seamless, full-service auth.

Flatiron Realty Capital is a privately funded real-estate lender that helps investors and developers build world-class portfolios with alternative financing options. Since founding in 2018, they’ve successfully backed everything from fix-and-flip and ground-up construction projects to single-family rental homes and large, multifamily properties. Within a short period of time, they’ve experienced exponential growth, having deployed hundreds of millions of dollars in business-purpose loans.



Behind Flatiron’s achievements is a robust underwriting system that sets a high but thoughtful bar for potential borrowers. That means their team processes and analyzes a large amount of data, evaluating track records, credit histories, liquidity profiles, and more. To consolidate this data and streamline the loan lifecycle from signup and application to decisioning and onboarding, they need a full-service authentication solution that unites all related activities and documents under a single user account. That’s where Stytch comes in.

Partnership highlights



Off-the-shelf auth: With Stytch, it took Flatiron less than a week to implement their sign up and log in flows, saving their two-person engineering team at least two months of work.



Built-in confidence: Flatiron can lean on Stytch to provide expertise and keep up with the latest industry standards, so they don’t have to hire an auth specialist in-house.



Room to grow: As Flatiron expands, they know they can easily work additional auth factors into a progressive MFA flow, thanks to Stytch’s flexible product suite.

Stytch products

Email Magic Links

Session Management

Challenge



There are many steps to the loan origination process, from setting up and verifying a new account to making a credit decision and onboarding an approved borrower. For a fast-moving lender like Flatiron, that also involves monitoring a user’s progress and keeping close track of all their linked workflows and materials to ensure a quick close time.



At its inception, Flatiron had to assemble isolated digital tools to connect and protect their users’ data. They knew they needed a more comprehensive authentication and identity management solution that could unite it all under a single, secure account.



Flatiron tried other auth providers at first, but couldn’t dedicate the time needed to make sense of their complex documentation — in some cases, even after several sales calls. Given the sensitivity of the data they work with and the complexity of handling metadata and role-based permissions, they were looking for an auth partner that offered clarity and efficiency, rather than roadblocks.

Solution



With one glance at Stytch’s docs, Flatiron knew they’d found an answer. It took their two-person engineering team less than a week to get essential auth flows up and running, saving them at least two months of busywork.



Stytch’s passwordless auth flows also mean Flatiron’s users can enjoy a smooth experience without putting their data at risk.



What’s more, Stytch offers an extra layer of security with session management, allowing Flatiron to track users’ IP addresses, monitor logins, and flip a kill switch if they detect suspicious activity.



As Flatiron expands, they plan to add auth factors — like SMS One-Time Passcodes and TOTP Authenticator Apps — downstream in the user journey, to protect riskier actions like editing contact details or scheduling automatic payments. Thanks to Stytch’s integrated suite of turnkey products, they know they can implement new flows at the click of a button, without adding friction to their users’ experience.



Results



With Stytch’s speed and flexibility at their back, Contrary was able to launch quickly. And now, they can scale and adapt their auth flows to their growing community’s needs.



2+ months saved: Stytch’s clear docs and turnkey solutions allowed Flatiron to launch their auth flows quickly and focus on their core products.



<1 week to scale: Flatiron can drag-and-drop new auth factors from Stytch’s flexible suite whenever they choose, allowing them to build custom MFA flows that work for their users.



<2 weeks to close: Stytch streamlines Flatiron’s sign up and log in flows and makes it easy to manage and track users’ accounts, allowing them to process more loans faster.



Bottom line, boosted: Flatiron knows they can rely on Stytch for the gold standard in auth, saving them the time and expense of an in-house expert.

The bottom line



With Stytch’s simple, scalable auth, Flatiron has not only saved countless time and resources building and managing their flows, they’ve given users security they can count on.



While the past year has seen an overall decline in lending, Flatiron is thriving — and they’ve used any lulls to upgrade their infrastructure and generate increased value for their users. That includes exploring Stytch’s product suite and looking for ways to drive an even smoother underwriting process and even faster close times. They’re particularly interested in trying innovative new auth methods like Strong CAPTCHA and Device Fingerprinting.



What can Stytch do for you?



Jump into our Docs to learn more about our flexible, frictionless auth solutions — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum, or email

---


# Streamlines sign-ups to <90-seconds with Stytch's SMS Passcodes
Source: https://stytch.com/customer-stories/unbanx

Learn how Unbanx met their 90-second onboarding challenge with Stytch’s SMS One-Time Passcodes

Unbanx is on a mission to bring the value of Web3, open banking, and open data to real people. The startup recently launched an app that lets users share their anonymized transaction data, pool it with other users’ data, and sell it in an attractive, aggregated package to qualified buyers. That’s why Unbanx calls itself the world’s first consumer transaction data union. It empowers people to unite and monetize their own data, instead of allowing it to be exploited by major companies.



To optimize their sign-up flow and boost performance, Unbanx presented a steep challenge to auth providers. Users needed to be able to complete their app’s three-part onboarding flow in under 90 seconds — without compromising on security. Enter Stytch’s passwordless SMS Passcodes, which met (and surpassed) their expectations.



Partnership highlights



<90-second onboarding: Thanks to Stytch’s frictionless SMS sign-ups, Unbanx’s users can complete the app’s three-part onboarding flow — including submitting personal details and linking their bank account — in under 90 seconds.



Better developer experience: Stytch was easy to integrate compared to Amazon Cognito, the provider Unbanx’s team had worked with on earlier projects. Plus, Stytch’s flexible solutions offered greater opportunities to customize their app’s UI.



Seamless scalability: Unbanx plans to expand their app’s capabilities in the next few years, and Stytch’s comprehensive product suite offers several passwordless options to evolve their auth.

Stytch products

SMS One-Time Passcodes

Challenge



To maximize adoption, Unbanx needed a secure, easy-to-use sign-up flow that would streamline their app’s onboarding process and drive higher conversion rates.



Members of the Unbanx team had worked with Amazon Cognito for past projects. But when it came to their new app, they didn’t want Cognito’s cumbersome password requirements and lengthy, friction-filled reset flows to get in users’ way.



That’s when they found Stytch’s passwordless SMS One-Time Passcodes, which can verify users via text with just a few clicks.

Solution



With Stytch as their provider, Unbanx was able to easily integrate an auth solution even as they finished up the beta version of their app.



Now, users can move speedily through their app’s sign-up flow before inputting their personal details and connecting their bank account. The entire process falls well under the “90-second challenge” Unbanx set as an onboarding goal — and users don’t have to generate and remember a complex new password to get started.



Unbanx envisions a not-distant future where users can leverage the app to improve their credit scores and tap into alternative lending sources. In the meantime, Unbanx is helping as many people as possible sign up, take ownership of their data, and earn income from what’s rightfully theirs — with Stytch by their side.

Results



Decreased development time: The Unbanx product team was able to keep working on their core platform while integrating with Stytch.



Reduced friction: Unbanx wanted users to navigate fewer screens and buttons upon sign-up. With Stytch’s SMS passcodes, they ended up exceeding their own expectations.



Customizable flows: Stytch’s solution enables Unbanx to customize their app’s UI. For example, they can craft their own error messages and alerts for users who enter the wrong information.



Continued growth: Stytch will play a big role as Unbanx develops its product roadmap and reduces friction even further. For example, Unbanx is looking into Stytch’s OAuth solution, which instantly verifies users through existing accounts on Google, Facebook, and Apple.



The bottom line



With its new app, Unbanx empowers every user to manage and monetize their own banking data. Stytch’s SMS Passcodes help make this possible by providing simple, passwordless auth that enhances security while reducing friction.

What can Stytch do for you?



Jump into our Docs to learn more about our flexible, frictionless auth solutions — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum, or email

---


# Turns flexible and scalable auth into seamless logins for a growing startup community
Source: https://stytch.com/customer-stories/contrary

Learn how a tech-forward venture fund scales its auth flows with Stytch's flexible product suite.

Contrary is a unique venture fund that finds, invests in, and nurtures emerging talent in the tech industry. That doesn't just mean providing the capital that new startups need to grow, but also the tooling and resources that entrepreneurs need to thrive. Their community includes scouts, venture partners, early-stage founders, and other members who can count on Contrary for everything from career coaching to fellowships to networking opportunities.



Given their tech-builder backgrounds, Contrary's members expect a magical online experience — far from the old-school systems of traditional VC. With Stytch, whether they’re getting onboarded, joining an event, or exploring resources on the platform, they get frictionless, passwordless auth flows that are just as agile as the products they’re supporting in their day-to-day work.

Partnership highlights



Speed: Stytch’s out-of-the-box SDK enabled Contrary to deliver value quickly to their community, without wasting time troubleshooting and iterating on authentication.



Flexibility: Contrary didn’t want to be locked into a fixed auth flow. Stytch’s integrated product suite lets them choose which methods they implement and when.



Self-service: Stytch’s intuitive solutions empowers Contrary to fly solo. They can easily embed and test new flows locally, while knowing that the Stytch team is just an email or a slack away from any support they may need.

Stytch products

Google OAuth Logins

Email Magic Links

Multi-Factor Authentication (MFA)

Challenge



Contrary knew from the start that their community and ecosystem would grow quickly. While early users shared the same, internal email domain — allowing them to rely on OAuth sign up and log in flows alone — they were primed to expand into exciting new markets and opportunities. They needed an auth solution that would scale with them.



Most auth providers only offered rigid products that would lock Contrary into a specific authentication flow and UX from day one, regardless of how their platform and users evolved. Stytch offered them the flexibility to scale on their terms.

Solution



With Stytch’s comprehensive product suite and turnkey SDKs, it’s simple for Contrary to work new auth methods into existing flows, like Email Magic Links to enhance their users’ access and experience, and MFA to add an additional layer of security.



Stytch’s products are easy to use and understand, so Contrary’s engineering team can test new options and play with configurations and customizations without having to follow a tiresome onboarding process.



These self-serve qualities not only save them considerable time and resources, but allow them to build swiftly and confidently with an effective solution.



Results



With Stytch’s speed and flexibility at their back, Contrary was able to launch quickly. And now, they can scale and adapt their auth flows to their growing community’s needs.



<100 lines of code: Stytch’s SDK gave Contrary’s team a simple block of code they could insert directly into their application — saving them countless integration hours, resources, and headaches.



<1 day to scale: With Stytch’s flexible platform, adding Email Magic Links to Contrary’s flow was like flipping a switch, allowing them to launch a new auth factor in less than a day.



Zero-effort debugging: Stytch’s intuitive dashboard gives Contrary clear visibility into each user’s settings, making it easy to diagnose login issues and address any errors or bugs.

The bottom line



Stytch’s flexible, frictionless auth flows mean Contrary can build quickly while providing the smooth sign up and log in experiences their community expects — and the valuable resources they deserve.



Stytch’s self-serve “starter pack” was perfect to get Contrary up and running. And as their platform and user needs evolve, they love how Stytch’s scalable solution will evolve seamlessly with them.



What can Stytch do for you?



Jump into our Docs to learn more about our flexible, frictionless SDKs — or sign up for a free account to try them out for yourself. Have questions? Reach out to our Developer Success team

Disclosure: In addition to being a third-party vendor of Contrary, Stytch is also a portfolio company of one or more of Contrary’s private funds, which could pose a conflict of interest due to the affiliation. Both Nathan Chiu and Jen Yang-Wong are employees of Contrary. Neither Nathan, Jen, nor Contrary were compensated for this testimonial.

---


# Launched a new loyalty program for devoted charitable users by implementing auth
Source: https://stytch.com/customer-stories/greater-good

Launched a new loyalty program for devoted charitable users by implementing auth.

GreaterGood makes charitable giving fun, easy, and free. Started in 1999 as the HungerSite.com – the world’s first click-to-donate site – they have since grown to include a whole network of charitable causes that users can donate to just by shopping or clicking a button.

With Stytch, GreaterGood launched a new membership and loyalty program that makes it easy for its users to track their clicks and other activities on the site , earn points that can be redeemed for further donations, reward users for their actions, and incentivize greater engagement with their charities.

Partnership highlights

Self-service: As an independent and self-starting culture, GreaterGood wanted a vendor that empowered them to customize and problem solve. With Stytch’s docs and API, they were able to get up and running quickly.

User-centered auth: GreaterGood’s average customer base is 40 years or older. With Stytch, they can offer more familiar login methods like passwords and Facebook OAuth, while still knowing they’re getting 21st century security and protection.

Flexibility: GreaterGood’s sessions must operate across dozens of partner sites – all built on different code stacks. With Stytch, they can rest easy knowing their users’ sessions are valid across all their giving activities.

Stytch products

OAuth

Breach-resistant Passwords

Email Magic Links

Session Management

Challenge

After over two decades at the intersection of ecommerce and charitable giving, GreaterGood had amassed a large network of users and a growing network of partner sites. But as they grew, they started to hear the same thing from their users: we want more ways to give! Users wanted to keep track of their past actions, favorite charities, which petitions they’d already signed, etc. There was also a large desire for rewards for such contributions and engagement. But without a secure session management or authentication system, GreaterGood didn’t have a way to offer that.



GreaterGood knew they were ready for a customer loyalty program, but had a few key requirements from their auth provider:

Customizability: They knew they wouldn’t be able to use an “out-of-the-box” auth solution, because they needed to track user sessions across multiple partner sites, each of which has its own code stack. API-first plus good documentation would be key

Passwords: They wanted to offer more streamlined options like OAuth and Email Magic Links, but also knew any solution without passwords would endanger alienating their user base. Passwords had to be part of the package.

Pricetag: GreaterGood knew some auth providers would gate keep features behind paywalls, or drastically increase the price tag with scale. Since they were launching a new program, they wanted pricing that was reasonable, affordable, and could grow with their new program.

With Stytch, they found everything they were looking for.

Solution

Stytch’s flexible offerings of multiple authentication factors with session management were exactly what GreaterGood was looking for. But it was the documentation, support, and affordable pricing that fully won them over.



Though the documentation was a high priority, GreaterGood also felt confident leaning on Stytch’s support team for edge cases and customization. For example, the dev team knew they wanted to require emails with their accounts, but also offer Facebook OAuth as a primary login method– except Facebook doesn’t require users to have an email!

With some fine-tuning from the Stytch support team, they devised a flow in which users had to confirm their account setup with a verification email, regardless of their auth method – thus ensuring GreaterGood had the information they needed to keep their customers up to speed, while their customers got first pick over the auth method that worked best for them.

Results

Customer satisfaction: With an affordable, flexible auth provider now on the case, GreaterGood was able to launch their GreaterGood Guardians user account program their donors had been asking for for years.

Ready for growth: In just the first month of their loyalty program, GreaterGood attracted thousands of new users. This is the exact traction and engagement they were hoping for.

Easy on developers: Stytch’s docs and combination of API with SDKs allowed the GreaterGood developers to get a product up and running swiftly and independently – and also promises for easy troubleshooting and updates in the future.



The bottom line

With their loyalty program in place, GreaterGood is now in a position to expand user engagement in new, exciting ways: referral credits, community voting to guide charitable donations, and even potential integrations with their ecommerce stores. We’re gratified to help them pave the way for more people to give, and share that generosity with a broader community.

What can Stytch do for you?

Jump into our Docs to learn more about our auth solutions — or sign up for a free account to try them out for yourself. Have questions? Reach us via Slack, Stytch Forum , or email.

---


# Turns robust crypto security into seamless onboarding with Stytch's OTPs
Source: https://stytch.com/customer-stories/ottr-finance

Ottr Finance turns robust crypto security into seamless onboarding with Stytch's OTPs.

Ottr is an intuitive, all-in-one web3 mobile wallet for people who aren't yet crypto-savvy. It works like a decentralized Venmo, allowing users to send USDC easily and instantly to anyone in the world while enjoying fee-free crypto trading and high-yield crypto rewards.



As a decentralized platform unshackled to a financial institution, Ottr doesn't have custody of users' holdings, reducing the risk of mismanaged funds. Security is the cornerstone of their business, and they need an authentication partner that keeps assets safe without disrupting the frictionless experience users have come to expect from consumer finance apps.



Partnership highlights

A readymade solution: With Stytch's helpful team at their back, Ottr got critical sign up and log in flows up and running within three weeks of development.

Turnkey, but tailorable: Unlike rigid auth solutions, Stytch's flexible templates allow Ottr to customize the verification flows and messages they send their users.

Global support: Stytch supports international messaging platforms like WhatsApp and offers international coverage, an important feature for Ottr's global user base.



Stytch products

One-Time Passcodes (SMS, Email, WhatsApp)



Challenge

With most crypto wallets, users are required to generate complex private keys and manually back them up to ensure security and access. These are tough tasks to perform on the go, leading many mobile users to either risk losing their keys (and their assets) or abandon the sign up flow.



Rather than making users responsible for their own security, Ottr automatically backs up encrypted keys to the cloud. Not only is this flow built into Ottr's app, it's completely passwordless. That means users don't have any secrets they need to remember to access and manage their funds, and they're not vulnerable to hackers who can easily intercept weak or recycled credentials.



Ottr decided to use one-time passcodes (OTPs) to support their authentication and encryption system. There was just one problem. With AWS as their auth provider, they only had access to Amazon Cognito, an inflexible, difficult-to-integrate OTP solution that would quickly eat up their development time and resources.



That's when Ottr's founder and CEO, Aleksei Zakharov, saw an ad for Stytch at a San Francisco bus stop — and the rest is history.



Solution

Stytch's turnkey templates got Ottr's sign up and log in flows operational in less than three weeks. Now, Ottr uses Stytch's One-Time Passcodes via SMS, email, and WhatsApp to verify users in just a few clicks. It's a smooth, friction-free process that yields over 80% conversion rates at onboarding.



With Cognito, Ottr's developers were locked into a rigid design. But Stytch's flexible solutions allow them to customize elements like email subject lines to their specific branding and user journeys — small nuances that go a long way when it comes to building trust and loyalty.



Also unlike Cognito, Stytch provides coverage across international messaging platforms and communication providers, an important feature given Ottr's global reach. Plus, Stytch offers built-in failover logic and cost-saving volume discounts that wouldn't be available with an in-house build.



Ottr is so pleased with the outcome that they're looking to integrate other Stytch solutions — like TOTP Authenticator Apps and Strong CAPTCHA solutions — into their flows for users who want an extra layer of security without the extra headaches.



Results

So, what has Stytch accomplished for Ottr? The numbers speak for themselves:

3 weeks to launch: Thanks to Stytch's out-of-the-box solutions, Ottr got their essential auth flows off the ground quickly, while still leaving room for customization.

2 minutes to onboard: The average user takes less than two minutes to complete Ottr's entire onboarding flow using Stytch's simple One-Time Passcodes.

80%+ conversions: Thanks to Stytch's passwordless, frictionless flows, a vast majority of new users complete Ottr's onboarding process and go on to engage with their app.



The bottom line

With Stytch, Ottr is able to offer an intuitive, consumer-friendly crypto wallet, without compromising on the powerful protections it takes to safeguard users' digital assets.



What can Stytch do for you?

Jump into our Docs to learn more about our flexible, frictionless Passcodes — or sign up for a free account to try them out for yourself.

---


# Launches no-code forms and flows with Stytch's turnkey solutions
Source: https://stytch.com/customer-stories/feathery

Feathery launches no-code forms and flows with Stytch's turnkey solutions.

Peter Dun founded Feathery on the idea that creating online forms like surveys, applications, and in-app onboarding flows shouldn’t require separate teams of software engineers and product developers. He envisioned a simpler approach that would allow product teams to take direct ownership of their content without hand-coding and complicated buildouts.



Feathery needed an easy, secure way to create authentication flows for customer-facing forms and applications as well as authenticate their own users on their platform. Having recently achieved SOC-2 compliance, the company looked for an authentication provider with a similar vision and the same high standards for protecting customer data. They found the perfect partner in Stytch.



Stytch’s authentication platform delivers exactly what Feathery needs to advance their product roadmap: a low-friction, passwordless solution that prioritizes both ease of use and enhanced security.



Partnership highlights:



Higher conversions: Stytch’s platform enables one-click sign-up and logins for all of Feathery’s customers and end-users, increasing both conversion and retention rates.

Quick, customizable solutions: Stytch’s SDK allows Feathery to get up and running quickly while still tailoring their forms to their customers’ unique business needs.

Effortless integration: Feathery integrated with Stytch in two ways — on the front end using Stytch’s Javascript SDK and on the back end using direct API calls — all in a matter of days.

Exceptional customer service: Stytch’s engineering team made themselves available throughout the integration process and continue to offer hands-on support.



Stytch products:



Email Magic Links

OAuth Logins



Challenge



Feathery’s challenge was to implement a powerful, secure auth solution that would be easy for their internal team as well as their customers’ product teams and end-users to navigate. The right provider would have a strong reputation and offer robust, customizable solutions for online forms and flows.



Solution



Feathery partnered with Stytch to launch their core offerings and selected two products to get started:



Email Magic Links: With Stytch’s one-click login solution, Feathery frees users from having to store or remember unique passwords. Thanks to the ease and convenience of magic links, they’ve been able to boost both conversion and retention rates.



OAuth Logins: With Stytch’s secure OAuth framework, Feathery’s users can sign up and log in with familiar IdP membership credentials through Google, Apple, or Facebook — instead of having to create a complex new password.



Results



Feathery completed the integration in just a few days, finding the process seamless and saving Feathery’s engineering team at least a week of work. Feathery has since been able to realize their vision for secure and easy-to-use forms and flows for all of their customers.



Unlocking ownership for product teams



In a traditional paradigm, product teams harbor the vision, but it’s up to the engineers to build out the forms and make any modifications. Even a simple color change requires an engineering team’s time and resources. Once Feathery joined forces with Stytch, they no longer needed to adhere to this outdated and inefficient approach. Thanks to Stytch’s solutions, product developers now have control over the vision and execution of customer-facing forms.



Ensuring the highest level of security



As a SOC-2-compliant SaaS company, Feathery needs a partner who values data security just as much as they do. Stytch’s one-click sign-on and OAuth features meet their criteria for user-friendly solutions that also reinforce security. Because of Stytch, Feathery’s forms no longer require their users to remember or securely store unique credentials, eliminating the risk of password-based cyber attacks like account takeovers.



Delivering flexibility and customization



Stytch’s turnkey SDK and direct API integrations facilitate seamless and secure solutions that can easily be customized. Feathery’s product team can adapt the flexible SDK templates by adding a logo, colors, and fonts to reflect each customer’s brand identity.



The bottom line



With Stytch’s support, Feathery has the robust tools they need to authenticate their own users, build secure auth flows into their customer-facing forms, and empower product teams.



What can Stytch do for you?



Jump into our Docs to learn more about our flexible, frictionless auth solutions — or sign up for a free account and try them out for yourself.

---


# Switched to Stytch’s flexible flows in only 4 days
Source: https://stytch.com/customer-stories/boletomovil

Boletomóvil uses Stytch's WhatsApp and SMS passcodes to create a seamless login experience, boosting conversions and delighting users.

Co-founders Roberto Rey and Walter González Domenzain started Boletomóvil for a simple reason: they love sports, but buying tickets for a game in Mexico — even through an online system like Ticketmaster — involved a multi-step process that made users jump between digital and physical points of sale. They decided Mexico needed an easy, fully digital ticketing experience for all events, with smooth authentication flows to make transactions fast, frictionless, and secure.



With Stytch, they get turnkey passcodes that support popular, international messaging platforms like WhatsApp — plus “just-in-time” auth that only adds friction when it’s absolutely necessary, driving a better UX and higher conversion rates.



Partnership highlights:



Speedy integration: it took Boletomóvil only four days to switch to Stytch from their previous auth provider, even as they created a whole new front end.

WhatsApp support: Boletomóvil had trouble finding an auth provider that covers WhatsApp, the most common messaging platform in Mexico — but Stytch delivered.

Smooth UX: with Stytch’s route-based, “just-in-time” approach to auth, verification flows are reserved for sensitive actions like making payments, reducing overall friction.



Stytch products:



SMS One-Time Passcodes

WhatsApp One-Time Passcodes



Challenge



In the ticketing world, the ability to act quickly and decisively on customer interest is critical to success.



“Entertainment is all about experiences and emotions,” said Rey. “People get excited about events, and the timeframe to convert their excitement into a ticket sale is short. A fast, frictionless authentication flow is a must to ensure high conversion rates.”



Initially, Boletomóvil used Firebase for SMS-based authentication, with the expectation that they’d also have login options through WhatsApp — Mexico’s most popular messaging app. But before long, their auth costs started rising, and their WhatsApp support vanished altogether.



“As we added more users, we noticed unexplained spikes in pricing,” said Rey. “Plus, we needed the WhatsApp integration, since WhatsApp is huge in Mexico. Having a WhatsApp option is the only way to ensure a smooth, successful login process for everyone.”



With that, Boletomóvil began looking for an alternative auth provider that could meet their needs.



Solution



Boletomóvil learned about Stytch through their participation in the Y Combinator accelerator program and knew they had found their auth partner. Stytch was the only provider offering fair, transparent pricing, simple integrations, and reliable WhatsApp flows for international customers.



Now, Boletomóvil enjoys out-of-the-box SMS and WhatsApp Passcodes that are easy to navigate, provide authentication that’s both flexible and secure, and — best of all — support the messaging platforms customers in Mexico actually use.



Results



A quick transition from Firebase to Stytch



Boletomóvil had a team of four replace their old Firebase flows with Stytch’s Passcodes. And, thanks to Stytch’s simple documentation, it took them under a week to implement from end to end.



Flexible flows with global reach and strict security



Rey explained how turnkey access to WhatsApp logins has transformed Boletomóvil’s business (and their users’ experience) for the better.



What’s more, Stytch’s passwordless product suite is both modular and robust, so Boletomóvil can offer multiple login options without compromising on security.



Friction only when necessary



Stytch supports “just-in-time” authentication, which only requires users to sign up or log in when they’re carrying out sensitive tasks like entering payment details. That means Boletomóvil can give users free, frictionless access to their platform for low-risk, read-only activities.



What’s next



Boletomóvil is growing fast, and they know Stytch’s forward-thinking solutions will continue to support them as they add innovative services to their platform.



“We recently launched Bilma, our new NFT marketplace, and we’re rolling out NFT collections in partnership with major sports teams,” said Rey. “We’re excited to try Stytch’s crypto wallet solutions and learn how Web3 options like MetaMask logins can help our customers pay with digital assets.”

The bottom line



With Stytch, Boletomóvil gets flexible, turnkey passcodes that authenticate users in a way that’s frictionless, secure, and channeled through the messaging platforms international customers actually use.



What can Stytch do for you?



Jump into our Docs to learn more about our flexible, frictionless auth solutions — or sign up for a free account, and try them out for yourself. Get started.

---


# Traded in a costly in-house authentication for Stytch’s out-of-the-box solutions
Source: https://stytch.com/customer-stories/bitcoin

In this client story, you'll see how Bitcoin.com chose Stytch for scalable, cross-platform authentication. Read more here!

Bitcoin.com is a multi-chain wallet, marketplace, and news outlet that makes it easy for anyone to buy, sell, trade, and learn about different cryptocurrencies. They recently broke new ground in the crypto space with the launch of Verse, a powerful utility token that rewards users in the Bitcoin.com ecosystem and eases newcomers into decentralized finance.



To support their services with a reliable account system and solid authentication, Bitcoin.com initially built onboarding and sign-in flows in-house — but they soon ran into heavy maintenance costs and workloads. With Stytch, they get cross-platform auth solutions right out of the box, plus a dedicated team that offers expert, round-the-clock support.

Partnership highlights



Easy integration: Stytch allowed Bitcoin.com to ditch a high-maintenance in-house build for a drop-in solution that took less than a month to implement from end to end.



Cross-platform performance: Stytch’s flexible solutions work seamlessly across the Bitcoin.com platform, including a wide variety of products for both web and mobile applications.



Close collaboration: Stytch’s team instantly understood what Bitcoin.com was looking for in a crypto-based auth flow — and delivered tailored solutions to meet their needs.

Stytch products

Email Magic Links

OAuth Logins

Challenge



Bitcoin.com is committed to non-custodial crypto services, which means users have direct access to their digital assets and exclusive control over their private keys. It also means a user who loses a key has no chance of recovery — prompting the platform to offer a convenient backup option.



“We were seeing a lot of support tickets from users losing their keys,” said Paul Bergamo, Product Lead at Bitcoin.com. “We decided to add a wallet function that allows them to back up encrypted keys to the cloud — which in turn necessitated a secure user account system.”



The need for robust accounts — and equally robust authentication to protect users’ KYC data — only grew as Bitcoin.com planned for the launch of their new native utility and rewards token, Verse, which was an important moment for the company. Their head of engineering, Andrei Terentiev, described how they first built their own sign-up and login flows in-house — an approach that quickly became untenable as their business grew.



“We learned that an in-house build wouldn’t scale effectively and involved a lot of maintenance we weren’t prepared to handle on our own,” he said. “As we developed more use cases, features, and products, it became a huge undertaking that drained our engineering resources.”



Bitcoin.com began researching third-party alternatives — and found a winning solution in Stytch.

Solution



The Bitcoin.com team tested several authentication providers, including AWS Cognito and Auth0. Then, they read an article about Stytch’s passwordless product suite and realized it could provide top-notch security without the typical friction of an auth flow.



Results



Easy implementation



Bitcoin.com was able to get their authentication flows up and running quickly, dropping Stytch’s React SDK straight into Verse’s web platform. They also built OAuth Login solutions for Google and Apple smoothly into their application, as well as Email Magic Links for anonymous users.



“We built a POC for our product team, and they were blown away by Stytch’s ease of use,” said Andreas Larsson, engineering manager at Bitcoin.com. “The integration was effortless compared to other tools, because we had so much support. There was even a Slack channel where we could ask Stytch questions and receive near-instant responses that put us on the right track. The whole process only took about a month from end to end, including testing and everything.”



Not only did the initial integration fly by — Stytch’s turnkey products gave Bitcoin.com’s team back the time and energy they needed to focus on their core products.



Cross-platform functionality



As Larsson explained, for Bitcoin.com, a successful authentication strategy isn’t just about efficiency, but about the range of services supported across the platform.



A true partnership



For Terentiev, Stytch’s most important quality is an intuitive understanding of Bitcoin.com’s mission and a willingness to jump in with tailored solutions and hands-on, personalized support.



“With a bigger company like Auth0 or Cognito, you’re one of many clients,” he said. “You can’t really ask for additional or customized features — you just have to use what they give you. When we reached out to Stytch, it was a totally different experience.

“As a startup, Stytch connected instantly to what we’re trying to do. Traditional authentication companies don’t really understand crypto — it’s still something new. With Stytch, we get the best of both worlds. They know what they’re talking about when it comes to auth, but they also immediately grasped what we needed in a crypto solution. It was clear right from the start that Stytch is the best match for our platform.”

The bottom line



With Stytch, Bitcoin.com gets out-of-the-box, easy-to-implement authentication solutions that allow them to concentrate on their core business — not on managing and maintaining an in-house build. What’s more, they get an attentive partner that will support their crypto platform as it scales.



“Verse and Bitcoin.com are a gateway for users to transition from traditional finance to our new, decentralized world of cryptocurrency,” said Terentiev. “Stytch is helping us provide users with the tools they need to get started. We’re excited to discover what Stytch does next with their Web3 solutions and to be among the first users of their next-level authentication technology.”

What can Stytch do for you?



Jump into our Docs to learn more about our frictionless authentication solutions — or sign up for a free account to try them out for yourself. Get started!

---


# Unplugged Cognito and plugged in Stytch in just 2 days
Source: https://stytch.com/customer-stories/pronti

Smart wardrobe app Pronti keeps costs low and offers flexible login options with Stytch’s One-Time Passcodes.

Imagine having a 24/7 personal stylist that helps you plan outfits and purchase items that optimize what you already have in your closet. That’s Pronti, a smart wardrobe app using AI and machine learning to make hyper-personalized styling and buying recommendations while supporting reuse and sustainability. Pronti is all about saving users the time, strain, and expense of endless scrolling and shopping — and they need a streamlined authentication flow to match. With Stytch’s flexible passcodes, they minimize their costs and workloads while maximizing users’ login options via email and SMS.

Partnership highlights



+30K MAUs: within 72 hours of integrating with Stytch, Pronti saw over 30K users log in seamlessly to their app.



Smooth UX: with Stytch’s easy One-Time Passcodes and autofill capabilities, users enjoy frictionless onboarding and instant access to Pronti’s platform via email or SMS.



200 errors to 0: Pronti received about 200 authentication errors a week with their earlier provider, AWS Cognito, creating work and worry for the team. With Stytch, they’ve reduced these errors to zero, giving them valuable time back to focus on their core product.

Stytch products

SMS One-Time Passcodes

Email One-Time Passcodes

Challenge



For Pronti, effective authentication means not only offering each user a unique, secured account, but also saving them time and effort logging in. These days, no one wants the hassle of creating and remembering usernames and passwords, so Pronti decided to eliminate them altogether.



“It was a UI/UX choice aimed at making our onboarding and access flows really smooth,” said Mila Banerjee, Pronti’s founder and CEO. “We just wanted a simple passcode that users could enter to instantly log in to our platform.”



Initially, Pronti turned to AWS Cognito. But users soon began experiencing slow and unsuccessful login attempts, resulting in mounting complaints and mounting costs.



“If users grew impatient, they would keep clicking the resend-code button,” said Banerjee. “Since Cognito priced us on a per-code basis, we were charged for every click. As we went viral and traffic increased, our authentication costs went through the roof.”



Pronti did some research into more flexible, user-friendly alternatives and found a promising answer in Stytch’s startup program.

Solution



Right off the bat, Stytch helped Pronti cut costs with a per-user pricing model that scales along with their business.



Stytch also set Pronti up with an adaptable set of One-Time Passcodes that users could access and execute without ever leaving Pronti’s app — leading not only to a better UX and an uptick in MAUs, but less cleanup and grunt work for Pronti’s team.

Results



A swift, simple integration



Thanks to Stytch’s straightforward documentation and helpful resources, Pronti’s small team had no trouble getting up and running quickly.



“When we partnered with Stytch, our team was lean, lean, lean,” said Banerjee. “A complex auth integration just wasn’t going to work. But Stytch’s solutions were easy to implement with one back-end engineer. We essentially unplugged Cognito and plugged in Stytch in just a couple of days, and the simplicity of Stytch’s docs made it effortless.”



And, unlike Cognito, where they struggled to get the tech support they needed, Banerjee noted that Stytch’s team was with them every step of the way.



Flexible flows



With Stytch’s simple, MAU-based pricing, Pronti’s users can log in however they want, as often as they want, without Pronti getting stuck with higher bills. That means Pronti can offer the same seamless, secure experience across different devices.



“The flexibility to authenticate via phone or email has been a huge deal for us,” said Banerjee. “Our users really appreciate the ability to use both and having an easy backup to get into their account.”



In fact, within days of integrating with Stytch, this streamlined, accessible UX helped 30K distinct users log in to Pronti’s platform without a hitch. And the numbers keep getting better.



Restored resources



According to Andrea Veintimilla, Pronti’s founding designer and marketer, before partnering with Stytch, Pronti’s team would regularly hear about frustrated users who weren’t receiving their authentication codes and weren’t able to log in to the app.



“With Cognito, we’d get so many user complaints that it would affect our ratings in the App Store,” she said. “We’d also get about 200 direct messages a week reporting authentication errors that we’d have to deal with. Now, we’re not getting any at all.”



The proliferating auth problems didn’t just drive away Pronti’s users — they created more work and worry for Pronti’s dedicated team.



“We just weren’t big enough to handle that volume of error, between the customer service hours and the back-end tech work it would take to figure out what was going on,” said Banerjee. “Stytch has allowed us to focus on our core business, rather than spending all our time on authentication.”

The bottom line



With Stytch, Pronti gets authentication flows that are affordable, flexible, and functional enough to cover their wide user base. Now, Banerjee says they’re excited to scale to a million users and add even more auth solutions — like embeddable magic links — to open new communication channels and tap into new revenue streams.



“Offering multiple easy ways to log in helps us get users into our app and using it faster,” she said. “At the end of the day, our whole mantra is about going out and doing what you do best — instead of wasting energy authenticating, picking an outfit, or whatever else distracts you from your goals.”



The proliferating auth problems didn’t just drive away Pronti’s users — they created more work and worry for Pronti’s dedicated team.



“We just weren’t big enough to handle that volume of error, between the customer service hours and the back-end tech work it would take to figure out what was going on,” said Banerjee. “Stytch has allowed us to focus on our core business, rather than spending all our time on authentication.”

What can Stytch do for you?



Jump into our Docs to learn more about our frictionless authentication solutions — or sign up for a free account to try them out for yourself. Get started!



---


# Turned to Stytch for simple, streamlined authentication flows
Source: https://stytch.com/customer-stories/gather

Virtual learning platform Gather streamlines authentication with Stytch’s flexible, frictionless solutions.

Gather (now Mighty) hosts online educational programs and interactive communities for cultural institutions like museums and universities. Their digital learning platform has grown exponentially in the wake of COVID-19, as remote and virtual experiences have become increasingly essential.



Users can register for an event through Gather or through a partnering organization’s website, app, or membership portal, necessitating a range of flexible and secure authentication options. With Stytch, Gather is able to provide a best-in-class sign up and login experience without having to spend time building or maintaining an authentication architecture.

Partnership highlights



Streamlined authentication: Gather allows guests to register for and join events from a variety of apps and channels. With Stytch’s flexible solutions, Gather can connect to partnering organizations’ APIs while streamlining authentication flows for users.



Safe and secure data: Relying on Stytch’s solid security and maintenance, Gather doesn’t have to worry (or even think) about protecting clients’ and users’ sensitive data or tending to technical errors.



Speedy integration: With Stytch’s straightforward documentation and hands-on support, it took Gather’s small engineering team just two weeks to integrate, saving them valuable time and energy.

Products used

Email magic links

Embeddable magic links

Google OAuth

Challenge



To work with their partners’ existing platforms and membership databases, Gather searched for an adaptable authentication solution that would reduce friction while allowing users to navigate between different applications and accounts.



“We don’t have your typical blog-style website,” said Ryan Rosztoczy, Gather’s founding engineer. “We need to be able to partner with organizations, connect to their API calls, and link our authentication together. For instance, one of our partners doesn’t use our signup, because they already had a pre-existing flow. So, the issue for us is, how can we stitch together pieces of auth on our back end to be really flexible for our clients?”



At the same time, Gather handles high-volume events for several prominent institutions, meaning they don’t just need a seamless user experience—they need security they can count on.



“Our clients tend to be stringent, especially the big universities and museums,” said Rosztoczy. “You have to go through RFT proposals where you outline your entire technical process. For us to do that and make changes based on each organization’s needs would be impossible. We need to be able not to worry about it—to check it off and say, ‘No, we don’t have this vulnerability here.’”

Solution



Gather turned to Stytch right off the bat to put a versatile authentication flow in place.



Once they decided on Stytch, the integration process was smooth and painless, even for a very small engineering team. And the Stytch team was there to support them throughout.



Results



With Stytch’s simple, streamlined authentication flows, Gather can create a seamless experience from end to end, even when users are jumping between different platforms.



“The most valuable thing by far is the ability to create tokens and attach them to user sessions,” said Rosztoczy. “Before, we’d send event reminders to registered users via email. When they clicked, it would bring them to the Gather website, but then they’d have to log in. Now, we just attach tokens to each email, so a user can go from their inbox to our app fully authenticated. We already have their data, and they’re verified automatically.”



What’s more, Stytch’s solid, passwordless solutions save Gather from having to worry about bolstering their security profile and safeguarding their users’ information.



“As an early startup with a small team, we want to think about security as little as possible so our focus can be on feature development,” said Rosztoczy. “One of the nice things about Stytch is that there are no passwords. We have no sensitive personal data contained in our application, nothing that we’re liable for. If we get hacked, it doesn’t matter.”

For Rosztoczy, that means he can set and forget Gather’s authentication infrastructure while using it as a springboard for new ideas and innovations—and saving time, to boot.



Looking ahead



Moving forward, Gather is excited to try the full range of Stytch’s authentication solutions, allowing their clients and end users to register for and join virtual events whatever way works for them.

`

“We’re eager to implement other passwordless products like Google Auth and SMS passcodes to reduce friction even more,” said Rosztoczy. “With Stytch, we know we’ll have a nice array of authentication tools in place to make everybody happy. I see us using almost all of them within a year.”

What can Stytch do for your app?



Jump into our Docs to learn more about our flexible, frictionless authentication solutions.



Sign up for a free account to try them out yourself.

---


# Improved conversion by 62% by switching from Auth0 to Stytch
Source: https://stytch.com/customer-stories/lighthouse

Lighthouse sees a 62% improvement in its sign-up conversion rate by switching from Auth0 to Stytch.

Key takeaways



Lighthouse is a next-gen rental platform that provides renters exclusive access to apartments that reward them with cash back. By switching from Auth0 to Stytch as its primary authentication provider, Lighthouse now offers a more flexible and seamless onboarding and authentication experience to its users. After the switch, Lighthouse saw a 62% improvement in its sign-up conversion rate.

Challenge



Lighthouse was using Auth0 as its primary user authentication tool. The Lighthouse team was able to quickly get Auth0 up and running, but it soon faced challenges after realizing that it was infeasible to customize its user flow to meet its users’ needs while remaining on Auth0. Specifically, Auth0’s inflexible data structure and authentication flow made it impossible to give users the flexibility to choose either emails or phone numbers as their primary identification method for signups and logins. In addition to forcing Lighthouse developers to select just one primary user identification method, Auth0’s authentication flow redirected users to an Auth0-hosted page and then back to the app, creating a clunky, frustrating onboarding experience for users.



As Lighthouse was quickly gaining traction and increasing its user base, the company soon realized that it needed to look for a new authentication solution that would allow it to fully customize its user authentication and onboarding flow, thereby improving its user experience and conversions.

Products used



SMS one-time passcodes



Email passcodes



Session management

Solution



When the Lighthouse team decided to revamp its authentication flow, it initially had an internal conversation about whether to build the authentication flow in-house vs. integrating with an authentication provider. It quickly realized that there were a myriad of complexities that go into building and managing an authentication flow (e.g. data management, security protocols, and building reliability measures) and that its internal resources could be better spent on core product initiatives by going with an existing authentication provider.



After carefully reviewing API docs of multiple authentication providers and determining whether those providers could support its use cases, Lighthouse decided that Stytch would be the best solution to meet its needs. Lighthouse software engineer, Jack Grzechowiak, was particularly impressed with Stytch’s easy-to-follow documentation and flexible APIs and also appreciated how quickly Stytch’s support team responded to his questions.



By stripping out Auth0 entirely and implementing Stytch’s API instead, Lighthouse can now deliver its vision of offering a flexible and seamless onboarding and authentication experience to its users. With the majority of users on mobile, the Lighthouse team wanted to create a mobile first experience with SMS OTP as the default authentication method, while also allowing users to first authenticate through email OTP to offer flexibility. In the second step of the onboarding process, Lighthouse now collects users’ email or phone numbers with an option to verify now or later. Those additional identification methods would later be used as secondary verification layers when users want to engage in activities that would require higher security such as accessing bank account information or changing insurance details. With Stytch’s flexible session management product, the Lighthouse team can introduce ”just-in-time” authentication only when necessary on any given route to remove unnecessary friction from its user flow while also maintaining security.



Moreover, instead of redirecting users to an Auth0-hosted landing page when they try to sign up or login, with Stytch, Lighthouse now presents a more seamless sign up and login flow through a pop-up screen that is completely embedded and on brand. The company believes that the new onboarding flow will provide a far better experience to its users, thereby increasing customer conversion and satisfaction.

Results



After the switch from Auth0 to Stytch, Lighthouse saw a 62% improvement in its sign-up conversion rate. As it looks to the future, the Lighthouse team is excited to continuously optimize and improve its user onboarding flow with Stytch’s flexible and secure APIs and further improve its sign-up conversion rate.

Ready to get started?



Interested in trying out Stytch for yourself and customizing your user onboarding and authentication flow like Lighthouse did? You can sign up for free to start using our flexible APIs. Or, you can read more about them in our documentation. We can’t wait to see what you build with Stytch!

---


# Integrated Stytch’s Email Magic Links and saw a 35% increase in users
Source: https://stytch.com/customer-stories/standard-metrics

Standard Metrics (formerly Quaestor) expands and improves its user authentication capabilities and user count with Stytch.

Products used



Email Magic Links [SDK]

Key takeaways



Time to value: One engineer was able to independently stand up Stytch in one day

Within just a few months, upwards of 35% of users are logging in through Stytch, many of whom didn’t have access due to a lack of Google or Microsoft account



Developer experience: Stytch’s clear documentation and SDK were difference makers in their decision making process



Uptime: Stytch has been a reliable sign up and login provider for Standard Metrics thus far. This is in part due to Stytch’s built-in support of failover redundancy across multiple providers, ensuring low latency and high deliverability.



Standard Metrics is an automated data platform that enables financial transparency between startups and investors. With Stytch, Standard Metrics enables their customers to reach a broader range of their investor constituents, resulting in more end users on the Standard Metrics platform.

Challenge



When Standard Metrics initially launched, the only way an end user could log in was through a Google or Microsoft OAuth flow. This made sense as a starting point as their first clients just supported those platforms. But as the popularity of their product grew, they came up against companies who either didn’t utilize Google or Microsoft login, or just weren’t comfortable with a password-based option. Because of this, there were important investors who simply could not log into Standard Metrics. This not only negatively affected Standard Metrics, since it limited who could access their platform, but it also frustrated Standard Metrics’s customers, as they had to maintain a separate flow to disseminate information to investors who couldn’t access Standard Metrics.



Standard Metrics quickly realized that they needed a secure, yet expansive, user authentication method that still relies on email as the primary factor while also emulating the passwordless experience that already existed with their existing OAuth flows.

Solution



After reviewing the available options in the market and deciding whether they should build a solution in-house or go with another provider, the Standard Metrics team ultimately decided to partner with Stytch to build out their ideal flow. The primary consideration point for them was the opportunity cost of their developers’ time, and Stytch enabled them to have very fast time to value. Additionally, implementing user authentication poorly has large downside risk and Standard Metrics could risk serious reputational harm. Finally, the team chose Stytch over other vendors because of Stytch’s intuitive documentation and focus on the overall developer experience.



The full implementation took less than a day.



The existing Standard Metrics user authentication flow was not something the team was super happy with, but they couldn’t afford to shut it off entirely to do a complete revamp without affecting their user base. With Stytch and the flexibility of their components and APIs however, Standard Metrics was able to have the best of both worlds.



By using Stytch’s React components and APIs, instead of ripping and replacing their existing flow, Standard Metrics was able to simply append a passwordless email authentication experience on top of what was already there. And because Stytch has an endpoint that enables customers to log in or create a user, Standard Metrics was able to modify both their Log In and Sign Up flows.



This let the Standard Metrics keep a user authentication flow in place while they built out a brand new onboarding flow that is just using the SDK to send out magic links, which will go live by the end of October 2021. Stytch’s products gave the Standard Metrics team the ultimate level of optionality and let them build what they needed, when they needed, all without disrupting their end users and letting them maintain control over their user experience.

Results



With Email Magic Links, Standard Metrics is no longer limited to only end users with a Google or Microsoft account, and they are able to expand access to its platform to anyone with an email address while still upholding their strong security. Anecdotally, the team found that end users tend to like using the magic links to login, and they were surprised at how many people gravitated towards that option despite not actively nudging end users towards it.



As of today, after having Stytch live for just a few months, Standard Metrics is seeing upwards of 35% of end users logging in through Stytch. Most importantly, Stytch has been a reliable partner for Standard Metrics and user authentication has not been something that their engineering team has needed to spend a lot of time on.



Ready to get started?



Interested in trying Stytch out for yourself? You can sign up for free to start using our products. Or, you can read more about them in our Docs. We can’t wait to see what you build with Stytch!

---


# Competitor page - Firebase
Source: https://stytch.com/stytch-vs-firebase

Build auth that feels native to your app and proactively removes fraud and abuse.



---


# Competitor landing page - WorkOS
Source: https://stytch.com/lp/workos

Build multi-tenant auth purpose built for hyperscaling B2B SaaS.



---


# Competitor page - Fingerprint
Source: https://stytch.com/stytch-vs-fingerprint

Compare Stytch's device fingerprinting solution vs. Fingerprint.js. Understand which device fingerprinting product is right for your use case.



---


# Admin Portal
Source: https://stytch.com/admin-portal

Increase conversion, security, and usability with Stytch's authentication platform, SDKs, and API. Easy to use — get started in minutes.



---


# Careers
Source: https://stytch.com/careers

Learn more about Stytch as a company, our team, leadership, mission, vision, values, and career opportunities.



---


# Connected Apps
Source: https://stytch.com/connected-apps

Enable your app as an IdP for secure cross-app integrations, data sharing, AI workflows, cross-device login, and app marketplaces—all with Stytch Connected Apps.



---


# SEM LP: Auth0 Pricing
Source: https://stytch.com/lp/auth0-pricing

Build auth that feels native to your app and proactively removes fraud and abuse, all at a lower price.



---


# Payment Fraud
Source: https://stytch.com/lp/payment-fraud

Stytch Fraud and Risk Prevention detects and blocks threats from users, bots and AI agents—before an order is even placed.



---


# SSO
Source: https://stytch.com/lp/sso

Enable SSO for your app.
Any identity provider. One integration.



---


# SEM LP: Cognito
Source: https://stytch.com/lp/cognito

Build auth that feels native to your app and proactively removes fraud and abuse.



---