73人参与 • 2026-10-09 • 其他编程
之所以有这么多概念,是因为出来了新场景。浏览器带来了cookie和session,如果没有app,cookie就够用了…
来来来,今天我们就一直梳理下这些高频出现的名词
从浏览器便签条到企业级单点登录,完整的认证体系讲解
想象你去一家餐厅吃饭:

定义:浏览器存储的小文件,自动随每个请求发送给服务器。
工作流程:
用户登录 → 服务器返回 set-cookie → 浏览器保存下次请求 → 浏览器自动发送 cookie → 服务器识别用户
特点:
安全属性:
set-cookie: sessionid=abc123 ; httponly # 禁止 javascript 访问 ; secure # 仅 https 传输 ; samesite=strict # 防止 csrf ; max-age=3600 # 1 小时后过期
代码示例:
// 服务器设置 cookieresponse.addcookie(new cookie(“sessionid”, “abc123”)); // 浏览器自动发送get /api/user http/1.1cookie: sessionid=abc123
定义:服务器端存储的用户信息,通过 cookie 中的 sessionid 关联。sessionid是cookie中的一个属性。cookie中存的东西可不只一个哦。
工作流程:
用户登录 → 服务器创建 session → 返回 sessionid(cookie)下次请求 → 浏览器发送 sessionid → 服务器查询 session → 识别用户
特点:
分布式 session 问题:
用户登录 → 服务器 a 创建 session
下次请求 → 负载均衡器转到服务器 b
问题:服务器 b 没有这个 session!
解决方案:
代码示例:
// 服务器创建 session
httpsession session = request.getsession();
session.setattribute(“userid”, 123);
session.setmaxinactiveinterval(3600); // 1 小时
// 下次请求获取 session
httpsession session = request.getsession(false);
if (session != null) {
integer userid = (integer) session.getattribute(“userid”);
}定义:服务器颁发的令牌,用户在请求中携带,服务器验证其有效性。
工作流程:
用户登录 → 服务器生成 token → 返回给客户端下次请求 → 客户端在 header 中发送 token → 服务器验证 token
特点:

代码示例:
// 生成 token
string token = generatetoken(userid);
response.setheader("authorization", "bearer " + token);
// 验证 token
string token = request.getheader("authorization").replace("bearer ", "");
if (validatetoken(token)) {
// token 有效
}结构:header.payload.signature
eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9 .eyjzdwiioiixmjm0nty3odkwiiwibmftzsi6ikpvag4grg9liiwiawf0ijoxnte2mjm5mdiyfq .sflkxwrjsmekkf2qt4fwpmejf36pok6yjv_adqssw5c
三部分解析:
header(头部):
{
“alg”: “hs256”, # 签名算法
“typ”: “jwt” # 令牌类型
}payload(载荷):
{
“sub”: “1234567890”, # 用户 id
“name”: “john doe”, # 用户名
“iat”: 1516239022, # 签发时间
“exp”: 1516242622 # 过期时间
}signature(签名):
hmacsha256( base64urlencode(header) + “.” + base64urlencode(payload), secret )
优点:
缺点:
刷新机制:
颁发两个 token:
access token 过期后:
代码示例:
post /api/token/refresh
{
"refreshtoken": "xxx"
}
返回:
{
"accesstoken": "yyy",
"expiresin": 900
}定义:一种授权框架,允许用户授权第三方应用访问其资源。
核心概念:
资源所有者(用户)
↓
授权服务器(微信、google)
↓
第三方应用(你的网站)
↓
资源服务器(微信、google 的 api)
四种授权方式:
1️⃣ 授权码流程(最常用)
用户点击"微信登录"
↓
跳转到微信授权页面
↓
用户同意授权
↓
微信返回授权码(code)
↓
后端用 code 换取 access_token
↓
用 access_token 获取用户信息
↓
登录成功
2️⃣ 隐式流程(已废弃)
直接返回 access_token(不安全)
3️⃣ 密码流程(内部系统)
用户输入用户名密码
↓
直接返回 access_token
↓
(仅用于内部系统,不推荐)
4️⃣ 客户端凭证流程(服务间通信)
服务 a 用 client_id + client_secret
↓
获取 access_token
↓
调用服务 b 的 api
代码示例:
// 1. 获取授权码
string authurl = "https://open.weixin.qq.com/connect/oauth2/authorize?" +
"appid=" + appid +
"&redirect_uri=" + redirect_uri +
"&response_type=code" +
"&scope=snsapi_userinfo";
// 2. 用授权码换取 access_token
string tokenurl = "https://api.weixin.qq.com/sns/oauth2/access_token?" +
"appid=" + appid +
"&secret=" + secret +
"&code=" + code +
"&grant_type=authorization_code";
// 3. 用 access_token 获取用户信息
string userurl = "https://api.weixin.qq.com/sns/userinfo?" +
"access_token=" + accesstoken +
"&openid=" + openid;定义:用户只需登录一次,就能访问多个相关系统。一次登录,处处访问。
sso,是一个期望达到的业务目标,落地的方案 各个项目、各个技术栈也不全相同。
工作流程:
用户访问系统 a
↓
重定向到 sso 服务器
↓
用户登录
↓
sso 服务器返回 token
↓
用户访问系统 b
↓
系统 b 验证 token(无需重新登录)
与 oauth2.0 的区别:

实现方式:
基于 cookie:
基于 token:
基于 saml:
代码示例:
// sso 服务器:生成 token
string ssotoken = generatessotoken(userid);
response.addcookie(new cookie("sso_token", ssotoken));
// 系统 a:验证 token
string ssotoken = request.getcookie("sso_token");
if (validatessotoken(ssotoken)) {
// 自动登录
}
// 系统 b:验证 token
string ssotoken = request.getcookie("sso_token");
if (validatessotoken(ssotoken)) {
// 自动登录
}
核心功能:
快速开始:
<!-- pom.xml -->
<dependency>
<groupid>cn.dev33</groupid>
<artifactid>sa-token-spring-boot-starter</artifactid>
<version>1.37.0</version>
</dependency>
// 登录
stputil.login(userid);
// 检查登录
stputil.checklogin();
// 获取当前用户
long userid = stputil.getloginid();
// 登出
stputil.logout();
// 权限检查
stputil.checkpermission("user:add");
// 角色检查
stputil.checkrole("admin");安全建议
性能优化
常见坑
高频面试题
q1: cookie 和 session 的区别?
标准答案:
存储位置:
安全性:
性能:
分布式:
大小限制:
q2: jwt 的优缺点?
标准答案:
优点:
✅ 无状态(服务器不需要存储)
✅ 支持分布式
✅ 跨域友好
✅ 移动端友好
缺点:
❌ token大(包含所有信息)
❌ 无法主动撤销
❌ 泄露后无法立即失效
❌ 需要刷新机制
q3: oauth2.0 有几种授权方式?
标准答案:
4 种:
q4: sso 和 oauth2.0 的区别?
标准答案:
sso(单点登录,一套技术方案):
oauth2.0(授权框架):
q5: 如何选择认证方案?
标准答案:

spring security
spring 生态官方安全框架,企业级标准。
核心:认证 + 授权 + 全栈安全防护(防 csrf、xss、会话固定、点击劫持等)。
设计哲学:安全第一、高度可扩展、工业级健壮。
sa-token
国人开源(dromara 社区),轻量级权限认证框架。
核心:登录认证 + 权限认证 + 会话管理 + sso/oauth2。
设计哲学:简单粗暴、一行代码搞定、少配置、低侵入。
一句话:
spring security = 全能重型装甲车
sa-token = 轻便摩托车,好骑省油
到此这篇关于一文讲清cookie、session、token、oauth2.0、sso、jwt的文章就介绍到这了,更多相关cookie、session、token、oauth2.0、sso、jwt内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
您想发表意见!!点此发布评论
版权声明:本文内容由互联网用户贡献,该文观点仅代表作者本人。本站仅提供信息存储服务,不拥有所有权,不承担相关法律责任。 如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 2386932994@qq.com 举报,一经查实将立刻删除。
发表评论