基础入门-网站协议身份鉴权OAuth2安全Token令牌JWT值Authirization标头
知识点：
1、网站协议-http/https安全差异（抓包）
2、身份鉴权-HTTP头&OAuth2&JWT&Token
一、演示案例-网站协议-http&https-安全测试差异性
1、加密方式
HTTP：使用明文传输，数据在传输过程中可以被任何人截获和查看。
HTTPS：通过SSL/TLS协议对数据进行加密，确保数据在传输过程中不被第三方截获和篡改。
2、身份验证
HTTP：不需要进行身份验证，任何人都可以访问网站。
HTTPS：通过数字证书和SSL/TLS协议验证服务器的身份，防止"中间人攻击"。(ssl是早期的加密协议，现在主流都用TLS来加密，可以理解为SSL的升级版)
3、端口号
HTTP：默认使用80端口。
HTTPS：默认使用443端口，提供更高的安全性。
二、演示案例-身份鉴权-Authorization&Token&JWT&OAuth
1、身份验证鉴权技术
Cookie，Session，Token，JWT，oauth2等
参考：https://mp.weixin.qq.com/s/Z6rt_ggCA8dNVJPgELZ44w
2、应用场景
Cookie+Session简单，建议在内网使用；
Token相对完善，推荐在外网使用；
JWT推荐使用，常用在SSO单点登录中；
OAuth灵活方便，对于第三方系统登录联动更友好(有些系统或者APP应用会支持第三方登录，例如微信、微博账户登录等，这样的方式基本都用这个OAuth。)
3、OAuth2技术
授权框架，使网站和Web应用程序能够请求对另一个应用上的用户帐户进行有限访问。至关重要的是，OAuth允许用户授予此访问权限，而无需向请求应用程序公开其登录凭据。这意味着用户可以微调他们想要共享的数据，而不必将其帐户的完全控制权移交给第三方(A网站允许B网站的用户登录)
四种验证模式：
authorization_code 授权码模式(最常见)
implicit code 简单模式
password 密码模式
client_credentials 客户端模式
授权码模式流程
安全漏洞问题
1、redirect_url 校验不严格导致code被劫持到恶意网站（fuzz各种bypass方式）
2、client_id与redirect_url 不一致造成滥用劫持
3、A应用生成的code可以用在B应用上
4、state未设置csrf防护，导致csrf风险
5、scope提权，将低scope权限的code用于高权限场景
6、HTTP劫持，网络层中间人攻击
7、点击劫持：通过点击劫持，恶意网站会在以下位置加载目标网站： 透明 iFrame（参见 [ iFrame ]）覆盖在一组虚拟的顶部 精心构造的按钮直接放置在 目标站点上的重要按钮。当用户单击可见的 按钮，他们实际上是在单击一个按钮（例如“授权” 按钮）在隐藏页面上。
4、Authorization头
Authorization是HTTP 提供一个用于权限控制和认证的通用框架，可能有不少小伙伴会感到疑惑"Cookie不就可以做权限控制和认证吗？ "，确实如此！ Cookie确实是在单个系统内认证用户身份、保持会话状态的有效方式，但如果涉及到多个系统、多个域名或多个应用程序之间认证、授权呢？ 使用Cookie的话该如何办呢？是不是想想都头皮发麻呢？为解决这个问题， HTTP急需一种更通用、更灵活的身份验证和授权机制，使跨系统和跨域的身份验证和授权管理更容易，这对于现代应用程序中的多样化环境非常重要，就这样Authorization诞生了！
Authorization是一种通用的、标准化的权限控制和认证的通用框架，它能够使跨系统和跨域的身份验证和授权管理更容易，使不同应用程序之间能够更轻松地实现单点登录（SSO）、用户身份验证和授权控制等。
参考：https://juejin.cn/post/7300812626279251987
授权方案
1、Basic认证
2、Digest认证
3、Bearer认证
4、JWT认证
5、API密钥认证
6、双因素认证
7、其他一些认证方式
安全漏洞问题
JWT攻防，Token劫持等