Forem: Clerk.dev

History and Rise of "Passwordless"

Clerk.dev — Fri, 01 Oct 2021 00:15:20 +0000

A Brief History of Passwordless

Passwords have been our main digital authentication method since 1961, though its vulnerability to hacking was demonstrated within one year.

Encrypted password storage and public-key cryptography were developed in the late 60s to early 70s.

But the 1980s brought the first version of "passwordless" authentication. This came in the form of dynamic, one-time passwords (OTP) held on physical fobs.

OTPs eventually developed into two protocols: time-based OTPs (TOTP) and cryptographed hash-based message authentication codes or HMAC OTPs (HOTP). Dynamic OTPs are still widely used as an authentication protocol.

The late 1990s brought single sign-on (SSO) into use. SSO helped organizations manage user authentication across an entire network of applications. However, fobs and other hardware tokens remained in use and popular throughout the 1990s and 2000s.

Smart cards are one hardware token that emerged in the early 2000s. These physical electronic authorization cards are sometimes used as passwordless security tokens.

The 2000s also saw the combination of these various passwordless and password-based authentication methodologies with the rise of multifactor authentication. AT&T actually holds the earliest recognized patent dating to 1998, but multi-factor auth (MFA) and single sign-on (SS0) really took off when organizations like Google began building them into their applications as a form of password-independent authentication.

The financial sector adjusted quickly. In 2005, the Federal Financial Institutions Examination Council (FFIEC) set out new user authentication guidelines. These included multi-factor authentication, biometrics, OTPs, and token-based authentication.

How Passwordless was popularized

As MFA and thus passwordless authentication strategies became more popular, passwords and authentication itself became a popular topic again.

The first sign of media interest was at a 2004 IT security conference, where Bill Gates publicly advocated for making passwords obsolete. Gates went over several of the security threats inherent to knowledge-based passwords. He then advocated for newer authentication technologies, including a tamper-resistant biometric ID card.

In late 2011, IBM predicted that "multi-factor biometrics" would become the dominant authentication protocol, creating a completely passwordless world. Their influential thought leadership spawned many other predictions and thought pieces.

Google pushed things further in 2013, when Eric Grosse, VP of security engineering, stated that "passwords and simple bearer tokens, such as cookies, are no longer sufficient to keep users safe." The company then made multi-factor authentication protocols standard within the organization, and that same year, Google's information security manager, Heather Adkins, put it bluntly, "Passwords are done at Google."

Then in 2014, after Russian hackers accessed the login credentials for over 1.2 billion internet users, Avivah Litan, VP Analyst at Gartner, reiterated the need to go passwordless. In her words, "Passwords were dead a few years ago. Now they are more than dead."

Finally, the rise of mobile has boosted the popularity of passwordless authentication. In 2013, Apple introduced Touch ID (and Face ID has since followed) making passwordless biometric authentication ubiquitous today. Additionally, passwordless strategies (i.e. sending an SMS-based magic-link) allowed mobile-first businesses, like Uber and Lyft, to authenticate users and perform account verification in a single easy step.

Is "Passwordless" here to stay?

There is no doubt that authentication technology and methodology will continue to evolve. The number of viable authentication methods will continue to grow, and inherently, most of these will be a passwordless one. Since two-factor and multi-factor authentication are widely popular (and in many use-cases a requirement), passwordless is definitely here to stay.

However, this doesn't mean that password-based methods will be completely replaced or that passwordless is right for everyone. To learn more about specific passwordless technologies and if they're the right choice for you, keep reading our series on passwordless authentication.

Passwordless 101

Clerk.dev — Fri, 01 Oct 2021 00:09:28 +0000

What is Passwordless Authentication?

Passwordless authentication is exactly what it sounds like: an authentication strategy to verify user identity without the need for the user to manually enter knowledge-based information.

As we outlined in the previous article in this series, passwordless methodologies have been in use since the 1980's, but were ultimately popularized in the 2000's as multi-factor authentication (MFA) and single sign-on (SSO) became standards.

From MFA and SSO to 'passwordless'

Multi-factor authentication requires users to provide multiple unique ways of identifying themselves, which can include:

Something the user knows, like an ID number, user name, and/or password
Something the user has, like a token, authenticator app, ubikey, email address, or phone number
Something that's part of the user, like facial recognition, finger print, or voice print

With single sign-on, a third party verifies the identity of a user, relieving sites and applications of the burden of storing and tracking credentials. When users log into a website, it checks with an SSO provider to confirm if they've already verified.

SSO and most of the MFA methods described above do not require the user to manually enter any information, and are thus, "passwordless".

Common Passwordless Authentication methods

Below is a brief overview of some of the most popular passwordless authentication methods.

Social sign-up: Social sign-up means a user is authenticated via an existing third-party, pre-verified account (e.g., Google, Facebook, Twitter). Most businesses see over 50% of users opt for social sign-in when offered, and sign-ins completed 35% faster than password users. B2C companies may do better with social sign-in options, especially those with a younger audience (e.g., under 50). However, some B2B companies may still benefit from social options. For instance, Mailchimp saw a 66% drop in failed login attempts after implementing social sign-ins, though only 3.4% of their users chose to use it.
Security Assertion Markup Language (SAML): SAML means a user can use one set of credentials on various apps, which the service provider stores. This is most common in enterprise environments, like with Microsoft products. IT teams for large companies appreciate the lightened load of support tickets when only global sign-on is required.
Magic link: Slack is probably the most well-known user of the Magic link, which sends an authorized URL to a unique user's email address or phone number to log in. Methods like a magic link have to play nicely with email providers, though, or they may end up in spam.
One-time passwords by SMS or email: This authentication method prompts users from their device or email to enter a unique code for signing on. Tech companies are making it easier to do this, like iPhone's ability to paste passcodes from SMS. 2FA using a one-time password authentication is a common strategy for financial institutions.
WebAuthn: Web authentication (or WebAuthn) uses public-key cryptography instead of password-based credentials to create a keypair for the specific user. The encryption needs the private key for the public key and vice versa, so it's harder to unlock. The downside is it's not completely user-friendly, and browsers don't use the same terminology.
Time-based one-time password (TOTP): This 2FA method uses time as part of the unique identifying authentication criteria. The time-sensitive unique code is then sent via SMS or directly to a browser. The TOTP Authenticator app is easy for users to set up and use for websites or apps and has an added layer of password protection.
The YubiKey: Yubico's hardware-based "strong two-factor authentication" option called YubiKey looks like your average USB device but packs a big security punch. This tangible option provides device-generated and password storage instead of relying on system or software solutions. Businesses may opt for the YubiKey to prevent phishing and create a similar authentication strategy for their teams.
Biometric: Think of your smartphone or spy movies (e.g., Face ID, Touch ID, eyeball scan). Small companies typically don't need biometric identification because they're expensive and unnecessary; however, this option is on the rise in the passwordless security landscape.

A Few Caveats for Passwordless Authentication

One drawback with passwordless authentication is that it doesn't truly exist yet. Even sophisticated authentication workflows will require the use of a password at some point. Also, passwords and credentials still need to be used as a backup, failsafe, or initial verification method.

Aside from this, every authentication protocol has its own disadvantages, for example:

Hardware fobs and physical tokens can be hard to implement
Security hardware can be left incompatible with various software after updates
Email accounts are not necessarily secure and phone numbers can be spoofed
Social network accounts can be compromised
Device-dependent biometrics can be useless if a device is lost or stolen
SMS security protocols are outdated, leaving these communications vulnerable and unprotected

Session management: What it is and why your security depends on it

Clerk.dev — Mon, 20 Sep 2021 22:52:57 +0000

Constantly having to log back in to your online accounts is a frequent annoyance - but this irritating problem stems from an inefficient solution to a genuine security concern.

Web applications need to make sure that your accounts are safe from hackers, and some handle that by requiring frequent re-authentication. Still, that's not the best solution. Proper session management can help apps like yours keep users safe *without *needing to constantly log back in.

Below, we'll cover the fundamentals of session management, what's required to implement it, and how it can help you keep your users safe without creating a frustrating user experience.

What is session management?

Session management is the process of facilitating private interactions between users and web applications. It specifically refers to managing different "sessions," or periods when the user is logged in and active in the application. The session management process lets users access their unique and potentially sensitive information securely without letting others get into their account, without forcing users to constantly re-authenticate.

Session management can take two forms: short-lived and long-lived. Short-lived sessions last only as long as the user remains in the application. Every time they leave the app, they need to re-authenticate to get back in.

Long-lived sessions keep the user logged in to the app even if they leave. These sessions store session IDs on the user's device, allowing them to reopen the app and start using it without needing to re-authenticate.

Long-lived sessions typically offer the best user experience, since they let people get into their accounts with no hassle. But this approach also has drawbacks. Anyone who accesses the device can also access that account as long as the session is still active, which is a security risk. For apps that contain sensitive information, short-lived sessions may make the user experience slightly more complicated, but will be more secure.

‌

The elements of session management implementation

Proper session management implementation involves three functions: creating session IDs, storing session cookies or tokens, and enforcing session expiry dates.

Here's what that means:

Session IDs

When the user first logs into the website or app, the server creates a unique session ID associated with the authenticated user. However, with each new request, the server still needs a way of identifying if the request came from that authenticated user without needing re-authentication. Which is where cookies or JWT tokens come in.

Session cookies vs. tokens

When the server creates a unique session ID, it also creates a cookie that is stored in the user's browser. The information contained in that cookie is sent along with each new request so the server understands it comes from the same authenticated user.

Session cookies are most commonly used with websites or web-based platforms. When it comes to modern web applications, a JSON Web Token, or JWT, is used instead.

When the user logs on with the right credentials, a JWT is created instead of a session ID and sends it to the user. The JWT is stored in local storage and the header of the token is sent with every new request.

This means that the user's state is not stored on the server, but inside the token, making this option more scalable and more useful for mobile device authentication.

Session expiry

Sessions are temporary states and expire under certain circumstances, such as the mobile app being closed, a set period of inactivity, or a maximum session duration that cannot be exceeded. Long-lived sessions may expire when the user hasn't interacted with the app in a certain number of days or weeks. The cookie or token storing the session ID should automatically delete itself at the end of those periods.

Security concerns addressed by well implemented session management

The purpose of session management is to help keep user data secure. Without appropriate session management, you can run into several security problems, putting your users at risk. Common vulnerabilities caused by a lack of or poorly implemented session management include:

‌Session hijacking

The cookies that you use to store session IDs need to be truly secure. Insecure session cookies are easy for hackers to predict or to use for brute-force attacks. If a hacker can spoof your users' session IDs, they can impersonate users and take over their accounts. This is known as session hijacking, and it can lead to the loss of sensitive information connected to the account.

‌Session fixation

If a specific session token can be used across platforms and without proper expiry protocols, it can be "fixated" by hackers. Essentially, the hacker tricks a user into logging in with a specific session ID, often by adding to the session ID in the URL argument, and then uses those credentials to log in to the user's account.

Session resources

Session management systems should beare resource-light, so that attacks, such as denial of service (DDoS) that flood the system with new session requests, don't consume huge amounts of resources.

‌Anomaly detection

Every application runs the risk of hacking attempts. If your session management tool doesn't have a way to detect abnormal patterns like brute force session ID guessing or DDoS attacks, you're more likely to fall victim to these attacks.

‌_Session expiry unset or too long_

Session expiration has two potential problems. If you don't set the timeout period, many programs may leave the cookie or token on the device forever, leaving the account vulnerable to anyone else with the device. Also, a set timeout period that's too long has the same issue.

‌

Stay secure with session management

‌Proper session management addresses all these concerns. It keeps your users and accounts safe by providing secure cookies or tokens, setting appropriate protocols and timeouts, and implementing anomaly detection.‌

Session management is a fundamental part of running a secure, trustworthy web application. By keeping a handle on your users' sessions, you can help them avoid the hassle of constant re-authentication without putting them at risk.

You can address all your session management needs by implementing a user management service, or you can write your own. Either way, your users will thank you for protecting them without making their lives more difficult.

Don’t underestimate the value of a secure, seamless ‘forgot password’ flow

Clerk.dev — Thu, 16 Sep 2021 22:03:59 +0000

Just about every software application today relies on individual user accounts to provide people with a personalized and private experience. However, as "software eats the world," the average user is managing an increasing number of accounts. Practically every online store, social media platform, SaaS product, newsletter, game, and group requires users to create an online account with a username and password. The average American adult has a total of 130 online accounts --- and they all need to be kept secure, which exacerbates an already all-too-common problem: lost and forgotten passwords.

That's why most apps offer password reset flows. This essential workflow allows users to reclaim their accounts while maintaining their security and privacy. Keep reading to learn about "forgot password" flows, how they work, and the best practices to keep in mind.

‌

What is a 'forgot password' flow?

If you've ever had to reset a password, you've gone through a "forgot password" flow. Users go through this self-service process to reset their passwords and reclaim their accounts. Any website, app, or other account that relies on passwords for security should have some kind of reset flow.

‌Why? Because users are prone to forgetting their passwords. It's also common for people to forget their accounts entirely or change devices and lose their saved passwords. Without some way for users to quickly and easily reset passwords and reclaim accounts, you may lose users, have to support multiple accounts for the same user, and/or deal with an overwhelming number of "forgot password" support requests.

‌

How 'forgot password' flows work

Password resets can be manual or automatic. Manual resets rely on the user reaching out to support by email or phone. The support team member asks them some kind of security or verification questions and resets their password accordingly. However, manual flows mean that a significant percentage of your support tickets will be password resets, taking up your staff's valuable time. Additionally, manual verification is often less secure than an automated process, and can be especially frustrating for a user that needs access quickly.

‌The alternative is to implement a self-service password reset (SSPR) process. These automated workflows allow users to reset their passwords or reclaim their accounts without human intervention. They're used by most websites, apps, and other password-protected systems to streamline the security process. Your support staff won't need to spend time answering password reset claims and can focus on more important work.

Each type of self-service flow works a little differently. For example:

Temporary passwords: This process will send the user a temporary password that they can use to access the system. The user then resets their password themselves once they're logged in.
‌Email verification: The system emails the user a link at their primary email address, and the link takes them to a dedicated password reset page.
‌SMS verification: The system sends the user a text to confirm they want to reset their password, with instructions to follow the reset link.
‌Passwordless logins: Passwordless flows send a one-time link to the user's email or phone, allowing them to log in without resetting their password at all. This can be great for a user that just wants to log in from a different device one time, or is pressed for time and wants to reset their password later on
‌Two-factor authentication (2FA) reset: Two methods are used instead of one to confirm the reset. The user confirms their identity one way and then resets their password with another method. The system may have them check their email or phone for the reset link, and then on the reset page, it may ask for a code that was sent to their phone or a sign-in authentication app.

‌

Why implementing SSPR workflows can be challenging

While password reset systems are essential, they can be a complex feature to implement on your own. Rolling your own password reset process means dealing with:

The constant evolution of best practices. Best practices regarding SSPR workflows are constantly evolving - from manual reset to security questions to email reset to SMS workflows to passwordless logins. You should keep up with these changes to make sure your password reset process stays secure and up-to-date.
‌Security maintenance. Password resets need to be a secure workflow end-to-end, or your users' accounts are at risk of being hacked. If you write your own, designing a secure process is your responsibility.
‌Design and integration. Your reset process might be technically sound, but it should also be frictionless and well-designed, as an easy sign in experience is critical to retention.
Complexity. Adding more authentication features and options can provide an excellent user experience when everything works right, but it also creates the potential for more "edge cases" where problems occur.

‌‌‌

Get started with password resets today

If your team has more pressing features to focus on than creating a password recovery flow, Clerk can eliminate the guesswork (and real work) of user management and authentication. Clerk makes it easy to add complete user management to your app in minutes today, while allowing you to easily make changes and add new features in the future.

Meet our Gatsby plugin

Clerk.dev — Wed, 15 Sep 2021 16:53:19 +0000

Learn how to add authentication and user management to your Gatsby app with Clerk.

At Clerk, our mission is to empower every developer to easily add authentication and user management to their apps.

We know it's hard to keep up with all the exciting new options out there, so we strive to create more tools and integrations, so you, the developer, can spend more time building what really matters: your app.

With that in mind, we're happy to announce our gatsby-plugin-clerk.

What it does

The plugin wraps our ClerkProvider component around the entire Gatsby app.

This has two benefits: keeping the layout component cleaner while grouping all the configuration in gatsby-config.js, alongside other plugins.

How to use it

First and foremost, install the necessary packages:

yarn add gatsby-plugin-clerk @clerk/clerk-react

# or

npm install gatsby-plugin-clerk @clerk/clerk-react

Now, let's configure the plugin on gatsby-config.js.

For this step, you'll need the frontendApi key of your Clerk application. To find it, go to your dashboard, choose the application and the instance you're working on, and locate the key on the Home tab.

// gatsby-config.js

module.exports =  {
    plugins:  [
        {
            resolve:  'gatsby-plugin-clerk',
            options:  {
                // OBS: Don't push your frontend API key to version control.
                // A safer approach is to set it as an environment variable for each environment your app will run in.
                frontendApi:  <YOUR_FRONTEND_API_KEY>
            }
        }
    ]
}

From here onwards, everything should work just the same. You can start using components like SignedIn and SignedOut from the root of your app.

// src/pages/index.js

import React from  'react'
import { SignIn, SignedIn, SignedOut, UserButton } from '@clerk/clerk-react'

function IndexPage() {
    return  (
        <>
            <SignedIn>
                <UserButton />
            </SignedIn>

            <SignedOut>
                <SignIn />
            </SignedOut>
        </>
    )
}

export default IndexPage

And that's it, in just a few steps, we added easy and secure authentication with beautiful and complete user management to your Gatsby app.

Bonus: Clerk + Gatsby starter

To make it even easier for you, we went ahead and created a Clerk + Gatsby starter repository. It has Clerk integrated with Gatsby's default starter.

Inside src/api you can also find the new Gatsby Functions in action. We added a couple of examples there, so you know how to use Gatsby's serverless functions with Clerk's backend API.

Fork it, clone it and build it!

Bonus 2: Deploy the starter on Gatsby Cloud

Ok, we owe this one to the Gatsby team. They did a great job in building a super easy deployment flow.

So, if you want to deploy the Clerk + Gatsby starter on Gatsby Cloud, just click here.

Once there, you can configure a number of things, like the Gatsby Cloud workspace the project should live in, the repository name that will be created in your GitHub account, and even add more integrations.

But here's the one thing you can't forget: your need to add your environment variables, like in the image below. If you don't know where to find them, check the README file of this starter.

Once you're done, head over to your GitHub account, find the newly created repository, clone it and start building.

And just like this, you can use all the benefits and performance that Gatsby Cloud provides to Gatsby apps.

If you encounter a permissions error while doing the steps above, here's what's happening: Gatsby Cloud requires permissions to create and manage future repositories on your GitHub account in order to create a new repository for you.

To fix it, go to your GitHub installations page, and configure Gatsby Cloud as such:

Need help?

If you're unfamiliar with how our prebuilt UI components or other details described in the guide work, you can always go to our documentation to find out more or reach out to us on our Discord server.

Happy coding!

Designing fast sign in forms— diving into the data

Clerk.dev — Fri, 02 Jul 2021 16:12:48 +0000

The modern web is obsessed with speed. Just this week, Vercel launched Next.js 11 with a special focus on Core Web Vitals, a new set Google metrics that are measured in tens of milliseconds to determine page speed. Google has noticed that faster websites mean better user experiences, and has incorporated these metrics into their search ranking algorithms.

At Clerk, we're focused on a speed challenge that's equally important but often neglected: how quickly can users sign in?

In working to optimize our prebuilt Sign In UI, we've learned a few surprising lessons we thought are worth sharing.

Social Sign In deserves the top spot

After much qualitative debate - Clerk originally launched with Google and Facebook sign in buttons below the option to sign in by email.

After collecting a few months of data, we realized we should make an adjustment. There was a near 50/50 split of users who preferred Social Sign In vs email and password. But, Social Sign In was also faster: ~5 seconds on average compared to ~8 seconds for email and password. So we made the switch:

In the months since making this change, Social Sign In usage has started to outpace email and password, with the last month seeing a 52/48 split.

As expected, since more users are now using a faster authentication strategy, that shift has also resulted in a faster overall speed of Sign In.

Passwordless should remain a fallback

The passwordless concept has existed in authentication systems for decades. If a user forgets their password, a code or link sent to their email address can be used to authenticate instead.

Recently, there has been a lot of buzz about promoting passwordless flows to the primary authentication mechanism. While we allow developers to configure Clerk in this manner, we recommend against it, and instead suggest leaving it as a fallback.

On average, we see passwordless flows take ~35 seconds to complete. Despite using Sendgrid to deliver our emails quickly and with high inbox rates, the process of checking email is just slow in comparison to Social Sign In or email and password.

The "edge cases" of Social Sign In are surprisingly common

While building Clerk, we cataloged any frustrating user experiences we encountered across the web and made sure to fix them. The source of many screenshots was Social Sign In - even among the web's biggest properties, it's common to stop users from using a Social Sign In if they didn't originally Sign Up that way:

While it's obvious that roadblocks like these slow the sign in process, handling them elegantly takes a lot of development time. Many developers are comfortable pushing off a proper solution because these scenarios feel like edge cases.

In practice, we've learned that these "edge cases" are surprisingly common. In fact, 15.9% of users who have used Social Sign In have also used another method. Of those:

2 in 3 originally signed up with a password then later chose Social Sign In
1 in 3 originally signed up with Social Sign In, then later tried signed in without (they were sent a code to their email)
At Clerk, we've invested heavily in handling these scenarios as elegantly and quickly as possible. Regardless of a user's choice of sign in strategy, they will always be linked to the same underlying account.

Clerk's prebuilt Sign In UI
Clerk enables developers to add beautiful, high-conversion Sign In form to their application in minutes. Our prebuilt UI can easily be themed to match any company's brand and style guidelines.

We're constantly analyzing the data in search of better user experiences, as well as evaluating new technologies for addition to our product. If you have questions or ideas for improvement, reach out to us on Twitter @ClerkDev, or through support.

This article was originally published on Clerk.dev by Colin Sidoti, CEO and Co-Founder of Clerk.

How we use End To End tests to bulletproof our authentication flows across browsers

Clerk.dev — Mon, 28 Jun 2021 10:37:07 +0000

In recent years, End To End testing has become a regular topic of discussion in small team environments. The main reasons for this are the evolution of tooling and the need to shift towards high velocity product development. At Clerk , we use End To End testing to create bulletproof authentication flows across browsers.

The 10,000 ft view of the End To End landscape

In the past, End To End testing was almost exclusively considered a Quality Assurance Engineering topic. For one reason or another, the development of test automation pipelines and application workflow validation tests were not so popular with software engineers.

That view has gradually become dated and replaced with the growing popularity of tools like Cypress, Puppeteer, Playwright, and even the latest version of Selenium.

The growth of those tools should not be seen as a simple technical advancement, but instead as an immediate answer to the growing need to efficiently and effectively validate fast moving development cycles of agile teams. At Clerk we deploy multiple times per day, and without these tools it would be impossible to ensure reliability.

The high bar for reliability at Clerk

As a solution for authentication and user management, Clerk must maintain exceptionally high reliability, even as our product and team expands rapidly around our core offering. It is critical that end-users can always access their accounts quickly, even through edge cases like originally signing up with Google, then trying to sign in with email instead.

We also take great pride in our developer experience, and often jump through hoops to ensure that Clerk works consistently across development, staging, and production environments and across all browsers.

To keep reliability high across our myriad of flows - and importantly, to give our own development team confidence that our product won't break with new deploys - it became clear the most pragmatic solution was to develop an End To End test suite.

Laying out our needs

These were our initial needs exactly as voiced by our team:

Cross-browser

The suite needs to cover all major browsers with as little external service interaction as possible.

Happy to code in - Meaning TypeScript

Most probably Frontend Engineers should be able to write and maintain the tests for the suite (with as much joy as possible).

Support containerized deployment

The suite needs to be portable enough to run on a GitHub Action workflow.

Choosing a platform

After investigating Selenium, Puppeteer, WebDriverIO, Cypress, and Playwright and weighing each platform against our needs, we decided to go with Playwright.

Although it felt less hyped, as a team we felt really confident in the architecture behind Playwright, its stellar documentation and tooling, and the excellent community backing the effort.

We will describe our exact selection process in a later post, but most critically, we appreciate the ability to execute our workflows across Chromium, WebKit and Firefox with so much ease and fine grained control.

How the suite is orchestrated

Our End to End test suite is a separate system from our main codebase as we have seen this pattern working really well for most applications.

Its main components as a Node.js application written in TypeScript are:

Playwright as the browser automation framework.
Jest as the test suite runner.
jest-playwright to connect Jest and Playwright as it makes our lives so much easier.
Faker.js to create API fixtures that fit our needs for the sign-up and sign-in processes fixtures.
Page Objects as the main pattern representing the interaction facade with our application views in code.

These components have proved to work together seamlessly while staying welcoming to our frontend engineering team. One of our main goals was to ensure that new teammates could understand the system quickly and create new tests, and so far this structure has exceeded our expectations.

Delivery of the suite on our day to day efforts

To keep us safe from accidental regressions, the test suite must run (and pass!) before any merge to production. To automate this process, integration with our Continuous Integration (CI) tooling was essential.

We run our CI through Github Actions, and fortunately, the Playwright team has created GitHub Action tools to simplify triggering the test suite. Paired with Vercel preview deployments, which is where most of our CI tasks take place, both Actions fit the spot quite nicely for End to End suite scenarios. The Playwright team has also created a GitHub action to quickly bootstrap Playwright tests.

The final action file that triggers our End to End suite on every pull request looks something like this:

jobs:
  e2e:
    if: github.event.deployment_status.state == 'success'
    name: End to End
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [14.x]
    steps:
      - uses: actions/checkout@v2
      - uses: microsoft/playwright-github-action@74fbf9d1a7c5d8735dab59804da3fdd367a98020
      - uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - name: Run Playwright tests
        run: cd e2e && npm install && npm run test

If the action succeeds, we are good to go!

Parting words

This was a really brief overview of how we went about designing our End to End test suite at Clerk . As Clerk and our customers' needs continue to evolve, we will continue to share our experiences with Playwright and any new tools we adopt.

_P. S. We have open sourced a template for starting up your own End To End suite using Playwright, so feel free to try it out! https://github.com/clerkinc/playwright-e2e-template

This article was originally published at Clerk.dev, by one of our engineers, Peter Perlepes.