很多人虽然“用过” JWT、Session、SSO、OAuth，但其实并没有真正理解它们的本质区别。

今天这篇文章，就带你梳理一下这 4 种前端常见的身份验证方式，不光要知道怎么用，还得知道他们背后的原理都有啥！

一、最老方案：Session

要说身份验证这事，Session 肯定是“资历最老”的了。几乎所有人刚入门做登录系统，第一个就是它。

那么它是怎么工作呢的？完整的流程，大致可以分为 6 步：

1. 用户输入账号密码，点登录；
2. 后端验证通过后，创建一条 Session 数据，生成唯一的 Session ID；
3. 后端通过 Set-Cookie 把这个 Session ID 发给浏览器；
4. 浏览器自动保存这个 Cookie；
5. 以后每次请求，这个 Cookie 自动带上，服务端就能识别出“哦，你是谁了”；
6. 用户退出登录？后端把这张纸条撕了，Session 就失效了。

简答来说就是： 用户登录后，服务端给你发个 “小纸条”（Session ID），你每次来都带着这张纸条，服务端一看，“哦，你是老李啊，进吧吧。”。

根据以上流程，我们就可以发现：使用 Session 时，对前端几乎 “无感知” 的，我们啥都不用操心：

• 浏览器自动帮我们带 Cookie；
• 登出只要后端把 Session 删了就行；
• 登录态是服务器说了算，能立刻失效，不留后患。

尤其在公司内网、传统后台项目中，香得很！

但是，为啥现在突然使用 Session 的就少了呢？

其实是因为前后端分离、微服务、移动端……这些场景对它实在不太友好。

• 服务端要维护 Session 状态，不利于扩展和分布式部署；
• Cookie 传输存在劫持风险，必须配合 HTTPS、安全配置一起上；
• 在配合上 微服务、微前端、跨域 就更加麻烦了

所以，在现代的复杂项目中，Session 就用的越来越少了。

二、用的最多的方案：JWT

讲真，现在要是你说没用过 JWT（Token），可能都不好意思说自己搞过前端分离。

但也正是这个“火”，让很多人以为它非常好用，从而忽略了它的一些问题，比如：文章最初上线第一天就挂了的同学

先说一下 JWT 的基础逻辑：

1. 用户登录，提交用户名密码；
2. 后端验证通过后，生成一个带有用户信息的 JWT（通常是用户 ID、权限、过期时间）；
3. 把这个 JWT 返回给前端；
4. 前端把它存到 localStorage 或者 cookie（自己看情况）；
5. 后续请求时，前端主动在 Authorization 头里带上这个 Token；
6. 后端收到请求后解析 Token，验证合法性，然后决定要不要放行。

简单来说，就是：用户登录成功后，服务端不再存啥“Session”，而是直接签发一个 Token 给前端，你拿着这个 Token 去访问接口，服务端每次验证这个 Token 来确认你是谁。

这个流程，大部分同学 应该熟悉，但是它的问题也很明显：

• token 可能会长期有效，在此期间一旦泄露就会很麻烦
• 无法让其主动失效，总不能维护一大堆黑名单吧

所以，JWT 确实不错，但是你需要做好对应的优化处理，比如：RefreshToken、黑名单 等等

三、只需要登录一次：SSO 单点登录

如果你做过企业项目、对接过公司统一认证，那你一定听过这个词：SSO（Single Sign-On）——单点登录

用户只需要登录一次，接下来访问一堆系统都不用重复登录了，一次认证，全网通行。

咱们先来看下它的流程：

1. 用户访问系统 A，系统发现你没登录，直接把你重定向到「登录中心」；
2. 登录中心让你输入账号密码；
3. 登录成功后，它发一个「身份令牌」；
4. 然后再把你重定向回系统 A，并带上令牌；
5. 系统 A 拿这个令牌去登录中心验证——你是谁、能不能进；
6. 验证通过，OK，放行；
7. 接下来你再去系统 B、C……他们也会让你先去登录中心“刷个脸”，但你已经登录过了，直接放行。

所以看上去你只登录了一次，实际背后是多个系统和登录中心在“套娃式”配合。

这样做的优势是很明显的：

• 一个账号打通多个系统，少了好多登录窗口
• 密码只输一次，不用记一堆
• 用户登出一个系统，也能一并下线，统一管理更安全

所以就特别适合：OA、CRM、邮件系统、知识库、审批流……这些系统分属不同部门，但是属于共一个公司的业务场景。

但是它的问题也是存在的，比如：

• 登录中心一挂，所有系统全完蛋
• 配置复杂，调试起来更复杂
• 跨系统数据同步、权限管理稍微麻烦一些

四、登录授权方案：OAuth 2.0

说起 OAuth 2.0，很多人第一反应是：“哦，那不就是微信扫码登录、GitHub 登录那些东西吗？”

说对了，但是没全对。

但如果你把 OAuth 理解成“用户登录协议”，那就大错特错了。OAuth 本质上不是登录协议，而是授权协议。

什么意思？

OAuth 的核心目标只有一个，那就是：让第三方应用“在不拿到你密码”的前提下，获得你的一部分资源访问权。

举个例子：

你用第三方网站（比如：石墨文档）绑定微信登录，授权它“获取你的微信头像和昵称”。

网站能拿到这些信息，但是 它永远不知道你的微信密码。这，就是 OAuth 的精髓：把权限，和账号密码分离。

整个 OAuth 的流程略复杂，大致分为 5 步：

1. 第三方应用（比如石墨）发起登录请求，把你重定向到微信；
2. 你在微信页面确认授权（允许它获取昵称、头像）；
3. 微信授权完后，发回一个“授权码”给石墨；
4. 石墨再拿这个码去微信那边换“访问令牌（Access Token）”；
5. 有了 Token，就可以去微信获取你的信息了。

目前有很多系统，拿 OAuth 来做“登录认证”，但是遇到的坑也很多，比如：

• 没搞清楚用户信息怎么拿；
• Token 过期机制处理不好；
• 把 AccessToken 存 localStorage，结果被偷走直接暴露资源；

特别是你自己在搞“扫码登录”这一套，想用 OAuth 模仿微信，没搞明白授权码和 Token 的生命周期，那系统大概率会挂。