无状态 API 之权限验证

说起无状态(stateless) API 的权限问题, 首先我们来回顾一下有状态 API 是如何做权限验证的.一般来说传统的权限验证有三大类:

Auth1:

1. 客户端发起 login 请求, 带上login 参数

2. 服务端验证后在 response 中带上唯一的 token 值

3. 客户端每次请求带上 token (一般来说可以设置在 cookie 中)

4. 服务端拿到 token 验证权限

Auth2:

1. 客户端发起 login 请求, 带上login 参数

2. 服务端验证后在 response 中带上唯一的 token 值

3. 客户端每次请求 Header 中 Authentication 带上 token

4. 服务端拿到 token 验证权限

Auth3:

1. 客户端发起 login 请求, 带上login 参数

2. 服务端验证后在 response 中设置 sessionId 在 cookie 中

3. 客户端每次请求带上 cookie 中的 sessionId

4. 服务端拿到sessionId 可以找到客户端的 session 信息

Auth1和 Auth2的区别很小, 在于 token 存储的位置, 而 Auth3 明显是传统的使用了 session 保存信息.

那么问题来了, 为什么会要有无状态的 API 呢?什么是无状态的呢?

我们可以看出, 不管是 token 还是 session, 服务端总会花销资源来保存他们, 如果有1万个客户端, 服务端将生成1万条 token 并保存起来等待验证. 客户端越多, 服务端开销越大, 查询也会消耗时间等等…

无状态的 API 就此诞生了, 它要求客户端每次请求不再带上类似 token, sessionId 的东西, 每次请求都是一样的, 服务端也不会存储任何保持会话的信息. 这样无疑是解放了服务端.

那么问题又出现了, 我们如何来保证 API 调用的安全性,也就是权限问题?

答案就是每次请求的时候都把 login 的信息传给服务器. 天呐?!那我岂不是每个 API 都要重新调用 login 的方法? 查询数据库用户是否存在? 答案肯定是否定的.

这里有两种解决方案:

方案一:

1. 客户端发起 login 请求, 带上login 参数

2. 服务端验证后, 在 response 中带上由请求参数加密而来的不可解密字段 (加密方法有很多种, 这里不再累赘, 但切记不要用类似 MD5这种大众方法)

3. 客户端再次发起请求, 带上 login 参数和加密字段

4. 服务端验证客户端传来的加密字段是否与传来的 login 参数再次加密得到的字段相同

方案二:

1. 客户端发起 login 请求, 带上login 参数

2. 服务端验证后, 在 response 中带上由请求参数加密而来的可解密字段 (网上有很多对称加密, 密钥加密等等, 这里不再累赘)

3. 客户端再次发起请求, 带上可解密的加密字段

4. 服务端解密成功后的参数格式正确, 即视为验证成功