3种基础的REST 安全机制,大家用了吗?

来自:杜亦舒 性能与架构

3种基础的REST 安全机制,大家用了吗?

文章插图
 
安全是 RESTful web service 的基石,我们主要讨论以下3种主要的方法:
  • Basic authentication
  • Oauth 2.0
  • Oauth 2.0 + JWT
1. Basic authentication这是最古老、最简单的方法 。
形式username + password + Base64 。
工作机制【3种基础的REST 安全机制,大家用了吗?】假设一个用户要登录 Facebook 账号,查看:feed 流、消息、好友、组,这4个服务都是独立的 。
用户提交用户名密码之后,系统验证后允许进入,然而系统是不知道其角色和权限的,例如什么服务允许访问 。
所以,每次用户访问任何服务时,系统需要再次验证是否允许此次操作,这意味着需要一次对授权服务器的额外调用 。例如上面的4个服务,那么每个用户就会有4次额外调用 。
现在想象每秒我们有 3000 个用户访问,乘以4个服务,结果就是每秒 12000 次授权服务器调用 。
3种基础的REST 安全机制,大家用了吗?

文章插图
 
结论可扩展性差,有大量的没有商业价值的额外调用,显著增加了服务器的压力 。
2. Oauth 2.0形式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,查看用户的角色 。
所以,最后还是需要多次调用授权服务器 。
3种基础的REST 安全机制,大家用了吗?

文章插图
 
结论和 Basic authentication 有同样的问题,扩展性差,授权服务器会有大量负载 。
OAuth 2 + Json Web Tokens形式username + password + JSON map + Base64 + private key + expiration date
工作机制用户第一次使用用户名密码登录系统后,系统不仅返回一个 access token,而且还有一个 JSON map,其中包含所有的用户信息,例如角色和权限,这些信息是使用 Base64 编码的,并使用私钥加密 。
3种基础的REST 安全机制,大家用了吗?

文章插图
 
在 token 中存储了状态信息,使服务是无状态的 。
用户自己拿着自己的信息,所有信息都在 token 里面,所以就不需要额外的调用了 。
这对减少服务器的负载起到了巨大的作用,现在这个方法在世界范围内被广泛使用 。
结论扩展性好,非常适合微服务 。
亚马逊的做法在用户创建亚马逊账号的时候,会生成一个永久的、超级安全的 access token,需要用户保护好 。
当用户需要请求亚马逊的时候,需要使用这个私有的 token 对 HTTP header 数据进行签名,并添加到 header 中一起发送过去 。
服务器端,亚马逊也有用户的这个私有 token,接收到用户的请求后,同样对 header 进行签名,然后和用户的签名进行比较,如何相同,则允许访问 。
最大的好处就是只需要发送一次用户名密码,用于获取 token,而且使用签名机制非常安全,不在乎消息被拦截 。
3种基础的REST 安全机制,大家用了吗?

文章插图
 
翻译自:
https://medium.com/@yellow/rest-security-basics-f59013850c4e




    推荐阅读