Federation, OIDC & SAML

Understand how identities outside traditional IAM users can obtain AWS access through federation.

Modern AWS environments increasingly rely on external identity systems rather than permanent IAM user credentials. Common patterns include enterprise SAML identity providers, OpenID Connect (OIDC), GitHub Actions, CI/CD systems, workforce federation and other external identity platforms.

Federation can reduce long-lived credential risk, but the trust conditions around federated access become part of the AWS attack surface.

Where to find federation analysis

The current view is named Federation Exposure. Depending on available evidence, the view can display context such as affected entity, entity type, federation type, identity provider and severity.

Use this view when investigating roles trusted by SAML or OIDC identity providers.

How AWS federation changes identity security

With federation, the identity does not necessarily originate as a permanent IAM user.

External Identity
       ↓
Identity Provider
       ↓
SAML / OIDC assertion or token
       ↓
AWS Role Trust
       ↓
Temporary AWS Session
       ↓
AWS Access

This is usually a desirable architecture. The security question becomes: which external identities are trusted to obtain which AWS roles, and under what conditions?

OIDC

OpenID Connect allows AWS roles to trust supported external identity providers. An OIDC trust typically depends on token claims. Relevant concepts include:

• Issuer / provider — which OIDC provider is trusted
• Audience (aud) — the intended token audience
• Subject (sub) — the workload identity context
• Repository / branch / environment — for CI/CD providers

Trust conditions matter because the provider itself may represent a large population of possible identities.

GitHub Actions OIDC

GitHub Actions can use OIDC to obtain temporary AWS credentials without storing a long-lived AWS access key in GitHub. A simplified trust path looks like:

GitHub Workflow
      ↓
GitHub OIDC Provider
      ↓
AWS Role Trust
      ↓
Temporary AWS Credentials
      ↓
Deployment / AWS Actions

This is generally preferable to permanent CI/CD access keys. However, a secure implementation should constrain which workflows are allowed to use the role.

Why the sub condition matters

The OIDC subject identifies the workload context represented by the token. For GitHub Actions, subject conditions can help restrict trust to intended repositories, environments or references.

GitHub OIDC
    ↓
Many repositories / workflows
    ↓
Production Role

Approved repository
    +
Approved branch / environment
    ↓
Production Role

Securitain can identify supported federation patterns where trust appears broader than expected.

Why the aud condition matters

The OIDC audience claim identifies the intended audience for the token. Audience restrictions can help ensure that the role trust applies to the intended token use. A federation trust policy should be evaluated as a complete trust relationship rather than checking only one claim.

Broad repository trust

A CI/CD role may be intended for one repository but configured with trust broad enough to include many repositories. The actual severity depends on the role's privilege, subject and audience restrictions, repository ownership, environment controls, branch protections and AWS role permissions.

SAML federation

SAML is commonly used for workforce access to AWS. A simplified pattern:

Employee
   ↓
Enterprise Identity Provider
   ↓
SAML Assertion
   ↓
AWS Federated Role
   ↓
AWS Session

The resulting AWS risk depends on both identity-provider controls and AWS role configuration. A powerful AWS administrator role exposed through SAML deserves a different level of scrutiny from a narrow read-only role.

Administrative federation

Federation is not inherently risky. But privileged federated roles require strong controls. Questions to investigate include:

• What can the role do?
• Who can receive the role?
• What conditions protect the trust?
• How long can the session last?
• Is the role appropriate for day-to-day activity?
• Does the identity provider enforce appropriate authentication?
• Is the role still required?

Use Effective Permissions, IAM Blast Radius and Privilege Escalation to understand the consequence of the federated role itself.

Session duration

Longer AWS sessions can increase the period during which valid federated credentials remain useful. The correct session duration depends on the access pattern.

CI/CD

Often benefits from relatively short sessions aligned to build or deployment duration.

Human administration

May require a different session duration depending on organizational workflow. Session duration should be evaluated in context — Securitain can surface configurations where duration contributes to risk.

Unused or stale federation relationships

Identity providers and roles can remain configured long after the original integration is no longer required. An unused provider is not automatically dangerous, but stale trust increases unnecessary attack surface and configuration complexity.

Investigate:

• whether the provider is still required
• which roles trust it
• who owns the integration
• whether access has been replaced by another mechanism

Federation vs Cross-Account Access

AWS Account A
      ↓
Role in Account B

External IdP
      ↓
AWS Federated Role

Both can appear in an enterprise access path. Use the appropriate view for each.

Investigating a federation finding

1. 1

   Identify the role

   Determine account, role purpose, privilege and owner.

2. 2

   Identify the provider

   Determine whether it is GitHub OIDC, another OIDC provider, SAML or another supported federation type.

3. 3

   Review trust conditions

   Look for restrictions appropriate to the provider — subject, audience, repository and workload context for OIDC; appropriate conditions for SAML.

4. 4

   Review role permissions

   Use Effective Permissions to determine what the federated role can actually do.

5. 5

   Review consequence

   Use Blast Radius and Privilege Escalation where relevant.

6. 6

   Confirm business purpose

   Identify the application, workflow, team, vendor or workforce group that owns the trust.

7. 7

   Tighten unnecessary access

   Narrow the trust relationship without breaking legitimate authentication.

Evidence and limitations

Federation analysis depends on the identity-provider and trust information available to the Securitain assessment. Actual role assumption depends on IdP configuration, token claims, trust-policy conditions, runtime identity context and AWS authorization.

Related guides