【OAuth2】：赋予用户控制权的安全通行证--原理篇

🥳🥳Welcome Huihui's Code World ! !🥳🥳

**接下来看看由辉辉所写的关于OAuth2的相关操作吧 **

一.什么是OAuth?

    OAuth 不是一个API或者服务，而是一个验证授权(Authorization)的开放标准，所有人都有基于这个标准实现自己的OAuth。

    更具体来说，OAuth是一个标准，app可以用来实现

secure delegated access

. OAuth基于HTTPS，以及APIs，Service应用使用

access token

来进行身份验证。

    OAuth主要有OAuth 1.0a和OAuth 2.0两个版本，并且二者完全不同，且不兼容。OAuth2.0 是目前广泛使用的版本，我们多数谈论OAuth时，为OAuth2.0

二.为什么要用OAuth?

    在OAuth之前，
HTTP Basic Authentication
, 即用户输入用户名，密码的形式进行验证, 这种形式是不安全的。OAuth的出现就是为了解决访问资源的安全性以及灵活性。OAuth使得第三方应用对资源的访问更加安全。
    可能这样讲，大家会觉得不生动，那么我接下来举一个生活中的例子让大家能够更快的去理解要使用oauth的原因
假设我住在一个大型的居民小区。

小区有门禁系统。

进入的时候需要输入密码，或者扫码。

我经常网购和外卖，每天都有快递员来送货。我必须找到一个办法，让快递员通过门禁系统，进入小区。

如果我把自己的密码，告诉快递员，他就拥有了与我同样的权限，这样好像不太合适。万一我想取消他进入小区的权力，也很麻烦，我自己的密码也得跟着改了，还得通知其他的快递员。

有没有一种办法，让快递员能够自由进入小区，又不必知道小区居民的密码，而且他的唯一权限就是送货，其他需要密码的场合，他都没有权限？

于是，我设计了一套授权机制。

第一步，门禁系统的密码输入器下面，增加一个按钮，叫做"获取授权"。快递员需要首先按这个按钮，去申请授权。

第二步，他按下按钮以后，屋主（也就是我）的手机就会跳出对话框：有人正在要求授权。系统还会显示该快递员的姓名、工号和所属的快递公司。

我确认请求属实，就点击按钮，告诉门禁系统，我同意给予他进入小区的授权。

第三步，门禁系统得到我的确认以后，向快递员显示一个进入小区的令牌（access token）。令牌就是类似密码的一串数字，只在短期内（比如七天）有效。

第四步，快递员向门禁系统输入令牌，进入小区。

有人可能会问，为什么不是远程为快递员开门，而要为他单独生成一个令牌？这是因为快递员可能每天都会来送货，第二天他还可以复用这个令牌。另外，有的小区有多重门禁，快递员可以使用同一个令牌通过它们。【大概的步骤就是下方图片所示】

综上，可知OAuth 就是一种授权机制。数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。

三. OAuth2的四种授权模式

1. 隐式授权模式（Implicit Grant）

第一步：用户访问页面时，重定向到认证服务器。

第二步：认证服务器给用户一个认证页面，等待用户授权。

第三步：用户授权，认证服务器想应用页面返回Token

第四步：验证Token，访问真正的资源页面

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，访问真正的资源页面

3. 密码模式（Resource Owner Password Credentials Grant）

第一步：用户访问用页面时，输入第三方认证所需要的信息(QQ/微信账号密码)

第二步：应用页面那种这个信息去认证服务器授权

第三步：认证服务器授权通过，拿到token，访问真正的资源页面

优点：不需要多次请求转发，额外开销，同时可以获取更多的用户信息。(都拿到账号密码了)

缺点：局限性，认证服务器和应用方必须有超高的信赖。(比如亲兄弟？)

应用场景：自家公司搭建的认证服务器

4. 客户端凭证模式（Client Credentials Grant）

第一步：用户访问应用客户端

第二步：通过客户端定义的验证方法，拿到token，无需授权

第三步：访问资源服务器A

第四步：拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式，只要client请求，我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任，而client本身也是安全的。

因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与

四.关于授权码授权模式的详细讲解

我们在实战中，用的最多的就是授权码的授权模式，这个模式相对来说用的比较多，所以我们再详细的讲解一下他的流程

1.流程说明

1、用户访问客户端
2、客户端将用户导向认证服务器
3、用户登录，并对第三方客户端进行授权
4、认证服务器将用户导向客户端事先指定的重定向地址，并附上一个授权码
5、客户端使用授权码，向认证服务器换取令牌
6、认证服务器对客户端进行认证以后，发放令牌
7、客户端使用令牌，向资源服务器申请获取资源
8、资源服务器确认令牌，向客户端开放资源

2.模拟过程

流程说明- 资源拥有者打开客户端，客户端要求资源拥有者给予授权，它将浏览器被重定向到授权服务器，重定向时会附加客户端的身份信息。如：
/server/oauth2/authorize? client_id=test&response_type=code&scope=app&redirect_uri=http://xx.xx/notify
client_id：客户端接入标识。

response_type：授权码模式固定为code。

scope：客户端权限。

redirect_uri：跳转uri，当授权码申请成功后会跳转到此地址，并在后边带上code参数（授权码）。例如：xx.xx/notify?code…

浏览器出现向授权服务器授权页面，之后将用户同意授权。

授权服务器将授权码（AuthorizationCode）转经浏览器发送给client(通过redirect_uri传递，url后面拼接参数)。

客户端拿着授权码向授权服务器索要访问access_token，请求如下：/server/oauth2/token? client_id=test&client_secret=gdjbcd&grant_type=authorization_code&code=qwe12&redirect_uri=http://xx.xx/notify> client_id：客户端准入标识。> > client_secret：客户端秘钥。> > grant_type：授权类型，填写authorization_code，表示授权码模式 code：授权码，就是刚刚获取的授权码，注意：授权码只使用一次就无效了，需要重新申请。> > redirect_uri：申请授权码时的跳转url，一定和申请授权码时用的redirect_uri一致

授权服务器返回令牌(access_token)

这种模式是四种模式中最安全的一种模式。一般用于Web服务器端应用或第三方的原生App调用资源服务的时候。因为在这种模式中access_token不会经过浏览器或移动端的App，而是直接从服务端去交换，这样就最大限度的减小了令牌泄漏的风险

3.实例说明

后续的几个步骤都是在后端完成的，我们在前端无法演示了