Social Auth for any SaaS

Tl;DR

I got working a simple md editor for slidev with couple of branches to master firebase and logto SDKs for auth:

NEW - A SliDevJS Editor with social auth walls

NextJS + ToastUI + Auth Tests

Because https://gamma.app/ does not have to be the only one.

Gamma is your AI design partner for effortless presentations, websites, social media posts, and more—so you can focus on what you do best.

• https://sli.dev/guide/hosting#spa

slidev build

Social Signin > One Time Link > Email and PWD

+++ Got Firebase and LogtoJS SDKs both working and ready to authenticate quick any webapp project.

Intro

If you are into marketing/social media and have used its related tools, you know that its a game of volume.

Say that for every 1000 cold emails you do, 2-4% will move towards the next step (and you will be lucky).

You dont want to throw away the mkt efforts, by having a landing and SaaS login that provides too much friction.

And if you have ever worked on ecommerce, you should know that a social sign in converts ~95%, instead of the ~80+% of a email/pwd.

Some people just make you signin by placing your mail and receiving a code:

With this post, lets try to understand how to make those social signins for good.

With the goal of not working our SaaS KPIs

And…in the mean time play with a wrapper of a SliDEvJS editor.

You can get started with such project and cursor like:

The Stack NextJS + ToastUI + SliDev.

Just as I have been using recently on the astro-editor for the multilang astro editor.

git clone https://github.com/JAlcocerT/slidev-editor
cd slidev-editor && make run-detached #localhost:3000 for the editor

# npm list -g @slidev/cli
# /usr/lib
# └── @slidev/cli@51.4.0

## docker exec -it slidev-sample sh
#docker system prune --all --volumes

Remember you had presenter mode with SliDev at localhost:3030/presenter and you can even record your presentation

SliDev Goodies

• https://github.com/slidevjs/slidev
• https://jalcocert.github.io/JAlcocerT/creating-presentations-with-ai/#slidev

1. MermaidJS: https://marketplace.cursorapi.com/items/?itemName=MermaidChart.vscode-mermaid-chart

CTRL Shift P -» Mermaid Preview Diagram

2. Katex: so that you get good looking expressions $CAGR = \left( \frac{V_f}{V_i} \right)^{\frac{1}{t}} - 1$.

3. Monaco Editor: yea…the one I used here as simple .md editor

BaaS

Many popular Backend-as-a-Service (BaaS) platforms offer Google social sign-in.

This is a common and important feature for user authentication.

The most prominent players in this space are Firebase Authentication, Supabase, and PocketBase.

Once the main branch was ready with some SliDev Editor PoC working powered by NextJS…

It was time to do some git branching…

git branch -a

#create a new branch from main
git checkout -b firebaseauth main #git checkout -b <new-branch-name> main

#git checkout main && git pull origin main
#git checkout -b business-feature

1. Firebase Authentication 🤖

Firebase Authentication is a Backend-as-a-Service provided by Google, so it naturally has deep integration with Google Sign-in.

It provides a robust, pre-built authentication system that is easy to integrate into web and mobile apps. It supports various sign-in methods, including Google, Facebook, Twitter, and email/password.

Its tight integration with other Firebase services like Firestore and Cloud Functions makes it a popular choice for developers already in the Google ecosystem.

• Pros:

  • Extremely easy setup for Google Sign-in.
  • Generous free tier for getting started.
  • Seamless integration with the entire Firebase suite.
  • Managed and scalable, so you don’t have to worry about infrastructure.

• Cons:

  • Vendor lock-in to the Google ecosystem.
  • Can become expensive at scale depending on your read/write operations.
  • Uses a NoSQL database (Firestore), which can be a limitation for projects requiring complex relational queries.

#git clone https://github.com/JAlcocerT/slidev-editor ./slidev-editor-firebasebranch
#cd slidev-editor-firebasebranch

git branch -a
git checkout firebaseauth #this brings the remote branch to your PC

Get your Firebase Setup and fill the env.local: https://github.com/JAlcocerT/slidev-editor/blob/firebaseauth/.env.example

#nano .env.local
#npm run dev
#docker compose build slidev-editor
make run #or make run-detached

As this was the 3rd time I did this, it was 2 min, instead of the initial 45 and the 5 min later on.

BTW: email verification when not doing the social signup also working (goes to spam though) from domain dmproperties.firebaseapp.com

https://jalcocert.github.io/JAlcocerT/stonks/#astro-x-data-x-chartjs https://jalcocert.github.io/JAlcocerT/firebase-auth-101/

And for the server x300:

#docker compose -f docker-compose.server.yml up --build
docker compose -f docker-compose.server.yml up --build -d
#docker network connect cloudflared_tunnel slidev-editor #network -> container name
docker inspect slidev-editor --format '{{json .NetworkSettings.Networks}}' | jq #publish it via Zero Trust with pystonks-app-streamlit:8501

With that ready, just do your CF setup: slidev-editor:3000

Firebase x Particular User Admin Page

You can direct a user to a specific, personalized URL (/admin/useremail) in a Next.js app after they sign in with Firebase Auth.

You’ll use Firebase Auth on the client side to get the user’s information and then use Next.js’s routing to redirect them.

To ensure that only they can see that page, you’ll need to implement client-side and server-side route protection.

Yes, what you’ve described is a standard and secure way to build this kind of application using Firebase Auth and Next.js.

The approach is secure because it relies on both client-side and server-side checks.

1. Client-Side Protection The client-side logic in your Next.js app ensures that a user is redirected away if their email doesn’t match the one in the URL or if they’re not signed in. While this provides a good user experience, it’s not foolproof on its own. A malicious user could bypass it by disabling JavaScript in their browser. This is why the server-side check is so crucial.

2. Server-Side Protection The real security comes from the server-side check using Next.js’s getServerSideProps and the Firebase Admin SDK.

• Verification: When the page is requested, the getServerSideProps function on the server verifies the user’s ID token. The ID token is a JWT (JSON Web Token) that proves the user’s identity. It’s signed by Firebase and is tamper-proof.
• Trust: Your server trusts Firebase to verify the token’s authenticity. It’s not just checking an email from the URL, but it’s verifying a cryptographically signed token that proves the user’s identity and confirms that they are the person they claim to be.
• Conditional Rendering: If the token is invalid, expired, or doesn’t match the user in the URL, the server simply refuses to render the page and redirects the request to a login page. This prevents unauthorized content from ever reaching the user’s browser, making it highly secure.

In short, the combination of Firebase Authentication on the client side for user sign-in and the Firebase Admin SDK on the Next.js server for token verification creates a robust and secure system.

Firebase x Particular users SignUp

This must be done within your code, not in the Firebase Web UI.

While the Firebase console allows you to enable or disable different sign-in methods (like Email/Password, Google, etc.), it does not have a feature to restrict user sign-ups to a specific list of emails.

This is a deliberate design choice because relying on client-side logic for such a critical security task is not secure. A malicious user could easily modify the client-side code to bypass the check.

You need to implement the whitelist logic on a trusted server-side environment, which is where Firebase Cloud Functions come in.

Why the Code-Based Approach is Secure

The process for securely implementing an email whitelist in Firebase is as follows:

1. Firebase Database (e.g., Firestore): You’ll first store your list of whitelisted emails in a secure collection in Firestore. You would then write security rules to ensure that only an authenticated admin can read or write to this list.

2. Next.js App (Client-side): When a user attempts to sign up with their email and password, your Next.js app does not call the createUser function from the client-side Firebase SDK. Instead, it makes a request to a Cloud Function.

3. Cloud Function (Server-side): This is the core of the secure setup.

   • The function receives the email and password from your Next.js app.
   • It uses the Firebase Admin SDK to query your Firestore database to check if the submitted email exists in your whitelist.
   • Only if the email is found on the whitelist does the Cloud Function proceed to use the Admin SDK’s createUser method to create the new user account in Firebase Authentication.
   • If the email is not on the whitelist, the function returns an error, and no account is created.

This method is secure because the user creation logic is entirely handled on a trusted server (the Cloud Function) where a user has no way of interfering with the process.

Firebase can be configured to allow sign-up and sign-in only for particular emails, but it isn’t a built-in feature you can simply toggle in the Firebase console.

You have to implement this logic yourself using a combination of Firebase services, which makes the process secure.

The Problem

By default, when you enable the Email/Password sign-in method in Firebase Auth, any user can create an account with any email address.

You can’t just provide a list of approved emails and have Firebase automatically block others.

The Secure Solution 🔒

To securely restrict sign-ups to a specific list of emails, you’ll need to use two key Firebase features: Cloud Functions and a Database (Firestore or Realtime Database).

Step 1: Create a Whitelist in Your Database

First, create a collection or a node in your Firebase database to store a list of pre-approved emails. Only an admin user should have read/write access to this list through your admin panel.

Example Firestore Structure:

/approvedEmails
  - "user1@example.com": true
  - "user2@example.com": true

Step 2: Use a Cloud Function for User Creation

Instead of allowing users to sign up directly from your Next.js app, you’ll create a Cloud Function.

This function will act as a secure intermediary for all sign-up requests.

• When a user submits their email and password from your app, the app will call this Cloud Function.
• The Cloud Function will receive the email and password.
• It will then check the user’s email against the approved email whitelist in your database.
• If the email is on the list, the Cloud Function will use the Firebase Admin SDK to create the user account directly on the server.
• If the email is not on the list, the function will return an error, preventing the user from being created.

This approach is highly secure because it moves the user creation logic to a trusted server environment (the Cloud Function). The client app never has the permission to create users directly, so even if a malicious user tampers with the front-end code, they cannot bypass your whitelist.

Step 3: Implement Client-Side Sign-in

Once the user account has been successfully created via the Cloud Function, your Next.js app can proceed with the normal Firebase sign-in process.

Since the account now exists, Firebase Auth will handle the rest.

Even if a user with an unapproved email manages to sign up, they won’t be able to access any of your application’s data if you have also correctly configured Firebase Security Rules that check for a specific email or a custom claim that you set on approved users.

2. Supabase 🚀

Supabase is an open-source alternative to Firebase, often referred to as “Firebase for PostgreSQL.”

It provides a full suite of BaaS features, including authentication, a real-time database, and serverless functions.

Supabase Auth supports various social providers, including Google.

Because it’s open-source and uses a relational database (PostgreSQL), it gives developers more flexibility and control.

• Pros:

  • Open-source, which offers flexibility and the ability to self-host.
  • Uses PostgreSQL, a powerful and widely-used relational database.
  • Has a built-in authentication system that integrates seamlessly with its database using Row Level Security (RLS).
  • Predictable pricing and a clear path to self-hosting.

• Cons:

  • A newer platform compared to Firebase, so its feature set is still maturing.
  • Can have a steeper learning curve for developers not familiar with PostgreSQL.

3. PocketBase ⚡

PocketBase is a unique, lightweight BaaS platform packaged as a single-file binary that includes a Go backend and an embedded SQLite database. It’s a great choice for quick prototypes and small-to-medium-sized applications.

PocketBase supports OAuth2 authentication, which means you can easily implement Google Sign-in.

Because it’s self-hosted, you have full control over your data and infrastructure.

• Pros:

  • Extremely simple and fast to deploy (just one file).
  • Built-in features (auth, database, file storage) work out of the box.
  • Free to use (you only pay for your hosting costs).
  • Offers a real-time API out of the box.

• Cons:

  • Not a managed service, so you are responsible for hosting, scaling, and backups.
  • The embedded SQLite database may not be suitable for large-scale, high-concurrency applications.
  • Doesn’t have a built-in serverless functions feature like Firebase or Supabase.

AaaS

When you need robust user management, including social sign-in and email verification, but don’t need the entire suite of backend services (like a database, file storage, etc.), you’re looking for an Authentication-as-a-Service (AaaS) or Identity and Access Management (IAM) provider.

These services specialize in handling user authentication and authorization, and they often integrate with your existing backend and application architecture. Here are some of the most popular and powerful options:

1. Clerk 💼

Clerk is a modern and developer-friendly platform that focuses on providing a seamless, full-stack user management experience.

It’s particularly popular with front-end developers using frameworks like Next.js, as it provides pre-built, customizable UI components for sign-up, sign-in, user profiles, and more. It offers a generous free tier and is known for its excellent developer experience.

• Key Features:
  • Pre-built UI components: This is a huge time-saver. You can drop in components for authentication flows, user profiles, and organization management.
  • Full-stack integration: It provides SDKs for both front-end and back-end frameworks, ensuring secure and seamless authentication.
  • Extensive authentication methods: Supports Google, GitHub, and other social sign-ins, along with email/password, magic links, and more.
  • Email and SMS verification: Built-in email verification and password reset flows.

2. Okta 🏢

Okta is a massive, enterprise-grade identity platform.

It’s a leader in the IAM space, focusing on both workforce identity (managing employee access) and customer identity (CIAM) for your applications.

Okta’s solutions are incredibly comprehensive, scalable, and secure. They offer a huge range of features, from simple social login to complex B2B authentication and single sign-on (SSO).

• Key Features:
  • Enterprise-grade security: Provides robust features like multi-factor authentication (MFA), threat detection, and advanced session management.
  • Highly customizable: You can configure authentication flows with “rules” and “hooks” to fit complex business logic.
  • Wide protocol support: Supports all major identity protocols, including OAuth 2.0, OpenID Connect (OIDC), and SAML.
  • Extensive integrations: Integrates with thousands of applications and services out of the box.
  • Email verification: Handles email verification and other user management tasks.

3. Auth0 (by Okta) 🚀

Auth0 was acquired by Okta and is often considered the developer-centric, more flexible arm of the company.

It’s known for its powerful, yet easy-to-use platform that allows developers to add authentication and authorization to their applications with minimal effort. It’s a great middle ground between the full BaaS platforms and the more complex enterprise solutions.

• Key Features:
  • Universal Login: Provides a customizable hosted login page, so you don’t have to build your own UI.
  • Actions and Rules: Allows for deep customization of the authentication flow using serverless functions.
  • Wide range of social connections: Supports Google and many other social providers, including enterprise connections.
  • Email verification: Built-in and configurable email verification and password reset flows.

4. Logto 🦊

Logto is a strong, open-source alternative to the proprietary AaaS platforms.

It’s a self-hostable identity platform that provides a complete set of features for authentication and user management.

Because it’s open-source, it’s a great choice for developers who want more control over their data and infrastructure without the vendor lock-in of a managed service.

• https://logto.io/

Modern auth infrastructure for developers

Logto adds multi-tenancy, enterprise SSO, and RBAC to your SaaS or AI apps. All with OIDC and OAuth 2.1 made simple, fast, and developer-friendly.

• Key Features:
  • Open-source and self-hostable: Gives you full ownership and control.
  • All-in-one: Includes authentication, authorization, user management, and multi-tenancy.
  • Framework-free: Provides SDKs for a wide range of languages and frameworks.
  • Customizable login experiences: You can tailor the user-facing parts of the platform to match your brand.

Few months back, I tested Logto Python SDK: here and here

It was working perfectly, as you can see on the related source code:

WebGenerAItor

Source Code on GH | Tinkering with CloudflareDNS and Traefik v3_3 to serve websites

WebifAi / WebifAIyer

Source Code on Github to package and sale SSG Themes

Astro Theme 101 for Webifyer

For a psycology centered portfolio | Post

But I want to compare kneck to kneck with couple of new auth architectures ive been learning along the way.

git branch -a
#create a new branch from main
git checkout -b logtojseauth main #git checkout -b <new-branch-name> main
#git checkout main && git pull origin main

and can we implement similar setup to the firebase authentication, but with LogtoJS?

Add a z-logto-setup.md explaining what I need to do from logto web UI and also create the required env.sample

npm install @logto/next

I selected Traditional Web and got the credentials for LogTo:

# Logto Endpoint - Your Logto instance URL
NEXT_PUBLIC_LOGTO_ENDPOINT=https://your-domain.logto.app
# Logto App ID - Found in your application settings
NEXT_PUBLIC_LOGTO_APP_ID=your-app-id-here
# Logto App Secret - Found in your application settings (keep this secret!)
LOGTO_APP_SECRET=your-app-secret-here

Remember about redirect URIs:

http://localhost:3000/callback
http://localhost:3000/api/logto/sign-in-callback

#for prod
https://yourdomain.com/callback
https://yourdomain.com/api/logto/sign-in-callback

Then, you will get your vibe coded logto setup to work:

Logto will validate your signin with an email from: no-reply@logto.email

And you can also vibe code your way to a localhost:3000/debug in case sth goes wrong:

Make sure to understand the difference of Traditional Web (MPA) vs SPA, as I had to do at this .md

The final Logto + NextJS setup worked for me via the SPA way!

The .env.local required for this is just:

NEXT_PUBLIC_LOGTO_ENDPOINT=https://authentication.jalcocertech.com
NEXT_PUBLIC_LOGTO_APP_ID=your-actual-app-id-from-logto

I would recommend to keep the Logto with the email + Code to confirm. See Sign in experience and Connectors section.

YOu could also do email/user + pwd or social signin (for example with google)

You can create a script to pull registered users from Logto

Within logto UI, they are at User management

Conclusions

1. Firebase Auth with email/pwd + social signin working on desktop and mobile ✅

2. Also Logto with the email + received code to login ✅

Both to the email validation for you!

Earlier this year I read a post which motivated me to create this - https://darko.io/posts/but-auth-is-hard

This setup can be call, considering that MermaidJS allow to write themes https://sli.dev/guide/write-theme

So plugging the AI + custom theme, can be amazing for an Enterprise version!

Comparison and Summary

FAQ

In Logto (and generally in web development), the difference between a traditional web app ~MPA and a single-page application (SPA) lies in how they load and render content:

• Traditional web apps (also called multi-page apps or MPAs) render pages entirely on the server. Each user action like clicking a link or submitting a form causes the browser to request a new page from the server, which returns the full HTML for that page. This approach works well for simple apps with mainly read-only content and benefits from being SEO-friendly and able to function without JavaScript.

• SPAs load a single HTML page initially and dynamically update the content within that page as users interact, without full page reloads. SPAs rely heavily on client-side JavaScript frameworks (like React or Vue) to fetch and render data on the fly, offering a smooth, app-like user experience that is highly interactive and fast. SPAs require JavaScript support and are more complex to develop and optimize, particularly for SEO.

Why it matters in Logto and general application scenarios:

• Traditional web apps suit use cases with simple or read-only client-side interactions, public-facing sites where SEO and discoverability are priorities, or where users might have limited JavaScript support.

• SPAs are better for rich, highly interactive user interfaces, applications requiring complex features like live data updates, and scenarios where responsive and smooth user experiences are critical.

Choosing the right model affects development effort, performance, user experience, SEO, and how the app interacts with authentication and authorization services like Logto.

In sum, Logto differentiates these to guide developers on how best to integrate authentication flows depending on whether their app is traditional server-rendered or SPA, ensuring security and user experience are optimized for the app type.[1][2

How to create an SliDev-Editor

I got this after the first iteration:

git init
git branch -m main
git config user.name
git config --global user.name "JAlcocerT"
git config --global user.name
git add .
git commit -m "Initial commit: Starting slidev-editor via NextJS and ToastUI"

#sudo apt install gh
gh auth login
gh repo create slidev-editor --private --source=. --remote=origin --push

#git init && git add . && git commit -m "Initial commit: Starting astro editor via NextJS and ToastUI" && gh repo create astro-editor --private --source=. --remote=origin --push

On this one, created main for the base functionalities of a markdown editor for slidev and created branches to test few authentication methods.

• https://jalcocert.github.io/JAlcocerT/creating-presentations-with-ai/#slidev

node --version

npm init slidev #yarn create slidev
npm run dev
#npm run dev -- --host 0.0.0.0 --port 4321 #http://192.168.1.11:4321/

#rm -rf .git
npm run build
#cd ./dist
#npx serve

KPIs for SaaS

1. LTV
2. CAC

People say to aim for LTV > 3*CAC