搞懂oauth2.0授权码模式

OAuth 2.0 是什么？

举一个电商的场景，你估计更有感觉。假如你是一个卖家，在京东商城开了一个店铺，日常运营中你要将订单打印出来以便给用户发货。但打印这事儿也挺繁琐的，之前你总是手工操作，后来发现有个叫“小兔”的第三方软件，它可以帮你高效率地处理这事。

　　但你想想，小兔是怎么访问到这些订单数据的呢？其实是这样，京东商城提供了开放平台，小兔通过京东商家开放平台的 API 就能访问到用户的订单数据。

　　只要你在软件里点击同意，小兔就可以拿到一个访问令牌，通过访问令牌来获取到你的订单数据帮你干活儿了。你看，这里也是有一次授权。你要是不同意，平台肯定不敢把这些数据给到第三方软件。

为什么用 OAuth 2.0？

OAuth 2.0 这种授权协议，就是保证第三方（软件）只有在获得授权之后，才可以进一步访问授权者的数据。因此，我们常常还会听到一种说法，OAuth 2.0 是一种安全协议。现在你知道了，这种说法也是正确的。

　　现在访问授权者的数据主要是通过 Web API，所以凡是要保护这种对外的 API 时，都需要这样授权的方式。而 OAuth 2.0 的这种颁发访问令牌的机制，是再合适不过的方法了。同时，这样的 Web API 还在持续增加，所以 OAuth 2.0 是目前 Web 上重要的安全手段之一了。

OAuth 2.0 是怎样运转的？

 图中的流程只是授权码的方式

为什么需要授权码

1.access_token不显示在浏览器是因为安全原因

2.浏览器直接获取调用授权带着回调，然后授权服务器把access_token直接返回给服务器行不行？

 首先access_token需要secret，客户端不能存储，所以请求access_token必须通过服务端。如果取消授权码模式，客户端需要更复杂的签名加密方式去把secret传递过去获取access_token。

• Http 协议是无状态的，“第三方服务器”无法从一个 Server 对 Server 的请求轻易区分这个 token 对着自己当前哪个 Session。
• 如果依赖第一步里，“第三方服务器”跳转到“认证服务器”时传递的 GET 参数来作为 Session 身份区分，又涉及到跳转本身就是明文，可能被篡改的问题，需要协定复杂的签名协议来保证安全，这和 OAuth2 希望设计简洁验证模式的初衷违背。
• 假设安全问题解决了，已跳转回来的“第三方服务器”网页需要等待一个不知道何时才会过来的“认证服务器” Server 回调，才能告诉用户到底授权成功没有。远不如同步主动去请求“认证服务器”获取方便。

-----------------------------------以后是旧内容---------------------------------

最早的简单登录

去访问一个网站，如果登录的话，需要注册，填一堆信息，用户名密码啥的，通常密码是前端加盐、哈希（md5，sha1等）然后再发给后端，后端存储起来，不能直接存储明文。然后再跳转到登录页面，输入用户名和密码，后端验证用户名和密码，如果成功了返回一个session id，然后前端就可以结合cookie使用。

问题：

1.安全性，需要对密码的加密有一个万全的应对之策

2.维护麻烦，用户用起来也麻烦

比较早的授权登录

后来yelp试图解决这些问题，如下图所示

想用什么登录就选中，但是得需要对应的用户和密码，然后yelp会用密码去google拉取你的相关信息。

问题：

1.安全性，虽然yelp承诺了不保存用户google的密码，但是可能是小公司，没有信用累积（谁知道背着用户有没有在后台做什么）

OAuth2.0授权登录

为了解决这些问题，oauth2.0授权登录出现了

上个流程换用oauth2.0的流程就变成下面的了

小公司不值得信任，但是我信任google，所以yelp与google建立联系

用户点击使用google登录，然后跳转到google的登录页面，输入自己google的账号和密码，然后弹出一个框，是否同意yelp访问你的个人信息和通讯录信息

如果你点否，那么yelp将会什么都不做，可能也无法登录

如果点击是，会回调到yelp的某个页面，然后yelp的后台会去访问google你的信息和页面，通过某种介质

这个流程总结为我授权yelp去google可以拿到我的个人信息和通讯录

oauth2.0的一些名词的解析

Resource owner： 资源的拥有者， 即想使用google登录yelp的用户

Client： 客户端 即yelp app 

Authorization server：授权服务，即上述流程中的account.google.com,在这里你登录了google，并且同意了授权

Resource server：资源服务，即上述流程中的contacts.google.com,存储你相关信息的服务

Authorization grant（这个好像是scops）：同时赋予某种权限，图中赋予了个人信息和通讯录的权限

Redirect URI： 回调URL，即上述流程中，授权成功后，跳转回的那个callback url

Access Token ： 去访问Resource server的令牌，即上述流程中yelp后台通过这个可以去google访问，获取到你同意的那些信息（个人信息，通讯录）

oauth2.0的授权码流程

用户使用google授权登录，yelp跳转到google的Authorization server， 通过下图的uri， 指定回调url，response type：code授权码方式，以及想要获取哪些授权，这里是profile 和 contacts。

然后如果没有登录，用户登录，成功后，跳转询问用户是否同意上述授权

如果同意了，又调回到我们指定的回调url，并且带着授权码，如下图

第一个uri是用户点否后，回调的uri 

第二个uri是用户点击是后，回调的uri

拿到这个uri后， client 即会访问这个uri，请求到yelp的后端进行应该的操作

假设用户同意授权，即yelp后端会用授权码 去换取token， 通过token在yelp后端再拿到用户的信息 

多了授权码这一步，就是为了避免access_token在前端暴露，  加强了安全性

上图就是前端拿到uri后，访问后端，后端要进行的操作，即用授权码和你再google注册的client_id,client_secret 来交换access_token。 ps：回调url也是在google注册的时候填写的。

上图即拿code交换access_token的响应body ps：少了refresh_token， 这个东西的过期时间会更长，一般access_token过期后，不用再走授权码的流程，只需要拿refresh_token去换取新的access_token和refresh_token即可。

问题：

oauth2.0是授权不是认证，所以用它拿来做用户认证是不正确的 

而且oauth2.0不是一个标准的协议，各家实现都有差异。 

为了解决这些问题，OpenID Connect的概念随即被提出

OpenID Connect

如图所示，oauth2.0是授权authorization ，OpenID Connect是认证 authentication

OpenID Connect在oauth2.0的基础上封装了一层，支持了用户认证。 也同样支持授权码方式，也oauth2.0不同的时返回了ID Token，用来做认证。下面看一下OpenID Connect的授权码流程

1.Scope：必须指定openid

2.ID token与 access_token一起返回

这2点是与oauth2.0不同的地方，其他的都类似。

多了个id_token， 一般是用jwt协议实现的，（jwt是啥，可以看我另一篇文章） 如下所示

获取用户信息

oauth2.0和OpenID Connect

这里指的是OpenID Connect 

撤销token