Web 服务中的认证介绍，通过HTTP协议访问各种 web 应用，认证是必不可少的部分，本文介绍常见的Http Authentication、以及 Session 和 Cookie 的区别
常见的 HTTP 认证协议
参考 HTTP authentication
Basic Authentication
Basic Authentication是HTTP提供的一种验证方式，因为明文传输用户名和密码，非HTTPS环境下很不安全，一般用的非常少
HTTP Basic Auth使用两个HTTP Header实现，分别是WWW-Authenticate和Authorization。
流程如下：
- 客户端请求服务器页面，服务器返回
401以及WWW-Authenticate: Basic realm="site"。
- 浏览器弹出对话框，提示用户输入用户名和密码。
- 浏览器再次请求页面，携带
Authorization: Basic <str>，其中，str=base64(username:password)。
- 服务器返回正常页面。
说明：
base64只是一个编码过程（RFC 4648），而不是加密过程。因此，HTTP Basic Auth是在明文传输用户名和密码，中间设备很容易通过检查数据包获取用户名和密码。realm属性用来标注页面所属的域
Bearer Authentication
Bearer authentication (也称 token authentication) 是 HTTP authentication scheme 涉及到称为bearer tokens的安全令牌。Bearer authentication 可以理解为“授予对该令牌持有者的访问权”。bearer token是一个加密的字符串，通常由服务器响应登录请求生成。客户端向受保护资源发出请求时，必须在授权头中发送此令牌，格式为:
Authorization: Bearer <token>
Digest authentication
流程如下：
- 客户端发起 GET 请求，服务器响应
401 Unauthorized，WWW-Authenticate指定认证算法，realm 指定安全域
- 客户端重新发起请求，
Authorization指定用户名和密码信息
- 服务器认证成功，响应
200，可选Authentication-Info
不以明文发送密码，在上述第 1 步时服务器响应返回随机字符串nonce，而客户端发送响应摘要 =MD5(HA1:nonce:HA2)，其中HA1=MD5(username:realm:password),HA2=MD5(method:digestURI)
在HTTP摘要认证中使用MD5加密是为了达成不可逆的。
认证 vs 授权
认证（Authentication） 检查用户是否为合法用户，认证包括：
- JWT tokens
- TLS 认证，通过 X509 client certs 证书 Subject 添加：
- CN: user/serviceaccount
- O: group
- user/password
- Static Token File
- Static Password File
- Service Account Tokens
- OpenId Connect Tokens
- …
授权（Authorization） 判断该用户是否具有该操作的权限
ACL（Access Control List，访问控制列表） 定义谁可以对某个数据进行何种操作RBAC（Role-based Access Aontrol，基于角色的访问控制） 用户具有角色，角色具有权限，从而表达用户具有权限ABAC（Attribute-based Access Control，基于属性的访问控制） 权限和资源当时的状态（属性）有关，属性的值可以用于正向判断（符合某种条件则通过）
Session 介绍
session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
当程序需要为某个客户端的请求创建一个 session 时，服务器首先检查这个客户端的请求里是否已包含了一个 session 标识（称为 session id），如果已包含则说明以前已经为此客户端创建过 session，服务器就按照 session id 把这个 session 检索出来使用（检索不到，会新建一个），如果客户端请求不包含 session id，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 session id，session id 的值应该是一个既不会重复，又不容易被找到规律以仿造的字符串，这个 session id 将被在本次响应中返回给客户端保存。
保存这个 session id 的方式可以采用 cookie，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器。一般这个 cookie 的名字都是类似于 SEEESIONID。但 cookie 可以被人为的禁止，则必须有其他机制以便在 cookie 被禁止时仍然能够把 session id 传递回服务器。
经常被使用的一种技术叫做 URL 重写，就是把 session id 直接附加在 URL 路径的后面。还有一种技术叫做表单隐藏字段。就是服务器会自动修改表单，添加一个隐藏字段，以便在表单提交时能够把 session id 传递回服务器。
Cookie 介绍
Cookies 是服务器在本地机器上存储的小段文本并随每一个请求发送至同一个服务器。IETF RFC 2965 HTTP State Management Mechanism 是通用 cookie 规范。网络服务器用 HTTP 头向客户端发送 cookies，在客户终端，浏览器解析这些 cookies 并将它们保存为一个本地文件，它会自动将同一服务器的任何请求缚上这些 cookies 。
具体来说 cookie 机制采用的是在客户端保持状态的方案。它是在用户端的会话状态的存贮机制，他需要用户打开客户端的 cookie 支持。cookie 的作用就是为了解决 HTTP 协议无状态的缺陷所作的努力。
Cookie 的分两类：
- 会话级别 Cookie：在浏览器关闭之后 Cookie 失效
- 持久级别 Cookie：只要设置了过期时间就是硬盘级别 Cookie
Session 和 Cookie 区别
session 记录状态
- 存储在服务器端
- 一般由框架提供 API 操作，如 spring、beego
- 一般用户认证成功后，用来记录状态信息
- 通过
set-cookie 将 sessionid 存到 cookie 中
- session 有声明周期，若
sessionid 泄漏，攻击者可以伪造请求
cookie 状态跟踪，其中 sessionid 存储在 cookie 中
- 存储在浏览器端
- 通过 response 中的
set-cookie 设置
- 浏览器发请求到服务器时，自动携带 cookie 信息
- session 在服务器端，cookie 在客户端（浏览器）
- session 默认被存在在服务器的一个文件里，也可以放在 文件、数据库、或内存中
- session 的运行依赖 session id，而 session id 是存在 cookie 中的，也就是说，如果浏览器禁用了 cookie ，同时 session 也会失效，但是可以通过其它方式实现传递，比如在 url 中传递 session_id
- cookie 不是很安全，别人可以分析存放在本地的 COOKIE 并进行 COOKIE 欺骗，考虑到安全应当使用 session；session 会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能。考虑到减轻服务器性能方面，应当使用 COOKIE；单个 cookie 在客户端的限制是 3K，就是说一个站点在客户端存放的 COOKIE 不能超过 3K