先赞后看，Java进阶一大半

各位hao，我是南哥。

记得前几天南哥在牛客看到一条面试题：工作的鉴权怎么做的，了解常用的鉴权方案吗？

不得不说，哪怕进入一家小型的互联网公司，他们的鉴权方案这类基础建设早已搭建好，在工作中用到的更多是前人搭建好的方案。遇到这道题，如果自己没去提前了解，回答起来容易太浅显。

⭐⭐⭐一份南哥编写的《Java学习/进阶/面试指南》：https://github/JavaSouth

1. N种鉴权方案

1.1 账号密码鉴权

最简单、最古老的鉴权方式，大家都知道是账号密码鉴权。最简单也最容易破解，用户不可能记住为每个网站设置的密码，所以他们更常把一个共用的密码设置为多个网站的密码。可怕的是某个网站的密码泄露，相当于所有网站的密码泄露。

NordPass在这个月发布了 2024 年最糟糕密码榜单，你中招了吗？？

1.2 HTTP鉴权

HTTP鉴权顾名思义是基于HTTP协议进行的认证鉴权，HTTP协议怎么鉴权？加密信息放在哪？

这种鉴权方式属于早期的鉴权方式，所以安全性实际上不高，它是通过HTTP请求头传递认证信息，把账号密码使用Base64编码后放在请求头，属于明文传输！

简单说下鉴权过程，各位也可以参考以下developer.mozilla.org站点提供的流程图。

1. 浏览器：我需要请求这个信息，服务器你给我返回过来
2. 服务器：这个信息要认证的，把账号密码发来
3. 浏览器：我让用户输入账号密码

如果服务器认证成功这个通过请求头传输过来的账号密码，则会返回所需的数据信息。

当然！HTTP鉴权也可以提高安全性，把HTTP协议升级为HTTPs协议。

由于HTTPS协议使用SSL/TLS协议对传输数据进行加密，可以确保数据在传输时是不可读的。大家可以回顾南哥刚刚讲的，HTTP鉴权使用Base64编码来加工账号密码，这种方式可以说算不上加密，Base64编码要解码出来是分分钟的事。

1.3 Cookie-Session鉴权

Cookie来源于服务器，存储在浏览器，在某个网址上设置Cookie也很简单。

# 设置Cookie
Set-Cookie: <cookie-name>=<cookie-value>

但！很多人可能会误会：Session是不同于Cookie的另一种数据。并不是，Session本质上也是Cookie，我称它为包含会话ID的Cookie。

通过Session-Cookie鉴权的步骤如下，整体流程还是和HTTP鉴权差不多，大家不用想得那么复杂。

1. 用户在浏览器将用户凭证发送到服务器，这个用户凭证可以是通过表单提交的账号密码
2. 服务器认证通过后，会在服务器内部存储一个包含有效期的会话ID，同时把该会话ID包装成Cookie发送给浏览器
3. 浏览器存储该Session，同时每次请求网站都会携带该Session
4. 如果服务器能成功匹配到发来的Session会话ID，则表示认证成功

当然！使用Cookie-Session鉴权也有一个痛点：跨越使用起来麻烦！下面南哥会说说哪一种鉴权没有跨越的烦恼。

Cooke的发送是由浏览器自动管理，浏览器和服务器又规定了一系列对Cookie的发送的限制，使得Cookie在跨越使用起来非常麻烦。

1. SameSite 属性：默认限制跨站点发送。
2. Domain 和 Path：绑定到特定域名和路径。
3. Secure 和 HttpOnly：受协议和客户端行为影响。

1.4 Token鉴权

Token鉴权和上文两种鉴权方式一样，都是在请求头里携带验证信息，同时在服务器上进行验证。

但Token鉴权有其特殊之处，这也是它相对传统鉴权方法的好处。

（1）上文南哥有提到Cookie-Session鉴权跨越使用起来麻烦，Token就没跨越的麻烦，没错简简单单没烦恼。Token鉴权是前端开发人员显式地把Token添加到请求头，甚至也可以把Token放在请求行，没有了浏览器制定的Cookie一系列限制。

（2）令牌是无状态的，服务器不需要像Cookie-Session鉴权一样维护会话状态，服务器只需要验证Token的真实性即可。

（3）Token验证非常适合目前的分布式系统，分布式系统的各个节点要维护同一套会话状态一直是一个痛点，Token验证完全没有这个事。

一般分布式系统有会一台专门生成Token令牌和存储Token令牌的服务器，也有一台专门验证Token有效性的服务器。另外Token鉴权没有固定的格式，Token存储的信息一般有：用户唯一标识符 + 时间戳 + 权限信息。

1.5 JWT鉴权

JWT全称叫JSON Web Token，又是Token？和Token有什么区别？

JWT实际上是一种标准，表示以JSON对象格式存储的一种Token。大家注意一点，JWT一定是Token，但Token不一定是JWT。

JWT也不需要像前面的Token鉴权一样需要有专门的Token验证服务器，在任何服务器节点只需要共享JWT的密钥secret就可以解码JWT，下面会介绍到密钥secret。

JWT由三部分组成：Header标头、Payload载荷、Signature签名，前面两部分都会由Base64编码进行加工。

（1）Header

标头由Token的类型和使用的签名算法组成，比如下面这种HMAC SHA256签名算法，标头的作用就是标识加密算法的类型。

{
  "alg": "HS256", // HMAC SHA256签名算法
  "typ": "JWT"
}

（2）Payload

载荷主要包含用户信息，前端和后端可以通过载荷拿到个人信息。

{
  "sub": "666666",
  "name": "JavaSouth南哥",
  "admin": true
}

（3）Signature

签名通过以下的加密方式生成，其中的密钥secret只有客户端、服务端知道，用来保证数据在传输过程中没有被篡改。

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

大家应该有用过这个https://jwt.io/网站，我们可以在上面解码、验证、生成JWT，特别是解码后拿到JWT里面的用户信息。

1.6 单点登录（SSO）

看起来很高级的鉴权名词，我给大家一张图，相信大家肯定都有用过单点登录。

我们在谷歌浏览器登录后，第一次访问谷歌邮箱、谷歌地图等，都能使用前面谷歌浏览器的登录状态一键登录其他平台，减少了重复的登录操作。

关于单点登录大家可以查阅auth0.com论坛，讲的很清楚完善。

1.7 OAuth 2.0鉴权

OAuth 2.0是一种业界标准的授权协议，设计的初衷也很简单：偷懒。哦不，是简化。OAuth 2.0可以简化客户端开发的工作，包括Web 程序、桌面应用、App、小程序都可以用到OAuth 2.0授权。

我们在手机下载一个新的App，使用微信第三方授权，这种模式其实就是OAuth 2.0授权。

OAuth 2.0站点可以说是对OAuth 2.0授权介绍得最完善、最全面的地方。

1.8 扫码登录

二维码在英文里其实被称为QR码，全称是Quick Response Code，最早由日本公司 Denso Wave 于 1994 年发明的。

一句话概括扫码登录，二维码里包含了一个会话标识信息，用户扫码后将会话标识 + 用户授权信息发送给服务器验证，服务器验证通过则表示登录成功。

我是南哥，南就南在Get到你的点赞点赞点赞。

看了就赞，Java进阶一大半。点赞 | 收藏 | 关注，各位的支持就是我创作的最大动力❤️