来自:杜亦舒 性能与架构
安全是 RESTful web service 的基石,我们主要讨论以下3种主要的方法:
这是最古老、最简单的方法。
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