一、概述
SSO是Single Sign On的缩写，OAuth是Open Authority的缩写，这两者都是使用令牌的方式来代替用户密码访问应用。流程上来说他们非常相似，但概念上又十分不同。SSO大家应该比较熟悉，它将登录认证和业务系统分离，使用独立的登录中心，实现了在登录中心登录后，所有相关的业务系统都能免登录访问资源。
OAuth2.0原理可能比较陌生，但平时用的却很多，比如访问某网站想留言又不想注册时使用了微信授权。以上两者，你在业务系统中都没有账号和密码，账号密码是存放在登录中心或微信服务器中的，这就是所谓的使用令牌代替账号密码访问应用。
二、SSO
两者有很多相似之处，下面我们来解释一下这个过程。先来讲解SSO，通过SSO对比OAuth2.0，才比较好理解OAuth2.0的原理。SSO的实现有很多框架，比如CAS框架，以下是CAS框架的官方流程图。特别注意：SSO是一种思想，而CAS只是实现这种思想的一种框架而已
三、OAuth2.0
OAuth2.0有多种模式，这里讲的是OAuth2.0授权码模式，OAuth2.0的流程跟SSO差不多，在OAuth2中，有授权服务器、资源服务器、客户端这样几个角色，当我们用它来实现SSO的时候是不需要资源服务器这个角色的，有授权服务器和客户端就够了。
授权服务器当然是用来做认证的，客户端就是各个应用系统，我们只需要登录成功后拿到用户信息以及用户所拥有的权限即可
-
用户在某网站上点击使用微信授权，这里的某网站就类似业务系统，微信授权服务器就类似单点登录系统
-
之后微信授权服务器返回一个确认授权页面，类似登录界面，这个页面当然是微信的而不是业务系统的
-
用户确认授权，类似填写了账号和密码，提交后微信鉴权并返回一个ticket，并重定向业务系统。
-
业务系统带上ticket访问微信服务器，微信服务器返回正式的token，业务系统就可以使用token获取用户信息了
简介一下OAuth2.0的四种模式：
授权码（authorization-code）
授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web 应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。
隐藏式（implicit）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）
密码式（password）
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）。
客户端凭证（client credentials）
最后一种方式是凭证式（client credentials），适用于没有前端的命令行应用，即在命令行下请求令牌。
四、说一下几个名词的区别
首先，SSO 是一种思想，或者说是一种解决方案，是抽象的，我们要做的就是按照它的这种思想去实现它
其次，OAuth2 是用来允许用户授权第三方应用访问他在另一个服务器上的资源的一种协议，它不是用来做单点登录的，但我们可以利用它来实现单点登录。在本例实现SSO的过程中，受保护的资源就是用户的信息（包括，用户的基本信息，以及用户所具有的权限），而我们想要访问这这一资源就需要用户登录并授权，OAuth2服务端负责令牌的发放等操作，这令牌的生成我们采用JWT，也就是说JWT是用来承载用户的Access_Token的
五、实际应用
OAuth 2 是一个授权框架，或称授权标准，它可以使第三方应用程序或客户端获得对HTTP服务上（例如 Google，GitHub ）用户帐户信息的有限访问权限。OAuth 2 通过将用户身份验证委派给托管用户帐户的服务以及授权客户端访问用户帐户进行工作。综上，OAuth 2 可以为 Web 应用 和桌面应用以及移动应用提供授权流程。
本文将从OAuth 2 角色，授权许可类型，授权流程等几方面进行讲解。
在正式讲解之前，这里先引入一段应用场景，用以与后文的角色讲解对应。
开发者A注册某IT论坛后，发现可以在信息栏中填写自己的 Github 个人信息和仓库项目，但是他又觉得手工填写十分麻烦，直接提供 Github 账户和密码给论坛管理员帮忙处理更是十分智障。
不过该论坛似乎和 Github 有不可告人的秘密，开发者A可以点击“导入”按钮，授权该论坛访问自己的 Github 账户并限制其只具备读权限。这样一来， Github 中的所有仓库和相关信息就可以很方便地被导入到信息栏中，账户隐私信息也不会泄露。
这背后，便是 OAuth 2 在大显神威。
5.1 OAuth2 角色
OAuth 2 标准中定义了以下几种角色：
- 资源所有者（Resource Owner）
- 资源服务器（Resource Server）
- 授权服务器（Authorization Server）
- 客户端（Client）
1 资源所有者（Resource Owner）
资源所有者是 OAuth 2 四大基本角色之一，在 OAuth 2 标准中，资源所有者即代表授权客户端访问本身资源信息的用户（User），也就是应用场景中的“开发者A”。客户端访问用户帐户的权限仅限于用户授权的“范围”（aka. scope，例如读取或写入权限）。
如果没有特别说明，下文中出现的"用户"将统一代表资源所有者。
2 资源/授权服务器（Resource/Authorization Server）
资源服务器托管了受保护的用户账号信息，而授权服务器验证用户身份然后为客户端派发资源访问令牌。
在上述应用场景中，Github 既是授权服务器也是资源服务器，个人信息和仓库信息即为资源（Resource）。而在实际工程中，不同的服务器应用往往独立部署，协同保护用户账户信息资源。
3 客户端（Client）
在 OAuth 2 中，客户端即代表意图访问受限资源的第三方应用。在访问实现之前，它必须先经过用户者授权，并且获得的授权凭证将进一步由授权服务器进行验证。
如果没有特别说明，下文中将不对"应用"，“第三方应用”，“客户端”做出区分。
5.2. OAuth 2 的授权流程
目前为止你应该对 OAuth 2 的角色有了些概念，接下来让我们来看看这几个角色之间的抽象授权流程图和相关解释。
请注意，实际的授权流程图会因为用户返回授权许可类型的不同而不同。但是下图大体上能反映一次完整抽象的授权流程。
- Authrization Request
客户端向用户请求对资源服务器的authorization grant。 - Authorization Grant（Get）
如果用户授权该次请求，客户端将收到一个authorization grant。 - Authorization Grant（Post）
客户端向授权服务器发送它自己的客户端身份标识和上一步中的authorization grant，请求访问令牌。 - Access Token（Get）
如果客户端身份被认证，并且authorization grant也被验证通过，授权服务器将为客户端派发access token。授权阶段至此全部结束。 - Access Token（Post && Validate）
客户端向资源服务器发送access token用于验证并请求资源信息。 - Protected Resource（Get）
如果access token验证通过，资源服务器将向客户端返回资源信息。
5.3. 客户端应用注册
在应用 OAuth 2 之前，你必须在授权方服务中注册你的应用。如 Google Identity Platform 或者 Github OAuth Setting，诸如此类 OAuth 实现平台中一般都要求开发者提供如下所示的授权设置项。
- 应用名称
- 应用网站
- 重定向URI或回调URL
重定向URI是授权方服务在用户授权（或拒绝）应用程序之后重定向供用户访问的地址，因此也是用于处理授权码或访问令牌的应用程序的一部分。
1 Client ID 和 Client Secret
一旦你的应用注册成功，授权方服务将以client id和client secret的形式为应用发布client credentials（客户端凭证）。client id是公开透明的字符串，授权方服务使用该字符串来标识应用程序，并且还用于构建呈现给用户的授权 url 。当应用请求访问用户的帐户时，client secret用于验证应用身份，并且必须在客户端和服务之间保持私有性。
2. 授权许可（Authorization Grant）
如上文的抽象授权流程图所示，前四个阶段包含了获取authorization grant和access token的动作。授权许可类型取决于应用请求授权的方式和授权方服务支持的 Grant Type。OAuth 2 定义了四种 Grant Type，每一种都有适用的应用场景。
- 授权码
结合普通服务器端应用使用。 - 简化模式
结合移动应用或 Web App 使用。 - 密码
适用于受信任客户端应用，例如同个组织的内部或外部应用。 - 客户端模式
适用于客户端调用主服务API型应用（比如百度API Store）
扫一扫
1243
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
