OAuth2.0学习总结

我不是女神ヾ 2022-05-14 12:45 133阅读 0赞

一. 什么是OAuth2.0

OAuth2.0是OAuth协议的下一版本,但不向后兼容OAuth 1.0即完全废止了OAuth1.0。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户,要么允许第三方应用代表用户获得访问的权限。同时为Web应用,桌面应用和手机,和起居室设备提供专门的认证流程。

二. OAuth2.0有什么用

oauth2的作用是给第三方发放一个有效的token,此token包含用户的 资源信息和权限,访问过期时间等,取代早期的web用session登陆的弊端,用户可以在api中添加token参数直接访问系统资源。

用户登录，登录将获取到的token保存 ,等需要访问api是直接获取,获取的token可能是一个超时失效的。这就需要一个判断去获取最新的token。

三. 应用场景

在上篇博客中，就写到了OAuth2.0在项目中的应用，为了给第三方提供资源，并且保证资源的安全性，就需要给第三方授权成功后，才能允许其访问我们系统的api。我们使用的授权模式是客户端模式。

在之前的项目经验中，也有需要通过调用第三方接口，将我们的资源同步给第三方。他们使用的是OAuth2.0密码模式做的授权，在访问他们的api前，我们需要通过他提供的用户名和密码，获取到token。

传统的授权方法是将自己的用户名和密码告诉第三方，第三方去验证用户名和密码的正确性，验证通过，就允许访问第三方。而这样的做法是存在缺点的，密码被暴露，不安全；第三方需要做密码登录系统，单纯的密码登录也是不安全的；一旦验证通过后，第三方没有办法限制授权的范围和有效期；等等。

因此，OAuth为了解决上述问题而诞生。

四. 名词解释

(1)Third-party application:第三方应用程序,又称”客户端”(client)。

(2)HTTP service:HTTP服务提供商,简称”服务提供商”。

(3)Resource Owner:资源所有者,又称”用户”(user)。

(4)User Agent:用户代理,指浏览器。

(5)Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器。

(6)Resource server:资源服务器,即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。

五. 运行流程

![这里写图片描述][70]

(A)用户打开客户端以后,客户端要求用户给予授权。

(B)用户同意给予客户端授权。

(C)客户端使用上一步获得的授权,向认证服务器申请令牌。

(D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。

(E)客户端使用令牌,向资源服务器申请获取资源。

(F)资源服务器确认令牌无误,同意向客户端开放资源。

上面的六个步骤，关键是B，也就是用户如何给客户端授权，有了授权以后，客户端就可以获取令牌，进而凭令牌获取资源。

六. 客户端的授权模式

OAuth2.0定义了四种授权方式，分别是授权码模式（authorization code)，简化模式（implicit），密码模式（resource owner password credentials），客户端模式（client credentials）.

(一）授权码模式：功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与”服务提供商”的认证服器进行互动。

![这里写图片描述][70 1]

(A)用户访问客户端,后者将前者导向认证服务器。包含以下参数：

1.  response\_type：表示授权类型，必选项，此处的值固定为”code”
2.  client\_id：表示客户端的ID，必选项
3.  redirect\_uri：表示重定向URI，可选项
4.  scope：表示申请的权限范围，可选项
5.  state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。

(B)用户选择是否给予客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的”重定向URI”(redirection URI),同时附上一个授权码。包含以下参数：

1.  code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
2.  state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

(D)客户端收到授权码,附上早先的”重定向URI”,向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。包含以下参数：

1.  grant\_type：表示使用的授权模式，必选项，此处的值固定为”authorization\_code”。
2.  code：表示上一步获得的授权码，必选项。
3.  redirect\_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
4.  client\_id：表示客户端ID，必选项。

(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。包含以下参数：

1.  access\_token：表示访问令牌，必选项。
2.  token\_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
3.  expires\_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
4.  refresh\_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
5.  scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。

(二）简化模式：不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了”授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

![这里写图片描述][70 2]

(A)客户端将用户导向认证服务器。包含以下参数：

(B)用户决定是否给于客户端授权。

(C)假设用户给予授权,认证服务器将用户导向客户端指定的”重定向URI”,并在URI的Hash部分包含了访问令牌。包含以下参数：

1.  access\_token：表示访问令牌，必选项。
2.  token\_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
3.  expires\_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
4.  scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
5.  state：如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数。

(D)浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。

(E)资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。

(F)浏览器执行上一步获得的脚本,提取出令牌。

(G)浏览器将令牌发给客户端。

(三）密码模式：用户向客户端提供自己的用户名和密码。客户端使用这些信息,向”服务商提供商”索要授权。

![这里写图片描述][70 3]

(A)用户向客户端提供用户名和密码。包含以下参数：

1.  grant\_type：表示授权类型,此处的值固定为”password”,必选项。
2.  username：表示用户名,必选项。
3.  password：表示用户的密码,必选项。
4.  scope：表示权限范围,可选项。

(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。

(C)认证服务器确认无误后,向客户端提供访问令牌。

(四）客户端模式：指客户端以自己的名义,而不是以用户的名义,向”服务提供商”进行认证。严格地说,客户端模式并属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求”服务提供商”提供服务,其实不存在授权问题。  
![这里写图片描述][70 4]

(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。包含以下参数：

1.  grant\_type：表示授权类型,此处的值固定为”password”,必选项。
2.  scope：表示权限范围,可选项。

(B)认证服务器确认无误后,向客户端提供访问令牌。

七. 总结

通过上面的总结，只能说对OAuth2.0有了进一步宏观上的认识，但对于其细节内容和原理认识，还是远远不够的，有时间应该还是需要阅读下源码，才能有更深入的认识。

[70]: /images/20220514/96b2fe70da1a40b09ae73922aaf594c9.png
[70 1]: /images/20220514/39bc8263592a4e9bb379bb2d610b476e.png
[70 2]: /images/20220514/38dea192525c4111b5263ea96486bda4.png
[70 3]: /images/20220514/0748be7a94064bed881b25eba206ae76.png
[70 4]: /images/20220514/90042f313b734c83842cca4d2fc14656.png