Going Passwordless on epilot 360 with Custom Cognito Triggers
Roland

Roland @rolandg

About: I'd rather not, thanks though.

Joined:
Mar 5, 2024

Going Passwordless on epilot 360 with Custom Cognito Triggers

Publish Date: Jul 22
0 1

“Can we make authentication more secure and easier for our users?”

That’s the question we asked ourselves a few months ago at epilot. The result? A brand-new passwordless login experience on our 360 platform — built using Amazon Cognito’s custom authentication triggers.

Let’s walk through what we built, why we went with custom triggers over Cognito’s new native flow, and how we made passwordless the default for all users.

 
 
 

🧠 Background: Why Passwordless?

Passwords are the weakest link. People reuse them, forget them, and attackers love to steal them. With passwordless login, we take that burden off the user and instead send a secure, time-limited magic link to their email.

The benefits?

  • No password resets.
  • Fewer login support tickets.
  • MFA by design (if implemented correctly).
  • A more modern and smooth experience.

 
 
 

⚖️ Why Custom Triggers Over Native Passwordless?

Amazon Cognito recently released native support for passwordless login. We considered using that flow, but ultimately chose the "old-school" custom triggers route. Why?

  1. Cost: Native passwordless requires the Cognito Plus tier, which comes with additional per-user costs.
  2. Control: Our portals already used a custom trigger model for MFA. Extending that to passwordless gave us full flexibility over the UX.
  3. Stability: Native passwordless is still new and less battle-tested.

We reused our Lambda-based CustomAuthFunction infrastructure — just tweaked it to generate magic links instead of OTPs.

 
 
 

🔧 How We Built It

This is a diagram of the architecture:

 
 

Here’s a high-level overview of our approach:

  1. User submits their email on the login page.

  2. Cognito triggers the DefineAuthChallenge → CreateAuthChallenge → VerifyAuthChallengeResponse flow.

  3. Our Lambda:

  • Generates a time-limited magic link.
  • Emails the link to the user using SES.
  1. User clicks the magic link.
  2. The link contains the token → Cognito verifies the token via VerifyAuthChallengeResponse through JWT signing.
  3. If valid, boom 💥 — user is authenticated.

Bonus: Built-in MFA

The beauty of passwordless login using email is that it’s inherently two-factor, assuming you trust the email channel.

 

📸 Screenshot of the new login UI

The new landing page

 
 

🧬 Making It the Default

We didn’t just offer passwordless as an option — we made it the default experience. Here’s how we pulled that off:

  1. Updated the login UI to prominently feature the email-based login method.

  2. For existing users:

    • If they had a password, they could still use it.
    • But we nudged them towards magic links by making it the first visible choice.
  3. Behind the scenes, our custom trigger logic prioritizes passwordless, falling back to MFA or password only if necessary.

 

📸 Screenshot of fallback to password/MFA

Fallback to the classical login via email and password

 
 
 

🧪 Testing and Rollout

We followed our usual rollout strategy:

  • ✅ Developed the feature in a feature-flagged branch.

  • ✅ QA-tested flows with both new and existing users.

  • ✅ Migrated Cognito pools using updated IaC scripts.

  • ✅ Added observability (metrics + alerts) to magic link delivery success/failures.

  • ✅ Rolled out gradually across all orgs.

 
 
 

💬 Developer Takeaways

  • Custom triggers = full control, but more work: You own link generation, token storage, delivery, and cleanup.

  • Security is critical: we securely verified tokens, set strict TTLs, and monitored patterns for abuse.

  • Fallbacks are key: email might fail. Make sure users can still get in, securely.

  • The UX matters: reducing friction boosts adoption. One-click logins made users want to switch.

 
 
 

📈 Early Results (and KPIs)

  • ✅ 23% adoption rate for magic link logins. Already huge in a couple of weeks!

  • ✅ Zero reported incidents about login failures!

  • ✅ Internal devs love it: “this feels like logging into Notion or Slack”

 
 
 

🔜 What’s Next?

We’re always exploring at epilot: both how we can secure our platform and provide the best user experience for our customers and their end customers. Flexible passwordless logins and upgrading our MFA features are always on our mind.

 
 
 

❤️ Wrapping Up

Going passwordless isn't just a security upgrade — it’s a usability win. And with Cognito custom triggers, you can get there today without breaking the bank.

If you're running a SaaS product and thinking about passwordless, this approach gives you flexibility and power, without waiting for native support to mature.

As for the epilot customers, this approach is the research-backed (and if we might add, free of charge out of the box ) way to help keep your organization secure on our platform. Use and abuse it!

Special thanks to Brendon Faccion and Marta Osowiecka for their amazing efforts on this feature!

Questions? Thoughts? Want code samples?
Drop a comment below or DM me — always happy to nerd out about identity flows! Sincerely yours, Roland Gharfine (epilot Head of Security).

Comments 1 total

  • Alex Norman
    Alex NormanJul 24, 2025

    Hey Roland,

    Slick looking login page and agree with all your sentiments around why passwordless benefits usability and security. We use AWS too and always seem to run into places where Lambdas are the glue when the service doesn't natively do everything you want. It looks like you took a hybrid build it yourself and utilising a third party auth provider approach.

    Do you find maintaining your part of the code conflicts with Cognito's native features?

    If Cognito's passwordless was in a cheaper tier, do you think you would have just gone down that route? Or was the lack of UX customisability a deal breaker regardless of the pricing part?

    Cheers, Alex

Add comment