本文主要是介绍OAuth2.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:资源服务器,即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。
五. 运行流程
(A)用户打开客户端以后,客户端要求用户给予授权。
(B)用户同意给予客户端授权。
(C)客户端使用上一步获得的授权,向认证服务器申请令牌。
(D)认证服务器对客户端进行认证以后,确认无误,同意发放令牌。
(E)客户端使用令牌,向资源服务器申请获取资源。
(F)资源服务器确认令牌无误,同意向客户端开放资源。
上面的六个步骤，关键是B，也就是用户如何给客户端授权，有了授权以后，客户端就可以获取令牌，进而凭令牌获取资源。
六. 客户端的授权模式
OAuth2.0定义了四种授权方式，分别是授权码模式（authorization code)，简化模式（implicit），密码模式（resource owner password credentials），客户端模式（client credentials）.
(一）授权码模式：功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与”服务提供商”的认证服器进行互动。
(A)用户访问客户端,后者将前者导向认证服务器。包含以下参数：
response_type：表示授权类型，必选项，此处的值固定为”code”
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。
(B)用户选择是否给予客户端授权。
(C)假设用户给予授权,认证服务器将用户导向客户端事先指定的”重定向URI”(redirection URI),同时附上一个授权码。包含以下参数：
code：表示授权码，必选项。该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。
(D)客户端收到授权码,附上早先的”重定向URI”,向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的,对用户不可见。包含以下参数：
grant_type：表示使用的授权模式，必选项，此处的值固定为”authorization_code”。
code：表示上一步获得的授权码，必选项。
redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致。
client_id：表示客户端ID，必选项。
(E)认证服务器核对了授权码和重定向URI,确认无误后,向客户端发送访问令牌(access token)和更新令牌(refresh token)。包含以下参数：
access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
(二）简化模式：不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了”授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
(A)客户端将用户导向认证服务器。包含以下参数：
response_type：表示授权类型，必选项，此处的值固定为”code”
client_id：表示客户端的ID，必选项
redirect_uri：表示重定向URI，可选项
scope：表示申请的权限范围，可选项
state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值。
(B)用户决定是否给于客户端授权。
(C)假设用户给予授权,认证服务器将用户导向客户端指定的”重定向URI”,并在URI的Hash部分包含了访问令牌。包含以下参数：
access_token：表示访问令牌，必选项。
token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型。
expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
state：如果客户端的请求中包含这个参数,认证服务器的回应也必须一模一样包含这个参数。
(D)浏览器向资源服务器发出请求,其中不包括上一步收到的Hash值。
(E)资源服务器返回一个网页,其中包含的代码可以获取Hash值中的令牌。
(F)浏览器执行上一步获得的脚本,提取出令牌。
(G)浏览器将令牌发给客户端。
(三）密码模式：用户向客户端提供自己的用户名和密码。客户端使用这些信息,向”服务商提供商”索要授权。
(A)用户向客户端提供用户名和密码。包含以下参数：
grant_type：表示授权类型,此处的值固定为”password”,必选项。
username：表示用户名,必选项。
password：表示用户的密码,必选项。
scope：表示权限范围,可选项。
(B)客户端将用户名和密码发给认证服务器,向后者请求令牌。
(C)认证服务器确认无误后,向客户端提供访问令牌。
(四）客户端模式：指客户端以自己的名义,而不是以用户的名义,向”服务提供商”进行认证。严格地说,客户端模式并属于OAuth框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求”服务提供商”提供服务,其实不存在授权问题。
(A)客户端向认证服务器进行身份认证,并要求一个访问令牌。包含以下参数：
grant_type：表示授权类型,此处的值固定为”password”,必选项。
scope：表示权限范围,可选项。
(B)认证服务器确认无误后,向客户端提供访问令牌。
七. 总结
通过上面的总结，只能说对OAuth2.0有了进一步宏观上的认识，但对于其细节内容和原理认识，还是远远不够的，有时间应该还是需要阅读下源码，才能有更深入的认识。
这篇关于OAuth2.0学习总结的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
