Identity federation is a trust arrangement between an identity provider, which authenticates an identity, and a relying party, which accepts evidence of that authentication. Instead of creating a separate password for every cloud account or application, an organization can use its existing identity system. The relying party validates the evidence and maps the identity to a local account, application session, role, or set of permissions. Federation does not require copying the identity's password into the destination system.
A typical flow begins when an engineer opens a cloud access portal and is redirected to the corporate identity provider. After authentication, potentially including multi-factor authentication, the provider issues a signed assertion or token. The relying party checks the signature, issuer, intended audience, validity period, and other required claims before accepting it. SAML 2.0 and OpenID Connect are common federation protocols. OAuth 2.0 primarily addresses delegated authorization; OpenID Connect adds an identity layer, so an arbitrary OAuth access token should not be treated as proof of user identity.
For workforce access in AWS, IAM Identity Center can connect to an external identity provider and assign users or groups access to accounts through permission sets. Those assignments result in access through IAM roles rather than requiring an IAM user for every employee in every account. SAML handles sign-in federation, while SCIM can provision and synchronize users and groups; provisioning and authentication are different functions. Direct SAML federation to IAM roles is another option, with AWS Security Token Service issuing temporary credentials through AssumeRoleWithSAML.
Federation also applies to applications and systems. A deployment pipeline can present an OpenID Connect token to AWS STS using AssumeRoleWithWebIdentity, avoiding a stored, long-lived AWS access key. Its role trust policy should constrain the trusted provider, audience, and subject, such as a specific repository and deployment environment. Customer-facing applications can use Amazon Cognito user pools to federate sign-in from external providers. Cognito identity pools serve a different purpose: they can exchange supported identity tokens for temporary AWS credentials. For workloads outside AWS, IAM Roles Anywhere uses trusted X.509 certificates to obtain temporary role credentials rather than relying on an interactive human login.
Authentication establishes who the caller is; authorization determines what that caller may do. An IAM role trust policy controls which principals can assume the role and under what conditions. The role's permissions policies define allowed actions, subject to other applicable controls such as service control policies, permissions boundaries, session policies, and explicit denies. A successful federated login therefore does not guarantee access to a resource. Amazon Verified Permissions addresses application authorization using policies and identity context; it is not a replacement for an identity provider or IAM authorization of AWS API calls.
Cross-account role assumption is a related trust pattern, but not every cross-account request involves external identity federation. For a principal in one AWS account to assume a role in another, the caller needs permission to call AssumeRole and the destination role must trust the caller. Some services also support direct cross-account access through resource-based policies without assuming a destination role. Evaluate the actual principal and the applicable identity and resource policies. IAM paths help organize identities and roles, but do not create security boundaries by themselves.
MFA strengthens authentication but is not itself federation. With an external identity provider, enforce MFA there and verify how authentication assurance is represented and checked downstream. Do not assume that IAM MFA condition keys automatically reflect MFA performed by an external provider. Likewise, single sign-on is a user experience that federation can enable, not a synonym for every federation deployment.
Federation reduces password duplication and long-lived credential exposure, but concentrates risk and availability dependencies in the identity provider and trust configuration. Restrict accepted issuers and claims, protect signing keys, rotate certificates safely, use suitable session durations, and preserve attributable session identities in audit logs. Disabling a user at the provider does not necessarily invalidate already-issued application sessions or AWS temporary credentials immediately. Troubleshooting should distinguish failed authentication, invalid assertions, failed role assumption, and denied resource access; common causes include expired certificates, clock skew, audience mismatches, incorrect claim mappings, missing assignments, and restrictive policies.
Amazon Cognito