常见的身份验证机制（sessions、JWT、OAuth）有哪些？

Question

Accepted Answer

现代应用使用各种**身份验证机制**——基于会话的、基于令牌的（JWT）和委托式身份验证（OAuth/OpenID Connect）。理解每种机制的工作原理及其权衡对于实现安全的身份验证很重要。

## 基于会话的身份验证

```text
SESSION-based (traditional):
  → user logs in → server creates a SESSION (stored server-side) → sends a session ID
    cookie → the browser sends it with each request → server looks up the session
  ✓ server controls sessions (easy to revoke); simple; cookie auto-sent
  ✗ stateful (server stores sessions); scaling needs shared session storage
```

## 基于令牌的（JWT）

```text
JWT (JSON Web Token):
  → user logs in → server issues a SIGNED token containing claims (user id, etc.) →
    client stores it → sends it (usually in an Authorization header) per request →
    server VERIFIES the SIGNATURE (no server-side lookup needed)
  ✓ STATELESS (scales easily; no session store); works well for APIs/SPAs/mobile
  ✗ hard to REVOKE before expiry (it's self-contained) → use short expiry + refresh tokens
  ⚠️ store securely; don't put secrets in the (readable) payload; validate properly
```

## OAuth 2.0 / OpenID Connect

```text
OAUTH 2.0 → DELEGATED AUTHORIZATION ("Log in with Google/GitHub"):
  → let users authenticate via a third party without sharing their password with your app
  → your app gets a token to access permitted resources (scoped)
OPENID CONNECT (on top of OAuth) → adds AUTHENTICATION (identity) → standard for SSO/
  social login
→ delegate auth to trusted providers; users don't create another password.
```

## 为什么这很重要

理解常见的身份验证机制很重要，因为**身份验证是大多数应用的基础**，选择和正确实现它会影响安全性和架构，因此这是宝贵的知识。

主要机制各有特点和权衡。**基于会话的身份验证**（带有会话ID cookie的服务器端会话）给服务器对会话的控制权（易于撤销），但是是有状态的（需要共享会话存储来扩展）。**JWT（基于令牌的）身份验证**（签名的自包含令牌，无需服务器查询即可验证）**是无状态的**（易于扩展，适用于API、SPA和移动应用），但有一个显著的权衡，即**令牌难以在过期前撤销**（因为它们是自包含的，需要短期过期加上刷新令牌），并且必须安全地存储，在可读的负载中不包含任何秘密——理解这些JWT注意事项很重要，因为JWT很常见，但常常被误用。**OAuth 2.0和OpenID Connect**（委托式身份验证——