Skip to content

Identity Propagation Patterns Cheat Sheet / 身份传播模式速查表

Introduction / 介绍

Identity propagation carries authenticated user context between services. Choose a representation that each recipient can validate and that limits where credentials can be used; OAuth security guidance recommends restricting access tokens to their intended resources and actions. See Authentication Patterns for authenticating the original request and Authorization Patterns for enforcing access decisions.

身份传播在服务之间传递已认证的用户上下文。选择一种每个接收者都可以验证且限制凭证使用范围的表现形式；OAuth安全指南建议限制访问令牌仅用于其预期资源和操作。参见身份验证模式以验证原始请求，以及授权模式以执行访问决策。

Validation at Each Boundary / 每个边界的验证

Separate the identity of the calling service from the user on whose behalf it acts. Authenticate service connections using the controls in Microservices Security; possession of user context alone does not establish the caller's service identity.

将调用服务的身份与其代表用户区分开来。使用微服务安全中的控件进行服务连接的认证；仅拥有用户上下文本身并不能确立调用者的服务身份。

  • Accept identity assertions only from configured issuers authorized to make those assertions. For JSON Web Tokens (JWTs), validate the signature, allowed algorithm, issuer, audience, token type, and validity period according to the applicable token profile. RFC 8725 explains why signature verification alone is insufficient.
    中文：仅接受配置的发行者提供的身份断言。对于 JSON Web Tokens (JWT)，根据适用的令牌配置文件验证签名、允许的算法、发行者、受众、令牌类型和有效期。RFC 8725 解释了为什么仅签名验证是不够的。
  • For opaque access tokens, use the issuer's supported validation mechanism. A token's representation does not determine whether it grants access to a particular operation.
    中文：对于不透明的访问令牌，使用发行者的支持验证机制。令牌的表现形式并不决定它是否授予对特定操作的访问权限。
  • Do not treat an OpenID Connect ID token as an API access token. Forwarding a certificate also does not preserve proof of private-key possession on a TLS connection. Preserve each protocol's validation and proof requirements.
    中文：不要将 OpenID Connect ID 令牌 视为 API 访问令牌。转发证书也不会保留 TLS 连接上私钥所有权的证明。保留每个协议的验证和证明要求。
  • Reject missing or invalid context. Each receiving service must still authorize the requested action and resource. A valid signature establishes the issuer and integrity of an assertion, not permission for every request.
    中文：拒绝缺失或无效的上下文。每个接收服务都必须授权请求的操作和资源。有效的签名确立了声明的发行者和完整性，而不是每个请求的权限。

The diagrams below illustrate the flow of identity data. Their verification steps include these checks; a component labeled "Verifier" need not be a separate online service.

下面的图示说明了身份数据的流动。它们的验证步骤包括这些检查；标记为“验证器”的组件不必是一个单独的在线服务。

Propagation Patterns / 传播模式

External Identity Propagation

The edge passes an external access token to a service that is an intended recipient. Each recipient validates it before use.

External identity propagation

外部身份传播

This is reasonable when services share the token's validation profile and the token is intended for those services. Do not widen token audiences merely to make forwarding work. Audience restriction limits the impact of a leaked token; forwarding a bearer token to more services increases the places from which it can leak. Forwarding is not inherently incompatible with Zero Trust, but it does not provide isolation between recipients that accept the same credential.

Simple Service-Level Identity Forwarding

A service extracts user attributes and forwards a JSON object, header, or assertion that it signs itself.

Simple service-level identity forwarding

简单服务级别身份转发

Avoid making arbitrary application services identity issuers. An authenticated channel, or a signature made by the forwarding service, can identify the sender and protect transit integrity; neither proves that the sender is entitled to assert a user's identity or privileges. Every service trusted to supply these attributes can misrepresent them. If using a trusted proxy header, remove client-supplied copies, authenticate the proxy, and prevent requests from bypassing it. Prefer an assertion from a designated issuer when context crosses multiple service boundaries.

Token Exchange

A service presents an incoming token to a Security Token Service (STS) and requests a token for a downstream recipient. RFC 8693 defines this exchange, including subject and actor tokens, requested audiences, and scopes. Authenticate the requesting service to the STS. The STS must authorize the exchange and constrain the issued privileges; requesting a narrower token is not a substitute for issuer-side enforcement.

Token exchange

基于令牌交换的身份发行

Use exchange when a downstream call needs a different audience or explicit delegation. Preserve the distinction between the user and the acting service where the policy depends on it. Exchange adds an issuance dependency; plan for STS outages without accepting invalid credentials. RFC 8693 does not require all input credentials to be OAuth access tokens or all issued tokens to be signed JWTs.

使用交换功能，当下游调用需要不同的受众或显式委派时。在策略依赖于用户与执行服务之间的区别时，保持这种区别。交换添加了一个发行依赖；在不接受无效凭据的情况下，计划处理 STS 停机。RFC 8693 不要求所有输入凭据都是 OAuth 访问令牌，也不要求所有发行的令牌都是签名 JWT。

Protocol-Agnostic Identity Propagation / 协议无关的身份传播

The edge validates the external credential and obtains a normalized internal assertion from a trusted issuer. Internal services validate that assertion instead of implementing each external authentication protocol.

边缘验证外部凭据，并从受信任的发行者那里获取一个标准化的内部断言。内部服务验证该断言，而不是实现每个外部认证协议。

Protocol-agnostic identity propagation

协议无关的身份传播

Prefer this approach when several external authentication mechanisms must feed the same internal services. Keep issuance privileges separate from verification privileges, and limit the assertion's recipients and lifetime. Signing protects integrity; it does not hide claims, prevent bearer-token replay, or compensate for a compromised issuer.

当多个外部认证机制必须为同一内部服务提供数据时，优先采用此方法。将发行权限与验证权限分开，并限制断言的接收者和有效期。签名保护完整性；它不会隐藏声明，防止携带令牌重放，或补偿受损害的发行者。

The Transaction Tokens draft is one developing example: an ingress or initiating workload obtains a transaction token and workloads normally propagate it unmodified within a trust domain. Recipients validate its signature, trust-domain audience, and expiry, then authorize their own operation. The draft also permits constrained replacement by the token service. Its tokens are not replay resistant; this is not a fresh audience-specific exchange at every service hop.

《事务令牌草案》（https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-11#section-12.2）是一个正在发展的示例：入口或发起工作负载获取一个事务令牌，工作负载通常在信任域内无修改地传播。接收者验证其签名、信任域受众和过期时间，然后授权自己的操作。该草案还允许由令牌服务进行约束性替换。其令牌不具有重放抵抗性；这不是在每个服务跳转时都进行的新受众特定的交换。

Privacy and Recommendation / 隐私和推荐

Send only the identity attributes a recipient needs. Use pseudonymous identifiers where appropriate and protect tokens in transit; RFC 8693's privacy considerations describe these controls. Mapping an external identifier to an internal one does not by itself prevent correlation, and signing does not provide confidentiality. Keep internal assertions out of client responses and follow the Logging Cheat Sheet when recording identity events.

只发送接收者需要的身份属性。在适当的情况下使用匿名标识符，并保护传输中的令牌；RFC 8693 的隐私考虑描述了这些控制措施。将外部标识符映射到内部标识符本身并不能防止关联，签名也不提供机密性。将内部断言排除在客户端响应之外，并在记录身份事件时遵循日志作弊表。

Start with a token that each intended recipient can validate. Use exchange for recipient-specific delegation, or a trusted internal issuer to normalize external credentials. In every pattern, validate context at each receiving service and enforce least privilege there.

从一个每个预期接收者都可以验证的令牌开始。使用交换进行针对接收者的特定委派，或使用受信任的内部发行者来标准化外部凭据。在每种模式中，在每个接收服务中验证上下文，并在那里执行最小权限原则。

References / 参考