互联网系统通常需要根据用户身份决定是否有资源的访问权限，这就需要对用户进行身份认证（Authentication），验证用户所声称的身份。验证手段通常是验证只有用户知道或拥有的东西，比如密码、手机号、指纹等。
基于浏览器的认证
- 在没有 JavaScript 的时代，认证由浏览器根据 HTTP 协议实现（约 1993 年），使用的是 HTTP Basic Authentication，登录界面由浏览器自动生成，无法自定义。由于此时浏览器页面无法存储状态，HTTP 服务端也通常只能提供无状态服务。认证信息通过浏览器内核添加到 HTTP Header 中发送给服务端。
- 1994 年发明了 Cookie，使得 HTTP 服务端可以通过 Cookie 实现有状态会话管理。此时可通过
<form>表单提交用户名和密码，由服务端生成 Session 并将其标识（Session ID）存储在 Cookie 中返回客户端，浏览器在后续请求中自动携带该 Cookie，从而实现有状态交互。此阶段状态由浏览器内核管理，页面应用本身仍无法持久存储状态。
1995 年 JavaScript 出现后，开发者获得了对 HTTP 请求的控制能力（例如使用 XMLHttpRequest），并能在客户端使用本地存储（如 LocalStorage、SessionStorage）。此时可以通过 JavaScript 控制认证流程，将 Token（如 Session ID、JWT 等）存储并注入到请求 Header 中，实现更灵活的前端控制和单页面应用（SPA）逻辑。
2012 年左右，第三方认证需求日益强烈，OAuth 2.0 架构被广泛采用。OAuth 将原有服务端职责拆分为授权服务器（Authorization Server）、令牌端点（Token Endpoint）、资源服务器（Resource Server）。页面应用可以通过标准的重定向流程（Authorization Code Flow 等）在无 JavaScript 环境下完成认证，并获取访问第三方资源的 Token。
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+
Figure 1: Abstract Protocol Flow
- 随着微服务的兴起（约 2014 年以后），传统的有状态 Session 模式难以横向扩展。为支持分布式系统的无状态认证，JSON Web Token（JWT）被广泛应用。JWT 将认证信息自包含于 Token 中，服务端无需存储会话状态，便可验证请求者身份。
无浏览器的认证
- 2000 年左右，为支持 API 的程序化访问，出现了 API Token 认证方式。客户端直接将 Token（如 API Key）放入 HTTP Header（通常为 Authorization 头）中发送，从而完成认证。此类方式无需用户界面，适合脚本、服务间通信等非交互式场景。