Zero Trust for Federal OAuth and SAML Trust Relationships: Securing Federation, Token Exchange, and Assertion Flows

Federal agencies have spent years building out identity federation to support hybrid workforces, cross-agency partnerships, and cloud-hosted applications. The protocols that make that federation work, primarily OAuth 2.0, OpenID Connect, and SAML 2.0, were designed for interoperability. They were not designed with the assumption that every trust relationship would be continuously validated, that signing keys would be rotated on a defined schedule, or that every token exchange would be treated as a potential attack surface. That gap is where real risk lives.

Applying Zero Trust to federation is not the same as applying Zero Trust to user access broadly. It requires examining the mechanics of how trust is established and transferred between systems, not just who is logging in. That means looking at how assertions are signed and validated, how tokens are scoped and bounded, how redirect flows are protected against injection and hijacking, and how brokered federation introduces translation points that can silently expand trust beyond what was intended.

Most federal environments running hybrid identity today have at least one of these problems: signing certificates that are not rotated on a defined schedule, SAML assertions that are not encrypted end-to-end, OAuth clients with scopes broader than any single use case requires, or federation gateways that log authentication events but not token exchange details. None of these are exotic vulnerabilities. They are the predictable result of deploying federation protocols under acquisition timelines that prioritize connectivity over security architecture.

This article is a protocol-level implementation guide. It addresses the specific control points within OAuth, OIDC, and SAML flows where trust can be validated, constrained, or broken, and maps those controls to federal Zero Trust, NIST, CISA, and RMF expectations. It is written for the engineers and architects who are actually configuring these systems, not for the program office that approved the identity modernization initiative.

OAuth and OIDC Trust Mechanics in Federal Environments

One of the most persistent misunderstandings in federal identity deployments is treating OpenID Connect as an authentication protocol in the same way SAML is an authentication protocol. OIDC is built on top of OAuth 2.0, which is an authorization framework. The ID token that OIDC returns is an assertion about the user’s identity, but the underlying grant is an authorization grant. That distinction matters because the security controls that apply to OAuth authorization flows also apply to OIDC, and many federal implementations apply only the identity-layer controls while leaving the authorization-layer controls under-configured.

In the authorization code flow, the most appropriate flow for federal web applications, the client exchanges an authorization code for tokens at the token endpoint. The security of that exchange depends on several controls working together: the redirect URI must be registered and validated exactly, the authorization code must be single-use and short-lived, and Proof Key for Code Exchange must be enforced to prevent code interception attacks. PKCE was originally designed for public clients but is now required for all client types in OAuth 2.1 and is consistent with NIST SP 800-63C guidance on assertion confidentiality.

Nonce binding is the primary replay protection mechanism in OIDC. The client generates a nonce, includes it in the authorization request, and validates that the same nonce appears in the returned ID token. If the identity provider does not include the nonce in the token, or if the client does not validate it, replay attacks become feasible. Federal deployments that use off-the-shelf identity provider configurations frequently skip nonce validation because the default client library behavior does not enforce it unless explicitly configured.

The issuer claim in an ID token must be validated against the expected issuer value from the identity provider’s discovery document. In multi-tenant cloud identity environments, this is especially important because a token issued by one tenant can be structurally valid while being issued by a completely different organization. Audience validation, the verification that the token’s audience claim matches the client’s registered identifier, prevents a token issued for one application from being accepted by another. Both checks must be enforced at the application layer, not assumed to be handled by the identity provider.

Token exchange, defined in RFC 8693, introduces additional complexity in federal environments where a service needs to act on behalf of a user when calling a downstream service. The delegation chain must be explicitly bounded. The subject token, the actor token, and the resulting token each carry scope and audience claims that define what the exchanged token is permitted to do. Without explicit scope restriction at the exchange endpoint, a service can request a token with broader permissions than the original grant authorized, which is the core of the confused-deputy problem in federated service-to-service access.

SAML Assertion Validation and Trust Boundary Controls

SAML 2.0 remains the dominant federation protocol in federal civilian and defense environments, particularly for legacy applications and cross-agency partnerships that predate OIDC adoption. The protocol’s trust model depends entirely on the integrity of the assertion, which is an XML document signed by the identity provider and consumed by the service provider. Every step of that chain has a corresponding validation requirement, and each one represents a control point where a misconfiguration creates exploitable trust.

Assertion Signature Validation

Signature validation must verify the assertion against the identity provider’s published signing certificate, not against any certificate embedded in the assertion itself. Accepting a certificate from within the assertion allows an attacker who can forge an assertion to also supply the certificate used to validate it. The service provider must maintain a local copy of the trusted signing certificate or retrieve it from a trusted metadata source, and that certificate must be pinned or validated against a known fingerprint. When the identity provider rotates its signing certificate, the service provider’s metadata must be updated before the old certificate expires, or authentication will fail for all users.

The assertion’s NotBefore and NotOnOrAfter conditions define the validity window. Federal deployments frequently set these windows too wide, sometimes hours, to accommodate clock skew between systems. A validity window longer than a few minutes significantly reduces the effectiveness of replay protection. Clock synchronization across identity infrastructure should be treated as a security control, not just an operational concern.

Audience Restriction and Issuer Verification

The AudienceRestriction element in a SAML assertion specifies which service provider the assertion was issued for. A service provider that does not enforce this check will accept assertions intended for other applications, which means a compromised application in the same federation can be used to gain access to other applications. Issuer verification confirms that the assertion was issued by the expected identity provider. In brokered federation environments where a hub identity provider re-signs assertions, the issuer in the forwarded assertion will be the broker, not the original identity provider. Service providers must be configured to trust the broker as the issuer, and the broker’s signing certificate must be separately governed.

Assertion encryption is distinct from transport encryption. TLS protects the assertion in transit, but an encrypted assertion protects the assertion content from intermediaries who have access to the transport layer, including federation gateways, reverse proxies, and logging infrastructure. Federal environments that route SAML assertions through shared network infrastructure should evaluate whether assertion encryption is warranted based on the sensitivity of the attributes carried in the assertion.

Token Design: Scope, Lifetime, and Audience Binding

Access token design is one of the most consequential and most frequently under-specified aspects of federal OAuth deployments. The scope of an access token defines what the token permits. The audience claim defines which resource server is permitted to accept it. The lifetime defines how long the token remains valid after issuance. All three of these parameters interact, and misconfiguring any one of them expands the blast radius when a token is compromised or misused.

Scope should be defined at the resource server level, not at the client level. Each API or resource should publish the scopes it requires, and the authorization server should issue tokens that contain only the scopes needed for the specific request. Federal deployments that define a small number of broad scopes, such as a single read-write scope for an entire data platform, effectively eliminate the granularity that scope-based access control is supposed to provide. When a token with broad scope is compromised, every resource covered by that scope is exposed.

Audience binding prevents token misuse across resource servers. A token issued for one API should not be accepted by a different API, even if both APIs are operated by the same agency. Without audience binding, a token obtained through a lower-assurance application can be presented to a higher-assurance resource if both are registered with the same authorization server. The resource server must validate the audience claim on every request, not just on initial session establishment.

Access token lifetimes in federal environments are frequently set to match session timeout policies rather than the actual risk profile of the token. A 60-minute access token for an API that processes sensitive data is a 60-minute window for an attacker who has obtained that token. Short-lived access tokens combined with refresh token rotation provide a better security posture. Refresh tokens must be bound to the client that requested them, and the authorization server must invalidate the entire token family when a refresh token is used more than once, which is the signal that the refresh token has been stolen and replayed.

Sender-constrained tokens, implemented through mechanisms such as Demonstrating Proof of Possession or mutual TLS client authentication, bind the token to the specific client that requested it. A bearer token can be used by anyone who possesses it. A sender-constrained token can only be used by the client that holds the corresponding private key or certificate. Federal environments handling sensitive data or operating under high-assurance requirements should evaluate sender-constrained tokens as a control that significantly reduces the value of a stolen access token.

Control	OAuth / OIDC	SAML 2.0	Federal Requirement Basis
Issuer Validation	Required – iss claim against discovery document	Required – Issuer element against metadata	NIST SP 800-63C, RMF IA controls
Audience Restriction	Required – aud claim validated by resource server	Required – AudienceRestriction enforced by SP	NIST SP 800-63C, CISA Zero Trust Maturity Model
Replay Protection	Required – nonce validation, single-use auth codes	Required – assertion ID tracking, validity window	NIST SP 800-63C Section 5.1
Signature Validation	Required – JWT signature against JWKS endpoint	Required – XML signature against pinned cert	NIST SP 800-63C, RMF SC controls
Token / Assertion Encryption	Optional – JWE for sensitive claims	Recommended – EncryptedAssertion for sensitive attributes	Data sensitivity classification, RMF SC-28
Sender Constraint	Recommended – DPoP or mTLS for high-assurance APIs	Not Applicable	NIST SP 800-63C, OMB M-22-09
Key Rotation	Required – JWKS rotation with overlap period	Required – signing cert rotation with SP metadata update	NIST SP 800-57, RMF IA-3 and SC controls

Federation Gateway Placement and Protocol Translation Risk

Federation gateways, sometimes called identity brokers or federation proxies, are components that sit between identity providers and service providers to translate between protocols, aggregate identity sources, or enforce policy. In federal environments, they appear in several common patterns: a cloud identity provider brokering access to on-premises applications, a cross-agency hub that federates multiple agency identity providers into a single trust point, or a commercial identity-as-a-service platform that translates SAML from a legacy system into OIDC tokens for a modern application.

The security problem with federation gateways is that they are trust amplifiers. A gateway that accepts an assertion from an upstream identity provider and issues a new assertion or token to a downstream application is performing a re-signing operation. The downstream application trusts the gateway, not the original identity provider. If the gateway’s signing key is compromised, an attacker can issue arbitrary tokens or assertions to any downstream application that trusts the gateway. The gateway’s key management posture is therefore at least as important as the identity provider’s.

Protocol translation at a gateway also introduces the risk of attribute loss or attribute inflation. When a SAML assertion carrying specific attributes is translated into an OIDC ID token, the mapping between SAML attributes and OIDC claims must be explicitly defined and validated. Attributes that carry authorization-relevant information, such as clearance level, role, or organizational affiliation, must survive the translation accurately. Attributes that should not be forwarded to a downstream application must be explicitly excluded. Without a documented and tested attribute mapping, the gateway may forward more information than intended or drop information that the downstream application requires for access control decisions.

Gateway placement in the network architecture affects both security and availability. A gateway positioned in a DMZ or shared services zone may be accessible to a broader range of clients than intended. A gateway that is a single point of failure for all federated authentication creates a continuity of operations risk that is rarely addressed in system security plans. Redundancy, failover behavior, and the behavior of downstream applications when the gateway is unavailable must be defined before the gateway is deployed, not after the first outage.

Logging at the gateway level must capture more than authentication events. Token exchange requests, scope grants, assertion translations, and policy enforcement decisions all need to be logged with sufficient detail to support incident investigation. A gateway that logs only successful authentications provides no visibility into the token exchange patterns that would indicate a confused-deputy attack or a compromised client credential.

Signing Key Governance and Certificate Lifecycle

Signing keys are the foundation of trust in both OAuth and SAML federation. In OAuth and OIDC, the authorization server publishes its public keys through a JWKS endpoint. Clients and resource servers retrieve these keys to validate token signatures. In SAML, the identity provider’s signing certificate is published in federation metadata and must be imported by each service provider. In both cases, the security of the entire federation depends on the integrity of these keys and the operational discipline applied to their lifecycle.

Key rotation is the most common operational failure point in federal federation deployments. The process requires coordination between the identity provider, the federation gateway if one is present, and every service provider or resource server that validates signatures. In SAML environments, this typically means updating metadata at every service provider before the old certificate expires. In OAuth environments, it means ensuring that clients and resource servers are configured to refresh the JWKS cache frequently enough to pick up new keys before the old keys are retired. Deployments that cache JWKS responses aggressively, or that hardcode public key values rather than retrieving them dynamically, will fail to validate tokens signed with a new key until the cache is manually cleared or the configuration is updated.

Key storage is a separate concern from key rotation. Signing private keys must be stored in hardware security modules or equivalent protected key stores. Storing signing keys in software key stores on general-purpose servers creates exposure through backup processes, snapshot operations, and administrative access paths that are not always covered by the system’s access control model. RMF assessments frequently identify signing key storage as a finding because the system security plan describes the key as protected without specifying the protection mechanism.

Applying Zero Trust principles to signing key governance means treating the key management infrastructure as a high-value target that requires continuous validation of access, not just initial configuration. Who can request a new signing key? Who can approve a rotation? Who can access the HSM or key vault? These questions need documented answers with corresponding access controls, audit logging, and periodic review. In many federal environments, these questions have no documented answer because the key management function was not formally assigned to a team during the initial deployment.

Federation metadata, the documents that describe identity provider and service provider configurations including signing certificates, supported bindings, and endpoint URLs, must be treated as authoritative configuration artifacts. Changes to metadata should go through change management, be stored in version control, and be validated before deployment. Metadata that is manually edited and deployed without review is a common source of federation failures and, in adversarial scenarios, a potential vector for trust manipulation.

Common Mistakes

The most consequential mistakes in federal federation deployments are not configuration errors in the obvious sense. They are architectural decisions made under time pressure that create structural weaknesses that persist for years.

Conflating OIDC with authentication. OIDC provides an identity assertion on top of an OAuth authorization grant. Treating it as equivalent to a direct authentication protocol leads teams to apply authentication-layer controls while leaving authorization-layer controls unconfigured. The result is a deployment where the identity assertion is validated but the underlying grant is not constrained by scope, audience, or lifetime controls appropriate to the resource being accessed.

Accepting assertions without validating all required fields. SAML service provider libraries frequently have permissive defaults. A library configured with minimal settings may validate the signature but not enforce the audience restriction, or enforce the audience restriction but not validate the issuer. Each validation step must be explicitly enabled and tested. Assuming that a library validates everything by default is a reliable path to a finding during an RMF assessment or a penetration test.

Defining scopes at the client level rather than the resource level. When scopes are defined by what a client application needs rather than what a resource server exposes, scope definitions tend to grow broad and remain broad. The result is access tokens that grant more permission than any single operation requires. This is particularly common in environments where the same authorization server supports multiple applications that were onboarded incrementally without a unified scope taxonomy.

Treating the federation gateway as a pass-through. A gateway that is configured to forward assertions or tokens without enforcing its own policy controls provides the appearance of a security boundary without the substance. Every gateway should enforce issuer validation, attribute filtering, scope restriction, and logging independently of what the upstream identity provider has already done. Defense in depth applies to federation infrastructure the same way it applies to network perimeters.

No defined owner for signing certificate rotation. This is the most common sustainment failure in federal federation deployments. The initial deployment team configures the signing certificate and moves on. The certificate is not tracked in the agency’s certificate inventory. No team is assigned responsibility for monitoring its expiration or executing the rotation procedure. The first indication that the certificate has expired is a complete authentication failure for all federated users, often on a weekend or during a high-tempo operational period.

Skipping failure-mode testing. Operational acceptance testing for federation deployments almost always covers the happy path: a user authenticates, receives a token or assertion, and accesses the application. It rarely covers what happens when the identity provider is unavailable, when a token is rejected due to an expired signature, when a replay is detected, or when the gateway fails to translate an attribute correctly. These failure modes need to be tested before the system goes into production, not discovered during an incident.

Logging authentication events but not authorization events. A SIEM that receives authentication success and failure events from the identity provider has visibility into who logged in. It has no visibility into what tokens were issued, what scopes were granted, what token exchanges occurred, or whether any of those exchanges resulted in privilege escalation. Federation-specific logging must capture the full token lifecycle, not just the initial authentication event.

Recommended Federal Approach

The following approach is structured for agencies that are actively deploying or hardening hybrid identity and federation infrastructure. It assumes existing federation is in place and focuses on systematically closing the trust boundary gaps that are most common in federal environments.

Start with a federation trust inventory. Before changing any configuration, document every federation relationship in the environment. For each relationship, capture the protocol in use, the identity provider, the service provider or resource server, the signing certificate and its expiration date, the scopes or attributes exchanged, and the team responsible for each endpoint. This inventory does not need to be elaborate. It needs to exist. Most agencies cannot answer basic questions about their federation topology because no one has ever written it down.

Validate existing controls against the protocol requirements. For each federation relationship in the inventory, verify that the required validation controls are actually enforced. This means testing, not reviewing configuration documentation. Send a token with a mismatched audience and confirm it is rejected. Send an expired assertion and confirm it is rejected. Send a token signed with an untrusted key and confirm it is rejected. If any of these tests pass when they should fail, the control is not functioning as documented.

Establish a signing certificate and key rotation program. Assign a named owner for each signing certificate and JWKS endpoint in the federation inventory. Define a rotation schedule, a rotation procedure, and a testing procedure for each. Integrate certificate expiration monitoring into the agency’s existing certificate management or monitoring infrastructure. The rotation procedure must be tested before the certificate expires, not for the first time during an emergency rotation.

Tighten scope and token lifetime configurations. Review the scope definitions for every OAuth client and resource server. Eliminate scopes that are broader than any documented use case requires. Set access token lifetimes based on the sensitivity of the resource, not on session timeout policies. Enable refresh token rotation and configure the authorization server to detect and respond to refresh token replay. For high-assurance APIs, evaluate sender-constrained tokens as a compensating control.

Harden federation gateway configurations. For each gateway in the environment, verify that it enforces its own validation controls independently of the upstream identity provider. Confirm that attribute mapping is documented, tested, and version-controlled. Confirm that the gateway’s signing key is stored in a protected key store and is included in the rotation program. Confirm that the gateway logs token exchange events with sufficient detail to support incident investigation.

Integrate federation logging into the SIEM. Define the specific log events that federation infrastructure must generate, including token issuance, token exchange, assertion validation failures, replay detection events, and scope grant decisions. Confirm that these events are being forwarded to the SIEM and that detection rules exist for anomalous patterns such as tokens being presented from unexpected IP ranges, assertion IDs being reused, or token exchange requests that result in scope elevation.

Document federation trust boundaries in the system security plan. RMF assessors need to understand how trust is established and validated in the system. The SSP should describe the federation protocols in use, the validation controls applied at each trust boundary, the signing certificate governance process, the token lifetime and scope policies, and the logging posture. This documentation also serves as the baseline for future assessors and for the teams that will sustain the system after the initial implementation team has moved on.

Plan for protocol evolution. SAML is not going away in federal environments in the near term, but OIDC adoption is accelerating. Agencies that are running both protocols simultaneously need a clear picture of which applications are candidates for migration, what the migration dependencies are, and how the federation gateway will be used during the transition period. Protocol coexistence is manageable, but it requires explicit planning. An agency that migrates some applications to OIDC while leaving others on SAML without updating its trust boundary documentation and monitoring coverage has not reduced complexity. It has added a new protocol surface without retiring the old one.