计算机本身无法判断坐在显示器前的使用者的身份，也无法确认网络的另一端的是谁。为了明确是谁在访问服务器，必须让客户端自报家门。
通常核对一些登录者本人的信息：
- 密码：只有本人知道的字符串信息
- 动态令牌：仅限本人持有的设备内显示的一次性密码
- 数字证书：仅限本人（终端）持有的信息
- 生物认证：指纹和虹膜等本人生理信息
- 身份证号、手机号等：仅限本人持有的信息
Basic 身份认证，是 HTTP 1.0 中引入的认证方案之一。虽然方案比较古老，实现简单，同时存在安全缺陷。通过核对用户名、密码的方式，来实现用户身份的验证。
关于realm：同一个 server，访问受限的资源多种多样，比如资金信息、机密文档等。可以针对不同的资源定义不同的 realm，并且只允许特定的用户访问。跟Linux下的账户、分组体系很像。
在进行 BASIC 认证的过程中，HTTP 的请求头字段会包含 Authorization 字段，Authorization: Basic <用户凭证>，该<用户凭证>是 userid 和 password 的组合而成的 Base64 编码。
GET /securefiles/ HTTP/1.1
Host: www.example.com
Authorization: Basic aHR0cHdhdGNoOmY=BASIC 认证流程图：
1. 用户在浏览器中访问了受限制的网页资源，但是没有提供用户的身份信息
2. 服务端接收到请求后返回 401 应答码（Unauthorized，未被授权的）要求进行身份验证，并附带提供了一个认证域（Access Authentication）WWW-Authenticate 说明如何进行验证的方法，例如 WWW-Authenticate: Basic realm="Secure Area"，Basic 就是验证的模式，而 realm="Secure Area" 则为保护域（告知认证的范围），用于与其他请求 URI 作区别
3. 浏览器收到应答后，会显示该认证域给用户并提示输入用户名和密码，此时用户可以选择录入信息后确定或取消操作
4. 用户输入了用户名和密码后，浏览器会在原请求头新增认证消息字段 Authorization 并重新发送请求，过程如下：
用户名:密码 格式的字符串Basic，设置为 Authorization 字段，假设用户名为 admin，密码为 password，则拼接后为 admin:password，使用 Base64 编码后为 YWRtaW46cGFzc3dvcmQ=，那么最终在 HTTP 头部里会是这样：Authorization: Basic YWRtaW46cGFzc3dvcmQ=5. 服务端接收了该认证后并返回了用户请求的网页资源。如果用户凭证非法或无效，服务器可能会再次返回 401 应答码，客户端就需要再次输入用户名和密码
Basic 认证的安全缺陷比较明显，它通过明文传输用户的密码，在 http 等非加密通信的线路上进行 Basic 认证的过程中如果被人监听，被盗的可能性极高。
除了安全缺陷，Basic 认证还存在无法吊销认证的情况。
“摘要”式认证（ Digest authentication）是一个简单的认证机制，最初是为HTTP协议开发的，因而也常叫做HTTP摘要，在 RFC2671 中描述。其身份验证机制很简单，它在密码发出前，先对其应用哈希函数，这相对于 HTTP Basic 认证发送明文而言，更安全。
Digest 认证同样使用质询/响应的方式（challenge/response），即一开始一方会先发送需要认证的请求给另一方，接着使用从另一方接收到的质询码计算生成响应码，最后将响应码返回给对方进行认证的方式。
nonce = BASE64(time-stamp MD5(time-stamp : ETag : private-key))cnonce：客户端发送给服务器的随机字符串，使得双方都可以查验对方的身份，并对消息的完整性提供一些保护
nc：nonce计数器，是一个16进制的数值，表示同一nonce下客户端发送出请求的数量。例如，在响应的第一个请求中，客户端将发送“nc=00000001”。这个指示值的目的是让服务器保持这个计数器的一个副本，以便检测重复的请求
1. 浏览器发送http报文请求一个受保护的资源。
2. 服务端的 web 容器将 http 响应报文的响应码设为 401，响应头部比 Basic 模式复杂：
WWW-Authenticate: Digest realm="myTomcat", qop="auth", nonce="xxxxxxxxxxx", opaque="xxxxxxxx"
3. 浏览器弹出对话框让用户输入用户名和密码，浏览器对用户名、密码、nonce值、HTTP请求方法、被请求资源URI等组合后进行MD5运算，把计算得到的摘要信息发送给服务端。请求头部类似如下：
Authorization: Digest username="xxxxx", realm="myTomcat", qop="auth", nonce="xxxxx", uri="xxxx", cnonce="xxxxxx", nc=00000001, response="xxxxxxxxx", opaque="xxxxxxxxx"
其中 Authorization 内必须包含 username、realm、nonce、uri 和 responce。
4. 服务端 web 容器获取 HTTP 报文头部相关认证信息，从中获取到 username，根据 username 获取对应的密码，同样对用户名、密码、nonce 值、HTTP 请求方法、被请求资源 uri 等组合进行 MD5 运算，计算结果和 response 进行比较，如果匹配则认证成功并返回相关资源，否则再执行 2，重新进行认证。
5. 以后每次访问都要带上认证头部。
1. 基本算法：
RFC 2069定义，由服务器生成随机数来维护安全性的摘要认证架构。
HA1 = MD5(A1) = MD5(username : realm : password)
HA2 = MD5(A2) = MD5(method : uri)
response = MD5(HA1 : nonce : HA2)
2. 安全增强算法：
RFC 2617 引入一系列安全增强的选项；“保护质量”(qop)、随机数计数器由客户端增加、以及客户生成的随机数。这些增强为了防止如选择明文攻击的密码分析。
如果 qop 的值为 "auth"，那么：
HA1 = MD5(A1) = MD5(username : realm : password)
HA2 = MD5(A2) = MD5(method : uri)
response = MD5(HA1 : nonce : nc : cnonce : HA2)
如果 qop 的值为 "auth-int"，那么：
HA1 = MD5(A1) = MD5(username : realm : password)
HA2 = MD5(A2) = MD5(method : uri : MD5(entityBody))
response = MD5(HA1 : nonce : nc : cnonce : HA2)
如果没有指定 qop，将以基本算法计算。
SSL 客户端认证是借由 HTTPS 的客户端证书完成认证的方式。凭借客户端证书认证，服务器可确认访问是否来自已经登录的客户端。
多数情况下，SSL 客户端认证不会仅依靠证书完成认证，一般会和基于表单认证组合成一种双因素认证方式使用。SSL 客户端证书用来认证客户端计算机，密码用来确定用户本人。
由于使用的便利性和安全性问题，HTTP 协议标准提供的 Basic 认证和 Digest 认证几乎不怎么使用。另外，SSL 客户端认证虽然具有高度的安全等级，但因为导入及维持费用等问题，还尚未普及。所以多数情况下基于表单认证。
流程
httpOnly 的 Cookie 中，能够有效避免浏览器中的 JS 脚本对 Cookie 的修改JSON Web Token
服务器认证后，生成一个 JSON 对象，返回给用户。
此后，用户与服务端通信的时候，都要返回这个 JSON 对象。服务器完全只靠这个对象认定用户身份。为了防止用户篡改数据，服务器在生成这个对象的时候，会加上签名。
JWT 是 JSON 格式的被加密了的字符串，中间用（.）分隔成三个部分：
其中 Header 和 Payload 加密的算法是 Base64URL。
Base64URL 算法跟 Base64 算法基本类似，但有一些小的不同。
JWT 作为一个令牌（token），有些场合可能会放到 URL（比如 api.example.com/?token=xxx）。Base64 有三个字符
+、/和=，在 URL 里面有特殊含义，所以要被替换掉：=被省略、+替换成-，/替换成_。这就是 Base64URL 算法。
Header
Header 部分是一个JSON 对象，描述 JWT 的元数据，通常是下面的样子：
{
"alg": "HS256",
"typ": "JWT"
}其中，alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。
Payload
Payload 部分也是一个 JSON 对象，用来存放实际需要传递的数据。JWT 规定了7个官方字段，供选用。
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
除了官方字段，还可以在这个部分定义私有字段：
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}Signature
Signature 部分是对前两部分的签名，防止数据篡改。
首先，需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。
HMACSHA256(base64UrlEncode(Header) + '.' + base64UrlEncode(Payload), secret);JWT 默认是不加密，但也是可以加密的。生成原始 Token 以后，可以用密钥再加密一次。
JWT 不加密的情况下，不能将秘密数据写入 JWT。
JWT 不仅可以用于认证，也可以用于交换信息。有效使用 JWT，可以降低服务器查询数据库的次数。
JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
JWT 本身包含了认证信息，一旦泄露，任何人都可以获得该令牌的所有权限。为了减少盗用，JWT 的有效期应该设置得比较短。对于一些比较重要的权限，使用时应该再次对用户进行认证。
为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
单点登录（Single Sign-on）又称 SSO，是指在多系统应用群中登录单个系统，便可在其他所有系统中得到授权而无需再次登录。
当存在两个相同域名下的系统 A a.abc.com 和系统 B b.abc.com 时，以下为他们实现 SSO 的步骤：
a.abc.com），如果没有登录，则跳转至 SSO 认证中心提供的登录页面进行登录Set-Cookie 字段中，随着请求返回写入浏览器中，并回跳到设定的子系统链接中abc.com，浏览器会自动带上之前的 Cookie。此时服务端就可以通过该 Cookie 来验证登录状态了。这实际上使用的就是 Session-Cookie 认证的登录方式。
目前大多数企业的系统都是部署在不同域名下的，显然同域 SSO 并不能满足。
单点登录的标准流程要使用到 CAS。
CAS（Central Authentication Service）中央授权服务，本身是一个开源协议，分为 1.0 版本和 2.0 版本。1.0 称为基础模式，2.0 称为代理模式，适用于存在非 Web 应用之间的单点登录。
CAS 重要概念：
key 查询缓存中是否有 TGT，如果有，则表示用户已登录过。CAS 流程：
详细流程：
至此，跨域单点登录就完成了。以后我们再访问 app1 系统时，会携带 app1 的登录态 Cookie，app1 就是登录的。接下来，如果访问 app2 系统时，流程如下：
这样，app2 系统不需要走登录流程，就已经是登录了。SSO，app1 和 app2 在不同的域，它们之间的session 不共享也是没问题的。
https://juejin.cn/post/6844903586405564430
https://zh.wikipedia.org/wiki/HTTP%E6%91%98%E8%A6%81%E8%AE%A4%E8%AF%81
https://www.cnblogs.com/xiongmaomengnan/p/6671206.html
https://tsejx.github.io/blog/authentication/
https://www.ruanyifeng.com/blog/2018/07/json_web_token-tutorial.html
https://developer.aliyun.com/article/636281