一、基础知识
1、OAuth产生背景
很多网站、APP 弱化甚至没有搭建自己的账号体系，而是直接使用社会化登录的方式，这样不仅免去了用户注册账号的麻烦、还可以获取用户的好友关系来增强自身的社交功能。
比如我们可以使用微博登录简书，简书会自动将你的微博头像设置为你的简书头像，将你的微博昵称设置为你的简书昵称，甚至还可以获取你微博中的好友列表，提示你哪些朋友已经在使用简书，这是如何做到的呢？
最传统的办法是让用户直接在简书的登录页面输微博的账号和密码，简书通过用户的账号和密码去微博那里获取用户数据，但这样做有很多严重的缺点：
- 简书需要明文保存用户的微博账号和密码，这样很不安全。
- 简书拥有了获取用户在微博所有的权限，包括删除好友、给好友发私信、更改密码、注销账号等危险操作。
- 用户只有修改密码，才能收回赋予简书的权限。但是这样做会使得其他所有获得用户授权的第三方应用程序全部失效。
- 只要有一个第三方应用程序被破解，就会导致用户密码泄漏，以及所有使用微博登录的网站的数据泄漏。
为了解决以上的问题，OAuth 协议应运而生。
2、定义
OAuth2.0（开放授权）是一个关于授权的开放的网络协议。
--->允许用户让第三方应用访问该用户在某一网站上存储的的资源（如：照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。
--->OAuth是一个关于授权（Authorization）的开放网络标准，目前的版本是2.0版。注意是Authorization(授权)，而不是Authentication(认证)。用来做Authentication(认证)的标准叫openid connect。
3、基本原理
OAuth在第三方应用与服务提供商之间设置了一个授权层。第三方应用不能直接登录服务提供商，只能登录授权层，以此将用户与客户端区分开来。第三方应用登录授权层所用的令牌，与用户的密码不同。用户可以在登录授权的时候，指定授权层令牌的权限范围和有效期。
第三方应用登录授权层以后，服务提供商根据令牌的权限范围和有效期，向第三方应用开放用户资源。
4、作用
让客户端安全可控地获取用户的授权，与服务提供商之间进行交互。可以免去用户同步的麻烦，同时也增加了用户信息的安全。
5、常用应用场景
- 用OAuth来实现第三方应用对我们API的访问控制；
- 登录第三方应用（APP或网页）时，经常会采用其他用户登录方式，比如QQ，微博，微信的授权登录（QQ用户登录）。
6、协议流程
（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
不难看出来，上面六个步骤之中，B是关键，即用户怎样才能给于客户端授权。有了这个授权以后，客户端就可以获取令牌，进而凭令牌获取资源。
7、客户端的授权模式
----客户端获取授权的四种模式
客户端必须得到用户的授权（authorization grant），才能获得令牌（access token）。OAuth 2.0定义了四种授权方式。
- 授权码模式（authorization code）
- 简化模式（implicit）
- 密码模式（resource owner password credentials）
- 客户端模式（client credentials）
（1）授权码模式（authorization code）
功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。
（2）简化模式（implicit grant type）
不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
（3）密码模式（Resource Owner Password Credentials Grant）
用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。
（4）客户端模式（Client Credentials Grant）
指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。
注：web资源：其实就是接口。
二、授权码模式
---以使用微博账号登录简书为示例详细讲解其工作原理
1、原理概要
新浪微博作为服务提供商，拥有用户的头像、昵称、邮箱、好友以及所有的微博内容，简书希望获取用户存储在微博的头像和昵称，假设它们是三个人：
- 简书问新浪微博：我想要获取用户 A 的头像和昵称，请你提供
- 微博说：我需要经过用户Ａ 本人的许可，然后去问用户 A 是否要授权简书访问自己的头像和昵称
- 用户 A 对微博说：我给简书一个临时的钥匙，如果他给你出示了这把钥匙，你就把我的资料给他
- 简书使用户给它的钥匙获取用户头像和昵称信息。
以上是 OAuth 认证的大概流程。在使用微博授权之前，简书需要先在微博开放平台上注册应用，填写自己的名称、logo、用途等信息，微博开放平台颁发给简书一个应用 ID 和叫 APP Secret 的密钥，在实际对接中，会使用到这两个参数。
注：
- 新浪微博开放平台即是认证服务器
- 用户发放code（时间极短）
认证服务器发放 token（时间长） - 资源服务器提供用户资源
2、详细流程
接下来分步详细解释上图中每步都做了什么：
1.用户点击简书上的微博登录按钮，跳转到微博授权页面。微博登录按钮的链接形如下方的 URL：
https://api.weibo.com/oauth2/authorize?client_id=123050457758183&redirect_uri=http://jianshu.com/callback
URL 中要包含以下参数：
- client_id：在微博开放平台申请的应用 ID
- redirect_uri：授权成功后要跳转到的地址
点击以上链接后跳转到微博的授权页面如下图：
这个页面会告诉用户第三方应用要获取用户的哪些数据，以及拥有什么权限，比如在上图中简书会要求获得个人信息、好友关系、分享内容到微博以及获得评论的权限，用户点击“允许”则表示允许简书获得这些数据，进行下一步。
2.页面自动跳转到初始参数中redirect_uri 定义的那个URL，并自动在 URL 末尾添加一个 code 参数，实际跳转的地址形如:
http://jianshu.com/callback?code=2559200ecd7ea433f067a2cf67d6ce6c
3.第三步，简书通过上一步获取的 code 参数换取 Token，Token 就是前文中说到的钥匙。简书请求如下的接口获取 Token：
POST https://api.weibo.com/oauth2/access_token
要包含以下参数：
- client_id：在微博开放平台申请的应用 ID
- client_secret：在微博开放平台申请时提供的APP Secret
- grant_type：需要填写authorization_code
- code：上一步获得的 code
- redirect_uri：回调地址，需要与注册应用里的回调地址以及第一步的 redirect_uri 参数一致
注：获取token十分重要，采用POST方式比较安全。
4.通过第三步的请求，接口返回 Token 和相关数据：
{
"access_token": "ACCESS_TOKEN",//Token 的值
"expires_in": 1234,//过期时间
"uid":"12341234"//当前授权用户的UID。
}
5.在第四步中获取了access_token ，使用它，就可以去获取用户的资源了，要获取用户昵称和头像，请求如下接口：
GET https://api.weibo.com/2/users/show.json
携带参数：
- access_token：上一步获取的access_token
- uid：用户的账号 id，上一步的接口有返回
注：access_token使用时间有限，若失效，常用的解决方法：
- 重新授权登录
- 使用refresh_token，重新申请。（一般用在不间断连续在线）
6.最后一步，微博返回用户信息，简书进行处理，整个流程结束。
通过以上的方式，在简书和新浪微博中间建立了一个独立的权限层，这个权限由用户赋予，可以被用户随时取消，不同第三方应用之间相互独立，互不干扰，这样就彻底解决了明文存放账号密码的问题。
总结：
目前很多互联网公司都提供了自己的开放平台使第三方应用接入。开源项目中也有很多框架提供了OAuth的实现，例如Spring Security OAuth，Apache Oltu等。使用OAuth协议能够很好的保证第三方应用访问用户数据的安全性。
原文地址：https://www.cnblogs.com/xiaofengwang/p/11376881.html