白话文的意思就是：你需要用身份证证明你自己是你自己。
比如我们常见的认证技术：
在现实生活领域：门禁卡需要通过门禁卡识别器，银行卡需要通过银行卡识别器；
在互联网领域：校验session/cookie/token的合法性和有效性
权限控制(Access/PermissionControl)将可执行的操作定义为权限列表，然后判断操作是否允许/禁止
对于权限控制，可以分为两部分进行理解：一个是权限，另一个是控制。权限是抽象的逻辑概念，而控制是具体的实现方式。
在现实生活领域中：以门禁卡的权限实现为例，一个门禁卡，拥有开公司所有的门的权限；一个门禁卡，拥有管理员角色的权限，因而可以开公司所有的门。
在互联网领域：通过web后端服务，来控制接口访问，允许或拒绝访问请求。
需要说明的是，这四个环节在有些时候会同时发生。例如在下面的几个场景：
在HTTP中，基本认证方案（BasicAccessAuthentication)是允许客户端（通常指的就是网页浏览器）在请求时，通过用户提供用户名和密码的方式，实现对用户身份的验证。
因为几乎所有的线上网站都不会走该认证方案，所以该方案大家了解即可
（1）客户端(如浏览器)：向服务器请求一个受限的列表数据或资源，例如字段如下
GET/list/HTTP/1.1Host:www.baidu.comAuthorization:BasicaHR0cHdhdGNoOmY=
（2）服务器：客户端你好，这个资源在安全区baidu.com里，是受限资源，需要基本认证；
其中Basic就是验证的模式，而realm="baidu.com"说明客户端需要输入这个安全域的用户名和密码，而不是其他域的
HTTP/1.1401Unauthorizedwww-Authenticate:Basicrealm="baidu.com"
（3）客户端：服务器，我已经携带了用户名和密码给你了，你看一下；（注：如客户端是浏览器，那么此时会自动弹出一个弹窗，让用户输入用户名和密码）；
输入完用户名和密码后，则客户端将用户名及密码以Base64加密方式发送给服务器
传送的格式如下(其中Basic内容为：用户名:密码的ase64形式)：
GET/list/HTTP/1.1Authorization:BasicKsid2FuZzp3YW5n==
（4）服务器：客户端你好，我已经校验了Authorization字段你的用户名和密码，是正确的，这是你要的资源。
成功：HTTP/1.1200OK失败：HTTP/1.1403Forbidden
2.3.1优点
实现简单，基本所有流行的浏览器都支持
2.3.2缺点
（1）不安全：
（2）无法主动注销：
由于HTTP协议没有提供机制清除浏览器中的Basic认证信息，除非标签页或浏览器关闭、或用户清除历史记录。
内部网络，或者对安全要求不是很高的网络。
Session-Cookie认证是利用服务端的Session（会话）和浏览器（客户端）的Cookie来实现的前后端通信认证模式。
在理解这句话之前我们先简单了解下什么是Cookie以及什么是Session？
3.1什么是Cookie
众所周知，HTTP是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）；
所以为了让服务器区分不同的客户端，就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态可以通过Cookie去实现。
特点：
3.2什么是Session
Session的抽象概念是会话，是无状态协议通信过程中，为了实现中断/继续操作，将用户和服务器之间的交互进行的一种抽象；
具体来说，是服务器生成的一种Session结构，可以通过多种方式保存，如内存、数据库、文件等，大型网站一般有专门的Session服务器集群来保存用户会话；
原理流程：
与Cookie的差异：
看到这里可能就有人想到了，Session-Cookie是不是就是把Session存储在了客户端的Cookie中呢？是的，的确是这样的，我们接着往下看
3.3Session-Cookie的认证流程图
3.4Session-Cookie认证步骤解析
注：可以使用签名对sid进行加密处理，服务端会根据对应的secret密钥进行解密（非必须步骤）
3.5Session-Cookie优缺点对比
优点
缺点
3.6使用场景
现在我们已经得知，Session-Cookie的一些缺点，以及Session的维护给服务端造成很大困扰，我们必须找地方存放它，又要考虑分布式的问题，甚至要单独为了它启用一套Redis集群。那有没有更好的办法？
那Token就应运而生了
Token是一个令牌，客户端访问服务器时，验证通过后服务端会为其签发一张令牌，之后客户端就可以携带令牌访问服务器，服务端只需要验证令牌的有效性即可。
一句话概括；访问资源接口（API）时所需要的资源凭证
一般Token的组成：
Token的认证流程图：
Token认证步骤解析：
Token的优点：
Token的缺点：
业务接口用来鉴权的Token，我们称之为AccessToken。
为了安全，我们的AccessToken有效期一般设置较短，以避免被盗用。但过短的有效期会造成AccessToken经常过期，过期后怎么办呢？
另外一种办法是：再来一个Token，一个专门生成AccessToken的Token，我们称为RefreshToken；
RefreshToken的认证流程图：
RefreshToken认证步骤解析：
4.3Token和Session-Cookie的区别
Session-Cookie和Token有很多类似的地方，但是Token更像是Session-Cookie的升级改良版。
如果你的用户数据可能需要和第三方共享，或者允许第三方调用API接口，用Token。如果永远只是自己的网站，自己的App，用什么就无所谓了。
5、OAuth2.0认证方案
5.1OAuth2.0定义
5.2OAuth2.0角色
（A）资源拥有者（RO）（B）客户端（Client）（C）资源服务器（RS）（D）授证服务器（AS)。
5.3OAuth2.0认证流程
5.3.1、OAuth2.0流程图
关键步骤：
说明备注：
5.3.2、隐式许可模式
所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
5.3.3、密码凭证模式
密码凭证模式（ResourceOwnerPasswordCredentialsGrant）中，用户向客户端提供自己的用户名和密码。
5.3.4客户端凭证模式
（A）客户端向认证服务器进行身份认证，并要求一个访问令牌。（B）认证服务器确认无误后，向客户端提供访问令牌。
备注说明：
6、JWTToken验证
我们知道了Token的使用方式以及组成，我们不难发现，服务端验证客户端发送过来的Token时，还需要查询数据库获取用户基本信息，然后验证Token是否有效；
这样每次请求验证都要查询数据库，增加了查库带来的延迟等性能消耗；
那么这时候业界常用的JWT就应运而生了！！！
6.2JWT的组成
JWT由三部分组成：Header头部、Payload负载和Signature签名
它是一个很长的字符串，中间用点（.）分隔成三个部分。列如：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
Header头部：
在Header中通常包含了两部分：
{"alg":"HS256","typ":"JWT"}
Payload负载：
除了官方字段，你还可以在这个部分定义私有字段，下面就是一个例子。
{"sub":"1234567890","name":"JohnDoe","admin":true}
Signature签名
Signature部分是对前两部分的签名，防止数据篡改。
首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用Header里面指定的签名算法（默认是HMACSHA256），按照下面的公式产生签名。
HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)
JWT加密、解密标例
客户端收到服务器返回的JWT，可以储存在Cookie里面，也可以储存在localStorage。
此后，客户端每次与服务器通信，都要带上这个JWT。你可以把它放在Cookie里面自动发送，但是这样不能跨域，所以更好的做法是放在HTTP请求的头信息Authorization字段里面。
Authorization:Bearer
其实JWT的认证流程与Token的认证流程差不多，只是不需要再单独去查询数据库查找用户用户；简要概括如下：
优点：
缺点：
我们集团内部有很多个业务系统包括（三大体系：职能、制造、营销）：
职能系统：OA系统、商旅系统、财务系统、培训系统、BPM、ERP；
制造系统：MES、MLP、MOM、MSCS、WCC、MTCS、TIMS、SRM、WMS、PLM、......
营销系统：用户中心、设计软件、客服400系统、客情调查问卷、订单系统，账号系统、活动系统、促销系统、会员系统、CRM、电商引流、营销补贴、学习培训、传单系统等各种独立的业务中台和数据中台共有60多个子系统。
1、集团内部已经有非常多个子系统，算下来大大小小有130多个子系统；
3、关键难搞的是只要涉及到财务和生产制造系统，保持系统稳定的指标压倒其他一切；
4、营销体系的各个系统相对比较新，采用Oauth2协议认证，实现营销体系内部统一认证。
7.1集团认证方案设计
7.1.1早期基于CAS集成SSO服务
整体逻辑概图
①用户请求访问业务系统。
②业务系统在系统中查看是否有对应请求的有效令牌，若有，则读取对应的身份信息，允许其访问；若没有或令牌无效，则把用户重定向到统一身份认证平台，并携带业务系统地址，进入第③步。
③在统一身份认证平台提供的页面中，用户输入身份凭证信息，平台验证此身份凭证信息，若有效，则生成一个有效的令牌给用户，进入第④步；若无效，则继续进行认证，直到认证成功或退出为止。
④用户携带第③步获取的令牌，再次访问业务系统。
⑤业务系统获取用户携带的令牌，提交到认证平台进行有效性检查和身份信息获取。
⑥若令牌通过有效性检查，则认证平台会把令牌对应的用户身份信息返回给业务系统，业务系统把身份信息和有效令牌写入会话状态中，允许用户以此身份信息进行业务系统的各种操作；若令牌未通过有效性检查，则会再次重定向到认证平台，返回第③步。
通过统一身份认证平台获取的有效令牌，可以在各个业务系统之间实现应用漫游。
sso的实现技术点：
1）所有应用系统共享一个身份认证系统。
2）所有应用系统能够识别和提取ticket信息
基于CASPC端认证流程时序图
下面对每个场景做单独阐述
二、移动端的认证方式，（Android、iOS）原理是一样的，移动端在本地是有一个小型的关系数据库，叫做sqllite，不过这个关系数据库比较小，就像一个文件夹似的内置，因为移动端本身并没有像我们web端的cookie机制，所以我们使用这个sqlite作为票据存储。
基于CAS移动端认证流程时序图
工作步骤如下：
2、认证通过、返回tgt，然后本地存储这个tgt
3、请求st、并且以上一步请求到的tgt作为参数
4、sso服务器返回st
5、移动端访问业务系统，并且携带st作为参数
6、业务系统接收到请求，会向sso服务器校验st是否有效
基于CAS关键类图
基于CAS集成存在的问题：
1、移动端集成起比较复杂和繁琐。
2、在实际生产使用过程当经常出现tgt串号的问题，多次被业务方投诉。
3、性能问题，随着接入系统越来越多，认证中点不堪其负，出现压力故障。
7.1.2基于OAuth2集成认证中心
营销体系与其他外部的集成示例
营销体系Oauth2认证方案
1、用户客户端所有请求都先经过网关gateway（如前后端分离设计的API请求）；
3、用户发起API请求，先经过网关系统token验证，通过才能进入下一步；
4、网关通过后，拿accessToken调用鉴权服务请求鉴权，鉴权通过，转发到真正的业务服务去；
5、业务服务返回API请求结果。
7.2关键问题
集团内部CAS单点与营销系统Oauth2.0认证内部打通隧道建立互信机制。
3、用户在任意一个体系注销，两边系统都会互发一次消息通知。
7.3核心代码实现
1、通过本文，我们可以全面系统学习认证体系的原理和设计方案；