我与OAuth 2.0那点荒唐的小秘密

OAuth2.0这个名词你是否在项目中时常听到呢?是否以为好像懂,又好像不太懂呢?前端

最近一直想写篇关于OAuth2.0的东西,记录下个人学习与感悟,然各类理由的拖延,直到今日才静下心来写下这篇博客。固然,这里仅表明我的理解,若有纰漏之处,望园内大佬们不吝赐教~安全

好了,话很少说,干货顶上。服务器


几个基本概念

认证(Authentication)和受权(Authorization)

在接触OAuth2.0时是否常听到认证和受权这两个名词呢?学习

刚接触时,一直觉得这两个词是一个意思,只是你们说法的不一样而已。然,在看完官方开发文档后才知道,这根本就是两个东西,不能混为一谈。下面详细说说:加密

  • 认证:主要用于验证身份。好比,咱们进出火车站,身份证证实本身是张三而不是李四,这就是认证。
  • 受权:主要用于判断是否拥有相应的权限。好比,咱们进出火车站,火车票证实咱们有乘坐列车的权限,这就是受权。

如今看看,是否是挺简单的概念,顿时清晰起来?spa

OAuth定义的四个角色

  • 资源拥有者:受保护资源的拥有者,能够对他人受权,让其访问该资源。
  • 资源服务器:托管受保护资源的服务器,只要认证和受权经过,即可响应该资源。
  • 客户端:提出请求受保护资源的应用程序。
  • 受权服务器:当认证和受权成功后,给客户端发布访问令牌(access token)。

访问令牌

访问令牌,其实就是能够访问受保护资源的一个凭证。通常而言,这是串加密过的字符串,颁发给客户端,用于替换用户名和密码,避免每次请求都携带用户名密码,增长安全风险。代理

协议流程

上面这张图即是OAuth 2.0抽象的协议流程,描述了其定义的四个角色之间的交互关系。我将这个流程分为了前期准备和获取资源两个部分,详细以下:blog

前期准备(这是一次性操做,可经过界面申请,与资源拥有者的用户代理沟通等):token

  • 客户端向资源拥有者申请受保护资源的访问权限;
  • 客户端获得拥有者的受权,表示客户端能够访问该受保护资源。

获取资源(Restful请求,每次访问资源都得通过该操做):ip

  • 客户端携带用户名、密码或clientId、secret等方式,向受权服务器发起认证和受权;
  • 受权经过,受权服务器向客户端返回访问令牌(access token);
  • 客户端携带访问令牌,向资源服务器访问受保护资源;
  • 资源服务器验证访问令牌的有效性以后,向客户端返回受保护资源。

受权

受权成功其实就是资源拥有者颁发的能够访问受保护资源的凭证。固然客户端直接拿着凭证是没法访问资源的,还需拿着这个凭证去受权服务器拿访问令牌,凭着令牌即可直接访问受保护资源。

OAuth 2.0官方给出的规范,受权的具体方式共有四种(可自定义):资源拥有者密码凭证,客户端凭证,受权码和隐式受权,;固然自定义机制也是支持的。

资源拥有者凭证受权

资源拥有者密码凭证的受权方式仅适用于资源拥有者和客户端高度信任的场景。

  • 资源拥有者提供客户端密码凭证(resourId: secret)
  • 客户端携带密码凭证直接去受权服务器获取访问令牌

客户端凭证受权

客户端携带自身凭证(clientId: secret)直接去受权服务器获取访问令牌

受权码受权

一次性操做(受权码只须要获取一次便可):

  • 客户端重定向URI和身份信息直接访问资源拥有者或者拥有者的用户代理(通常为前端)
  • 用户代理拿着客户端身份信息和重定向URI,重定向至访问受权服务器;
  • 受权服务器对客户端的信息进行认证和受权;
  • 认证和受权经过后,将受权码返回至用户代理;
  • 用户代理将受权码返回给客户端

获取资源:

  • 客户端拿着受权码和去受权服务器获取访问令牌;
  • 客户端携带访问令牌,向资源服务器访问受保护资源;
  • 资源服务器验证访问令牌的有效性以后,向客户端返回受保护资源。

优点:对客户端进行认证;访问令牌没有直接返回至客户端,因此没有经历第三方(用户代理),减小暴露令牌的可能。

隐式受权

隐士受权是个简化的受权流程,适用于前端页面由脚本语言(如Javascript)编写的场景,对于React,Angular等编写的前端,建议使用受权码的受权方式。

  • 客户端携带身份信息和从新向URI(通常为前端主界面地址)访问用户代理;
  • 用户代理将客户端身份信息和重定向URI发往受权服务器,并进行用户认证;
  • 认证受权经过后,将访问令牌拼进重定向URI,并将这个新的URI发往用户代理;
  • 用户代理直接重定向至新的URI,加载主界面(所需数据,可根据访问令牌去资源服务器获取);
  • 用户代理将访问令牌返回客户端。

注意:通常隐式受权,能够利用重定向URI进行客户端认证。


做者:吴家二少

博客地址:https://www.cnblogs.com/cloudman-open/

本文欢迎转载,但未经做者赞成必须保留此段声明,且在文章页面明显位置给出原文链接

相关文章
相关标签/搜索