什么是OAuth2.0
认证流程通常包括以下步骤
- 客户端向授权服务器发送认证请求，包括客户端ID和重定向URI。
- 授权服务器要求用户进行身份验证，并请求用户授权访问其受保护资源。
- 用户同意授权，授权服务器将重定向用户到客户端提供的重定向URI，并附带授权码。
- 客户端使用授权码向授权服务器请求访问令牌。
- 授权服务器验证客户端身份和授权码，并向客户端颁发访问令牌。
- 客户端使用访问令牌向资源服务器请求访问受保护资源。
OAuth2 有4种授权模式
名词定义
（1） Third-party application：第三方应用程序，本文中又称"客户端"（client），比如打开知乎，使用第三方登录，选择qq登录，这时候知乎就是客户端。
（2）HTTP service：HTTP服务提供商，本文中简称"服务提供商"，即上例的qq。
（3）Resource Owner：资源所有者，本文中又称"用户"（user）,即登录用户。
（4）User Agent：用户代理，本文中就是指浏览器。
（5）Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
（6）Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
1. OAuth2简易实战（一）-四种模式
1.1. 隐式授权模式（Implicit Grant）
- 第一步：用户访问页面时，重定向到认证服务器。
- 第二步：认证服务器给用户一个认证页面，等待用户授权。
- 第三步：用户授权，认证服务器想应用页面返回Token
- 第四步：验证Token，访问真正的资源页面
1.2. 授权码授权模式（Authorization code Grant）
- 第一步：用户访问页面
- 第二步：访问的页面将请求重定向到认证服务器
- 第三步：认证服务器向用户展示授权页面，等待用户授权
- 第四步：用户授权，认证服务器生成一个code和带上client_id发送给应用服务器
- 然后，应用服务器拿到code，并用client_id去后台查询对应的client_secret
- 第五步：将code、client_id、client_secret传给认证服务器换取access_token和
- refresh_token
- 第六步：将access_token和refresh_token传给应用服务器
- 第七步：验证token，访问真正的资源页面
案例Github自取:GitHub – PinkPig-cq/springSecurityoAuth: Spring-Security基于OAuth2.0的授权码验证
其中的access code授权码模式在实现时可以使用JWT生成code, 也可以不用. 它们之间没有必然的联系；
- 示例2：QQ音乐使用微信登录
1.3. 密码模式（Resource Owner Password Credentials Grant）
- 第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)
- 第二步：应用页面那种这个信息去认证服务器授权
- 第三步：认证服务器授权通过，拿到token，访问真正的资源页面
优点：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。(都拿到账号密码了)
缺点：局限性，认证服务器和应用方必须有超高的信赖。(比如亲兄弟？)
应用场景：自家公司搭建的认证服务器
1.4. 客户端凭证模式（Client Credentials Grant）
- 第一步：用户访问应用客户端
- 第二步：通过客户端定义的验证方法，拿到token，无需授权
- 第三步：访问资源服务器A
- 第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。
这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。
因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。
使用HTTPS保护用户密码
在进一步讨论OAuth2和JWT的实现之前，有必要说一下，两种方案都需要SSL安全保护，也就是对要传输的数据进行加密编码。
安全地传输用户提供的私密信息，在任何一个安全的系统里都是必要的。否则任何人都可以通过侵入私人wifi，在用户登录的时候窃取用户的用户名和密码等信息。
一些重要的实施考虑在做选择之前，参考一下下边提到的几点。
时间投入OAuth2是一个安全框架，描述了在各种不同场景下，多个应用之间的授权问题。有海量的资料需要学习，要完全理解需要花费大量时间。甚至对于一些有经验的开发工程师来说，也会需要大概一个月的时间来深入理解OAuth2。这是个很大的时间投入。相反，JWT是一个相对轻量级的概念。可能花一天时间深入学习一下标准规范，就可以很容易地开始具体实施。
出现错误的风险OAuth2不像JWT一样是一个严格的标准协议，因此在实施过程中更容易出错。尽管有很多现有的库，但是每个库的成熟度也不尽相同，同样很容易引入各种错误。在常用的库中也很容易发现一些安全漏洞。当然，如果有相当成熟、强大的开发团队来持续OAuth2实施和维护，可以一定成都上避免这些风险。
社交登录的好处在很多情况下,使用用户在大型社交网站的已有账户来认证会方便。如果期望你的用户可以直接使用Facebook或者Gmail之类的账户,使用现有的库会方便得多。
OAuth2的使用场景
OAuth2用在使用第三方账号登录的情况(比如使用weibo, qq, github登录某个app)
如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。
优势
- 灵活的实现方式
- 可以和JWT同时使用
- 可针对不同应用扩展
原创文章，作者：优速盾-小U，如若转载，请注明出处：https://www.cdnb.net/bbs/archives/31066
