When building APIs, one important question always comes up:

“How does the server know who is sending the request?”

This is solved using authentication systems.

Let’s understand it in a simple way.

---

🧭 1. The Basic Idea of API Authentication

Whenever a user logs in:

1. User sends email + password
2. Server checks if they are correct
3. Server gives a token
4. User sends that token with every request
5. Server checks the token every time

Example request:

Authorization: Bearer abc123

If token is valid → user is allowed
If not → request is rejected

---

🔐 2. Laravel Sanctum (Simple Token System)

Sanctum is a popular Laravel package for API authentication.

How it works:

Step 1: Login

User sends:

{
  "email": "test@example.com",
  "password": "123456"
}

Server:

• checks credentials
• creates a token
• stores it in database

---

Step 2: Token is returned

{
  "token": "1|abc123xyz"
}

---

Step 3: Client sends token in every request

Authorization: Bearer 1|abc123xyz

---

Step 4: Server verifies token every time

Server:

• finds token in database
• checks if it is valid
• allows or denies request

---

⚠️ Important point

Even if login is done once, the server still checks the token on every request.

Why?

Because:

• tokens can be stolen
• users can logout
• access must be controlled continuously

---

🧠 3. Is this slow?

Not really.

Each request does:

• small database lookup (fast index search)
• simple comparison

This usually takes milliseconds.

So performance impact is very low.

---

🔐 4. Password Reset Tokens (Similar Idea)

Password reset also uses tokens, but differently.

Flow:

1. User clicks “Forgot Password”
2. Server generates reset token
3. Token is stored in database (hashed)
4. Email is sent with reset link

Example:

https://site.com/reset?token=abc123

---

When user clicks link:

Server checks:

• Is token valid?
• Is it expired?

If yes → allow password reset

---

Difference from Sanctum

Feature	Sanctum Token	Reset Token
Purpose	Login authentication	Password recovery
Usage	Many requests	One-time use
Lifetime	Long-lived	Short-lived
Reusable	Yes	No

---

🔄 5. Why Do We Check Tokens Every Time?

Because API systems are usually stateless:

Server does not remember past requests.

So every request must prove identity again.

Otherwise:

• stolen token = full access forever
• logout would not work
• security becomes weak

---

⚖️ 6. Other Authentication Methods

Different systems exist because different apps have different needs.

---

🍪 Session Authentication (Traditional websites)

Used in normal websites.

• Server stores login session
• Browser sends cookie automatically

✔ Pros:

• very secure
• easy logout

❌ Cons:

• needs server storage

---

🎫 JWT (JSON Web Token)

Used in large scalable APIs.

• token contains user info
• no database lookup required

✔ Pros:

• very fast
• scalable

❌ Cons:

• hard to revoke immediately
• less control

---

🔐 OAuth (Google login, Facebook login)

Used for third-party login systems.

• complex but standard
• supports permissions (scopes)

---

🧠 7. Why so many methods exist?

Because no single system is perfect.

Each one balances:

• speed ⚡
• security 🔒
• control 🎛️
• scalability 🌍

---

🚀 Simple Analogy

Think of authentication like transport:

• 🛵 Sanctum → simple scooter (easy & practical)
• 🚗 Sessions → secure car (controlled & safe)
• ✈️ JWT → airplane (fast & scalable)
• 🏢 OAuth → airport system (complex but standardized)

---

📌 Final Summary

• API authentication = proving identity using tokens
• Sanctum uses database-stored tokens
• Tokens are checked on every request for security
• Password reset uses similar token concept but one-time use
• Other systems exist for performance, scale, or special use cases