Why do attacker-controlled OIDC providers create persistence risk in AWS even without exploiting a software vulnerability?

How a Trusted OIDC Provider Becomes a Persistence Mechanism in AWS

In AWS, the issue is not whether the provider can break cryptography. The issue is that a configured OIDC provider is part of the trust boundary, so any token it signs can be exchanged for AWS credentials if the role trust policy accepts it. That makes the provider itself a durable access path, especially when trust conditions are broad or poorly scoped.

Once a role trusts an issuer, the attacker does not need a software flaw in AWS. They need only control the issuer, or the issuer’s signing material, long enough to keep minting claims that satisfy the role assumption conditions. That is why the persistence risk lives in the trust relationship and not in protocol correctness.

In practice, this behaves like delegated access that can be renewed on demand. A malicious provider can issue fresh tokens after detection, credential cleanup, or normal rotation activity, which means the defender must treat the provider as a standing control dependency. Identity Provider and SSO Security Guide is a useful companion for understanding how federation trust, token signing, and provider hardening shape that boundary.

Why Broad Trust Policies Turn Federation Into Repeatable Access

The persistence condition is created by scope, not by the OIDC protocol itself. If the AWS role trust policy allows a wide issuer, audience, or claim pattern, then a compromised provider can continue presenting valid-looking assertions that AWS will accept as proof of trust.

That broadness matters because it usually outlives the initial incident response. Even if one token is revoked or one session expires, the attacker can simply mint another token as long as the provider remains trusted and the role condition still matches. OpenID Connect Core 1.0 explains the identity-token model that AWS is relying on, while OAuth 2.0 and OpenID Connect Guide for Identity Teams provides the practical trust and token context for how those assertions are used.

The control failure is governance drift: teams often validate that the provider is legitimate once, then forget that the trust policy can make every future token equally acceptable. When the trust relationship is not narrow enough, the attacker does not need persistence malware or a backdoor. The federation path is the backdoor.

For cloud operators, the same pattern appears wherever external identity is allowed to assume cloud roles, so the safest mental model is that the provider is a privileged upstream control plane. IAM and IGA Basics helps anchor the distinction between authentication, authorization, and entitlement governance, which is exactly where this failure emerges.

What Practitioners Should Check Before They Trust an OIDC Federation Path

Do not judge this risk only by whether the provider is “approved.” Judge it by the exact claims that AWS requires, the audiences accepted, and whether the role can be assumed from more than one issuer or environment. A trust policy that is too permissive can turn a single compromised provider into repeated AWS access across accounts or roles.

What to verify: the provider’s signing key ownership, the claim conditions in each trust policy, the session duration, and whether one compromised issuer can reach multiple roles. Also verify that decommissioned or test providers are removed quickly, because stale trust relationships are a common way persistence survives cleanup. Identity Provider and SSO Security Guide and OAuth 2.0 and OpenID Connect Guide for Identity Teams both support that review by showing where federation controls usually fail.

What good looks like: each AWS trust policy binds tightly to one issuer, one intended audience, and only the minimal claims needed for the workload. The provider is monitored like a high-value control point, because if it is abused, every downstream assumption becomes suspect.

Risk and Threat Considerations

Attacker-controlled OIDC providers create persistence risk because they let an adversary repeatedly re-enter AWS through a trusted federation path without needing to exploit code in the platform. The danger is durable trust abuse: if the issuer remains trusted and the role conditions remain broad, the attacker can keep obtaining temporary credentials even after individual tokens or sessions are cleaned up.

Failure mechanism: A compromised or malicious identity provider mints valid assertions that satisfy the AWS role trust policy, so the attacker can re-assume the role whenever needed. The persistence survives as long as trust in that provider survives.

Impact: The attacker gains a repeatable access channel for credential refresh, lateral movement, and delayed re-entry, which makes containment harder than a one-time credential theft event.

Practitioner Guidance

What to prioritise: Treat the OIDC provider and the AWS role trust policy as one control surface, not two separate settings. If the provider can still issue tokens and the role still trusts those claims, the attacker still has a path back in.

What to verify: Confirm that every trust policy is narrowed to a specific issuer, audience, and claim set, and that no role trusts a provider more broadly than the workload requires. Also verify that provider key rotation, revocation, and deprovisioning are operationally owned, because persistence often survives where cleanup is slow.

Practitioner takeaway: The real question is not whether AWS accepts the token, but whether the trust policy makes that token a reusable access right after compromise.

Related resources from NHI Mgmt Group

• Why do non-human identities create compliance risk even when policies exist?
• Why do AWS permissions create account compromise risk even without malware?
• Why do leaked AWS access keys create immediate account risk even before an attacker uses them?
• Why does a publicly accessible endpoint create risk even when no software vulnerability is present?