鉴权(Authentication)
是一个在计算机和信息安全领域中用来验证用户或系统身份的过程。其目的是确保系统中的资源（如数据、应用程序和网络服务）仅被授权用户或系统访问和操作。鉴权通常在用户试图访问系统资源时进行，以确认其身份和权限。
常见鉴权方案及细节阐述
HTTP Basic Authentication
概述
HTTP 提供一个用于权限控制和认证的通用框架。最常用的 HTTP 认证方案是 HTTP Basic authentication。服务器可以用来针对客户端的请求发 送 challenge（质询信息），客户端则可以用来提供身份验证凭证
鉴权流程
- 客户端向服务端发起请求
- 服务端接收到客户端的请求后，进行身份凭证验证，向客户端返回 401（Unauthorized，未被授权的）状态码，并在 WWW-Authenticate 首部提供如何进行验证的信息
- 客户端会弹出一个密码框让用户填写
- 客户端在新的请求中添加 Authorization 首部字段进行验证，字段值为身份验证凭证信息。
凭证生成以及安全性
“Basic” HTTP 验证方案是在 RFC 7617中规定的，在该方案中，使用用户的 ID/密码作为凭证信息，并且使用 base64 算法进行编码。由于ID与密码都是以明文形式，易导致泄露，安全性较差
Cookie-Session
概述
Cookie ：存储在客户端（用户的浏览器）中的一小段数据。通常是需要记忆的一段信息，如某人的购物车等。会在浏览器对同一服务器再次发起请求时被携带送到服务器上。
Session : 存储在服务器端的一段数据，用户访问时会有一个唯一的session ID与之对应。代表的是一次会话，其内容通常为需要在整个用户会话过程中保持其状态的信息，如用户的登录信息.
鉴权流程
- 客户端发起HTTP请求
- 服务端接收请求，若无鉴权则返回401状态码
- 提示用户输入账号和密码
- 客户端发起登陆验证
- 服务端进行身份校验，首次访问时，若正确则创建一个 session 并将 session 保存到服务器中，而后将 session 唯一标识 session ID 与其他特定数据返回到客户端
- 客户端接收请求时，将 cookie 解析储存，在后续客户端发送HTTP请求的时候，会在 header 中携带 cookie 进行访问
- 服务器接收请求时，在 cookie 中寻找 session ID 从而再服务器中寻找相对应的 session 对话，从而验证相用户会话
- 当用户退出或者 session 超时时，服务端会将 session 对话失效处理，下次访问时则需要重新认证和创建对话
凭证生成与安全性
根据需求制定过期时间、域、路径、有效期、适用站点等信息生成cookie，其属性过多，暂且不论。就安全性而言，本地cookie容易被窃取，攻击者可以利用本地 Cookie 进行欺骗和 CSRF 攻击。当机器处于不安全环境时，切记不能通过 HTTP Cookie 存储、传输敏感信息。
JWT(Json Web Token)
概述
为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准（(RFC 7519)。该 token 被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该 token 也可直接被用于认证，也可被加密。
鉴权流程
- 客户端发起HTTP请求
- 服务器接收请求，若无鉴权则返回401状态码
- 提示用户输入帐号以及密码
- 客户端发起登录验证
- 服务端验证信息，若正确则将客户信息部分作为 payload 生成 JWT 并向客户端发送有效 JWT 令牌
- 客户端接收到成功信号时，将接收到的 JWT 存储到某一位置
- 后续HTTP请求中都会携带 Token 令牌，服务端验证 Token 值并据此返回相应资源
凭证生成与安全性
JWT是由Header、Payload和Signature等三部分组成，他们之间通过.连接起来，例如：header.payload.signature
- header：一个Json对象，定义了JWT元数据
- payload: 一个Json对象，定义了需要传输的一些数据
- Signature： 对 Header 和 Payload 部分进行签名，防止数据篡改。一般根据 header 中指定的算法产生签名
安全性：JWT 默认是不加密的，遭到泄露时，任何人都可以获得该令牌的所有权限。JWT 的有效期应该设置得比较短。对于重要权限，使用时应该再次对用户进行认证。同时采用HTTPS协议进行传输
OAuth2
概述
用于授权第三方应用访问用户的资源，比如用户的照片、个人信息等。他定义了四种授权模式：
- 授权码模式 ：最为复杂，但也是安全系数最高的，比较常用的一种方式。适用于兼具前后端的Web项目
- 隐式授权模式： 主要为纯前端应用服务，令牌的申请与存储都需要在前端完成，跳过了授权码这一步。
- 密码模式： 直接拿用户的账号和密码作为信息申请授权令牌，安全系数极低，容易造成信息泄露，仅在客户端为高度信任应用时采用该模式
- 客户端凭证模式 ：Server-to-Server通信，不涉及用户，客户端使用自己的ID与密钥向授权服务器申请访问令牌。
鉴权流程
不同的授权模式间鉴权流程有均有分别，但大致遵循一下流程进行鉴权
- 用户 User 访问客户端，客户端 Clinet 向用户请求授权
- 用户输入授权信息（如账号密码），经服务器验证后返回到客户端
- 客户端带着授权许可访问授权服务器 Authorization Server，授权服务器验证授权许可后返回客户端许可令牌 Access Token
- 客户端携带 Token 访问资源服务器，资源服务器经验证后返回可被访问的受保护资源
（ps：流程如图）
凭证生成与安全性
对于不同授权模式下的token的组成部分各有千秋，且均包含以下属性
- clientId：客户端ID，当前token隶属的客户端
- userId：用户的ID，表示当前token来自哪个用户授权
- scope: 权限范围，该token允许换取的用户受保护资源范围
- issueTime：下发时间，用于控制token的生命周期
- tokenType：token的类型，不同类型可能会采用不同的验证措施
安全性： 既保证了第三方应用即客户端获取了授权权限，又同时保证安全可控，不会危害系统本身。