Forem: Tấn Trương

When OTP Becomes a Spam Goldmine — And How to Stop It with One Shift

Tấn Trương — Fri, 24 Apr 2026 01:27:51 +0000

When OTP Becomes a Spam Goldmine — And How to Stop It with One Shift

There’s a paradox in modern authentication that anyone who has worked with OTP systems long enough will eventually notice:

The very mechanism designed to secure users can also be weaponized at scale.

Part 1 — The Zalo Story

Take a platform like Zalo.

They fully understand how OTP can be abused — because they’ve lived through it. There was a time when users were heavily spammed with OTP messages. Not because the system was weak, but because the mechanism itself was exploitable.

If you expose an endpoint that sends OTP → it will be abused.

No matter how many rate limits or CAPTCHA layers you add, attackers adapt:

Rotate IPs
Simulate devices
Distribute requests across sessions

Eventually, the cost of defense becomes higher than the cost of attack.

So what did they do?

They shifted the model.

Instead of sending OTP outward (SMS), they introduced user-initiated flows like inbound voice OTP. No outbound API → no spam vector.

But here’s the irony.

As a platform, they reduce OTP abuse.
As a service provider, they still offer ZNS OTP — now costing ~440 VND per message.

Which reveals an uncomfortable truth:

Outbound OTP is both a security feature and a monetizable surface — even though it’s also the root of the spam problem.

Part 2 — The Real Threat: Cross-App Abuse

Modern OTP spam isn’t sophisticated.

It’s industrialized.

There are public tools, tutorials, even ready-to-run scripts. Anyone can do it.

And the most dangerous part?

Attackers don’t target just one system.

They exploit the same OTP logic across hundreds of apps.

Even if:

App A limits 1 OTP per phone number
App B does the same
App C does the same

An attacker can still trigger:

100 OTP messages → to the same victim → from 100 different apps

Each request:

Comes from a different IP
Uses a different device fingerprint
Runs in a separate session

From the perspective of each system, everything looks legitimate.

So traditional defenses fail — not because they’re bad, but because:

You’re trying to solve an ecosystem-level problem at a system level.

Part 3 — The Global Product Reality

If you’re building for international users, SMS OTP becomes even worse.

You quickly realize this isn’t just a technical problem — it’s a regulatory maze:

Some countries require sender registration
Some filter or rewrite content
Some delay messages unpredictably
Some block entire routes without notice

At scale, OTP delivery turns into a compliance + telecom negotiation problem, not engineering.

Part 4 — The One Shift That Changes Everything

Here’s the core insight:

Stop sending OTP. Start making users request it.

This sounds trivial, but it changes the entire threat model.

Old model (vulnerable)

Server sends OTP → user receives
Attack surface = public API

New model (resilient)

User initiates authentication
Server responds only to verified intent

Examples:

Inbound call OTP
App-based approval (push)
TOTP (Google Authenticator-style)
Deep link / magic link
Device binding

Now the attacker has a harder problem:

They must control the user interaction channel
Not just spam an API

That’s a completely different game.

Final Thought

OTP spam is not a bug.

It’s a business + architecture side-effect.

As long as:

Sending OTP is easy
And costs are externalized
And APIs remain public

It will continue to be abused.

You can keep adding layers (rate limit, CAPTCHA, fingerprinting)...
Or you can change the model entirely.

Sometimes the most effective fix isn’t optimization — it’s elimination.

If you're building auth for a real-time product or scaling globally, this is not an edge case.

It's inevitable.

The only question is:
Do you design for it early — or react when it becomes a problem?

Authentication Mechanisms: JWT, OAuth, and Single Sign-On (SSO)

Tấn Trương — Thu, 23 Apr 2026 02:35:34 +0000

Introduction

In modern application development, securing user authentication is a foundational requirement. As systems scale and threats become more sophisticated, choosing the right authentication and authorization strategy becomes critical.

Three widely adopted approaches are JWT (JSON Web Token), OAuth 2.0, and Single Sign-On (SSO). While often mentioned together, they solve different problems and are frequently used in combination.

This article provides a clear, practical comparison along with system flows and best practices.

Authentication vs Authorization

Before diving deeper:

Authentication: Who are you?
Authorization: What are you allowed to do?

A secure system must enforce both.

JWT (JSON Web Token)

What is JWT?

JWT is a compact, URL-safe token used to transmit claims between client and server. It is commonly used for stateless authentication.

Structure

A JWT consists of three parts:

Header.Payload.Signature

Header: Algorithm (HS256, RS256)
Payload: Claims (user_id, role, exp)
Signature: Integrity verification

Flow

User → Login → Server
Server → Generate JWT → Client
Client → Attach JWT → API
API → Verify JWT → Response

Pros

Stateless (no session storage)
Scales well in microservices
Fast verification

Cons

Hard to revoke
Token leakage risk

Best Practices

Short-lived access tokens
Use HTTP-only cookies
Avoid sensitive payload data
Implement refresh token strategy

OAuth 2.0

What is OAuth?

OAuth 2.0 is a protocol for delegated authorization. It allows applications to access user data without exposing credentials.

Roles

Resource Owner (User)
Client (App)
Authorization Server
Resource Server

Flow

User → Login + Consent → Authorization Server
Authorization Server → Access Token → Client
Client → API Request → Resource Server
Resource Server → Validate Token → Response

Grant Types

Authorization Code (recommended)
Client Credentials
Implicit (deprecated)
Password (legacy)

Best Practices

Use Authorization Code + PKCE
Never expose client secret
Validate redirect URIs
Use refresh tokens

Single Sign-On (SSO)

What is SSO?

SSO allows users to log in once and access multiple applications without re-authentication.

Flow

        [ SSO Provider ]
               │
     ┌─────────┼─────────┐
     ▼         ▼         ▼
  App A     App B     App C

Technologies

SAML (enterprise)
OpenID Connect (modern, built on OAuth)

Pros

Better user experience
Centralized access control

Cons

Single point of failure
Higher complexity

Best Practices

Enforce MFA
Implement RBAC
Monitor and audit logs

Comparison Table

Criteria	JWT	OAuth 2.0	SSO
Purpose	Authentication	Authorization	Central Authentication
State	Stateless	Token-based	Session-based
Use Case	APIs, microservices	Third-party access	Multi-app systems
Complexity	Low	Medium	High
Scalability	High	High	Medium
Revocation	Difficult	Managed by auth server	Centralized

Real-World Architecture (Recommended)

Client
  │
  ├── Access Token (JWT - short-lived)
  ├── Refresh Token (stored in DB)
  │
Backend
  ├── Verify JWT
  ├── Manage session / revoke
  ├── Integrate OAuth providers
  │
SSO Provider (optional)

Key Ideas

Use JWT for performance
Store refresh tokens in database (revocable)
Route all API calls through backend
Track device/session for security

Conclusion

There is no one-size-fits-all solution:

Use JWT for stateless APIs
Use OAuth 2.0 for third-party integrations
Use SSO for unified login across systems

In practice, modern systems combine all three to achieve both security and scalability.