细说API – 认证、授权和凭证

生成JWT 令牌的流程为

1. header json 的 base64 编码为令牌第一部分
2. payload json 的 base64 编码为令牌第二部分
3. 拼装第一、第二部分编码后的 json 以及 secret 进行签名的令牌的第三部分

因此只需要签名的 secret key 就能校验 JWT 令牌，如果在消息体中加入用户 ID、过期信息就可以实现验证令牌是否有效、过期了，无需从数据库/缓存中读取信息。因为使用了加密算法，所以第一、二部分即使被修改(包括过期信息)也无法通过验证。JWT 优点是不仅可以作为 token 使用，同时也可以承载一些必要信息，省去多次查询。

注意：

1. JWT token 的第一、二部分只是 base64 编码，肉眼不可读，不应当存放敏感信息
2. JWT token 的自包含特性，导致了无法被撤回
3. JWT 的签名算法可以自己拟定，为了便于调试，本地环境可以使用对称加密算法，生产环境建议使用非对称加密算法

JWT token 在微服务的系统中优势特别突出。多层调用的 API 中可以直接传递 JWT token，利用自包含的能力，可以减少用户信息查询次数;更重要的是，使用非对称的加密方式可以通过在系统中分发密匙的方式验证 JWT token。

当然 OAuth 对 access token 等凭证所选用的技术并没有做出限制，OAuth 并不强制使用 JWT，在使用 JWT 自包含特性的优势时，必须考虑到 JWT 撤回困难的问题。在一些对撤回 token 要求很高的项目中不适合使用JWT，即使采用了一些方案实现(whitelist 和 blacklist)也违背了设计 JWT 的初衷。

Cookie 、Token in Cookie、Session Token 依然被使用

在构建 API 时，开发者会发现我们的认证方式和网页应用有一些不同，除了像 ajax 这种典型的 web 技术外，如果我们希望 API 是无状态的，不推荐使用 Cookie。

使用 Cookie 的本质是用户第一次访问时服务器会分配一个 Session ID，后面的请求中客户端都会带上这个 ID 作为当前用户的标志，因为 HTTP 本身是无状态的，Cookie 属于一种内建于浏览器中实现状态的方式。如果我们的 API 是用来给客户端使用的，强行要求 API 的调用者管理Cookie 也可以完成任务。

在一些遗留或者不是标准的认证实现的项目中，我们依然可以看到这些做法，快速地实现认证。

使用 cookie，例如 web 项目中 ajax 的方式

使用 session ID 或 hash 作为 token，但将 token 放入 header 中传递

将生成的 token (可能是JWT)放入 cookie 传递，利用 HTTPonly 和 Secure 标签保护 token

选择合适的认证方式

随着微服务的发展，API 的设计不仅仅是面向 WEB 或者 Mobile APP，还有BFF(Backend for Frontend)和 Domain API 的认证，以及第三方服务的集成。

客户端到服务器之间认证和服务器到服务器之间认证是不同的。

我们把终端用户(Human)参与的通信，叫做 Human-to-machine (H2M)，服务器与服务器之间的通信叫做 Machine-to-machine (M2M)。

H2M 的通信需要更高的安全性，M2M 的通信天然比 H2M 安全，因此更多的强调性能，在不同的场合下选择合适的认证技术就显得特别重要。例如 HTTP Basic Authentication 用来作为 H2M 认证显得有些落后，但是在 M2M 中被大量使用。

另外值得一提的是，H2M 这种通信方式下，客户端不受控制，由于无法自主分发密匙，认证通信的安全高度依赖 HTTPS。

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!