OAuth2协议概述

什么是OAuth2

OAuth（开放授权）是一个开放标准，允许用户授权第三方应用访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方应用或分享他们数据的所有内容。

OAuth2是OAuth协议的延续版本，但不向后兼容OAuth1即完全废止了OAuth1。

综上：OAuth2 可以为Web应用、桌面应用、移动应用提供授权流程。

角色

• Third-party application：第三方应用程序，本文中又称"客户端"（client）
• HTTP service：HTTP服务提供商，本文中简称"服务提供商"
• Resource Owner：资源所有者，本文中又称"用户"（user）。
• User Agent：用户代理，本文中就是指浏览器。
• Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
• Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

客户端注册

在应用OAuth2之前，必须在授权方服务中注册你的应用。如微信、QQ。

OAuth2实现平台中，一般都要求开发者提供如下所示的授权设置项：

• 应用名称
• 应用网站
• 重定向URI或回调URL

重定向URI是授权方服务在用户授权（或拒绝）应用程序之后重定向供用户访问的地址，因此也是用于处理授权码或访问令牌的应用程序的一部分。

一旦应用注册成功，授权方服务将以 client id 和 client secret 的形式为应用发布client credentials（客户端凭证）。client id是公开透明的字符串，授权方服务使用该字符串来标识应用程序，并且还用于构建呈现给用户的授权 url 。当应用请求访问用户的帐户时，client secret用于验证应用身份，并且必须在客户端和服务之间保持私有性。

运行流程

OAuth2在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层后申请的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

运行流程

• 用户打开客户端以后，客户端要求用户给予授权；
• 用户同意给予客户端授权；
• 客户端使用上一步获得的授权，向认证服务器申请令牌；
• 认证服务器对客户端进行认证以后，确认无误，同意发放令牌；
• 客户端使用令牌，向资源服务器申请获取资源；
• 资源服务器确认令牌无误，同意向客户端开放资源；

授权协议

授权许可类型取决于应用请求授权的方式和授权方服务支持的 Grant Type。OAuth 2 定义了四种 Grant Type，每一种都有适用的应用场景。

• 授权码模式（authorization code）
  采用Authorization Code（授权码）获取Access Token的授权验证流程又被称为Web Server Flow，适用于所有 有Server端 的应用，如Web/Wap站点、有Server端__的手机/桌面客户端应用等。

• 简化模式（implicit）
  采用Implicit Grant（隐式授权）方式获取Access Token的授权验证流程与OAuth 2.0标准的User-Agent Flow相同，适用于所有无Server端配合的应用（由于应用往往位于一个User Agent里，如浏览器里面，因此这类应用在某些平台下又被称为Client-Side Application），如手机/桌面客户端程序、浏览器插件等, 他们的一个共同特点是，应用无法妥善保管其应用密钥（App Secret Key），如果采取Authorization Code模式，则会存在泄漏其应用密钥的可能性。

• 密码模式（Password）
  适用于受信任客户端应用，例如同个组织的内部或外部应用。

• 客户端模式（client credentials）
  适用于客户端调用主服务API型应用（比如百度API Store）

授权码模式

授权码模式（authorization code）是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器，与"服务提供商"的认证服务器进行互动。

授权码模式

• 用户访问客户端，后者将前者导向认证服务器；
• 用户选择是否给予客户端授权；
• 假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码；
• 客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见；
• 认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）；

简化模式

简化模式（implicit grant type）不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了"授权码"这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。

简化模式

• 客户端将用户导向认证服务器；
• 用户决定是否给于客户端授权；
• 假设用户给予授权，认证服务器将用户导向客户端指定的"重定向URI"，并在URI的Hash部分包含了访问令牌；
• 浏览器向资源服务器发出请求，其中不包括上一步收到的Hash值；
• 资源服务器返回一个网页，其中包含的代码可以获取Hash值中的令牌；
• 浏览器执行上一步获得的脚本，提取出令牌；
• 浏览器将令牌发给客户端；

密码模式

密码模式（Resource Owner Password Credentials Grant）中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。

在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，比如客户端是操作系统的一部分，或者由一个著名公司出品。而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

授权码模式

• 用户向客户端提供用户名和密码；
• 客户端将用户名和密码发给认证服务器，向后者请求令牌；
• 认证服务器确认无误后，向客户端提供访问令牌；

客户端模式

客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

客户端模式

• 客户端向认证服务器进行身份认证，并要求一个访问令牌；
• 认证服务器确认无误后，向客户端提供访问令牌；

转载于:https://www.jianshu.com/p/468ddfb5c3a9