3种基础的REST 安全机制，大家用了吗？

2019-12-30

来自：杜亦舒性能与架构

安全是 RESTful web service 的基石，我们主要讨论以下3种主要的方法：

1. Basic authentication

这是最古老、最简单的方法。

username + password + Base64。

假设一个用户要登录 Facebook 账号，查看：feed 流、消息、好友、组，这4个服务都是独立的。

用户提交用户名密码之后，系统验证后允许进入，然而系统是不知道其角色和权限的，例如什么服务允许访问。

所以，每次用户访问任何服务时，系统需要再次验证是否允许此次操作，这意味着需要一次对授权服务器的额外调用。例如上面的4个服务，那么每个用户就会有4次额外调用。

现在想象每秒我们有 3000 个用户访问，乘以4个服务，结果就是每秒 12000 次授权服务器调用。

可扩展性差，有大量的没有商业价值的额外调用，显著增加了服务器的压力。

username + password + access token + expiration token

用户使用用户名密码登录系统之后，会收到一对 token，一个 access token 和一个 refresh token。

access token 用于访问所有服务，过期时，使用 refresh token 产生一对新的 token。

如果一个用户每天都进入系统，token 会每天更新，不必每次使用用户名密码登录。

refresh token 也有过期周期，过期后需要再次使用用户名密码登录。

Oauth 2.0 用来替换 Basic authentication，有其明显的优势，例如用户不必每次都提交用户名密码，然而，系统仍然需要调用授权服务器，来检查 token 所属用户能做的操作。

假设过期时间是一天，可以大大减少登录服务器的负载，因为一个用户一天只需要登录验证一次，而不是每次进入系统时都需要。

但是，系统仍然需要去存储状态的地方去验证每个 token，查看用户的角色。

所以，最后还是需要多次调用授权服务器。

和 Basic authentication 有同样的问题，扩展性差，授权服务器会有大量负载。

username + password + JSON map + Base64 + private key + expiration date

用户第一次使用用户名密码登录系统后，系统不仅返回一个 access token，而且还有一个 JSON map，其中包含所有的用户信息，例如角色和权限，这些信息是使用 Base64 编码的，并使用私钥加密。

在 token 中存储了状态信息，使服务是无状态的。

用户自己拿着自己的信息，所有信息都在 token 里面，所以就不需要额外的调用了。

这对减少服务器的负载起到了巨大的作用，现在这个方法在世界范围内被广泛使用。

扩展性好，非常适合微服务。

在用户创建亚马逊账号的时候，会生成一个永久的、超级安全的 access token，需要用户保护好。

当用户需要请求亚马逊的时候，需要使用这个私有的 token 对 HTTP header 数据进行签名，并添加到 header 中一起发送过去。

服务器端，亚马逊也有用户的这个私有 token，接收到用户的请求后，同样对 header 进行签名，然后和用户的签名进行比较，如何相同，则允许访问。

最大的好处就是只需要发送一次用户名密码，用于获取 token，而且使用签名机制非常安全，不在乎消息被拦截。

翻译自：

https://medium.com/@yellow/rest-security-basics-f59013850c4e