HTTP API 身份认证
互联网系统通常需要根据用户身份决定是否有资源的访问权限,这就需要对用户进行身份认证(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 头)中发送,从而完成认证。此类方式无需用户界面,适合脚本、服务间通信等非交互式场景。