OAuth2.0和sso单点登陆原理

OAuth 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。

那么为什么需要授权机制,这里引出另外一个词:单点登录( Single Sign On)SSO。

单点登录解决的是:在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。这也是为了解决多点登录系统中,每个站点都实现了本站专用的帐号数据库和登录模块。各站点的登录状态相互不认可,各站点需要逐一手工登录的麻烦。

因而,通过一种授权机制来实现单点登录。

2.OAuth2.0

OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。OAuth 的核心就是向第三方应用颁发令牌。

首先需要解释几个名词:

客户端(client)、资源所有者(Resource Owner)、资源服务器(Resource server)

OAuth2.0和sso单点登陆原理

OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种,向第三方应用颁发令牌。下面就是这四种授权方式。

授权码(authorization-code)

隐藏式(implicit)

密码式(password)

客户端凭证(client credentials)

OAuth2.0和sso单点登陆原理

为什么有这么多方式,每一种方式,都有不同的应用环境。

首先说一下,目前最流行的方式:

授权码(authorization code)方式,指的是第三方应用先申请一个授权码,然后再用该码获取令牌。

适用于:那些有后端的 Web 应用。授权码通过前端传送,令牌则是储存在后端,而且所有与资源服务器的通信都在后端完成。这样的前后端分离,可以避免令牌泄漏。例如:通过微信,QQ,github登录等。下图是说明请求的简单过程。

OAuth2.0和sso单点登陆原理

response_type=code

实例:

https://b.com/oauth/authorize? response_type=code& client_id=CLIENT_ID& redirect_uri=CALLBACK_URL& scope=read

隐藏式:有些 Web 应用是纯前端应用,没有后端。这时就不能用上面的方式了,必须将令牌储存在前端。RFC 6749 就规定了第二种方式,允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤,所以称为(授权码)"隐藏式"(implicit)。

response_type=token

实例:
https://b.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

OAuth2.0和sso单点登陆原理

密码式: 如果你高度信任某个应用,RFC 6749 也允许用户把用户名和密码,直接告诉该应用。该应用就使用你的密码,申请令牌,这种方式称为"密码式"(password)。

grant_type=password

https://b.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

凭证式: 适用于没有前端的命令行应用,即在命令行下请求令牌。

grant_type=client_credentials

https://b.com/token?grant_type=client_credentials&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

滚动至顶部