认证 · XB 现场笔记

OAuth 授权码用码换令牌

Wed, 20 Oct 2027 00:00:00 +0000

授权码流程把访问令牌的交付移到令牌端点，而不是在面向浏览器的授权重定向里直接返回访问令牌。这能减少令牌暴露在地址中的机会，却不代表浏览器绝不可能持有令牌。究竟由谁兑换授权码，以及结果保存在哪里，取决于客户端架构。审阅时应区分协议步骤、客户端类型和实际存储位置，不能把一种部署方式当成整个流程的定义。

公共客户端也能使用授权码流程

机密 Web 后端可以向令牌端点进行客户端认证，并把令牌保存在服务端。浏览器随后使用应用自己的会话，但会话安全仍需单独处理。原生应用和浏览器应用等公共客户端无法可靠地保守分发出去的客户端秘密，然而它们仍然可以使用授权码加 PKCE。因此，授权码流程并不是只有后端才能采用的方案。

若浏览器应用自行兑换，JavaScript 就会收到令牌响应。流程避免了在授权跳转地址里交付访问令牌，却不会消除脚本被入侵或令牌存储泄露的问题。后端架构改变了边界，并没有让所有浏览器侧风险消失。OAuth 解决委托访问；需要确认用户身份的应用，应采用 OpenID Connect 等适合的身份协议，并验证其中独立的身份凭据，不能把任意访问令牌直接当作登录证明。

把兑换绑定到原始请求

PKCE 为每次事务生成高熵校验串。授权请求携带它的 S256 挑战，令牌请求再提供原校验串，授权服务器检查二者是否对应。校验串不是固定的客户端口令，必须与发起它的事务关联。这样，只有截获授权码、却没有校验串的一方，不应能够完成兑换。日志和错误报告也不应同时泄露这两部分。

RFC 9700 要求公共客户端使用 PKCE，并建议机密客户端也使用。应选择 S256，避免降级成 plain。机密客户端仍需执行已配置的客户端认证，PKCE 不能代替这一职责。客户端认证也不一定意味着发送共享秘密；部署可以采用非对称认证机制。判断安全性时，要核对服务端实际执行的验证，而不是只看请求里出现了几个参数。

每枚授权码都应绑定客户端与回调地址，设置短有效期并限制只能使用一次。登记的回调地址通常必须精确匹配；原生应用的回环地址端口存在标准规定的例外。授权请求携带 redirect_uri 时，令牌请求中的值必须一致。在授权阶段就要拒绝未登记的回调，而不是等到授权码已泄露之后才靠兑换失败补救。

坏掉的样子

一次性并不能阻止攻击者抢先兑换一枚没有充分保护的授权码。过期只是缩短机会，不会让截获变得无害。回调中的授权码仍可能出现在访问日志、浏览器历史、来源信息和崩溃报告里。避免记录这些值，使用合适的 HTTPS 回调；开发原生客户端时，则按照原生回环重定向的专门规则处理，不要把例外扩展到任意明文回调。

客户端必须防止回调 CSRF 与授权码注入。事务状态应安全绑定发起请求的浏览器会话，并根据协议与提供方保证，正确组合 state、PKCE 或 OpenID Connect 的相应保护。随机 state 如果没有会话绑定，仍然不足。支持多个授权服务器时，还需防止签发者混淆；兑换成功本身，不能证明响应一定来自原本预期的身份提供方。

刷新令牌有独立的生命周期。对于公共客户端，安全最佳实践要求使用发送者约束，或者采用刷新令牌轮换。带重用检测的轮换是一种方案，并不意味着每枚没有变化的刷新令牌都无限有效。过期、撤销、不活跃时间限制和客户端绑定，共同决定真实的泄露窗口。不能只凭令牌字符串是否变化，就宣布整个刷新流程安全或失守。

快速验证

保存为 oauth_code_demo.py，执行 python3 oauth_code_demo.py。模型完全离线且单线程运行，使用合成客户端、明确登记的回调、每次新生成的随机授权码以及注入的时间。辅助函数接收校验串是为了在本地计算挑战；真正的授权请求只能发送挑战，不能把校验串一起送出去。程序不读取用户账号，也不调用任何身份提供方。

import base64
import hashlib
import hmac
import re
import secrets

REGISTERED = {'demo-client': 'https://app.example.test/callback'}
CODES = {}
NOW = 1_800_000_000


def challenge(verifier):
 if not re.fullmatch(r'[A-Za-z0-9._~-]{43,128}', verifier):
 raise ValueError('invalid verifier syntax')
 return base64.urlsafe_b64encode(hashlib.sha256(verifier.encode('ascii')).digest()).rstrip(b'=').decode()


def authorize(client, redirect, verifier, now):
 if REGISTERED.get(client) != redirect:
 raise ValueError('unregistered redirect')
 code = secrets.token_urlsafe(32)
 CODES[code] = {'client': client, 'redirect': redirect, 'challenge': challenge(verifier),
 'expires': now + 60, 'used': False}
 return code


def exchange(code, client, redirect, verifier, now):
 entry = CODES.get(code)
 if entry is None:
 raise ValueError('unknown code')
 if entry['used']:
 raise ValueError('code already used')
 if now >= entry['expires']:
 raise ValueError('code expired')
 if client != entry['client'] or redirect != entry['redirect']:
 raise ValueError('client or redirect mismatch')
 if not hmac.compare_digest(challenge(verifier), entry['challenge']):
 raise ValueError('PKCE verifier mismatch')
 # Atomic only because this demonstration runs sequentially in one thread.
 entry['used'] = True
 return 'DEMO-' + secrets.token_urlsafe(32)


def rejected(label, operation):
 try:
 operation()
 except ValueError:
 print('rejected:', label)
 return
 raise RuntimeError('unexpected acceptance: ' + label)


client = 'demo-client'
redirect = REGISTERED[client]
verifier = secrets.token_urlsafe(32)
code = authorize(client, redirect, verifier, NOW)
rejected('wrong client', lambda: exchange(code, 'other-client', redirect, verifier, NOW))
rejected('wrong redirect', lambda: exchange(code, client, redirect + '/extra', verifier, NOW))
rejected('wrong verifier', lambda: exchange(code, client, redirect, 'x' * 43, NOW))
if not exchange(code, client, redirect, verifier, NOW).startswith('DEMO-'):
 raise RuntimeError('valid exchange failed')
rejected('replay', lambda: exchange(code, client, redirect, verifier, NOW))
stale = authorize(client, redirect, verifier, NOW)
rejected('exact expiry', lambda: exchange(stale, client, redirect, verifier, NOW + 60))
rejected('unregistered callback', lambda: authorize(client, 'https://other.example.test/', verifier, NOW))
print('PASS: bound code accepted once; six negative cases rejected')

预期打印六条拒绝结果和 PASS。正确兑换只成功一次。错误客户端、改变后的回调和错误校验串在消耗授权码之前失败；成功之后再次兑换则被拒绝。另一枚码恰好在到期时失败，未登记回调在签发前就被拒绝。代码和令牌既不打印，也不传输，所有状态仅在这次实验的内存中存在。

模型刻意比真实授权服务器简单。顺序执行的检查和标记操作没有测试并发；生产存储必须原子地消费授权码。示例还省略了 HTTP 处理、用户授权、客户端认证、浏览器会话绑定、签发者检查及刷新令牌处理。可把这些用例转成隔离配置中的集成测试要求，但通过内存实验不等于已经验证完整登录旅程，也不意味着可以直接部署这段代码。

来源

RFC 6749: OAuth 2.0，授权码绑定与令牌兑换，已核验 2026-10-15。
RFC 7636: PKCE，校验串语法与 S256 挑战，已核验 2026-10-15。
RFC 9700: OAuth 2.0 Security Best Current Practice，公共客户端、重定向、CSRF 与刷新令牌保护，已核验 2026-10-15。
RFC 8252: OAuth 2.0 for Native Apps，公共原生客户端与回环重定向，已核验 2026-10-15。

Basic Auth 携带的是可重复使用的凭据

Thu, 11 Feb 2027 00:00:00 +0000

HTTP Basic 认证把编码后的用户名与密码放进 Authorization 请求头。由于编码可逆，取得该请求头的值，往往就相当于取得凭据本身。Basic 确实定义了认证挑战与响应流程，但不会用密码学方式把响应绑定到服务器刚生成的一次性随机数。只要服务器继续接受这个账号和凭据，一份曾被接受的值就可能被再次使用。不能把“存在挑战流程”误解成“重放一定失败”。

看清真正发生的交换

服务器可以返回四零一，并通过 WWW-Authenticate: Basic 挑战声明 realm，客户端再带 Authorization 重试。客户端也可以在合适的保护空间内提前发送凭据。因此，带认证的请求会携带凭据，不意味着每个最初请求一开始就必须有它。realm 用于标识保护空间，并不会自动授予同名路径上的所有权限，更不能替代具体的资源访问控制。

编码输入由用户标识、一个冒号和密码拼接。第一个冒号是分隔符，所以用户名不能包含冒号，密码则可以包含后续冒号。用户名和密码都不能包含控制字符；允许密码里出现冒号，并不意味着它可以包含任意字符。Base64 既不是加密，也不是密码哈希。涉及非 ASCII 凭据时还要考虑字符编码：RFC 7617 在兼容 ASCII 的条件下没有统一默认编码，并允许服务器挑战指明 UTF-8。仅验证一个 ASCII 示例，不等于已经覆盖所有国际化账号的编码与比较路径。

Basic 本身不定义会话令牌或通用退出登录协议。应用仍可以设置账号到期、禁用账号、改变授权或拒绝旧密码。因此，轮换密码并不是阻止泄露请求头继续生效的唯一办法。凭据的有效期与撤销方式，应依据服务器真实的账号策略定义，不能期待网络传输格式自动提供完整账号生命周期管理。客户端停止发送，与服务器已经拒绝旧值，也是不同事实。

坏掉的样子

在没有保护的网络链路上，能够读取请求头的人可以解码并再次使用。正确校验证书的 HTTPS 保护的是到 TLS 终点的传输，不会让终点本身、合法终止 TLS 的代理或疏忽的应用日志看不到凭据。还需要保护后续链路，并避免在日常追踪、报告和共享诊断文件中记录 Authorization 的真实值。传输加密不能替代服务端对凭据的妥善处理。

权限过大的凭据会扩大泄露后果。账号应匹配具体任务及其生命周期，身份验证之后仍要执行授权。凭据有效，不等于每个操作都允许；realm 标签也不是租户隔离机制。客户端需要限制凭据发送位置，尤其关注重定向和脚本复用全局请求头的情况。把同一个认证头传给无关目的地址，超出了原来的保护空间，也破坏了凭据使用边界。

重复的四零一可能来自凭据缺失、错误、到期或服务端不支持相应方式。在下面例子中，四零三表示已经识别的演示账号缺少目标权限，但不能据此认为所有服务返回四零三都证明认证已成功。应结合服务契约及响应中的认证挑战检查，不能仅凭一个数字推断完整的身份状态。认证结果和业务许可，应分别提供能够判断的证据。

快速验证

保存为 basic-auth.py，执行 python3 basic-auth.py。所有凭据都是刻意编造的演示值：用户名为 DEMO，密码为 NOT:A:SECRET。服务器只绑定回环地址，用明文 HTTP 展示协议机制；不要把这些值替换成真实凭据。实验没有测试 TLS、持久账号存储或生产认证服务，也不会读取当前环境的登录信息。

from base64 import b64decode, b64encode
from http.client import HTTPConnection
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
from threading import Thread
import hmac
import json

synthetic = b'DEMO:NOT:A:SECRET'
authorization = 'Basic ' + b64encode(synthetic).decode('ascii')


class Handler(BaseHTTPRequestHandler):
 def do_GET(self):
 accepted = hmac.compare_digest(self.headers.get('Authorization', '').encode('latin1'),
 authorization.encode('ascii'))
 status = 401 if not accepted else 403 if self.path == '/admin' else 200
 data = {401: b'credentials required\n', 403: b'permission denied\n', 200: b'allowed\n'}[status]
 self.send_response(status)
 if status == 401:
 self.send_header('WWW-Authenticate', 'Basic realm="local-demo", charset="UTF-8"')
 self.send_header('Cache-Control', 'no-store')
 self.send_header('Content-Length', str(len(data)))
 self.end_headers()
 self.wfile.write(data)

 def log_message(self, *args):
 pass


server = ThreadingHTTPServer(('127.0.0.1', 0), Handler)
thread = Thread(target=server.serve_forever)
thread.start()
try:
 observed = []
 for path, credential in [('/', None), ('/', authorization), ('/', authorization),
 ('/admin', authorization), ('/', 'Basic invalid')]:
 connection = HTTPConnection('127.0.0.1', server.server_port, timeout=5)
 try:
 connection.request('GET', path, headers={'Authorization': credential} if credential else {})
 response = connection.getresponse()
 observed.append({'status': response.status,
 'challenge': response.getheader('WWW-Authenticate'),
 'body': response.read().decode()})
 finally:
 connection.close()
 assert [r['status'] for r in observed] == [401, 200, 200, 403, 401]
 assert observed[0]['challenge'] == 'Basic realm="local-demo", charset="UTF-8"'
 user, password = b64decode(authorization.split()[1], validate=True).split(b':', 1)
 assert user == b'DEMO' and password == b'NOT:A:SECRET'
 print(json.dumps({'responses': observed, 'synthetic_decoded_user': user.decode(),
 'synthetic_decoded_password': password.decode(), 'replay_accepted': True}))
finally:
 server.shutdown()
 thread.join()
 server.server_close()

第一次请求得到四零一和 Basic 挑战。随后使用完全相同的编码值发送两次请求，都得到二百，说明凭据继续有效时重放可以被接受。演示账号访问 /admin 得到四零三，无效认证头则再次得到四零一。服务端关闭了常规请求日志，不会记录这些请求头；输出只展示事先明确说明的合成值与相应结果。

最终断言对合成凭据解码，并只在第一个冒号处分割，后面的冒号都属于密码。这验证了可逆编码、挑战发送、重复接受以及独立的权限判断。处理器只识别一个固定演示值，不是完整认证系统。生产审阅仍需把凭据存储、请求节流、撤销、传输与授权放在一起检查，不能将这个局部示例当作已经具备全部账号安全能力的实现。

来源

RFC 7617: Basic authentication，认证挑战、编码、凭据重用与保护空间，已核验 2026-09-13。
MDN: HTTP authentication，认证请求头及传输层注意事项，已核验 2026-09-13。

Cookie 与会话守住边界

Tue, 12 Jan 2027 00:00:00 +0000

Cookie 是浏览器的存储与传输机制。服务端会话则是一种应用设计，用 Cookie 的值查找服务器保存的状态。分开这两种责任，登录、过期和退出才容易验证。本文沿着不透明会话标识的生命周期展开，不再重复主机、路径或 SameSite 匹配规则；这些发送条件不能回答旧会话是否已经真正失效。

持有标识仍可能获得权限

在这种设计中，服务器生成不可预测的标识，并把它关联到一条会话记录。客户端不需要理解该值，但持有它仍可能获得访问资格：窃取有效 bearer 标识的人，可以尝试直接重放。称它“只是指针”不能让读者以为它无害。不要把它放入 URL、日志、诊断截图或支持材料中，随机字符串也可能是实际凭据。

不能直接信任客户端控制的明文角色字段。不过，Cookie 中含有有意义的数据，也不等于必然可以伪造：经过正确认证和签名的会话格式属于另一种设计。签名保护完整性，不提供保密性；无状态方案仍须明确过期、密钥管理与撤销策略。应选择维护良好的会话框架，不要仅为了省一次服务端查询就自行发明格式。

不透明方案需要使用密码学安全随机生成器和足够熵值。未知标识应被拒绝，而不能用客户端任意指定的值建立特权状态。服务器解析会话后，还须根据当前权限授权每项操作。某个会话已经认证，不代表它可以读取每一个对象、操作每一个账号，或自动获得所有管理功能；会话存在与具体动作获准是两项检查。

两种寿命需要两处控制

Cookie 的 Max-Age 与 Expires 管理客户端存储，不会自动使服务端会话记录过期。非浏览器客户端可以保留这个值，并在浏览器本该删除后继续重放。浏览器会话 Cookie 也可能通过会话恢复机制保留。因此必须在服务端强制执行绝对期限与空闲期限，使用明确的边界比较和一致的时间来源，而不能靠标签页里的倒计时作为安全判断。

退出时既要作废服务端状态，也要按匹配的作用域清除浏览器 Cookie，否则复制出来的令牌仍可能有效。认证后与权限变化后轮换标识，有助于防止会话固定，但前提是旧标识确实失去权限。并发请求和分布式存储需要额外协调，避免一个较晚完成的旧请求悄悄恢复已经撤销的会话；只覆盖单进程正常路径远远不够。

Secure 与 HttpOnly 分别约束传输和脚本读取；HttpOnly 不会阻止注入脚本发起认证请求。SameSite 是浏览器语境防御，不是服务端过期或权限检查。Cookie 与请求头限制也因浏览器和服务器而异，并不存在普遍适用的八千字节请求头上限。保持标识紧凑可以减少开销，但不能把体积当成判断会话是否安全的唯一依据。

坏掉的样子

登录时升级了认证前记录，却保留攻击者已经知道的标识；退出时只删除 Cookie，却让复制的值继续有效；空闲超时只由 JavaScript 检查，直接客户端仍能访问。这些都是服务端生命周期故障，即使开发工具中的 Cookie 标记完全正确，也不能弥补这些逻辑问题。排查时要重放旧的虚构标识，而不只是确认响应发出了哪些属性。

不要假定定期活动就应该无限延长访问。空闲计时可以随接受的活动滑动，而同一个会话的绝对截止时间仍然固定。是否在重新认证或提权时开始新的生命周期，应由明确策略决定。尤其要检查令牌刷新是否意外不断重置原本的硬期限，否则名义上的绝对过期可能在活跃客户端面前永远不会到来。

快速验证

将代码保存为 session-lifecycle.py，使用 Python 3.11 或更新版本执行 python3 session-lifecycle.py。它使用虚构用户、可预测的夹具标识与传入的时间值，不打开套接字，也不提供任何真实认证服务。绝不能把这个标识生成器或内存模型用于真实应用；可预测取值只是为了让本地断言清楚可复现。

from itertools import count

# Predictable identifiers are deliberate fixtures, never production tokens.
identifiers = count(1)
sessions = {}
IDLE = 30
ABSOLUTE = 100


def issue(user, role, now):
 sid = f"fixture-{next(identifiers)}"
 sessions[sid] = {"user": user, "role": role, "born": now, "last": now}
 return sid


def lookup(sid, now):
 session = sessions.get(sid)
 if session is None:
 return None
 if now - session["born"] >= ABSOLUTE or now - session["last"] >= IDLE:
 sessions.pop(sid)
 return None
 session["last"] = now
 return session.copy()


def rotate(sid, user, role, now):
 assert lookup(sid, now) is not None
 sessions.pop(sid)
 return issue(user, role, now)


def logout(sid):
 sessions.pop(sid, None)


assert lookup("attacker-chosen", 0) is None
anonymous = issue(None, "anonymous", 0)
authenticated = rotate(anonymous, "demo-user", "reader", 1)
assert authenticated != anonymous and lookup(anonymous, 1) is None
privileged = rotate(authenticated, "demo-user", "editor", 2)
assert lookup(authenticated, 2) is None
assert lookup(privileged, 2)["role"] == "editor"
logout(privileged)
assert lookup(privileged, 3) is None
print("PASS: unknown ID, login rotation, privilege rotation, and logout")

idle = issue("demo-user", "reader", 0)
assert lookup(idle, 20) is not None
assert lookup(idle, 50) is None
active = issue("demo-user", "reader", 0)
for now in (20, 40, 60, 80, 99):
 assert lookup(active, now) is not None
assert lookup(active, 100) is None
assert not sessions
print("PASS: idle and absolute expiry reject at the configured boundary")

第一行确认未知标识被拒绝、登录和提权后得到新标识、被替换的标识不能再使用，以及退出使记录失效。轮换在这个夹具里明确开始新的寿命，策略可直接从 issue 函数看出来。第二行验证空闲三十个时间单位和绝对一百个时间单位的精确边界；即使绝对期限前刚刚有活动，到期仍然被拒绝，不会因为刷新空闲时间而继续生效。

这些断言验证的是生命周期逻辑，不是随机熵、浏览器行为、持久存储、并发轮换或分布式撤销。生产验收应通过真实应用，在登录、提权、退出和超时之后分别重放旧的虚构会话，既检查请求被拒绝，也检查没有产生业务副作用。仅看到删除 Cookie 的响应成功，不能证明旧凭据已经失效，更不能证明所有服务实例都同步采用了撤销结果。

来源

OWASP 会话管理，不可预测标识、重新生成、过期与作废，已核验 2026-10-15。
RFC 6265：Cookie 寿命，客户端存储寿命与属性，已核验 2026-10-15。
RFC 7519：JWT，签名令牌的安全考虑与信任判断，已核验 2026-10-15。

单点登录委托认证，应用仍需验证

Tue, 17 Nov 2026 00:00:00 +0000

单点登录让应用依赖身份提供方的认证结果，用户不必把提供方的密码交给每一个应用。应用仍要负责自己的授权决定、本地会话和接入配置；机密客户端还可能持有客户端凭据。委托认证不会消除应用的安全边界，也不保证以后每次登录都无需用户交互。是否需要重新认证，仍然受提供方策略、当前会话和应用要求影响。

先分清协议与令牌

SAML 与 OpenID Connect 都可支持联合身份，但它们是不同协议，不能简化成可以互换的 XML 与 JSON 编码。本文聚焦 OIDC：它在 OAuth 2.0 之上定义身份层，通过 ID Token 表达认证信息。访问令牌用于访问资源，格式也可能不同。一个看起来像 JWT 的字符串并不自动成为 ID Token；资源服务器更不能因为认识签发者，就把任意一种令牌当作访问许可。

对于 OIDC 身份令牌，应按所选流程的规则校验预期签发者、客户端受众、过期时间，以及请求时发送的 nonce，同时执行适用的授权方和认证上下文检查。签名正确但发给另一个客户端的令牌，仍然不适用。验签密钥要属于已信任的签发者，不能让未验证的签发者字符串驱动程序去任意元数据服务器取得“可信”密钥。

允许的算法和密钥类型，应由验证器的配置确定，而不是由不可信输入自由选择。头部声明必须符合该策略，并与实际密码学操作一致。HS256 本身并非错误：OIDC 定义了使用适当共享秘密的协商式 MAC 签名。把 RSA 公钥当作这个共享秘密，才属于算法混淆。陌生的密钥编号也可能来自合法轮换，但无论如何都不能成为跳过验证的理由。

坏掉的样子

最容易误导人的成功是解码成功。Base64url 与 JSON 解析可以显示一组貌似可信的声明，却没有证明是谁签发了它。管理员身份、正确受众和未来过期时间，都可以被随意编造。不要把真实令牌粘贴到在线解码网站或事故日志；其中可能含有个人信息和仍可使用的凭据。诊断应经过批准的路径，并且只查看确有必要的字段。

登录请求的绑定与令牌验证同样重要。应采用持续维护的 OIDC 接入组件，并按客户端类型与流程使用重定向校验、请求关联及 PKCE 等保护。RFC 9700 给出了 OAuth 安全指导。只检查几个 JWT 字段，不能替代完整协议处理；如果接收了属于另一次请求的令牌，即使签名是真的，也仍可能产生安全问题。

快速验证

把脚本保存为 inspect-sso-fixture.py，在保持断言开启的情况下运行 python3 inspect-sso-fixture.py。它只使用虚构数据，不连接提供方，不读取密钥或凭据，也不访问网络或第三方软件包。这是一项完整的“解码不等于认证”演示，不是供生产使用的令牌解析器，更不是自行实现身份验证的起点：

import base64
import json


def encode(value):
 raw = json.dumps(value, separators=(",", ":")).encode()
 return base64.urlsafe_b64encode(raw).rstrip(b"=").decode()


def inspect_fixture(token):
 header, payload, signature = token.split(".")
 decode = lambda part: json.loads(base64.urlsafe_b64decode(
 part + "=" * (-len(part) % 4)))
 return {"header": decode(header), "claims": decode(payload),
 "signature_text": signature, "verified": False}


header = {"alg": "RS256", "kid": "invented-key"}
claims = {"iss": "https://issuer.example", "aud": "billing",
 "sub": "user-7", "exp": 2000000000}
first = encode(header) + "." + encode(claims) + ".not-a-signature"
second = encode(header) + "." + encode(dict(claims, sub="admin")) + ".not-a-signature"
rows = [inspect_fixture(token) for token in (first, second)]
assert [row["claims"]["sub"] for row in rows] == ["user-7", "admin"]
assert all(row["header"]["alg"] == "RS256" for row in rows)
assert all(row["verified"] is False for row in rows)
print("decoded subjects: user-7, admin")
print("cryptographic verification performed: False")

两个字符串都声称使用 RS256，面向 billing，并来自同一个签发者。把用户改成 admin 不需要任何签名密钥，因为最后一段只是编造的文字。脚本会打印两个身份，并明确报告没有进行密码学验证。它没有验证签名、有效期、受众或发现文档；结果中的假值专门防止读者把一份成功解析的输出误认成已经认证的身份。

实际接入需要另外的测试集，确认错误签发者、错误受众、过期令牌、错误签名、请求 nonce 不匹配及令牌类型不适用时都会被拒绝。还应使用真实库与提供方验证受支持的密钥轮换和错误处理。这些是要在相应环境中完成的集成检查，不能声称本地解码样本已经证明了它们，更不能因为正向登录一次成功就省略负向案例。

为登出单独定义约定

提供方会话、应用会话、访问令牌与刷新令牌，分别具有自己的生命周期。登录时使用的身份令牌过期，不会自动销毁应用 cookie 或服务端会话。因此，缩短令牌期限本身，并不能回答停用账号后现有应用访问会在多久内结束。需要把这些对象及其终止条件逐一列出，避免用其中一个计时器代替整条访问链路。

JWT 的 jti 是可选编号，不是所有系统都必须执行的撤销名单查询。如果要求及时登出，应选择受支持的机制，并确认应用确实终止对应会话。OIDC 后端登出定义了需要独立验证的登出消息及会话清理动作。受支持的令牌自省回答的是某个令牌当前状态，并不会自动作废另一个独立的应用会话。应明确记录离职或停用的实际保证，以及通知失败时的处理方式。

来源

OIDC Core 身份令牌验证，身份令牌、签发者、受众、nonce 与协商算法，已核验 2026-10-15。
RFC 8725：JWT 最佳实践，算法策略、可信签发者与不同令牌类型混淆，已核验 2026-10-15。
RFC 7519：JWT ID，可选编号与重放防护用途，已核验 2026-10-15。
RFC 9700：OAuth 安全，重定向流程与 PKCE 保护，已核验 2026-10-15。
OIDC 后端登出，登出令牌验证与应用会话终止，已核验 2026-10-15。
SAML 2.0 Core，断言与协议消息，已核验 2026-10-15。
RFC 7662，令牌内省，令牌元数据与活动状态，已核验 2026-10-15。

让可复用访问令牌远离请求地址

Sun, 01 Nov 2026 00:00:00 +0000

可复用访问令牌会把某种约定访问能力交给持有它的人。把令牌放进地址，会让这项能力进入平时就会复制地址的系统，例如访问日志、监控记录、浏览器导航历史、书签和分享链接。具体暴露范围取决于请求及策略，但查询参数的名称看起来像秘密，并不会自动让它受到保护。传输位置本身就是凭据披露边界的一部分，应当结合它会经过哪些记录和分享环节判断。

对于 OAuth 持有者令牌请求，通常应采用授权请求头机制。HTTPS 仍然不可缺少，因为把值从查询移动到请求头并不会加密它；TLS 保护的是到终止位置为止的传输数据。传输结束后，应用和中间组件仍然能够检查字段。请求头的直接收益，是让令牌离开请求地址，而不是保证它永远不会被日志或诊断工具捕获。不能把两种不同的保护作用混为一谈。

分清减少暴露与绝对保密

某些访问日志只记录方法、请求目标和状态。在这种格式里，请求头令牌不会出现在目标字段中，而查询令牌会出现。但其他系统可能采集请求头，因此授权字段仍需在日志、链路和错误报告配置中被明确处理。应验证真实管线究竟保存了什么，不能假定请求头可以绕过全部日志层。检查时使用无效的合成值即可，不应为了演示而把真正凭据再次写入更多记录。

引用来源策略能够减少源地址向后续目标披露，却不会删除已经发给目的地的查询内容，也不会抹去浏览器记录或改写已复制的链接。同样，禁止缓存响应并不是要求清除全部访问日志和导航历史的通用指令。把令牌移到片段，会改变 HTTP 请求发送哪些内容，但值仍可被页面脚本和浏览器地址状态访问，也不是适合所有场景的凭据存储方案。

坏掉的样子

团队可能把接口认证从查询参数改成请求头，却让旧的带令牌地址继续留在报告和共享书签中。传输方式改变并不会撤销此前暴露，需要调查受影响的副本，并在系统支持时使已经暴露的可复用凭据失效。另一种误判是把有效期很短的链接称为泄露也无所谓；在有效期间，任何取得这项能力的人仍然可能使用它。缩短时间窗口只能减少风险，不能取消披露的后果。

当实际客户端流程需要时，签名地址可以是有意设计的、范围很窄的资源访问方式，但允许访问的资源、操作、期限和处理规则都应明确审阅。到期失效与只能使用一次并不相同，要阻止到期之前重复使用，需要真正强制执行消费状态的机制。简单的回调接口或浏览器导航，也不会自动构成把无限制可复用接口凭据放进查询的理由，应根据真实客户端选择合适的认证流程。

快速验证

保存代码为 token-placement.py，执行 python3 token-placement.py –serve，打开打印出的页面。本次使用 Python 3.14.4 和 Chrome 152，全部演示值都是明确无效的固定标记，不能替换为真实凭据。回环服务只是观察实验，不是认证服务；它记录请求目标以及示例授权头是否存在，不记录该请求头的值。结束后按控制键加 C 关闭服务，临时事件仅留在本次进程的内存中。

import json
import sys
from http.server import BaseHTTPRequestHandler, HTTPServer
from threading import Event, Thread
from urllib.parse import urlsplit
from urllib.request import Request, urlopen

# Synthetic demonstration value only; this server is not an authentication service.
demo = "DEMO-NOT-A-SECRET"
events = []


class Handler(BaseHTTPRequestHandler):
 def log_message(self, *args):
 pass

 def do_GET(self):
 path = urlsplit(self.path).path
 if path == "/events":
 body = json.dumps(events).encode()
 kind = "application/json"
 elif path == "/echo":
 entry = {"request_target": self.path,
 "authorization_present": self.headers.get("Authorization") == "Bearer " + demo,
 "referer": self.headers.get("Referer")}
 events.append(entry)
 body = json.dumps(entry).encode()
 kind = "application/json"
 else:
 events.append({"request_target": self.path, "document": True})
 body = ("""<!doctype html><meta charset="utf-8"><title>Token placement lab</title>
<h1>A clean referrer does not erase the request URL</h1><pre id="result">Running...</pre><script>
const demo=""" + json.dumps(demo) + """;
async function run() {
 const query=await (await fetch('/echo?access_token='+demo)).json();
 const header=await (await fetch('/echo',{headers:{Authorization:'Bearer '+demo}})).json();
 await new Promise(resolve=>requestAnimationFrame(resolve));
 const resourceUrls=performance.getEntriesByType('resource').map(entry=>entry.name).filter(name=>name.includes('/echo'));
 window.labResult={page:location.href,query,header,resourceUrls};
 document.getElementById('result').textContent=JSON.stringify(window.labResult,null,2);
}
run().catch(error=>{window.labError=String(error);});
</script>""").encode()
 kind = "text/html; charset=utf-8"
 self.send_response(200)
 self.send_header("Content-Type", kind)
 self.send_header("Content-Length", str(len(body)))
 self.send_header("Referrer-Policy", "no-referrer")
 self.send_header("Cache-Control", "no-store")
 self.end_headers()
 self.wfile.write(body)


server = HTTPServer(("127.0.0.1", 0), Handler)
thread = Thread(target=server.serve_forever, daemon=True)
thread.start()
origin = f"http://127.0.0.1:{server.server_port}"
try:
 with urlopen(origin + "/echo?access_token=" + demo, timeout=5) as response:
 query = json.load(response)
 with urlopen(Request(origin + "/echo", headers={"Authorization": "Bearer " + demo}), timeout=5) as response:
 header = json.load(response)
 assert demo in query["request_target"] and query["authorization_present"] is False
 assert demo not in header["request_target"] and header["authorization_present"] is True
 events.clear()
 print(json.dumps({"app_url": origin + "/?access_token=" + demo,
 "wire_placement_checks": "PASS", "real_credentials_used": False}), flush=True)
 if "--serve" in sys.argv:
 Event().wait()
except KeyboardInterrupt:
 pass
finally:
 server.shutdown()
 thread.join(timeout=5)
 server.server_close()

页面先通过 access_token 查询发出一次请求，再通过授权请求头发出另一次请求。因为页面设置了不发送引用来源，两次接收结果中的 Referer 都为空。然而查询请求的目标仍然包含演示标记，请求头方案的目标则只是 echo 路径。浏览器资源计时条目中的地址也体现同样差异。页面自身的地址同样带有演示标记，因此当前导航记录仍保留这条完整地址，不能因为后续请求没有来源头就认为它消失了。

这些观察分别与浏览器状态和服务端合成事件列表核对，单独执行的 Python 探针另外确认了两种请求目标的区别。实验没有验证生产认证、TLS 终止、日志脱敏或签名链接的单次消费。应用到实际客户端和日志系统时，应尽量让可复用凭据离开地址表面，对仍然承载凭据的字段明确进行保护，并验证请求结束后继续存在的存储和分享路径。这样才能知道传输位置改变究竟减少了哪些暴露，以及哪些责任仍然需要完成。

来源

RFC 6750 OAuth 2.0 Bearer Token Usage，授权请求头用法、查询传递的限制及 TLS 要求，已核验 2026-09-13。
OWASP information exposure through URL query strings，地址在日志和浏览器记录中的留存与暴露，已核验 2026-09-13。
MDN Referrer-Policy，禁止引用来源信息能够控制的范围，已核验 2026-09-13。

认证 · XB 现场笔记

OAuth 授权码用码换令牌

公共客户端也能使用授权码流程

把兑换绑定到原始请求

坏掉的样子

快速验证

延伸阅读

来源

Basic Auth 携带的是可重复使用的凭据

看清真正发生的交换

坏掉的样子

快速验证

延伸阅读

来源

Cookie 与会话守住边界

持有标识仍可能获得权限

两种寿命需要两处控制

坏掉的样子

快速验证

延伸阅读

来源

单点登录委托认证，应用仍需验证

先分清协议与令牌

坏掉的样子

快速验证

为登出单独定义约定

来源

让可复用访问令牌远离请求地址

分清减少暴露与绝对保密

坏掉的样子

快速验证

延伸阅读

来源