Coder Legion - Recent posts tagged authentication

Lock Your Inbox: Email 2FA, Passkeys and App Passwords

Wed, 28 Oct 2026 13:51:22 +0000

This article was originally published on the [@fuck.it] blog and is republished here by the author.

There is a quiet assumption sitting behind almost every account you own: that if you ever lose your way in, your email will let you back. Click "forgot password," wait a moment, and something arrives in your inbox that puts you back in charge.

It is a reasonable way to build things. It also means your mailbox is not really one account among many. It is the drawer where the spare keys to the others are kept, which makes it the one account worth being fussy about.

So here is the fussy version. What the options actually do, which of them hold up against a convincing fake login page, the one feature that quietly undoes the rest and how to switch all of it on.

TL;DR

Use a passkey or a hardware security key if your provider offers one. They are phishing-resistant in a way that SMS codes and authenticator codes are not.
Use an authenticator app if it doesn't. Enormous improvement over nothing. Still phishable.
SMS codes are the weakest real option. NIST's current guidelines classify exactly one authenticator as restricted, and this is it.
Save your recovery codes somewhere that is not the inbox they unlock. Locking yourself out is a very real way to lose an email account.
App passwords bypass your second factor completely. That is their entire job. Create one only when a client demands it, keep it to one per device and revoke it when you are done.
Your recovery address and recovery phone are keys too. A locked front door and an open window is not security.

Why the Inbox Is the Wrong Thing to Secure Casually

Almost every account you own has a button that says it will email you a way back in. That is sensible design. It also means that for a great many of your accounts, the real lock on the door is your mailbox, however strong the password on each individual one happens to be.

Attackers worked this out long before users did. Taking over an inbox is not usually the goal. It is the tool. Once somebody is reading your mail they can trigger resets, collect the codes, approve the changes and delete the warning messages on the way out, without ever having to attack the accounts they actually want.

So if you are going to be fussy about exactly one account, make it this one. Everything in this article is worth doing on your email before you do it anywhere else.

What People Mean When They Talk About 2FA

There are four of them in common use, and they are not equivalent. The gap between the best and the worst is wider than most people assume.

A code by SMS. The provider texts you six digits. Better than nothing, and worse than every other option here. The weakness is not the code, it is the phone number. Numbers get moved to a new SIM by somebody who has talked a carrier employee into it, and your codes move with them. The problem is real enough that the FCC adopted rules in November 2023 requiring carriers to authenticate customers properly before a SIM change or a port-out, and to offer you a free account lock against both. NIST's 2025 authentication guidelines go further: use of the phone network for out-of-band verification is classified as restricted, and at publication it was the only restricted authenticator in the document. Services may still offer it, but they have to provide something better alongside it and tell you about the risk.

A code from an authenticator app. A six-digit number that changes every thirty seconds, generated on your device from a shared secret. No phone number, no carrier, no text message to intercept. This is a very large upgrade, and for most people it is the realistic default.

It has one specific weakness worth understanding, because it is the weakness that catches people who thought they were safe. Typing a code into a web page does not tie that code to the real site. NIST puts it plainly: manual entry does not bind the output to the session, so an impostor verifier could relay it. In practice, a fake login page that looks right can collect your password and your code, pass both to the real provider inside the thirty seconds they are valid, and let itself in. Ready-made tooling for exactly this has existed for years. An authenticator app defeats password reuse, credential stuffing and opportunistic attacks. It does not defeat somebody who has got you onto a convincing fake page.

A push notification you approve. Your phone asks "was this you?" and you tap yes. Convenient, and vulnerable to the oldest trick in the catalog: send the prompt over and over at eleven at night until the human taps approve to make it stop. The better implementations use number matching, where the login screen shows you two digits that you have to type into the app. That kills the half-asleep approval, and it is worth turning on wherever you are offered it. Against a live fake-page attack it is in the same boat as an authenticator app.

A passkey or a hardware security key. This one differs in kind rather than in degree, so it gets its own section.

What a Passkey Actually Is

A passkey is a pair of cryptographic keys. The private half stays on your device or in an encrypted credential manager and never travels to the site you are signing into. The site keeps only the public half, which is useless to a thief. When you sign in, your device proves it holds the private key without ever revealing it.

The part that matters for phishing is less obvious and more important. When a passkey is created, it is bound to the exact domain that created it. A passkey you made for your bank will not answer a request from your-bank-secure-login.example, no matter how perfect the copy of the page is, because your browser will not even offer it. NIST calls this verifier name binding, and names WebAuthn, the standard passkeys are built on, as the example of how to do it.

That is the whole argument, so it is worth reading twice. With an authenticator app, your safety depends on you noticing the fake site. With a passkey, the fake site gets nothing even when you do not notice. The decision has moved from your judgment at eight in the morning to a check your browser performs every single time without ever getting tired or distracted.

Two honest drawbacks, both smaller than they were a year ago and neither of them gone.

First, a synced passkey puts part of your security in the hands of a credential manager and its account recovery. Moving them used to be close to impossible. That has improved: Apple's iOS 26, iPadOS 26 and macOS 26 releases and recent Android versions support transferring credentials directly between credential manager apps on the same device, and Apple Passwords, 1Password, Bitwarden, Dashlane and others have adopted it. The underlying work is only half finished, though. The exchange format reached proposed-standard status in 2025, while the protocol for actually moving credentials between providers is still a working draft that explicitly says it is not a basis for implementations. Same-device switching between participating credential managers works today on both Apple and Android. What does not exist yet is a finished universal protocol for moving credentials freely between providers across different devices and platforms.

Second, support is uneven. Microsoft began making new consumer accounts passwordless by default in 2025 and most large providers accept passkeys somewhere, but plenty of smaller services still do not offer them at all. A physical security key sidesteps the ecosystem question completely, at the cost of being an object you can lose. Credentials cannot be exported from a certified hardware key by design, so there is no migration path and the answer is to buy two and register both.

Where a passkey is on offer for your email, take it.

App Passwords: The Back Door You Opened Yourself

Now the part that is mostly missing from articles about securing email, and that can undo everything above.

Turn on two-factor authentication, then try to set up your mailbox in an older desktop mail client or on an office printer. It fails, and the reason is structural. When an older mail client connects over IMAP or SMTP using traditional password authentication, it hands over a username and a password, and there is no interactive moment in that exchange where the server can stop and ask you for a code from your phone.

The modern fix is to stop using a password at all. RFC 7628 defines OAuth-based authentication over these protocols for exactly this situation: the client sends you through a browser login where two-factor happens normally, then receives a token it uses from then on. This is what "modern authentication" means in Gmail and Outlook, and it is why those accounts work properly in current mail apps.

The older fix, still available at many providers, is an app password. Your provider generates a long random string that works in place of your real password and skips your second factor entirely. Google's is sixteen characters, shown to you exactly once. You can only create one if two-step verification is already switched on, which is the quiet irony of the feature: it exists only for accounts that took security seriously, and what it produces is a credential that ignores the protection they switched on.

Google itself says app passwords are not recommended and are unnecessary in most cases. That has not stopped them being widely used, and it has not stopped them being targeted.

In June 2025 the Citizen Lab published a report on a campaign that did precisely that. Over at least ten email exchanges, an attacker posing as a US State Department official cultivated a relationship with Keir Giles, a Chatham House specialist on Russian information operations. Four apparently fabricated state.gov addresses were copied into the thread for credibility, which worked partly because the real State Department mail server appears to accept messages to addresses that do not exist without bouncing them. Eventually a professionally formatted PDF arrived with instructions for joining a government platform. The instructions walked him through creating an app-specific password on his Google account, labeling it with a meaningless string and sending it back.

The PDF contained no malware. There was no exploit anywhere in the operation. The entire attack was a set of polite instructions that persuaded a careful, security-aware target to generate a credential that bypassed his own two-factor authentication, and then to hand it over. Google's threat intelligence group attributed the operator to UNC6293, linked with low confidence to APT29.

The rules that follow are short:

Create an app password only when a device truly cannot do anything else, and look for an OAuth option first.
One per device, named for that device, so you can revoke precisely.
Revoke it the moment you stop using that client, sell the phone or replace the printer.
Never send one to anybody. There is no legitimate situation in which a person, a company or a support agent needs your app password. None.
Google revokes its app passwords when you change your account password. Do not assume every provider does. After any scare, change the password and then go and audit the app password list separately.
Audit that list occasionally anyway. Old app passwords have a habit of surviving long after the device they were created for is gone.

Recovery Codes Are the Part Everyone Skips

When you switch on two-factor authentication you are handed a list of one-time codes and a button to download them. Do it. NIST calls these look-up secrets and treats them as a legitimate authenticator in their own right, with the caveat that they are not phishing-resistant either.

The reason to care is not heroic. A very ordinary way to lose access to an email account is a phone that went into a canal carrying the only copy of the authenticator secret. Recovery codes are the answer to that, and they are the step people reliably skip, because the account works perfectly well without them right up until it does not.

Where to put them: printed on paper somewhere a burglar would not think to look is perfectly reasonable. A password manager is good too, with one trap worth thinking through. If your password manager's own account recovery runs through the email address these codes protect, and the codes exist only inside that password manager, you have built a circle with no way in. Keep at least one copy outside the loop.

And do not store them as a draft in the inbox they unlock, which is a thing people do.

The Windows You Left Open

Two more ways into your mailbox that are not the front door.

Your recovery address and recovery phone. These exist to let you back in, which means they can let somebody else in. An abandoned address at a provider you no longer check, or worse, one that has lapsed and could be registered by anybody who notices, is a live key to your current mailbox. Go and look at what is actually listed.

Forwarding rules and filters. This is a standard move after a mailbox compromise and one that is easy to overlook. A rule that quietly copies everything to an outside address, or files all mail from your bank into a folder you never open, survives the password change, the new second factor and the warm feeling of having dealt with it. If you ever suspect something happened, read your rules before you relax.

Turning It On

The wording differs between providers, but the shape of it almost never does.

Sign in and open your account settings, then look for a section called Security, Sign-in or Password.
Switch on two-factor authentication, two-step verification or multi-factor authentication. Same thing, three names.
Scan the QR code with any authenticator app. Anything that does standard TOTP works, so you are not tied to a particular vendor.
Type the six-digit code once to confirm. If you skip this step, it is not actually on.
Save the recovery codes. This is the step that matters most in a year's time.

One thing worth understanding while you are in there. A mail client using traditional password authentication over IMAP, POP3 or SMTP has no interactive moment where the server can stop and ask you for a code. Providers deal with that in different ways: some disable password authentication once a second factor is enabled, some issue separate application passwords and modern services increasingly use OAuth so that the second factor can happen during a browser login instead.

The practical conclusion matters more than the mechanism, so find out what credential your mail apps are actually using. If your normal mailbox password still works over IMAP, POP3 or SMTP after you switch on two-factor authentication, then that password is still a way into the mailbox with no second factor standing in front of it. Make it long, make it unique to this account and never reuse it anywhere else.

Worth checking separately: a few services keep more than one login. The account you use for billing and the mailbox itself can be two different doors with two different settings, and switching one on does not switch on the other.

The Twenty-Minute Version

In order, because the order matters:

Email first. It is the recovery channel for a disturbing number of your other accounts, so securing them while the mailbox is open is largely decorative.
Turn on the strongest second factor on offer. Passkey or security key, then authenticator app, then SMS. If SMS is the only option, take it and ask your provider why.
Save the recovery codes. Somewhere physical, outside the loop described above.
Review your app passwords and connected apps. Revoke anything you do not recognize or no longer use.
Check your forwarding rules and filters. Takes a minute, almost never done.
Fix your recovery address and phone. Make sure both are things you still control.
Then do steps two and three for your password manager and your phone's cloud account. Those are the other two sets of spare keys.

That is the lot. One short session on the sofa, once, for the account that holds the spare keys to so many of the others.

One Number Before You Go

We run a small paid email service, which puts us in a position to look something up that most people writing about this subject cannot: how many of our own customers actually switch this on.

Fewer than one in five.

Sit with that for a second. Our customers are, by definition, people who went looking for a private email service, found an invite-only one and paid money for it. If adoption is that low among people who are actively paying for privacy, it says something uncomfortable about how badly an optional security feature loses to inertia, no matter how motivated the person is.

Which is the honest note to end on. An optional second factor cannot protect you if you never switch it on.

It takes about four minutes. Go on.

Sources & further reading: NIST SP 800-63B-4: Authentication and Authenticator Management · NIST: Authenticators and phishing resistance · NIST: Syncable authenticators · W3C Web Authentication (WebAuthn) · RFC 7628: SASL Mechanisms for OAuth · Citizen Lab: Same Sea, New Phish · Google: Sign in with app passwords · FCC: SIM swap and port-out fraud rules · Open-Xchange: Application passwords

Disclosure: We run [@fuck.it], a privacy-focused, subscription-funded email service by Paradise Circus, Inc. — no ads, no tracking. Facts and product details are accurate as of October 28, 2026; check the original for the latest version.

Building Verifiable Bounty Payments and Revocable Account Sessions at MyZubster Over the latest MyZu

Mon, 28 Sep 2026 14:14:58 +0000

Engineering MyZubster: Verifiable Crypto Settlements, Refresh-Token Rotation, Revocable Sessions, and Cross-Mongoose Runtime Hardening

MyZubster recently completed a substantial infrastructure iteration spanning two systems that initially appear unrelated: contributor bounty settlement and authentication/session security.

They share an important engineering requirement:

external or client-side state must not be treated as authoritative without server-side verification and persistence.

For bounty payments, a blockchain transaction needs to become a verified, replay-safe treasury record.

For authentication, possession of a cryptographically valid JWT should not permanently imply that a session is still authorized.

This development cycle introduced infrastructure addressing both problems.

This article goes through the implementation, security properties, failure modes we discovered during integration testing, and the validation performed before pushing the final changes.

1. The Systems We Changed

The work covered two major areas.

Treasury and bounty settlement

We implemented infrastructure for recording verified cryptocurrency conversions associated with bounty settlement.

The flow now supports:

external transaction
        │
        ▼
blockchain reference
        │
        ▼
conversion verification
        │
        ▼
normalized treasury object
        │
        ▼
dry-run validation
        │
        ▼
idempotency check
        │
        ▼
persistent settlement record

Authentication and account security

MYZ-71 introduced a more substantial authentication lifecycle:

authentication
      │
      ▼
persistent server session
      │
      ├── short-lived access token
      │
      └── rotating opaque refresh token
                    │
                    ▼
             replay detection
                    │
                    ▼
              session revocation

The frontend then gained automatic renewal, account/device controls, terminal-expiry recovery, and CSRF protection for cookie-authenticated mutations.

Part I — Verifiable Cryptocurrency Bounty Settlement

2. Moving Beyond “A Transaction Was Sent”

Sending cryptocurrency is only one part of a bounty system.

From an engineering perspective, the application needs to answer several additional questions:

Why was the transaction made?
Which asset left the treasury?
Which asset arrived?
Which network was used?
What external provider participated?
Which blockchain transaction proves the operation?
Has the conversion been independently verified?
Has this exact operation already been recorded?
Can the dashboard consume the result without directly coupling itself to persistence?

For the settlement flow implemented during this cycle, the normalized record contains information such as:

{
  "purpose": "BOUNTY_SETTLEMENT",
  "provider": "SimpleSwap",
  "source": {
    "asset": "BTC",
    "amount": "0.000464",
    "txId": "2ea0bc209a2d5bcfbf520f830f1a39dee0691e47c461afc316e5aeb2e83cdd2d"
  },
  "target": {
    "asset": "ETH",
    "network": "ethereum-mainnet",
    "amount": "0.014355678390291923",
    "txId": "0x62b58e69931ef6046d8f68df39c118fe0b1fc7234b88c780d26a8b53fdcddcc6"
  },
  "state": "CONVERSION_COMPLETED",
  "verification": {
    "status": "VERIFIED"
  }
}

This represents the BTC → ETH treasury conversion as application state rather than leaving the operation as an external exchange receipt or manually interpreted transaction history.

3. Separating Verification From Persistence

A financial script should not immediately mutate production data simply because it successfully parsed its input.

We therefore implemented a dry-run path.

The sequence becomes:

construct record
     │
     ▼
validate input
     │
     ▼
verify external reference
     │
     ▼
print normalized result
     │
     ▼
STOP

The operator sees:

DRY-RUN OK — no database write performed

Only explicit commit mode proceeds to persistence.

This creates a useful operational boundary:

verification != mutation

That distinction matters for treasury operations because malformed metadata can be caught before it becomes part of the persistent accounting history.

4. Idempotent Conversion Recording

Financial scripts are frequently rerun.

A terminal disconnect, uncertain command result, deployment retry, or operator mistake should not produce a second logical settlement record.

The first committed execution recorded the conversion:

RECORDED
{
  "id": "6ab96bcb4c201256912e837a",
  "purpose": "BOUNTY_SETTLEMENT",
  "state": "CONVERSION_COMPLETED",
  "verificationStatus": "VERIFIED"
}

Repeating the operation returned:

IDEMPOTENT REPLAY — conversion already recorded

instead of creating a duplicate.

The desired invariant is:

same external conversion
        +
same transaction identity
        =
same internal logical record

This is much safer than relying on the operator to remember whether a previous command completed.

5. Provider Boundary for Settlement Observability

The settlement dashboard should not need to understand database internals.

We introduced a conversion-provider boundary so the dashboard can receive preloaded conversion information.

Conceptually:

buildDashboard({
  conversionProvider: () => conversion
});

This provides two useful properties.

First, the dashboard can consume treasury state without performing hidden database I/O.

Second, provider failure does not need to crash the entire dashboard.

If the repository fails, the conversion layer can instead return:

configured: false
items: []
reason: conversion repository unavailable

and emit an explicit warning.

That is deliberate degraded behavior.

For operational dashboards, an unavailable subsystem should be visible as unavailable — not silently represented as empty valid state and not allowed to crash unrelated observability.

Part II — Revocable Authentication Sessions

6. Why JWT Validation Alone Was Not Enough

A signed JWT answers an important question:

Was this token issued by a trusted signer and has its cryptographic validity expired?

It does not necessarily answer:

Does the server still want this browser session to exist?

Those are different questions.

A user may need to revoke a stolen device.

A refresh token may have been replayed.

An administrator or security flow may invalidate a session.

A user may explicitly log out.

For these cases, authentication needs authoritative server-side state.

We introduced persistent AuthSession records.

The resulting model is conceptually:

User
 │
 ├── AuthSession A
 │      ├── sessionId
 │      ├── expiry
 │      ├── device metadata
 │      ├── lastSeenAt
 │      ├── refreshTokenHash
 │      └── revocation state
 │
 ├── AuthSession B
 │
 └── AuthSession C

Access JWTs contain a session identifier.

JWT verification can therefore be followed by server-session validation.

A valid signature no longer necessarily means an active session.

7. Refresh Tokens Became Opaque, Persistent, and Rotating

The new refresh credential is an opaque token.

Its raw value is not persisted.

Instead, the server stores an HMAC-SHA256 representation.

The lifecycle looks like this:

refresh token R1
      │
      ▼
hash / identify
      │
      ▼
validate session
      │
      ▼
atomically consume R1
      │
      ▼
issue R2
      │
      ▼
store hash(R2)

R1 is now consumed.

The server maintains bounded history for previously consumed refresh-token hashes.

The bounded part matters: security metadata must not create an indefinitely growing session document.

8. Atomic Rotation

Refresh rotation introduces a concurrency problem.

Imagine two requests attempting to use R1 at nearly the same time:

Request A ── R1 ──┐
                  ├── session
Request B ── R1 ──┘

A naive implementation could allow both requests to observe R1 as valid before either update becomes visible.

Rotation therefore needs an atomic state transition.

Conceptually:

UPDATE AuthSession
WHERE
    session = S
AND currentRefreshHash = hash(R1)

SET
    currentRefreshHash = hash(R2)
    consumed += hash(R1)

Only the request that successfully matches the expected current state should rotate the token.

This is effectively compare-and-swap behavior applied to authentication state.

9. Refresh Replay Detection

Single-use refresh tokens provide another security signal.

If R1 was already consumed and later appears again, something unusual happened.

Possibilities include:

credential theft;
duplicated stale browser state;
client bugs;
copied authentication material;
an actual replay attempt.

Our implementation treats reuse as a security event.

The tested behavior is:

consumed refresh token reused
            │
            ▼
AUTH_REFRESH_REPLAY
            │
            ▼
revoke complete session
            │
            ▼
revokedReason = refresh-token-replay

The response is therefore stronger than simply rejecting the stale token.

The associated session itself becomes invalid.

10. Frontend Refresh Deduplication

Server-side single-use credentials require corresponding client-side concurrency control.

Suppose a page launches five API requests and the access token expires.

All five may receive 401.

Without coordination:

401 A → refresh
401 B → refresh
401 C → refresh
401 D → refresh
401 E → refresh

Only one of those refresh attempts can legitimately consume the current refresh token.

So the browser authentication client shares an in-flight refresh promise:

401 A ─┐
401 B ─┤
401 C ─┼──► one refresh operation
401 D ─┤
401 E ─┘
              │
              ▼
          new access state
              │
              ▼
         retry requests

This aligns frontend concurrency semantics with backend single-use token semantics.

Requests are retried only once.

The client does not enter an infinite 401 → refresh → retry loop.

Part III — Account Security

11. Session Management API

The session architecture is exposed through account-security endpoints:

POST   /api/auth/refresh
POST   /api/auth/logout
GET    /api/auth/me
GET    /api/auth/me/sessions
DELETE /api/auth/me/sessions/:sessionId

These endpoints provide the foundation for user-controlled session management.

12. Active Device Management

The frontend now contains an account-security surface.

Users can inspect session information including:

whether the session is the current one;
creation time;
last activity;
expiry;
available revocation actions.

A remote session can be revoked without destroying every other login.

The current session can also be terminated.

When that happens, server-side state is revoked and browser authentication state is cleared.

This turns logout from a mostly client-side token deletion into an actual server-side authorization transition.

13. Session Metadata and Privacy

Session observability is useful, but it should not require retaining unnecessary sensitive network data.

The session implementation therefore does not store raw client IP addresses as plain values.

Instead, IP information can be represented through an HMAC-SHA256 digest.

This allows certain correlation/security use cases without turning the session collection into a direct historical database of raw IP addresses.

Session lifetime is also bounded.

Part IV — Authentication Recovery in the Metaverse

14. A Renewable Authenticated Fetch Layer

The Metaverse API was moved onto a reusable authenticated request layer.

The high-level flow is:

API request
    │
    ▼
access accepted?
 ┌──┴──┐
yes    no
 │      │
return  ▼
     renewable auth failure?
          │
       ┌──┴──┐
       no    yes
       │      │
      fail    ▼
           refresh
              │
              ▼
          retry once

Not every 401 is renewable.

An explicitly revoked session, for example, should not cause endless attempts to resurrect authentication.

The client distinguishes terminal authentication state from renewable access-token failure.

15. Terminal Expiry Events

If refresh fails terminally, the browser:

clears migration authentication state;
emits an authentication-expired event;
redirects through the login flow.

This behavior was connected to:

Neon Plaza;
Metaverse room pages;
room creation.

Multiple concurrent failures are deduplicated so the application does not perform several competing redirects.

16. Preserving the Intended Destination

Authentication expiry should not destroy user navigation context.

The system preserves a local return path so a user can authenticate and return to the intended Metaverse location.

That can include:

/metaverse/rooms/example?invite=...#section

But return paths are also security-sensitive.

Protocol-relative destinations are rejected.

The application falls back to a known local Metaverse path when the return target is unsafe.

This prevents the convenience mechanism from becoming an open-redirect primitive.

Part V — CSRF Protection

17. Cookies Changed the Threat Model

Once authentication relies on HttpOnly cookies, the browser automatically attaches those credentials to matching requests.

That is useful for protecting credentials from direct JavaScript access, but it also means CSRF must be addressed explicitly.

The server now distinguishes:

Authorization: Bearer ...

from ambient cookie authentication.

Unsafe cookie-authenticated browser mutations require trusted request-origin information.

18. Origin, Referer, and Fetch Metadata

For applicable unsafe methods, the server evaluates browser request context.

Cross-site Fetch Metadata can be rejected before session lookup:

Sec-Fetch-Site: cross-site
        │
        ▼
      reject

Trusted Origin or Referer information is checked for cookie-authenticated mutations.

Rejected requests return a structured error:

AUTH_CSRF_REJECTED

Trusted production origins can be configured rather than hardcoded.

Bearer clients remain supported during the migration because explicit bearer credentials have different ambient-credential behavior from browser cookies.

Part VI — Structured Authentication Errors

19. Error Codes Instead of Raw Cryptographic Errors

Raw JWT/library exceptions are not a good public API.

The authentication layer now uses structured application errors and request IDs.

Conceptually:

{
  "error": {
    "code": "AUTH_...",
    "request_id": "..."
  }
}

This creates a stable contract between server and frontend.

The UI can distinguish:

access expiry;
revoked sessions;
refresh replay;
terminal refresh failure;
CSRF rejection;

without parsing arbitrary exception strings.

Request IDs also improve operational debugging.

Part VII — The Mongoose/BSON Failure We Found During Testing

20. The Initial Symptom

One of the most useful results of the final integration test was not a passing test.

It was a hang.

The social-identity suite stopped at:

RUNS tests/socialIdentityService.test.js

Eventually it failed with:

MongooseError:
Operation `metaversecharacters.findOne()` buffering timed out after 10000ms

The same thing happened during test cleanup:

metaversecharacters.deleteMany()
buffering timed out

At first glance, this looked like a MongoMemoryServer or asynchronous-test problem.

It wasn't.

21. Two Mongoose Runtimes in One Process

The root application used:

Mongoose 7.8.12

while the nested backend used:

Mongoose 8.24.3

User and AuthSession came from the root runtime.

MetaverseCharacter came from:

backend/src/models/MetaverseCharacter

and that model resolved its own:

require('mongoose')

against the backend installation.

So the test had effectively created:

MongoMemoryServer
       │
       ▼
root Mongoose 7
       │
       ├── User
       └── AuthSession


backend Mongoose 8
       │
       └── MetaverseCharacter
            X
       no connected test DB

The timeout suddenly made sense.

22. Connecting Both Runtimes Revealed the Deeper Problem

As a diagnostic step, both Mongoose instances were connected to the same in-memory MongoDB.

The timeout disappeared.

But the next error was more informative:

BSONVersionError:
Unsupported BSON version,
bson types must be from bson 6.x.x

An ObjectId produced by one Mongoose/BSON ecosystem was being passed into a model using another BSON implementation.

So simply connecting both instances was not a sound fix.

It exposed the deeper boundary problem.

23. Model Factory as the Boundary Repair

We did not solve this by increasing Jest timeouts.

We did not keep --forceExit.

We did not normalize every ObjectId manually and hope no other BSON type crossed the boundary.

Instead, MetaverseCharacter was changed to expose a model factory.

Conceptually:

function createMetaverseCharacterModel(mongoose) {
  const schema = new mongoose.Schema({
    // ...
  });

  return mongoose.models.MetaverseCharacter ||
    mongoose.model('MetaverseCharacter', schema);
}

Backend consumers can continue using the backend Mongoose runtime.

Root consumers can instantiate the same schema using the root runtime.

That changes the topology to:

Root application
       │
       ▼
root Mongoose
       │
       ├── User
       ├── AuthSession
       └── MetaverseCharacter

and:

Backend application
       │
       ▼
backend Mongoose
       │
       └── MetaverseCharacter

The schema definition can be shared without forcing two incompatible Mongoose runtime objects into the same database operation.

24. Why This Matters Beyond Tests

It would have been easy to classify the failure as “just a Jest problem.”

That would have been incorrect.

The test exposed an actual architectural boundary:

shared model source
≠
shared Mongoose runtime

Node's module resolution can load different versions of the same dependency from different package trees.

ODM objects such as ObjectIds, models, connections, and schemas are not automatically interchangeable simply because they ultimately represent MongoDB concepts.

The lesson is broader:

When a Node.js process contains multiple ODM/library runtimes, pass primitives or explicitly bind shared schemas to the owning runtime. Do not assume runtime-specific objects are portable across package boundaries.

Part VIII — Repairing Source Corruption

25. UTF-8 and Control-Character Validation

During the MYZ-71 repair we also discovered corrupted frontend source content.

The affected surfaces included authentication/security and Metaverse pages.

We explicitly checked for:

Unicode replacement characters;
unexpected control characters;
malformed JSX;
corrupted localized strings.

The affected source was repaired and then checked again before running the frontend suite.

This was important because some apparent React/parser failures were not behavioral regressions at all — they were malformed source bytes or broken string literals.

26. JavaScript String Parsing Failure

Another backend gate exposed a malformed JavaScript string containing an apostrophe:

Autorizzazione GitHub non associata all'account ...

The single quote terminated the surrounding single-quoted JavaScript string.

This prevented Babel/Jest from parsing the controller.

The string was repaired and syntax validation was performed before rerunning the backend suites.

This is a simple bug, but it reinforces why syntax/build gates belong in the final validation pipeline even after behavioral tests have been added.

Part IX — Validation

27. Backend Final Gate

After repairing the Mongoose boundary and JavaScript syntax, the targeted backend gate completed successfully:

Test Suites: 3 passed, 3 total
Tests:       18 passed, 18 total
Time:        4.478 s

The suites covered the relevant session controller, social authentication callback, and social identity behavior.

The previously hanging social identity tests now completed normally.

28. Frontend Final Gate

The targeted frontend gate also completed successfully:

Test Suites: 4 passed, 4 total
Tests:       13 passed, 13 total

Coverage included the authentication-expiry redirect, account-security page, auth-session API, and Metaverse API behavior.

29. Production Build

We then generated an optimized React production build:

Creating an optimized production build...
Compiled with warnings.

The build completed successfully.

The remaining ESLint warnings were non-blocking and outside the scope of the repair.

They were deliberately not mixed into the security fix simply to produce an artificially warning-free diff.

30. Git Integrity Gate

Before committing:

git diff --cached --check

completed cleanly.

Generated build artifacts were removed from the commit.

An unrelated untracked directory was also deliberately kept outside the MYZ-71 commit.

The final repair was committed as:

1878e02a
fix: harden revocable account sessions

and pushed to the MYZ-71 branch.

Part X — What Is Operational Now

31. Treasury

The implemented treasury infrastructure now supports:

bounty settlement purpose
        │
        ▼
crypto source transaction
        │
        ▼
asset conversion
        │
        ▼
target-chain transaction
        │
        ▼
verification
        │
        ▼
dry-run
        │
        ▼
idempotent persistence
        │
        ▼
dashboard provider

The recorded BTC → ETH operation reached:

CONVERSION_COMPLETED
VERIFIED

and replaying the recorder did not create a duplicate conversion.

32. Authentication

The implemented authentication/session infrastructure now provides:

login
 │
 ▼
persistent AuthSession
 │
 ├── access JWT bound to session
 │
 └── opaque rotating refresh credential
          │
          ├── atomic rotation
          ├── bounded consumed-token history
          └── replay detection
                   │
                   ▼
              session revocation

The frontend adds:

authenticated request
       │
       ▼
renew if allowed
       │
       ▼
retry once
       │
       ▼
terminal failure?
       │
       ▼
clear state + auth-expired event
       │
       ▼
login
       │
       ▼
restore safe local destination

Part XI — Security Properties Achieved

The resulting implementation has several concrete security properties.

Server authority over sessions

A cryptographically valid JWT can still be rejected when its server session has been revoked or removed.

Single-use refresh credentials

Refresh credentials rotate instead of remaining indefinitely reusable.

Replay detection

Reuse of consumed refresh state causes session revocation.

No raw refresh-token persistence

Refresh credentials are represented server-side through cryptographic hashes.

Client/server concurrency alignment

The frontend shares concurrent refresh work while the backend performs atomic token rotation.

Remote session revocation

A user can invalidate another authenticated device without necessarily destroying every active session.

Unsafe cookie-authenticated browser operations are protected by trusted-origin/Fetch Metadata checks.

Structured auth failures

Clients receive stable authentication semantics rather than raw JWT/library errors.

Authentication recovery preserves useful local navigation without accepting arbitrary protocol-relative redirect destinations.

Explicit ODM runtime ownership

The same Metaverse schema can be bound to the Mongoose runtime that actually owns the surrounding connection and models.

Replay-safe treasury persistence

Reexecuting the same verified conversion recorder does not produce duplicate settlement state.

Part XII — What We Deliberately Did Not Claim

Engineering reports are more useful when they clearly distinguish completed infrastructure from future work.

This iteration does not mean the entire MYZ-71 roadmap is finished.

Remaining work includes:

passkeys and/or magic-link authentication;
step-up authentication for sensitive operations;
extending automatic renewal to authenticated clients outside the current Metaverse integration;
completing migration away from legacy localStorage/bearer compatibility;
strict production server-session enforcement after the migration window;
production trusted-origin verification;
broader OAuth production verification;
production MongoDB stability validation.

On the treasury side, a verified conversion record is also not the final form of a contributor payment platform.

Future settlement work can connect:

bounty
  ↓
contributor
  ↓
approved amount
  ↓
payment instruction
  ↓
source transaction
  ↓
optional conversion
  ↓
destination transaction
  ↓
verification
  ↓
notification
  ↓
settled bounty state

into one auditable lifecycle.

Conclusion

The most valuable part of this development cycle was not the number of endpoints or React components added.

It was the strengthening of system boundaries.

For payments:

blockchain activity
      ↓
verified application state
      ↓
idempotent treasury record

For authentication:

client credential
      ↓
server-authoritative session
      ↓
rotating credentials
      ↓
replay detection
      ↓
revocation

And for the Node/MongoDB architecture:

shared schema
      ↓
explicit runtime ownership
      ↓
consistent Mongoose connection

The final repair was validated with 18/18 targeted backend tests, 13/13 targeted frontend tests, a successful optimized frontend build, and a clean Git diff check.

More importantly, integration testing exposed a real Mongoose 7/Mongoose 8 BSON boundary that would have been easy to hide with larger timeouts. Fixing the ownership boundary instead of suppressing the symptom left the architecture in a better state.

MyZubster now has stronger primitives for two areas where correctness matters disproportionately: moving value and maintaining identity.

That gives us a much safer base for the next layer of automation.

How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse

Mon, 28 Sep 2026 01:35:52 +0000

Ecco la versione in inglese pronta per CoderLegion.
How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse
Authentication in a Metaverse platform is more than a login form.
An authenticated identity may control characters, social relationships, private spaces, Marketplace activity and, eventually, payment-related operations. For MyZubster, relying only on long-lived JSON Web Tokens was no longer a sufficient security model.
Under MYZ-71 — Authentication, Sessions & Account Security, we started replacing stateless browser authentication with persistent, revocable and observable server-side sessions.
This article describes what we implemented, how refresh-token rotation works, how we detect token replay, what we tested and what still needs to be completed before production deployment.
The implementation is currently in a Draft pull request. It has not been merged or declared production-ready.

Why stateless JWT authentication was not enough
JWTs are useful because a server can validate them without loading a database record for every request.
However, a completely stateless model creates important limitations:

logout cannot reliably invalidate an existing token;
users cannot see which devices are authenticated;
administrators cannot revoke one compromised device;
a stolen token remains valid until expiration;
password changes do not automatically terminate sessions;
long-lived tokens increase the potential impact of credential theft;
tokens stored in localStorage can be accessed by malicious JavaScript after an XSS compromise.
We therefore introduced a hybrid architecture:
Authentication
```
↓
```
Persistent server-side session
```
↓
```
Short-lived JWT access token
```
↓
```
Rotating opaque refresh token
```
↓
```
Replay detection and session revocation
JWTs are still used for request authentication, but the server-side session is now the final source of authority.
Persistent server-side sessions
We added a MongoDB AuthSession model.
A separate session is created for each authenticated device. The record contains:
a unique session identifier;
the user who owns the session;
creation and expiration timestamps;
the last activity timestamp;
revocation state and reason;
limited device metadata;
a privacy-preserving client-IP digest;
the current refresh-token hash;
a bounded history of consumed refresh-token hashes;
refresh-token rotation metadata.
MongoDB TTL indexing is used to remove expired session records automatically.
This enables real session lifecycle management. A valid JWT is rejected whenever its associated session is expired, missing or revoked.
Session-bound access tokens
New JWT access tokens include a server-generated sid claim.
A simplified payload looks like this:
{
"sub": "user-id",
"sid": "session-uuid",
"jti": "access-token-uuid",
"iat": 1790540000,
"exp": 1790540900
}
Authentication now involves two checks:
1. Verify the JWT signature and expiration
2. Validate the persistent session referenced by sid
  This architecture preserves the advantages of JWTs while restoring the ability to revoke access immediately.
  If the user removes a device from the account-security page, the session becomes invalid even if its most recent JWT has not expired.
  Opaque refresh tokens
  The refresh token is not a JWT and does not contain trusted user data.
  Its conceptual format is:
  myzr.<session-id>.<cryptographically-random-secret>
  The random section is produced using a cryptographically secure random-number generator.
  The complete refresh token is sent to the authenticated browser, but it is never stored directly in MongoDB.
  Instead, the backend calculates:
  HMAC-SHA256(server secret, raw refresh token)
  Only the resulting digest is saved.
  This prevents a database leak from immediately exposing usable refresh credentials.
  Protected authentication cookies
  Refresh tokens are stored in cookies configured with:
  HttpOnly
  SameSite=Lax
  Secure in production
  Path=/api/auth
  HttpOnly prevents frontend JavaScript from reading the credential.
  The restricted path reduces the number of requests carrying the refresh cookie.
  Access tokens can also be received through an HttpOnly cookie. Bearer-token authentication remains temporarily supported to avoid breaking clients during the migration.
  Atomic refresh-token rotation
  A refresh token is single-use.
  When the browser calls:
  POST /api/auth/refresh
  the backend:
3. reads the refresh cookie;
4. extracts the session identifier;
5. calculates the HMAC digest of the submitted token;
6. generates a new opaque token;
7. atomically compares the submitted hash with the current stored hash;
8. replaces the stored hash;
9. records the consumed hash;
10. issues a new access token;
11. sends new access and refresh cookies.
  The database update only succeeds if:
the session exists;
the session has not expired;
the session has not been revoked;
the submitted hash is still the current refresh-token hash.
This is effectively a compare-and-swap operation.
If two requests try to use the same refresh token simultaneously, only one can rotate it successfully.
Refresh-token replay detection
Rotation prevents normal reuse, but the system must also detect when an old token appears again.
After every successful rotation, the consumed token hash is placed in a bounded history.
If a token from that history is submitted again, the server treats it as a possible credential compromise.
Previously consumed token submitted
```
          ↓
```
Replay detected
```
          ↓
```
Entire server-side session revoked
```
          ↓
```
Authentication cookies cleared
```
          ↓
```
A new login is required
The session receives the revocation reason:
refresh-token-replay
The history is limited to the latest 50 hashes so the MongoDB document cannot grow indefinitely.
Replay does not necessarily prove malicious activity. It could also indicate an outdated client or an unusual concurrency condition. Revoking the session is nevertheless the safest response.
New authentication endpoints
The current implementation provides the following endpoints.
Refresh the session
POST /api/auth/refresh
This endpoint rotates the refresh token and issues a new access token.
The raw refresh token is never included in the JSON response.
Log out
POST /api/auth/logout
Logout is idempotent.
Authentication cookies are cleared even when the access token is missing, malformed, expired or already revoked.
When possible, the refresh token is used to find and revoke the persistent session.
Retrieve the authenticated account
GET /api/auth/me
Returns the authenticated user and safe session metadata.
List active devices
GET /api/auth/me/sessions
Returns the user’s active sessions and indicates the current device.
Revoke a device
DELETE /api/auth/me/sessions/:sessionId
Allows users to terminate another session remotely.
Revoking the current session also clears local authentication state and returns the user to the login flow.
Password and social authentication
Password registration and login now create persistent sessions and issue both access and refresh cookies.
Verified social-login flows use the same architecture.
The raw refresh token is not placed inside:
redirect URLs;
OAuth query parameters;
signed callback tickets;
public API responses.
This reduces the risk of credentials leaking through browser history, analytics systems, proxy logs or referrer headers.
Account-security interface
The React frontend now includes:
/account/security
The page displays:
active sessions;
the current device;
session creation time;
last activity;
expiration time;
limited device information.
Users can remotely revoke another device or terminate the current session.
The page is linked from the authenticated account panel and Neon Plaza.
The deployment configuration also supports the route as a single-page application path and applies:
X-Robots-Tag: noindex, nofollow
Account-security pages should not be indexed by search engines.
Privacy-preserving session metadata
The system does not store raw client IP addresses.
Instead, it saves an HMAC-derived digest. This provides a limited correlation signal for security purposes without retaining the original IP address as normal application data.
Device metadata is also intentionally limited.
Session security should help users recognize their devices without becoming an invasive tracking mechanism.
Legacy migration support
The existing frontend still contains API clients that expect a token in localStorage or use:
Authorization: Bearer
Removing this immediately would break existing routes and clients.
The migration is therefore divided into stages:
Persistent sessions and cookie support
```
          ↓
```
Rotating refresh tokens
```
          ↓
```
Centralized access-token renewal
```
          ↓
```
CSRF protection
```
          ↓
```
Cookie-only authentication
```
          ↓
```
Expiration of legacy browser tokens
```
          ↓
```
Strict server-session enforcement
```
          ↓
```
Removal of localStorage and bearer migration
An environment option is available for strict enforcement:
REQUIRE_SERVER_SESSION=true
It should only be activated after existing clients and legacy credentials have been migrated.
Testing the implementation
The focused authentication implementation currently passes:
Backend: 30/30 tests
Frontend: 12/12 tests
The React production build also completes successfully.
Real MongoDB integration coverage verifies the complete replay lifecycle:
Create persistent session
```
  ↓
```
Use current refresh token
```
  ↓
```
Rotate successfully
```
  ↓
```
Submit the old token again
```
  ↓
```
Reject the replay
```
  ↓
```
Revoke the server-side session
```
  ↓
```
Persist refresh-token-replay as the reason
The following authentication suites also pass in GitHub Actions:
tests/authSessionService.test.js
tests/authSessionController.test.js
tests/socialIdentityService.test.js
Repository-wide CI status
The complete repository pipeline is not yet green.
The latest full backend execution reported:
141 test suites passed
42 test suites failed

738 tests passed
44 tests failed
The failing tests mainly concern pre-existing behavior in:

Zorgax payments and payment intents;
Marketplace flows;
seller-membership policies;
older Metaverse authentication expectations;
Metaverse observability;
legacy source-code assertion tests.
The Security Audit and MYZ-164 policy workflows also remain red because of previously identified repository-wide conditions.
The new MYZ-71 session and refresh-token suites are green, but the pull request must remain a Draft until the wider baseline and the remaining authentication work are addressed.
What still needs to be implemented
Centralized access-token renewal
The frontend needs a shared API layer that can:
1. identify an expired access token;
2. call /api/auth/refresh;
3. retry the original request;
4. prevent simultaneous refresh calls;
5. redirect to login when renewal fails.
  Without a centralized implementation, individual pages may respond differently when the access token expires.
  CSRF protection
  Cookie-based authentication requires explicit protection for state-changing operations.
  The final design should combine appropriate controls such as:
origin validation;
CSRF tokens;
double-submit cookies;
carefully selected SameSite policies;
rejection of unsafe cross-origin requests.
SameSite=Lax should not be considered the only defence.
Removal of browser-stored tokens
The current frontend still updates the legacy localStorage token as a temporary compatibility bridge.
The final architecture should not expose reusable authentication credentials to frontend JavaScript.
Before removing localStorage, we must migrate:
every authenticated API client;
protected React routes;
realtime and websocket authentication;
mobile or embedded clients;
old sessions and legacy JWTs.
Passkeys and magic links
The MYZ-71 roadmap includes passwordless authentication based on flows such as:
/auth/start
/auth/verify
Passkey support will require correct WebAuthn management for:
relying-party configuration;
allowed origins;
challenge creation and expiration;
credential counters;
credential revocation;
account recovery.
Magic links will require short-lived, single-use verification tokens and replay protection.
Step-up authentication
Sensitive operations should require recent stronger verification.
Examples include:
changing the primary email;
changing a password;
registering or deleting passkeys;
deleting the account;
accessing wallet or payment functionality;
modifying high-impact Marketplace settings.
A valid session should not automatically authorize every sensitive action indefinitely.
Password-change session policy
The application must define what happens after a password change:
revoke every session;
keep only the current session;
allow the user to choose;
require step-up authentication.
This policy must be enforced on the server and tested with real session records.
Production OAuth validation
Google, GitHub and Facebook login still need production verification for:
exact callback URLs;
public frontend and API origins;
provider secrets;
redirect allowlists;
account-linking behavior;
missing-email cases;
cookie behavior across domains.
MongoDB Atlas validation
The production deployment must verify:
TTL-index creation;
refresh-token indexes;
cleanup of expired sessions;
document growth;
rolling-deployment compatibility;
session behavior under concurrent refresh requests.
Rate limiting
Authentication endpoints need dedicated abuse protection.
This includes limits for:
password login;
refresh requests;
password recovery;
magic-link generation;
WebAuthn challenge creation;
social-auth callbacks.
Security monitoring
Structured security events should be produced for:
login success and failure;
session creation;
session revocation;
remote device removal;
refresh-token replay;
password changes;
passkey registration;
suspicious authentication activity.
Logs must never contain passwords, raw access tokens, raw refresh tokens, OAuth authorization codes or provider secrets.
Recommended deployment sequence
The safest rollout order is:
1. review the Draft pull request;
2. deploy with legacy compatibility enabled;
3. verify MongoDB indexes;
4. validate cookies using the real public domains;
5. test login, refresh, logout and remote revocation;
6. execute a controlled refresh-token replay test;
7. implement centralized frontend renewal;
8. add and validate CSRF protection;
9. monitor session and replay events;
10. allow legacy credentials to expire;
11. activate strict server-session enforcement;
12. remove localStorage and legacy bearer authentication;
13. introduce passkeys, magic links and step-up authentication.
  Current progress
  Persistent server-side sessions DONE
  Session-bound JWT access tokens DONE
  Real logout DONE
  Active-device listing DONE
  Remote session revocation DONE
  Opaque rotating refresh tokens DONE
  Refresh-token replay detection DONE
  Password and social-login integration DONE
  Account-security interface DONE
  Focused backend and frontend testing DONE

Centralized access-token renewal PENDING
CSRF hardening PENDING
Cookie-only migration PENDING
Removal of localStorage authentication PENDING
Passkeys and magic links PENDING
Step-up authentication PENDING
Production OAuth validation PENDING
MongoDB Atlas production validation PENDING
Repository-wide green CI PENDING
Final thoughts
Secure authentication is not just about generating a token.
It requires a complete lifecycle:
Issue
Verify
Renew
Observe
Revoke
Recover
Monitor
MyZubster now has the foundation for persistent multi-device sessions, secure refresh-token rotation and automatic replay response.
The next major objective is completing the browser migration safely through centralized renewal, CSRF protection and the removal of JavaScript-accessible authentication credentials.
Only after those controls are validated should strict session enforcement be activated in production.
The current implementation can be reviewed in the Draft pull request:
https://github.com/danieldirimini-myzubster/myzubster/pull/10

Spring Boot Authentication Boilerplate: From JWT Basics to Production-Ready Auth

Sun, 20 Sep 2026 16:50:00 +0000

Starting a new Spring Boot project usually feels great.

You create the project, add a few dependencies, write your first controller...

Then authentication enters the chat.

Suddenly you're configuring:

Spring Security
JWT access tokens
refresh tokens
roles and permissions
password hashing
exception handling
database migrations

Three hours later, your original feature still has exactly zero lines of code.

Congratulations. You built authentication again.

The auth code isn't the interesting part

Most applications need roughly the same authentication foundation.

Return an access token.

Refresh it safely.

Protect endpoints.

Check roles.

Logout.

Maybe add passkeys, OAuth, account recovery, or multiple sessions later.

None of this is particularly unique to your SaaS, internal tool, API, or side project.

But we keep rebuilding it.

I was doing the same thing with my Spring Boot projects, so I eventually turned that repeated setup into AuthKit.

AuthKit Lite

AuthKit Lite is the free and open-source version.

It gives you a working Spring Boot authentication foundation with:

JWT access tokens
rotating refresh tokens
Spring Security
role-based authorization
BCrypt passwords
optional WebAuthn passkeys
Flyway migrations
H2 for instant local testing
MySQL support
integration tests
a browser-based API testing page

The goal is simple:

Clone → run → test the APIs → start building your application.

git clone https://github.com/buildbasekit/AuthKit-Lite.git
cd AuthKit-Lite
./mvnw spring-boot:run

Then open:

http://localhost:8080/api-test

No Docker ceremony.

No spending your evening creating JWT filters for the 17th time.

No pretending you'll "clean up the auth code later."

You can find AuthKit Lite here:

https://buildbasekit.com/boilerplates/authkit-lite/

When Lite isn't enough

Basic authentication is enough for many projects.

But production applications often grow into things like:

email verification
password recovery
multiple user sessions
session revocation
refresh-token replay protection
OAuth2 / OIDC
account linking
magic links
passkeys
account lifecycle handling

That is where AuthKit Pro comes in.

It takes the same idea further: provide the authentication foundation while keeping the application-specific business logic in your application.

The important part for me was avoiding a giant framework that tries to own the entire application.

Auth should be infrastructure.

Not your new hobby.

AuthKit Pro is here:

https://buildbasekit.com/boilerplates/authkit-pro

Lite or Pro?

The easiest way to think about it:

AuthKit Lite

Use it when you need a clean Spring Boot authentication starting point or want to understand and extend the implementation yourself.

It's free and open source.

AuthKit Pro

Use it when the project needs more complete authentication flows and production-focused session and account lifecycle features.

Both are source-code foundations.

You still own the application.

You can change the architecture.

You can remove features.

You can add your own authorization rules.

And your business logic doesn't have to live inside somebody else's authentication service.

Why a boilerplate?

I'm not trying to eliminate authentication decisions.

You still need to decide things like:

token lifetimes
authorization rules
production secrets
rate limiting
monitoring
application-specific permissions

A boilerplate just means you don't have to start those decisions from an empty SecurityConfig.java.

That's the part I wanted to solve.

Because there are much more interesting bugs waiting for us in the actual product.

AuthKit Lite — Free & Open Source

https://buildbasekit.com/boilerplates/authkit-lite/

AuthKit Pro — Production-Focused

https://buildbasekit.com/boilerplates/authkit-pro

Built with Spring Boot and Spring Security.

If you're building Spring Boot APIs, I'd also be interested to know:

Do you rebuild authentication for every project, maintain your own starter, or use an external identity provider?

How to Authenticate Users with Solana Wallets in NestJS

Sat, 19 Sep 2026 07:40:14 +0000

Let's talk about wallet based auth in NestJS. What this is, is basically an auth system where the user is authenticated and authorized based on their web3 wallet. We'll be doing this with a Solana wallet. The process is quite straightforward:

User requests a nonce (a single-use random number that prevents replay attacks)
Backend sends the nonce
User signs the nonce with their wallet address and returns the signed nonce back to the backend
Backend verifies that the nonce was signed by the right address

From this point on it's your regular auth flow and you can hook this up to any existing JWT or session auth system you've implemented.

One thing to note is that a frontend is required for this or at least some way for the client to sign nonces with their web3 wallet. We'll be using @solana/kit SDK for this as it's the modern implementation of the @solana/web3.js SDK and recommended for production use by Anza.

Backend

The backend's job is to generate unique challenges (nonces), verify that signatures were created by the claimed wallet address, and issue JWT tokens on successful authentication.

We'll need to install @solana/kit as well as redis since we will be using that to store our nonces. Redis is ideal here because it provides fast in-memory storage with built-in TTL (time-to-live) expiration, automatically cleaning up old nonces without manual intervention.

npm install @solana/kit redis

Redis Service

Let's set up our redis client and service.

In NestJS, when you're working with non-class instances like Redis clients, you can't use the standard class-based dependency injection. Instead, you use string tokens as injection identifiers. The Redis client is created by a factory function (not instantiated via new RedisService()), so TypeScript can't use the class itself as a token. String constants provide a unique identifier that NestJS can use to register and retrieve the instance.

This is why we define REDIS_CLIENT as a constant string token that we'll use to register and inject our Redis client throughout the application.

//redis.constants.ts
export const REDIS_CLIENT = 'REDIS_CLIENT';

We need two specific methods here. The setNonce method stores the nonce with a 5-minute expiration using Redis's EX option, which automatically cleans up old nonces and prevents replay attacks.

The getAndDeleteNonce method atomically retrieves and deletes the nonce in one operation, ensuring each nonce can only be used once for verification. This pattern prevents an attacker from reusing a previously signed nonce.

//redis.service.ts
import { Inject, Injectable } from '@nestjs/common';
import { REDIS_CLIENT } from './redis.constants';
import type { RedisClientType } from 'redis';

@Injectable()
export class RedisService {
  constructor(@Inject(REDIS_CLIENT) private readonly redis: RedisClientType) {}

  // Store nonce with 5-minute expiration
  async setNonce(address: string, nonce: string): Promise<void> {
    await this.redis.set(`nonce:${address}`, nonce, { EX: 300 });
  }

  // Retrieve and immediately delete nonce to prevent replay attacks
  async getAndDeleteNonce(address: string): Promise<string | null> {
    const nonce = await this.redis.get(`nonce:${address}`);
    
    if (nonce) {
      await this.redis.del(`nonce:${address}`);
    }
    
    return nonce;
  }
}

We're using NestJS's ConfigService to manage environment variables in a type-safe way. This is better than directly accessing process.env because it centralizes configuration, provides validation, and makes testing easier. You can validate required variables at startup (fail fast), type-check them, and mock them in tests without polluting the global process object.

The @Global() decorator makes this module available throughout your application without needing to import it into every module. Make sure to set up ConfigModule in your AppModule like this:

// app.module.ts
import { Module } from '@nestjs/common';
import { ConfigModule } from '@nestjs/config';
// ... other imports

@Module({
  imports: [
    ConfigModule.forRoot({
      isGlobal: true, // Makes ConfigModule available globally
    }),
    // ... other modules
  ],
  // ... controllers and providers
})
export class AppModule {}

Now we can set up our Redis module:

//redis.module.ts
import { Global, Module } from '@nestjs/common';
import { RedisService } from './redis.service';
import { REDIS_CLIENT } from './redis.constants';
import { ConfigService } from '@nestjs/config';
import { createClient } from 'redis';

@Global()
@Module({
  providers: [
    {
      provide: REDIS_CLIENT,
      inject: [ConfigService],
      useFactory: async (configService: ConfigService) => {
        const client = createClient({
          url: configService.get<string>('REDIS_URL'),
        });
        
        client.on('error', (err) => console.error('Redis client error', err));
        
        await client.connect();
        
        return client;
      },
    },
    RedisService,
  ],
  exports: [REDIS_CLIENT, RedisService],
})
export class RedisModule {}

Auth Service

With Redis configured to handle nonce storage, we can build the authentication logic. The auth service will generate nonces, create SIWS-compliant messages, verify signatures, and issue JWT tokens. Let's implement our service logic.

We need to provide a way for the frontend to request a nonce. We also need to use our redis methods to store the nonce we provide to be used during verification later.

We use randomBytes from Node's crypto module to generate cryptographically secure random values. The 16 bytes of random data are then converted to base64url encoding, which is URL-safe and produces a string without padding characters. This encoding ensures the nonce can be safely included in URLs and JSON without escaping issues, while 16 bytes provides sufficient entropy (2^128 possible values) to prevent collision attacks. This gives us a unique, unpredictable nonce for each authentication attempt.

import { randomBytes } from 'crypto';

generateNonce(): string {
  return randomBytes(16).toString('base64url');
}

The message format follows the Sign-In with Solana (SIWS) standard, which is analogous to Sign-In with Ethereum (SIWE). This standardized format includes the domain requesting authentication, the user's wallet address, a human-readable message, the unique nonce, and a timestamp. This structure ensures the user knows exactly what they're signing and prevents phishing attacks where a malicious site might try to get users to sign messages intended for other domains.

async getChallenge(address: string) {
  const nonce = this.generateNonce();
  
  await this.redisService.setNonce(address, nonce);
  
  // Standard SIWS message format for wallet authentication
  const message = `titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}`;
  
  return { message, nonce };
}

The signature verification method is the heart of the authentication system. It retrieves the stored nonce, reconstructs the exact message that was signed, and uses Solana's cryptographic primitives to verify that the signature was created by the private key corresponding to the claimed wallet address. If any part of this fails, authentication is rejected.

import { getAddressFromPublicKey, getBase58Decoder, getBase58Encoder } from '@solana/kit';

async verifySolanaSignature(data: {
  address: string;
  signatureBase58: Uint8Array;
  message: Uint8Array;
  nonce: string;
}): Promise<boolean> {
  const { address, signatureBase58, message, nonce } = data;

  // Retrieve and delete the nonce to prevent replay attacks
  const storedNonce = await this.redisService.getAndDeleteNonce(address);

  if (!storedNonce || storedNonce !== nonce) {
    return false;
  }

  try {
    // Decode the signature and message from base58
    const signature = getBase58Decoder().decode(signatureBase58);
    const messageBytes = getBase58Decoder().decode(message);
    
    // Verify the signature matches the address
    const publicKey = getAddressFromPublicKey(
      getBase58Decoder().decode(address)
    );
    
    // Use Solana's signature verification
    const isValid = await verifySignature(publicKey, messageBytes, signature);
    
    return isValid;
  } catch (error) {
    console.error('Signature verification error:', error);
    return false;
  }
}

The validateUserWithWallet method either finds an existing user by wallet address or creates a new one. This is where you'd integrate with your user management system. In this example, we're using Prisma to handle database operations, but you could adapt this to any ORM or database layer.

async validateUserWithWallet(address: string): Promise<UserEntity | null> {
  // Find existing user by wallet address
  let user = await this.prisma.user.findUnique({
    where: { walletAddress: address },
  });

  // If no user exists, create one
  if (!user) {
    user = await this.prisma.user.create({
      data: {
        walletAddress: address,
      },
    });
  }

  return user;
}

The login function creates JWT tokens after successful authentication. We build a payload containing the user's ID and device information, then conditionally add email and wallet address if they exist. The function returns both an access token for immediate use and a refresh token for obtaining new access tokens when the current one expires. The refresh token is handled by a separate service that manages longer-lived tokens with different expiration rules.

async login(
  user: UserEntity,
  deviceInfo: string,
  walletAddress?: string,
): Promise<{
  access_token: string;
  refresh_token: string;
}> {
  const payload = {
    sub: user.id,
    deviceInfo,
  };

  if (user.email) {
    payload['email'] = user.email;
  }

  if (walletAddress) {
    payload['walletAddress'] = walletAddress;
  }

  const refresh_token = await this.jwtRefreshService.create(payload);
  
  return {
    access_token: this.jwtService.sign(payload),
    refresh_token,
  };
}

Wallet Auth Guard

Now we need a way to protect our login endpoint. NestJS guards intercept incoming requests before they reach the controller, making them perfect for authentication logic.

The guard is responsible for intercepting requests to protected endpoints and verifying that the wallet signature is valid before allowing the request to proceed. It extracts the signed data from the request body, verifies the signature using our auth service, finds or creates the user, and attaches both the user entity and wallet address to the request object for use in the controller.

// guards/wallet-auth.guard.ts
import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { AuthService } from '../auth.service';
import { UnauthorizedException } from '@nestjs/common';

@Injectable()
export class LocalWalletAuthGuard implements CanActivate {
  constructor(private readonly authService: AuthService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const { address, signatureBase58, message, nonce } = request.body;

    // Verify signature first
    const isValid = await this.authService.verifySolanaSignature({
      address,
      signatureBase58,
      message,
      nonce,
    });

    if (!isValid) {
      throw new UnauthorizedException('Invalid signature');
    }

    // Find or create user
    const user = await this.authService.validateUserWithWallet(address);

    if (!user) {
      throw new UnauthorizedException('Could not validate user');
    }

    // Attach user and address to request for use in controller
    request.user = user;
    request.address = address;

    return true;
  }
}

Auth Controller

With our guard handling verification, the controller becomes simple. It just needs to provide nonces to unauthenticated users and issue tokens after the guard confirms valid signatures.

In the controller, we have two endpoints. The loginWithWallet endpoint uses our LocalWalletAuthGuard which verifies the signature and attaches both the user entity and wallet address to the request object. By the time we reach this controller method, we know the authentication is valid. We extract device information from the user-agent header, call the login service, set the refresh token as an httpOnly cookie for security, and return the access token. The getChallenge endpoint is marked with @Public() decorator since users need to request a nonce before they can authenticate. It simply returns the SIWS message and nonce for the given wallet address.

@Post('login-with-wallet')
@UseGuards(LocalWalletAuthGuard)
async loginWithWallet(
  @Request() req: RequestType & { user: UserEntity; address: string },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
    req.address,
  );

  // Set refresh token as httpOnly cookie for security
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true,
    secure: true,
    sameSite: 'strict',
  });

  return { access_token };
}

@Public()
@Get('nonce/:address')
@ApiOperation({ summary: 'Request nonce for wallet-based authentication' })
@ApiResponse({
  description: 'Nonce and SIWS message sent successfully.',
  status: 200,
  example: {
    message:
      'titan-app.com wants you to sign in with your Solana account:\n${address}\n\nSign this message to authenticate.\n\nNonce: ${nonce}\nTimestamp: ${Date.now()}',
    nonce: '1234xlrhex',
  },
})
async getChallenge(@Param('address') address: string) {
  return await this.authService.getChallenge(address);
}

Backend Summary

That covers the backend implementation. We've set up a Redis-backed nonce system that generates unique challenges for each authentication attempt, an auth service that creates SIWS-compliant messages and manages JWT token generation, a guard that verifies signatures using Solana's cryptographic primitives, and controller endpoints that handle the nonce request and login flow. The signature verification ensures that only the holder of the wallet's private key can authenticate, while the nonce system prevents replay attacks.

Frontend

The backend is now ready to issue nonces and verify signatures. The frontend's job is to request these nonces, get the user to sign them with their wallet's private key (which never leaves their browser), and send the signed message back for verification. Now let's implement the frontend of our auth system.

Now let's implement the frontend of our auth system. The user needs to sign our message with their private key. It is important this private key stays secure and never leaves the frontend. A tool that facilitates this is a wallet. Since we're using Solana we'll be using the Phantom wallet.

The setup steps are straightforward. First, install Phantom as a browser extension. Once installed, create a new wallet or import an existing one. Then navigate to Settings, go to Developer Settings, and enable Testnet mode. In Testnet mode, select Solana Devnet. You could use Localnet if you have a test validator running locally or Testnet for a shared testing environment, but Devnet provides a good balance of accessibility and realistic network conditions.

Once all this is done we can start hacking. We'll spin up a small React frontend. This is just for speed and general accessibility. You can implement this in any frontend stack as long as you understand the core steps. I used Vite to set up my React project with TypeScript and Tailwind. We should also install the @solana/kit package, which automatically includes @solana/react and other necessary dependencies, along with @wallet-standard/react-core.

npm install @solana/kit @wallet-standard/react-core

After we're done with project setup, the first thing we want to do is define our Solana client instance. This will be used to communicate with the Solana chain via its RPC endpoints.

// lib/solana-client.ts
import type {
  Rpc,
  RpcSubscriptions,
  SolanaRpcApi,
  SolanaRpcSubscriptionsApi,
} from "@solana/kit";

export type Client = {
  rpc: Rpc<SolanaRpcApi>;
  rpcSubscriptions: RpcSubscriptions<SolanaRpcSubscriptionsApi>;
};

// lib/helpers.ts
import { createSolanaRpc, createSolanaRpcSubscriptions } from "@solana/kit";
import type { Client } from "./solana-client";

let client: Client | undefined;

export function createClient(): Client {
  if (!client) {
    client = {
      rpc: createSolanaRpc(`${import.meta.env.SOLANA_RPC_URL}`),
      rpcSubscriptions: createSolanaRpcSubscriptions(
        `${import.meta.env.SOLANA_RPC_SUBSCRIPTIONS_URL}`
      ),
    };
  }
  
  return client;
}

Make sure your .env file contains the Devnet URLs:

SOLANA_RPC_URL=https://api.devnet.solana.com
SOLANA_RPC_SUBSCRIPTIONS_URL=wss://api.devnet.solana.com

With the Solana client configured, we need functions to communicate with our backend. In our features/auth/api folder, we'll create two API calls: one to request a nonce and another to submit the signed message. Let's define them both.

// features/auth/types
export type RequestNonceOutput = {
  message: string;
  nonce: string;
};

export type VerifyNonceInput = {
  address: string;
  signatureBase58: Uint8Array<ArrayBufferLike>;
  message: Uint8Array<ArrayBufferLike>;
  nonce: string;
};

export type LoginResponse = {
  access_token: string;
};

// features/auth/api/requestNonce.ts
import type { RequestNonceOutput } from "../types";

export async function requestNonce(
  address: string
): Promise<RequestNonceOutput> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/nonce/${address}`
  );

  if (!response.ok) {
    throw new Error(`Failed to request nonce: ${response.statusText}`);
  }

  const data = await response.json();
  
  // Validate response structure
  if (!data.message || !data.nonce) {
    throw new Error('Invalid response format from nonce endpoint');
  }
  
  return data as RequestNonceOutput;
}

// features/auth/api/loginWithWallet.ts
import type { VerifyNonceInput, LoginResponse } from "../types";

export async function loginWithWallet(
  signedData: VerifyNonceInput
): Promise<LoginResponse> {
  const response = await fetch(
    `${import.meta.env.VITE_API_URL}/auth/login-with-wallet`,
    {
      method: "POST",
      headers: {
        "Content-Type": "application/json",
      },
      body: JSON.stringify(signedData),
    }
  );

  if (!response.ok) {
    const errorData = await response.json().catch(() => ({}));
    throw new Error(
      errorData.message || `Login failed: ${response.statusText}`
    );
  }

  const data = await response.json();
  
  // Validate response contains access token
  if (!data.access_token) {
    throw new Error('Invalid response format from login endpoint');
  }
  
  return data as LoginResponse;
}

These are going to serve as our connection to the backend we made previously.

Before we build the UI components, we need to manage wallet connection state across the app. React Context provides a clean way to share the selected wallet without prop drilling.

As this is only an auth demonstration it's not going to be anything fancy, just enough to implement the authentication flow and some state to show we're logged in.

First off, our wallet account context. You can use some other way to manage context in your application. Here we'll be using the React Context API.

// src/context/SelectedWalletAccountContext.tsx
import { createContext } from "react";
import type { UiWallet, UiWalletAccount } from "@wallet-standard/react-core";

export type SelectedWalletAccountState = UiWalletAccount | undefined;

export const SelectedWalletAccountContext = createContext<
  readonly [
    selectedWalletAccount: SelectedWalletAccountState,
    setSelectedWalletAccount: React.Dispatch<
      React.SetStateAction<SelectedWalletAccountState>
    >,
    selectedWallet: UiWallet | undefined
  ]
>([
  undefined,
  function setSelectedWalletAccount() {
    /* empty */
  },
  undefined,
]);

The wallet account context provider handles persistence and synchronization of the selected wallet across sessions. When a user selects a wallet, we save a storage key composed of the wallet name and account address to localStorage. On subsequent visits, the provider attempts to restore the previously selected wallet if it's still available. The provider also handles cleanup when wallets disconnect and ensures the selected account stays synchronized with the actual connected wallets from the Wallet Standard registry.

// src/context/SelectedWalletAccountContextProvider.tsx
import { useEffect, useMemo, useState } from "react";
import {
  SelectedWalletAccountContext,
  type SelectedWalletAccountState,
} from "./SelectedWalletAccountContext";
import {
  getUiWalletAccountStorageKey,
  uiWalletAccountBelongsToUiWallet,
  uiWalletAccountsAreSame,
  useWallets,
  type UiWallet,
  type UiWalletAccount,
} from "@wallet-standard/react-core";

const STORAGE_KEY = "solana-wallet-standard-react:selected-wallet-and-address";

let wasSetterInvoked = false;

// Attempts to restore previously selected wallet from localStorage
function getSavedWalletAccountAndWallet(
  wallets: readonly UiWallet[]
):
  | { account: UiWalletAccount | undefined; wallet: UiWallet | undefined }
  | undefined {
  // Stop auto-selecting after user makes explicit choice
  if (wasSetterInvoked) {
    return;
  }
  
  const savedWalletNameAndAddress = localStorage.getItem(STORAGE_KEY);
  if (
    !savedWalletNameAndAddress ||
    typeof savedWalletNameAndAddress !== "string"
  ) {
    return;
  }
  
  const [savedWalletName, savedAccountAddress] =
    savedWalletNameAndAddress.split(":");
    
  if (!savedWalletName || !savedAccountAddress) {
    return;
  }
  
  // Find matching wallet and account in current connected wallets
  for (const wallet of wallets) {
    if (wallet.name === savedWalletName) {
      for (const account of wallet.accounts) {
        if (account.address === savedAccountAddress) {
          return { account, wallet };
        }
      }
    }
  }
}

export function SelectedWalletAccountContextProvider({
  children,
}: {
  children: React.ReactNode;
}) {
  const wallets = useWallets();
  
  const [selectedWalletAccount, setSelectedWalletAccountInternal] =
    useState<SelectedWalletAccountState>(
      () => getSavedWalletAccountAndWallet(wallets)?.account
    );
  
  const [selectedWallet, setSelectedWalletInternal] = useState<
    UiWallet | undefined
  >(() => getSavedWalletAccountAndWallet(wallets)?.wallet);
  
  // Wrapper that saves selection to localStorage
  const setSelectedWalletAccount: React.Dispatch<
    React.SetStateAction<SelectedWalletAccountState>
  > = (setStateAction) => {
    setSelectedWalletAccountInternal((prevSelectedWalletAccount) => {
      wasSetterInvoked = true;
      const nextWalletAccount =
        typeof setStateAction === "function"
          ? setStateAction(prevSelectedWalletAccount)
          : setStateAction;
          
      const accountKey = nextWalletAccount
        ? getUiWalletAccountStorageKey(nextWalletAccount)
        : undefined;
        
      if (accountKey) {
        localStorage.setItem(STORAGE_KEY, accountKey);
      } else {
        localStorage.removeItem(STORAGE_KEY);
      }
      
      return nextWalletAccount;
    });
  };
  
  // Restore saved wallet on mount
  useEffect(() => {
    const savedWalletAccount = getSavedWalletAccountAndWallet(wallets)?.account;
    const savedWallet = getSavedWalletAccountAndWallet(wallets)?.wallet;
    
    if (savedWalletAccount && savedWallet) {
      setSelectedWalletAccountInternal(savedWalletAccount);
      setSelectedWalletInternal(savedWallet);
    }
  }, [wallets]);
  
  // Keep selected account synchronized with connected wallets
  const walletAccount = useMemo(() => {
    if (selectedWalletAccount) {
      for (const uiWallet of wallets) {
        for (const uiWalletAccount of uiWallet.accounts) {
          if (uiWalletAccountsAreSame(selectedWalletAccount, uiWalletAccount)) {
            return uiWalletAccount;
          }
        }
        
        // If selected account's wallet is connected, use its first account
        if (
          uiWalletAccountBelongsToUiWallet(selectedWalletAccount, uiWallet) &&
          uiWallet.accounts[0]
        ) {
          return uiWallet.accounts[0];
        }
      }
    }
  }, [selectedWalletAccount, wallets]);
  
  const wallet = useMemo(() => {
    if (selectedWallet) {
      for (const uiWallet of wallets) {
        if (uiWallet.name === selectedWallet.name) {
          return uiWallet;
        }
      }
    }
  }, [selectedWallet, wallets]);
  
  // Clear selection if wallet disconnects
  useEffect(() => {
    if (selectedWalletAccount && !walletAccount) {
      setSelectedWalletAccountInternal(undefined);
    }
  }, [selectedWalletAccount, walletAccount]);
  
  return (
    <SelectedWalletAccountContext.Provider
      value={useMemo(
        () => [walletAccount, setSelectedWalletAccount, wallet],
        [walletAccount, wallet]
      )}
    >
      {children}
    </SelectedWalletAccountContext.Provider>
  );
}

Once our context is set up we can import and use it like so:

// src/main.tsx
import { StrictMode } from "react";
import { createRoot } from "react-dom/client";
import "./index.css";
import App from "./App.tsx";
import { SelectedWalletAccountContextProvider } from "./context/SelectedWalletAccountContextProvider.tsx";

createRoot(document.getElementById("root")!).render(
  <StrictMode>
    <SelectedWalletAccountContextProvider>
      <App />
    </SelectedWalletAccountContextProvider>
  </StrictMode>
);

Wallet List

With context set up to track wallet state, we can build the UI. Users need a way to see available wallets and connect them to our app. The Wallet Standard exposes all compatible browser wallets, so we'll create a dialog that lists them. We'll start with the wallet list item.

// features/auth/components/wallet_list_item.tsx
import { Button } from "@/components/ui/button"
import { SelectedWalletAccountContext } from "@/context/SelectedWalletAccountContext";
import { useConnect, type UiWallet } from "@wallet-standard/react-core";
import { useContext } from "react";

type Props = {
  wallet: UiWallet;
  setOpen: () => void;
};

export const WalletListItem = ({ wallet, setOpen }: Props) => {
  const [isConnecting, connect] = useConnect(wallet);
  const [_, setSelectedWalletAccount] = useContext(
    SelectedWalletAccountContext
  );
  
  const handleConnect = () => {
    try {
      // Connect returns array of accounts, we select the first one
      connect().then((res) => {
        setSelectedWalletAccount(res[0]);
      });
    } catch (error) {
      console.error("Failed to connect:", error);
    } finally {
      setOpen();
    }
  };
  
  if (!wallet) return;

  return (
    <li>
      <Button
        variant="outline"
        disabled={isConnecting}
        onClick={handleConnect}
        className="flex flex-row p-4 items-center justify-start gap-3 w-full"
      >
        <img alt="wallet logo" src={wallet.icon} className="w-6 h-6" />
        <p className="text-lg font-semibold">{wallet.name}</p>
      </Button>
    </li>
  );
};

One thing to note is that while we can fetch all wallets connected to the browser, you often only want the ones that support the chain your application is based on. To do this we can create a hook to fetch and filter these wallets for us. You can extend this to work for multiple chains if need be. Extracting this logic into a custom hook is production-grade because it encapsulates the filtering logic in a reusable, testable unit. It makes your components cleaner by separating concerns, and if you need to add more complex filtering logic later or support multiple chains, you only need to modify this one hook rather than hunting through multiple components.

// features/auth/hooks/useFilteredWallets.tsx
import { useWallets } from "@wallet-standard/react-core";

export function useFilteredWallets() {
  const wallets = useWallets();
  
  // Filter wallets that support Solana chains
  const solanaWallets = wallets.filter((uiWallet) =>
    uiWallet.chains.some((chain) => chain.startsWith("solana:"))
  );

  return solanaWallets;
}

Now we can implement the actual wallet list to render all connected wallets that match our base chain.

// features/auth/components/wallet_list.tsx
import { Button } from "@/components/ui/button";
import {
  DialogHeader,
  Dialog,
  DialogTrigger,
  DialogContent,
  DialogTitle,
  DialogDescription,
} from "@/components/ui/dialog";
import { WalletListItem } from "./wallet_list_item";
import { useFilteredWallets } from "../hooks/useFilteredWallets";
import { useState } from "react";
  
export const WalletList = () => {
  const [open, setOpen] = useState(false);
  const solanaWallets = useFilteredWallets();

  return (
    <Dialog open={open} onOpenChange={setOpen}>
      <form>
        <DialogTrigger asChild>
          <Button variant="outline">View Wallets</Button>
        </DialogTrigger>

        <DialogContent className="sm:max-w-106.25">
          <DialogHeader>
            <DialogTitle>Select Wallet</DialogTitle>
            <DialogDescription>
              Select the wallet you want to connect to Titan.
            </DialogDescription>
          </DialogHeader>

          <ul className="flex flex-col gap-2">
            {solanaWallets.map((wallet, idx) => (
              <WalletListItem
                key={idx}
                wallet={wallet}
                setOpen={() => setOpen(false)}
              />
            ))}
          </ul>
        </DialogContent>
      </form>
    </Dialog>
  );
};

Once a wallet is connected, we need to authenticate the user. This is where the full flow comes together: request nonce, sign it, send to backend. This is just going to be a simple button that triggers the auth flow.

The first thing that will happen on click is that we request a nonce from our backend. Immediately after we get the nonce we use the useSignIn hook to sign our message. We then extract the results we need and send them in our login request.

// features/auth/components/auth_buttons.tsx
import { useSignIn } from "@solana/react";
import { Button } from "@/components/ui/button";
import { requestNonce } from "../api/requestNonce";
import { loginWithWallet } from "../api/loginWithWallet";
import type { UiWallet } from "@wallet-standard/react-core";

type SignInProps = {
  address: string;
  wallet: UiWallet;
};

export const SignInButton = ({ wallet, address }: SignInProps) => {
  const signIn = useSignIn(wallet);
  
  if (!wallet) return;

  const handleSignIn = async () => {
    try {
      // Request nonce from backend
      const res = await requestNonce(address);

      // Sign the message with wallet's private key
      const { account, signedMessage, signature } = await signIn({
        nonce: res.nonce,
        domain: import.meta.env.VITE_APP_DOMAIN || "localhost:5173",
      });

      // Send signed data to backend for verification
      const loginResponse = await loginWithWallet({
        address: account.address,
        signatureBase58: signature,
        message: signedMessage,
        nonce: res.nonce,
      });
      
      // Store access token (you might want to use a state management solution)
      localStorage.setItem('access_token', loginResponse.access_token);
      
      console.log('Successfully authenticated!');
    } catch (error) {
      console.error("Failed to sign in:", error);
      // You might want to show this error to the user via a toast or alert
    }
  };
  
  return <Button onClick={handleSignIn}>Sign In</Button>;
};

Our finished App.tsx looks like this.

// App.tsx
import { useContext } from "react";
import { WalletList } from "./features/auth/components/wallet_list";
import { SelectedWalletAccountContext } from "./context/SelectedWalletAccountContext";
import { SignInButton } from "./features/auth/components/auth_buttons";

function App() {
  const [selectedWalletAccount, _, selectedWallet] = useContext(
    SelectedWalletAccountContext
  );

  return (
    <div className="flex gap-3 min-h-svh flex-col items-center justify-center">
      <div>
        <p className="text-lg font-semibold">
          Active account: {selectedWalletAccount?.address || 'None'}
        </p>
      </div>

      <WalletList />

      {selectedWalletAccount && selectedWallet && (
        <SignInButton
          address={selectedWalletAccount.address}
          wallet={selectedWallet}
        />
      )}
    </div>
  );
}

export default App;

Frontend Summary

That wraps up the frontend implementation. We've built a wallet connection system that integrates with the Wallet Standard to support any compatible Solana wallet, not just Phantom. The context provider manages wallet selection persistence across sessions, while the sign-in flow requests a nonce from the backend, prompts the user to sign it with their wallet, and sends the signed message back for verification. The private key never leaves the user's wallet, ensuring security throughout the process.

Conclusion

We've implemented a complete wallet-based authentication system for Solana. The backend generates unique nonces with Redis-backed storage, creates SIWS-compliant challenge messages, verifies signatures using Solana's cryptographic primitives, and manages JWT token generation after successful verification. The frontend leverages the Wallet Standard to support multiple wallet providers and handles the signing flow securely within the user's wallet extension.

This auth pattern is fundamentally different from traditional username/password authentication because the user proves ownership of their wallet through cryptographic signatures rather than shared secrets. The nonce prevents replay attacks, the standardized message format prevents phishing, and the time-limited Redis storage ensures old challenges can't be reused. You can extend this system by adding additional user data to the JWT payload, implementing token refresh logic, or supporting multiple blockchain networks with minimal modifications to the core flow.

What Is Authentication? A Beginner's Guide (2026)

Tue, 01 Sep 2026 05:07:56 +0000

Every time you type your email and password into a login form, something is quietly deciding whether you actually get in. That decision — proving you are who you say you are — is called authentication, and it's one of those concepts every developer touches constantly but rarely stops to explain from scratch.

If you've ever wondered what actually happens between "click Sign In" and "welcome back," or mixed up authentication with authorization in an interview, this guide is for you. By the end, you'll know exactly what authentication is, how the major methods work under the hood, and how to build a basic authentication flow yourself.

What Is Authentication? (Quick Answer)

Authentication is the process of verifying that someone is who they claim to be. It answers one question: "Who are you?" This usually happens by checking a password, a code from your phone, a fingerprint, or a token — something only the real user should have or know.

Authentication is different from authorization, which answers a separate question: "What are you allowed to do?" A logged-in user is authenticated. Whether that user can delete another person's account is authorization. Mixing these two up is one of the most common beginner mistakes — keep them mentally separate from the start.

💡 Simple way to remember it: Authentication = ID check at the door. Authorization = the guest list that decides which rooms you can enter once you're inside.

Why Authentication Matters

Without proper authentication and authorization, an app that stores personal data could expose private information to unauthorized users. Authentication provides the identity context that many authorization, personalization, and auditing systems rely on.

It matters for a few concrete reasons:

Privacy — only the right person sees their own data
Security — prevents account takeover and unauthorized access
Personalization — apps can remember who you are across visits
Accountability — actions can be traced back to a real identity (important for admin tools, financial apps, audit logs)

Authentication vs. Authorization: The Difference That Trips Everyone Up

	Authentication	Authorization
Question it answers	Who are you?	What can you do?
Happens	First	After authentication
Example	Logging in with a password	Only admins can access `/admin`
Failure result	401 Unauthorized	403 Forbidden

Why the HTTP status codes are confusingly named: 401 Unauthorized actually means "you're not authenticated" (log in first), while 403 Forbidden means "you're authenticated, but not allowed to do this." Yes, 401 should really be called "Unauthenticated" — it's a long-standing naming quirk in the HTTP spec that trips up almost every developer at least once.

Related: Role-Based Access Control (RBAC) in Next.js 16 goes deep on the authorization half of this once you're ready for it.

How Authentication Works (Step by Step)

At a high level, almost every authentication system follows the same basic loop:

The user provides credentials — a password, a fingerprint, a one-time code, or an existing account from another provider (like signing in with Google)
The server verifies those credentials — checking a hashed password, validating a signed token, or confirming a biometric match
The server issues proof of identity — usually a session or a token, stored in a cookie or sent back to the client
That proof is sent with future requests — so the user doesn't have to log in again on every page

User submits credentials
        ↓
Server verifies credentials
        ↓
Server issues session/token
        ↓
Client stores it (cookie)
        ↓
Future requests include it
        ↓
Server verifies it's still valid

That last step — verifying the proof of identity on every request — is what keeps a user "logged in" without asking for their password on every single page.

The Main Types of Authentication

There isn't just one way to authenticate someone. Here are the methods you'll actually run into as a developer.

1. Password-Based Authentication

The classic: a username/email plus a password, checked against a hashed value stored in your database. Never store plain-text passwords — always hash them with a slow, password-specific hashing algorithm such as Argon2id. If it's not available, bcrypt or another appropriate password hashing algorithm can be used.

// lib/auth/hash-password.ts
import bcrypt from "bcryptjs";

const SALT_ROUNDS = 12;

export async function hashPassword(plainPassword: string): Promise<string> {
  return bcrypt.hash(plainPassword, SALT_ROUNDS);
}

export async function verifyPassword(
  plainPassword: string,
  hashedPassword: string
): Promise<boolean> {
  return bcrypt.compare(plainPassword, hashedPassword);
}

What's happening here: bcrypt.hash() doesn't just scramble the password — it applies a slow, computationally expensive algorithm on purpose, which increases the cost of each password guess and makes large-scale brute-force attacks significantly more expensive. SALT_ROUNDS = 12 is above OWASP's minimum bcrypt work factor of 10, but the right value depends on your server's hardware and traffic. Benchmark your production environment and choose a cost that makes password verification sufficiently expensive without creating unacceptable latency.

⚠️ bcrypt limitation: bcrypt has a hard 72-byte input limit, and most implementations (including bcryptjs) silently truncate anything past it rather than erroring. Because UTF-8 characters like emoji or accented letters can take up to 4 bytes each, a password that looks well under the limit in characters can still get silently cut short in bytes — which can cause two different passwords to be treated as equivalent after truncation.
OWASP currently recommends enforcing a maximum of 72 bytes (or less, depending on the implementation) when bcrypt is used. Because UTF-8 characters can occupy multiple bytes, a character-count limit alone doesn't necessarily correspond to bcrypt's byte limit.

⚠️ Common Mistake: Comparing passwords with a plain === check after "encrypting" them with something reversible like Base64. That's encoding, not hashing — it can be reversed instantly. Only use a dedicated password-hashing library.

2. Session-Based Authentication

After a successful login, the server creates a session record stored in server-side session storage such as a database or shared cache — and gives the browser a random session ID in an httpOnly cookie. On every request, the server looks up that ID to know who's logged in.

// lib/auth/session.ts
import { cookies } from "next/headers";
import { randomUUID } from "crypto";

export async function createSession(userId: string, expiresAt: Date) {
  // Generate a random, unguessable session ID — never store the raw
  // userId (or anything else predictable) directly as the cookie's
  // value. The cookie is a reference you look up server-side; it
  // should never double as proof of identity on its own.
  const sessionId = randomUUID();

  // Persist the mapping server-side, e.g.:
  // await db.session.create({ data: { sessionId, userId, expiresAt } });

  const cookieStore = await cookies();

  cookieStore.set("session_id", sessionId, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    expires: expiresAt,
    path: "/",
  });
}

Why each flag matters: httpOnly stops client-side JavaScript from reading the cookie (blocking a common XSS attack path). secure means it's only sent over HTTPS. sameSite: "lax" limits when the browser sends the cookie in cross-site requests and provides some CSRF protection. For state-changing operations, you should still implement an appropriate CSRF defense rather than relying on SameSite alone.

Pros: straightforward server-side revocation; deleting a session record can invalidate that session immediately, and deleting all of a user's sessions can log them out everywhere.
Cons: can require a server-side session lookup on authenticated requests, although caching can reduce the cost.

3. Token-Based Authentication (JWT)

Instead of looking anything up server-side, a JSON Web Token (JWT) packs the user's identity directly into a signed token. In a stateless JWT design, the server can verify the token cryptographically without looking up a session record in the database.

// lib/auth/jwt.ts
import { SignJWT, jwtVerify } from "jose";

const secretKey = new TextEncoder().encode(process.env.AUTH_SECRET);

export async function signToken(userId: string, expiresAt: Date) {
  return new SignJWT({})
    .setProtectedHeader({ alg: "HS256" })
    .setSubject(userId)
    .setIssuedAt()
    .setExpirationTime(expiresAt)
    .sign(secretKey);
}

export async function verifyToken(token: string) {
  try {
    const { payload } = await jwtVerify(token, secretKey, {
      algorithms: ["HS256"],
    });
    return payload;
  } catch {
    return null; // invalid or expired
  }
}

What's happening here: jose is the standard, actively maintained library for signing and verifying JWTs using the Web Crypto API — it works in Node.js, edge runtimes, and browsers. setSubject(userId) stores the user's ID in the token's standard sub claim. jwtVerify() automatically rejects the token if the signature doesn't match or if it's expired, so you never write manual expiry checks.

⚠️ Signing is not encryption. A JWT's payload is only base64url-encoded, not encrypted — anyone can decode and read it. The signature only proves it wasn't tampered with. Never put sensitive data (passwords, secrets) inside a JWT payload.

Pros: no database lookup needed to verify identity, works well across distributed/stateless servers.
Cons: harder to instantly revoke a single token before it expires (it's valid until it naturally expires unless you build extra machinery around it).

💡 For a deeper side-by-side of these two models — including how each behaves at scale — see Session vs JWT: Which Should You Use in Next.js 16?

OAuth 2.0 is an authorization framework that lets an application obtain limited access to resources on behalf of a user. It doesn't, by itself, define how an application verifies the user's identity.

For "Sign in with Google," "Sign in with Microsoft," and similar login flows, applications commonly use OpenID Connect (OIDC) — an identity layer built on top of OAuth 2.0. The identity provider authenticates the user and returns an ID token containing claims about that authentication.

User clicks "Sign in with GitHub"
        ↓
Redirected to GitHub
        ↓
User authenticates and approves access
        ↓
GitHub redirects back with a code
        ↓
Your server exchanges the code for tokens
        ↓
Your server validates the OIDC identity information
        ↓
Your app creates its own session

This is why OAuth is so popular for beginners and production apps alike — you outsource the hardest parts (password storage, breach risk, 2FA) to a provider that already does it well.

5. Multi-Factor Authentication (MFA / 2FA)

MFA requires more than one proof of identity — typically "something you know" (a password) plus "something you have" (a phone, an authenticator app code, a hardware key). Even if a password leaks, the attacker still can't get in without the second factor.

6. Passwordless Authentication (Magic Links & Passkeys)

Two increasingly common alternatives to passwords:

Magic links — the user enters their email, gets a one-time sign-in link, and clicking it logs them in. No password to remember or leak.
Passkeys (WebAuthn) — device-based authentication using Face ID, Windows Hello, or a hardware security key. No shared secret exists to steal in the first place, which makes passkeys resistant to phishing in a way passwords fundamentally aren't.

A Minimal Authentication Flow in Next.js

Here's a simplified but realistic login flow using Next.js 16, TypeScript, and session cookies — the same core pattern used by most production apps, just without the database wiring.

// actions/login.ts
"use server";

import { redirect } from "next/navigation";
import { verifyPassword } from "@/lib/auth/hash-password";
import { createSession } from "@/lib/auth/session";
import { z } from "zod";

const loginSchema = z.object({
  email: z.email(),
  password: z.string().min(8),
});

export async function login(prevState: unknown, formData: FormData) {
  const parsed = loginSchema.safeParse({
    email: formData.get("email"),
    password: formData.get("password"),
  });

  if (!parsed.success) {
    return { error: "Enter a valid email and password." };
  }

  // Look up the user in your database (pseudocode)
  const user = await db.user.findUnique({ where: { email: parsed.data.email } });

  if (!user || !(await verifyPassword(parsed.data.password, user.passwordHash))) {
    // Same generic error for both cases — don't reveal which one was wrong
    return { error: "Invalid email or password." };
  }

  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000); // 7 days
  await createSession(user.id, expiresAt);

  redirect("/dashboard");
}

What's happening here: the form data is validated with Zod before touching the database — never trust raw input. Notice the login failure returns the same generic message whether the email doesn't exist or the password is wrong; revealing which one failed makes it easier for attackers to enumerate valid accounts. A working session gets created only after the password check succeeds, then the user is redirected.

⚠️ Common Mistake: Checking authentication only in proxy and assuming that's enough. Proxy-level checks are a good UX shortcut (fast redirect before a page even loads), but sensitive Server Actions, Route Handlers, and data-access functions should independently verify authentication and authorization rather than relying solely on proxy.ts.

Building this by hand is a great way to learn, but most production apps reach for a maintained library instead — see How to Add Auth.js (NextAuth v5) in Next.js 16, Add Clerk Authentication to Next.js 16, or (if you're already on Supabase) Supabase Auth vs Firebase Auth.

Common Authentication Mistakes to Avoid

Storing plain-text passwords — always hash with Argon2id or bcrypt, never store or log the raw password
Storing a predictable value as the session cookie — the cookie should be a random, unguessable reference, never the raw user ID or anything else an attacker could construct
Weak or reused session/JWT secrets — generate a long, random secret and never commit it to git
Revealing which field was wrong — "Invalid email" vs. "Invalid password" tells attackers an account exists
Skipping rate limiting — without it, attackers can brute-force passwords with unlimited attempts
Relying only on client-side checks — a hidden button or disabled form field doesn't stop a direct API request
Forgetting to expire sessions/tokens — every session and token should have a sane expiry, not live forever

Frequently Asked Questions

What is the difference between authentication and authorization?

Authentication confirms who someone is (logging in). Authorization decides what they're allowed to do once they're recognized (permissions, roles, access control). You always need authentication before authorization can happen.

Yes — a login system is simply the implementation of authentication. Whatever mechanism confirms a user's identity (password, OAuth, passkey) is functioning as authentication, regardless of what you call the feature.

What's the difference between sessions and JWTs?

A session stores authentication/session state on the server and gives the browser only a random reference ID, which allows instant revocation. A JWT stores the identity data directly inside a signed token the server can verify without a database lookup, trading easy revocation for less server-side state.

Keep JWT minimal — a JWT should not be treated as a general-purpose user profile or database replacement.

Do I need a library to build authentication, or can I build it myself?

You can build basic password + session authentication yourself using the patterns above, but for anything production-facing, an established library (Auth.js, Clerk, Better Auth, or your database provider's built-in auth) is strongly recommended — they handle edge cases like token rotation, breach detection, and secure defaults that are easy to get subtly wrong by hand.

Is two-factor authentication (2FA) actually necessary?

For anything holding sensitive data — financial info, personal messages, admin access — yes. 2FA dramatically reduces account takeover risk even when a password leaks, since the attacker also needs the second factor.

Are passkeys better than passwords?

Generally yes, from a security standpoint — passkeys are phishing-resistant because there's no shared secret to trick someone into revealing. Adoption is still growing, though, so most apps currently offer passkeys as an option alongside passwords rather than a full replacement.

Wrapping Up

Authentication boils down to one question — "who are you?" — answered through a password, a token, a device, or some combination of them. Once you separate authentication from authorization, the ecosystem becomes easier to understand: passwords and passkeys are authentication mechanisms, sessions and JWTs are ways to maintain authenticated state, and OAuth/OIDC provide delegated authorization and federated identity.

If you're building this in a real Next.js app, the next logical steps are wiring up role-based authorization on top of your authentication layer, and deciding between session-based and JWT-based auth based on whether instant revocation matters for your product.

Continue Learning

Free Developer Tools

Zod Schema Generator — generate a validated schema for your role/permission payloads straight from a JSON sample or TypeScript interface, including a ready-to-use Server Action.
Supabase RLS Policy Generator — pair this guide's application-level RBAC with database-level Row Level Security. Generates owner-only, team, and admin-override policies with the auth.uid() performance wrapper built in.

Session vs JWT: Which Should You Use in Next.js 16?

Tue, 25 Aug 2026 04:12:26 +0000

You're building a login flow in Next.js 16, and you hit the question every auth tutorial glosses over: should the logged-in state live in a session or a JWT? Half the guides you find use one, half use the other, and almost none of them tell you why — or what breaks if you pick wrong.

Here's the annoying part: both approaches look nearly identical from the outside. A cookie gets set, the user stays logged in, everyone's happy. The difference only shows up later — when you need to log a user out of every device instantly, when your app scales past one server, or when you're debugging why a "revoked" user can still hit your API for another six days.

By the end of this guide, you'll know exactly how sessions and JWTs work under the hood, see real, working code for both in Next.js 16 — using jose, Server Actions, and proxy.ts — and know which one actually fits your project instead of copying whatever the last tutorial you read happened to use.

Why This Is Tricky

Most explanations of "session vs JWT" get stuck comparing them as if they're two totally separate technologies. They're not. In both approaches, the browser stores a cookie. The real difference is what that cookie contains, and where the source of truth lives:

Session-based auth: the cookie holds a random ID. The actual user data lives in your database. Every request that needs to know "who is this?" looks it up server-side.
JWT-based auth: the cookie holds the user data itself, cryptographically signed. Your server can verify it's untampered without ever touching a database.

That one distinction — lookup vs. self-contained — is what drives every tradeoff in this post: revocation, scaling, latency, and how much you need to trust the cookie itself.

💡 Tip: If you've used Auth.js (NextAuth v5), you've already used both without necessarily noticing — its session: { strategy: "jwt" } and session: { strategy: "database" } options are exactly this same choice, just configured for you.

Prerequisites

This guide uses:

Next.js 16 with the App Router
TypeScript in strict mode
React Compiler enabled (no manual useMemo/useCallback needed)
Tailwind CSS for the (minimal) UI examples

You don't need a real database to follow along — the JWT section has zero dependencies, and the session section uses a generic db client you can swap for Postgres, Supabase, or whatever you're already using.

How Sessions Work

💡 Think of it like: a coat check ticket. The ticket itself is just a number — it means nothing on its own. The actual coat (your user data) stays with the attendant (your database). Lose the ticket, and the attendant can also just... stop honoring it. Instantly.

User logs in with the right credentials.
Your server generates a random token, stores it in a sessions table alongside the user's ID and an expiry, and sends that token back as an httpOnly cookie.
On every request, your server takes the cookie value, looks it up in the database, and either finds a valid session or doesn't.
To log someone out — including forcibly, from your side — you delete the row. Done. The cookie is now worthless.

The tradeoff: every authenticated request costs a database round trip (unless you cache it), but you get instant, guaranteed revocation.

How JWTs Work

💡 Think of it like: a sealed, signed letter. Anyone can read what's inside once it's opened, but nobody can forge your signature or quietly edit the contents without breaking the seal. The letter is self-sufficient — you don't need to call anyone to confirm it's real, just check the seal.

User logs in with the right credentials.
Your server creates a token containing the user's ID (and whatever else you want) and signs it with a secret key.
On every request, your server checks the signature against that same secret. If it matches, the data inside is trusted — no database lookup required.
To log someone out, you delete the cookie client-side. But if someone already has a copy of that token, it's still valid — and still verifiable — until it naturally expires. There's no built-in way to say "actually, ignore this one."

The tradeoff: verification is fast and needs no database, but you give up the ability to instantly kill a single session without extra machinery.

⚠️ Common Mistake: Calling a JWT stored in a cookie a "session" and assuming it behaves like one. It doesn't — a JWT has no server-side record at all unless you deliberately build one (see the revocation section below). If your mental model is "session," you'll be surprised the first time you try to force-logout a user and nothing happens.

⚠️ Cookie size limits: browsers cap a single cookie at roughly 4KB, and most reverse proxies (Nginx, Cloudflare) reject requests once the total header size gets much past 8KB. A session-ID cookie is always tiny — it's just a random string. A JWT cookie grows with every claim you cram into the payload (roles, permissions, profile fields). Stuff enough into it and the cookie silently fails to set, or your CDN starts 400-ing requests, with no obvious error pointing back at "your JWT got too big." Keep JWT payloads minimal — an ID and maybe a role, not a serialized user object.

Step 1: Set Up the Shared Pieces

Both approaches need somewhere to keep a signing secret. Add one to your environment file:

# .env.local
SESSION_SECRET=your-long-random-secret-here

Generate a strong value instead of typing something memorable:

node -e "console.log(crypto.randomBytes(32).toString('hex'))"

⚠️ Common Mistake: Committing SESSION_SECRET to git, or reusing your .env.local value in production. Treat it exactly like a database password — if it leaks, an attacker can forge valid sessions for any user, for either approach below.

Step 2: Build JWT-Based Auth with `jose`

jose is the standard library for signing and verifying JWTs in an Edge-compatible way — it uses the Web Crypto API instead of Node's crypto module, so it works identically in Server Actions, Route Handlers, and proxy.ts.

npm install jose

Create the sign/verify helpers

// lib/jwt/session.ts
import "server-only";
import { SignJWT, jwtVerify } from "jose";

const secretKey = process.env.SESSION_SECRET;
const encodedKey = new TextEncoder().encode(secretKey);

export async function encrypt(userId: string, expiresAt: Date) {
  return new SignJWT({})
    .setProtectedHeader({ alg: "HS256" })
    .setSubject(userId) // sub — who this token belongs to
    .setIssuedAt() // iat — when it was issued
    .setExpirationTime(expiresAt) // exp — when it stops being valid
    .sign(encodedKey);
}

export async function decrypt(token: string | undefined = "") {
  try {
    const { payload } = await jwtVerify(token, encodedKey, {
      algorithms: ["HS256"],
    });
    return payload; // payload.sub is the userId; iat/exp are unix seconds
  } catch {
    // Invalid signature, tampered payload, or expired token
    return null;
  }
}

What's happening here: instead of a custom userId field, this uses the standard, registered JWT claims — sub (subject, via .setSubject()), iat (issued-at, via .setIssuedAt()), and exp (expiry, via .setExpirationTime()). These three are part of the JWT spec itself, not a jose-specific convention, so any JWT library — in any language — knows how to read them. jwtVerify automatically checks exp and rejects an expired token before your code ever sees the payload, so you never write manual date comparisons.

⚠️ Signing is not encryption. SignJWT — despite this file calling the wrapper functions encrypt/decrypt for readability — does not hide the payload. A JWT's contents are only base64url-encoded, not encrypted, so anyone who intercepts the cookie (or just opens DevTools → Application → Cookies) can decode and read sub, iat, and exp in plain text. What the signature guarantees is that the payload wasn't tampered with — change one character and jwtVerify rejects it. Never put anything genuinely secret (passwords, tokens for other services, PII you wouldn't want exposed) inside a signed JWT. If you actually need to hide the contents too, that's a different primitive — JWE — which jose supports separately via EncryptJWT/jwtDecrypt.

💡 Do you still need setExpirationTime if you also track expiry elsewhere? No — and the version above deliberately avoids the redundancy. Compute the expiry date once, and hand that same Date to both setExpirationTime() (for the JWT's own exp claim) and the cookie's expires option, as shown in the next step. Two separately-computed "7 days from now" values can drift apart by milliseconds and give you two conflicting sources of truth for the same thing — pick one.

// lib/jwt/actions.ts
"use server";

import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { encrypt } from "./session";

export async function createSession(userId: string) {
  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000);
  const session = await encrypt(userId, expiresAt); // same Date used for exp and the cookie
  const cookieStore = await cookies();

  cookieStore.set("session", session, {
    httpOnly: true,
    secure: true,
    expires: expiresAt,
    sameSite: "lax",
    path: "/",
  });
}

export async function deleteSession() {
  const cookieStore = await cookies();
  cookieStore.delete("session");
  redirect("/login");
}

What's happening here: httpOnly: true keeps the cookie invisible to client-side JavaScript, which stops it from being stolen via an XSS attack. secure: true means it's only ever sent over HTTPS. sameSite: "lax" blocks the cookie from being attached to most cross-site requests, which is your main defense against CSRF here. None of this is JWT-specific — you'd want the exact same flags on a session-ID cookie too.

Verify the session with a Data Access Layer

Don't scatter decrypt() calls across every page. Centralize verification in one cached function — this is what Next.js's own docs call a Data Access Layer (DAL).

// lib/jwt/dal.ts
import "server-only";
import { cache } from "react";
import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { decrypt } from "./session";

export const verifySession = cache(async () => {
  const cookieStore = await cookies();
  const token = cookieStore.get("session")?.value;
  const session = await decrypt(token);

  if (!session?.sub) {
    redirect("/login");
  }

  return { isAuth: true, userId: session.sub };
});

What's happening here: wrapping this in React's cache() means that no matter how many components on the same page call verifySession(), the actual decrypt-and-check logic only runs once per request — every subsequent call reuses the result. session.sub is the standard claim set by .setSubject() earlier, so this reads it back out under a friendlier userId name for the rest of your app. Call this at the top of any Server Component, Server Action, or Route Handler that needs to know who's logged in.

// app/dashboard/page.tsx
import { verifySession } from "@/lib/jwt/dal";

export default async function DashboardPage() {
  const { userId } = await verifySession();

  return <h1>Welcome back, user {userId}</h1>;
}

Add an optimistic check in `proxy.ts`

In Next.js 16, middleware.ts was renamed to proxy.ts — same file convention, same idea. It's the first thing that runs before a request reaches a page, which makes it a good place for a fast, optimistic redirect. Full verification still happens in the DAL above — proxy.ts just avoids letting an obviously-unauthenticated request render a protected page at all.

// proxy.ts
import { NextRequest, NextResponse } from "next/server";

const protectedRoutes = ["/dashboard"];
const publicRoutes = ["/login", "/signup"];

export default function proxy(req: NextRequest) {
  const path = req.nextUrl.pathname;
  const isProtectedRoute = protectedRoutes.some((route) => path.startsWith(route));
  const isPublicRoute = publicRoutes.includes(path);

  // Optimistic check only — we just look for the cookie's presence.
  // We deliberately don't verify the signature here; that happens
  // in verifySession() inside the Data Access Layer.
  const cookie = req.cookies.get("session")?.value;

  if (isProtectedRoute && !cookie) {
    return NextResponse.redirect(new URL("/login", req.nextUrl));
  }

  if (isPublicRoute && cookie) {
    return NextResponse.redirect(new URL("/dashboard", req.nextUrl));
  }

  return NextResponse.next();
}

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico).*)"],
};

⚠️ Common Mistake: Treating proxy.ts as your only security check. It's a UX nicety that avoids a flash of protected content — it is not a substitute for re-verifying the session inside every Server Action and Route Handler that actually touches data. A request can always be sent directly, bypassing whatever page it "should" have come from.

Step 3: Build Database-Backed Sessions

Now the other approach — a real session table your server checks on each request.

Create the sessions table

-- Works for Postgres/Supabase; adjust types for your database
create table sessions (
  token_hash text primary key,
  user_id uuid not null references auth.users(id) on delete cascade,
  expires_at timestamptz not null,
  created_at timestamptz not null default now()
);

create index idx_sessions_user_id on sessions (user_id);

What's happening here: notice the primary key is token_hash, not token. We never store the raw session token in the database — only its hash. This mirrors how you'd never store a plaintext password: if your database ever leaked, an attacker with the hashes still couldn't reconstruct a working cookie.

⚠️ Cleanup: expiring a session only stops it from being accepted — the expires_at < now() check in verifyDbSession below handles that. It does not delete the row. Left alone, this table grows forever, one row per login, most of them long past their expiry date. Run a scheduled cleanup — a Vercel Cron job hitting a small Route Handler once a day is enough for most apps:
delete from sessions where expires_at < now();
This is purely a housekeeping/performance concern (an unbounded table gets slower to index and back up over time), not a security one — an expired row is already useless for authentication either way.

// lib/db-session/create.ts
import "server-only";
import { randomBytes, createHash } from "crypto";
import { cookies } from "next/headers";
import { db } from "@/lib/db";

function hashToken(token: string) {
  return createHash("sha256").update(token).digest("hex");
}

export async function createDbSession(userId: string) {
  const token = randomBytes(32).toString("hex"); // goes to the browser
  const tokenHash = hashToken(token); // goes to the database
  const expiresAt = new Date(Date.now() + 7 * 24 * 60 * 60 * 1000);

  await db.session.create({
    data: { tokenHash, userId, expiresAt },
  });

  const cookieStore = await cookies();
  cookieStore.set("session", token, {
    httpOnly: true,
    secure: true,
    sameSite: "lax",
    expires: expiresAt,
    path: "/",
  });
}

What's happening here: randomBytes(32) generates a token with enough entropy that guessing it is computationally infeasible — this is the piece doing the actual security work, not the hashing. We hash it with SHA-256 purely so a database leak doesn't hand out working session tokens; the browser still holds the real, unhashed token in its cookie.

Verify the session (with caching, so it doesn't hit the database on every render)

// lib/db-session/dal.ts
import "server-only";
import { cache } from "react";
import { cookies } from "next/headers";
import { createHash } from "crypto";
import { redirect } from "next/navigation";
import { db } from "@/lib/db";

function hashToken(token: string) {
  return createHash("sha256").update(token).digest("hex");
}

export const verifyDbSession = cache(async () => {
  const cookieStore = await cookies();
  const token = cookieStore.get("session")?.value;

  if (!token) redirect("/login");

  const tokenHash = hashToken(token);
  const session = await db.session.findUnique({
    where: { tokenHash },
    include: { user: true },
  });

  if (!session || session.expiresAt < new Date()) {
    redirect("/login");
  }

  return { isAuth: true, userId: session.userId, user: session.user };
});

What's happening here: just like the JWT version, cache() means one database lookup per request no matter how many components ask "who's logged in?" This is the piece that makes database sessions viable in practice — without it, a page with five components each checking auth would fire five identical queries.

Revoking a session — the whole point of this approach

// lib/db-session/delete.ts
"use server";

import { cookies } from "next/headers";
import { redirect } from "next/navigation";
import { createHash } from "crypto";
import { db } from "@/lib/db";

function hashToken(token: string) {
  return createHash("sha256").update(token).digest("hex");
}

export async function deleteDbSession() {
  const cookieStore = await cookies();
  const token = cookieStore.get("session")?.value;

  if (token) {
    await db.session.delete({ where: { tokenHash: hashToken(token) } }).catch(() => {});
  }

  cookieStore.delete("session");
  redirect("/login");
}

// Force-logout every session for a user — e.g. after a password reset
export async function revokeAllSessionsForUser(userId: string) {
  await db.session.deleteMany({ where: { userId } });
}

What's happening here: revokeAllSessionsForUser is the function you can't build with plain JWTs — one query, and every device that user is logged in on is instantly signed out, because the next request they make finds no matching row. This is the single biggest practical reason teams reach for database sessions over JWTs.

proxy.ts looks identical to the JWT version above — it's still just checking whether the session cookie exists, since that check never needed to know which auth strategy is behind it.

Session vs JWT: Side-by-Side

	Session (database)	JWT
Where the data lives	Server-side (database row)	Inside the token itself
Cookie contents	Random, meaningless ID	Signed, self-contained payload
Instant revocation	✅ Delete the row	❌ Not without extra machinery
Force-logout everywhere	✅ One query	❌ Requires a blocklist or short expiry + refresh
Per-request cost	One DB lookup (cacheable per request)	No DB call — just signature verification
Works well at scale / multi-server	Needs a shared database (usually already true)	Naturally stateless, nothing to share
Payload can go stale	No — always reads current data	Yes — data inside is frozen until re-issued
Implementation complexity	Slightly more (schema, hashing, cleanup)	Slightly less (no schema needed)
Best for	Apps where instant revocation matters <br/> (banking, admin tools, anything security-sensitive)	High-traffic, distributed systems where avoiding a <br/>DB hit per request matters

💡 Tip: "JWTs don't need a database" is true for verification, but most real apps still store something — a refresh-token table, a denylist, or at minimum a passwordChangedAt timestamp checked against the token's iat (issued-at) claim. The stateless promise of JWTs is a little softer in practice than it sounds in theory.

A Closer Look: What "Horizontal Scaling" Actually Means Here

"Naturally stateless" in the table above is doing a lot of work, so let's unpack it. Say your app runs on five server instances behind a load balancer — a request from the same user could land on a different instance every time.

With database sessions: whichever instance handles the request just needs to reach the same database everyone else does. In practice this is a non-issue for most Next.js apps, since you already have one shared database — every instance was already talking to it for everything else. The "scaling problem" people worry about here mostly doesn't exist unless you're deliberately running sessions in something instance-local, like in-memory storage (don't do that).
With JWTs: verification needs nothing but the signing secret, which every instance already has as an environment variable. No instance has to coordinate with any other instance, or with a database, to answer "is this token valid?" That's genuinely useful once you're running at the edge — Cloudflare Workers, Vercel Edge Functions — across multiple regions, where a round trip to a single-region database could add real, noticeable latency to every request.

So the honest version: for a typical app with one shared Postgres/Supabase database, this isn't really a deciding factor — you're already "horizontally scaled" for sessions for free. It starts to matter once you're running truly distributed, multi-region, or edge-first infrastructure where a database round trip per request is a real, measured cost, not a hypothetical one.

Sliding (Rolling) Sessions

So far, every example here uses a fixed expiry — log in, get 7 days, and after 7 days you're logged out no matter how active you were. A sliding session (also called a rolling session) instead extends the expiry every time the user does something, so an active user effectively never gets logged out, while an idle one still expires on schedule.

With database sessions, this is simple: on every successful verifyDbSession() call, update that row's expires_at to "now + 7 days" again.
```
// Inside verifyDbSession, after confirming the session is valid
await db.session.update({
  where: { tokenHash },
  data: { expiresAt: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000) },
});
```
One extra write per (cached) verification — cheap, and the source of truth (the row) is already being touched anyway.

💡 Tip: In production it's common to only extend the session once every few hours instead of on every request to avoid unnecessary writes.

With JWTs, this is more work: the exp claim is baked into the signature at issue time — you can't quietly extend it without re-signing a brand-new token and setting a brand-new cookie on the response. Doable inside a Route Handler or Server Action (create a fresh token with a new expiresAt, call cookies().set() again), but it means writing a cookie back on requests that otherwise wouldn't need one, which is easy to forget to wire up consistently across every route.

💡 Tip: If "stay logged in while active, expire after a week of silence" is a real requirement for your app, that alone is a reasonable tie-breaker toward database sessions — it's a one-line update there versus meaningfully more plumbing with JWTs.

Can You Get Revocation With JWTs?

Yes, with a tradeoff. Two common patterns:

Short expiry + refresh tokens. Issue an access token that expires in 10–15 minutes, plus a longer-lived refresh token stored in the database. To revoke, you delete the refresh token — the access token is still technically valid, but only for a few more minutes, which is an acceptable blast radius for most apps.
A denylist. Keep a small, fast-to-check store (Redis is the usual choice) of token IDs (jti claims) that have been explicitly revoked. Every verification also checks this list. This reintroduces a lookup on every request — at that point, you've mostly reinvented database sessions with extra steps.

Neither of these makes JWTs behave exactly like sessions — they just narrow the gap. If instant, guaranteed revocation is a hard requirement (think: a compromised admin account), database sessions remove the problem entirely instead of managing around it.

Which One Should You Actually Use?

Building a typical SaaS dashboard, internal tool, or content site? Database sessions. The DB hit is cheap with caching, and "log this user out right now" is a feature you'll eventually need, even if you don't think so today.
Building something with genuinely massive, distributed, stateless traffic (think: an API consumed by thousands of independent clients, or infrastructure where adding a database round trip to every request is a real cost)? JWTs earn their keep here.
Already using Auth.js or Clerk? You don't have to choose by hand — Auth.js exposes session: { strategy: "jwt" | "database" } directly, and Clerk manages this decision for you behind its own infrastructure.
Not sure yet? Default to database sessions. It's the safer, more debuggable choice, and the performance cost is rarely the bottleneck people assume it'll be — cache the lookup with cache() as shown above and it disappears from your profiler.

Frequently Asked Questions

Can I combine both approaches?

Yes — this is actually what "refresh tokens" are: a short-lived JWT for fast verification, backed by a database-stored refresh token for revocation. You get JWT-speed reads most of the time, with a real revocation point when you need one.

No, and the difference matters for security. An httpOnly cookie can't be read by client-side JavaScript, so it's protected from XSS attacks that steal tokens. localStorage is fully readable by any script running on your page — a single XSS vulnerability anywhere in your dependency tree can leak every token stored there. Always use httpOnly cookies for auth tokens in a Next.js app.

Does `proxy.ts` need to fully verify the session on every request?

No, and for JWT-based auth verifying in proxy.ts with jose is genuinely fine performance-wise since it needs no database call. The stronger rule is: never treat proxy.ts as your only check. Always re-verify inside the Server Action or Route Handler that actually reads or writes data — proxy.ts can be bypassed by hitting that endpoint directly.

Why hash the session token before storing it in the database?

The same reason you hash passwords — if your database is ever compromised (a leaked backup, a misconfigured access policy), the attacker gets a list of hashes they can't turn back into working session cookies. It costs you one sha256 call per request, which is effectively free.

Which one does Auth.js use by default?

Auth.js defaults to the "jwt" strategy unless you configure a database adapter, in which case it switches to "database" automatically. You can also set session: { strategy: "jwt" } explicitly even with an adapter configured, if you want JWTs for speed while still persisting user accounts.

Wrapping Up

Sessions and JWTs aren't competing standards — they're two different answers to "where does the source of truth for a logged-in user live?" Sessions keep it on your server, trading a database lookup for instant, total control over who stays logged in. JWTs keep it in the token itself, trading that control for verification that never has to leave the request.

For most Next.js apps, start with database sessions — the caching pattern above keeps the performance cost near zero, and you'll be glad revocation is a solved problem the first time you actually need it. Reach for JWTs specifically when you've measured that the database hit matters, not because a tutorial defaulted to it.

From here, a natural next step is wiring either pattern into a real login form with Zod validating the credentials before they ever reach your session logic, or layering role-based permissions on top of whichever session strategy you pick.

Continue Learning

Useful Resources

Supabase Auth vs Firebase Auth: Which One Should You Choose in 2026?

Thu, 20 Aug 2026 10:26:22 +0000

You're starting a new Next.js project, and before you write a single feature, you have to answer one boring but critical question: who's going to handle login?

Two names keep showing up at the top of every list — Supabase Auth and Firebase Auth. Both are free to start, both support Google/GitHub/email login, and both promise to save you from writing your own password-hashing logic. But they're built on completely different foundations, and picking the wrong one can mean months of awkward workarounds later — like discovering you need SQL joins for a permissions system, but you're stuck with Firestore's document model.

This guide breaks down exactly how Supabase Auth and Firebase Auth differ in 2026 — architecture, pricing, security, and real Next.js 16 App Router code for both — so you can pick the right one before you've built half your app on top of it.

Why This Comparison Is Tricky

Most "Supabase vs Firebase" posts compare marketing pages, not real implementation experience. The truth is these two products solve authentication very differently under the hood:

Supabase Auth is a layer on top of PostgreSQL — every user lives in a real SQL table (auth.users), and permissions are enforced with Row Level Security (RLS) policies written in SQL.
Firebase Auth is a layer on top of Firestore/Google Cloud — users live in Google's own auth system, and permissions are enforced with Firestore Security Rules, a completely different (non-SQL) rules language.

That single architectural difference is what actually decides which one fits your project — not the login form UI, which looks nearly identical on both.

Quick Answer

Choose Supabase Auth if you want a real Postgres database, SQL-based permissions (RLS), open-source flexibility, and the option to self-host later.
Choose Firebase Auth if you're already invested in Firebase or Google Cloud services, or if Firebase's managed identity infrastructure fits your application's architecture.

Now let's get into the details.

Supabase Auth vs Firebase Auth: Which Is Better for Next.js?

If you're building a Next.js SaaS application with PostgreSQL, Supabase Auth is usually the more natural choice because authentication, database access, and authorization can be designed around the same Postgres/RLS model.

Firebase Auth is a better fit when your application already uses Firebase/Google Cloud services or your data model naturally fits Firestore.

Supabase Auth vs Firebase Auth: Feature Comparison

Feature	Supabase Auth	Firebase Auth
Authentication architecture	Integrated with Supabase/PostgreSQL ecosystem	Managed identity service
Common database pairing	PostgreSQL	Firestore (NoSQL)
Free/no-cost auth tier	50,000 monthly active users (MAU)	Depends on Firebase Auth / Identity Platform configuration
Paid pricing	Included in Supabase plan quota; $0.00325/MAU over Pro quota	Identity Platform: 50,000 MAU no-cost tier on Blaze, then usage-based pricing
Email/password	✅	✅
Magic links	✅	✅ (email link sign-in)
Social OAuth (Google, GitHub, etc.)	✅	✅
Phone/SMS OTP	✅	✅
Permissions model	Row Level Security (SQL policies)	Firestore Security Rules (custom rules language)
Self-hosting	✅ Yes (fully open source)	❌ No
Open source	✅ Yes	❌ No
Next.js SSR package	`@supabase/ssr`	Firebase JS SDK + `initializeServerApp`
Best paired with	Postgres-based SaaS apps	Google Cloud / Firestore apps

💡 Tip: Both platforms' free tiers are generous enough to cover most side projects and early-stage SaaS apps completely — pricing usually isn't the deciding factor until you're well past MVP stage.

Architecture: The Real Difference

This is the part most comparison articles skip, and it's the one that actually matters.

Supabase Auth Runs on Postgres

When someone signs up with Supabase Auth, a row gets created in a special auth.users table inside your actual Postgres database. Every other table you create — profiles, posts, orders — can have a foreign key pointing straight at auth.users.id.

That means your permissions logic is just SQL:

-- Only let a user see their own orders
create policy "Users can view own orders"
on orders
for select
using (auth.uid() = user_id);

Why this matters: if your app has relational data — a user has many orders, an order has many line items, a team has many members — Postgres joins handle that naturally. You're not fighting the database to model relationships.

Firebase Auth And Firestore

Firebase Auth manages identity separately from your application data. When paired with Firestore, authorization is commonly enforced using Firestore Security Rules — a rules language, not SQL:

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /orders/{orderId} {
      allow read: if request.auth != null && request.auth.uid == resource.data.userId;
    }
  }
}

Why this matters: Firestore is a document database. There's no native JOIN. If your data is deeply relational (think: multi-tenant SaaS with teams, roles, and shared resources), you'll end up duplicating data across documents or running multiple round-trip queries to stitch things together client-side.

💡 Tip: Neither model is "wrong" — Firestore's document model is genuinely great for chat apps, real-time feeds, and simple per-user data. Postgres shines once your data has real relationships between tables.

Setting Up Supabase Auth in Next.js 16

This guide assumes Next.js 16 with the App Router, TypeScript in strict mode, and Tailwind CSS — the current defaults for any new Next.js project.

Step 1: Install Dependencies

npm install @supabase/supabase-js @supabase/ssr

What's happening here: @supabase/supabase-js is the core client library. @supabase/ssr is the package built specifically for frameworks like Next.js — it handles the tricky part of syncing auth cookies between the browser and the server so your session works correctly in Server Components, Server Actions, and the browser alike.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_SUPABASE_URL=https://yourproject.supabase.co
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=your_publishable_key

⚠️ Never expose a Supabase secret key (sb_secret_...) or legacy service_role key in client-side code. Both bypass RLS.

💡 Tip: For new Supabase projects, use the publishable key rather than the legacy anon key. Supabase is transitioning away from the legacy API keys during 2026.

Step 3: Create the Browser Client

// lib/supabase/client.ts
import { createBrowserClient } from "@supabase/ssr";

export function createClient() {
  return createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );
}

Use this inside Client Components — anywhere you need "use client".

Step 4: Create the Server Client

// lib/supabase/server.ts
import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },
        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Safe to ignore when called from a Server Component
          }
        },
      },
    }
  );
}

What's happening here: this client reads and writes auth cookies through Next.js's cookies() API, so a session created during login is visible to Server Components and Server Actions immediately — no manual token passing needed.

Step 5: Add the Auth Proxy (Middleware)

// utils/supabase/proxy.ts
import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({ request });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },
        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );
          supabaseResponse = NextResponse.next({ request });
          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );
          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

// proxy.ts (root of project)
import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

⚠️ Common Mistake: Skipping this proxy file. Without it, Supabase's refresh token doesn't get renewed on every request, and users get randomly logged out mid-session — one of the most common Supabase Auth bugs beginners hit.

// actions/auth.ts
"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/lib/supabase/server";

export async function login(prev: unknown, formData: FormData) {
  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword({
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  });

  if (error) {
    return { error: error.message };
  }

  redirect("/dashboard");
}

Step 7: Protect Data with Row Level Security

This is Supabase Auth's biggest advantage — security lives at the database level, not just in your app code:

alter table profiles enable row level security;

create policy "Users can view own profile"
on profiles for select
using ((select auth.uid()) = id);

create policy "Users can update own profile"
on profiles for update
using ((select auth.uid()) = id)
with check ((select auth.uid()) = id);

Why this matters: even if someone bypasses your Next.js app entirely and hits the Supabase API directly, RLS still blocks them from seeing data that isn't theirs. Your frontend code stops being the only line of defense.

💡 If you're using Supabase Auth with multiple tables, writing RLS policies manually can become repetitive. DevStacked's Supabase RLS Policy Generator can generate strict policies based on your access pattern.

Setting Up Firebase Auth in Next.js 16

Step 1: Install Dependencies

npm install firebase firebase-admin

What's happening here: firebase is the client SDK (runs in the browser and in Server Components via Firebase's newer server app support). firebase-admin is for privileged, server-only operations like verifying tokens.

Step 2: Add Environment Variables

# .env.local
NEXT_PUBLIC_FIREBASE_API_KEY=your_api_key
NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN=yourproject.firebaseapp.com
NEXT_PUBLIC_FIREBASE_PROJECT_ID=yourproject

Step 3: Initialize Firebase (Client Side)

// lib/firebase/client.ts
import { initializeApp, getApps, getApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const firebaseConfig = {
  apiKey: process.env.NEXT_PUBLIC_FIREBASE_API_KEY,
  authDomain: process.env.NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN,
  projectId: process.env.NEXT_PUBLIC_FIREBASE_PROJECT_ID,
};

const app = getApps().length ? getApp() : initializeApp(firebaseConfig);

export const auth = getAuth(app);

What's happening here: getApps().length ? getApp() : initializeApp(...) prevents Firebase from being re-initialized on every hot reload in development — a classic Firebase + Next.js gotcha if you skip this check.

// components/login-form.tsx
"use client";

import { signInWithEmailAndPassword } from "firebase/auth";
import { auth } from "@/lib/firebase/client";
import { useRouter } from "next/navigation";
import { useState } from "react";

export function LoginForm() {
  const router = useRouter();
  const [error, setError] = useState("");

  const handleSubmit = async (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    const form = new FormData(e.currentTarget);

    try {
      await signInWithEmailAndPassword(
        auth,
        form.get("email") as string,
        form.get("password") as string
      );
      router.push("/dashboard");
    } catch (err) {
      setError(err instanceof Error ? err.message : "Login failed");
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="email" type="email" required />
      <input name="password" type="password" required />
      <button type="submit">Sign in</button>
      {error && <p>{error}</p>}
    </form>
  );
}

⚠️ Common Mistake: Doing all your auth logic client-side and assuming that's enough for SSR. Firebase's client SDK doesn't automatically make the logged-in user visible to your Next.js Server Components — you need a separate step to bridge that gap (next).

Step 5: Bridge the Session to the Server

Firebase's newer Firebase Server App feature lets you read the authenticated user inside Server Components:

// lib/firebase/server.ts
import { cookies } from "next/headers";
import { initializeApp, initializeServerApp } from "firebase/app";
import { getAuth } from "firebase/auth";

export async function getAuthenticatedAppForUser() {
  const authIdToken = (await cookies()).get("__session")?.value;

  const firebaseServerApp = initializeServerApp(initializeApp(), {
    authIdToken,
  });

  const auth = getAuth(firebaseServerApp);
  await auth.authStateReady();

  return { firebaseServerApp, currentUser: auth.currentUser };
}

Learn more Firebase Server App here

What's happening here: the client sets a __session cookie containing the Firebase ID token after login (you write this cookie yourself, typically via a small API route or onIdTokenChanged listener). The server then rebuilds an authenticated Firebase app instance from that cookie — this is meaningfully more manual than Supabase's @supabase/ssr package, which handles cookie syncing for you out of the box.

Note: This example demonstrates the server-side bridge rather than a complete production session-cookie implementation. In production, use a secure HTTP-only session cookie and validate it server-side.

⚠️ Common Mistake: Assuming Firebase Auth "just works" with Server Components the way it works with a client-only SPA. The App Router's server/client split means you need this extra bridging step — it's the single biggest source of Firebase + Next.js App Router complaints online.

Step 6: Protect Data with Firestore Security Rules

// firestore.rules
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /profiles/{userId} {
      allow read, update: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Firestore rules are enforced server-side by Google's infrastructure, similar in spirit to RLS — but written in a proprietary rules language instead of SQL, so there's a real learning curve if your team already knows SQL but not Firestore's rule syntax.

Pricing Comparison

	Supabase Auth	Firebase Auth
Free tier	50,000 MAU	Depends on Firebase Auth / Identity Platform configuration
Paid tier	Included in Supabase plan quota; additional MAU billed after quota	Usage-based pricing with Identity Platform
Self-hosting	✅ Available	❌ Not available

Both platforms offer generous options for early-stage projects, although the exact limits and pricing depend on the plan and services you use. The real cost difference shows up later: Supabase gives you a self-hosting escape hatch if you ever want to leave the MAU pricing model entirely; Firebase does not.

Security Considerations for Both

Regardless of which you choose, keep these in mind for Next.js 16:

Never trust client-side auth checks alone. Whether you're using Supabase or Firebase, always re-verify the session inside Server Actions and Route Handlers — a hidden button in the UI doesn't stop a direct API call.
proxy.ts (formerly middleware.ts) is a UX nicety, not your security boundary. Both Supabase's session refresh and any Firebase token check you add there can be bypassed by calling your backend directly — the real gate is the check inside your Server Action or database rule.
Default new users to the lowest-privilege role. Never let a signup form set its own role or is_admin field — assign it server-side.

When Should You Use Supabase Auth?

You want a real relational database (Postgres) under your app, not just auth.
Your app has complex relationships — teams, roles, shared resources, multi-tenancy.
You want the option to self-host later, or you like knowing you could.
You're already comfortable with SQL, or want to learn it.

When Should You Use Firebase Auth?

You're already using Firestore, Cloud Functions, Firebase Cloud Messaging, or Google Analytics.
Your data model is simple and document-shaped (a user has a profile, a handful of settings — no deep relational joins).
You want Google's massive scale and long production track record specifically for mobile + web apps together.
Your team already knows Firestore Security Rules.

Decision Table

If you need...	Better choice
Next.js + PostgreSQL	🟢 Supabase
SQL + relational data	🟢 Supabase
RLS-based authorization	🟢 Supabase
Self-hosting	🟢 Supabase
Firestore	🟢 Firebase
Firebase ecosystem	🟢 Firebase
Google Cloud integration	🟢 Firebase
Mobile + web Firebase stack	🟢 Firebase
Complex relational SaaS	🟢 Supabase
Document-oriented data	🟢 Firebase

Frequently Asked Questions

Can I switch from Firebase Auth to Supabase Auth later?

Yes, but it's real migration work. You'll need to migrate users and identities, account for password-hash compatibility and provider configuration, and rebuild authorization rules from your Firebase/Security Rules model into Supabase RLS.

Which one is easier for a complete beginner?

Firebase Auth's client-only setup (no SSR bridging) is slightly faster to get a basic login working. But Supabase Auth's @supabase/ssr package makes Next.js App Router integration smoother once you add server-side checks, which almost every real app eventually needs.

Yes — Supabase Auth supports Google, GitHub, Apple, Discord, and dozens of other OAuth providers, configured directly from the Supabase dashboard with no extra backend code required.

Is Firebase Auth open source?

No. Firebase Auth is a fully managed Google Cloud service — you can't self-host it or inspect its internals. Supabase Auth (part of the broader Supabase platform, built on the open-source GoTrue project) is open source and can be self-hosted.

Do I need Row Level Security if I'm already checking auth in my Next.js code?

RLS protects your database from application-level mistakes and direct client access, but it does not protect against misuse of a secret/service-role key because those elevated keys bypass RLS.

Wrapping Up

Supabase Auth and Firebase Auth both get you a working login system fast — the real decision comes down to what's underneath: a relational Postgres database with SQL-based security, or Firestore's document model with Google's rules language. If your app has real relationships between users, teams, and data, Supabase's Postgres foundation will save you pain down the road. If you're already deep in the Google Cloud ecosystem, Firebase Auth keeps everything under one roof.

Whichever you pick, remember the same rule applies to both: UI checks are for user experience, and server-side/database-level checks are your actual security boundary.

Continue Learning

Helpful Free Tools

Supabase RLS Policy Generator — generate strict, pattern-specific Row Level Security policies in seconds instead of hand-writing SQL.
Zod Schema Generator — generate validated schemas for your auth forms straight from JSON or TypeScript, including a ready-to-use Server Action.

Role-Based Access Control (RBAC) in Next.js 16 (2026 Beginner's Guide)

Tue, 18 Aug 2026 03:49:46 +0000

Logging a user in is the easy part. The hard part shows up right after — when your "admin" and your "customer" both hit /dashboard and somehow need to see completely different things. Or worse, when a regular user figures out they can just type /admin into the URL bar and… get in, because nothing was actually checking who they were.

That's the gap role-based authorization (RBAC — Role-Based Access Control) fills. It's not about whether someone is logged in anymore — it's about what they're allowed to do once they are. An admin can delete users. An editor can publish posts. A viewer can only look. Same login system, three completely different sets of permissions.

In this guide, you'll build a complete role-based authorization system in Next.js 16 — from storing roles, to protecting routes with proxy.ts, to locking down Server Actions and API routes so a sneaky curl request can't bypass your UI checks. By the end, you'll have a reusable pattern you can drop into any SaaS, dashboard, or internal tool.

Why This Is Tricky

Authentication just answers "who are you?" Authorization answers "what are you allowed to do?" — and that second question has to be checked in every place data or actions are exposed, not just once at the login screen.

The mistake almost everyone makes early on is checking roles only in the UI — hiding an "Edit" button if role !== "admin". That stops confused users, but it does nothing to stop a determined one, since a hidden button doesn't stop someone from calling the underlying Server Action or API route directly. Real role-based auth needs checks in at least three layers:

Route level — don't even let the page load for the wrong role
UI level — hide actions the user can't perform (good UX, not security)
Server level — re-verify inside every Server Action, Route Handler, and database query (the actual security boundary)

We'll build all three.

What We're Building

A small app with three roles:

admin — full access, can manage users
editor — can create and edit posts
viewer — read-only access

You'll end up with:

A typed Role system shared across the whole app
Role storage using Auth.js v5's JWT session (works the same pattern with a database session)
Route protection in proxy.ts based on role, not just login state
A reusable requirePermission() helper for Server Actions and Route Handlers
A <Can> component for conditionally showing UI based on permissions

                 ┌──────────────┐
                 │    Role      │
                 │ admin/editor │
                 │    viewer    │
                 └──────┬───────┘
                        ↓
                 ┌──────────────┐
                 │ Permissions  │
                 └──────┬───────┘
                        ↓
              ┌─────────┴─────────┐
              ↓                   ↓
      requirePermission()       <Can>
              ↓                   ↓
       Security boundary      UI visibility

Tech Stack

This guide uses:

Next.js 16 with the App Router
TypeScript in strict mode
Tailwind CSS for the small UI examples
Auth.js v5 (next-auth@beta) for authentication — the same library covered in Clerk vs NextAuth (Auth.js) in 2026

💡 Tip: Don't have Auth.js set up yet? Read How to Add Auth.js (NextAuth v5) Authentication in Next.js 16 first — this guide picks up right where that one leaves off. If you're using Clerk instead, skip to the Clerk section near the end — the concepts are identical, just the plumbing changes.

Step 1: Define Your Roles in One Place

Before writing any auth code, decide what roles exist and what each one can actually do. Hardcoding role strings ("admin", "editor"...) all over your codebase is exactly how typos slip in and silently break a permission check.

// lib/auth/roles.ts
export const ROLES = ["admin", "editor", "viewer"] as const;

export type Role = (typeof ROLES)[number];

// What each role is allowed to do — the single source of truth
export const PERMISSIONS = {
  admin: ["manage_users", "create_post", "edit_post", "delete_post", "view_post"],
  editor: ["create_post", "edit_post", "view_post"],
  viewer: ["view_post"],
} as const satisfies Record<Role, readonly string[]>;

export type Permission = (typeof PERMISSIONS)[Role][number];

export function hasPermission(role: Role, permission: Permission): boolean {
  return (PERMISSIONS[role] as readonly string[]).includes(permission);
}

What's happening here: ROLES is a fixed list — TypeScript's as const makes Role a union type ("admin" | "editor" | "viewer") instead of a loose string, so a typo like "admn" fails to compile instead of silently failing at runtime. PERMISSIONS maps each role to what it's allowed to do, and hasPermission() is the one function every check in this guide will eventually call.

💡 Tip: Notice we're checking permissions ("create_post"), not roles ("editor"), everywhere except this one file. If you ever add a new role or change what editors can do, you update this file once — nothing else in your app needs to change.

Step 2: Store the Role on the User

Your role has to live somewhere Auth.js can read it during login. In a real app, this is a role column on your users table. For this guide, here's the shape assuming you're using a database adapter (Prisma, Drizzle, or similar):

-- Minimal schema addition
alter table users
add column role text not null default 'viewer'
check (role in ('admin', 'editor', 'viewer'));

New users default to the lowest-privilege role — viewer — which is a good default for any RBAC system. Never default a new signup to admin.

TypeScript protects application code at compile time; the database constraint protects persisted data at runtime.

⚠️ Common Mistake: Letting the client send its own role during signup (formData.get("role")). Always assign the default role server-side and require an existing admin to promote anyone — otherwise anyone can sign up and just declare themselves an admin.

Step 3: Put the Role on the Session

This is the step most tutorials skip, and it's the one that actually makes RBAC work. By default, Auth.js's session only contains the basics (name, email, image) — you have to explicitly add role to it using two callbacks: jwt and session.

// lib/auth.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";
import type { Role } from "./auth/roles";

declare module "next-auth" {
  interface User {
    id: string;
    role: Role;
  }
  interface Session {
    user: {
      id: string;
      role: Role;
    } & DefaultSession["user"];
  }
}

declare module "@auth/core/jwt" {
  interface JWT {
    role: Role;
    id: string;
  }
}

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [GitHub],
  callbacks: {
    async jwt({ token, user }) {
      // Runs on sign-in, and on every subsequent request
      if (user) {
        // `user` is only defined right after login — look up the role from your DB here
        token.id = user.id!;
        token.role = user.role ?? "viewer";
      }
      return token;
    },
    async session({ session, token }) {
      // Copies data from the JWT token into the session object your app actually reads
      session.user.id = token.id;
      session.user.role = token.role;
      return session;
    },
  },
});

What's happening here: jwt() can run whenever the JWT session is created or updated, but the user object is available during the initial sign-in flow. That's where you copy the user's role into token.role. On later requests, the role is read from the token rather than fetched again. session() then runs on every auth() call and copies fields from that token onto the session object your pages and Server Actions actually read. The declare module blocks aren't runtime code — they extend Auth.js's built-in TypeScript types so session.user.role autocompletes instead of throwing a type error.

⚠️ Common Mistake: Trying to read the role directly off session.user without adding it in these two callbacks first. Auth.js won't magically know about a custom role column — you have to wire it through jwt() → session() explicitly, every time.

💡 Tip: If a user's role changes (e.g. an admin promotes them), the JWT won't reflect that until they log in again, since jwt() only re-reads user on fresh sign-in. For roles that need to update instantly, either switch to database sessions (strategy: "database") or add a trigger === "update" branch that re-fetches the role on demand.

Step 4: Protect Routes by Role in `proxy.ts`

In Next.js 16, middleware.ts was renamed to proxy.ts — same file conventions, same idea: it runs before a request reaches a page, making it useful for a fast, optimistic route-level redirect before the page renders.

// proxy.ts
import { NextResponse } from "next/server";
import { auth } from "@/lib/auth";
import type { Role } from "@/lib/auth/roles";

// Map route prefixes to the roles allowed to access them
const ROUTE_ROLES: { prefix: string; roles: Role[] }[] = [
  { prefix: "/admin", roles: ["admin"] },
  { prefix: "/editor", roles: ["admin", "editor"] },
  { prefix: "/dashboard", roles: ["admin", "editor", "viewer"] },
];

export default auth((req) => {
  const { nextUrl } = req;
  const role = req.auth?.user?.role;

  const matched = ROUTE_ROLES.find((r) => nextUrl.pathname === r.prefix || nextUrl.pathname.startsWith(`${r.prefix}/`));
  const isAuthPage = nextUrl.pathname === "/login";
  const isLoggedIn = !!req.auth;

  if (isAuthPage && isLoggedIn) {
      // Redirect authenticated users to the dashboard
      return NextResponse.redirect(new URL("/dashboard", nextUrl))
  }

  if (!matched) {
    return NextResponse.next(); // route isn't role-protected, let it through
  }

  if (!isLoggedIn) {
    // Not logged in at all — send to login
    return NextResponse.redirect(new URL("/login", nextUrl));
  }

  if (!role || !matched.roles.includes(role)) {
    // Logged in, but wrong role — send to a friendly "not allowed" page, not login
    return NextResponse.redirect(new URL("/unauthorized", nextUrl));
  }

  return NextResponse.next();
});

export const config = {
  matcher: ["/((?!api|_next/static|_next/image|favicon.ico).*)"],
};

What's happening here: ROUTE_ROLES is a lookup table — no scattered if statements per route, just prefixes mapped to the roles allowed in. The proxy checks the incoming path against that table, and only bothers checking req.auth at all if the route is actually protected. Notice the two different redirects: no session → /login (they need to authenticate), wrong role → /unauthorized (they're authenticated, just not allowed here) — conflating these two cases is a common source of confusing UX.

⚠️ Common Mistake: Forgetting the matcher config, or matching too broadly. Running the proxy on every static asset request adds unnecessary overhead and can cause odd caching behavior — always exclude _next/static, _next/image, and favicon paths.

Step 5: Build a `requirePermission()` Helper for the Real Security Boundary

proxy.ts stops the page from loading, but it does not protect Server Actions or Route Handlers called directly — those need their own check. This is the layer that actually matters for security, since proxy.ts is a UX nicety, not a guarantee.

// lib/auth/require-role.ts
import { auth } from "@/lib/auth";
import type { Permission } from "./roles";
import { hasPermission } from "./roles";

export class UnauthorizedError extends Error {}
export class ForbiddenError extends Error {}

export async function requirePermission(permission: Permission) {
  const session = await auth();

  if (!session?.user) {
    throw new UnauthorizedError("You must be signed in.");
  }

  if (!hasPermission(session.user.role, permission)) {
    throw new ForbiddenError("You don't have permission to do that.");
  }

  return session.user; // callers get a typed, guaranteed-authorized user back
}

What's happening here: requirePermission() checks permissions ("delete_post"), not roles directly — this keeps every call site decoupled from which roles can do what, so changing that mapping later only touches roles.ts. Two distinct errors (Unauthorized vs Forbidden) let callers respond differently — a 401 (not logged in) is a different problem than a 403 (logged in, not allowed).

Using It in a Server Action

// actions/posts.ts
"use server";

import { requirePermission, ForbiddenError, UnauthorizedError } from "@/lib/auth/require-role";
import { revalidatePath } from "next/cache";

export async function deletePost(postId: string) {
  try {
    await requirePermission("delete_post");
  } catch (err) {
    if (err instanceof UnauthorizedError) return { error: "Please sign in." };
    if (err instanceof ForbiddenError) return { error: "You can't delete posts." };
    throw err;
  }

  // await db.post.delete({ where: { id: postId } });
  revalidatePath("/dashboard");
  return { success: true };
}

⚠️ Common Mistake: Only checking permissions in proxy.ts and assuming Server Actions are automatically covered. They aren't — a Server Action is a real network endpoint under the hood, callable directly, and needs its own requirePermission() call every single time it touches something sensitive.

Using It in a Route Handler

// app/api/users/[id]/route.ts
import { NextResponse } from "next/server";
import { requirePermission, ForbiddenError, UnauthorizedError } from "@/lib/auth/require-role";

export async function DELETE(req: Request, { params }: { params: Promise<{ id: string }> }) {
  try {
    await requirePermission("manage_users");
  } catch (err) {
    if (err instanceof UnauthorizedError) {
      return NextResponse.json({ error: "Unauthorized" }, { status: 401 });
    }
    if (err instanceof ForbiddenError) {
      return NextResponse.json({ error: "Forbidden" }, { status: 403 });
    }
    throw err;
  }

  const { id } = await params;
  // await db.user.delete({ where: { id } });
  return NextResponse.json({ success: true });
}

Same pattern, correct HTTP status codes this time — 401 for "log in first," 403 for "you're logged in, but no."

Step 6: Conditionally Show UI with a `<Can>` Component

Server-side checks are the real security boundary, but users still need a UI that doesn't dangle buttons they can't actually use. A small <Can> component keeps this readable instead of {role === "admin" && ...} scattered through every page.

// components/can.tsx
import type { Permission } from "@/lib/auth/roles";
import { hasPermission } from "@/lib/auth/roles";
import { auth } from "@/lib/auth";

interface CanProps {
  permission: Permission;
  children: React.ReactNode;
  fallback?: React.ReactNode;
}

export async function Can({ permission, children, fallback = null }: CanProps) {
  const session = await auth();

  if (!session?.user || !hasPermission(session.user.role, permission)) {
    return <>{fallback}</>;
  }

  return <>{children}</>;
}

// app/dashboard/page.tsx
import { Can } from "@/components/can";
import Link from 'next/link';

export default function DashboardPage() {
  return (
    <div className="space-y-4">
      <h1 className="text-2xl font-semibold">Dashboard</h1>

      <Can permission="create_post">
        <button className="rounded-lg bg-primary px-4 py-2 text-white">
          New Post
        </button>
      </Can>

      <Can permission="manage_users" fallback={<p className="text-sm text-muted-foreground">Admins only.</p>}>
        <Link href="/admin/users" className="underline">Manage Users</Link>
      </Can>
    </div>
  );
}

What's happening here: Can is an async Server Component — it calls auth() directly, no client-side loading flicker, no useEffect. Wrap anything role-gated in it, optionally supply a fallback for what non-permitted users see instead (or leave it out to render nothing at all).

💡 Tip: Because Can reads the current session on the server, use it in parts of the tree where request-time authentication data is expected.

💡 Tip: This component controls visibility, not security. Someone could still call the underlying Server Action with dev tools open — that's exactly why Step 5's requirePermission() exists as the real gate. <Can> is UX, requirePermission() is the lock.

Step 7: Filter Data at the Query Level Too

There's a fourth layer worth calling out separately: what data a query even returns. A viewer shouldn't just be blocked from an edit button — if your query returns draft posts by default, make sure a viewer's query never fetches drafts in the first place, rather than fetching everything and hiding it in the UI.

// lib/data/posts.ts
import { auth } from "@/lib/auth";
import { UnauthorizedError } from "../auth/require-role";

export async function getVisiblePosts() {
  const session = await auth();
  const role = session?.user?.role;

  if (!session?.user) {
    throw new UnauthorizedError("You must be signed in.");
  }

  if (role === "admin" || role === "editor") {
    // return await db.post.findMany(); // everything, including drafts
  }

  // return await db.post.findMany({ where: { status: "published" } }); // viewers only see published
}

This matters because a UI-only check can miss cases like server-rendered pages, RSS feeds, or an API response that isn't wired through the component you added <Can> to.

Frequently Asked Questions

What's the difference between authentication and authorization?

Authentication confirms who someone is (logging in). Authorization decides what they're allowed to do once they're recognized (roles and permissions). You need both — Auth.js/Clerk handle authentication, and everything in this guide is the authorization layer on top.

Should I store roles as a string or a separate roles table?

A single role string column (like this guide uses) is fine for simple apps with a handful of fixed roles. If you need multiple roles per user, per-organization roles, or roles that admins can create dynamically, move to a proper roles and user_roles join table instead — the hasPermission() pattern still works the same way on top of either.

Is checking roles in `proxy.ts` enough security by itself?

No. Treat proxy.ts as a fast UX redirect, not your security boundary — it can be bypassed by hitting a Server Action or API route directly. Always re-check permissions inside the Server Action or Route Handler itself, as shown in Step 5.

How do I handle a role change without forcing the user to log out?

With JWT sessions, the user value isn't available on every JWT callback invocation, so simply changing the role in your database doesn't automatically replace the role already stored in an existing token. Either switch to strategy: "database" sessions (Auth.js re-reads the DB on every request), or add an update() trigger that refreshes the token when an admin changes someone's role.

Can I have more granular permissions than just three roles?

Yes — that's exactly why Step 1 separates PERMISSIONS from ROLES. Add a new permission string to whichever roles should have it, and every requirePermission() call automatically respects the new mapping without touching the rest of your codebase.

Doing This with Clerk Instead

If you're using Clerk instead of Auth.js, the RBAC architecture stays the same. Only the way you retrieve the user's role changes.

For a simple app, store the role in Clerk's publicMetadata:

{
  role: "editor"
}

Set it server-side or through the Clerk Dashboard. Never let users submit their own role during signup.

Expose the metadata through the Clerk session token. In Clerk Dashboard → Sessions → Customize session token, add:

{
  "metadata": "{{user.public_metadata}}"
}

Then read the role with auth():

import { auth } from "@clerk/nextjs/server";
import type { Role } from "@/lib/auth/roles";

const { isAuthenticated, sessionClaims } = await auth();

if (!isAuthenticated) {
  // Not signed in
}

const role = sessionClaims?.metadata?.role as Role | undefined;

From here, the same hasPermission(), requirePermission(), and <Can> pattern from this guide still applies. Your authorization layer doesn't need to care whether the role came from Auth.js or Clerk.

Role changes may take a short time to appear in an existing session token, so don't assume a metadata update is immediately reflected in sessionClaims.

💡 Tip: If you're building a multi-tenant SaaS with teams or organizations, consider Clerk's built-in Organizations, Roles, and Permissions instead of storing organization roles in publicMetadata. (Clerk Roles & Permissions)

The important rule remains the same: UI checks improve UX; server-side permission checks provide security.

Wrapping Up

Role-based authorization isn't one big feature — it's four small, boring checks layered together: a protected route in proxy.ts, a re-check inside every Server Action and Route Handler, a <Can> wrapper for the UI, and a query that filters data before it ever leaves the server. Skip any one layer and you've got a gap; stack all four and a "hidden" admin button stops being a real vulnerability.

From here, a natural next step is adding an admin UI for promoting/demoting users, or layering row-level security on top if you're using Supabase alongside this pattern for defense in depth at the database layer too.

📦 Source Code: View on GitHub

Continue Learning

Free Developer Tools

Supabase RLS Policy Generator — pair this guide's application-level RBAC with database-level Row Level Security. Generates owner-only, team, and admin-override policies with the auth.uid() performance wrapper built in.
Zod Schema Generator — generate a validated schema for your role/permission payloads straight from a JSON sample or TypeScript interface, including a ready-to-use Server Action.

How to Add Auth.js (NextAuth v5) Authentication in Next.js 16 (2026)

Tue, 04 Aug 2026 04:46:25 +0000

Every real app eventually needs to answer one question: who is this user? The moment you add a dashboard, a settings page, or anything that shouldn't be public, you need authentication — and rolling your own login system from scratch (password hashing, sessions, CSRF protection, OAuth flows) is a rabbit hole most developers don't have time for.

That's exactly what Auth.js (the project formerly known as NextAuth) solves. It's free, open source, and gives you production-ready authentication — email/password, GitHub, Google, and dozens of other providers — without owning any of that security-critical code yourself.

In this guide, you'll set up Auth.js v5 in a Next.js 16 App Router project from scratch: installing it, configuring a provider, protecting routes with proxy.ts, and reading the logged-in user inside Server Components. By the end, you'll have a working "Sign in with GitHub" flow you can extend to any provider you want.

What you'll learn

By the end of this guide you'll know how to:

✓ Install Auth.js v5
✓ Configure GitHub OAuth
✓ Protect routes
✓ Read sessions
✓ Use auth() inside Server Components
✓ Secure Server Actions

What Is Auth.js, Exactly?

Auth.js is an authentication library built specifically for full-stack JavaScript frameworks. If you've read older tutorials, you've probably seen it called NextAuth — that's the same project. It was renamed to Auth.js when the team expanded support beyond Next.js to other frameworks like SvelteKit and Express, while the npm package name stayed next-auth for backwards compatibility.

Think of Auth.js as a middleman between your app and the identity providers (GitHub, Google, your own database, etc.). Instead of you writing the OAuth handshake, generating secure session cookies, and validating tokens by hand, Auth.js handles all of it — you just tell it which providers to use.

💡 Tip: If you've seen getServerSession() in an older tutorial, that's the Auth.js v4 API. In v5 (what this guide uses), everything is exported from a single auth() function instead — much simpler.

What We're Building

By the end of this guide, you'll have:

Auth.js v5 installed and configured in a Next.js 16 App Router app
A working GitHub OAuth sign-in flow (the pattern is the same for Google, Discord, etc.)
A proxy.ts file that protects private routes automatically
A Navbar that shows "Sign in" or the user's avatar depending on auth state
Access to the logged-in user inside Server Components using auth()

Prerequisites

Before we start, make sure you have:

Next.js 16 with the App Router
TypeScript (strict mode)
Tailwind CSS for styling
Basic familiarity with React and the App Router

If your project doesn't have these yet, scaffold one first:

npx create-next-app@latest my-app

For this guide, we're using the src/ directory layout (choose Yes when the CLI asks). Everything works the same without it — just drop the src/ prefix from the file paths below.

Folder Structure

src/
├── app/
│   └── api/
│       └── auth/
│           └── [...nextauth]/
│               └── route.ts
├── actions/
│   └── create-post.ts
├── components/
│   └── auth-buttons.tsx
├── lib/
│   └── auth.ts
├── proxy.ts
.env.local

How does Auth.js work?

User clicks "Sign in"
        ↓
Redirect to GitHub
        ↓
User approves
        ↓
GitHub redirects back
        ↓
Auth.js validates
        ↓
Session cookie created
        ↓
auth() can now read the user

Step 1: Install Auth.js

Auth.js v5 is still installed under its old package name, next-auth, using the beta tag:

npm install next-auth@beta

⚠️ Common Mistake: Installing next-auth without @beta gives you the old v4 API, which uses a completely different setup ([...nextauth].ts pages, authOptions, getServerSession()). This guide is written entirely for v5.

Step 2: Create a GitHub OAuth App

We're using GitHub as our sign-in provider in this guide. In one sentence: OAuth lets users sign in using an existing account (like GitHub or Google) without ever sharing their password with your application. Instead, GitHub itself confirms the user's identity and hands your app a token proving it — your app never sees or stores their GitHub password.

Since we're using GitHub, GitHub needs to know about your app before it'll let anyone sign in with it.

Go to github.com/settings/developers
Click New OAuth App
Fill in:
- Application name: anything, e.g. My App (Dev)
- Homepage URL: http://localhost:3000
- Authorization callback URL: http://localhost:3000/api/auth/callback/github
Click Register application
Copy the Client ID, then generate and copy a Client Secret

💡 Tip: The callback URL pattern /api/auth/callback/<provider> is fixed by Auth.js — don't change it, or GitHub won't be able to redirect back to your app correctly.

Step 3: Add Environment Variables

Create a .env.local file in your project root:

# .env.local
AUTH_SECRET=replace-this-with-a-random-string
AUTH_GITHUB_ID=your_github_client_id
AUTH_GITHUB_SECRET=your_github_client_secret

AUTH_SECRET is used to sign and encrypt session tokens — it must stay private. Generate a strong random value with:

npx auth secret

This command (from the auth CLI that ships with next-auth) automatically writes a secure AUTH_SECRET into your .env.local file for you.

⚠️ Common Mistake: Forgetting to add .env.local to .gitignore. If AUTH_SECRET or your OAuth secret leaks into a public repo, attackers can forge valid sessions for your app.

Step 4: Configure Auth.js

This is the heart of the setup. Create an auth.ts file inside src/lib/:

// src/lib/auth.ts
import NextAuth from "next-auth";
import GitHub from "next-auth/providers/github";

export const { handlers, signIn, signOut, auth } = NextAuth({
  providers: [GitHub],
});

What's happening here?

NextAuth(...) takes a config object and returns everything you need: handlers (for the API route), signIn/signOut (Server Actions you can call from forms or buttons), and auth() (a function to read the current session anywhere on the server).
providers: [GitHub] tells Auth.js to use GitHub OAuth. Since our environment variables follow the AUTH_GITHUB_ID / AUTH_GITHUB_SECRET naming convention, Auth.js picks them up automatically — no need to pass them manually.

💡 Tip: Want to add Google too? Just import Google from next-auth/providers/google, add matching AUTH_GOOGLE_ID / AUTH_GOOGLE_SECRET env variables, and drop it into the providers array. Auth.js supports 80+ providers this way.

Step 5: Create the API Route Handler

Auth.js needs a route to handle sign-in, sign-out, and OAuth callbacks. Create this file:

// src/app/api/auth/[...nextauth]/route.ts
import { handlers } from "@/lib/auth";

export const { GET, POST } = handlers;

Why a catch-all route?

The [...nextauth] folder name is a catch-all dynamic route — it matches every path under /api/auth/, like /api/auth/signin, /api/auth/callback/github, and /api/auth/session. Instead of writing a route for each one, Auth.js's handlers object already knows how to respond to all of them internally.

Step 6: Add the Proxy (Middleware)

In Next.js 16, what used to be called middleware.ts is now named proxy.ts — same concept, same file conventions, just a renamed file. This is the ideal place to check authentication before a request even reaches your page.

// src/proxy.ts
export { auth as proxy } from "@/lib/auth";

export const config = {
  matcher: [
    "/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
  ],
};

What's happening here?

Think of proxy.ts like a security guard standing at the entrance of your app — every matching request passes through it before reaching a page. By exporting auth as proxy, every request now has access to the session, which you can use to redirect unauthenticated users.

By default, this doesn't block anything yet — it just makes auth checking available. Let's actually protect a route next.

Step 7: Protect a Route

Let's say you have a /dashboard page that only logged-in users should see, and you also want to bounce already-logged-in users away from your login/home page. Update proxy.ts:

// src/proxy.ts
import { NextResponse } from "next/server";
import { auth } from "@/lib/auth";

export default auth((req) => {
    const isLoggedIn = !!req.auth;
    const { nextUrl } = req

    // Define routes that logged-in users shouldn't see
    const isAuthPage = nextUrl.pathname === "/login" || nextUrl.pathname === "/"

    if (isAuthPage) {
        if (isLoggedIn) {
            // Redirect authenticated users to the dashboard
            return NextResponse.redirect(new URL("/dashboard", nextUrl))
        }
        return NextResponse.next()
    }

    // Protect private routes
    if (!isLoggedIn && nextUrl.pathname.startsWith("/dashboard")) {
        return NextResponse.redirect(new URL("/", nextUrl))
    }
});

export const config = {
    matcher: [
        "/((?!api|_next/static|_next/image|favicon.ico|sitemap.xml|robots.txt).*)",
    ]
};

Breaking this down

auth((req) => {...}) wraps your proxy function, giving you req.auth — the current session, or null if nobody's logged in.
isAuthPage covers routes a logged-in user has no reason to revisit (like /login or your home page) — if they're already signed in, we send them straight to /dashboard instead.
The second check does the opposite: if someone isn't logged in and tries to visit /dashboard, we redirect them back to / instead of letting the request through.

⚠️ Common Mistake: Relying on proxy.ts alone for security. Middleware-level checks are great for UX (redirecting before a page even loads), but you should also verify the session inside Server Actions and Route Handlers that touch sensitive data — never trust the frontend redirect as your only line of defense.

Auth.js exposes signIn and signOut as Server Actions, so you can call them directly from a <form> without any client-side JavaScript.

// src/components/auth-buttons.tsx
import { auth, signIn, signOut } from "@/lib/auth";

export default async function AuthButtons() {
  const session = await auth();

  if (!session?.user) {
    return (
      <form
        action={async () => {
          "use server";
          await signIn("github");
        }}
      >
        <button
          type="submit"
          className="rounded-lg bg-primary px-4 py-2 text-sm font-medium text-primary-foreground"
        >
          Sign in with GitHub
        </button>
      </form>
    );
  }

  return (
    <form
      action={async () => {
        "use server";
        await signOut();
      }}
    >
      <button
        type="submit"
        className="rounded-lg border px-4 py-2 text-sm font-medium"
      >
        Sign out
      </button>
    </form>
  );
}

What's happening here?

AuthButtons is an async Server Component — it calls auth() directly to check whether someone's logged in, no useEffect or loading state needed.
The inline "use server" function inside action={...} is an inline Server Action. When the form is submitted, this function runs on the server and calls signIn("github") or signOut().
signIn("github") tells Auth.js exactly which provider to start the OAuth flow with — useful once you add more than one provider.

Drop this component into your navbar, and you've got a fully working auth toggle with zero client-side JavaScript.

Step 9: Read the Session in a Server Component

Anywhere on the server — a page, a layout, another component — you can call auth() to get the current user:

// src/app/dashboard/page.tsx
import { auth } from "@/lib/auth";

export default async function DashboardPage() {
  const session = await auth();

  return (
    <div>
      <h1 className="text-2xl font-bold">Dashboard</h1>
      <p className="text-muted-foreground">
        Welcome back, {session?.user?.name}!
      </p>
    </div>
  );
}

Since we already protect /dashboard in proxy.ts, session is guaranteed to exist by the time this page renders — but it's still good practice to use optional chaining (session?.user?.name) in case that logic ever changes.

Step 10: Protect a Server Action Directly

Even with proxy.ts in place, always double-check authentication inside anything that mutates data:

// src/actions/create-post.ts
"use server";

import { auth } from "@/lib/auth";

export async function createPost(formData: FormData) {
  const session = await auth();

  if (!session?.user) {
    return { error: "You must be signed in to do that." };
  }

  const title = formData.get("title") as string;

  // Your database logic here
  // await db.post.create({ data: { title, authorId: session.user.id } })

  return { success: true };
}

This is the same idea as validating input on the server even though your form already validates on the client — never trust that a request only came from your UI.

Frequently Asked Questions

Is Auth.js free?

Yes, completely. Auth.js is open source and has no usage limits, unlike some hosted auth providers that charge per monthly active user. You're only responsible for hosting and maintaining your own database if you want persistent user records.

Why is Auth.js still installed as `next-auth`?

Because the npm package name never changed, even though the project itself rebranded. Renaming a package that thousands of projects already depend on would break every existing install, so the team kept next-auth as the package name and just changed the project's public name and docs to Auth.js. You'll see both names used interchangeably — they refer to the exact same library.

Why did NextAuth become Auth.js?

NextAuth started out Next.js-only, but the maintainers wanted the same authentication core to work with other frameworks too — SvelteKit, Express, and more, via a shared @auth/core package. "NextAuth" no longer described what the project did, so it was renamed to the framework-agnostic Auth.js, with next-auth continuing on as the Next.js-specific package built on top of that shared core.

Do I need a database?

Not for OAuth-only sign-in like the GitHub example above — Auth.js can run in a stateless JWT session mode with zero database. You'll need a database (with an Auth.js adapter, like the Drizzle or Prisma adapter) if you want persistent user records, email/password login, or multiple linked accounts per user.

What's the difference between Auth.js and Clerk?

Auth.js gives you full ownership of your data — everything lives in your own database (or nowhere, if you're stateless) — but you build your own UI. Clerk is a hosted service with prebuilt sign-in components and a dashboard, which is faster to set up but means your user data lives on Clerk's infrastructure. If data ownership matters for compliance reasons, Auth.js is the safer default.

💡 If you're deciding between the two, see Clerk vs NextAuth (Auth.js) in 2026 for a full comparison.

Yes, using the Credentials provider. It requires you to write your own password hashing and verification logic (Auth.js won't do this for you, since it's security-sensitive), and you'll need a database to store user records.

Why is my session `null` even after signing in?

This is almost always a mismatched AUTH_SECRET or an incorrect callback URL. Double-check that your GitHub OAuth app's callback URL exactly matches http://localhost:3000/api/auth/callback/github (or your production domain), and that .env.local was loaded — restart your dev server after any environment variable change.

Wrapping Up

You've now got a complete Auth.js v5 setup in Next.js 16 — GitHub OAuth sign-in, route protection via proxy.ts, and session access in both Server Components and Server Actions. This same pattern extends cleanly: add more providers, connect a database adapter for persistent users, or layer role-based access control on top of the session object.

From here, a natural next step is wiring up a database adapter so user accounts persist across sign-ins, or adding a second provider like Google for more sign-in options.

📦 Source Code: View on GitHub

Useful Resources

Continue Learning

Helpful Free Tools

Meta Tag Generator for Next.js & HTML — generate SEO meta tags, Open Graph tags, Twitter Cards, canonical URLs, and JSON-LD structured data instantly. Handy for wiring up per-post metadata like the generateMetadata() function above.
Supabase RLS Policy Generator — if your next project pairs this blog setup with a Supabase backend, generate secure, performance-optimized Row Level Security policies in seconds.
Zod Schema Generator — generate Zod schemas instantly from JSON or TypeScript. Includes smart inference, live validation, React Hook Form, Next.js API Routes, and Server Actions.

Stop Implementing Authentication Inside Containers on Kubernetes

Sat, 25 Jul 2026 10:00:00 +0000

You have ten microservices running in Kubernetes. Each one validates JWTs, checks scopes, maintains sessions, and implements its own RBAC rules. One team uses jsonwebtoken v8, another uses a custom Go library, a third rolled their own HMAC check because “it was simple.” They all accept alg: none. Three accept RS256 and HS256 simultaneously.

This is not a security posture. This is a distributed security liability — and Kubernetes makes the problem worse, because the cluster creates an illusion of isolation that encourages teams to treat each Pod as a security boundary it was never designed to be.

The pattern of embedding authentication and authorization logic inside individual containers is one of the most pervasive anti-patterns in Kubernetes-based microservices. It feels like ownership and simplicity. It is, in practice, inconsistency at scale — and the blast radius of a single misconfiguration is your entire service portfolio.

Kubernetes provides the primitives to fix this at the infrastructure layer: Ingress controllers, the Gateway API, service mesh sidecars, admission webhooks, and workload identity via SPIFFE. None of these require a line of auth code inside your application containers.

This article explains why the anti-pattern exists, what’s wrong with it technically, and what the correct Kubernetes-native alternatives are — with concrete implementation guidance and references to the standards and incidents that validate the argument.

The Anti-Pattern: What It Looks Like

In-Application JWT Validation

Every service imports an auth library and validates tokens independently:

# Pattern seen in thousands of microservices
from jose import jwt

def authenticate(token: str):
    payload = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])
    return payload["sub"]

Variations include:

Algorithm confusion: accepting both HS256 and RS256, or letting the token header drive verification behavior instead of pinning acceptable algorithms server-side. This is a distinct JWT implementation failure class, documented extensively by PortSwigger on JWT attacks and RFC 8725
alg: none bypass: libraries that accept unsigned tokens when alg is set to none. This is a documented attack vector in Auth0’s JWT security analysis
Missing exp / iss / aud validation: trusting a valid signature without checking whether the token is expired, for the right audience, or from the right issuer
Key confusion attacks: accepting a public RS256 key as an HS256 symmetric secret

Session State in Every Service

When services maintain session state directly, they duplicate logic that has no business being duplicated — cookie validation, refresh token flows, PKCE verification — and each implementation diverges over time.

RBAC Reimplemented Per Service

Authorization rules (“can this user access this resource?”) end up embedded in service logic, mixed with business logic, tested inconsistently, and impossible to audit across the portfolio.

Why This Is a Structural Problem

1. The Vulnerability Surface Scales With Your Service Count

Each new microservice is a new JWT validation surface. A single incorrect library configuration — an unvalidated alg, a missing aud check — is an authentication bypass affecting that entire service. With ten services, you have ten potential misconfigurations. With a hundred services, the probability that at least one is misconfigured approaches certainty.

The OWASP Kubernetes Security Cheat Sheet and OWASP Microservices Security Cheat Sheet both identify in-service auth as a primary attack surface in microservices environments. NIST SP 800-204 and its companion NIST SP 800-204A on DevSecOps make the same argument: security controls belong at infrastructure boundaries, not inside application code.

2. Maintenance Cost Is Multiplicative

When a JWT vulnerability is disclosed — and they are disclosed regularly — you update one library in one service. Then another. Then you discover service C is pinned to an old version because it has a transitive dependency conflict. Meanwhile the vulnerability is exploitable in production.

The CNCF Cloud Native Security Whitepaper frames this directly: security controls implemented redundantly across services create maintenance overhead that teams cannot sustain, leading to version drift and policy divergence.

3. Centralized Policy Is Impossible to Enforce

When policy is in code — even well-factored library code — it cannot be changed atomically across services. A policy update requires a coordinated deployment across every affected service. In practice, services deploy on different schedules, managed by different teams, with different testing cycles. The result is that at any given moment, some fraction of your services are running different authorization rules.

This is the core argument in Google’s BeyondCorp model and the Zero Trust Architecture guidance from NIST SP 800-207: authentication and authorization decisions should be made by a centralized, auditable policy enforcement point — not distributed across workloads.

4. Secrets Distribution Is a Problem You Don’t Need

If every service validates JWTs, every service needs the signing key (for symmetric algorithms) or the public key (for asymmetric). Distributing and rotating signing keys across a fleet of microservices is an operational burden with meaningful blast radius: a leaked symmetric key compromises every service holding it.

The CNCF SPIFFE/SPIRE project was built specifically to solve this class of problem: workload identity should be cryptographically attested, not rely on secrets distributed to application code.

The Real-World Incidents

The `alg: none` Class

In 2015, critical vulnerabilities in JWT libraries from Auth0 affecting Python, PHP, Node.js, Ruby, Java, and .NET allowed attackers to forge tokens by setting alg: none. The signature was not verified. The vulnerability was present in applications that had copied JWT validation code from tutorials or used unpatched libraries — exactly the pattern that in-service auth produces at scale.

Java’s Psychic Signatures (CVE-2022-21449)

CVE-2022-21449 affected ECDSA signature verification in Oracle Java SE and GraalVM, including java.security.Signature paths used by higher-level libraries. The bug allowed certain malformed ECDSA signatures to verify when they should not. JWT validation was in scope only when the deployment used an affected Java runtime and ECDSA-signed tokens, for example ES256. A gateway would help only if verification happened on a patched or unaffected runtime at the gateway instead of inside every Java service.

CVE-2023-2728 (Kubernetes Mountable Secrets Bypass)

CVE-2023-2728 was not an ImagePolicyWebhook outage behavior. It was a Kubernetes API server issue where users could use ephemeral containers to bypass the mountable secrets policy enforced by the ServiceAccount admission plugin. Clusters were affected only when the ServiceAccount admission plugin, the kubernetes.io/enforce-mountable-secrets annotation, and ephemeral containers were used together. The adjacent ImagePolicyWebhook issue was CVE-2023-2727, also involving ephemeral containers, but it is a separate CVE.

The Uber API Gateway Evolution

Uber’s engineering blog describes its API gateway as a centralized layer for routing, protocol conversion, rate limiting, load shedding, header propagation, security auditing, and user access blocking. That supports the architectural point here: high-volume platforms move cross-cutting controls into shared infrastructure. The public source does not prove that Uber migrated specifically from per-service authentication to gateway authentication, so that stronger claim should not be made.

Netflix Zuul

Netflix’s Zuul is an L7 gateway for dynamic routing, monitoring, resiliency, security, and related edge concerns. Netflix’s own Zuul posts list authentication among common edge-service uses, but they do not frame Zuul primarily as a case study in eliminating per-service auth. Treat it as evidence that authentication is a natural edge concern at scale, not as proof of a specific migration story.

The Alternatives

Use these as complementary controls, not as a single replacement for all authentication and authorization logic:

Alternative	When to use it	What it solves	Principal trade-off
API Gateway / Edge Auth	External API clients, public ingress, partner integrations, mixed auth mechanisms at the boundary	Central JWT/API-key/OAuth2 validation, rate limiting, request shaping, and identity header propagation before traffic reaches services	Does not secure east-west service calls by itself; trusted headers require strict network boundaries
Service Mesh mTLS	Service-to-service traffic inside the cluster, especially across teams or sensitive domains	Workload identity, automatic mTLS, peer authentication, and proxy-level authorization policy	Adds data-plane/control-plane complexity and operational coupling to sidecars or ambient mesh components
OAuth2 Proxy	Browser-facing internal apps that need OIDC login, redirects, cookies, and session handling	Delegates login/session management to a reverse proxy and forwards authenticated identity headers	Best for HTTP/browser flows; not a general machine-to-machine authorization system
OPA	Complex, auditable, frequently changing authorization rules	Separates policy decisions from application releases and can run as sidecar, service, ext_authz backend, or admission control via Gatekeeper	Policy/data distribution and failure behavior must be designed deliberately
SPIFFE/SPIRE	Multi-cluster, multi-cloud, or meshless environments that need portable workload identity	Issues short-lived workload identities without application-managed shared secrets	Provides identity, not business authorization; needs registration and attestation lifecycle management

Option 1: API Gateway (Edge Auth)

An API Gateway sits at the perimeter and handles authentication before a request reaches any downstream service. Services receive pre-validated identity in a trusted header.

What it does: – Validates JWTs, API keys, OAuth2 tokens – Enforces rate limiting per identity – Strips and re-adds Authorization headers as needed – Routes to upstream services with verified identity headers

When to use it: – North-south traffic (external clients → cluster) – Mixed authentication mechanisms (JWT + API key + mTLS) at the Ingress layer – Teams that want to centralize auth policy without rolling out a full service mesh

Tools:

Gravitee.io API Gateway can be deployed on Kubernetes via its Helm chart and integrates with the Kubernetes Gateway API:

helm repo add graviteeio https://helm.gravitee.io
helm install gravitee-apim graviteeio/apim \
  --namespace gravitee \
  --create-namespace \
  --set gateway.replicaCount=2 \
  --set gateway.ingress.enabled=true \
  --set gateway.ingress.hosts[0]=api.example.com

Once deployed, authentication policies are declared on the ApiV4 CRD — no application code involved:

apiVersion: gravitee.io/v1alpha1
kind: ApiV4
metadata:
  name: payment-api
  namespace: gravitee
spec:
  name: "Payment API"
  type: PROXY
  listeners:
    - type: HTTP
      paths:
        - path: /v1/payments
      entrypoints:
        - type: http-proxy
  endpointGroups:
    - name: default
      type: http-proxy
      endpoints:
        - name: upstream
          type: http-proxy
          configuration:
            target: http://payment-service.production.svc.cluster.local:8080
  flows:
    - name: JWT validation
      enabled: true
      request:
        - policy: jwt
          enabled: true
          configuration:
            signature: RSA_RS256
            publicKeyResolver: JWKS_URL
            jwksUrl: https://idp.example.com/.well-known/jwks.json
            checkTokenRevocation: true
            requiredClaims:
              - name: aud
                value: payment-api
        - policy: rate-limit
          enabled: true
          configuration:
            rate:
              limit: 100
              periodTime: 1
              periodTimeUnit: MINUTES

Gravitee’s Kubernetes operator reconciles ApiV4 resources against the gateway, making API policy a first-class GitOps object — versioned, reviewed, and deployed the same way as any other Kubernetes manifest.

Other Kubernetes-native options: Emissary-Ingress (formerly Ambassador) with its AuthService CRD; Traefik with ForwardAuth middleware on IngressRoute resources.

Limitations: API Gateways handle north-south traffic. They don’t address east-west (service-to-service) authentication inside the cluster.

Option 2: Service Mesh (East-West mTLS + Auth)

A service mesh provides mutual TLS between every service pair and enforces authorization policy at the sidecar proxy, without any application code changes.

What it does: – Automatic mTLS between all service-to-service calls – Workload identity via X.509 certificates (SPIFFE SVIDs) – Fine-grained AuthorizationPolicy at the Envoy sidecar – JWT validation at the proxy, not the application

Istio Implementation:

Istio uses Envoy’s ext_authz filter and native RequestAuthentication + AuthorizationPolicy CRDs:

<pre class="wp-block-c

Build a Todo App with Next.js 16 and Supabase (2026 Guide)

Tue, 21 Jul 2026 04:06:26 +0000

In this guide, we’ll build a production-ready Todo App using:

Next.js 16
Supabase
TypeScript
Tailwind CSS
Server Actions
Authentication
Row Level Security (RLS)

This tutorial focuses more on logic and architecture rather than UI design.

By the end of this guide, you'll have:

Authentication with Supabase
Protected routes
Todo CRUD operations
Row Level Security (RLS)
Form validation with Zod
Server Actions
Secure session handling

What We’re Building

Our Todo App will include:

User Registration
User Login
Protected Dashboard
Create Todo
Complete Todo
Delete Todo
Secure Database Access with RLS

Prerequisites

Before starting, make sure you have:

Node.js installed
A Supabase account
Basic understanding of React and Next.js

Folder Structure

proxy.ts
src
├── actions
│   ├── auth.ts
│   └── todo.ts
├── app
│   ├── layout.tsx
│   ├── (auth)
│   │   ├── layout.tsx
│   │   ├── login
│   │   │   └── page.tsx
│   │   ├── register
│   │   │   └── page.tsx
│   ├── (private)
│   |   ├── layout.tsx
│   |   ├── page.tsx
│   |   ├── create
│   │   │   └── page.tsx
├── components
│   ├── form-error.tsx
│   ├── input.tsx
│   ├── loading-button.tsx
│   ├── navbar.tsx
│   └── todo-actions.tsx
├── utils
│   ├── supabase
│   |   ├── client.ts
│   |   ├── proxy.ts
│   |   └── server.ts
│   ├── validators
│   |   ├── auth.ts
│   │   └── todo.ts

Create a Next.js 16 Project

Run the following command:

npx create-next-app@latest todo-app

Choose options according to your preferences.

Recommended setup:

TypeScript
Tailwind CSS
App Router
React Compiler
src/ directory

Now move into the project:

cd todo-app

Setup Supabase

Go to Supabase Dashboard:

Create a New Project

Click New Project
Enter project name
Enter database password
Select region
Enable automatic RLS
Click Create Project

Add Environment Variables

Inside your project Dashboard:

Under Get Connected section
Click Frameworks

Copy the environment variables.

Create .env.local in your project root:

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=

Install Supabase Packages

Run:

npm install @supabase/supabase-js @supabase/ssr

We’ll also install Zod later for validation.

Understanding Supabase Clients

Supabase provides two client types:

Browser Client

Used inside Client Components.

Server Client

Used inside:

Server Components
Server Actions
Route Handlers

Create Supabase Browser Client

Create:

/src/utils/supabase/client.ts

import { createBrowserClient } from "@supabase/ssr";

export const createClient = () =>
  createBrowserClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!
  );

Create Supabase Server Client

Create:

/src/utils/supabase/server.ts

import { createServerClient } from "@supabase/ssr";
import { cookies } from "next/headers";

export async function createClient() {
  const cookieStore = await cookies();

  return createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return cookieStore.getAll();
        },

        setAll(cookiesToSet) {
          try {
            cookiesToSet.forEach(({ name, value, options }) =>
              cookieStore.set(name, value, options)
            );
          } catch {
            // Ignore if called from Server Component
          }
        },
      },
    }
  );
}

Setup Supabase Session Middleware

Create:

/src/utils/supabase/proxy.ts

import { createServerClient } from "@supabase/ssr";
import { NextResponse, type NextRequest } from "next/server";

export async function updateSession(request: NextRequest) {
  let supabaseResponse = NextResponse.next({
    request,
  });

  const supabase = createServerClient(
    process.env.NEXT_PUBLIC_SUPABASE_URL!,
    process.env.NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY!,
    {
      cookies: {
        getAll() {
          return request.cookies.getAll();
        },

        setAll(cookiesToSet, headers) {
          cookiesToSet.forEach(({ name, value }) =>
            request.cookies.set(name, value)
          );

          supabaseResponse = NextResponse.next({
            request,
          });

          cookiesToSet.forEach(({ name, value, options }) =>
            supabaseResponse.cookies.set(name, value, options)
          );

          Object.entries(headers).forEach(([key, value]) =>
            supabaseResponse.headers.set(key, value)
          );
        },
      },
    }
  );

  await supabase.auth.getClaims();

  return supabaseResponse;
}

Setup Next.js Middleware

Create:

/src/proxy.ts

import { type NextRequest } from "next/server";
import { updateSession } from "@/utils/supabase/proxy";

export async function proxy(request: NextRequest) {
  return await updateSession(request);
}

export const config = {
  matcher: [
    /*
     * Match all request paths except for the ones starting with:
     * - _next/static (static files)
     * - _next/image (image optimization files)
     * - favicon.ico (favicon file)
     * Feel free to modify this pattern to include more paths.
    */
    "/((?!_next/static|_next/image|favicon.ico|.*\\.(?:svg|png|jpg|jpeg|gif|webp)$).*)",
  ],
};

Create Route Groups

We’ll use route groups for better organization.

app
 ├── (auth)
 └── (private)

Route groups help organize routes without affecting URLs.
Learn more about Nextjs Route Groups.

Create Auth Layout

Create:

/app/(auth)/layout.tsx

export default function AuthLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <div className="bg-gray-900 flex items-center justify-center flex-1">
      {children}
    </div>
  );
}

Create:

/app/(auth)/login/page.tsx

"use client";

import { login } from "@/actions/auth";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import Image from "next/image";
import Link from "next/link";
import { useActionState } from "react";

export default function Login() {
  const [state, formAction] = useActionState(login, {
    errors: {
      email: [],
      password: [],
      formError: "",
    },
    data: {
      email: "",
      password: "",
    },
  });

  return (
    <div className="flex flex-col justify-center w-full">
      <div className="sm:mx-auto sm:w-full sm:max-w-sm">
        <Image
          src="https://tailwindcss.com/plus-assets/img/logos/mark.svg?color=indigo&shade=500"
          alt="Logo"
          className="mx-auto"
          width={50}
          height={50}
        />

        <h2 className="mt-10 text-center text-2xl/9 font-bold tracking-tight text-white">
          Sign in to your account
        </h2>
      </div>

      <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
        <form action={formAction} className="space-y-6">
          <Input
            defaultValue={state?.data?.email || ""}
            name="email"
            type="email"
            label="Email address"
          />

          <FormError errors={state.errors.email} />

          <Input
            defaultValue={state?.data?.password || ""}
            name="password"
            type="password"
            label="Password"
          />

          <FormError errors={state.errors.password} />

          <LoadingButton title="Sign in" />

          <FormError errors={state?.errors?.formError} />
        </form>

        <p className="mt-10 text-center text-sm/6 text-gray-400">
          Not a member?{" "}
          <Link
            href="/register"
            className="font-semibold text-indigo-400 hover:text-indigo-300"
          >
            Register
          </Link>
        </p>
      </div>
    </div>
  );
}

Important Note About Input Names

The name attribute is extremely important because we later access form values using:

formData.get("email")

If names don’t match, your form won’t work correctly.

Create Reusable Input Component

Create:

/src/components/input.tsx

interface InputProps {
  name: string;
  label?: string;
  type?: string;
  defaultValue?: string;
  required?: boolean;
}

const Input = ({
  name,
  label,
  type = "text",
  defaultValue,
  required = true,
}: InputProps) => {
  return (
    <div>
      {label && (
        <label
          htmlFor={name}
          className="block text-sm/6 font-medium text-gray-100"
        >
          {label}
        </label>
      )}

      <div className="mt-2">
        <input
          id={name}
          type={type}
          name={name}
          defaultValue={defaultValue}
          required={required}
          autoComplete={type === "email" ? "email" : undefined}
          className="block w-full rounded-md bg-white/5 px-3 py-1.5 text-base text-white outline-1 outline-white/10"
        />
      </div>
    </div>
  );
};

export default Input;

Create Loading Button

Create:

/src/components/loading-button.tsx

"use client";

import { useFormStatus } from "react-dom";

const LoadingButton = ({
  title,
  className = "",
}: {
  title: string;
  className?: string;
}) => {
  const { pending } = useFormStatus();

  return (
    <button
      disabled={pending}
      type="submit"
      className={`cursor-pointer flex w-full justify-center rounded-md bg-indigo-500 px-3 py-1.5 text-white ${className}`}
    >
      {pending ? "Loading..." : title}
    </button>
  );
};

export default LoadingButton;

What is useFormStatus?

useFormStatus() gives information about the latest form submission state.

We use it to:

Disable button while submitting
Show loading state
Prevent duplicate submissions

Create Form Error Component

Create:

/src/components/form-error.tsx

export default function FormError({
  errors,
}: {
  errors?: string | string[];
}) {
  if (!errors || (Array.isArray(errors) && errors.length === 0)) {
    return null;
  }

  return (
    <p aria-live="polite" className="text-sm text-red-500">
      {typeof errors === "string" ? errors : errors.join(", ")}
    </p>
  );
}

Install Zod

Run:

npm install zod

Create Auth Validation Schema

Create:

/src/utils/validators/auth.ts

import z from "zod";

export const authSchema = z.object({
  email: z.email(),
  password: z
    .string()
    .min(6, "Password must be at least 6 characters long")
    .max(100, "Password must not exceed 100 characters"),
});

Create:

/src/actions/auth.ts

"use server";

import { redirect } from "next/navigation";
import { createClient } from "@/utils/supabase/server";
import { authSchema } from "@/utils/validators/auth";

export async function login(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signInWithPassword(
    validatedFields.data
  );

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Here’s what happens:

Get form values using formData
Validate using Zod
Call Supabase Auth API
Redirect user after successful login

Because this is a Server Action, we must use the server Supabase client.

Create Register Page

Create:

/app/(auth)/register/page.tsx

Use the same structure as login page but replace:

import { signup } from "@/actions/auth";

and:

<LoadingButton title="Sign up" />

Add this inside:

/src/actions/auth.ts

export async function signup(prev: unknown, formData: FormData) {
  const data = {
    email: formData.get("email") as string,
    password: formData.get("password") as string,
  };

  const validatedFields = authSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      errors: {
        ...validatedFields.error.flatten().fieldErrors,
        formError: "",
      },
    };
  }

  const supabase = await createClient();

  const { error } = await supabase.auth.signUp(validatedFields.data);

  if (error) {
    return {
      data,
      errors: {
        formError: error.message,
        email: [],
        password: [],
      },
    };
  }

  redirect("/");
}

Supabase may require email confirmation depending on project settings after signup.

Create Private Layout

Create:

/app/(private)/layout.tsx

import Navbar from "@/components/navbar";

export default function PrivateLayout({
  children,
}: Readonly<{
  children: React.ReactNode;
}>) {
  return (
    <>
      <Navbar />

      <div className="mt-16">{children}</div>
    </>
  );
}

Create:

/src/components/navbar.tsx

import { logout } from "@/actions/auth";
import { createClient } from "@/utils/supabase/server";
import LoadingButton from "./loading-button";
import Link from "next/link";

const Navbar = async () => {
  const supabase = await createClient();

  const {
    data: { user },
  } = await supabase.auth.getUser();

  return (
    <div className="w-full flex items-center gap-4 p-4 bg-gray-800 justify-between">
      <div className="text-lg font-bold">
        Hi {user?.email}
      </div>

      <div className="flex items-center gap-4">
        <nav className="flex items-center gap-4">
          <Link href="/">Home</Link>
          <Link href="/create">Create Todo</Link>
        </nav>

        <form action={logout}>
          <LoadingButton title="Logout" />
        </form>
      </div>
    </div>
  );
};

export default Navbar;

Create Logout Action

Add this to:

/src/actions/auth.ts

export async function logout() {
  const supabase = await createClient();

  const { data: claimsData } = await supabase.auth.getClaims();

  if (claimsData?.claims) {
    await supabase.auth.signOut();
  }

  redirect("/login");
}

Protect Private Routes

Right now, users can manually access protected pages.

We need route protection.

Update:

/src/utils/supabase/proxy.ts

Replace this

await supabase.auth.getClaims()

With

const { data } = await supabase.auth.getClaims();

const user = data?.claims;
const publicRoutes = ["/login", "/register"];

if (user && publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/";
  return NextResponse.redirect(url);
}

if (!user && !publicRoutes.includes(request.nextUrl.pathname)) {
  const url = request.nextUrl.clone();
  url.pathname = "/login";
  return NextResponse.redirect(url);
}

Understanding Logic

Here’s what happens:

Get User
Create Public Routes
First if block checks if the user is logged in & trying to access public routes then navigates user to Home
Second if block checks if the user is not logged in & trying to access private routes then navigates user to Login

How Route Protection Works

Public Routes

Anyone can access:

/login
/register

Private Routes

Only authenticated users can access them.

Additional Protection

Logged-in users cannot revisit auth pages.

Create Todos Table

Open:

Supabase Project Dashboard
From sidebar click SQL Editor

Run:

create table todos (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id) on delete cascade not null,
  title text not null,
  completed boolean default false,
  created_at timestamptz default now()
);

Add Row Level Security Policies

Run:

create policy "Users can view own todos"
on todos
for select
using (auth.uid() = user_id);

create policy "Users can insert own todos"
on todos
for insert
with check (auth.uid() = user_id);

create policy "Users can update own todos"
on todos
for update
using (auth.uid() = user_id);

create policy "Users can delete own todos"
on todos
for delete
using (auth.uid() = user_id);

Why RLS is Important

Without RLS:

Any user could access all data.

With RLS:

Users can only access their own data.

This is one of the most important security features in Supabase.

Create Todo Validation Schema

Create:

/src/utils/validators/todo.ts

import z from "zod";

export const todoSchema = z.object({
  title: z
    .string()
    .min(2, "Title must be at least 2 characters long")
    .max(100, "Title must not exceed 100 characters"),
});

Create Todo Form

Create:

/app/(private)/create/page.tsx

"use client";

import { createTodo } from "@/actions/todo";
import FormError from "@/components/form-error";
import Input from "@/components/input";
import LoadingButton from "@/components/loading-button";
import { useActionState } from "react";

const CreateTodo = () => {
  const [state, formAction] = useActionState(createTodo, {
    error: "",
    data: {
      title: "",
    },
  });

  return (
    <div className="mt-10 sm:mx-auto sm:w-full sm:max-w-sm">
      <form action={formAction} className="space-y-6">
        <Input
          defaultValue={state?.data?.title || ""}
          name="title"
          label="Todo Title"
        />

        <FormError errors={state?.error} />

        <LoadingButton title="Create Todo" />
      </form>
    </div>
  );
};

export default CreateTodo;

Create Todo Action

Create:

/src/actions/todo.ts

"use server";

import { todoSchema } from "@/utils/validators/todo";
import { createClient } from "@/utils/supabase/server";
import { redirect } from "next/navigation";

export async function createTodo(
  prev: unknown,
  formData: FormData
) {
  const supabase = await createClient();

  const data = {
    title: formData.get("title") as string,
  };

  const validatedFields = todoSchema.safeParse(data);

  if (!validatedFields.success) {
    return {
      data,
      error:
        validatedFields.error.flatten().fieldErrors.title?.[0],
    };
  }

  const {
    data: { user },
  } = await supabase.auth.getUser();

  if (!user) {
    return {
      data,
      error: "Please login first",
    };
  }

  const { error } = await supabase.from("todos").insert({
    title: validatedFields.data.title,
    user_id: user.id,
  });

  if (error) {
    return {
      data,
      error: error.message,
    };
  }

  redirect("/");
}

Understanding the Create Todo Action

Here’s what happens:

Get form values using formData
Validate using Zod
Get logged in user
Call Supabase Auth API
Redirect user after successful insert

Create Home Page

Move:

/app/page.tsx

to:

/app/(private)/page.tsx

Now update it:

import TodoActions from "@/components/todo-actions";
import { createClient } from "@/utils/supabase/server";

export default async function Home() {
  const supabase = await createClient();

  const { data } = await supabase
    .from("todos")
    .select("*")
    .order("created_at", {
      ascending: false,
    });

  return (
    <div className="overflow-x-auto rounded-2xl border border-gray-200 bg-white shadow-sm max-w-xl mx-auto">
      <table className="divide-y divide-gray-200 w-full">
        <thead className="bg-gray-50">
          <tr>
            {['Todo', 'Status', 'Actions'].map((header) => (
              <th
                key={header}
                className="px-6 py-4 text-left text-sm font-semibold text-gray-700">
                {header}
              </th>
            ))}
          </tr>
        </thead>

        <tbody className="divide-y divide-gray-100 bg-white">
          {data?.map((todo) => (
            <tr
              key={todo.id}
              className="transition-colors hover:bg-gray-50"
            >
              <td className="px-6 py-4">
                <p className="font-medium text-gray-900">
                  {todo.title}
                </p>
              </td>

              <td className="px-6 py-4">
                <span
                  className={`inline-flex rounded-full px-3 py-1 text-xs font-medium ${todo.completed
                    ? "bg-green-100 text-green-700"
                    : "bg-yellow-100 text-yellow-700"
                    }`}
                >
                  {todo.completed ? "Completed" : "Pending"}
                </span>
              </td>

              <td className="px-6 py-4">
                <TodoActions todoId={todo.id} isCompleted={todo.completed} />
              </td>
            </tr>
          ))}
        </tbody>
      </table>

      {data?.length === 0 && (
        <div className="py-10 text-center text-sm text-gray-500">
          No todos found
        </div>
      )}
    </div>
  );
}

We’re fetching todos in descending order so that the latest todo comes at top.

Create Todo Actions Component

Create:

/src/components/todo-actions.tsx

'use client';

import { handleTodoAction } from "@/actions/todo";
import { useActionState } from "react";

const TodoActions = ({ todoId, isCompleted }: { todoId: string; isCompleted: boolean; }) => {
    const [_, action, isPending] = useActionState(handleTodoAction, undefined);

    const completeTodo = () => action({ todoId, action: "complete" });
    const deleteTodo = () => action({ todoId, action: "delete" });

    return (
        <form className="flex justify-end gap-3">
            {!isCompleted &&
                <button
                    formAction={completeTodo}
                    disabled={isPending}
                    className="rounded-lg disabled:opacity-50 bg-blue-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-blue-600"
                >
                    Complete
                </button>
            }
            <button
                formAction={deleteTodo}
                disabled={isPending}
                className="rounded-lg disabled:opacity-50 bg-red-500 px-4 py-2 text-sm font-medium text-white transition hover:bg-red-600"
            >
                Delete
            </button>
        </form>
    )
}

export default TodoActions

Complete and Delete Todo Action

Add inside:

/src/actions/todo.ts

import { revalidatePath } from "next/cache";

export async function handleTodoAction(prev: unknown, data: { todoId: string; action: "delete" | "complete" }) {

    const { todoId, action } = data;

    if (!todoId) return;

    const supabase = await createClient()
    const { data: { user } } = await supabase.auth.getUser();

    if (!user) return;

    if (action === 'delete') {
        await supabase
            .from("todos")
            .delete()
            .eq("id", todoId)
            .eq("user_id", user.id);
    } else {
        await supabase
            .from("todos")
            .update({
                completed: true,
            })
            .eq("id", todoId)
            .eq("user_id", user.id);
    }
    revalidatePath('/');
}

Final Result

You now have a fully functional Todo App with:

Next.js 16
Supabase Authentication
Protected Routes
Server Actions
Zod Validation
Secure RLS Policies
CRUD Operations

Conclusion

This project demonstrates a modern full-stack architecture using:

Next.js 16
Server Actions
Supabase
RLS
Authentication

Even though it’s a simple Todo App, the structure is production-ready and scalable.

You can now build larger applications using the same architecture and patterns.

Useful Resources

Source Code: View on GitHub

How to Add Clerk Authentication in Next.js 16 (2026 Guide)

Mon, 20 Jul 2026 03:23:46 +0000

Introduction

Authentication is one of the most important parts of modern web applications. Whether you're building a SaaS product, admin dashboard, marketplace, or social platform, you need a secure way to manage users, sessions, and protected routes.

In this guide, you'll learn how to add authentication to your Next.js 16 app using Clerk. We’ll cover:

Setting up Clerk in Next.js 16
Creating sign-in and sign-up pages
Protecting private routes
Accessing authenticated users in server components
Protecting server actions
Adding social login
Understanding route groups and dynamic routes

By the end, you’ll have a complete authentication system running in your app.

Why Use Clerk for Authentication?

Building authentication from scratch is time-consuming and error-prone. You need to handle:

Password hashing
Sessions
Social login
Email verification
Security best practices
Protected routes
User management

Instead of reinventing all of this, Clerk provides a production-ready authentication system with prebuilt UI components and secure session handling.

Key Features of Clerk

Prebuilt authentication UI
User management dashboard
Social login providers
Session management
Route protection
Server-side authentication helpers
Easy integration with Next.js

Clerk works extremely well with the App Router in Next.js 16 and makes authentication much simpler.

What You’ll Build

In this tutorial, we’ll create:

Sign-in page
Sign-up page
Protected private routes
Navbar with auth state
Server-side user authentication
GitHub OAuth login

Prerequisites

Before starting, make sure you have:

Node.js installed
Basic knowledge of React and Next.js
A Clerk account

Create a Next.js Project

Create a new Next.js app using:

npx create-next-app@latest clerk-auth

Choose the options according to your preferences.

For this tutorial, we’re using:

TypeScript
Tailwind CSS
React Compiler
src/ directory

Install Clerk

Install Clerk in your project:

npm install @clerk/nextjs

Project Folder Structure

Your project structure will look like this:

root/
    .env.local

src/
  proxy.ts

  app/
    layout.tsx
    globals.css

    (private)/
      layout.tsx
      page.tsx

    (public)/
      layout.tsx

        sign-in/[[...sign-in]]/
          page.tsx

        sign-up/[[...sign-up]]/
          page.tsx

  components/
    navbar.tsx

Add Clerk Middleware

Create a proxy.ts file.

If you’re using the src directory, place it inside src/proxy.ts.

src/proxy.ts

import { clerkMiddleware } from '@clerk/nextjs/server'

export default clerkMiddleware();

export const config = {
  matcher: [
    // Skip Next.js internals and static files
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',

    // Always run for API routes
    '/(api|trpc)(.*)',

    // Clerk frontend API routes
    '/__clerk/(.*)',
  ],
}

What Does This Middleware Do?

The Clerk middleware:

Handles authentication sessions
Detects signed-in users
Protects routes
Works with both client and server components

The matcher ensures middleware runs only where necessary.

Wrap Your App with ClerkProvider

Now wrap your application with ClerkProvider.

src/app/layout.tsx

import { ClerkProvider } from '@clerk/nextjs'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body className="min-h-full flex flex-col">
        <ClerkProvider>
          {children}
        </ClerkProvider>
      </body>
    </html>
  )
}

Why Use ClerkProvider?

ClerkProvider gives your entire application access to:

Authentication state
User sessions
Clerk UI components
Server helpers

Without it, Clerk components won’t work.

Now let’s create a navigation bar that changes depending on whether the user is logged in.

src/components/navbar.tsx

import {
  Show,
  SignInButton,
  SignUpButton,
  UserButton,
} from '@clerk/nextjs'

const Navbar = () => {
  return (
    <header className="flex justify-end items-center p-4 gap-4 h-16 shadow-md">
      <Show when="signed-out">
        <SignInButton />

        <SignUpButton>
          <button className="bg-[#6c47ff] text-white rounded-full font-medium text-sm sm:text-base h-10 sm:h-12 px-4 sm:px-5 cursor-pointer">
            Sign Up
          </button>
        </SignUpButton>
      </Show>

      <Show when="signed-in">
        <UserButton />
      </Show>
    </header>
  )
}

export default Navbar

Understanding the Clerk Components

`Show`

The Show component conditionally renders content based on authentication state.

<Show when="signed-in">

<Show when="signed-out">

`SignInButton`

Opens the Clerk sign-in flow.

`SignUpButton`

Opens the Clerk sign-up flow.

`UserButton`

Displays the authenticated user avatar and account menu.

Clerk has a lots of built in UI components that’s already do the heavy lifting, learn more Clerk’s UI Components.

Update your root layout:

src/app/layout.tsx

import { ClerkProvider } from '@clerk/nextjs'
import Navbar from '@/components/navbar'

export default function RootLayout({
  children,
}: {
  children: React.ReactNode
}) {
  return (
    <html lang="en">
      <body>
        <ClerkProvider>
          <Navbar />
          {children}
        </ClerkProvider>
      </body>
    </html>
  )
}

Start the Development Server

Run:

npm run dev

You’ll see a Clerk popup in the bottom-left corner.

Click:

Configure your application

You’ll be redirected to the Clerk dashboard.

Create a Clerk Application

After logging into Clerk:

Enter your application name
Create the application
Copy your environment variables

Add Environment Variables

Create a .env.local file.

.env.local

NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=pk_test_****
CLERK_SECRET_KEY=***

After adding them, restart your development server.

Now let’s create our own sign-in route.

src/app/(public)/sign-in/[[...sign-in]]/page.tsx

import { SignIn } from '@clerk/nextjs'

const Login = () => {
  return <SignIn />
}

export default Login

Understanding the Route Structure

Route Groups

(public)

This is a Route Group in Next.js.

Route groups help organize routes without affecting the URL.
Learn more about Nextjs Route Groups.

Dynamic Catch-All Routes

[[...sign-in]]

This is a dynamic catch-all route.

It allows Clerk to handle multiple auth-related routes internally.
Learn more about Nextjs Dynamic Routes.

src/app/sign-up/[[...sign-up]]/page.tsx

import { SignUp } from '@clerk/nextjs'

export default function Page() {
  return <SignUp />
}

Redirect Clerk Buttons to Custom Pages

Right now, the buttons still redirect to Clerk-hosted pages.

To fix this, update .env.local.

.env.local

NEXT_PUBLIC_CLERK_SIGN_IN_URL=/sign-in
NEXT_PUBLIC_CLERK_SIGN_UP_URL=/sign-up

Now the buttons will redirect to your custom routes.

Learn more about these environment variables and how to customize Clerk's redirect behavior in this dedicated clerk redirect guide.

Render User Information in a Server Component

Now let’s display the logged-in user’s name.

Move your homepage into a private route group:

app/(private)/page.tsx

And add

import { currentUser } from '@clerk/nextjs/server'

const Home = async () => {
  const user = await currentUser()

  return (
    <div className='mt-3 text-2xl'>
      Welcome {user?.fullName}
    </div>
  )
}

export default Home

Why Use `currentUser()`?

currentUser() works inside Server Components and allows you to securely access authenticated user data.

This is one of the best parts of using Clerk with Next.js App Router.

Protect Private Routes

Right now, unauthenticated users can still access your pages.

Let’s fix that.

Update your proxy.ts.

src/proxy.ts

import {
  clerkMiddleware,
  createRouteMatcher,
} from '@clerk/nextjs/server'

const isPublicRoute = createRouteMatcher([
  '/sign-in(.*)',
  '/sign-up(.*)',
])

export default clerkMiddleware(async (auth, req) => {
  if (!isPublicRoute(req)) {
    await auth.protect()
  }
})

export const config = {
  matcher: [
    '/((?!_next|[^?]*\\.(?:html?|css|js(?!on)|jpe?g|webp|png|gif|svg|ttf|woff2?|ico|csv|docx?|xlsx?|zip|webmanifest)).*)',
    '/(api|trpc)(.*)',
    '/__clerk/(.*)',
  ],
}

How Route Protection Works

We created a public route matcher:

const isPublicRoute = createRouteMatcher([
  '/sign-in(.*)',
  '/sign-up(.*)',
])

Everything except those routes becomes protected.

await auth.protect()

If the user is not authenticated, Clerk automatically redirects them to the sign-in page.

Protect Server Actions

You can also secure server actions using Clerk’s auth() helper.

dummy-server-action.ts

'use server'

import { auth } from '@clerk/nextjs/server'

export const dummyAction = async () => {
  // Check if user is authenticated
  const { isAuthenticated } = await auth()

  if (!isAuthenticated) {
    return {
      error: 'Please login',
    }
  }

  // Database logic here
}

Why Protect Server Actions?

Even if your UI is protected, server actions should still verify authentication because users can manually send requests.

This adds an additional security layer.

Add GitHub Authentication

Clerk also supports social authentication providers like:

GitHub
Google
Discord
Microsoft
Apple

Let’s enable GitHub login.

Go to your Clerk dashboard:

Select your application
Open the Configure tab
Click SSO Connections
Click Add Connection
Select GitHub
Enable:
- Sign-in
- Sign-up
Save the connection

Now users can authenticate using GitHub.

Important Production Note

When deploying to production, you should also enable:

Use Custom Credentials

This requires configuring your own GitHub OAuth credentials.
Follow this clerk doc on How to setup Github Custom Credentials.

Tip

If the built-in Clerk UI components don’t fully match your design requirements, you can create fully custom authentication flows using Clerk APIs. For more information, see the custom flow guide.

Common Mistakes to Avoid

Forgetting ClerkProvider

Without ClerkProvider, Clerk components won’t work.

Incorrect Middleware Location

If using src/, place middleware inside:

src/proxy.ts

Missing Environment Variables

Always restart your development server after changing .env.local.

Not Protecting Server Actions

Client-side protection alone is not enough.

Always validate authentication on the server.

Final Thoughts

You now have a complete authentication system in your Next.js 16 application using Clerk.

You learned how to:

Install Clerk
Create sign-in and sign-up pages
Protect routes
Access users in server components
Secure server actions
Add GitHub authentication

Clerk removes a huge amount of complexity from authentication and integrates extremely well with modern Next.js applications.

If you're building production-grade applications, Clerk is one of the fastest and safest ways to add authentication.

Next Steps

Helpful Resources

Access vs Refresh Tokens: I Was Missing Two Ideas

Wed, 15 Jul 2026 12:11:13 +0000

Years ago I was building a login API, and a colleague looked at what I was returning and asked why I only had one token. He said the newer APIs hand back two, an access token and a refresh token. Mine returned one. So I asked him the obvious thing: why two? What does the second one buy you?

He didn't really know either. He was a front-end dev, and he'd only ever seen the two tokens come back from the backend on a project he'd worked on. When he asked the person who built that side why there were two, all he got was "it's industry standard." That was the whole explanation. So he was passing that straight down to me: two tokens, that's just how it's done. He said he'd dig into the real reason and get back to me. Two developers standing there, and the actual why had already gone missing one hop up the chain, buried under "it's industry standard."

So I did what a confused junior does when the fancy version doesn't make sense. I called it overhead and shipped the simple one. One token, a JWT, and because I didn't want to think about expiry I gave it a life of something like seven years. No revocation. Once it was signed and handed out, it was valid until roughly the next World Cup, and there was nothing I could do to kill it. The only reason that never blew up in my face is that the project never went to production. I didn't get smart, I got lucky.

Why two tokens made no sense to me

The thing worth being honest about is exactly why I thought it was dumb, because the wrong mental model is the interesting part, not the right one.

First, I thought the refresh token was just a longer-lived copy of the access token. Same thing, one lives longer. If they're the same thing, why carry two? Just use the long one.

Then my colleague came back with the first real clue: the refresh token lives longer, and it's used rarely, only the access token gets sent on every request, so there's less chance of the refresh one getting stolen. And I remember pushing back on that, because "less chance of being stolen" sounded like a hand-wave. There's still a chance. If it can be stolen at all, and it's the long-lived one, then leaking it is worse, not better. That didn't sound like security, it sounded like hoping.

And underneath both of those was a bigger assumption I didn't even know I was making: tokens are stateless. That's the whole selling point, right, the server doesn't store them, it just checks the signature. So the idea of revoking one made no sense to me. You can't reach out and kill a stateless token, there's nothing to kill. And if you did want that, we already have sessions for exactly that job, so why reinvent it worse.

I also had never heard of scopes. It genuinely never occurred to me that a token could be restricted to one specific job. In my head a token meant "this is me, let me do things," full stop. So when I stacked all of that up, two tokens looked like ceremony. Two things that do the same job, one just lives longer, neither one killable, for a benefit I couldn't measure.

The two ideas I was actually missing

None of this resolved quickly. For months after that conversation we just kept shipping the single-token approach, because it worked and we didn't know any better. We were a handful of junior devs with nobody above us to ask. We knew JWT was the standard tool for auth, so we used it the way we understood it, one token, and moved on. The question just sat there, unanswered, for months.

It didn't click on the job. It clicked on YouTube, which is where I go when a thing refuses to make sense and I want to hear someone who actually gets it explain it.

Two concepts landed in the same video and the whole thing fell over at once.

The first was revocation. A token doesn't have to be a fire-and-forget thing you can never call back. If you store it, you can keep a list of the ones you've killed and refuse them. I'd been treating "stateless" as a law instead of a choice, and the moment it's a choice, killing a leaked token is just something you get to decide.

The second was scopes. A token can be restricted to certain actions and nothing else. So the two tokens weren't two copies of the same authority after all. They could have different powers on purpose.

Once I had those two pieces I ran every scenario in my head and it all just resolved, and honestly I started laughing at myself, because it was so easy. This was the same access-and-refresh split I'd bounced off when I first went reading about auth, back when none of the articles made sense. Nothing had changed. I'd just been missing two words. I went to my computer and built a small login, signup, and refresh flow as a demo, and I understood the entire thing end to end in under an hour.

So what are the two tokens actually for

Here's the version I wish someone had handed me at the start.

The access token is the one you send on every single request. Because it's everywhere, all the time, in headers, in logs if you're careless, on every hop, it's the one most likely to leak. So you make it cheap to lose. You give it a short life, minutes to an hour, and you scope it to just what it needs. It's a stateless JWT, so the server never looks it up, it just checks the signature and trusts it until it expires. That's what keeps it fast, and it's also why you don't try to kill an access token individually: you can't, so you lean on the short life instead. If a copy leaks, the damage is small and it ages out on its own fast.

The refresh token has exactly one job: get a new access token. That's it. It can't read your data, it can't hit your endpoints, it does one thing. And here's the part I'd had backwards: the refresh token usually isn't a JWT at all. It's an opaque random string, a row in your database, and that's on purpose, because a row is a thing you can delete. That's what makes it revocable. It also only ever travels to one place, the single refresh endpoint, never your other routes, so its exposure is a sliver of what the access token's is. You send it rarely, only when the access token is about to run out, so there are fewer chances to leak it in the first place, and the moment you suspect it, you delete the row and it's dead on the next use.

That finally answers the thing past-me couldn't get over: yes, the long-lived one can still be stolen, but it only works against that one refresh route, it's useless anywhere else, and it dies the instant you kill the row. The long life stops being scary once the thing is killable and can barely go anywhere.

Where you keep it matters as much as any of this. The refresh token lives in a cryptographically signed, httpOnly cookie, which the browser will hand back only to your server and which JavaScript on the page can't read. What you never do is drop it in localStorage. Anything running on your page can read localStorage, and on a modern app that's a pile of npm packages you didn't write. One compromised dependency reads your token straight out of storage and walks off with it, and you won't get so much as a log line. A signed cookie closes that door.

That's the piece I'd been missing. The refresh token is not a longer copy of the access token. It has a job the access token can't safely do. It keeps you logged in without making you re-type your password every hour, and it does that while staying killable. Short-lived thing you use constantly, long-lived thing you use almost never and can revoke on demand. Two different jobs, so two different tokens.

And that split is the best-of-both trick I never saw coming. A session checks the database on every single request: safe, always current, but a lookup every time. A pure JWT checks nothing, ever: fast, but you can't call it back. Two tokens sit right between them. The access token is the no-lookup JWT on the hot path, so the requests that happen constantly stay fast, and the refresh token is the database-backed, revocable thing on the cold path that fires rarely. You get the speed of stateless where it's hot and the killability of sessions where it counts.

The honest part: you probably don't need it

Now that I get it, I'm not going to pretend everyone should reach for two tokens. Most apps don't need this.

For a normal app with sessions, one token is fine. Give it a sane life, seven or thirty days, and when it expires, ask the user to log in again. That's not a security hole, that's just a login. The two-token dance has a real cost: you're now refreshing tokens on a timer, maintaining a blacklist, handling the refresh failing, handling the race where two requests refresh at once. That's more moving parts, and every moving part is a new place for it to break.

Notice that my seven-year JWT wasn't dumb because it was one token. It was dumb because it was unbounded and I couldn't kill it. A single token with a bounded life and a re-login is a perfectly reasonable design for most things I'd build today. Two tokens is what you reach for when the blast radius is big enough to earn the extra machinery: a big multi-tenant system, anything moving real money, anything where a leaked credential is expensive to clean up.

If I could hand one sentence back to the guy shipping that seven-year token, it'd be this. Short access, long refresh, only the refresh can mint new ones. If the small one leaks, the damage window is tiny. If the long one leaks, you blacklist it. That's the whole thing, and it took me two words, revocation and scopes, to see it.

The Other Half of Authentication Is 345 Years Old

Wed, 24 Jun 2026 04:57:16 +0000

Canonical: originally published at vibeagentmaking.com.

In 1675 a scholar declared the old charters were forgeries. A monk answered with a method, diplomatics, the half of document authentication PKI quietly forgot to build.

In 1675, a Jesuit scholar named Daniel van Papenbroeck did something that would feel very familiar today: he announced that you couldn't trust the documents. Writing in the preface to a volume of saints' lives, Papenbroeck argued that a large class of supposedly seventh-century royal charters, Merovingian land grants, the kind of parchment on which monasteries based their legal claims to property and privilege, were forgeries. Not a few of them. Essentially all of them, anything older than around AD 700. The historical record before a certain date, he suggested, was mostly fake.

This was not an idle academic spat. The Benedictine monks of Saint-Denis held exactly those charters, and their prestige, and their property rights, rode on the documents being real. So the order did the sensible thing and handed the problem to its sharpest young scholar, a monk named Jean Mabillon, with what amounted to a brief: prove the documents are authentic, or prove we have a method for telling. Mabillon spent six years on it. What he produced in 1681, a six-volume Latin treatise called De re diplomatica, did not just defend the charters. It founded a science.

We are living through Papenbroeck's panic again. The 2020s version is "nothing online is real": deepfaked memos, AI-forged letters, synthetic leaked documents, screenshots of conversations that never happened. And our instinct, like the seventeenth century's, swings between two bad options: credulously trust everything, or cynically trust nothing. Mabillon's contribution was to refuse both. He replaced the panic with a method, and that method, a discipline called diplomatics, is the half of document authentication that modern security engineering quietly forgot to build.

A science for telling the true from the false

Mabillon had a phrase for what his discipline was for: discrimen veri ac falsi, "the distinguishing of the true from the false." And his central move, the one that made it a science rather than a series of educated guesses, was this: you authenticate a document from its form, not from its custody.

That distinction is the whole game, so it's worth being precise about it. There are two ways to decide whether a document is genuine. The first is to trace where it came from, who held it, who passed it to whom, an unbroken line back to its creation. Call that the chain. The second is to interrogate the artifact itself, its structure, its conventions, the thousand small choices a genuine document of its kind would make and a forgery gets subtly wrong. Mabillon's insight was that the second method works even when the first is unavailable, which, for medieval charters scattered and recopied across five centuries, it almost always was.

To make this systematic, diplomatics treats every formal document as having a predictable anatomy. The opening is the protocol, the invocation, the issuer's title, the addressee, the greeting. The middle is the text, including the dispositio, the operative clause that actually does the thing (grants the land, confirms the privilege), wrapped in rhetorical preamble and penalty clauses. The close is the eschatocol, the signatures and cross-marks, the witness list, the date and place, the closing benediction. None of this is decoration. In a world where most people couldn't read, the form was the mechanism by which a document claimed legal force: the right formula, in the right place, sealed the right way, was the authority.

And here is the part that should make any security engineer sit up, because it is a forensic principle of startling generality: forgeries almost always fail at the transitions between the parts. A forger can copy a salutation perfectly and then attach it to a dating clause from the wrong century. They can reproduce an authentic seal and bolt it onto a protocol whose formulae no real chancery of that era would have paired with it. The forger learns the surface of the document type, what it looks like, but not its internal grammar, the way the parts have to cohere. The seams are where the lie shows.

The nineteenth-century German scholar Theodor von Sickel sharpened this into something explicitly forensic with a concept he called Kanzleimäßigkeit, "chancery-conformity." The point was that you don't compare a suspect charter to a vague sense of "how thirteenth-century documents feel." You compare it to the specific office that supposedly produced it: which scribe's hand, the clerk who habitually drafted these formulae, the officials who co-signed, what this one chancery's working habits actually were. The target of comparison stopped being a period and became an institution. That is a fingerprinting discipline.

It worked, and not just on charters. The most famous case predates Mabillon: in 1440 the humanist Lorenzo Valla demolished the Donation of Constantine, the document by which the fourth-century emperor had supposedly handed temporal authority over the Western Empire to the Pope, by showing its Latin vocabulary and institutional terminology were anachronistic, language a fourth-century chancery could not have produced. The forgery had fooled people for centuries because nobody had read its form closely enough. Modern scholarship dates the actual composition to the eighth or ninth century. A political fraud that shaped the map of medieval Europe was undone not by finding a smoking-gun source but by reading the document against itself.

What PKI does, and the cases it can't reach

Now jump 345 years, to how we authenticate digital documents today. The dominant answer is public-key infrastructure: a digital signature, validated through a chain of certificates up to a trusted authority, proving two things, who signed the document, and that the bytes haven't changed since. When it works, it's beautiful, and far stronger than anything Mabillon had. I want to be clear that PKI is not broken and this is not an argument against it.

It is an argument about scope. Because PKI authenticates the chain, and the chain has failure modes, and they are, almost exactly, the cases diplomatics was invented for.

Start with the one PKI practitioners know best: revocation. Certificates expire, and a certificate authority can revoke one early, publishing the fact through a Certificate Revocation List or an OCSP responder. Here's the catch that's underappreciated outside the field: this quietly undoes PKI's most-advertised selling point. A certificate is supposed to be self-authenticating, you can check it without phoning home. But once revocation is in the picture, you must fetch the current revocation data online, and CRLs lag by their publication interval, leaving a window in which a revoked certificate still validates. The "self-authenticating" certificate isn't actually self-contained. Sit with the irony: Mabillon's analysis of a document's internal form is more self-contained than a modern certificate, because the form is all there, in the artifact, with nothing to go fetch.

Then the cases that get worse. Dead keys. A digital record signed thirty years ago, with algorithms now obsolete and signing keys long gone, you cannot re-validate that chain, ever. This is precisely the problem the archival world has wrestled with for decades: how do you trust the authenticity of a digital record over the long term when the entire cryptographic context that vouched for it has crumbled?

And the case that's exploding right now: artifacts that were never signed at all. A leaked file. An internal draft. A screenshot. A forwarded copy stripped of its headers. An AI-generated document. For all of these, there is no chain to check, PKI has nothing to say, because nothing in its model ever happened. The signature it's looking for was never there.

The clean way to hold the two methods is this: PKI verifies provenance you have; diplomatics reconstructs trust when provenance is broken or absent. They aren't rivals. They're the two halves of the authentication problem, and the security world, reaching naturally for cryptography, built one half and left the other in the archives.

The bridge already exists, it just never crossed the wall

I want to be careful here, because there's a tempting and false version of this essay that says "nobody has ever connected medieval document science to digital authentication." That's wrong, and the truth is more interesting.

The archivist Luciana Duranti and the international InterPARES project have been doing exactly this since 1999, building what they call the archival diplomatics of digital records, and, pointedly, digital records forensics. For a quarter century, a serious research program has been carrying Mabillon's principles from parchment to pixels: treating a born-digital record's structure, its metadata, its formal elements as the evidence, asking whether a digital object conforms to the documentary form its claimed origin would produce. The parchment-to-pixels bridge is not a thought experiment. It is a mature field.

The strange thing, the actual gap worth naming, is that this mature field lives in archival science and has almost never crossed the disciplinary wall into the cryptographic, PKI, and security-engineering literature. Two communities have been working the same problem, authenticating documents, with almost no traffic between them. The cryptographers reached for the chain; the archivists kept reading the form; and they rarely cite each other. The opportunity isn't to invent the connection. It's to import it, to put the form-reading toolkit on the same workbench as the signature-checking one.

Which brings us to the sharpest modern case, and the one where the two halves most need each other. An AI-generated document is the ultimate chain-broken artifact: a deepfake contract, an LLM-forged resignation letter, a synthetic "leaked memo" can never be caught by PKI, because nothing valid ever signed them. But they are a textbook diplomatics problem. A language model learns the surface of a document type, the look and cadence of a contract, a memo, an official letter, from its training distribution. What it does not reliably learn is the institutional grammar underneath: which formula has to pair with which, which validation marks a specific office actually uses, whether the opening and the operative clause are internally consistent, whether the dating convention matches the claimed issuer. It will, in other words, tend to get the form subtly wrong at the transitions, which is the exact failure signature Mabillon used to catch the Merovingian forgers. I'm offering that as a natural application, not a finished detector. The lens is the right one. A model that has absorbed the appearance of a document type without its institutional grammar is, structurally, a very fast forger, and forgers have a known weakness.

What to build with this

The practical takeaway for anyone building or trusting verification systems is to stop treating authentication as one question and start asking two.

PKI's question, can I trust the chain of custody?, is the right one whenever the chain is intact, and you should keep leaning on it hard. Diplomatics' question, does the document's own form betray it?, is the one you need whenever the chain is broken, which in the AI era is more and more of the time. The mature engineering posture is to build both, and to know which you're relying on.

Three concrete things follow. First, authentication is not binary, and diplomatics knew this three centuries before we did: a document can be genuine in substance but altered in form, a faithful copy of a lost original, or a real act recorded in a forged instrument. "Real" and "fake" are too coarse; the useful output is a structured judgment about which elements conform and which don't. Second, internal consistency is a verification primitive you can actually implement, does this artifact cohere the way a genuine document of its claimed type and origin would?, and it has the rare property of working precisely where signatures don't. Third, and most pointed for anyone shipping AI systems, including those of us building them: where there is no signing chain, internal-evidence authentication is the only verification left. For synthetic content, the form is the evidence.

Mabillon's real discovery, the thing that let one monk answer a continent's worth of forgery panic, was that you do not always need to know where a document has been. If you can read its form closely enough, the document carries its own testimony, the seams, the formulae, the conformity or its absence. Three and a half centuries later, as the chain of custody breaks more often than it holds, that is not a quaint medieval technique waiting to be rediscovered. It is the half of authentication we already had, in another building, the whole time.

Sources

Jean Mabillon, De re diplomatica libri VI (Paris, 1681), and the Papenbroeck–Mabillon bella diplomatica over the Saint-Denis Merovingian charters, via Encyclopædia Britannica ("De Re Diplomatica," "Jean Mabillon") and Wikipedia ("Diplomatics," "Jean Mabillon"). Lorenzo Valla, De falso credita et ementita Constantini Donatione (1440), on the Donation of Constantine; the document anatomy (protocolum / textus / eschatocolum) and Theodor von Sickel's Kanzleimäßigkeit are standard diplomatics, codified by the 19th-century German and French schools. Luciana Duranti and the InterPARES Project (1999– ): "Archival Diplomatics of Digital Records," "From Digital Diplomatics to Digital Records Forensics" (Archivaria), "The Return of Diplomatics as a Forensic Discipline," and "The Authenticity of Electronic Records: the InterPARES Approach"; Wikipedia, "InterPARES Project." On PKI revocation and the self-authenticating caveat: Wikipedia, "Certificate revocation list"; TechTarget, "Certificate Revocation List (CRL)"; eMudhra, "How to Verify a PKI-Based Digital Signature." The application of diplomatics to AI-generated documents is offered here as a proposed forensic approach, not a demonstrated result.

When the chain of custody breaks, the form is the evidence. PKI verifies the provenance you have; it has nothing to say about a leaked draft, a dead-key archive, or an AI-forged memo that nothing valid ever signed. The other half is reading the artifact's own form. Chain-of-consciousness records an agent's reasoning as it works, so the work carries its own internal testimony, a trail you can read even when there is no signature to check.

pip install chain-of-consciousness · npm install chain-of-consciousness · Hosted Chain-of-Consciousness

Building Authentication From Scratch in Go — No Libraries, No Magic

Tue, 19 May 2026 14:02:04 +0000

In Part 2, I had a working REST API with two endpoints. You could create entries and query them. But anyone could hit the API — no login, no tokens, no protection.

This post is about the day I decided to build authentication from scratch, and the Go pattern that changed how I think about HTTP servers.

The Plan

I needed three things:

Register — hash a password, save the user
Login — verify credentials, return a JWT token
Middleware — block unauthenticated requests before they reach any handler

No auth libraries. No Passport.js equivalent. Just golang-jwt/jwt for token creation and golang.org/x/crypto/bcrypt for password hashing.

Registration: My First Time Hashing a Password

Here's what the register handler looked like:

func Register(w http.ResponseWriter, r *http.Request) {
    var req RegisterRequest
    json.NewDecoder(r.Body).Decode(&req)

    // Validate
    if req.Email == "" { /* 400 */ }
    if !strings.Contains(req.Email, "@") { /* 400 */ }
    if len(req.Password) < 6 { /* 400 */ }

    // Hash password — NEVER store plain text
    passwordHash, err := bcrypt.GenerateFromPassword(
        []byte(req.Password), bcrypt.DefaultCost,
    )

    // Save to database
    userID, err := db.CreateUser(req.Email, string(passwordHash))
}

Two things I learned here:

bcrypt.DefaultCost is 10. That means it runs the hashing algorithm 2^10 = 1,024 times. Slow on purpose — makes brute-force attacks impractical. I spent 20 minutes reading about why a slower hash function is a feature, not a bug.

[]byte() everywhere. bcrypt's functions take byte slices, not strings. Coming from JavaScript where everything is just a string, I kept forgetting to convert. Go makes you think about data types at every step.

The login flow taught me more about Go than any tutorial:

// 1. Get user from database
userID, passwordHash, err := db.GetUserByEmail(req.Email)

// 2. Compare password with stored hash
err = bcrypt.CompareHashAndPassword(
    []byte(passwordHash), []byte(req.Password),
)

// 3. Create JWT claims
claims := jwt.MapClaims{
    "user_id": userID,
    "exp":     time.Now().Add(24 * time.Hour).Unix(),
}

// 4. Sign the token
token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
tokenString, err := token.SignedString([]byte(secret))

I left this comment in my code at the time:

// Why Unix()? JWT needs simple numbers, not complex Go time objects
// Example: time.Now().Unix() = 1736359530 (just a number)
// Add 24 hours = add 86400 seconds (24 * 60 * 60 = 86400)

Again — verbose, maybe obvious to experienced devs. But I was explaining JWT to myself while building it. That's the whole point of learning in public.

One security detail I got right: the error message for a wrong password is "Invalid email or password" — same as for a non-existent email. You never want to reveal whether an account exists.

The Middleware Pattern That Changed Everything

This is the part I'm most proud of from this phase. Go doesn't have middleware built in like Express. You build it yourself:

func AuthMiddleware(next http.HandlerFunc) http.HandlerFunc {
    return func(w http.ResponseWriter, r *http.Request) {
        // 1. Get token from "Authorization: Bearer <token>"
        authHeader := r.Header.Get("Authorization")
        tokenString := strings.TrimPrefix(authHeader, "Bearer ")

        // 2. Validate token
        claims, err := validateToken(tokenString)
        if err != nil {
            errorResponseAuth(w, http.StatusUnauthorized, "Invalid token")
            return
        }

        // 3. Extract user_id and add to request context
        userID := claims["user_id"].(float64)
        ctx := context.WithValue(r.Context(), "user_id", int64(userID))

        // 4. Call next handler with updated context
        next(w, r.WithContext(ctx))
    }
}

Read that again. A function that takes a handler and returns a new handler. The returned handler does the auth check first, and only calls the original handler if the token is valid.

In main.go, using it looks like this:

// Public routes — no protection
http.HandleFunc("/register", handlers.Register)
http.HandleFunc("/login", handlers.Login)

// Protected route — wrapped with AuthMiddleware
http.HandleFunc("/entries", handlers.AuthMiddleware(func(w http.ResponseWriter, r *http.Request) {
    if r.Method == http.MethodPost {
        handlers.CreateEntry(w, r)
    } else if r.Method == http.MethodGet {
        handlers.GetEntries(w, r)
    }
}))

AuthMiddleware(handler) — that's it. One wrapper function. No framework, no plugin system, no decorator syntax. Just a function wrapping another function.

This is the moment Go clicked for me at a deeper level. Functions are values. You can pass them around, wrap them, chain them. Middleware isn't a framework feature — it's just how functions work.

The `context.WithValue` Trick

The most clever part of Go's auth pattern: how you pass the user ID from middleware to the handler.

// Middleware sets it:
ctx := context.WithValue(r.Context(), "user_id", int64(userID))
next(w, r.WithContext(ctx))

// Handler reads it:
userID := r.Context().Value("user_id").(int64)

No global variables. No session objects. The user ID travels with the request itself. Every handler that needs to know who's making the request just reads it from the context.

Coming from Express where you'd do req.user = decoded, this felt more explicit and safer. The data is scoped to the request, not bolted onto a mutable object.

One Thing That Tripped Me Up

JWT numbers come back as float64, not int64. This line:

userID, ok := claims["user_id"].(float64)

I originally wrote .(int64) and couldn't figure out why it kept failing. Turns out JSON (which JWT uses internally) doesn't distinguish between integers and floats — everything is a number. Go's JSON decoder maps all numbers to float64.

Took me an hour of debugging. Now I'll never forget it.

What the API Looked Like After This

POST /register  → Create account (public)
POST /login     → Get JWT token (public)
POST /entries   → Create entry (protected)
GET  /entries   → List entries (protected)
GET  /health    → Health check (public)
GET  /ping      → Ping (public)

Four real endpoints. Authentication. Authorization. No frameworks. Just Go's standard library plus two packages for JWT and bcrypt.

What's Next

In Part 4, I'll cover the week I added testing, UPDATE, and DELETE — and why writing tests after the code changed how I thought about designing handlers.

This is Part 3 of the "Learning Go in Public" series. Part 1 | Part 2

B2B Authentication Provider Comparison: Features, Pricing & SSO Support (2026)

Tue, 28 Apr 2026 20:29:55 +0000

Enterprise SaaS buyers now expect SSO and SCIM support by default.

Most enterprise security teams will reject SaaS products that do not support SSO. Identity infrastructure has become a core requirement for B2B SaaS platforms.

Modern authentication providers help SaaS companies integrate:

Enterprise Single Sign-On (SSO)
Directory synchronization
SCIM user provisioning
Multi-factor authentication
Passwordless login

Instead of building authentication infrastructure internally, most SaaS companies rely on specialized identity platforms.

Below is a quick comparison of the leading B2B authentication providers in 2026.

Quick Comparison of Authentication Providers

Provider	Best For	Pricing Model	Enterprise SSO	SCIM
Auth0	Full CIAM platform	MAU	✓	✓
Okta	Enterprise IAM	Per-user	✓	✓
WorkOS	B2B SaaS SSO integrations	Per connection	✓	✓
SSOJet	Enterprise SSO for SaaS	Per connection	✓	✓
MojoAuth	Passwordless authentication	API / MAU	Partial	Limited
FusionAuth	Self-hosted CIAM	License / self-hosted	✓	✓
Keycloak	Open-source IAM	Self-hosted	✓	Limited

Enterprise authentication platforms differ significantly in architecture and pricing models.

Some providers offer complete identity platforms, while others focus on enterprise SSO infrastructure.

For example:

Auth0 provides a full CIAM platform covering authentication, MFA, and user management.
Okta dominates enterprise workforce identity.
SSOJet focuses on enterprise SSO integrations for SaaS apps.

However, many modern B2B SaaS companies prefer dedicated enterprise SSO platforms designed specifically for multi-tenant SaaS architectures.

This is where platforms like SSOJet stand out.

Instead of replacing your authentication system, SSOJet allows SaaS companies to add enterprise SSO and SCIM provisioning quickly without rebuilding their identity stack.

This approach is particularly valuable for SaaS startups and mid-market platforms that want to support enterprise customers without complex identity infrastructure.

Key Authentication Trends in 2026

The authentication landscape is evolving rapidly as organizations prioritize stronger identity security and seamless access management. Several major trends are shaping the identity and authentication market in 2026.

1. Enterprise SSO Becoming a Standard Requirement

Enterprise Single Sign-On (SSO) is no longer considered an optional feature. Most enterprise customers now require SSO support as part of their vendor procurement process.

Organizations expect SaaS platforms to integrate with existing identity systems to simplify user management and improve security. Supporting standards like SAML and OpenID Connect has become essential for B2B applications.

2. Rapid Growth of Passwordless Authentication

Traditional password-based authentication is gradually being replaced by passwordless methods.

Technologies such as Passkeys and WebAuthn are gaining adoption because they:

eliminate password-related security risks
reduce phishing vulnerabilities
improve user experience

Many modern authentication platforms now prioritize passwordless login as a core capability.

3. Identity Security Moving Toward Zero-Trust

Security architectures are shifting toward Zero Trust Architecture, where access decisions are based on verified identity signals rather than network location.

In this model:

every access request is verified
user identity and device signals are continuously evaluated
trust is never assumed

Identity providers and authentication platforms play a central role in enabling these zero-trust security models.

4. Expansion of Enterprise Identity Integrations

Modern organizations rely on multiple identity providers and enterprise platforms to manage user access across their technology stack.

Common identity providers used by enterprises include:

Okta
Microsoft Entra ID
Google Workspace
Ping Identity

As a result, SaaS companies must support seamless identity integrations to enable enterprise customers to authenticate users using their existing identity systems.

Why This Comparison Matters

Choosing the wrong authentication platform can create major technical and financial problems later.

Identity infrastructure directly impacts:

Security
Enterprise Sales
Developer Productivity
Platform Scalability

A poorly chosen identity provider can make it difficult to support enterprise customers.

On the other hand, the right provider can dramatically accelerate enterprise onboarding and reduce engineering complexity.

This guide compares the most important authentication platforms used by B2B SaaS companies in 2026, including:

Auth0
Okta
WorkOS
SSOJet
MojoAuth
FusionAuth
Keycloak

We will analyze their:

Features
Pricing Models
Enterprise SSO Capabilities
Developer Experience
Real-World Use Cases

Why Authentication Infrastructure Is Critical for B2B SaaS

Authentication is no longer just a login feature.

For modern SaaS platforms, identity infrastructure directly impacts security, enterprise sales, and user management.

Enterprise customers expect SaaS applications to support secure authentication standards and identity federation. Without these capabilities, many companies cannot even begin a security review.

Below are the key reasons why authentication infrastructure has become essential for B2B SaaS products.

Enterprise Customers Require SSO

Enterprise companies typically manage employee access through a centralized identity provider.

These identity providers control:

Employee Authentication
Application Access
Security Policies
Multi-factor Authentication

Instead of creating separate accounts for every SaaS application, employees sign in using Single Sign-On (SSO).

SSO allows a company’s identity provider to authenticate users across multiple applications.

For example, a company using Okta can allow employees to log into a SaaS product using their corporate account.

This approach improves security and reduces password management issues.

However, it also means that SaaS companies must integrate with enterprise identity providers to support SSO.

Platforms like SSOJet and WorkOS help SaaS applications quickly add enterprise SSO integrations without building complex identity infrastructure.

Enterprise Procurement Requires Identity Integration

SSO is often a mandatory requirement during enterprise procurement.

Security teams typically evaluate SaaS vendors based on their identity and access management capabilities.

Common enterprise requirements include:

SAML SSO support
SCIM Provisioning
Multi-Factor Authentication
Role-Based Access Control
Audit Logging

If a SaaS product cannot support enterprise identity standards, it may fail security reviews.

This is one of the main reasons many SaaS startups adopt dedicated authentication platforms such as:

Auth0
SSOJet
WorkOS

These platforms simplify enterprise identity integrations and reduce development effort.

SCIM Automates User Provisioning

Managing user accounts manually becomes difficult for large organizations.

When a new employee joins a company, the IT team needs to create accounts across multiple SaaS tools.

When an employee leaves, those accounts must be removed immediately.

SCIM (System for Cross-domain Identity Management) solves this problem.

SCIM allows enterprise identity providers to automatically:

Create User Accounts
Update User Information
Deactivate Accounts

This process is called automated user provisioning.

For SaaS companies selling to enterprises, SCIM support is becoming just as important as SSO.

Platforms such as SSOJet and WorkOS provide built-in SCIM provisioning to simplify enterprise onboarding.

Security Risks of Building Authentication Internally

Some SaaS teams attempt to build authentication systems from scratch.

While this may seem simple initially, identity systems quickly become complex.

Authentication infrastructure must support:

Password Hashing and Security
Multi-Factor Authentication
Session Management
Token Handling
Identity Federation
Enterprise SSO Protocols

Maintaining these systems securely requires significant engineering effort.

Security vulnerabilities in authentication systems can lead to:

Account Takeovers
Data Breaches
Compliance Violations

For this reason, most SaaS companies rely on specialized identity providers rather than building authentication internally.

Platforms like Auth0 provide a complete identity platform, while providers like SSOJet focus specifically on enterprise SSO infrastructure.

Identity Has Become the Security Perimeter

Modern cloud applications no longer operate within traditional network boundaries.

Employees access SaaS platforms from:

Remote Locations
Mobile Devices
Multiple Networks

Because of this, security teams increasingly rely on identity-based security models.

In a zero-trust architecture, identity verification becomes the primary method of controlling access.

Authentication providers play a central role in this model by managing:

User Authentication
Identity Federation
Access Policies
Security Signals

This shift is one reason why identity infrastructure has become a critical component of SaaS architecture.

Why Many B2B SaaS Platforms Use Dedicated SSO Providers

Supporting enterprise authentication standards can significantly slow product development.

Implementing SAML integrations with multiple enterprise identity providers often requires:

Complex Protocol Handling
Metadata Configuration
Certificate Management
Security Testing

Dedicated enterprise SSO providers simplify this process.

Platforms like SSOJet provide ready-to-use integrations with enterprise identity providers, allowing SaaS companies to support enterprise authentication quickly.

This enables SaaS teams to focus on their core product rather than building identity infrastructure.

Core Authentication Protocols Every SaaS Company Should Know

Enterprise authentication relies on a few core identity standards.

These protocols allow SaaS applications to integrate with enterprise identity providers and support secure login flows.

Most modern SaaS authentication platforms support the following protocols:

SAML
OAuth 2.0
OpenID Connect (OIDC)
SCIM

Understanding these protocols helps SaaS teams choose the right authentication provider.

SAML (Security Assertion Markup Language)

SAML is the most widely used protocol for enterprise Single Sign-On (SSO).

SAML allows an enterprise identity provider to authenticate users for external applications.

In a typical SAML login flow:

A user attempts to access a SaaS application.
The application redirects the user to their company’s identity provider.
The identity provider authenticates the user.
The identity provider sends a signed authentication response back to the application.

The SaaS application trusts this response and grants access.

SAML is commonly used by enterprise identity providers such as:

Okta
Google Workspace
Microsoft identity services

Because SAML integrations can be complex, many SaaS companies rely on platforms like SSOJet or WorkOS to simplify implementation.

OAuth 2.0

OAuth 2.0 is an authorization framework.

It allows applications to access resources on behalf of a user without sharing passwords.

OAuth is commonly used for:

API access
third-party integrations
delegated permissions

For example, when a SaaS application asks to access a user's Google Drive files, it typically uses OAuth authorization.

OAuth does not authenticate users directly. Instead, it provides access tokens that allow applications to access specific resources.

OpenID Connect (OIDC)

OpenID Connect is an authentication layer built on top of OAuth 2.0.

OIDC allows applications to verify a user’s identity.

Unlike OAuth, which focuses on authorization, OpenID Connect provides authentication information.

OIDC is widely used for modern applications because it supports:

Mobile Applications
Web Applications
API-Based Authentication

Many modern authenticati

Why Language Schools Should Prioritize Cybersecurity: A Passwordless Approach

Mon, 27 Apr 2026 09:12:54 +0000

As language schools use more digital tools, they face bigger risks from cyberattacks. Hackers often target schools because of the valuable personal data they hold. Traditional passwords are not strong enough to protect this information and can be easily hacked. A better solution is passwordless authentication.

In this article, we will explore why language schools should prioritize cybersecurity and how adopting passwordless authentication can protect sensitive information while improving user experience.

The Rising Threats to Language School Security

Language schools face a variety of cybersecurity risks, including data breaches, phishing attacks, and the theft of sensitive student information. Hackers target educational platforms because they hold valuable personal data, such as student records, payment details, and communication histories.

Unfortunately, many schools have weak security systems that make them easy targets. For example, a 2020 report found that educational institutions were among the top sectors targeted by cyberattacks, with over 1,200 cybersecurity incidents reported in the U.S. alone.

These attacks not only threaten student privacy but also damage the reputation and trust that language schools have built. With the rise in cyberattacks, it’s crucial for schools to strengthen their security measures before it’s too late.

Why Passwords Aren’t Enough for Language Schools

For years, passwords have been the standard way to secure online accounts, but they are no longer enough to protect against modern cyber threats. Hackers can easily guess or steal passwords through techniques like phishing or brute force attacks, leading to data breaches and identity theft. This makes relying on passwords a risky choice for language schools. Common challenges with traditional password systems include:

Password fatigue: Users often forget complex passwords, leading them to reuse simple ones across different accounts.
Weak password practices: Many individuals choose easily guessable passwords, like “123456” or “password,” which are highly vulnerable to attack.
Security loopholes: When passwords are reused or not updated regularly, they create gaps in security that hackers can exploit.

What Is Passwordless Authentication and How Does It Work?

Passwordless authentication is a secure login method that eliminates the need for traditional passwords. Instead, users authenticate through alternative methods, such as:

Magic links: A one-time link sent to the user’s email to grant access.
One-time passwords (OTPs): Temporary codes sent via email, SMS, or apps like WhatsApp.
Biometrics: Authentication through fingerprints, facial recognition, or other physical identifiers.

The key benefits of passwordless systems include:

Improved security: Without passwords, there's less risk of phishing or password theft.
Reduced login friction: Users don't have to remember or type passwords, making access faster and easier.
Better user experience: A more secure login process leads to higher user satisfaction.

Modern EdTech platforms, especially those offering multilingual learning, must balance ease of access with strong security. Whether you're building a custom LMS or integrating with easy to use language teacher software, implementing passwordless authentication ensures students and instructors can log in securely without friction.

Endnote

Language schools must prioritize cybersecurity to protect sensitive data. Traditional passwords are no longer enough, leaving schools vulnerable to attacks. Adopting passwordless authentication enhances security, reduces login friction, and improves the user experience. By integrating solutions like MojoAuth, language schools can safeguard their platforms and ensure a safer and efficient learning environment.

7 Enterprise Infrastructure Tools That Eliminate Months of Engineering Work

Sun, 26 Apr 2026 03:44:00 +0000

Engineering teams lose thousands of hours annually building infrastructure that already exists as battle-tested platforms. Authentication systems, AI security layers, internal developer portals, and database management consume months of development cycles that could go toward shipping product features.

This guide covers seven enterprise infrastructure tools that eliminate this engineering toil. Each tool addresses a specific infrastructure bottleneck, with verified pricing and deployment timelines based on current market data.

Quick Comparison: All 7 Tools at a Glance

Tool	Category	Free Tier	Paid From	Best For
MojoAuth	Passwordless Auth	25K MAUs	$50/month	B2C/B2B apps needing SSO
Gopher MCP	AI/MCP Security	1K tool calls	$179/month	AI agent deployments
Port.io	Developer Portal	15 seats	Custom	Platform engineering
Pulumi	Infrastructure as Code	Individual	$0.0005/credit	Multi-cloud IaC
Retool	Internal Tools	5 users	$12/user/mo	Admin panels, dashboards
LaunchDarkly	Feature Flags	Developer tier	$10/conn/mo	Progressive rollouts
Neon	Serverless Postgres	100 CU-hours	$5/month	Dev/test databases

1. MojoAuth: Passwordless Authentication Platform

Website: mojoauth.com

What it does: MojoAuth provides a unified API for passwordless authentication methods including Passkeys, Magic Links, OTPs (Email, SMS, WhatsApp), and enterprise SSO. It replaces months of custom authentication development with production-ready infrastructure that integrates in hours.

Key Features

Multiple authentication methods: Passkeys/WebAuthn, Magic Links, Email OTP, SMS OTP, WhatsApp OTP, TOTP/HOTP, and Social Login through a single unified API.
Enterprise SSO integration: SAML 2.0 and OIDC support for connecting to corporate identity providers including Okta, Azure AD, and Google Workspace.
Multi-factor authentication: Layer additional security with SMS, TOTP, or push notifications without rebuilding authentication flows.
Developer SDKs: Production-ready libraries for JavaScript/Node.js, Python, Go, .NET, and React with comprehensive documentation.
Self-enrollment and recovery: Users manage their own passwordless credentials without requiring support intervention.

Pricing (March 2026)

Free Plan: Up to 25,000 Monthly Active Users. Includes Email OTP, Magic Links, Social Login, and basic features.
Business Pro: Starting at $50/month. Scales to 500,000 MAUs at approximately $1,700/month. Includes all authentication methods, enterprise SSO, custom branding, and priority support.
Enterprise: Custom pricing. Includes dedicated infrastructure, SLA guarantees, and compliance certifications.

Engineering Time Saved

Building a secure, production-ready authentication system typically requires 3 to 6 months of engineering time. This includes handling token management, rate limiting, account recovery flows, and staying current with evolving security threats. MojoAuth claims integration in under a day with up to 75% faster time-to-market compared to building in-house. The platform reports 99.9999% uptime SLA and claims to reduce support tickets related to authentication by 80%.

2. Gopher MCP: AI Agent Security Gateway

Website: gopher.security

What it does: Gopher MCP provides enterprise-grade security infrastructure for Model Context Protocol (MCP) deployments. As AI agents gain access to production databases, APIs, and internal tools, Gopher acts as a security layer that inspects every tool call and enforces granular access policies.

Key Features

4D Security Framework: Deep inspection and threat detection, context-aware access control, granular policy enforcement, and post-quantum end-to-end encryption.
MCP threat protection: Defends against tool poisoning, puppet attacks, prompt injection, and malicious external resource loading.
API schema to MCP server: Upload Swagger, Postman, or OpenAPI schemas to deploy secure MCP servers in minutes.
Post-quantum encryption: P2P connections use quantum-resistant cryptographic algorithms to protect against both current and future threats.
Compliance support: Built-in audit logging and policy controls for SOC 2, GDPR, and HIPAA requirements.

Pricing (March 2026)

Free Plan: 1 MCP server, 1,000 tool calls/month, 5GB data transfer, community support.
Starter: $199/month ($179/month annual). 3 MCP servers, 1M tool calls/month, 5TB data transfer, multi-environment support.
Business: $999/month ($899/month annual). 10 MCP servers, 5M tool calls/month, 25TB data transfer, advanced IAM, SSO, and compliance reports.
Enterprise: Custom pricing. Unlimited servers, dedicated infrastructure, phone support, and custom integrations.

Engineering Time Saved

The MCP authorization specification has evolved rapidly through 2025 with major revisions adding OAuth 2.1, Cross App Access protocols, and machine-to-machine authentication. Building spec-compliant MCP authentication in-house typically requires 6 to 12 weeks of dedicated development. Gopher claims deployment in under 30 minutes with the platform handling ongoing spec compliance updates automatically.

3. Port.io: Internal Developer Platform

Website: port.io

What it does: Port.io is an internal developer portal that provides a unified view of your software catalog, self-service infrastructure provisioning, and developer experience scorecards. It replaces the fragmented tooling that forces developers to context-switch between AWS console, Datadog, PagerDuty, and dozens of other platforms.

Key Features

Dynamic software catalog: Define custom blueprints that model your specific SDLC, with relationships between services, teams, and resources.
Self-service actions: Developers provision infrastructure, create environments, and perform day-2 operations without filing tickets.
Scorecards and standards: Define quality, maturity, and production readiness standards with automated compliance tracking.
Workflow automation: Long-running and asynchronous actions with TTL support and run logs visible to developers.
Integrations: Native connectors for Terraform, ArgoCD, Kubernetes, GitHub, Datadog, PagerDuty, and most enterprise tooling.

Pricing (March 2026)

Free Plan: 15 seats, 10,000 entities, 500 automation runs/month. No time limit.
Paid Plans: Custom pricing based on team size and feature requirements. Contact sales for quotes.
Enterprise: Flexible deployment options including dedicated tenancy and Private Link connectivity.

Engineering Time Saved

Port.io reports customers reducing environment provisioning time from 30 minutes to 30 seconds. According to their State of Internal Developer Portals report, 75% of developers lose 6 to 15 hours weekly to tool sprawl. For a team of 50 engineers, this translates to nearly $1 million in lost productivity annually. Port raised $100M in December 2025 at an $800M valuation, signaling strong enterprise adoption.

4. Pulumi: Infrastructure as Code in Real Languages

Website: pulumi.com

What it does: Pulumi lets engineering teams define cloud infrastructure using TypeScript, Python, Go, C#, Java, or YAML instead of domain-specific languages. This means loops, conditions, functions, unit tests, and package managers work natively with infrastructure code.

Key Features

Real programming languages: Write infrastructure in TypeScript, Python, Go, C#, Java, or YAML with full IDE support, type checking, and debugging.
Pulumi Neo AI agent: Generate infrastructure from natural language requirements, review PRs, and debug deployments with organizational context.
120+ cloud providers: Deploy to AWS, Azure, Google Cloud, Kubernetes, and over 120 providers through a unified model.
Policy as code: CrossGuard lets you define security, compliance, and cost controls that run during previews and updates.
Secrets management: Pulumi ESC provides a single interface for all secrets with connections to HashiCorp Vault, AWS Secrets Manager, and Azure Key Vault.

Pricing (March 2026)

Individual (Free): Unlimited updates, automatic state management, and core features. Free forever for individuals.
Team: $0.0005 per Pulumi Credit (one resource managed for one hour). Includes staging environments and release management.
Enterprise: Starting at $32,850/year via AWS Marketplace. SAML SSO, self-hosted options, and source control integrations.
Business Critical: Starting at $50,000/year via Azure Marketplace. 150 concurrent deployments and volume pricing.

Engineering Time Saved

Werner Enterprises reported reducing provisioning time from 3 days to 4 hours using Pulumi. The platform claims one organization expanded infrastructure contributors from 1-2 people to over 40 active engineers because developers could use familiar programming languages instead of learning specialized DSLs like HCL.

5. Retool: Internal Tools Development Platform

Website: retool.com

What it does: Retool combines drag-and-drop UI building with AI assistance to create internal tools such as admin panels, dashboards, and workflow apps. It connects to databases and APIs natively, eliminating the need to build CRUD interfaces from scratch.

Key Features

100+ pre-built components: Tables, forms, charts, maps, and calendars that connect to data sources with minimal configuration.
Native database connectors: Direct connections to PostgreSQL, MySQL, MongoDB, Snowflake, and 40+ other data sources with SSH tunneling and SSL support.
AI-powered app building: Generate apps from prompts, then customize with code or visual editing.
Workflows and automation: Build automated processes with scheduling, webhooks, and conditional logic.
Mobile apps: Build native iOS and Android apps alongside web applications from the same platform.

Pricing (March 2026)

Free: 5 users, unlimited apps, 500 workflow runs/month, 5GB storage.
Team: $12/month per standard user, $7/month per end user. Includes staging environments and version history.
Business: $65/month per standard user, $18/month per end user. Adds audit logging, unlimited environments, and embedded apps.
Enterprise: Custom pricing. SAML/OIDC SSO, self-hosted deployment, custom SLAs.

Engineering Time Saved

Retool claims teams can build internal tools 10x faster than traditional development. Used by Amazon, DoorDash, OpenAI, and Mercedes-Benz for mission-critical internal applications. One customer reported building a complete dashboard with 10 data sources in 24 hours. The platform is particularly effective for replacing Google Sheets or legacy internal tools that have become unstable.

6. LaunchDarkly: Feature Flag Management

Website: launchdarkly.com

What it does: LaunchDarkly provides feature flags that act as on/off switches for features in production. Teams can deploy code continuously while controlling exactly who sees new features through gradual rollouts, A/B tests, and instant kill switches.

Key Features

Feature flags: Toggle features on or off for specific user segments without redeploying code.
Progressive rollouts: Gradually expose features to increasing percentages of users while monitoring for issues.
Experimentation: Run A/B tests and funnel optimization experiments with statistical analysis.
Release Guardian: Monitor critical flag changes in release pipelines and automatically detect regressions.
Mobile Lifecycle Assistant: Deliver personalized mobile experiences and fix bugs without waiting for app store review cycles.

Pricing (March 2026)

Developer (Free): 1 project, 3 environments. Feature flagging for individual projects.
Foundation: $10/month per service connection (annual) or $12/month (monthly). Plus $10 per 1,000 client-side MAUs.
Enterprise: Custom pricing. Typically $20,000 to $120,000/year depending on scale and feature requirements.

Engineering Time Saved

LaunchDarkly enables instant rollbacks when issues are detected. Instead of a full deployment rollback taking 15 to 30 minutes, a feature flag toggle takes seconds. The platform is trusted by over 5,500 customers. Users report that the ability to decouple deployment from release fundamentally changes how teams ship software, allowing continuous integration without continuous exposure to users until features are ready.

7. Neon: Serverless PostgreSQL

Website: neon.tech

What it does: Neon provides serverless PostgreSQL that separates compute from storage, enabling instant database branching, scale-to-zero for idle databases, and automatic scaling based on actual usage. It eliminates the operational overhead of managing database infrastructure.

Key Features

Database branching: Create instant copy-on-write branches for development, testing, and CI/CD pipelines without duplicating data.
Scale to zero: Databases automatically suspend after inactivity (5 minutes default), eliminating charges for idle resources.
Autoscaling compute: Automatically scale between minimum and maximum compute units based on query load.
Point-in-time restore: Instant recovery to any point in time within the configured retention window.
Full PostgreSQL compatibility: Standard Postgres with all extensions, no proprietary modifications.

Pricing (March 2026)

Following Databricks acquisition in May 2025, Neon reduced compute costs 15 to 25% and storage from $1.75 to $0.35/GB-month.

Free: 100 CU-hours per project (doubled from 50 in October 2025), 0.5GB per project, up to 100 projects.
Launch: $5/month minimum. $0.106 per CU-hour, $0.35 per GB-month storage. Up to 16 vCPU and 64GB RAM.
Scale: $700/month base. $0.222 per CU-hour, includes 1,000 CU-hours and 500GB storage. Up to 56 vCPU and 224GB RAM.

Engineering Time Saved

Database provisioning traditionally requires DevOps involvement for each new environment. Neon branches create isolated database copies in seconds using copy-on-write technology. For a multi-tenant SaaS with 100 customer databases, one analysis showed Neon costing approximately $4,380/month compared to $9,985/month for equivalent Azure Database for PostgreSQL Flexible Server instances. The serverless architecture eliminates infrastructure management overhead entirely.

Frequently Asked Questions

How do I decide between building infrastructure in-house versus buying?

Build in-house when the component is a core differentiator for your product. Buy when the component is commodity infrastructure that every company in your industry needs. Authentication, feature flags, internal tooling, and database management are rarely competitive differentiators. The engineering time spent building these could go toward features that actually distinguish your product.

What is the typical ROI calculation for enterprise infrastructure tools?

Calculate the fully-loaded cost of engineering time for the alternative. If building a passwordless authentication system requires 4 months of senior engineer time at $200,000/year fully loaded, that represents approximately $67,000 in engineering cost alone. Compare this to annual subscription costs. Most infrastructure tools pay for themselves within the first quarter through avoided engineering time.

Do third-party infrastructure tools create vendor lock-in risks?

Lock-in risk varies by tool category. Authentication providers using standard protocols (SAML, OIDC) offer relatively easy migration paths. Feature flag platforms have more switching costs since flags become embedded throughout your codebase. Infrastructure as code tools like Pulumi provide escape hatches through code generation and multi-provider support. Evaluate migration complexity during vendor selection.

How do these tools affect compliance requirements like SOC 2 and HIPAA?

Enterprise infrastructure tools often simplify compliance by providing pre-built audit logging, access controls, and encryption that would otherwise require custom implementation. When you build in-house, your team bears full responsibility for security and compliance of that code. With certified vendors, you inherit their compliance posture and can reference their certifications in your own security assessments.

What is the best way to evaluate multiple tools in the same category?

Passkeys vs Bots: Do They Really Solve the Human Verification Problem?

Sat, 25 Apr 2026 06:55:07 +0000

Passkeys authenticate users securely, but they do not prove a user is human. Passkeys replace passwords with device-bound cryptographic authentication. They prevent phishing, credential theft, and password reuse attacks.

However, passkeys only verify identity at login, not behavior after login. A bot can still operate inside a valid authenticated session. Automated browsers, scripts, and AI agents can interact with systems after authentication succeeds.

Passkeys solve authentication problems, not human verification problems.
Human verification requires analyzing behavior, context, and request patterns.

Modern security therefore separates two different questions:

Who logged in? → authentication
Is this activity human? → bot detection

Passkeys answer the first question extremely well. They do not answer the second question.

That distinction is critical for modern applications facing automated attacks. Bots today perform actions such as scraping APIs, creating fake accounts, and automating purchases. Many of these actions happen after authentication, not before it.

This means that even a system protected with passkeys can still experience bot abuse.

To fully protect modern applications, security must combine multiple layers:

Strong authentication (passkeys)
Bot detection systems
Behavioral analysis
Runtime identity verification

Understanding where passkeys help—and where they do not—is essential for building secure systems.

2. Quick TL;DR

Passkeys replace passwords with device-bound authentication.
Passkeys prevent phishing and credential theft attacks.
Passkeys verify identity but do not verify human behavior.
Bots can operate inside authenticated sessions.
Authentication does not prove human intent.
CAPTCHA was originally designed to detect bots.
Modern bots can solve or bypass many CAPTCHA challenges.
Bot detection relies on behavioral and device signals.
Passkeys improve authentication security but not bot detection.
Modern security requires authentication plus runtime verification.

3. The Core Question: Do Passkeys Prove You Are Human?

The short answer is no. Passkeys prove that a user controls a device credential. They do not prove that the actor using that device is human.

Passkeys verify identity ownership, not human intent.
Human verification and authentication are fundamentally different security goals.

Many developers confuse these two concepts because both appear during login flows. However, they solve different problems in system security.

Authentication vs Human Verification

Authentication answers one specific question:

Who is the user?

Human verification answers a different question:

Is this activity being performed by a human or a bot?

These two goals require completely different technologies.

Security Goal	Purpose	Example Technology
Authentication	Verify user identity	Passwords, Passkeys, OAuth
Authorization	Control resource access	RBAC, Access policies
Human Verification	Detect automated behavior	CAPTCHA, Behavior analysis

Authentication confirms identity credentials.
Human verification analyzes interaction behavior.

Authentication proves identity.
Human verification proves intent.

Identity vs Intent

Passkeys solve the identity problem extremely well. They replace passwords with cryptographic authentication tied to a device.

When a user signs in with a passkey:

The device proves ownership of a private key
The server verifies the cryptographic signature
The user is authenticated successfully

At that moment, the system knows:

A valid credential was used.

However, the system does not know:

Whether the interaction is automated
Whether a bot controls the browser
Whether an AI agent triggered the action

Passkeys prove device ownership, not human presence.

Why This Distinction Matters

Modern bots rarely try to guess passwords anymore. Instead, they operate through automated browsers or scripts that interact with websites exactly like real users.

Examples include:

automated account creation
ticket scalping bots
ecommerce checkout bots
API scraping bots

These bots can operate after authentication succeeds.

Most automated abuse happens inside authenticated sessions.

This means a system using passkeys can still experience bot-driven activity.

A Simple Example

Imagine a user logs into a website using a passkey.

The authentication process is secure and successful.

Now consider two scenarios:

A real human navigates the site normally.
A bot script controls the browser and performs automated actions.

From the authentication system's perspective, both sessions look valid.

The passkey successfully verified identity in both cases.

Authentication alone cannot distinguish humans from automated behavior.

The Key Insight

Passkeys are a major improvement for authentication security. They eliminate passwords and prevent many common attacks.

However, they do not replace bot detection systems.

Passkeys solve authentication.
Human verification requires additional security layers.

Understanding this difference is essential for building secure modern applications.

4. What Problem Passkeys Actually Solve

Passkeys were designed to solve the weaknesses of password-based authentication. They replace passwords with device-bound cryptographic credentials that are resistant to phishing and credential theft.

Passkeys solve authentication security problems, not bot detection problems.
They eliminate passwords while improving login success and security.

Passkeys are based on the FIDO and WebAuthn standards. These standards use public-key cryptography instead of shared secrets like passwords.

When a user registers a passkey:

The device generates a public-private key pair.
The private key stays securely on the user’s device.
The public key is stored on the server.

During login, the server sends a challenge that the device signs with the private key. The server verifies the signature using the stored public key.

The private key never leaves the user’s device.

Password Elimination

Passwords have been the weakest link in authentication for decades.

Common password problems include:

password reuse across services
weak passwords chosen by users
password database breaches
phishing attacks stealing credentials

Microsoft reports that more than 99% of identity attacks involve passwords.

Passkeys remove passwords entirely from the authentication process.

No password means nothing for attackers to steal or guess.

Phishing Resistance

Traditional phishing attacks trick users into entering credentials on fake websites.

Passkeys prevent this because authentication is tied to the website’s domain.

If a phishing site tries to trigger passkey authentication:

The browser detects the domain mismatch.
The passkey will not authenticate.

Passkeys are inherently phishing resistant.

This makes them far more secure than passwords, SMS OTPs, or many MFA systems.

Device-Bound Authentication

Passkeys are stored securely on the user’s device.

They rely on hardware-backed security features such as:

secure enclaves on smartphones
trusted platform modules (TPM) on computers
biometric authentication like Face ID or fingerprint

The authentication process requires the user to unlock the device.

This ensures the device owner is present during login.

Passkeys combine device possession with biometric verification.

Improved User Experience

Passwords introduce friction during login.

Users often forget passwords, reset them, or struggle with password policies.

Passkeys simplify login significantly.

Typical passkey login flow:

User enters username or email.
Device prompts biometric verification.
Authentication completes instantly.

Microsoft reports that passwordless authentication achieves 95% login success rates, compared to much lower success rates for password logins.

Passkeys improve both security and usability.

Protection Against Credential Theft

Credential stuffing attacks rely on leaked password databases.

Attackers reuse stolen passwords across multiple services.

Passkeys eliminate this attack vector because:

There is no shared secret to reuse.
Each passkey is unique to a specific domain.

Even if one service is compromised, the passkey cannot be reused elsewhere.

Passkeys eliminate credential reuse attacks entirely.

5. What Problem Passkeys Do NOT Solve

Passkeys dramatically improve authentication security. They prevent phishing, password theft, and credential reuse. However, they do not stop automated behavior or bots operating after login.

Passkeys verify identity credentials, not user behavior.
Bots can still interact with systems after authentication succeeds.

This distinction is important because most modern automated attacks no longer focus on breaking authentication. Instead, they target the application layer after login.

Passkeys Do Not Detect Automated Browsers

Modern bots often run inside automated browsers that behave like real users.

These tools include:

Selenium
Puppeteer
Playwright
headless Chrome

These automated browsers can load web pages, click buttons, submit forms, and interact with applications exactly like a human user.

Once authentication succeeds, the system sees only normal requests.

Passkeys cannot distinguish between human actions and automated browser actions.

Passkeys Do Not Detect Scripted Sessions

Many automated attacks occur inside valid authenticated sessions.

Examples include:

automated product purchases
fake account activity
automated social media posting
scraping user data

These actions happen after authentication has already succeeded.

From the server’s perspective, the requests are coming from a valid session.

Passkeys do not evaluate how a session is being used.

Passkeys Do Not Detect API Automation

Modern applications rely heavily on APIs.

Bots often interact directly with APIs instead of web interfaces.

For example:

automated scraping tools
mobile app reverse engineering
automated account creation
bulk data extraction

If the API accepts valid tokens or session cookies, the requests may look legitimate.

Passkeys secure login but do not analyze API behavior.

Passkeys Do Not Detect AI Agents

The rise of AI-driven automation introduces a new category of automated activity.

AI agents can:

navigate websites
interact with forms
simulate user actions
trigger workflows automatically

These agents may operate inside authenticated sessions.

Because authentication was valid, the system cannot easily distinguish between human actions and automated actions.

Passkeys authenticate the device, not the actor controlling it.

Passkeys Do Not Analyze Behavior

Human verification systems often rely on behavior signals.

These signals may include:

mouse movement patterns
typing speed
navigation patterns
request timing

Passkeys do not analyze these signals.

They only verify the cryptographic credential during login.

Passkeys do not evaluate behavioral patterns.

Passkeys Do Not Detect Intent

A valid login does not guarantee safe behavior.

A user may log in successfully and then perform malicious actions.

Examples include:

scraping competitor data
abusing APIs
automating high-volume transactions
launching spam campaigns

Authentication confirms identity, but it does not validate intent.

Intent can only be inferred through behavioral analysis.

The Key Insight

Passkeys solve one specific problem extremely well: secure authentication.

They eliminate passwords and significantly reduce account takeover attacks.

However, modern systems face additional challenges that occur after authentication.

Bots, automated scripts, and AI agents often operate inside valid sessions.

Passkeys secure the login event, not the entire user session.

To detect automation, systems need additional mechanisms such as:

bot detection systems
behavioral analysis
device fingerprinting
runtime identity evaluation

Understanding these limitations is essential when designing modern security architectures.

6. How Bot Detection Actually Works

Bot detection systems are designed to distinguish automated traffic from human users. Unlike authentication systems, bot detection focuses on analyzing behavior, patterns, and environmental signals.

Bot detection identifies automated behavior, not identity credentials.
Human verification depends on analyzing how a system is used.

Modern bot detection systems combine multiple techniques to detect suspicious activity.

CAPTCHA Challenges

CAPTCHA systems were originally designed to separate humans from automated scripts. The name CAPTCHA stands for Completely Automated Public Turing test to tell Computers and Humans Apart.

CAPTCHA systems challenge users with tasks that are assumed to be easy for humans but difficult for machines.

Examples include:

selecting images with traffic lights
typing distorted characters
solving puzzles

These tests attempt to ensure that the actor interacting with the system is human.

CAPTCHA systems challenge interaction rather than identity.

Behavioral Analysis

Behavioral analysis examines how users interact with a website or application.

Human users behave differently from automated scripts.

Common behavioral signals include:

mouse movement patterns
typing speed and rhythm
navigation flow across pages
click timing and interaction speed

Bots often generate extremely regular patterns that differ from human behavior.

Human behavior contains randomness that automated scripts struggle to replicate.

Behavioral analysis systems monitor activity throughout the session to detect anomalies.

Device Fingerprinting

Device fingerprinting identifies unique characteristics of a device and browser environment.

This technique collects signals such as:

browser type and version
operating system
screen resolution
installed fonts and plugins

These attributes can create a fingerprint that helps identify automated tools.

Bots often use headless browsers or simplified environments that differ from real user devices.

Device fingerprints help detect suspicious environments.

Rate Limiting

Rate limiting controls how frequently requests can be made to a system.

Bots often send large volumes of requests in short periods of time.

Rate limiting can prevent excessive traffic from automated sources.

Examples include:

limiting login attempts
restricting API request frequency
blocking repeated requests from the same IP address

Rate limiting reduces automated abuse by controlling request volume.

Network Reputation Analysis

Many bot detection systems analyze the reputation of IP addresses and networks.

Signals may include:</p

How to Implement Passwordless Authentication to Boost User Conversion

Thu, 23 Apr 2026 11:03:25 +0000

Passwordless authentication is already widely deployed across modern applications. It’s the single most effective tool you have to kill the friction that’s currently choking your user journey.Passwords create friction in signup and login experiences.Passwordless authentication removes shared secrets from the authentication process.

Think about the last time you signed up for a service. You’re ready to buy, you’re excited to use the product, and then—bam. You’re hit with a password requirement. Needs 12 characters, a special symbol, a blood sacrifice, and a partridge in a pear tree. You forget it five minutes later, hit the "forgot password" loop, and suddenly, you’re done. You’re gone.

By replacing that archaic, memory-heavy chore with cryptographic proof, you stop bleeding customers at the exact moment they’re ready to engage. Don’t take my word for it, the Passwordless Conversion Impact Report 2026 makes it clear: the faster the entry, the higher the lifetime value. Speed isn't just a luxury; it’s a conversion multiplier.

The Business Case: Is Passwordless Just About Security?

If you think this is purely an IT security play, you’re missing the point. Sure, ditching shared secrets helps you avoid the nightmares documented in the IBM Cost of Data Breach Report, but the real win happens on your P&L.

Let’s talk about your help desk. How much time and money does your team waste on "I forgot my password" tickets? It’s a massive, soul-crushing tax on your support operations. Switching to biometric or device-bound authentication effectively nukes that ticket category. Your team can finally focus on actual problems instead of playing the role of digital locksmiths.

Then there’s the conversion math. Every single field you force a user to fill out is a potential exit ramp. When you stop demanding they create, verify, and store yet another password, the cognitive load plummets. Users aren’t balancing the value of your app against the headache of managing another account. You turn the login process from a barrier into a feature.

Password-Based vs Passwordless Authentication

Feature	Password Authentication	Passwordless Authentication
Credential Type	Shared secret	Cryptographic key
Phishing Risk	High	Very low
Password Resets	Frequent	Rare
User Experience	Friction-heavy	Fast and seamless
Credential Theft Risk	High	Minimal

Demystifying the Tech: What Are Passkeys and FIDO2?

Passkeys are passwordless authentication credentials based on public-key cryptography.

Passkeys replace passwords with a cryptographic key pair:

a private key stored on the user’s device
a public key stored on the server

During login, the device signs a cryptographic challenge to prove identity.

Passkeys are resistant to phishing because the private key never leaves the user’s device. We’re moving away from "shared secrets"—the old model where both you and the user hold a copy of a password. In the old world, if your database gets hacked, the keys to the kingdom are gone. In a passwordless world, the secret never actually leaves the user’s device.

It sounds like magic, but it’s just math. It uses FIDO2 and WebAuthn standards—basically a high-tech digital handshake.

When a user signs up, their device creates a pair of keys: one public, one private. The private key stays locked in the device’s secure enclave, accessible only by a fingerprint or face scan. The public key goes to your server. When they come back, your server sends a "challenge," the device signs it, and your server checks the signature. No passwords. No phishing. No nonsense.

Learn more in our guide:
What are passkeys and how They Work

Benefits of Passwordless Authentication

Passwordless authentication improves both security and user experience.

Key benefits include:

Eliminating Password Reuse
Preventing Credential Phishing Attacks
Reducing Password Reset Support Tickets
Improving Login Conversion Rates
Simplifying Authentication Flows

Organizations adopting passwordless authentication often see measurable improvements in both security posture and customer experience.

How to Design a Frictionless Authentication Flow

Here is where most companies screw it up: they turn their login page into a science project.

If you want people to actually use this, keep it simple. It should feel like a native extension of the phone or laptop they already trust. Follow the best practices from the FIDO Alliance to keep your UI clean.

Avoid "the cliff." Don’t make the user choose between a password they know and some mysterious, scary biometric prompt. Use progressive disclosure. If they’re on a modern device, offer the passkey as the obvious, "recommended" path. Use human language: "Use FaceID to sign in" beats "Authenticate via WebAuthn assertion" every single time.

And for heaven’s sake, give them feedback. If a biometric scan fails, don’t just throw a cryptic error code. Offer a secondary way in—like a magic link—without making them refresh the page or restart the whole process.

The Migration Roadmap: Moving Millions Without Breaking Trust

Don't panic—you don't have to delete your password database overnight. You need a hybrid approach. This is a standard practice in modern CIAM architecture because it keeps the lights on for your legacy users while you transition.

Keep both methods running for a while. When a user logs in the old way, show a small, non-intrusive overlay: "Want to enable one-tap sign-in for next time?"

Once they click yes, you register their device. Over a few months, your password-reliant user base will shrink as your passkey base grows. This phased approach lets you catch bugs, refine your fallback protocols, and harden your security without ever locking a loyal user out of their account.

Is Passwordless Authentication NIST Compliant?

Yes. Passkey-based authentication satisfies phishing-resistant authentication requirements under NIST SP 800-63 guidelines.

Passkeys meet AAL2 authentication requirements because they:

resist phishing attacks
use cryptographic authentication
bind credentials to devices

This makes passkeys suitable for high-security authentication environments.

Staying Compliant: Meeting NIST SP 800-63-4 Standards

If you’re working with enterprise clients, compliance isn't optional. The NIST SP 800-63-4 guidelines are the gold standard now.

Passkeys hit the AAL2 (Authenticator Assurance Level 2) requirements for phishing resistance perfectly. Think about SMS-based MFA—it’s easy to intercept. FIDO2 passkeys are locked to your website’s origin. Even if a user visits a fake, malicious version of your site, the browser won’t provide the cryptographic signature because the domain doesn’t match. That level of security is exactly what enterprise procurement teams are looking for.

Passwordless Readiness Checklist: Is Your Stack Prepared?

Before you dive in, run a quick audit of your setup:

Browser Compatibility: Are you using the latest WebAuthn APIs? Most modern browsers are great, but make sure your frontend handles legacy browsers gracefully.
Database Compatibility: Can your schema store public keys? You’re moving away from salted hashes to storing public key associations. Make sure your backend team is ready for that shift.
Account Recovery: This is the big one. If someone loses their phone, how do they get back in? You need a rock-solid, identity-verified recovery flow—like a backup email or a secondary device—that doesn't just fall back to a weak, phishable password.

Overcoming the "Cold Start" Problem

The biggest hurdle is getting users to set up that first passkey. People are creatures of habit. They’ll keep typing that password until you give them a damn good reason to stop.

Stop talking about "cryptographic tokens" in your UI. Nobody cares. Sell the benefit. Frame the switch as a massive time-saver. Prompt them during high-intent moments, like right after they log in or finish a checkout. "Speed up your next checkout by 5 seconds with TouchID" is a value proposition that hits home.

When you frame the transition as a premium feature that makes their life easier, you stop being a tech company forcing an update and start being a product company providing a better experience.

Frequently Asked Questions

Will users find passwordless logins confusing?

Not at all. Users are already conditioned by the ubiquity of FaceID and TouchID on their mobile devices. The muscle memory for "glance to unlock" is already there. When you align your web authentication with the native biometric prompts users see every day, the conversion rate typically outperforms traditional password entry.

What happens if a user loses their device?

Device loss is a reality, which is why multi-device support is essential. Modern passkey providers allow users to sync their credentials across their ecosystem (e.g., iCloud or Google Password Manager). For edge cases, your recovery protocol should rely on verified secondary channels, such as hardware security keys or a pre-verified recovery email, ensuring that the user never loses access to their account.

Is passwordless authentication compatible with older browsers?

While FIDO2/WebAuthn is supported by all major modern browsers, you should implement a fallback strategy for edge cases. A "magic link" sent to the user's registered email address serves as a perfect, secure bridge for users on legacy systems who cannot utilize biometric passkeys.

How do I migrate my existing user database to passwordless?

The most effective strategy is the "Hybrid Login" transition. You keep your existing password database active but implement a prompt that triggers during a successful login. Once the user authenticates via their old password, you ask them to register their device as a passkey. Over time, your reliance on the password database wanes until you can eventually deprecate it entirely.

Does passwordless authentication increase or decrease security?

It significantly increases security. By shifting from shared secrets—which can be stolen, phished, or guessed—to cryptographic proof of possession, you effectively neutralize the primary attack vectors of the modern web: credential stuffing and phishing. When the key never leaves the user’s device, the server has nothing for an attacker to steal.

Final Thoughts

Passwords were designed for an earlier internet.

Modern applications require authentication systems that prioritize both security and usability.

Passwordless authentication replaces shared secrets with cryptographic identity verification.

By adopting passkeys and passwordless login flows, organizations can improve conversion rates while reducing credential-based attacks.

Passwordless authentication is not just a security upgrade.
It is a fundamental improvement to the user authentication experience.

Enhancing User Experience with Passwordless Authentication: A Design-First Approach

Wed, 22 Apr 2026 21:13:01 +0000

Passwords were meant to protect users. Instead, they’ve become one of the biggest sources of friction in digital products.

As explained by the FIDO Alliance, whose survey of 10,000 users across 10 countries found that respondents manually entered passwords nearly 1,639 times per year - and nearly 60% admitted abandoning an online service entirely in the last month because they couldn't remember their password - password fatigue isn’t rare. It’s routine.

That’s not just a security issue. It’s a user experience problem. A full-service UI/UX design agency looks at passwordless authentication not as a technical upgrade, but as a behavior redesign.

Why Passwords Create Friction

Passwords interrupt flow. You’re ready to complete a task. You click login. You hesitate. Was it uppercase first? Did you add a symbol? Do you need to reset it again?

That pause matters - it breaks momentum and creates doubt. And sometimes it ends the journey entirely. When users abandon products because they can’t remember credentials, the issue isn’t complexity. It’s friction layered into the experience.

Good design removes friction; it doesn’t defend it.

Passwordless Authentication Starts with Context

Biometrics, passkeys, device-based authentication - the tools are already here.

The real question is how they’re introduced. A full-service UI/UX design agency doesn’t just remove the password field and call it progress. It studies how users access the product. Mobile or desktop? Frequent use or occasional? High-stakes access or casual browsing?

Context shapes the solution. Face ID feels natural on a phone. A one-time secure link might work better in a desktop workflow. The interface should adapt to how people already behave.

Trust Has to Be Designed

When you remove something familiar, even if it’s annoying, users need reassurance.

If a system logs someone in instantly, they should understand why. Clear messaging, confirmation states, and visible fallback options build confidence.

You can see this kind of structured clarity in interface explorations like this one:
https://www.pinterest.com/pin/686024955782241025/

The layout is calm. Focused. It supports entry without stealing attention from the product itself. That’s the goal. Security should feel present, not overwhelming.

Reducing Abandonment Through Simplicity

The FIDO Alliance data shows how often password friction leads to abandonment. So the opportunity is obvious. Fewer steps. Fewer interruptions. Clear recovery paths. But simplicity isn’t just about fewer clicks. It’s about fewer decisions.

If users don’t need to think about login, they stay focused on why they came to the product in the first place. That’s where design makes a real difference.

Security and Experience Don’t Compete

There’s an old idea that stronger security means more complexity. That’s outdated.

Passwordless systems can improve protection while reducing effort. Device-bound credentials and biometric verification often reduce risk compared to reused passwords. But the shift needs guidance.

A UI/UX design agency ensures onboarding explains what’s happening. It ensures recovery flows are clear. It ensures edge cases - lost devices, new hardware, shared accounts - are handled calmly. Security should feel stable, not confusing.

Authentication Is Part of the Product, Not a Gate

Login is often treated as a barrier before the “real” product begins. That mindset is flawed. Authentication is the first experience users have. If it’s frustrating, everything after it feels harder.

A full-service UI/UX design agency integrates authentication into the broader journey. Onboarding, device changes, recovery, and session management all connect. Nothing feels patched together. When done well, authentication fades into the background. And that’s the point.

The Takeaway

Passwords are familiar, but familiarity isn’t the same as usability. The FIDO Alliance’s research makes it clear: repeated manual entry and forgotten credentials drive real abandonment. That’s lost trust and lost opportunity. Passwordless authentication works best when it’s designed around human behavior, not just security protocols.

When entry feels natural, users stay focused on value instead of barriers. And when friction disappears quietly, engagement improves without anyone having to think about why.

Building a Layered Security Stack: Identity, Network and Device Protection

Wed, 22 Apr 2026 05:02:59 +0000

Modern organizations use cloud platforms and remote work which helps improve productivity but it also increases cybersecurity risks and a single security solution is no longer enough to protect sensitive systems and data.

To reduce risk businesses now use a layered security stack that protects identities networks and devices and this approach creates many security layers so if one control fails other layers continue to protect the system.

Layer 1: Identity Security

Identity security is the first line of defense in modern cybersecurity and many cyberattacks start with stolen or compromised login details and stronger authentication helps make sure that only authorized users can access company resources.

Passwordless Authentication

Traditional passwords are often weak and easy targets for phishing attacks and passwordless authentication replaces passwords with stronger ways of verification.

Common passwordless authentication methods include:

Biometric authentication
Hardware security keys
Authentication apps
One time login codes

By removing passwords organizations reduce the risk of credential theft and also make the login process easier for users.

MFA

Multi Factor Authentication ( MFA ) adds an extra verification step during login and even if attackers get a password they cannot access the system without the second authentication step.

Common MFA verification methods include:

Password or PIN
One time codes sent to mobile devices
Authentication apps
Biometric verification

Using MFA greatly reduces the chance of unauthorized access.

SSO

Single Sign On ( SSO ) allows users to log in once and access many applications without entering login details again and this makes authentication easier and reduces password fatigue.

Key benefits of SSO include:

Simplified login experience
Centralized authentication management
Improved employee productivity
Stronger access control policies

When SSO is used with MFA it gives both convenience and stronger identity security.

Layer 2: Network Security Tools

Network security protects the data that moves between users devices and applications and as organizations depend more on remote work and cloud systems securing network access becomes very important.

Network layer protection usually includes VPN platforms and secure web gateways and SASE solutions and teams that research options often look at providers and review platforms such as Cisco AnyConnect Palo Alto GlobalProtect Zscaler as part of their evaluation process.

VPN Platforms

Tested Virtual Private Networks ( VPNs ) create encrypted tunnels between users and company networks and this encryption keeps sensitive data safe from being intercepted when employees access systems remotely.

Key advantages of VPN platforms include:

Encrypted communication channels
Secure remote access for employees
Protection when using public Wi Fi
Increased data privacy

VPNs remain an essential tool for remote workforce security.

Secure Web Gateways

Secure Web Gateways ( SWGs ) monitor and filter internet traffic to protect users from malicious websites and unsafe downloads.

Common capabilities include:

URL filtering and website blocking
Malware detection and prevention
Phishing protection
Web traffic monitoring

These tools help organizations enforce safe browsing policies and reduce exposure to online threats.

SASE

Secure Access Service Edge ( SASE ) combines networking and security services into one cloud based platform and this setup helps organizations manage security better in distributed environments.

SASE platforms typically integrate:

Secure web gateways
Firewall as a service
Cloud access security brokers
Zero Trust access controls

This allows companies to apply consistent security policies regardless of user location.

ZTNA

Zero Trust Network Access ZTNA follows the rule never trust always verify and instead of giving full network access users are checked every time they try to access an application.

ZTNA systems evaluate factors such as:

User identity
Device security status
Location of the request
Access permissions

This approach limits access to only the resources users need and reducing the risk of internal attacks.

Layer 3: Device Protection

Devices like laptops and smartphones and tablets often act as entry points to company systems and protecting these endpoints is an important part of a layered security strategy.

Endpoint Detection and Response ( EDR )

Endpoint Detection and Response tools watch device activity to find suspicious behavior or possible threats.

Key EDR features include:

Continuous threat monitoring
Malware detection
Automated incident response
Security alerts for IT teams

These tools help security teams detect and stop threats before they spread.

Mobile Device Management ( MDM )

Mobile Device Management solutions let organizations manage and keep mobile devices used for work secure.

Capabilities include:

Device encryption enforcement
Remote wipe for lost or stolen devices
App installation controls
Security configuration management

This ensures that company data remains protected on employee devices.

Patch and Update Management

Old software often has weaknesses that attackers can use and patch management systems make sure devices get updates and security fixes on time.

Patch management typically includes:

Automatic operating system updates
Application security patches
Vulnerability monitoring
Scheduled update deployment

Keeping software updated helps reduce security risks across the organization.

Conclusion

Building a layered security system is important for protecting modern digital environments and by combining identity security and network protection and device safeguards organizations can reduce cybersecurity risks significantly.

Many growing teams also evaluate SOC 2 compliance as part of your layered security posture, especially when identity controls, network protections, and endpoint safeguards must align with customer security expectations and audit readiness.

Technologies like passwordless authentication ,MFA, VPNs, SASE and endpoint protection work together to protect users and sensitive data and make security stronger across systems devices and networks

How AI Agents Are Transforming Identity Verification and Authentication Systems

Tue, 21 Apr 2026 02:20:04 +0000

Authentication systems are no longer simple gatekeepers that validate credentials and issue tokens. In modern digital ecosystems — especially SaaS and API-driven platforms — authentication operates within complex, distributed environments. Identity providers, OAuth flows, session tokens, device intelligence, and zero-trust policies all interact continuously.

As threat actors automate credential stuffing, phishing campaigns, and session hijacking attempts, static rule-based authentication models struggle to respond effectively. AI agents are emerging as a powerful layer within authentication stacks, introducing adaptive intelligence into identity verification and access control workflows.

From Rule-Based Access to Adaptive Risk Engines

Traditional authentication logic typically follows deterministic paths: validate credentials, check second factor, issue JWT or session token. Risk scoring, if present, often relies on predefined thresholds such as IP reputation or location mismatches.

AI agents replace static evaluation with contextual analysis. Instead of checking isolated conditions, they process multi-dimensional signals in real time:

Device fingerprint consistency
Behavioral biometrics (keystroke dynamics, interaction velocity)
Network reputation signals
Historical login timelines
Session navigation patterns

These signals feed into dynamic risk models that adjust authentication decisions based on probabilistic assessment rather than binary logic.

As organizations adopt AI-driven authentication systems, many evaluate specialized engineering partners capable of integrating adaptive risk engines into identity stacks. Teams assessing technical implementation pathways can explore more options here.

AI Agents as Risk Microservices in Authentication Architecture

In modern authentication stacks, AI agents often operate as dedicated risk evaluation microservices. During a login request, the authentication server communicates with the AI risk engine before issuing an access token. As these AI systems take on more automated decision-making tasks, concerns about AI job replacement are growing, particularly for roles focused on routine security monitoring and risk assessment. At the same time, the rise of AI systems is also creating new opportunities for individuals to earn training AI models by contributing to data labeling, behavioral analysis, and human-in-the-loop validation processes that improve authentication accuracy.

A simplified flow may look like this:

User submits credentials or initiates passwordless login.
Identity provider validates primary authentication factors.
Risk signals (device, IP, behavioral input) are sent to the AI agent.
The AI agent calculates a contextual risk score.
Based on risk level:
- Token is issued immediately,
- Step-up authentication is triggered, or
- Access is denied.

This architecture allows AI agents to influence authentication outcomes without disrupting existing OAuth or OIDC flows. The risk engine becomes an intelligent decision layer rather than a replacement for identity infrastructure.

Real-Time Token Issuance and Conditional Access

AI agents enhance token management by introducing conditional issuance logic. Instead of issuing JWTs solely based on credential validation, authentication systems can incorporate contextual intelligence into access decisions.

For example:

A known device in a consistent geolocation may receive long-lived tokens.
A suspicious login attempt may trigger short-lived tokens with limited scope.
High-risk activity may require additional verification before issuing refresh tokens.

This dynamic token lifecycle management strengthens access control without increasing friction for legitimate users.

Continuous Authentication and Session Monitoring

Authentication does not end once an access token is issued. Session hijacking and privilege escalation attacks frequently occur post-login.

AI agents support continuous authentication by monitoring session behavior in real time. Instead of relying only on token expiration or inactivity timeouts, systems analyze behavioral patterns throughout a session.

If an AI agent detects anomalies — such as sudden behavioral deviation, unusual API call patterns, or abnormal navigation flow — it can:

Invalidate session tokens
Force re-authentication
Limit access scope
Trigger backend security alerts

This proactive model enhances security posture without requiring constant user interaction.

Strengthening Passwordless and MFA Workflows

Passwordless authentication reduces reliance on shared secrets, but it does not eliminate identity risks. AI agents enhance passwordless systems by evaluating contextual trust signals surrounding each login attempt.

Even if biometric authentication or magic link validation succeeds, AI agents assess additional risk factors. If the device environment or behavior appears inconsistent, step-up verification can be enforced automatically.

Similarly, MFA systems become more intelligent when AI agents determine when additional factors are truly necessary. Low-risk sessions remain frictionless, while high-risk attempts receive additional scrutiny.

AI in Identity Verification and KYC Pipelines

Beyond login workflows, AI agents also transform identity verification processes such as onboarding and KYC checks.

Within verification pipelines, AI agents can orchestrate:

Document authenticity detection using deep learning
Face matching and liveness analysis
Cross-database identity validation
Behavioral consistency checks during submission

Rather than evaluating each validation step independently, AI agents correlate outputs into unified confidence scores. This orchestration reduces manual review load while increasing detection accuracy.

Zero-Trust and Context-Aware Policy Enforcement

Zero-trust security assumes that no request should be inherently trusted, regardless of origin. AI agents enhance zero-trust frameworks by continuously evaluating contextual signals across authentication and authorization layers.

This same challenge is explored in AI Agents and the Security Nightmare Nobody's Solving, which examines how identity, authorization, and trust models break when autonomous agents begin making security-sensitive decisions across distributed systems.

Within API-driven environments, AI agents can:

Adjust access policies dynamically
Restrict sensitive endpoints based on risk score
Enforce adaptive rate limiting
Modify authorization scopes in real time

This enables authentication systems to operate as living security layers rather than static gateways.

Model Governance and Compliance Considerations

Deploying AI agents within authentication systems introduces governance responsibilities. Risk scoring decisions must be explainable and auditable, particularly in regulated sectors.

Organizations should implement:

Model drift monitoring
Bias detection in behavioral analysis
Transparent logging of AI-driven access decisions
Secure storage of feature inputs
Regular retraining cycles

Authentication systems directly impact user access, making accountability essential.

The Future of Intelligent Identity Infrastructure

AI agents are transforming authentication from a static verification checkpoint into an adaptive, context-aware security ecosystem. By operating as real-time risk engines within OAuth and identity provider architectures, they enhance fraud detection, reduce friction, and support continuous session integrity.

As authentication systems grow more distributed and API-driven, intelligent risk evaluation will become a foundational component of identity infrastructure. Organizations that integrate AI agents thoughtfully — with strong architectural discipline and governance oversight — will be better positioned to defend against increasingly automated threats.

Deploying AI agents in identity pipelines is as much a culture challenge as a technical one. Organizations that integrate adaptive authentication successfully tend to invest equally in the human side, building organizational trust in AI-driven workflows that help teams understand when to override AI decisions and when to rely on them.

AI agents are not replacing authentication systems. They are making them smarter, more responsive, and better equipped for the realities of modern digital security.

How OTP Authentication Streamlines Service Delivery for HVAC Companies

Mon, 20 Apr 2026 11:50:01 +0000

Photo courtesy of Freepik

As HVAC businesses grow and expand into new areas, they need to find ways to manage more customers and staff. One of the biggest challenges is making sure that service delivery and payments are secure and efficient, especially when working with new customers in different locations.

A simple solution to this problem is one-time password (OTP) authentication. OTP authentication makes it easy to verify customers and payments quickly and securely that helps HVAC companies improve their overall service process.

In this article, we’ll explore how OTP authentication helps HVAC companies streamline service delivery by improving customer verification, appointment scheduling, payments, and service completion, all while keeping things secure and simple.

1. Simplified Customer Verification

OTP (One-Time Password) authentication replaces traditional login methods by sending a unique code to a customer’s phone or email, which they use to verify their identity instantly. For HVAC service appointments, customers can receive an OTP to confirm their identity, eliminating the need for passwords or lengthy forms.

2. Enhanced Service Appointment Scheduling

OTP authentication helps verify and confirm HVAC service appointments, ensuring both the customer and service provider are clear on the timing and details. When a customer schedules a service, they receive an OTP confirmation, which confirms the appointment and reduces the risk of any misunderstandings.

This process ensures that appointments are tracked accurately, leading to fewer scheduling errors and improved customer satisfaction. As you invest in marketing or HVAC SEO services to generate more leads, it’s essential to have a reliable system for booking appointments to avoid confusion and ensure a smooth customer experience.

3. Improved Payment and Transaction Security

OTP authentication adds a layer of security to payments and transactions, protecting HVAC businesses and their customers. When a payment is made, an OTP is sent to the customer's phone or email to verify the transaction, ensuring it’s legitimate. This reduces the risk of fraud or unauthorized charges.

Additionally, OTP can prevent fraud from service vendors by confirming that payments are processed correctly and only authorized transactions are completed. This enhances security, builds trust, and ensures a reliable payment system for HVAC companies and their clients.

4. Streamlined Service Completion Confirmation

OTP authentication simplifies service completion verification. After an HVAC service is completed, an OTP is sent to the customer’s phone or email to confirm the work was done. This ensures clear communication and prevents any disputes about the service, making the process quicker and more reliable.

5. Seamless Communication for Customer Support

OTP authentication streamlines customer support by ensuring secure communication. When a customer contacts the HVAC company for assistance, they can verify their identity through OTP, confirming they are the account holder. This prevents unauthorized access to support channels and ensures that customer queries are handled by the right team.

Endnote

OTP authentication enhances security and simplifies key processes for HVAC businesses. By streamlining customer verification, service confirmations, and payments, it improves efficiency and builds trust.

Adopting OTP ensures smoother operations, better customer experience, and strengthens the company's competitive edge in a growing market. It’s a valuable investment for long-term success.

# How Authentication Really Works (JWT vs Session vs OAuth)

Fri, 17 Apr 2026 06:14:22 +0000

Whenever you log in to a website…

You enter:

Email
Password

And suddenly…

You are “logged in”

But what actually happens behind the scenes?

How does the system remember you?

Let’s break it down simply

First: What is Authentication?

Authentication =

“Proving that you are who you say you are”

Example:

Login form
OTP verification
Google login

⚙️ Basic Flow (Before JWT / Session / OAuth)

User enters email + password
Server verifies credentials
Now server needs to “remember” the user

This is where things get interesting

1. Session-Based Authentication

How It Works

User logs in
Server creates a session
Stores session in database/memory
Sends a session ID to browser (via cookie)

Now:

Every request → sends session ID
Server checks → “Yes, this is the user”

Flow

✅ Pros

Simple to implement
Easy to invalidate (logout)

❌ Cons

Server has to store sessions
Not scalable for large systems

⚡ 2. JWT (JSON Web Token)

How It Works

Instead of storing session on server…

Server gives token to user

This token contains:

User ID
Expiry time
Signature

Example:

header.payload.signature

Now:

Client stores JWT (localStorage / cookie)
Sends it with every request

Server:

Verifies token → allows access

Flow

✅ Pros

Stateless (no server storage)
Scalable
Fast

❌ Cons

Hard to revoke instantly
Needs proper security handling

How It Works

Instead of creating your own login system…

You use another provider

Example:

“Login with Google”
“Login with GitHub”

Flow

User clicks Google login
Redirect to Google
User authenticates
Google sends token back
Your app trusts Google → logs user in

✅ Pros

No need to manage passwords
More secure
Faster user onboarding

❌ Cons

Dependency on third-party
Slightly complex setup

JWT vs Session vs OAuth (Simple Comparison)

Feature	Session	JWT	OAuth
Storage	Server	Client	Third-party
Scalability	Medium	High	High
Complexity	Easy	Medium	Medium-Hard
Use Case	Small apps	APIs / SPAs	Social login

When to Use What?

Small app → Session
Modern API / frontend → JWT
Social login → OAuth

Many apps use combination (JWT + OAuth)

⚠️ Common Mistakes

Storing JWT insecurely ❌
Not setting expiry ❌
Weak session management ❌

Security matters a lot here

Final Thought

Authentication looks simple on UI…

But behind the scenes:

It’s all about trust, identity, and security

As a developer:

Understanding this = real backend skill

Now next time you click “Login”…

You know exactly what’s happening

Thinking auth in producation systems a dive on the backend

Sat, 07 Feb 2026 15:07:52 +0000

When building an application, authentication is unavoidable. You can outsource it to services like Clerk or Better Auth and be productive fast, but that convenience often comes with trade-offs: third-party lock-in, limited control over flows, and opaque behavior when things go wrong.

In production systems, authentication is not just about logging users in. It shapes your security model, influences your database design, and quietly dictates how scalable and debuggable your system will be.

In this article, I’ll walk through how I designed and implemented authentication for a real production project, the decisions I had to make, and the compromises that came with them. Since all systems have different auth requirements, it might vary from your version.

Requirements for my project

For this project, authentication needs to be intentionally simple:
email + password–based registration and login, with Google OAuth as an alternative for both signup and sign-in.

If a user registers using email and password, the email must be verified via a verification link. Once the email is verified, the user is automatically logged in. The frontend receives the required tokens and user context without forcing an additional login step.

Strategy

For this project, I’m using a JWT-based authentication approach with short-lived access tokens and refresh tokens, with refresh token rotation enabled.

private async generateTokens(
    userId: string,
    email: string,
    role: number,
    deviceId: string,
  ) {
    const accessTokenSecret =
      this.configService.get<string>('JWT_ACCESS_SECRET');

    const refreshTokenSecret = this.configService.get<string>(
      'JWT_REFRESH_TOKEN_SECRET',
    );

    const accessTokenExpiryRaw = this.configService.get<string>(
      'JWT_ACCESS_TOKEN_EXPIRE_TIME',
      '1h',
    );
    const refreshTokenExpiryRaw = this.configService.get<string>(
      'JWT_REFRESH_TOKEN_EXPIRE_TIME',
      '7d',
    );

    const accessTokenTtlMs = ms(accessTokenExpiryRaw);
    const refreshTokenTtlMs = ms(refreshTokenExpiryRaw);

    const [accessToken, refreshToken] = await Promise.all([
      this.jwtService.signAsync(
        { sub: userId, email, role },
        {
          secret: accessTokenSecret,
          expiresIn: Math.ceil(accessTokenTtlMs / 1000),
        },
      ),
      this.jwtService.signAsync(
        { sub: userId, email, role },
        {
          secret: refreshTokenSecret,
          expiresIn: Math.ceil(refreshTokenTtlMs / 1000),
        },
      ),
    ]);

    // Extract the signature part of the JWT
    const accessTokenSignature = accessToken.split('.')[2];

    // Keyv expects TTL in ms - cache key includes deviceId for device-specific validation
    await this.cacheManager.set(
      `${CacheKey.ACCESS_KEY}:${userId}:${deviceId}`,
      { tokenSignature: accessTokenSignature, deviceId },
      accessTokenTtlMs,
    );

    return { accessToken, refreshToken };
  }

To minimize authentication lookup latency, access tokens are cached in Redis, mapped to the corresponding user_id and device_id. This allows the system to validate active sessions without hitting the primary database on every authenticated request.

Device Identification
Each client device is assigned a unique deviceId, generated on the backend.

My first approach was to derive this identifier from the IP address and user agent. From a security perspective, this worked well. Tokens were tightly bound to their original context, and replaying them from elsewhere was difficult.

In practice, though, IP addresses change far more often than you’d expect, especially for mobile users. The result was unnecessary session invalidation and a poor user experience.

After weighing those trade-offs, I switched to deriving the deviceId from the user ID and user agent instead.

The goal of the deviceId is simple:

Avoid duplicate session entries in Redis when a user logs in multiple times from the same device
Make session tracking and revocation possible on a per-device basis
Add an extra check during token validation beyond signature and expiry
By anchoring sessions to a deterministic deviceIdRedis maintains a single active access-token entry per device rather than accumulating redundant session data.

In practice, access and refresh tokens are validated not just by their cryptographic signature and expiration, but also by the reason the deviceId they were issued for. This means that even if a token is leaked, it can’t be trivially replayed from a completely different device context unless the attacker also replicates the same user agent.

  private generateDeviceFingerprint(userId: string, userAgent: string): string {
    const raw = `${userId}|${userAgent}`;
    return crypto
      .createHash('sha256')
      .update(raw)
      .digest('hex')
      .substring(0, 32);
  }

User agents aren’t secret, and this is not meant to be a perfect defense. What it does provide is a meaningful reduction in the blast radius of token leakage and protection against a large class of naive replay attacks.

This approach intentionally trades stronger environmental binding for stability and usability. For this system, that trade-off is acceptable. The deviceId isn’t a cryptographic fingerprint; it’s a pragmatic mechanism to keep sessions predictable, revocable, and reasonably safe in production.

Schema design

For authentication, the core requirements can be met with just two tables: one to represent the user, and another to track login sessions via refresh tokens.

Table users {
  id        uuid PK        // uuidv7
  name      string
  email     string UNIQUE NOT NULL
  password  string null // hashed password
  role      int NOT NULL   // 0 = user, 1 = admin, 2 = super_admin
  created_at timestamp
  updated_at timestamp
}
Table user_login_tokens {
  id                     uuid PK
  user_id                uuid FK -> users.id
  device_id              string
  refresh_token_signature string NOT NULL
  user_agent             string
  ip_address             string
  expires_at             timestamp NOT NULL
  revoked_at             timestamp
  created_at             timestamp
}

Rate Limiting & Abuse Protection
Authentication endpoints are a natural target for abuse, so basic rate limiting is enforced at the infrastructure level using Redis.

Rather than applying a single global limit, rate limiting is scoped by action and tracked independently by IP address and email. This allows the system to respond differently to suspicious behavior without punishing legitimate users.

The following flows are protected:

Login attempts.
Registration attempts
Forgot password requests
Each flow has its own threshold, time window, and temporary block duration.

How It Works

For every request, the system checks whether the IP address or email is currently blocked for the given action. If either is blocked, the request is rejected immediately.

On failed attempts, counters are incremented in Redis with a short TTL. Once the configured threshold is exceeded, a temporary block is applied, and the counter is cleared. Successful authentication clears any existing attempt counters.

This keeps rate limiting fast, stateless, and independent of the primary database.

Here’s an example:

this.loginConfig = {
  maxAttempts: this.configService.get<number>('AUTH_LOGIN_MAX_ATTEMPTS', 5),
  windowMs: this.configService.get<number>('AUTH_LOGIN_WINDOW_MS', 60000),
  blockDurationMs: this.configService.get<number>('AUTH_LOGIN_BLOCK_MS',
    60000,
  ),
};

// Registration: 3 attempts per 5 minutes, blocked for 5 minutes
this.registerConfig = {
  maxAttempts: this.configService.get<number>(
    'AUTH_REGISTER_MAX_ATTEMPTS',
    3,
  ),
  windowMs: this.configService.get<number>(
      'AUTH_REGISTER_WINDOW_MS',
      300000,
  ),
  blockDurationMs: this.configService.get<number>(
      'AUTH_REGISTER_BLOCK_MS',
      300000,
    ),
};

// Forgot Password: 3 attempts per 5 minutes, blocked for 5 minutes
this.forgotPasswordConfig = {
   maxAttempts: this.configService.get<number>(
      'AUTH_FORGOT_MAX_ATTEMPTS',
      3,
   ),
   windowMs: this.configService.get<number>('AUTH_FORGOT_WINDOW_MS', 300000),
   blockDurationMs: this.configService.get<number>(
     'AUTH_FORGOT_BLOCK_MS',
     300000,
   ),
}

Token Lifecycle & Rotation
Access tokens in this system are intentionally short-lived. Any long-running session relies on refresh tokens, which makes the refresh flow a critical security boundary.

To handle this safely, refresh tokens are rotated on every use.

Refresh Flow

When a client requests a new access token using a refresh token, the system performs the following steps inside a database transaction:

Revoke the existing refresh token
The refresh token used for the request is immediately marked as revoked. This ensures that a refresh token can only be used once.
Re-evaluate the device context
The request’s device information is re-derived on the backend, ensuring that the new tokens are bound to the correct deviceId.
Issue a new token pair
A fresh access token and refresh token are generated and returned to the client.
Persist the new refresh token
The new refresh token is stored in the database, replacing any existing token for the same user-device combination.
This entire flow is executed atomically. Either all steps succeed, or none do.

Why Rotation Matters

Refresh token rotation prevents an entire class of replay attacks.

If a refresh token is leaked and reused:

The first request succeeds and rotates the token
Any subsequent reuse of the old token fails because it has already been revoked
This ensures that a compromised refresh token has a very limited window of usefulness.

Failure Behavior

If a refresh token is revoked, expired, or does not match the stored signature for the given device, the refresh request is rejected. At that point, the client must re-authenticate.

This makes refresh token misuse noisy, detectable, and self-limiting.

Design Trade-off

This approach slightly increases complexity compared to static refresh tokens, but it dramatically improves security and debuggability.

Token rotation turns refresh tokens from long-lived secrets into single-use credentials, which aligns much better with production threat models.

logout and token revocations
Logout is handled server-side.

When a user logs out:

The refresh token for the current session is revoked in the database
The cached access token for the corresponding userId and deviceId is removed from Redis
After this, the session cannot be refreshed, and any in-flight access tokens are rejected.

Logout is scoped to the current device. Other active sessions remain unaffected unless explicitly revoked.

async logout(userId: string, refreshToken: string, request: Request) {
    return await this.sequelize.transaction(async (t) => {
      const dbOptions = { transaction: t };
      // Revoke refresh token in database
      await this.tokenRepository.revokeRefreshToken(
        userId,
        refreshToken,
        dbOptions,
      );

      // Clear access token from cache
      // Extract device info and clear specific device cache

      const { deviceId } = this.extractDeviceInfo(request, userId);
      deleteFromCache(userId, deviceId)

      return null;
    });
  }

Email Verification Token Handling

On events like registration, or forgot password, or a verification token is created, which is sent through email to the user. where the web passes that token along with the other information, i.e., the new password field, to change the password.

These tokens live shortly in Redis; on successful request processing, these tokens are deleted, and the database is updated properly.

Password reset tokens are intentionally not bound to a device. These flows are designed to work across devices and browsers, and binding them to a device context would introduce unnecessary friction without meaningful security benefits.

// a generic implementation without rate limiting, since it's getting long
 async resetPassword(email: string, token: string, newPassword: string) {
    let payload: any;
    try {
      payload = await this.jwtService.verifyAsync(token, {
        secret: this.configService.get<string>('JWT_VERIFICATION_SECRET'),
      });
    } catch {
      throwBadRequest('auth.INVALID_OR_EXPIRED_TOKEN');
    }
    if (payload.email !== email || payload.type !== 'password_reset') {
      throwBadRequest('auth.INVALID_CREDENTIALS');
    }
    const tokenSignature = token.split('.')[2];
    const cacheKey = `reset_password_token:${tokenSignature}`;
    const userId = await this.cacheManager.get<string>(cacheKey);
    if (!userId) {
      throwBadRequest('auth.INVALID_OR_EXPIRED_TOKEN');
    }
    const hashedPassword = this.hashPassword(newPassword);
    await this.usersService.updateById(userId, { password: hashedPassword });
    await this.cacheManager.del(cacheKey);
    return null;
  }

Closing thoughts
This authentication system is built around clear trade-offs rather than generic patterns. Short-lived access tokens, refresh token rotation, per-device sessions, explicit revocation, and targeted rate limiting together provide predictable behavior and reasonable security without unnecessary complexity.

Follow me on X (formerly known as Twitter): https://x.com/Itstheanurag

Advance Auth Templete

Fri, 30 Jan 2026 11:40:29 +0000

Advance Auth (TypeScript) – Production-Ready Auth Template for Real Projects

I built a modular, production-grade authentication template so I never have to rewrite auth again, and now you don’t either.

This is not a demo. This is a fork-and-build foundation for real SaaS, startups, and side projects.

Repo: https://github.com/SAYOUNCDR/Advance-Auth

What’s inside

A full auth system written in TypeScript + Node + Express, designed the way it should be done in real backends:

JWT access + refresh token rotation

RBAC (User / Admin roles)

Google OAuth

Email verification flow

Forgot / Reset password

2FA with TOTP (Google Authenticator)

Zod validation everywhere

Modular, clean architecture

Secure password hashing (bcrypt)

Token versioning, secure cookie handling

Ready for scaling and extension

⚠️ What’s left (being honest)

Only two things are pending:

Final rate limiting middleware wiring

A few extra security hardening checks

The core system is already solid and usable.

Why this matters

Auth is boring, repetitive, and easy to mess up.

Now you can:

Fork this repo

Plug in your business logic

Start building features immediately

Modify or extend auth without pain

No rewrites. No hacks. No copy-paste hell.

️ Stack

TypeScript

Node.js + Express

MongoDB (Mongoose)

JWT

Zod

OAuth

Nodemailer

otplib (2FA)

Who should use this

Indie hackers

Startup founders

Full-stack devs

Anyone tired of rebuilding auth from scratch

Fork it, break it, improve it, ship with it.

If you care about clean backend engineering, this is for you.

Building Secure JWT Auth in NestJS: Argon2, Redis Blacklisting, and Token Rotation

Sun, 18 Jan 2026 17:16:38 +0000

Imagine you've just watched your first tutorial on authentication. You spin up a login flow, add some JWTs, and call it done. Then you push to production and realize those tutorials skipped the hard parts—token revocation, session management, replay attacks.

It's not enough to have a login endpoint. Production auth means thinking like an attacker and handling edge cases that basic tutorials ignore. Let's talk about what actually secure authentication looks like in NestJS and how to implement it without the security holes.

When a developer says they are "implementing auth," they are usually talking about two distinct but inseparable concepts: Authentication and Authorization. When building robust systems, these go hand in hand.

Authentication (AuthN) vs. Authorization (AuthZ)

Authentication is about identity. It answers "Who are you?" using credentials like email/password, passkeys, or biometrics.
Authorization is about permissions. It answers "What can you do?" Once we know who you are, we use strategies like Role-Based Access Control (RBAC) to ensure you only touch the resources you're allowed to.

The NestJS Toolkit: Passport and Guards

In the NestJS ecosystem, we don't reinvent the wheel. We use Passport.js, the industry standard for Node.js authentication. NestJS wraps this in @nestjs/passport and provides AuthGuards.

Guards are the "bouncers" of your application. When a request hits a protected route, the Guard intercepts it, extracts the token, and validates it before the request ever reaches your controller logic.

@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
  constructor(
    private readonly reflector: Reflector,
    private readonly redis: RedisService,
  ) {
    super();
  }

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const isPublic = this.reflector.getAllAndOverride<boolean>(IS_PUBLIC_KEY, [
      context.getHandler(),
      context.getClass(),
    ]);

    if (isPublic) return true;

    const request = context.switchToHttp().getRequest();
    if (!request.headers['authorization']) return false;

    const token = request.headers['authorization'].split(' ')[1] as string;

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    const result = super.canActivate(context);
    return result instanceof Promise ? result : (result as boolean);
  }
}

Secure Onboarding: Why Argon2?

For sign-up, you need to store passwords. I chose Argon2 over the more common Bcrypt. Argon2 was the winner of the Password Hashing Competition for a reason: it's memory-intensive.

Unlike older algorithms, Argon2 allows you to configure memory usage, making it significantly harder to crack using specialized hardware like GPUs or ASICs. It essentially punishes brute-force attempts with slow, high-resource computation.

Registration (Hashing)

When a user signs up, the plain-text password is transformed into a hash before being stored in the database.

// UsersService
import { hash } from '@node-rs/argon2';

async create(data: CreateUserDto): Promise<User> {
  let userData = { ...data };
  if (data.password) {
    const passwordHash = await hash(data.password); //
    userData = { ...userData, password: passwordHash };
  }
  return await this.prisma.user.create({ data: userData });
}

Crucially, we never "decrypt" a password. When a user logs in:

We retrieve the stored hash from the DB.
We take the plain-text password provided in the login form.
We run the provided password through the same hashing process (including the "salt" stored within the hash).
If the resulting hash matches the stored one, the user is verified.

import { verify } from '@node-rs/argon2';

// AuthService
async validateUser(email: string, password: string): Promise<UserEntity | undefined> {
  const user = await this.usersService.findOneByEmail(email);
  if (user && user.password) {
    /* The verify function automatically creates a hash of the plain
password and compares it against our stored password hash */
    const isPasswordValid = await verify(user.password, password);
    if (isPasswordValid) return new UserEntity(user);
    throw new UnauthorizedException('Password is not valid');
  }
}

The Dual-Token Strategy

Once verified, we generate two tokens.

1. The Access Token (Short-lived & Stateless)

Signed with a secret key, this contains the user’s ID and metadata. We set this to 15 minutes. This is the industry standard because it limits the "blast radius"—if a token is stolen, it’s only useful for a tiny window.

2. The Refresh Token (Long-lived & Stateful)

Signed with a completely different secret (this is vital for security), we set this to 7 days. Unlike the access token, we store this in our database (Prisma) because it needs to be stateful. We also attach a unique JTI (JWT ID) when signing the token to allow for efficient database lookups after decoding the JWT.

By storing it, we gain a "Kill Switch." If we detect suspicious activity, we can manually revoke that specific token in the DB, preventing it from ever being used to generate a new access token. Here's how we create and store the refresh token in our database:

import { randomUUID } from 'node:crypto';

// JwtRefreshService
async create(payload: CreateRefreshTokenDto): Promise<string> {
  const tokenId = randomUUID(); // Unique ID for this token
  const refresh_token = this.jwtService.sign(
    { ...payload, jti: tokenId },
    {
      secret: this.configService.get('JWT_REFRESH_SECRET'),
      expiresIn: '7d',
    },
  );

  const hashed_refresh_token = await hash(refresh_token);

  await this.prisma.refreshToken.create({
    data: {
      id: tokenId,
      token: hashed_refresh_token,
      userId: payload.sub,
      absolute_limit_at: new Date(Date.now() + 90 * 24 * 60 * 60 * 1000), // Hard session limit
      isRevoked: false,
    },
  });

  return refresh_token;
}

Solving the "Stateless Revocation" Problem with Redis

The biggest flaw in JWTs is that they are stateless. If a user logs out, their Access Token is still technically valid until those 15 minutes are up.

To fix this without destroying performance, we use Redis.

Redis is an in-memory key-value store. Because it lives in RAM, it provides the sub-millisecond read/writes we need to check every single incoming request without slowing down the API. On logout, we "blacklist" the access token in Redis for the remainder of its lifespan. Our JwtAuthGuard then checks Redis on every request: if the token is in the blacklist, access is denied. When the user logs out, we calculate how long until the access token would naturally expire and blacklist it for exactly that duration:

// RedisService implementation
async blacklistToken(token: string, ttl: number): Promise<void> {
  await this.redis.set(`blacklist:${token}`, '1', { EX: ttl }); //
}

async isTokenBlacklisted(token: string): Promise<boolean> {
    const result = await this.redis.exists(`blacklist:${token}`);
    return result === 1;
 }

// JwtAuthGuard
@Injectable()
export class JwtAuthGuard extends AuthGuard('jwt') {
    // existing authorization logic

    // Check if the token was manually revoked (logout)
    const isBlacklisted = await this.redis.isTokenBlacklisted(token);
    if (isBlacklisted) return false;

    // return result
   }
}

// Logout logic
async logout(data: { userId: string; access_token: string; refresh_token: string }) {
  const access_token_payload = await this.jwtService.verifyAsync(data.access_token);
  const ttl = access_token_payload.exp - Math.floor(Date.now() / 1000);
  
  if (ttl > 0) {
    await this.redisService.blacklistToken(data.access_token, ttl); //
  }
  // ... proceed to revoke refresh token
}

Refresh Token Rotation & Absolute Limits

What if a refresh token is stolen? An attacker could theoretically stay logged in for 7 days. We solve this with Refresh Token Rotation.

Every time a user uses a Refresh Token to get a new Access Token, we:

Invalidate the old Refresh Token.
Issue a brand-new Refresh Token.

The Absolute Time Limit

To prevent a session from being kept alive forever by rotation, we implement an Absolute Time Limit (e.g., 90 days). This is set at the initial login. Every time a token rotates, that original 90-day timestamp is carried forward. Once we hit that date, no more rotations are allowed—the user must log in with their password again.

// rotateRefreshToken logic
async rotateRefreshToken(payload: RotateRefreshTokenDto) {
  const { old_refresh_token_id, time_limit, sub, email, deviceInfo } = payload;
  
  await this.revokeRefreshToken(old_refresh_token_id); // Invalidate old

  const new_refresh_token = this.jwtService.sign(
        {
          email,
          sub,
          deviceInfo,
        },
        {
          secret: this.configService.get<string>('JWT_REFRESH_SECRET'),
          expiresIn: '7d',
        },
      );
  
  // Create new token record with the original time_limit
  await this.prisma.refreshToken.create({
    data: {
      token: await hash(new_refresh_token),
      userId: sub,
      absolute_limit_at: time_limit, // Carry forward absolute limit
      isRevoked: false,
    },
  });
}

  async revokeRefreshToken(token_id: string) {
    try {
      await this.prisma.refreshToken.update({
        where: {
          id: token_id,
        },
        data: {
          isRevoked: true,
        },
      });
    } catch (error) {
      if (error instanceof Prisma.PrismaClientKnownRequestError) {
        if (error.code === 'P2025') {
          throw new NotFoundException('Token not found');
        }
      }
      throw error;
    }
  }

  @Public()
  @UseGuards(JwtRefreshAuthGuard)
  @Post('refresh')
  async refresh(
    @Request()
    req: RequestType & {
      user: { email: string; id: string; refreshToken: string };
    },
    @Response({ passthrough: true }) res: ResponseType,
  ) {
    if (req.user) {
      const tokens = await this.authService.refreshTokens({
        userId: req.user.id ?? '',
        email: req.user.email ?? '',
        token: req.user.refreshToken ?? '',
      });

      res.cookie('titan_refresh_token', tokens?.refresh_token, {
        httpOnly: true,
        secure: true,
        sameSite: 'strict',
      });

      return { access_token: tokens?.access_token };
    }
  }

Reuse Detection (The "Nuclear" Option)

If a token that was already revoked is used, it signals a potential theft. The system responds by revoking all tokens for that user.

// validateToken snippet
if (storedToken?.isRevoked) {
  // Nuke 'em
  await this.prisma.refreshToken.updateMany({
    where: { userId: payload.userId },
    data: { isRevoked: true }, // Revoke all active sessions for this user
  });
  throw new UnauthorizedException('Token reuse detected. Please login again');
}

One thing to note is that while we return the access token to the user in the response body, we have to set the refresh token as a http-only cookie.

  @Post('login')
@UseGuards(LocalAuthGuard)
async login(
  @Request() req: RequestType & { user: UserEntity },
  @Response({ passthrough: true }) res: ResponseType,
) {
  const deviceInfo = req.headers['user-agent'] || 'Unknown Device';

  const { access_token, refresh_token } = await this.authService.login(
    req.user,
    deviceInfo,
  );

  // Securely set the Refresh Token as a cookie
  res.cookie('titan_refresh_token', refresh_token, {
    httpOnly: true, // Prevents JS from reading the cookie
    secure: true,   // Only sent over HTTPS
    sameSite: 'strict', // Protects against CSRF
    path: '/auth/refresh', // Optional: Only send cookie to the refresh endpoint
  });

  // Send the Access Token in the body for the frontend to store in memory
  return { access_token };
}

The reason for this is to make the refresh token invisible to the client-side javascript. Even if an attacker successfully runs a script on your page, they cannot "read" the refresh token. We also set secure: true (ensuring it's only sent over HTTPS) and sameSite: strict to protect against CSRF attacks.

As for the access token, the frontend receives it in the JSON response and typically stores it in memory (a variable). While it's still technically vulnerable to XSS, because it isn't persisted in storage, it's much harder to exfiltrate, and its short 15-minute lifespan limits the damage if it is compromised

Conclusion

At the end of the day, writing code alone doesn't build a secure authentication system. We need to constantly balance security, speed, and user experience. By thinking like an attacker, we can turn standard JWTs into a fortified system using tools like Redis and techniques like Refresh Rotation. It takes a bit more effort to set up, but the peace of mind knowing you’ve accounted for edge cases like token theft or stale sessions is well worth the complexity, especially in sensitive applications.

Summary of our Security Workflow

Memory-Hard Hashing: Used Argon2 to ensure passwords are resistant to GPU-based cracking.
Dual-Token Architecture: Balanced security with short-lived (15 min) access tokens and long-lived (7 day) refresh tokens.
Real-time Revocation: Leveraged Redis for sub-millisecond access token blacklisting upon logout.
Session Lifecycle Management: Implemented 90-day absolute time limits to ensure no session lasts forever.
Automatic Breach Detection: Enabled Refresh Token Rotation with a "nuclear" reuse detection trigger that invalidates all user sessions if a stolen token is detected.

Technical Stack Overview

Tool	Purpose	Key Feature
NestJS	Backend Framework	Modular architecture and robust dependency injection.
Passport.js	Auth Logic	Industry-standard middleware for handling JWT strategies.
Argon2	Password and Token Hashing	Memory-intensive hashing
Prisma	Database ORM	Type-safe interaction with our stateful Refresh Token storage.
Redis	In-Memory Store	Rapid read/write operations for stateless token revocation (blacklisting).
JWT	Tokenization	Secure, encoded payload delivery for AuthN and AuthZ.

Login-free trials using localStorage refresh tokens

Fri, 12 Dec 2025 15:25:16 +0000

I just posted on Hacker News about a pattern I implemented for letting users try my side project without signing up first.

The short version: click "Try it now", you're immediately in the dashboard with a working account. No email, no OAuth. A guest secret gets stored in localStorage, and if you come back later we swap it for a fresh JWT. Sign up for real whenever you want and your stuff transfers over.

I wrote up the security considerations (separate JWT keypairs for guests vs real users, hashed secrets, rate limiting, etc.) and the trade-offs I'm accepting (localStorage clearing = lost access, single device only).

Would love to hear if anyone else has done something similar or has thoughts on the approach.

Full post and discussion on HN: https://news.ycombinator.com/item?id=46244742

The project is Spikelog (simple metrics tracking) if you want to poke at the implementation: https://spikelog.com

Website Authentication Made Simple with SafeLine

Wed, 03 Dec 2025 03:08:23 +0000

Website authentication is a fundamental part of modern web security. It ensures that only authorized users can access protected resources, reducing the risk of data breaches, abuse, and unauthorized operations.

This article will explain what website authentication is, when it is needed, introduce several free and practical authentication tools, and finally walk through SafeLine WAF’s authentication feature and how to configure it.

What Is Website Authentication?

Website authentication is the process of verifying a user’s identity before granting access to a website, application, or specific resources.

Common authentication methods include:

Username and password
Tokens or API keys
Cookies and sessions
Single Sign-On (SSO)
IP-based or request-based verification

Authentication answers the question:

“Who are you, and should you be allowed to access this resource?”

When Do You Need Website Authentication?

Not every website needs authentication, but it becomes essential in many scenarios:

Administrative Interfaces

Admin panels (/admin)
Internal dashboards
Management APIs

Internal or Private Services

Staging environments
Internal tools
Test platforms not meant for public access

APIs and Web Services

Prevent unauthorized API usage
Protect against abuse and scraping
Control access for partners or customers

Temporary Protection

Maintenance pages
Pre-launch websites
Emergency protection during attacks

If your website exposes sensitive functionality or data, authentication should be considered mandatory.

Free and Useful Website Authentication Tools

Here are some popular and free authentication solutions commonly used today:

1. Basic Authentication

Built into HTTP standard
Username and password via browser prompt
Easy to configure
Best for internal tools or temporary protection

✅ Simple
❌ Not suitable for public-facing login systems

2. OAuth / OpenID Connect

Used by Google, GitHub, Microsoft, etc.
Enables Single Sign-On (SSO)
Supported by many open-source tools

Popular providers:

Google OAuth
GitHub OAuth
Auth0 (free tier available)
Keycloak (open-source)

✅ Secure and scalable
❌ Slightly more complex to deploy

3. API Key / Token-Based Authentication

Common for APIs
Client sends a token in headers
Easy to rotate and revoke

✅ Ideal for machine-to-machine access
❌ Requires careful key management

4. Reverse Proxy Authentication

Authentication handled at the gateway layer
No need to modify backend applications
Ideal for legacy systems

✅ Very flexible
✅ Application-agnostic

This is where SafeLine WAF authentication shines.

SafeLine WAF Authentication: Overview

SafeLine WAF provides a built-in identity authentication feature at the WAF layer, allowing users to protect websites and applications without changing backend code.

With SafeLine authentication, you can:

Add authentication to any website behind SafeLine
Protect directories, paths, or entire domains
Block unauthorized users before traffic reaches the server
Reduce attack surface and backend load

This is especially useful for:

Admin panels
Internal services
Temporary access control
Protecting legacy applications

How To Configure Authentication in SafeLine

Basic Configuration

SafeLine provides two authentication modes: Simple Auth and SSO.

Simple Auth: Application-specific authentication system where users can only access that application after logging in
SSO (Single Sign-On): allowing users to access multiple related applications after logging in once, without repeated logins. See SSO

Field	Description
Login Method	Multiple login methods available, including AccountPassword, OIDC, Github, LDAP. For SSO mode, configuration must be done in `AUTH-SETTINGS-SSO`.
Auth Callback URL	Required when passing user authentication information to the application server, used to exchange for user information.
Application Redirect URL	Required in SSO mode. When clicking on the application in the unified management panel, it will redirect to this address.

Advanced Configuration

Approval Configuration: Options for authorization approval
- Need to approve access: First-time users will trigger an approval request after authentication, requiring admin approval before accessing.
- Access directly after authentication: Users can directly access the application after authentication without approval.
Enable authentication for specific conditions: Supports options to authenticate when conditions are met or skip authentication when conditions are met

How to Configure Passing User Authentication Information to the Application Server?

After successful user authentication, SafeLine will redirect to the following URL, where http://example.com/application is the Auth Callback URL configured:

http://example.com/application?code=123456&redirect_uri=original_user_access_address

Find the API Token in the SafeLine console under Settings-Management page
The application should implement using the code to request SafeLine's /.safeline/auth/api/user interface to obtain authenticated user information at the Auth Callback URL. The code can only be used once

// Request:

GET http://safeline-console.com/.safeline/auth/api/user?code=123456

X-SLCE-API-TOKEN: safeline-api-token

// Response:

Content-Type: application/json

{
    "code": 0, // 0: success, non-zero: failure
    "msg": "Error description",
    "data": {
        "id": 1,
        "username": "username"
    }
}

After successfully obtaining user information, the application should cache the login information to determine whether the current user is logged in for subsequent requests, then redirect to the redirect_uri

If retrieving user information fails, the application needs to delete cookies with the prefix sl_authsession, prompting the user to authenticate again

Why Use WAF-Level Authentication?

Compared to application-level authentication, WAF-level authentication offers:

✅ No code changes
✅ Faster deployment
✅ Consistent protection across services
✅ Reduced backend attack surface
✅ Ideal for legacy or third-party systems

It provides a lightweight but effective layer of access control exactly where it matters.

Conclusion

Website authentication is a critical security mechanism for protecting sensitive resources and preventing unauthorized access. While many tools and frameworks exist, WAF-level authentication offers a powerful and flexible option—especially when backend changes are impractical.

SafeLine WAF enables teams to implement authentication quickly, securely, and transparently, making it an excellent choice for internal tools, admin panels, APIs, and temporary access control scenarios.

By combining authentication with SafeLine’s traffic inspection and protection capabilities, you gain both identity control and attack defense at the gateway level.

SafeLine Website: https://ly.safepoint.cloud/ShZAy9x
Live Demo: https://demo.waf.chaitin.com:9443/statistics
Discord: https://discord.gg/dy3JT7dkmY
Doc: https://docs.waf.chaitin.com/en/home
Github: https://github.com/chaitin/SafeLine

Auth Sessions Should Never Cross Internal Boundaries

Tue, 02 Dec 2025 15:31:54 +0000

It is tempting to treat user authentication sessions as ambient context. You pass them through API layers, into service calls, across event processors, and through background jobs. If a component needs to know who the user is, it needs the user's session, right?

This conflates authentication with context. You're treating an external trust artifact as internal state.

The result is internal services coupled to the external auth mechanism, a replayable credential spread across them, and systems that break when work runs after the session ends or without one.

Sessions Validate at Boundaries, Context Flows Internally

What Crosses the Boundary

"Session" here means whatever the client presents to prove who the user is, whether that's a cookie bound to a server-side session or a bearer access token such as a JWT. The arguments below apply to both, and where they differ, the post says which one it means.

Authentication sessions serve one purpose: validating identity at a security boundary. Once validated, the session should be consumed and replaced with explicit context and service credentials.

A user session arrives at the boundary: an API endpoint, gateway, or edge function. The boundary validates the session and confirms identity. The session is then consumed. You extract only the necessary context: user_id, tenant_id, correlation_id, a non-secret session id, and, when a client acts for the user, the client's identity and the scopes the user granted it. From that point forward, internal operations use service roles. Components operate with service credentials like database connections, API keys, and queue permissions. User context is passed explicitly as structured data, not as the original session token.

The granted scopes in that context matter. A third-party app that holds only read access to a user's orders must not gain everything the user can do once its token is converted at the edge. So downstream authorization allows an action only when the user's current permissions and the client's granted scopes both permit it.

The Boundary Signs the Context

Passing context explicitly doesn't mean leaving it unprotected. A downstream service can't accept a bare user_id from anyone who sends one, or any caller could claim to be any user. The context has to arrive in a form the receiver can trust, which means a small object the boundary signs. An authenticated service-to-service channel isn't enough on its own. It proves which service is calling but not which user that service is acting for, so a compromised caller could assert any user_id it liked.

Netflix describes this design in its "Edge Authentication and Token-Agnostic Identity Propagation" post. Its edge services validate the many token types clients present and mint an integrity-protected identity object, called a Passport, which is what downstream services receive.

A signed context object is still a credential, so it needs limits of its own:

It's issued and accepted only inside your trust domain, never by an external API.
It's bound to one request or one message rather than to the user's login, through a short expiry, an audience claim that limits it to your internal services, and a request or message id.
It carries only the fields the work needs.

The boundary signs with a private key that only it holds, so a compromised internal service can read the context it was given but can't mint one for a different user. Like Netflix's Passport, the same context is passed along the whole call chain rather than re-signed at each hop, so no hop has to call a signing service mid-request.

The context can still be replayed inside your system. Within its short validity window, a service in the call path could replay it to another internal service, which is the same exposure a forwarded token has. What's gone is the external replay. No API outside your system accepts it, and it doesn't outlive the request.

Token Exchange Meets the Line, Forwarding Doesn't

This post draws its line at the first two limits above. Whatever travels inward is issued inside your trust domain and bound to one request or message. A gateway that exchanges the user's token for an internally issued, internally audienced one, using OAuth 2.0 Token Exchange (RFC 8693), meets that line. Forwarding the token the client presented does not.

Another alternative, per-hop delegation from the external identity provider, has each service trade for a new token audienced to the next one. It answers the replay concern but still crosses the line. Every hop then calls the provider at runtime and parses its token format, while a boundary-signed context is verified locally with a key you own.

Meeting that line at the gateway doesn't have to be heavy. For a system with two or three services and one issuer, the gateway signing a short-lived internal token with a standard JWT library keeps its cost to one key to manage.

Why Sessions Don't Belong in Internal Flows

Sessions are external trust artifacts. A user session token represents authentication with an external identity provider or your auth system. It's proof that someone outside your system is who they claim to be. Once verified at your boundary, propagating it further treats authentication as global state rather than a specific validation event.

Repeated validation adds a runtime dependency on the auth server. Every component that receives a user session has to validate it. For a self-contained token like a JWT, that's a local signature and expiry check. Verifying a boundary-signed context costs about the same, so the saving there is small. For opaque tokens and server-side sessions, validation means a call to the auth server, such as the introspection endpoint defined in RFC 7662. Each hop then adds a network round trip and makes the auth server's availability a condition of every internal call for a single user action.

Coupling to external authentication. When internal components accept user sessions, they become coupled to the token format, the issuer's validation requirements, token refresh logic, and external auth provider availability. With one standard OIDC issuer and a shared validation library, switching issuers can be mostly configuration. The coupling shows when the estate isn't that tidy, with several client token types, a proprietary session format, or a migration between them. Then every component that parses sessions has to change with it. Netflix's Passport work was a response to exactly that variety. A boundary-signed context still needs a shared format and key distribution, but that format is yours and doesn't change when the external issuer does.

Session Propagation Breaks When Work Outlives the Request

Propagating user sessions through internal components creates predictable failures whenever work outlives the request or has no user behind it.

Session expiration mid-flow is the first to appear. Event processors run minutes later and the session has expired. Background jobs run hours later and the session is gone. Async processors retry and the session is invalid. You build workarounds: token refresh in queues, session persistence in metadata, special "system sessions" for background work.

Missing sessions entirely breaks your logic. Scheduled reports run at 3 AM with no user logged in. Webhooks arrive from external systems with no user session. System maintenance tasks have no user context. You duplicate logic: one path for user requests and one for non-user operations.

Context across time and actors fragments workflows. Multi-step workflows span hours. The original user's session expires. Different actors have different sessions. Background processors have none. The workflow breaks without explicit context that persists beyond the session lifetime.

Storing context as data, which the boundary pattern makes the default, removes all three. The service that owns a workflow stores the original context with the workflow's own record, as data about who started it. Each later step or retry works from that record rather than from a credential that expires. When a later step calls another service, the workflow service calls as itself and passes the initiating user_id as data. The receiver checks that this service is allowed to request this action for this tenant, then checks the user's current permissions. A scheduled job or a webhook handler works the same way, with its own service identity and no user at all.

Pair the pattern with one rule. Every step authorizes against the user's current permissions and account status when it runs, so a user whose access was removed, or whose session was revoked after a compromise, is refused even hours later. The rule is independent of the token question, and a design that forwards tokens could adopt it too, but this pattern can't work without it. The context carries identity and the client's scope ceiling, not the user's roles, so a step has to look up permissions to decide anything. That lookup reads your own permission data, which the service already depends on to do the work, rather than making the external auth server a condition of every hop.

Async work has a limit here. Nothing in this path ties the user_id to a workflow that user started. A compromised workflow service can therefore act for any user in the tenants it serves, through the operations its own service identity is allowed. That is the same trust any background job carries, and it's why each service's identity should be allowed only the operations that service performs.

Common Objections

"We Can Forward Tokens on Synchronous Calls Only"

The strongest version of this view forwards a short-lived, audience-restricted token down synchronous call chains and uses explicit context only for async work. That view's async half is this post's design. Its sync half still carries the external artifact, so it keeps the coupling to the issuer's format described earlier. Widening the token's audience to cover the internal services, which RFC 9700 permits for a small set of resource servers, keeps the external replay out. It still leaves a credential in the issuer's format that lasts the token's whole lifetime rather than one request.

"We Lose User Context for Auditing"

You lose the session token, not the user context. Proper auditing requires intentional context capture: user_id, tenant_id, correlation_id, source_ip, user_agent, and timestamp.

The identity fields travel in the signed context through every component. Request details like source_ip and user_agent are logged once at the boundary and joined to downstream records by correlation_id, so no internal service can forge them. Relying on session tokens for auditing is worse because sessions don't persist for audit trails, you're logging authentication artifacts instead of business context, and different components might parse tokens differently.

Intentional data flow is the point. If you need user_id in audit logs, require it as an explicit parameter. This forces you to think about what context crosses boundaries and prevents accidental omissions.

"Compliance Requires User Identity Throughout the System"

Compliance rules ask you to authenticate who is acting and to record what they did. The HIPAA Security Rule, for example, requires verifying that a person seeking access is the one claimed (45 CFR 164.312(d)) and mechanisms that record and examine activity in systems holding health data (164.312(b)). Authentication happens at the boundary. Recording happens wherever the action happens, and a trusted user_id in explicit context is what that record needs. Passing the session token does not improve compliance. It couples your compliance logging to your auth mechanism.

"Service Roles Create Privilege Escalation Risks"

The risk is that a service with broad credentials can be tricked or compromised into acting outside the current user's rights. A forwarded token limits that risk only on calls to other services. On those calls, within one request, a boundary-signed context limits it just as well, since a compromised service can't mint context for another user. Async steps rely on the calling service's own identity, with the limit described earlier.

For the service's own resources, the token changes nothing. A compromised service with a database connection that reads every tenant's rows can read them whether or not it holds a user token, unless the database itself enforces the user's identity.

Service roles provide technical capability like database access and API credentials. Business logic enforces authorization through grant checks, tenant isolation, and permission verification. Where a breach would be severe, the data layer can enforce tenant isolation too, for example with row-level security keyed to the tenant in the context. These checks are necessary whether you use service roles or propagate user sessions. Scope each service's credentials to what that service does, so a compromise is limited to one service's capability.

A forwarded session adds its own risk. A bearer token works for anyone who holds it, so every internal component that receives the user's token can replay it as that user anywhere the token is accepted. That's why RFC 9700, the OAuth 2.0 security best practice, says access tokens should be audience-restricted to a specific resource server. A token restricted to your API shouldn't be accepted by every service behind it, and one that is has become a credential your whole system leaks.

Service roles also make the split clearer. The service has technical capability but requires explicit business authorization. User sessions blur this distinction by suggesting the session itself grants permission.

"Zero Trust Means Every Service Verifies the User"

Zero trust doesn't ask for the user's original token at every hop. NIST SP 800-207 requires that authentication and authorization are enforced before every access to a resource, rather than inherited from network location or an earlier step. A downstream service that verifies its caller's service identity and the signature on the user context, then authorizes the action against that context, meets the requirement. Forwarding the session meets it no better and spreads a replayable credential.

The legitimate exception is a component that must call another system as the user, such as a third-party API that only accepts the user's delegated token. Even then the original session doesn't travel. The boundary, the one place that holds the user's token, uses OAuth 2.0 Token Exchange (RFC 8693) to trade it for a new token issued for that one audience and scoped to that call. Work that calls the third party hours later relies on a grant the owning service stores as data, the way a workflow stores its context, not on a token carried through queues.

"We Need Sessions for Distributed Tracing"

You need correlation IDs for distributed tracing, not session tokens.

Distributed systems require explicit tracing infrastructure: correlation_id, trace_id, span_id, and timestamps. This works for all request types including user requests, background jobs, webhooks, internal system tasks, lambda invocations, and event processors.

If you rely on session tokens for tracing, non-user-initiated requests fail. When you need to join traces to a login session, the non-secret session id in the context does that without carrying the token.

"We're Using a Monolith, This Doesn't Apply"

Inside one process there's no token crossing a network and nothing to replay, so the security arguments above weigh less. Most web frameworks already apply the boundary rule for you, since their request principal holds a validated identity rather than the raw token. What remains is where business logic gets that identity. You still must avoid global user session context and pass user context within structures appropriate to the needs of each module.

Business logic that reads the current user from the web request couples your service layer to your web layer. A background job, CLI tool, or internal script that calls the same logic has no web request, so it either fails the way a missing session fails or has to fake a request principal first. Logic that takes the user as a parameter can be called from any of them as it stands.

The same principles apply: modules accept explicit context and perform explicit authorization. Whether those modules are in separate processes or the same codebase is irrelevant to that design.

Respect the Boundary

User authentication sessions serve one purpose: validating identity at a security boundary. Once validated, the session has done its job.

In practice:

Validate the session once, and let no component behind it parse the token
Extract only the context the work needs, such as user_id, tenant_id, correlation_id, and the calling client's granted scopes
Sign that context at the boundary, bind it to one request or message, and send it over authenticated service calls
Give each service its own narrowly scoped credentials
Authorize every action against current permissions, account status, and the client's granted scopes, whether a user, a webhook, or a scheduled job started it
When a component must act as the user elsewhere, exchange for a new token scoped to that call

This isn't about microservices versus monoliths. It's about recognizing architectural boundaries and respecting them. Authentication artifacts belong at boundaries, not in internal flows.

Authentication Tokens: Your Digital VIP Pass

Wed, 24 Sep 2025 13:05:12 +0000

In today's connected world, we all want to access our favorite apps and websites without re-entering our password every two seconds. That's where authentication tokens, or "auth tokens," come in. Think of them like a digital VIP pass. When you log in with your username and password, the server checks your credentials and, if everything's good, hands you a special token. Instead of sending your password with every request, your app sends this token. The server then uses the token to confirm you're still you, and you can access all the cool stuff you're supposed to.

How It Works: A Simple Flow

The basic process is pretty straightforward:

Login: You enter your username and password on an application's login screen.
Verification: The application sends your credentials to its server for verification.
Token Generation: If your credentials are correct, the server generates a unique auth token.
Token Received: The server sends this token back to your application, which stores it, usually in a cookie or local storage.
Access: From now on, whenever you need to access a protected resource, like your profile page or your shopping cart, the application includes the token in the request header.
Token Validation: The server receives the request, validates the token, and grants access if it's valid.

This system is great for scalability because the server doesn't need to remember who is logged in. This makes the server stateless, which is a huge plus for performance and building microservice architectures.

Types of Tokens You'll Encounter

There are a few different types of tokens, each with its own pros and cons.

1. JSON Web Tokens (JWTs)

A JWT (pronounced "jot") is a popular type of token that's self-contained. This means all the necessary user information is right inside the token itself. A JWT is made up of three parts, separated by periods:

Header: Describes the token type and the signing algorithm.
Payload: Contains "claims," which are statements about the user and the token. This is where you'd find user ID, roles, and the token's expiration date.
Signature: A unique signature created using a secret key. This is what the server uses to verify that the token hasn't been tampered with.

Because a JWT contains everything the server needs to know, the server doesn't have to perform a database lookup for every request. This makes them really fast and efficient.

Here's a quick Python example using the PyJWT library to create a JWT:

import jwt
import datetime

payload_data = {
    'sub': '1234567890',
    'name': 'John Doe',
    'iat': datetime.datetime.now(datetime.timezone.utc),
    'exp': datetime.datetime.now(datetime.timezone.utc) + datetime.timedelta(minutes=30)
}

secret_key = 'your_super_secret_key' # In a real app, use an environment variable!

token = jwt.encode(payload_data, secret_key, algorithm='HS256')

print(token)

You can then decode and verify this token on the server side to get the payload data.

2. Opaque Tokens

Unlike JWTs, opaque tokens are just random strings of characters. The client can't read anything from them. They are essentially a reference to a record stored in the server's database. When a server receives an opaque token, it has to go to the database to look up the token and retrieve the associated user data and permissions.

Pros & Cons:

JWTs: Fast, scalable, and don't require database lookups. The downside is that once issued, they can't be easily revoked before they expire.
Opaque Tokens: More secure since no information is exposed to the client. They are also easily revocable. The trade-off is that they require a database lookup on every request, which can add overhead.

3. Hybrid Tokens

A common and secure pattern is to use a hybrid approach. This combines the best of both worlds. You'll often see this with OAuth 2.0:

Short-lived Access Token: This is a JWT, used for accessing resources. It's valid for a short time (e.g., 15 minutes), so if it's stolen, the attacker doesn't have much time to use it.
Long-lived Refresh Token: This is an opaque token, used to get a new access token once the old one expires. It's stored securely and can be revoked by the server if needed. This prevents a user from having to log in again every 15 minutes.

This approach balances the performance benefits of JWTs with the security and revocability of opaque tokens.

Conclusion: Which One Should You Use?

The choice of token depends on your application's needs. For a simple app where you want to keep things fast and stateless, a JWT might be the perfect fit. For a system that requires a high level of security and granular control over token revocation, a hybrid model is often the way to go. No matter which you choose, understanding how they work is a crucial skill for any developer building secure and scalable applications.

PostgreSQL Client Certificate Authentication: Complete Setup Guide

Fri, 01 Aug 2025 12:50:19 +0000

Client certificate authentication in PostgreSQL provides a secure, passwordless way to authenticate users. Instead of relying on passwords, clients present valid X.509 certificates to prove their identity.

What to Configure

Server-Side Requirements

SSL certificates: Server certificate + client certificates
PostgreSQL SSL settings: Enable SSL and configure certificate paths
Authentication rules: Configure pg_hba.conf for certificate-based auth
User mapping: Link certificate Common Names to database users

Client-Side Requirements

Client certificate: Valid X.509 certificate for the user
Private key: Matching private key for the certificate
Root certificate: Server's certificate for verification
Connection parameters: Proper SSL mode and certificate paths

How to Configure

1. Generate SSL Certificates

# Create SSL directory
mkdir -p /var/lib/postgresql/17/main/ssl
cd /var/lib/postgresql/17/main/ssl

# Generate server certificate
openssl genrsa -out server.key 4096
openssl req -new -key server.key -out server.csr \
  -subj "/C=US/ST=State/L=City/O=Org/OU=OrgUnit/CN=localhost"
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

# Generate client certificate for user 'appuser'
openssl genrsa -out appuser.key 4096
openssl req -new -key appuser.key -out appuser.csr \
  -subj "/C=US/ST=State/L=City/O=Org/OU=OrgUnit/CN=appuser"
openssl x509 -req -days 365 -in appuser.csr \
  -CA server.crt -CAkey server.key -CAcreateserial -out appuser.crt

# Set permissions
chown postgres:postgres *.crt *.key
chmod 600 *.key
chmod 644 *.crt

2. Configure PostgreSQL SSL Settings

Add to postgresql.conf:

# SSL Configuration
ssl = on
ssl_cert_file = '/var/lib/postgresql/17/main/ssl/server.crt'
ssl_key_file = '/var/lib/postgresql/17/main/ssl/server.key'
ssl_ca_file = '/var/lib/postgresql/17/main/ssl/server.crt'
ssl_prefer_server_ciphers = on
ssl_min_protocol_version = 'TLSv1.2'

3. Configure Authentication Rules

Update pg_hba.conf:

# SSL connections require client certificate authentication
hostssl all             all             0.0.0.0/0               cert clientcert=verify-full
hostssl all             all             ::/0                    cert clientcert=verify-full

# Non-SSL connections require password authentication
hostnossl all           all             0.0.0.0/0               scram-sha-256
hostnossl all           all             ::/0                    scram-sha-256

4. Create Database User

The database user must match the certificate's Common Name(CN):

CREATE USER appuser WITH LOGIN;
GRANT CONNECT ON DATABASE mydb TO appuser;
-- Grant additional permissions as needed

How to Connect from Client

Critical Connection Parameters

Parameter	Self-Managed Value	RDS Value	Purpose
`sslmode`	`require` or `verify-full`	`require` or `verify-full`	Force SSL connection
`sslcert`	`/path/to/client.crt`	N/A (not supported)	Client certificate file
`sslkey`	`/path/to/client.key`	N/A (not supported)	Client private key file
`sslrootcert`	`/path/to/server.crt`	`./global-bundle.pem`	Server certificate for verification
`host`	`localhost` or custom	`instance.region.rds.amazonaws.com`	Database server endpoint
`password`	Not required with client cert	Required (or IAM token)	Authentication credential

Connection Examples

Self-Managed PostgreSQL with Client Certificates

# psql - No password required
psql "host=localhost port=5432 dbname=mydb user=appuser \
      sslmode=require \
      sslcert=./certs/appuser.crt \
      sslkey=./certs/appuser.key \
      sslrootcert=./certs/server.crt"

// .NET - Client certificate authentication
var connectionString = "Host=localhost;Port=5432;Database=mydb;Username=appuser;" +
                      "SSL Mode=Require;" +
                      "Client Certificate=./certs/appuser.crt;" +
                      "Client Key=./certs/appuser.key;" +
                      "Root Certificate=./certs/server.crt;";

# Python - Client certificate authentication
import psycopg2
conn = psycopg2.connect(
    host="localhost",
    port=5432,
    database="mydb",
    user="appuser",
    sslmode="require",
    sslcert="./certs/appuser.crt",
    sslkey="./certs/appuser.key",
    sslrootcert="./certs/server.crt"
)

// Java JDBC - Client certificate authentication
String url = "jdbc:postgresql://localhost:5432/mydb" +
            "?ssl=true" +
            "&sslmode=require" +
            "&sslcert=./certs/appuser.crt" +
            "&sslkey=./certs/appuser.key" +
            "&sslrootcert=./certs/server.crt" +
            "&user=appuser";

Connection conn = DriverManager.getConnection(url);

AWS RDS PostgreSQL with SSL (Password Required)

# psql - Password required, verify server certificate
psql "host=mydb.cluster-xyz.us-east-1.rds.amazonaws.com \
      port=5432 dbname=postgres user=myuser password=mypassword \
      sslmode=verify-full sslrootcert=./global-bundle.pem"

// .NET - RDS with SSL verification
var connectionString = "Host=mydb.cluster-xyz.us-east-1.rds.amazonaws.com;" +
                      "Port=5432;Database=postgres;Username=myuser;Password=mypassword;" +
                      "SSL Mode=Require;Root Certificate=./global-bundle.pem;";

# Python - RDS with SSL verification  
import psycopg2
conn = psycopg2.connect(
    host="mydb.cluster-xyz.us-east-1.rds.amazonaws.com",
    port=5432,
    database="postgres",
    user="myuser",
    password="mypassword",
    sslmode="verify-full",
    sslrootcert="./global-bundle.pem"
)

// Java JDBC - RDS with SSL verification
String url = "jdbc:postgresql://mydb.cluster-xyz.us-east-1.rds.amazonaws.com:5432/postgres" +
            "?ssl=true" +
            "&sslmode=verify-full" +
            "&sslrootcert=./global-bundle.pem" +
            "&user=myuser" +
            "&password=mypassword";

Connection conn = DriverManager.getConnection(url);

Server Configuration vs Client Parameters

Server Side (`pg_hba.conf`)

# Authentication method MUST be 'cert'
hostssl all all 0.0.0.0/0 cert clientcert=verify-full

Client Side (Connection String)

# SSL mode MUST be 'require' or 'verify-full'
sslmode=require
# All three certificate files MUST be provided
sslcert=./client.crt
sslkey=./client.key  
sslrootcert=./server.crt

Common Pitfalls

Certificate CN mismatch: Client certificate CN must match database username
Missing clientcert=verify-full: Server won't require client certificates
Wrong SSL mode: sslmode=disable or prefer may skip certificate auth
File permissions: Private keys must be readable only by the client process
Certificate expiration: Monitor and rotate certificates before expiry

Security Benefits

No password transmission: Eliminates password-based attacks
Strong authentication: Based on cryptographic proof of identity
Non-repudiation: Certificate-based audit trails
Mutual authentication: Both client and server verify each other

AWS RDS PostgreSQL Configuration

RDS Limitations for Client Certificates

AWS RDS PostgreSQL has limited support for client certificate authentication compared to self-managed PostgreSQL:

What's NOT Available in RDS

Custom client certificate generation: You cannot upload custom client certificates
Full cert authentication method: RDS doesn't support the cert method in pg_hba.conf
Direct certificate file access: No access to /var/lib/postgresql/ directory

What IS Available in RDS

1. RDS SSL Server Certificates & Configuration

# Download RDS CA certificate bundle
wget https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

# Enable SSL in RDS parameter group
aws rds modify-db-parameter-group \
    --db-parameter-group-name mygroup \
    --parameters "ParameterName=ssl,ParameterValue=1,ApplyMethod=immediate"

2. Alternative: IAM Database Authentication

For passwordless authentication in RDS, use IAM database authentication:

-- Create IAM-enabled database user
CREATE USER iamuser;
GRANT rds_iam TO iamuser;
GRANT CONNECT ON DATABASE postgres TO iamuser;

# Connect using IAM token (Python example)
import boto3
import psycopg2

rds_client = boto3.client('rds', region_name='us-east-1')
token = rds_client.generate_db_auth_token(
    DBHostname='mydb.xyz.us-east-1.rds.amazonaws.com',
    Port=5432,
    DBUsername='iamuser'
)

conn = psycopg2.connect(
    host="mydb.xyz.us-east-1.rds.amazonaws.com",
    port=5432,
    database="postgres",
    user="iamuser",
    password=token,  # IAM token as password
    sslmode="require",
    sslrootcert="./global-bundle.pem"
)

3. Hybrid Approach: ALB + Client Certificates + RDS

For applications requiring client certificate authentication with RDS:

[Client with Client Cert] → [ALB with SSL termination] → [App Server] → [RDS with IAM Auth]

ALB handles client certificate verification
Application validates certificates in code
RDS connection uses IAM authentication

Summary & Verification

Self-Managed vs AWS RDS Comparison

Feature	Self-Managed	AWS RDS
Client Certificate Auth	✅ Full support	❌ Not supported
Server SSL Certificates	✅ Custom certificates	✅ AWS-managed certificates
Passwordless Authentication	✅ Client certificates	✅ IAM authentication
Certificate Management	❌ Manual rotation	✅ Automatic rotation
SSL Configuration Control	✅ Full control	❌ Limited parameters

Verification Commands

-- Verify SSL is enabled
SHOW ssl;

-- Check active SSL connections with certificate details
SELECT datname, usename, client_addr, ssl, ssl_version, ssl_cipher,
       client_dn, issuer_dn
FROM pg_stat_ssl 
JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid 
WHERE ssl = true;
-- Example output
pid|ssl |version|cipher                |bits|client_dn                                                      |client_serial                                   |issuer_dn                                                   |datid|datname       |pid|leader_pid|usesysid|usename       |application_name|client_addr|client_hostname|client_port|backend_start                |xact_start|query_start                  |state_change                 |wait_event_type|wait_event|state|backend_xid|backend_xmin|query_id           |query                                                                                                                        |backend_type  |
---+----+-------+----------------------+----+---------------------------------------------------------------+------------------------------------------------+------------------------------------------------------------+-----+--------------+---+----------+--------+--------------+----------------+-----------+---------------+-----------+-----------------------------+----------+-----------------------------+-----------------------------+---------------+----------+-----+-----------+------------+-------------------+-----------------------------------------------------------------------------------------------------------------------------+--------------+
754|true|TLSv1.3|TLS_AES_256_GCM_SHA384| 256|/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=redgatemonit|608692775915102986323080169170088721995325147053|/C=US/ST=State/L=City/O=Organization/OU=OrgUnit/CN=localhost|16384|redgatemonitor|754|          |   16385|redgatemonitor|psql            |10.88.0.1  |               |      59168|2025-07-30 09:43:20.240 +0100|          |2025-07-30 09:43:58.869 +0100|2025-07-30 09:43:58.870 +0100|Client         |ClientRead|idle |           |            |8885888923103386772|SELECT datname, usename, client_addr, ssl,* FROM pg_stat_ssl JOIN pg_stat_activity ON pg_stat_ssl.pid = pg_stat_activity.pid;|client backend|

Key Takeaways

Self-managed PostgreSQL: Use client certificates for true passwordless authentication
AWS RDS: Combine IAM authentication with SSL encryption for secure connections
Hybrid approach: Use ALB for client certificate verification with RDS backend
Security: Both approaches provide enterprise-grade security with different trade-offs

Client certificate authentication in PostgreSQL provides enterprise-grade security without the overhead of password management, making it ideal for automated systems and high-security environments.

References

https://www.postgresql.org/docs/current/ssl-tcp.html

DevLog 20250523: Firebase Auth

Fri, 23 May 2025 19:06:57 +0000

The Authentication Problem

Let's face it: develop a custom authentication service is conceptually straightforward but practically troublesome. You either allow user registration or not, then authenticate by taking a look at username and password (likely hashed) against database, then provide user profile results for authorized users. Throughout the process you might set browser cache, deal with (generated) API keys for app usages (so password need not be sent every time). It's a handful of steps, and lots of work to code everything piece by piece. Worse, there is a whole database to worry about. One would naturally expect, such a thing should just exist as a service. Yes, there is.

Quick Comparison

|Platform|What it is|Free tier|Pros|Cons|
|-|-|-|-|-|
|AWS Cognito | Amazon’s identity and user‑management service for web and mobile apps, integrating natively with API Gateway/Lambda and Amplify JS. | 10,000 MAUs for direct/social sign‑in + 50 MAUs for SAML/OIDC federation; Identity Pools are free | No extra vendor to learn; pay only for MAUs above free tier; built‑in social and SAML/OIDC support; AWS‑managed hosted UI. | Learning curve around User Pools vs Identity Pools and IAM policies.|
|Auth0 | Popular identity platform with SDKs for nearly every framework. | 25,000 MAUs; unlimited social & Okta connections; 5 organizations; 5 actions/forms; passwordless & custom domain | Intuitive, developer‑friendly dashboard; extensible via Rules (JavaScript); excellent documentation. | Pricing increases sharply above free tier.|
|Firebase Authentication | Google’s auth service, part of Firebase/GCP. | Unlimited email/password, anonymous, and most social sign‑ins; pay only for phone‑SMS verification | Fastest setup for web/mobile; pre‑built UI widgets; seamless integration with other Firebase services. | SMS‑based authentication incurs per‑message cost.|
|Supabase Auth | Open‑source Firebase alternative built on PostgreSQL. | Unlimited API requests; 50,000 MAUs; 500 MB database; 5 GB bandwidth; 1 GB file storage; community support | True SQL under the hood; you own your data; robust JS client. | Free projects pause after 1 week of inactivity; limited to 2 active projects.|
|Netlify Identity | Netlify’s built‑in auth service powered by GoTrue. | Up to 1,000 registered users per site | Seamless drop‑in for Netlify‑hosted. | Limited to Netlify sites; basic compared to full‑blown IDaaS; deprecated as of Feb 28, 2025 .|
|Okta Developer Edition | Enterprise‑grade identity platform in a developer sandbox. | 100 MAUs | Enterprise features: OpenID Connect federation, SCIM provisioning, lifecycle hooks, universal directory | Console can feel heavy for hobby projects.|

Recommendations:

Full AWS: Use AWS Cognito (with Amplify libraries) to stay within the AWS ecosystem and enjoy a free tier up to 10 K direct/social MAUs and 50 MAUs for SAML/OIDC.
Rapid prototyping: Firebase Authentication for the fastest setup (unlimited email/password/social; pay only for SMS).
SQL‑power & control: Supabase Auth if you need open‑source Postgres‑based auth with a 50 K MAU free tier and 500 MB of built‑in storage.

For reasons I would not disclose, we picked Firebase for Divooka and other Methodox services.

The Setup

For Firebase Auth, the "API Key" just identifies the application and can totally be shown on the client side script.

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8"/>
  <title>Custom Email/Password Auth</title>
  <script type="module">
    import { initializeApp } from "https://www.gstatic.com/firebasejs/11.8.1/firebase-app.js";
    import {
      getAuth,
      createUserWithEmailAndPassword,
      updateProfile,
      signInWithEmailAndPassword,
      signOut
    } from "https://www.gstatic.com/firebasejs/11.8.1/firebase-auth.js";

    // Firebase web config
    // For Firebase JS SDK v7.20.0 and later, measurementId is optional
    const firebaseConfig = {
        apiKey: "*********************",
        authDomain: "*********************",
        projectId: "*********************",
        storageBucket: "*********************",
        messagingSenderId: "*********************",
        appId: "*********************",
        measurementId: "*********************"
    };
    // Initialize Firebase
    const app = initializeApp(firebaseConfig);
    const auth = getAuth(app);

    // Register a new user
    async function registerUser() {
      const email = document.getElementById("regEmail").value;
      const password = document.getElementById("regPass").value;
      const username = document.getElementById("regName").value;
      try {
        const cred = await createUserWithEmailAndPassword(auth, email, password);
        // Set a displayName on the Firebase user record
        await updateProfile(cred.user, { displayName: username });
        alert("Registration successful! You can now log in.");
      } catch (e) {
        console.error(e);
        alert("Registration error: " + e.message);
      }
    }

    // Login existing user
    async function loginUser() {
      const email = document.getElementById("loginEmail").value;
      const password = document.getElementById("loginPass").value;
      try {
        const cred = await signInWithEmailAndPassword(auth, email, password);
        const idToken = await cred.user.getIdToken();

        // Call your API
        const resp = await fetch("https://myapi.com/profile", {
          headers: { "Authorization": "Bearer " + idToken }
        });
        if (!resp.ok) throw new Error(await resp.text());
        const profile = await resp.json();
        document.getElementById("output").textContent = JSON.stringify(profile, null, 2);
      } catch (e) {
        console.error(e);
        alert("Login error: " + e.message);
      }
    }

    // Logout
    function logoutUser() {
      signOut(auth);
      document.getElementById("output").textContent = "";
      alert("Signed out");
    }

    window.onload = () => {
      document.getElementById("btnRegister").onclick = registerUser;
      document.getElementById("btnLogin").onclick    = loginUser;
      document.getElementById("btnLogout").onclick   = logoutUser;
    };
  </script>
</head>
<body>
  <h2>Register</h2>
  <input id="regName"  type="text"     placeholder="Username"/><br/>
  <input id="regEmail" type="email"    placeholder="Email"/><br/>
  <input id="regPass"  type="password" placeholder="Password"/><br/>
  <button id="btnRegister">Register</button>

  <hr/>

  <h2>Login</h2>
  <input id="loginEmail" type="email"    placeholder="Email"/><br/>
  <input id="loginPass"  type="password" placeholder="Password"/><br/>
  <button id="btnLogin">Log In</button>
  <button id="btnLogout">Log Out</button>

  <h3>Profile:</h3>
  <pre id="output"></pre>
</body>
</html>

Create API Key

To create API key, navigate to the project then find "Add App" in Project Settings, which is a hidden menu.

References

Official doc on API key, which is not very clear without pictures: here

A quick guide to adding wallets like Phantom and Solflare to your Solana DApp.

Sat, 12 Apr 2025 21:13:14 +0000

Integrating Wallets into Your Solana DApp

Why Wallet Integration Is Essential in Solana DApps

In the Solana ecosystem, wallets serve as a user’s digital identity. Unlike traditional apps that rely on usernames and passwords, decentralized applications use wallets for:

Authentication
Signing and submitting transactions
Viewing balances and token ownership
Interacting with smart contracts

Without wallet integration, your DApp will be read-only — users won’t be able to do anything meaningful like stake, mint, or transfer tokens.

Prerequisites and Tools Needed

Before integrating wallets, ensure your environment includes the following:

Development Setup

React (or any JavaScript frontend framework)
Node.js and npm
Basic knowledge of Solana’s architecture

Required Libraries

```bash
npm install @solana/web3.js
npm install @solana/wallet-adapter-react \
            @solana/wallet-adapter-wallets \
            @solana/wallet-adapter-react-ui
```

These libraries allow you to connect to Solana nodes and interact with user wallets.

Understanding Wallet Adapter and Why It Matters

Solana’s Wallet Adapter provides a standardized, plug-and-play interface to support **multiple

wallets** like:
- **Phantom**
- **Solflare**
- **Backpack**
- **Glow**
- **Ledger (hardware)**

It handles the complexities of detecting installed wallets, establishing connections, signing transactions, and disconnecting sessions.

️ Step-by-Step Guide to Integrate Phantom Wallet

⚙️ Step 1: Bootstrap Your React Project

```bash
npx create-react-app solana-wallet-dapp
cd solana-wallet-dapp
```

Install necessary packages:
```bash
npm install @solana/web3.js \
            @solana/wallet-adapter-react \
            @solana/wallet-adapter-wallets \
            @solana/wallet-adapter-react-ui
```

⚙️ Step 2: Create a Wallet Context Provider

```jsx
// WalletContextProvider.js
import {
  ConnectionProvider,
  WalletProvider
} from '@solana/wallet-adapter-react';

import {
  PhantomWalletAdapter,
  SolflareWalletAdapter,
} from '@solana/wallet-adapter-wallets';

import { WalletModalProvider } from '@solana/wallet-adapter-react-ui';
import { clusterApiUrl } from '@solana/web3.js';
import React, { useMemo } from 'react';

require('@solana/wallet-adapter-react-ui/styles.css');

export const WalletContextProvider = ({ children }) => {
  const network = 'devnet'; // Change to 'mainnet-beta' for production
  const endpoint = useMemo(() => clusterApiUrl(network), [network]);

  const wallets = useMemo(() => [
    new PhantomWalletAdapter(),
    new SolflareWalletAdapter(),
  ], []);

  return (
    <ConnectionProvider endpoint={endpoint}>
      <WalletProvider wallets={wallets} autoConnect>
        <WalletModalProvider>{children}</WalletModalProvider>
      </WalletProvider>
    </ConnectionProvider>
  );
};
```

⚙️ Step 3: Wrap Your App with Wallet Provider

In `index.js`, wrap your `<App />` component:

```jsx
import React from 'react';
import ReactDOM from 'react-dom';
import App from './App';
import { WalletContextProvider } from './WalletContextProvider';

ReactDOM.render(
  <React.StrictMode>
    <WalletContextProvider>
      <App />
    </WalletContextProvider>
  </React.StrictMode>,
  document.getElementById('root')
);
```

⚙️ Step 4: Display Connect Wallet Button

Use the built-in WalletMultiButton:

```jsx
// App.js
import { WalletMultiButton } from '@solana/wallet-adapter-react-ui';

function App() {
  return (
    <div style={{ padding: '2rem' }}>
      <h1> Solana Wallet DApp</h1>
      <WalletMultiButton />
    </div>
  );
}

export default App;
```

This button dynamically shows installed wallets like Phantom and handles connection/disconnection automatically.

Bonus: Send SOL From Connected Wallet

Add a component to send SOL from the connected wallet to another address:

```jsx
import {
  useWallet,
  useConnection
} from '@solana/wallet-adapter-react';
import {
  LAMPORTS_PER_SOL,
  Transaction,
  SystemProgram,
  PublicKey
} from '@solana/web3.js';

const SendSol = () => {
  const { connection } = useConnection();
  const { publicKey, sendTransaction } = useWallet();

  const handleSend = async () => {
    if (!publicKey) return alert("Connect your wallet first!");

    const transaction = new Transaction().add(
      SystemProgram.transfer({
        fromPubkey: publicKey,
        toPubkey: new PublicKey("DestinationPublicKeyHere"),
        lamports: 0.01 * LAMPORTS_PER_SOL,
      })
    );

    const signature = await sendTransaction(transaction, connection);
    await connection.confirmTransaction(signature, 'processed');

    alert("Transaction successful: " + signature);
  };

  return <button onClick={handleSend}>Send 0.01 SOL</button>;
};
```

Other Wallets You Can Integrate

Solana supports a wide ecosystem of wallets. With Wallet Adapter, you can plug in:

Glow
Solong
Torus
Ledger hardware wallets
Backpack (XNFTs)

Each wallet has different capabilities — such as hardware security or mobile support.

Official Resources

✅ Best Practices

Detect wallet availability before rendering connect buttons.
Show user feedback on network connection (e.g., devnet vs mainnet).
Use tooltips or modals to explain wallet permissions.
Always check for publicKey before sending transactions.

Conclusion

Integrating wallets into your Solana DApp is a must-have feature for real blockchain interactions. With libraries like wallet-adapter and web3.js, you can easily implement secure, scalable wallet connectivity.

By empowering users to authenticate and transact through their wallets, you create a truly decentralized, user-driven experience — the essence of Web3.

✨ The more seamless the wallet connection, the higher the user trust and engagement in your DApp.

A Beginner's Guide to Authentication: Best Practices and Key Concepts

Sun, 02 Mar 2025 02:11:50 +0000

Have you ever wondered how websites or apps know that it's really you logging in? Or how they keep your data secure when you sign in? Authentication is the process that makes this possible, ensuring that users are who they claim to be. In today's digital world, understanding authentication is crucial for developers and users alike. This guide will take you through the basics of authentication, its types, and how it plays a key role in securing web applications.

What is Authentication?

Authentication is the process of verifying the identity of a user, device, or system. It's a fundamental aspect of security in computing, ensuring that only authorized users can access specific resources. Without proper authentication, websites and applications would be vulnerable to unauthorized access and data breaches.

Why is Authentication Important?

Authentication is important because it acts as the first line of defense against cyberattacks. If a user's identity is not verified correctly, sensitive information or actions could be accessed or manipulated by malicious actors. It also helps maintain privacy and control over personal data, which is crucial in today's online environment.

Types of Authentication

Authentication can be classified into different types, based on how the user proves their identity.

Password-based Authentication

The most common form of authentication, where users log in using a username and a password.
While convenient, passwords can be vulnerable to theft if not handled securely.

Two-Factor Authentication (2FA)

This requires two forms of identification: something you know (e.g., a password) and something you have (e.g., a phone or hardware token).
It adds an extra layer of security by requiring a second form of validation.

Biometric Authentication

Uses physical characteristics like fingerprints, facial recognition, or retina scans.
Often used in mobile devices, biometrics are more difficult to replicate, making them highly secure.

OAuth Authentication

Used when logging in through third-party services like Google or Facebook.
Instead of using a password, you grant the application access through the third-party service's authentication system.

Single Sign-On (SSO)

A method where users log in once to gain access to multiple applications.
Great for improving user experience while maintaining security.

Authentication Factors and Technologies

Authentication is built on different factors, which are categorized as follows:

Something You Know:

Passwords, PINs, or passphrases.

Something You Have:

A mobile device (for SMS or app-based codes), smartcards, or hardware tokens.

Something You Are:

Biometric data such as fingerprints or voice recognition.

Technologies in Authentication

Password Hashing and Salting: Protects stored passwords by converting them into an unreadable format.
JWT (JSON Web Tokens): A compact way of securely transmitting information between parties. Often used in token-based authentication.
OAuth and OpenID Connect: Protocols for secure, token-based authentication.

Authentication in Web Development

Authentication plays a key role in both the frontend and backend of web development.

Frontend Authentication

The frontend is where the user interacts with the application. It collects input, like login credentials, and sends them to the backend for validation.
Example: A user submits a login form with their username and password, which is sent to the server for verification.

Backend Authentication

The backend handles the actual authentication process, such as validating credentials, generating tokens, and ensuring secure storage of user data.
Example: The server checks the submitted password against a hashed password stored in a database, then creates a session or JWT token for the user.

Authentication Process

Signup / register/join/create account: The process where a new user creates an account by providing a username, password, and possibly other personal information.
Sign-in/login: To verify a user's identity and use their credentials (username and password) to access their account.
Password Recovery/forgot password/reset password: If a user forgets their password, a recovery process (via email or SMS) is initiated to allow them to reset it and regain access to their account.

Security Best Practices for Web Application Authentication

To keep your web application secure, it's important to follow the best practices for authentication:

Use Strong Passwords
Encourage users to create strong, unique passwords by combining letters, numbers, and special characters.
Implement Multi-Factor Authentication (MFA)
Adding a second layer of authentication significantly reduces the risk of unauthorized access eg Password + Authenticator App, and Password + SMS Text Code
Use HTTPS
Always encrypt your website with HTTPS to protect the data being transmitted between the client and server.
Hash Passwords Properly
Never store passwords in plaintext. Use hashing algorithms like bcrypt or Argon2 to securely store passwords.
Limit Login Attempts
Implement account lockout or CAPTCHA after several failed login attempts to prevent brute-force attacks.
Secure Tokens
For token-based authentication, ensure tokens are stored securely and have a short expiration time.
Session Management
Ensure secure session management practices, such as invalidating sessions on logout and using secure cookies.

Common Challenges and Solutions

Weak Passwords

Solution: Enforce strong password policies and encourage the use of password managers.

Session Hijacking

Solution: Use secure cookie flags and ensure tokens are stored safely.

Phishing Attacks

Solution: Implement 2FA and educate users about phishing scams.

Advanced Techniques and Additional Considerations

For advanced users or developers, consider these approaches to enhance authentication security:

Adaptive Authentication

Use machine learning or risk-based authentication to adjust security measures based on user behavior, location, or device.

Federated Identity Management

Utilize SSO (Single Sign-On) and other federated identity systems to allow users to log in across multiple applications with one identity.

Biometric Authentication in Web Apps

Explore WebAuthn and FIDO2 standards to implement biometric authentication in web browsers.

Conclusion

Authentication is a critical part of securing web applications. By understanding the different types of authentication, factors, and best practices, you can ensure that your applications remain secure while offering a smooth user experience. Start implementing these strategies in your development projects today, and always stay ahead of the latest security trends to protect user data and prevent unauthorized access.

Ready to level up your web app's security? Start applying these authentication techniques today and share your thoughts in the comments below!

Coder Legion - Recent posts tagged authentication

Lock Your Inbox: Email 2FA, Passkeys and App Passwords

TL;DR

Why the Inbox Is the Wrong Thing to Secure Casually

What People Mean When They Talk About 2FA

What a Passkey Actually Is

App Passwords: The Back Door You Opened Yourself

Recovery Codes Are the Part Everyone Skips

The Windows You Left Open

Turning It On

The Twenty-Minute Version

One Number Before You Go

Building Verifiable Bounty Payments and Revocable Account Sessions at MyZubster Over the latest MyZu

Engineering MyZubster: Verifiable Crypto Settlements, Refresh-Token Rotation, Revocable Sessions, and Cross-Mongoose Runtime Hardening

1. The Systems We Changed

Treasury and bounty settlement

Authentication and account security

Part I — Verifiable Cryptocurrency Bounty Settlement

2. Moving Beyond “A Transaction Was Sent”

3. Separating Verification From Persistence

4. Idempotent Conversion Recording

5. Provider Boundary for Settlement Observability

Part II — Revocable Authentication Sessions

6. Why JWT Validation Alone Was Not Enough

7. Refresh Tokens Became Opaque, Persistent, and Rotating

8. Atomic Rotation

9. Refresh Replay Detection

10. Frontend Refresh Deduplication

Part III — Account Security

11. Session Management API

12. Active Device Management

13. Session Metadata and Privacy

Part IV — Authentication Recovery in the Metaverse

14. A Renewable Authenticated Fetch Layer

15. Terminal Expiry Events

16. Preserving the Intended Destination

Part V — CSRF Protection

17. Cookies Changed the Threat Model

18. Origin, Referer, and Fetch Metadata

Part VI — Structured Authentication Errors

19. Error Codes Instead of Raw Cryptographic Errors

Part VII — The Mongoose/BSON Failure We Found During Testing

20. The Initial Symptom

21. Two Mongoose Runtimes in One Process

22. Connecting Both Runtimes Revealed the Deeper Problem

23. Model Factory as the Boundary Repair

24. Why This Matters Beyond Tests

Part VIII — Repairing Source Corruption

25. UTF-8 and Control-Character Validation

26. JavaScript String Parsing Failure

Part IX — Validation

27. Backend Final Gate

28. Frontend Final Gate

29. Production Build

30. Git Integrity Gate

Part X — What Is Operational Now

31. Treasury

32. Authentication

Part XI — Security Properties Achieved

Server authority over sessions

Single-use refresh credentials

Replay detection

No raw refresh-token persistence

Client/server concurrency alignment

Remote session revocation

Cookie mutation protection

Structured auth failures

Safe return navigation

Explicit ODM runtime ownership

Replay-safe treasury persistence

Part XII — What We Deliberately Did Not Claim

Conclusion

How We Built Revocable Sessions and Refresh-Token Replay Protection for the MyZubster Metaverse

Spring Boot Authentication Boilerplate: From JWT Basics to Production-Ready Auth

The auth code isn't the interesting part

AuthKit Lite

When Lite isn't enough

Lite or Pro?

Why a boilerplate?

How to Authenticate Users with Solana Wallets in NestJS

Step 2: Build JWT-Based Auth with `jose`

Add an optimistic check in `proxy.ts`

Does `proxy.ts` need to fully verify the session on every request?