Oauth协议1，你是如何跨平台登陆的？

Oauth协议，你是如何跨平台登陆的？

在今天我们在某些网站进行登录、注册的时候，不乏都能看见可以使用QQ注册，只用微信注册等等。我之前一直以为这是区块链连起来所有数据去中心化的功劳，可这玩应好像在区块链火了之前就一直存在，其实背后的原理，就是Oauth协议的功劳。

基本概念

Oauth, Open Authorization , 一种开放授权协议，允许第三方应用程序使用资源的所有者通过凭据获取资源访问权限。现在我们进行跨平台登陆的时候最常用的就是2.0版本。1.0版本理念比较差，而且和2.0不兼容，就没有学的必要了

换句话说，就是我们在登陆第三方平台的时候（比如leetcode， 我用QQ登陆的），使用默写已有主流平台账户登录（QQ)，第三方平台会获取账户平台分发的授权凭证，据此可以有限的访问用户名，头像等安全性和私密性要求不高的资源。而这种凭证，一般是平台(QQ)生成的Token，包括有效时间，访问权限等等信息。

协议详解

角色：

OAuth2.0整个协议中会出现四种角色：

• 资源拥有者（Resourcw owner) 指用户，就是我这个个体
• 认证服务器（Authorization server) ， 用来认证用户凭证，颁发授权的服务器 （QQ那边的认证的服务器）
• 资源服务器（Resource server ), 存放用户熟保护资源的服务器 （QQ那边存放我账号数据的服务器）
• 第三方应用（Client), 客户端，得到Token授权的数据并给我们提供我们需要的服务（Leetcode)

上面这张图是一个简单的认证流程。可以看到Client获得Token的前提是注册与否，所以接下来会分几个阶段介绍认证流程

阶段：

1. 注册

第三方平台要想获取授权就需要到账号所在的授权服务器进行注册，注册需要提供基本的信息，如认证信息，服务域名，申请用户授权的范围、甚至企业资质（例如申请微信公众号的企业服务）等等。注册成功后， 认证服务器会给Client发送client_id与client_secret 作为以后交互的凭证

2.授权流程

这个协议是RFC6749文档的，感兴趣可以自己去看看原文，但是挺长的，我就自己翻教程速成了整个流程官方文档图是这样的，非常清晰：

• 客户端向用户发起授权请求
• 用户统一或反对授权请求，同意会继续往下走，反对会取消
• 客户端请求认证服务器办法Token
• 认证服务器用上面说过的注册过的信息蛇和之后通过就会给出Token
• 客户端用Token向资源服务器请求资源
• 资源服务器验证Token后给与相应

授权模式

上面的的流程抽线掉了Token的颁发的过程。在Oauth2.0中提供了四种授权模式用来完成Token颁发的过程。（它还提供了一种用于定义其他授权类型的扩展机制。）

1. 授权码模式

最完整，安全性最高，最常用的一种模式，如图：

过程如下：

A. Client 重定向到授权服务器开始整个流程，此时用户被重定向到了认证服务器并准备好User-gent头信息。

B. 用户把信息发给授权服务器认证身份（相当于我们在第三方平台上跳转官方登录平台的界面）

C. 认证成功返回认证一个重定向的URI（就是你要访问资源的URI) 给Client 并给予一个授权码（Code)

D. Client将 URI 连同code 发给认证服务器

E. 认证服务器给Client Token, 且不允许做缓存，以提高安全性

整个过程的参数可以参考这一篇https://www.cnblogs.com/qjj19931230/p/12551916.html

access_Token有可能会过期，所以一般在请求access_Token会同时发一个refresh_token,用来在过期前重新获取access_token，在access_token过期前,重新获取新的Token

2. 简化模式

全程使用浏览器完成，跳过了**授权码（Code)**的步骤。令牌对User可见，而且客户端不做认证

其实有图还是好理解的，可以考到这里几乎就是User在做工作，，

A. Client把User Rediect 到认证服务器

B. User 准备一些信息发送给认证服务器做认证

C. 认证服务器认证成功之后给出重定向URI, 并在URI的Hash部分包含了令牌 access_token

D. 用户向资源服务器发起请求，但是不包括Hash, 也就是不包含令牌

E. 资源服务器返回一个能从Hash中提取令牌的脚本

F. 客户端的服务器用个脚本提取令牌

G. 把令牌发给Client。

参数还是可以看上面的那一篇https://www.cnblogs.com/qjj19931230/p/12551916.html

3. 密码模式

这个模式就很够了，用户向客户端提供自己的用户名和密码，这个模式多流氓客户端使用这些信息去向认证服务器要Token, 必须保证Client不得存储密码，否则无权谈论安全性

4. 客户端模式

这个就更离谱了，严格来说都不算Oauth框架中的东西，客户端以自己的名义而不是User的名义要Token , 在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题.