Authentication Patterns Cheat Sheet / 身份验证模式速查表

Introduction / 介绍

Authentication can be enforced at different layers of a system's architecture. This cheat sheet compares the main patterns, where verification happens in each, and what that means for trust boundaries:

身份验证可以在系统架构的不同层级强制执行。此速查表比较了主要模式，其中每个模式中的验证发生位置，以及这对信任边界意味着什么：

• Service-Level: each service verifies identity itself, or delegates it to a proxy tightly coupled to it.
  中文：服务层：每个服务自行验证身份，或将验证委托给与其紧密耦合的代理。
• Edge-Level: authentication is centralized in a shared component at the system boundary.
  中文：边缘层：身份验证在系统边界的共享组件中集中进行。
• Network-Layer (Node-Level): peers are authenticated cryptographically at the network layer, transparently to applications.
  中文：网络层（节点层）：对等体在网络层进行加密验证，对应用程序是透明的。

The patterns apply to external actors (end users and client applications outside the system) and to internal actors (services, other workloads, and the nodes they run on), although the mechanisms and trust assumptions differ. Most systems authenticate in two phases:

这些模式适用于外部参与者（系统外的最终用户和客户端应用程序）和内部参与者（服务、其他工作负载以及它们运行的节点），尽管机制和信任假设不同。大多数系统分为两个阶段进行身份验证：

• Primary authentication verifies a credential and links it to a known identity: a password, a signed challenge such as a WebAuthn assertion, or, for internal actors, a machine certificate or a workload identity such as a SPIFFE ID.
  中文：主要身份验证验证凭证并将其与已知身份关联：密码、签名挑战，如WebAuthn断言，或者对于内部操作者，机器证书或SPIFFE ID等工作负载身份。
• Authentication proof verification checks the reusable artifact issued after primary authentication (a session cookie, token, or assertion at the application layer; a TLS session key or IPsec Security Association at lower layers) so that primary authentication is not repeated on every request. NIST SP 800-63B describes this as session management based on a session secret.
  中文：身份验证证明验证检查主要身份验证后发放的可重复使用的工件（应用层的一个会话cookie、令牌或断言；低层的一个TLS会话密钥或IPsec安全关联），以确保在每次请求时不会重复主要身份验证。NIST SP 800-63B将此描述为基于会话秘密的会话管理。

Where the distinction does not matter, this cheat sheet uses authentication data for both. The patterns differ in what is verified (credentials or proofs), where verification happens, and which implications this has for system design and trust boundaries.

当区分不重要时，此速查表使用身份验证数据来表示两者。模式的不同之处在于验证什么（凭据或证明）、在哪里进行验证，以及这对系统设计和信任边界有什么影响。

For authorization and for propagating an authenticated identity between services, see the Microservices Security Cheat Sheet, in particular its edge-level, identity propagation, and service-to-service authentication sections.

有关授权和在不同服务之间传播已验证身份的信息，请参阅微服务安全速查表，特别是其边缘层授权、身份传播和服务间身份验证部分。

Service-Level Embedded Authentication / 服务级嵌入式身份验证

In this pattern, each service handles primary authentication itself: it manages identities and credentials, verifies them, and implements the authentication workflows, typically with username/password or API keys. All authentication logic and subject data storage live inside the service, in custom code or built-in libraries. If you have to maintain such a service, the credential handling must follow the Authentication Cheat Sheet and the Password Storage Cheat Sheet.

在此模式中，每个服务自行处理主要身份验证：它管理身份和凭证，验证它们，并实现身份验证工作流程，通常使用用户名/密码或API密钥。所有身份验证逻辑和主题数据存储都位于服务内部，在自定义代码或内置库中。如果您必须维护此类服务，凭证处理必须遵循身份验证速查表和密码存储速查表。

Pros / 优点

• Simplicity: Each service is self-contained and needs no external authentication infrastructure.
  中文：简单性：每个服务都是自包含的，无需外部身份验证基础设施。
• Customization freedom: Authentication behavior can be adapted to service-specific requirements without external constraints.
  中文：定制自由度：可以不受外部约束地根据服务特定要求调整身份验证行为。
• Support for external and internal actors: Because the service controls all authentication functionality, it can orchestrate different authentication contexts (internal services and external users), at the price of significant complexity (see the authentication orchestration con below).
  中文：支持外部和内部参与者：因为服务控制所有身份验证功能，所以它可以协调不同的身份验证上下文（内部服务和外部用户），但这会带来显著的复杂性（见下文中的身份验证编排）。

Cons / 缺点

• Inconsistency: Authentication behavior, credential storage, and flows differ across services, which fragments the system, degrades the user experience, and rules out Single Sign-On (SSO).
  中文：不一致性：身份验证行为、凭证存储和工作流程在服务之间不同，这会碎片化系统，降低用户体验，并排除单点登录（SSO）。
• Security risk: Authentication code is duplicated across services, increasing the risk of vulnerabilities and complicating audits.
  中文：安全风险： 认证代码在服务间重复，增加了漏洞风险并复杂化了审计过程。
• Maintenance burden: Changing authentication methods (for example, introducing multi-factor authentication (MFA)) requires updates across all affected services.
  中文：维护负担： 更改认证方法（例如，引入多因素认证（MFA））需要在所有受影响的服务中进行更新。
• Limited scalability: Each service manages its own identities, which does not scale to service-to-service authentication across a large system.
  中文：可扩展性有限： 每个服务管理自己的身份，这在大规模系统中无法扩展到服务间认证。
• Limited observability and governance: Without centralized monitoring, credential reuse, account compromise, or brute-force attacks against one service remain invisible to the others, hindering coordinated detection and response.
  中文：可观察性和治理有限： 没有集中监控，一个服务的凭证重用、账户被篡改或暴力破解攻击对其他服务来说是不可见的，阻碍了协调检测和响应。
• Authentication orchestration: Supporting multi-principal subjects (multiple authentication configurations, protocol chaining, and subject-specific variations for contexts such as first- and third-party access, or external clients next to service-to-service calls) adds significant complexity.
  中文：认证编排： 支持多主体（多个认证配置、协议链式和针对如第一方和第三方访问、或服务间调用旁边的外部客户端等上下文的特定主体变体）增加了显著复杂性。
• Coupling of external authentication data with internal trust assumptions: Using the same authentication data for external clients and internal services increases the risk of leakage and unauthorized access. If an internal service is exposed through a misconfiguration, or an attacker gains internal access, the leaked authentication data grants access to sensitive resources.
  中文：外部认证数据与内部信任假设的耦合： 使用相同的认证数据对外部客户端和内部服务增加了泄露和未经授权访问的风险。如果内部服务因配置错误而暴露，或攻击者获得内部访问权限，泄露的认证数据将允许访问敏感资源。

Service-Level Code-Mediated Authentication / 服务级代码中介认证

This pattern addresses key limitations of Service-Level Embedded Authentication: fragmented identity management, duplicated credential stores, and lack of SSO. The service no longer verifies credentials directly. Instead, an external Identity Provider (IdP) authenticates the subject and issues authentication proofs; the service verifies these itself and extracts identity attributes for request processing.

此模式解决了服务级嵌入式认证的关键局限性：身份管理碎片化、凭证存储重复和缺乏SSO。服务不再直接验证凭证。相反，外部身份提供者（IdP）验证主体并颁发认证证明；服务自行验证这些证明并提取身份属性以进行请求处理。

Pros / 优点

• SSO support: Identity and credential lifecycle is consolidated in the IdP, enabling SSO and reducing duplication.
  中文：单点登录支持： 身份和凭证生命周期在身份提供者（IdP）中集中管理，实现单点登录并减少重复操作。
• Lower security risks: Centralized authentication reduces the attack surface related to credential handling.
  中文：降低安全风险： 集中认证减少了与凭证处理相关的攻击面。
• Improved user experience: Consistent authentication flows and session handling across services.
  中文：提升用户体验： 在各个服务中保持一致的认证流程和会话管理。
• Interoperability: Widely adopted protocols like OpenID Connect (OIDC) and SAML provide flexibility and broad integration possibilities with various IdPs.
  中文：互操作性： 广泛采用的协议，如 OpenID Connect (OIDC) 和 SAML，提供了灵活性和广泛的集成可能性，与各种身份提供者 (IdP) 配合使用。
• Customization freedom: Services can still tailor authentication behavior to specific needs, for example where standards like OIDC are not applicable.
  中文：定制自由度： 服务仍然可以根据特定需求定制认证行为，例如在OIDC等标准不适用的情况下。
• Support for external and internal actors: As in the embedded pattern, with the same orchestration complexity.
  中文：支持内外部参与者： 如嵌入式模式中所述，具有相同的编排复杂性。

Cons / 缺点

• Protocol handling overhead: Each service must implement and maintain logic for authentication proof verification and protocol-specific behavior.
  中文：协议处理开销： 每个服务都必须实现和维护认证证明验证和特定协议行为的逻辑。
• Misconfiguration risks: Incorrect verification logic, such as missing expiration checks or improper use of cryptography, can introduce severe security vulnerabilities.
  中文：配置错误风险： 如缺少过期检查或不当使用加密等错误的验证逻辑，可能会引入严重的安全漏洞。
• Authentication orchestration: Same complexity as in the embedded pattern.
  中文：认证编排： 与嵌入式模式中的复杂性相同。
• Coupling of external authentication data with internal trust assumptions: Same risk as in the embedded pattern.
  中文：外部认证数据与内部信任假设的耦合： 与嵌入式模式中的风险相同。

Service-Level Proxy-Mediated Authentication / 服务级代理中介认证

This pattern builds on the previous pattern but moves authentication logic out of the service into a dedicated proxy deployed as a sidecar alongside it. The proxy sits in front of the application, verifies authentication proofs with the Identity Provider (IdP), injects identity context into the request (typically as headers), and forwards it locally to the service.

该模式基于之前的模式，但将认证逻辑从服务中移出，部署为与其并行的专用代理。代理位于应用程序之前，验证来自身份提供者（IdP）的认证证明，将身份上下文注入请求（通常作为头部），并将其本地转发到服务。

Pros / 优点

• All benefits of the code-mediated pattern: SSO, centralized credential handling, a consistent user experience, and standards-based interoperability (see above).
  中文：代码中介模式的所有优势： 单点登录（SSO）、集中式凭证处理、一致的用户体验和基于标准化的互操作性（见上文）。
• Separation of concerns: Removes authentication logic from application code, simplifying service development and reducing maintenance effort.
  中文：关注点分离： 将认证逻辑从应用程序代码中移除，简化服务开发并减少维护工作量。
• Consistent behavior: Identity verification and protocol handling in the proxy ensure uniform behavior across services.
  中文：一致的行为： 代理中的身份验证和协议处理确保服务之间的行为一致。
• Improved security posture: Consolidating authentication logic into a dedicated, hardened component reduces the risk of implementation flaws.
  中文：改进的安全态势： 将认证逻辑整合到专用、加固的组件中，降低了实现缺陷的风险。
• Authentication orchestration: Some proxies support multiple authentication configurations, including protocol chaining and subject-specific variations, which covers first- and third-party access or a mix of external clients and internal services.
  中文：认证编排： 一些代理支持多种认证配置，包括协议链和特定主题的变体，涵盖了第一方和第三方访问或外部客户端和内部服务的混合。
• Strong foundation for service-to-service trust: Enables Zero Trust networking with workload identity, typically realized with SPIFFE/SPIRE, which issues workload identities as X.509 certificates used for mutual TLS (mTLS) between services.
  中文：服务间信任的坚实基础： 通过工作负载身份实现 零信任 网络，通常使用 SPIFFE/SPIRE 实现，它通过颁发 X.509 证书 作为服务间相互 TLS (mTLS) 的身份验证。

Cons / 缺点

• Operational complexity: Requires deploying and maintaining an additional component per microservice, with higher resource usage and cost.
  中文：操作复杂性： 每个微服务都需要部署和维护额外的组件，导致更高的资源使用和成本。
• Header spoofing risk: The application trusts identity headers set by the sidecar, so any path that lets a caller set those headers yields a forged identity: a client reaching the application port directly, or the proxy forwarding identity headers it received from the caller. Countermeasures: the sidecar must strip or overwrite every inbound identity header before injecting its own (Envoy, for example, sanitizes x-forwarded-client-cert by default); the application must accept traffic only from its sidecar (bind to loopback, or enforce a network policy that only allows the sidecar to reach the application port); or, where that isolation cannot be guaranteed, the sidecar must sign the injected headers with HTTP Message Signatures so the application can verify their origin. Define a signature profile that binds the identity to the intended service and relevant request components. The application must verify the trusted signer's signature and enforce freshness and replay checks. NIST SP 800-204 (MS-SS-13) recommends layer 3 network segmentation for sensitive applications precisely to counter callers bypassing the sidecar proxy.
  中文：头部欺骗风险： 应用程序信任由边车设置的标识头部，因此任何允许调用者设置这些头部的路径都会产生伪造的身份：客户端直接到达应用程序端口，或者代理转发从调用者接收到的标识头部。对策：边车必须在注入自己的头部之前删除或覆盖每个传入的标识头部（例如，Envoy 默认会 清理 x-forwarded-client-cert）；应用程序必须只接受来自其边车的流量（绑定到回环，或强制执行仅允许边车到达应用程序端口的网络策略）；或者，如果无法保证这种隔离，边车必须使用 HTTP 消息签名 对注入的头部进行签名，以便应用程序可以验证其来源。定义一个签名配置文件，将身份绑定到目标服务和相关的请求组件。应用程序必须验证受信任的签名者的签名，并强制执行新鲜性和重放检查。NIST SP 800-204 (MS-SS-13) 建议对敏感应用程序进行第 3 层网络分段，以精确地对抗绕过边车代理的调用者。
• Configuration consistency: All proxies across the service landscape must be configured uniformly; inconsistencies lead to confusing user flows or security vulnerabilities.
  中文：配置一致性： 服务范围内的所有代理必须统一配置；不一致性会导致用户流程混乱或安全漏洞。
• Coupling of external authentication data with internal trust assumptions: Same risk as in the embedded pattern, because the external authentication data still travels to every service's sidecar for verification.
  中文：外部认证数据与内部信任假设的耦合： 与嵌入式模式中的风险相同，因为外部认证数据仍然需要传输到每个服务的边车进行验证。

Edge-Level Authentication / 边缘级认证

In this pattern, authentication is handled at the system boundary by a shared component such as an API gateway or ingress proxy. This component authenticates incoming requests from external clients before they reach internal services. It uses OIDC or SAML with an identity provider for user authentication, validates OAuth 2.0 access tokens for API access, or uses mTLS for certificate-based client authentication. It propagates verified identity information, typically via headers, to downstream services.

在此模式中，认证由共享组件（如API网关或入口代理）在系统边界进行处理。该组件在请求到达内部服务之前对来自外部客户端的请求进行认证。它使用OIDC或SAML与身份提供者进行用户认证，验证OAuth 2.0访问令牌以访问API，或使用mTLS进行基于证书的客户端认证。它通过头部等途径传播已验证的身份信息，通常传递给下游服务。

This consolidates authentication into a single enforcement point and removes per-service authentication handling. It corresponds to the gateway or portal placement of the policy enforcement point described in NIST SP 800-207 (Zero Trust Architecture).

这将认证集中到单个执行点，并消除了每个服务的认证处理。它对应于NIST SP 800-207（零信任架构）中描述的策略执行点的网关或门户位置。

Pros / 优点

• Improved consistency: Authentication is performed uniformly at a single entry point, reducing fragmentation and configuration drift and improving auditability.
  中文：提高一致性： 认证在单个入口点统一执行，减少碎片化和配置漂移，并提高可审计性。
• Simplified service logic: Internal services are relieved from implementing authentication and focus on authorization and business functionality.
  中文：简化服务逻辑： 内部服务从实现认证中解脱出来，专注于授权和业务功能。
• Faster service onboarding: New services rely on the existing infrastructure for authentication and need minimal additional setup.
  中文：更快的服务上线： 新服务依赖于现有基础设施进行身份验证，并且需要最少的额外设置。
• Protocol-agnostic identity propagation: The edge verifies the external authentication data once and propagates identity to internal services in a trusted, implementation-independent format: a newly issued JSON Web Token (JWT), headers protected with HTTP Message Signatures, or a signed proprietary structure. Unlike the service-level patterns, where every service or its sidecar must receive and verify the external authentication data, internal services only ever see the internal representation.
  中文：协议无关的身份传播： 边缘验证一次外部认证数据，并以信任的、实现无关的格式将身份传播到内部服务：一个新颁发的 JSON Web Token (JWT)，使用 HTTP 消息签名 保护的头部，或一个签名专有结构。与服务级别模式不同，其中每个服务或其边车都必须接收和验证外部认证数据，内部服务只看到内部表示。

Cons / 缺点

• Limited granularity: Fine-grained or per-endpoint authentication policies (for example, step-up authentication) are harder to implement and may require coordination with downstream services, depending on the capabilities of the edge proxy.
  中文：有限的粒度： 细粒度或按端点身份验证策略（例如，逐步身份验证）更难实现，并且可能需要与下游服务协调，具体取决于边缘代理的能力。
• Identity propagation challenges: Secure and reliable propagation of identity context (for example, via headers) requires strict validation and an explicit trust model between the edge and internal services. Use one of the protected formats above, and make internal services verify the signature and reject requests whose identity context is missing or unsigned.
  中文：身份传播挑战： 安全且可靠地传播身份上下文（例如，通过头部信息）需要严格的验证以及在边缘和内部服务之间显式的信任模型。使用上述受保护的格式之一，并让内部服务验证签名，拒绝身份上下文缺失或未签名的请求。
• Single point of failure: The ingress proxy or gateway is already a central component in most architectures, but authenticating at the edge makes it a critical part of the security infrastructure. Misconfiguration or compromise affects the integrity of authentication decisions system-wide.
  中文：单点故障： 入口代理或网关在大多数架构中已经是中央组件，但在边缘进行身份验证使其成为安全基础设施的关键部分。配置错误或被入侵会影响整个系统身份验证决策的完整性。
• Not suitable for service-to-service authentication: Edge-level authentication only covers incoming external requests. Internal service-to-service calls need their own mechanism, and any component that can reach a service directly bypasses the gateway entirely; NIST SP 800-204 (MS-SS-2) recommends mutual authentication to prevent such direct, anonymous connections. Routing internal traffic through the edge is technically possible but introduces severe performance bottlenecks.
  中文：不适用于服务间认证： 边缘级别认证仅涵盖传入的外部请求。内部服务间调用需要自己的机制，任何可以直接到达服务的组件都会完全绕过网关；NIST SP 800-204 (MS-SS-2) 建议相互认证以防止此类直接、匿名的连接。通过边缘路由内部流量在技术上可行，但会引入严重的性能瓶颈。

Network-Layer (Node-Level) Authentication / 网络层（节点级）身份验证

This pattern authenticates peers at the network layer (layer 3), inside the operating system kernel, using cryptographic identities attached to a node or host rather than to an application. Implementations are built on IPsec or WireGuard: the identity of a peer is bound to keys configured on each node, and every packet is cryptographically authenticated. Enforcement is transparent to applications, which makes it a good complement for securing traffic between workloads, but not a replacement for application-layer authentication.

此模式在操作系统的内核中（第3层）的网络层对等身份进行身份验证，使用附加到节点或主机的加密身份，而不是应用程序。实现基于 IPsec 或 WireGuard：对等方的身份绑定到每个节点上配置的密钥，每个数据包都进行加密验证。执行对应用程序是透明的，这使得它成为保护工作负载之间流量的一种很好的补充，但不能替代应用层身份验证。

Pros / 优点

• Transparent to applications: Services need no authentication logic; the kernel enforces peer identity for all traffic.
  中文：对应用程序透明： 服务不需要身份验证逻辑；内核强制执行所有流量的对等方身份。
• Protocol-agnostic: Applies to all traffic types, not just HTTP.
  中文：协议无关： 适用于所有流量类型，而不仅仅是HTTP。
• Low overhead: Kernel implementation and lightweight handshakes keep latency low while providing strong isolation between nodes.
  中文：低开销： 内核实现和轻量级握手保持低延迟，同时在节点之间提供强大的隔离性。
• Provides node (host) identity: Each node holds its own key material and every packet is authenticated, which resists spoofing and replay at the network layer and supports Zero Trust segmentation between nodes.
  中文：提供节点（主机）身份：每个节点持有自己的密钥材料，每个数据包都经过认证，这可以在网络层抵抗欺骗和重放攻击，并支持节点间的零信任分段。

Cons / 缺点

• Not suitable for application-level (layer 7) authentication: Identities belong to nodes or hosts, not to individual users, external clients, or, usually, individual workloads. Every workload on a node shares the node's identity, and user-specific attributes cannot be conveyed.
  中文：不适用于应用层（第7层）身份验证： 身份属于节点或主机，而不是单个用户、外部客户端或通常的单独工作负载。节点上的每个工作负载都共享节点的身份，无法传达特定于用户属性。
• Limited observability: Monitoring is confined to connection-level data (source and destination nodes), with no insight into user-driven actions inside the application.
  中文：可观察性有限： 监控仅限于连接级别数据（源节点和目标节点），无法洞察应用程序内部由用户驱动的操作。
• Infrastructure complexity: Requires robust automation for key and identity management and OS- or kernel-level policy enforcement (for example, via eBPF).
  中文：基础设施复杂性：需要强大的自动化进行密钥和身份管理以及操作系统或内核级别的策略执行（例如，通过eBPF）。

Operational and Security Considerations / 操作和安全考虑因素

The patterns differ primarily in where and how authentication is performed, but they also have significant implications for operations and authorization. Choosing a pattern comes down to balancing development flexibility, operational effort, and risk tolerance.

模式的主要区别在于在哪里以及如何执行身份验证，但它们也对操作和授权有重大影响。选择模式取决于平衡开发灵活性、操作努力和风险承受能力。

Operational Considerations / 操作考虑因素

Pattern / 模式	Configuration & Implementation Burden / 配置与实施负担	Operational Overhead / 运营开销	Observability Scope / 可观察范围
Service-Level Embedded 服务级嵌入式	High	High	Application-specific 应用特定
Service-Level Code-Mediated 服务级别代码中介	Medium 中等	Medium 中等	IdP + Application-specific 身份提供者 + 应用特定
Service-Level Proxy-Mediated 服务级别代理中介	Medium 中等	High (infra cost) 高（基础设施成本）	Proxy + Application 代理 + 应用
Edge-Level 边缘级	Low	Low	Centralized (Proxy) 集中式（代理）
Network-Layer (Node-Level) 网络层（节点级）	Low-Medium 低-中	High (infra complexity) 高（基础设施复杂性）	Network-level only 仅网络层

Patterns with decentralized authentication (like Service-Level Embedded Authentication) typically incur more operational overhead due to inconsistencies, duplicated configuration, and monitoring complexity. Centralized patterns reduce duplication but introduce infrastructure dependencies and require resilient design.

具有去中心化身份验证（如服务级内嵌身份验证）的模式通常由于不一致性、重复配置和监控复杂性而造成更多的操作开销。集中式模式减少了重复，但引入了基础设施依赖，并需要具有弹性的设计。

Security Considerations / 安全考量

Security risks increase significantly when authentication logic and credentials are handled directly within application code. Centralized enforcement, whether at the IdP, at the edge, or in the kernel, limits exposure, enforces stronger boundaries, and reduces the risk of misconfiguration. However, trust leakage must be prevented, because it directly undermines the principle of least privilege. This depends not only on where authentication occurs, but also on how identity information is propagated and verified downstream. Without trustworthy, tamper-resistant propagation, even strong initial authentication can be undermined, weakening trust boundaries and the system's ability to make reliable authorization decisions. The Identity Propagation Patterns Cheat Sheet compares forwarding, token exchange, and trusted internal assertions, including their validation requirements and limitations.

当认证逻辑和凭证直接在应用程序代码中处理时，安全风险显著增加。无论是在身份提供者（IdP）、边缘还是内核中进行集中执行，都可以限制暴露范围，加强边界，并减少配置错误的风险。然而，必须防止信任泄露，因为它直接破坏了最小权限原则。这不仅取决于认证发生的位置，还取决于身份信息如何传播和验证。如果没有可靠的、防篡改的传播，即使是强大的初始认证也可能被破坏，削弱信任边界和系统做出可靠授权决策的能力。身份传播模式速查表比较了转发、令牌交换和可信内部断言，包括它们的验证要求和限制。

Note: Token theft, replay protection, session lifecycle, and reauthentication are critical when implementing any of these patterns. They are covered in the Authentication Cheat Sheet and the Session Management Cheat Sheet.

注意：在实现这些模式时，令牌盗窃、重放保护、会话生命周期和重新认证是至关重要的。它们在认证速查表和会话管理速查表中有详细说明。

Recommendations / 建议

• Authenticate external actors at the edge. Centralize external authentication in a gateway or ingress proxy, as described in NIST SP 800-207 and NIST SP 800-204 (MS-SS-2). Normalize different authentication mechanisms into a signed internal assertion when needed. Forward an external access token only to its intended recipients, with the required validation and proof at each receiving service; otherwise exchange it or issue a suitable internal assertion. See Identity Propagation Patterns for these requirements.
  中文：在边缘验证外部参与者。如NIST SP 800-207和NIST SP 800-204（MS-SS-2）所述，在网关或入口代理中集中外部身份验证。在需要时，将不同的身份验证机制标准化为签名内部声明。仅将外部访问令牌转发给其预期接收者，在每个接收服务中进行必要的验证和证明；否则交换它或颁发合适的内部声明。参见身份传播模式以了解这些要求。
• Authenticate internal service calls with proxy-mediated mTLS and workload identity. Give every workload its own cryptographic identity, for example an X.509 SVID issued through SPIFFE, and have the sidecar enforce mutual authentication with TLS client certificates on every service-to-service connection, as NIST SP 800-204 (MS-SS-4) recommends. See also Client Certificates and Mutual TLS.
  中文：使用代理介导的mTLS和工作负载身份验证内部服务调用。 为每个工作负载分配其自己的加密身份，例如通过SPIFFE颁发的X.509 SVID，并让边车代理在每个服务间连接上强制执行与TLS客户端证书的相互认证，正如NIST SP 800-204 (MS-SS-4)所建议的。参见客户端证书和相互TLS。
• Do not embed authentication in new systems. Service-level embedded authentication fragments identity, duplicates credential stores, and rules out SSO. Reserve it for legacy code you cannot change, and even then follow the Authentication Cheat Sheet.
  中文：不要在新系统中嵌入认证。服务级嵌入式认证会分割身份，重复凭证存储，并排除单点登录（SSO）。仅将其保留在无法更改的旧代码中，即使如此，也应遵循认证速查表。
• Treat network-layer (node-level) authentication as a transport complement, never as the sole control. It authenticates nodes, not users or workloads, and NIST SP 800-207 is explicit that network location alone does not imply trust. Combine it with edge-level or proxy-mediated authentication; NIST SP 800-204 (MS-SS-13) likewise positions layer 3 segmentation as a complement to service mesh controls.
  中文：将网络层（节点级）认证视为传输补充，绝不能作为唯一控制手段。 它认证节点，而不是用户或工作负载，NIST SP 800-207明确指出，网络位置本身并不表示信任。将其与边缘级或代理介导的认证结合；NIST SP 800-204 (MS-SS-13)同样将第3层分段定位为服务网格控制的补充。

References / 参考

• NIST SP 800-204: Security Strategies for Microservices-Based Application Systems) （NIST SP 800-204：基于微服务应用程序系统的安全策略）
• NIST SP 800-207: Zero Trust Architecture) （NIST SP 800-207：零信任架构）