API接口安全认证方案对比：Token、JWT与OAuth怎么选

一个前后端分离的网站，前端调后端接口拿数据，第三方调开放平台接口对接业务。这些接口如果没有认证机制，等于把数据库直接暴露在公网上。谁都能调，谁都能拿数据。

API认证方案市面上主要有三种：自定义Token、JWT、OAuth 2.0。没有绝对的好坏，但有明确的适用边界。选错了不是安全问题就是开发量爆炸。

一、自定义Token：简单直接

实现方式很朴素：用户登录成功后，服务端生成一个随机字符串作为Token，存到Redis里，设过期时间。后续请求带上这个Token，服务端查Redis验证有效性。

优点是实现简单，吊销方便——直接从Redis删掉就行。缺点是依赖Redis，分布式场景下要做会话同步。而且Token本身不携带任何用户信息，每次验证都要查一次存储。

适用场景：单体应用、内部系统、接口量不大的项目。如果就十几个接口、几百个用户，别折腾，自定义Token够用了。

二、JWT：无状态的利器

JWT（JSON Web Token）把用户信息编码在Token里，服务端拿到Token后用密钥验签，不需要查存储。天然适合分布式和微服务架构。

但JWT的缺点也很明显——无法主动吊销。Token签发后到过期之前一直有效，用户退出登录或被封号后Token还能用。解决方案有两个：一是缩短过期时间（比如15分钟），配合Refresh Token续期；二是维护一个黑名单，每次验签时检查Token是否在黑名单中，但这样又引入了状态依赖。

JWT的Payload里千万别放敏感信息。虽然做了Base64编码，但那是编码不是加密，任何人都能解码。放用户ID和角色就够了，手机号身份证号一律不放。

签名算法必须用RS256或ES256，不要用HS256。HS256是对称签名，签发和验证用同一个密钥，一旦密钥泄露攻击者可以伪造任意Token。RS256用非对称密钥，私钥签发公钥验证，安全性高一个量级。

三、OAuth 2.0：开放场景的标准

如果你的接口需要给第三方使用——比如开放平台、小程序对接、第三方登录——那必须上OAuth 2.0。它定义了一套完整的授权流程，用户不需要把密码给第三方，而是通过授权码换取访问令牌。

OAuth 2.0有四种授权模式，最常用的是授权码模式（Authorization Code），安全性最高。隐式模式已经不推荐使用，密码模式只在高度可信的客户端使用。

实施OAuth 2.0要注意几个安全点：redirect_uri必须做白名单校验，防止授权码被劫持到攻击者控制的服务器；state参数必须验证，防止CSRF攻击；access_token的有效期建议2小时以内，refresh_token建议7天。

选型其实不复杂：自己系统内部用JWT，给第三方开放用OAuth，简单单体项目用自定义Token。怕的不是选错方案，怕的是选了JWT却不处理吊销问题，选了OAuth却不校验redirect_uri。方案本身都成熟，工程实现到位才是关键。