名词解释

1.什么是 CAS

CAS全称叫做中央认证服务，英文是 Central Authentication Service。这是由耶鲁大学发起的一个开源项目，目的是帮助 Web 应用系统构建一种可靠的单点登录解决方案。

概念：

TGT：Ticket Grangting Ticket

TGT 是 CAS 为用户签发的登录票据，拥有了 TGT，用户就可以证明自己在 CAS 成功登录过。TGT 封装了 Cookie 值以及此 Cookie 值对应的用户信息。当 HTTP 请求到来时，CAS 以此 Cookie 值（TGC）为 key 查询缓存中有无 TGT ，如果有的话，则相信用户已登录过。

TGC：Ticket Granting Cookie

CAS Server 生成TGT放入自己的 Session 中，而 TGC 就是这个 Session 的唯一标识（SessionId），以 Cookie 形式放到浏览器端，是 CAS Server 用来明确用户身份的凭证。

ST：Service Ticket

ST 是 CAS 为用户签发的访问某一 service 的票据。用户访问 service 时，service 发现用户没有 ST，则要求用户去 CAS 获取 ST。用户向 CAS 发出获取 ST 的请求，CAS 发现用户有 TGT，则签发一个 ST，返回给用户。用户拿着 ST 去访问 service，service 拿 ST 去 CAS 验证，验证通过后，允许用户访问资源。

1.1 CAS 架构

CAS 分为两部分：
一个是 CAS Server，这是单点验证服务，作用类似于我们OAuth2+JWT 方案中的授权服务器，用来校验用户名/密码等，一般来说都是独立部署。
另一个则是 CAS Client，相当于就是一个一个的（微）服务。

1.2 支持平台

• CAS Client 支持的平台有：
• Apache httpd Server (mod_auth_cas module)
• Java (Java CAS Client)
• .NET (.NET CAS Client)
• PHP (phpCAS)
• Perl (PerlCAS)
• Python (pycas)Ruby (rubycas-client)

2. OAuth2.0

OAuth 全称是 Open Authentication

开放授权（OAuth）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。 OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth让用户可以授权第三方网站访问他们存储在另外服务提供者的某些特定信息，而非所有内容。

2.1 OAuth 2.0术语

• 资源拥有者（resource owner): app用户，拥有app想要的数据（用户名，头像等）
• 客户（client）：app
• 授权服务器（Authorization server）:授权的系统
• 资源服务器（Resource server）：拥有用户数据的系统
• 授权许可（Authorization grant）：用户对于数据授权的证明
• Redirect Uri（重定向Uri）：当用户允许之后，重定向到的地方
• 访问令牌（access token）：从资源服务器获取数据的令牌
• 访问（Scope）：决定app可以对用户进行的操作的等级

2.2 OAuth2.0流程

• 客户端向资源所有者请求其授权
• 客户端收到资源所有者的授权许可，这个授权许可是一个代表资源所有者授权的凭据
• 客户端向授权服务器请求访问令牌，并出示授权许可
• 授权服务器对客户端身份进行认证，并校验授权许可，如果都是有效的，则发放访问令牌
• 客户端向资源服务器请求受保护的资源，并出示访问令牌
• 资源服务器校验访问令牌，如果令牌有效，则提供服务

2.3 OAuth2.0 授权方式

授权方式有四种

2.3.1. Authorization Code

授权码是授权服务器用来获取并作为客户端和资源所有者之间的中介。代替直接向资源所有者请求授权，客户端定向资源所有者到一个授权服务器，授权服务器反过来指导资源所有者将授权码返回给客户端。在将授权码返回给客户端之前，授权服务器对资源所有者进行身份验证并获得授权。因为资源所有者只对授权服务器进行身份验证，所以资源所有者的凭据永远不会与客户机共享。

2.3.2. Implicit

隐式授权是为了兼顾到在浏览器中用诸如JavaScript的脚本语言实现的客户端而优化的简化授权代码流程。在隐式授权流程中，不是发给客户端一个授权码，而是直接发给客户端一个访问令牌，而且不会对客户端进行认证。隐式授权提高了一些客户端（比如基于浏览器实现的客户端）的响应能力和效率，因为它减少了获得访问令牌所需的往返次数。

2.3.3. Resource Owner Password Credentials

资源所有者的密码凭据（比如，用户名和密码）可以直接作为授权许可来获取访问令牌。这个凭据只应该用在高度信任的资源所有者和客户端之间（比如，客户端是系统的一部分，或者特许的应用），并且其它授权模式不可用的时候。

2.3.4. Client Credentials

客户端凭据通常用作授权许可，凭证式和密码式很相似，主要适用于没有前端的纯后台应用。