Security

Exploring Passwordless Authentication at Metal Toad Hackathon

Exploring the integration of passwordless authentication using AWS Cognito at Metal Toad Hackathon, enhancing security and user experience while overcoming implementation challenges.


Imagine a world without passwords, yet still secure. That’s what we aimed to explore during a three-day hackathon at Metal Toad. The hackathon objective was to pick any sample code from the AWS GitHub repository and build upon it. After some consideration, we chose a solution that piqued our interest: passwordless authentication.

Passwordless login promises stronger security while removing the hassle of managing passwords—something that could transform the way users and developers approach online security. We saw this as an opportunity to not only learn how to deploy several types of passwordless authentication within our own apps, but also to potentially offer it as a solution for our clients at Metal Toad.

In this post, we’ll walk you through how we adapted the AWS Cognito passwordless authentication sample code to fit our hackathon project. We’ll also detail some of the challenges we faced while adapting the sample repo to a new application and share our key takeaways from the process.

Making Life Easier for Users and Apps Safer

When we think about logging into any apps or services, passwords act as a necessary evil. Passwords continue to be a problem for users, with the best practice of using a separate password for each site essentially requiring the use of a password manager or vault, something a lot of users have difficulties with. Even with the use of a password vault and unique passwords for each site, passwords are still subject to phishing attacks, compromise of password vaults, the need for multi-factor-authentication to add another layer of security, and even if the user does everything correctly, the need for the site that uses the password to store some sort of representation (ideally a properly hashed value, but all-too-often something as simple as an unencrypted password) means that the user that does everything correctly can still get bitten by a compromised site. And woe to any user who re-uses a password on moret han one site, only to find one compromised site leads to more compromised sites.

That’s where passwordless authentication comes in—a solution that ideally simplifies the login process and also strengthens security for both users and the applications they rely on. 

 



For Users: A Simpler, Safer Experience

Goodbye, Passwords

With passwordless authentication, the user no longer needs to type or remember passwords. Newer authentication systems rely on more secure models, like passkeys, which are more secure on a number of levels, or magic links sent via email, which, while subject to certain windows of vulnerability, don’t require a user to remember or store a password for a site, but instead generate individual, short-lived credentials for that site.

These designs remove the vulnerability of passwords and replace them with methods that are are either inherently more secure, user-friendly, or both.1.1.2 Faster, Easier Access

Depending on the method, passwordless authentication is near-instantaneous. A glance at your phone for Face ID, or a tap of your finger for Touch ID, and you’re in. For other users, a magic link via email puts login and authentication through a familiar interface: email, instead of requiring a ‘complex’ interface such as a password vault.

Security Without (As Many) Headaches

Passkey authentication systems are inherently more secure because they use public-key cryptography. Instead of transmitting a password over the internet (which could be intercepted or accidentally sent to the wrong site), your device verifies your identity locally and communicates securely with the server. This protects your data from phishing, password theft, and other attacks.

There are some challenges to consider. While users won’t forget passkeys or (usually) change biometrics, losing access to a device or facing issues with biometric recognition can present hurdles. Passkeys don’t currently have a defined import/export mechanism. Magic Links, while suitable for certain applications, still have windows of vulnerability and lack multi-factor authentication and the security of public key encryption. Developers must implement robust fallback options, such as secondary devices or account recovery methods, to ensure users can still access their accounts securely if these issues arise.

Consistency Across Devices

Passkeys can sync across devices if the passkey is set up within certain sharing frameworks, making switching between devices easier. Whether you're logging in from your phone, tablet, or laptop, your secure credentials follow you, no extra setup needed. However, this is only within certain ecosystems, such as Apple Devices, or multi-device credential applications like 1Password.

 

For Applications: Stronger Security, Less Hassle

For developers, passwords have always been a double-edged sword. They’re a necessary evil, but they also introduce a lot of risk and overhead. Here’s how passwordless authentication can affect applications.

Stronger Defense Against Breaches

With passwordless authentication, the biggest security vulnerability—passwords themselves—is eliminated. Traditional passwords are often stored on servers, making them a prime target for hackers. Passkey systems, on the other hand, rely on public-key cryptography, which means no passwords are stored on the server. In the event of a data breach, only the server-side credentials are affected, localizing the scope of the breach to that application environment. In the case of Magic Links, even less information is kept server-side, albeit at the cost of less security than when using passkeys.

Smoother Onboarding, Fewer Abandoned Signups

The more difficult the signup process, the more likely users are to abandon that process. Passwordless login options can cut down on this friction by allowing users to get started without needing to create or remember a password. This might lead to higher sign-up completion rates and more users returning thanks to simple, one-tap logins or use of authentication workflows users are familiar with.

However, the effectiveness of this approach depends on the implementation. Some applications still require users to create a password before enabling passwordless options, which can add an extra step to the process. In addition, passwordless authentication is new to most users, compared to the ‘login and password’ workflow most users are accustomed to. Some users might even see a passkey system as less secure for their own purposes due to loss of control of their login credentials (limited import/export options, and certain passkey requirements which could limit the applications allowed to contain passkeys compared to a standard password vault or even pen and paper). But, as passwordless authentication becomes more widely adopted, we’re likely to see the need for initial password creation diminish, possibly even entirely for many sites and applications.

Reduced Support Overhead

Password resets are one of the most common pain points. Passwordless systems can help reduce this burden, as users no longer need to remember or reset passwords. With passkeys, the likelihood of forgetting login credentials drops, which can result in fewer password-related support requests. With Magic Links, fresh login credentials are generated for every session.

It is important to recognize that while passwordless authentication minimizes some types of support issues, it introduces new ones, such as helping users recover access if they lose their device and cannot recover or sync their passkeys from a backup or different device. Similarly, loss of access to a primary email account could render Magic Links ineffective until access is restored, and the corporate workflow for recovering an account attached to a permanently lost email account would be painful and possibly too expensive to support. 

Building Trust Through Security

In a world where data breaches and phishing attacks dominate headlines, users are increasingly concerned about security. Offering passwordless authentication is a signal to users that your application prioritizes user safety without sacrificing ease of use. 

Increased Speed

While passkeys are still in their early days of deployment, there are case studies where implementation of passkeys leads to a faster, easier user experience. In Japan, the Tokyu Corporation (a rail company) implemented passkeys in their mobile application, leading to a 12x faster sign-in experience for users.

Future-Proofing Your Application

As more apps adopt passkeys, password-based systems can begin to feel outdated. Integrating passwordless authentication future-proofs applications and increases options for users and developers. Magic Links can obviate the need for login credentials beyond per-session tokens. Passkeys can provide a higher degree of mutual security for both users and developers, and in the future will allow for better multi platform synchronization of credentials.

 

Our Goal

Using the AWS Codebase, implement the tutorial and then extend to using passwordless authentication on an existing Metal Toad project. More specifically Magic Link and Passkeys.

Original Sample Code Overview

Chosen Repository

For the hackathon, we selected the Amazon Cognito Passwordless Auth solution available on the AWS Samples repository collection. An AWS solution to implement passwordless authentication with Amazon Cognito.

AWS Sample Code

The AWS sample code focuses on creating passwordless login flows using Amazon Cognito, a service designed for secure user authentication. It simplifies the process of setting up passwordless login, making it easier for developers to integrate these flows into their applications using AWS resources.

The original solution, packaged as an NPM module, provides a full-stack reference for implementing secure, passwordless authentication across web and mobile platforms, and includes several key components:

  • A CDK construct that deploys a Cloud Formation stack containing an Amazon Cognito User Pool with custom authorization flows, integrated with other AWS services like Lambda, DynamoDB and HTTP API.
  • Web functions for use in web applications to simplify front-end integration with passwordless authentication.
  • React and React Native hooks to streamline the implementation of passwordless authentication in these frameworks.
  • Prebuilt React components that can be easily dropped into your web application to quickly set up passwordless authentication as a foundation for further customization.

The provided passwordless authentication methods are:

  • FIDO2 (WebAuthn): Allows users to sign in with biometrics like Face ID, Touch ID, or hardware keys (e.g., YubiKey). It also supports Passkeys, enabling authentication without providing a user name outside of the passkey itself.
  • Magic Link Sign-In: Sends users a one-time-use link via email to log in without a password, usable across browsers
  • SMS-based Step-Up Authentication: Verifies users already signed in with an SMS-based One-Time Password (OTP), without requiring them to enter a password again

Challenges:

The original solution isn't fully compatible with Terraform, and the npm package only works on Node backends. It also creates AWS resources through a CloudFormation stack, which isn't ideal for most Metal Toad projects infrastructure setup.

What Did We Do?

To solve this, we created a Node backend with the sole purpose of uploading the CloudFormation stack to our AWS account using the amazon-cognito-passwordless-auth library and CDK commands (see code above) following this tutorial. The library was configured to create only the necessary resources for our project given the following diagram:

Then, from the CloudFormation console, the template was retrieved and customized to fit our needs. A key change we made was to remove the creation of new Cognito user pools and clients, as we needed to work within an existing project’s environment. (One of the other Hackathon projects was also based on CDK but then used an LLM coding model to convert the CDK to Terraform, something we might consider doing in the future.)

Now, with the template in hands, we can add it to any existing terraform project. Therefore, to serve as an example, a new terraform backend was created and granted the necessary cloud formation permissions and github actions configuration (see images above). The terraform created the following:

  1. An S3 bucket to store the template (since it was too big to be inserted directly into text).
  2. A CloudFormation stack with:
    1. The template_url as the bucket object url.
    2. "CAPABILITY_IAM" on the capabilities list.
    3. Some parameters to reference in the stack like: the ID and ARN of our user pool, ID of the user pool client, verified SES email address for the magic links and allowed origins for the API Gateway and other resources.
    4. Take note that some of the parameters are the same provided on the nodeJS code.

This approach let us bridge the gap between the original solution and our Terraform-based infrastructure, making it more adaptable for future projects.

Frontend Implementation

We now  implement Amazon Cognito Passwordless Auth on the frontend of the existing React application we chose.

Following this example provided on the github as a base, we began by installing the amazon-cognito-passwordless-auth NPM package.

Next, we initialized the configuration, providing the credentials obtained from our backend setup.

To integrate the passwordless functionality into our application, we wrapped it in a Context Provider provided by the newly installed library. Using the usePasswordLess hook, we gained access to essential functions like signOut, signInStatus (for monitoring user status and redirect accordingly), tokensParsed (for retrieving user information), and more.

A component from the same library handles the sign-in process and displays the necessary UI. This component could be seamlessly integrated anywhere within our application.

Finally, minor adjustments were made to the CSS to align the sign-in screen with our existing web application's style.

Lessons Learned and Best Practices

Why We Chose Terraform Over CDK

While CDK is a great tool for defining infrastructure, we decided to use Terraform for this project, given our team’s experience and the fast-paced environment of the hackathon. Terraform offered several advantages that fit our workflow:

  • Familiarity and Efficiency: Terraform is widely used at Metal Toad, allowing us to move quickly and leverage existing expertise for configuring and managing infrastructure.
  • Multi-Cloud Flexibility: Terraform’s cloud-agnostic nature gave us the flexibility to define infrastructure that could be adapted across multiple cloud providers, which is more versatile than CDK’s AWS-centric approach.
  • State Management: Terraform’s built-in state management enabled us to track infrastructure changes, making it easier to collaborate and ensure smooth updates throughout the project.

Takeaways

This AWS solution and implementation is for development purposes only. Some securities measures were skipped, making it not production-ready.

Here are some notes to have in mind:

  1. Study carefully and thoroughly the library for any tutorials, issues and warnings.
    1. Token (JWS) Storage
    2. Some security best practices
    3. FAQ
    4. Issues
    5. End-to-end example
  2. We plan on migrating the whole cloud formation template manually to terraform. This way we:
    1. Get rid of a static CloudFormation template.
    2. Get rid of the need to run CDK to generate the initial CDK templates.
    3. Make it easier to adapt to any new/existing projects and add/remove resources as we see fit.

Similar posts

Get notified on new marketing insights

Be the first to know about new B2B SaaS Marketing insights to build or refine your marketing function with the tools and knowledge of today’s industry.