深度解析OAuth2.0授权协议

OAuth2.0简介

OAuth产生背景

很多网站、APP 弱化甚至没有搭建自己的账号体系，而是直接使用社会化登录的方式，这样不仅免去了用户注册账号的麻烦、还可以获取用户的好友关系来增强自身的社交功能。
　　比如我们可以使用微信登录CSDN，CSDN会自动将你的微信头像设置为你的CSDN头像，将你的微信昵称设置为你的CSDN昵称，甚至还可以获取你微信中的好友列表，提示你哪些朋友已经在使用CSDN，这是如何做到的呢？
最传统的办法是让用户直接在CSDN的登录页面输微信的账号和密码，CSDN通过用户的账号和密码去微信那里获取用户数据，但这样做有很多严重的缺点：

-CSDN需要明文保存用户的微信账号和密码，这样很不安全。

• CSDN拥有了获取用户在微信所有的权限，包括删除好友、给好友发私信、更改密码、注销账号等危险操作。
• 用户只有修改密码，才能收回赋予CSDN的权限。但是这样做会使得其他所有获得用户授权的第三方应用程序全部失效。
• 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有使用微信登录的网站的数据泄漏。

为了解决以上的问题，OAuth 协议应运而生。

OAuth2.0介绍

OAuth是一个关于授权（authorization）的开放网络标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。OAuth2.0是OAuth协议的延续版本，但不向后兼容OAuth 1.0即完全废止了OAuth1.0。很多大公司如Google，Yahoo，Microsoft等都提供了OAUTH认证服务，这些都足以说明OAUTH标准逐渐成为开放资源授权的标准。
Oauth协议目前发展到2.0版本，1.0版本过于复杂，2.0版本已得到广泛应用。

参考：https://baike.baidu.com/item/oAuth/7153134?fr=aladdin
Oauth协议：https://tools.ietf.org/html/rfc6749

简单历史回顾

• OAuth 1.0在2007年的12月底发布并迅速成为工业标准。
• 2008年6月，发布了OAuth 1.0 Revision A，这是个稍作修改的修订版本，主要修正一个安全方面的漏洞。
• 2010年四月，OAuth 1.0的终于在IETF发布了，协议编号RFC 5849。
• OAuth2.0的草案是在2011年5月初在IETF发布的。
• OAuth 2.0是个全新的协议，并且不对之前的版本做向后兼容，然而，OAuth 2.0保留了与之前版本OAuth相同的整体架构。
• 这个草案是围绕着 OAuth2.0的需求和目标，历经了长达一年的讨论，讨论的参与者来自业界的各个知名公司，包括Yahoo!, Facebook, Salesforce, Microsoft, Twitter, Deutsche Telekom, Intuit, Mozilla, and Google。
• OAuth is a security protocol that enables users to grant third-party
  access to their web resources without sharing their passwords.
  OAuth是个安全相关的协议，作用在于，使用户授权第三方的应用程序访问用户的web资源，并且不需要向第三方应用程序透露自己的密码。

下边分析一个Oauth2认证的例子，通过例子去理解OAuth2.0协议的认证流程
本例子是掘金网站使用微信认证的过程，这个过程的简要描述如下：
用户借助微信认证登录掘金网站，用户就不用单独在掘金注册用户，怎么样算认证成功吗？掘金网站需要成功从微信获取用户的身份信息则认为用户认证成功，那如何从微信获取用户的身份信息？用户信息的拥有者是用户本人，微信需要经过用户的同意方可为掘金网站生成令牌，掘金网站拿此令牌方可从微信获取用户的信息

1. 客户端请求第三方授权 用户进入掘金的登录页面，点击微信的图标以微信账号登录系统，用户是自己在微信里信息的资源拥有者。
   

2. 点击“微信”出现一个二维码，此时用户扫描二维码，开始给掘金授权

3. 资源拥有者同意给客户端授权 资源拥有者扫描二维码表示资源拥有者同意给客户端授权，微信会对资源拥有者的身份进行验证，
   验证通过后，微信会询问用户是否给授权掘金访问自己的微信数据，用户点击“确认登录”表示同意授权，微信认证服务器会颁发一个授权码，并重定向到掘金的网站。

4. 客户端获取到授权码，请求认证服务器申请令牌 此过程用户看不到，客户端应用程序请求认证服务器，请求携带授权码。

5. 认证服务器向客户端响应令牌 微信认证服务器验证了客户端请求的授权码，如果合法则给客户端颁发令牌，令牌是客户端访问资源的通行证。
   此交互过程用户看不到，当客户端拿到令牌后，用户在掘金看到已经登录成功。

6. 客户端请求资源服务器的资源 客户端携带令牌访问资源服务器的资源。 掘金网站携带令牌请求访问微信服务器获取用户的基本信息。

7. 资源服务器返回受保护资源 资源服务器校验令牌的合法性，如果合法则向用户响应资源信息内容。
   

通过上边的例子我们大概了解了OAauth2.0的认证过程，下边我们看OAuth2.0认证流程：
引自OAauth2.0协议rfc6749 https://tools.ietf.org/html/rfc6749
OAauth2.0包括以下角色：

1. 客户端
   本身不存储资源，需要通过资源拥有者的授权去请求资源服务器的资源，比如：Android客户端、Web客户端（浏览器端）、微信客户端等。

2. 资源拥有者 通常为用户，也可以是应用程序，即该资源的拥有者。

3. 授权服务器（也称认证服务器） 用于服务提供商对资源拥有的身份进行认证、对访问资源进行授权，认证成功后会给客户端发放令牌
   （access_token），作为客户端访问资源服务器的凭据。本例为微信的认证服务器。

4. 资源服务器 存储资源的服务器，本例子为微信存储的用户信息。

现在还有一个问题，服务提供商能允许随便一个客户端就接入到它的授权服务器吗？答案是否定的，服务提供商会给准入的接入方一个身份，用于接入时的凭据:
client_id：客户端标识 client_secret：客户端秘钥
因此，准确来说，授权服务器对两种OAuth2.0中的两个角色进行认证授权，分别是资源拥有者、客户端。
Spring-Security-OAuth2是对OAuth2的一种实现，并且跟Spring Security相辅相成，与Spring Cloud体系的集成也非常便利.