Skip to content

快速开始

我是用户,我要查看用户相关的文档

“快速开始” 已更新,新版本包括使用示例和一些对令牌相关知识的补充:https://www.alongw.cn/archives/1650


下面是原版 “快速开始”

特别感谢小米,我们遵循小米相关文章的协议,并且引用他的文章

OAuth 2.0 协议是一种三方授权协议,目前大部分的第三方登录与授权都是基于该协议的标准或改进实现。OAuth 1.0 的标准在 2007 年发布,2.0 的标准则在 2011 年发布,其中 2.0 的标准取消所有 Token 的加密过程,并简化了授权流程,但因强制使用 HTTPS 协议,被认为安全性高于 1.0 的标准。

OAuth2.0 定义的5种角色

  • 客户端(Client)

客户端是 OAuth 服务的接入方,其目的是请求用户存储在资源服务器上的受保护资源,客户端可以移动应用、网页应用,以及电视应用等等。

  • 用户代理(User Agent)

用户代理是用户参与互联网的工具,一般可以理解为浏览器。

  • 资源所有者(Resource Owner)

受保护资源所属的实体,比如资源的持有人等,下文的用户即资源所有者。

  • 授权服务器(Authorization Server)

授权服务器的主要职责是验证资源所有者的身份,并依据资源所有者的许可对第三方应用下发令牌。

  • 资源服务器(Resource Server)

托管资源的服务器,能够接收和响应持有令牌的资源访问请求,可以与授权服务器是同一台服务器,也可以分开。

OAuth2.0 中各名词基本概念

访问令牌(access token)

​ 访问令牌是在用户授权许可下,授权服务器下发给客户端的一个授权凭证,该令牌所要表达的意思是“用户授予该APP在多少时间范围内允许访问哪些与自己相关的服务”,所以访问令牌主要在 时间范围 和 权限范围 两个维度进行控制,此外访问令牌对于客户端来说是非透明的,外在表现就是一个字符串,客户端无法知晓字符串背后所隐藏的用户信息,因此不用担心用户的登录凭证会因此而泄露。

刷新令牌(refresh token)

​ 刷新令牌的作用在于更新访问令牌,访问令牌的有效期一般较短,这样可以保证在发生访问令牌泄露时,不至于造成太坏的影响,但是访问令牌有效期设置太短存在的副作用就是用户需要频繁授权,虽然可以通过一定的机制进行静默授权,但是频繁的调用授权接口,之于授权服务器也是一种压力,这种情况下就可以在下发访问令牌的同时下发一个刷新令牌,刷新令牌的有效期明显长于访问令牌,这样在访问令牌失效时,可以利用刷新令牌去授权服务器换取新的访问令牌,不过协议对于刷新令牌没有强制规定,是否需要该令牌是客户端可以自行选择。

回调地址(redirect uri)

​ OAuth2.0 是一类基于回调的授权协议,在授权码模式中,整个授权需要分为两步进行,第一步下发授权码,第二步根据第一步拿到的授权码请求授权服务器下发访问令牌。OAuth 在第一步下发授权码时,是将授权码以参数的形式添加到回调地址后面,并以 302 跳转的形式进行下发,这样简化了客户端的操作,不需要再主动去触发一次请求,即可进入下一步流程。

​ 回调请求的设计却存在一个很大的安全隐患,坏人如果在客户端请求过程中修改了对应的回调地址,并指向自己的服务器,那么坏人可以利用这种机制去拿到客户端的授权码,继而走后面的流程,最终拿到访问令牌,另外坏人可以利用该机制引导用户到一个恶意站点,继而对用户发起攻击。以上两点都是该机制对于用户所造成的安全威胁,对于授权服务器而言,也存在一定的危害,坏人可以利用该机制让授权服务器变成“请求发送器”,以授权服务器为代理请求目标地址,这样在消耗授权服务器性能的同时,也对目标地址服务器产生 DDOS 攻击。

​ 为了避免上述安全隐患,OAuth 协议强制要求客户端在注册时填写自己的回调地址,这个回调地址的目的是为了让回调请求能够到达客户端自己的服务器,从而可以走获取访问令牌的流程。客户端可以同时配置多个回调地址,并在请求授权时携带一个地址,服务器会验证客户端传递上来的回调地址是否与之前注册的回调地址相同,或者前者是后者集合的一个元素,只有在满足这一条件下才允许下发授权码,同时协议还要求两步请求客户端携带的回调地址必须一致,通过这些措施来保证回调过程能够正常达到客户端自己的服务器,并继续后面拿授权码换取访问令牌的流程。

权限范围(scope)

​ 访问令牌自带过期时间,可以在时间维度上对授权进行控制,而在范围维度上,OAuth 引入了一个 scope 的概念。scope 可以看做是一个对象,包含一个权限的 ID,名称,以及描述信息等,比如“获取您的基本资料(头像、昵称)”。应该在接入帐号服务时必须向第三方登录服务提供方申请响应的 scope,并在请求授权时指明该参数(否则表明获取该应用所允许的所有权限),这些权限在用户确认授权时,必须毫无保留的展示给用户,以让用户知道该APP需要获取用户的哪些数据或服务。

基本授权流程

  1. 客户端请求授权服务器
  2. 授权授权服务的授权端点重定向用户至授权交互页面,并询问用户是否授权(如果用户没有在授权服务器上登录,则引导用户登录再重定向至授权交互页面)
  3. 如果用户许可,则授权端点验证客户端的身份,并发放授权码给客户端
  4. 客户端拿到授权码之后,携带授权码请求授权服务器的令牌端点下发访问令牌
  5. 令牌端点验证客户端的身份和授权码,通过则下发访问令牌和刷新令牌(可选)
  6. 客户端拿到访问令牌后,携带访问令牌请求资源服务器上的受保护资源
  7. 资源服务器验证客户端身份和访问令牌,通过则响应受保护资源访问请求

整个流程中,客户端都无法接触到用户的登录凭证信息,客户端通过访问令牌请求受保护资源,用户可以通过对授权操作的控制来间接控制客户端对于受保护资源的访问权限范围和时效。

Powered by ALONGW