How do you let a contractor from another company access your AWS server for just one afternoon, without creating them a permanent user account and without giving them a password that could be stolen? This is the exact problem that identity federation and temporary credentials solve for cloud security professionals. For the SCS-C02 exam, understanding this mechanism is critical because it moves security away from long-lived, static passwords and towards dynamic, short-lived access that automatically expires, drastically reducing the blast radius if credentials are leaked.
Jump to a section
A simple way to picture IAM Identity Federation and Temporary Credentials
Have you ever been handed a hotel key card that only works for one night, and only for your room and the gym, not the executive suite or the staff pantry?
That key card is a perfect picture of temporary credentials. You arrive at the hotel lobby (the AWS account). You show your passport and booking confirmation (you authenticate via an identity provider, like your company's login system). The hotel clerk doesn't give you a permanent master key that opens every door forever. Instead, they create a plastic key card that expires at checkout time (a temporary, time-limited credential). That card lets you into only the places you need: your room, the breakfast hall, the pool. It cannot open the manager's office or the boiler room.
Now imagine the hotel runs a conference. You are an attendee (a user from another company). The hotel doesn't know you personally, but they trust the conference organiser's badge (federation). They look at your badge, see it is valid, and issue you a day-pass key card (temporary credential) based on that external trust. You never get a permanent hotel key. Your access vanishes when the conference ends. That is identity federation and temporary credentials: relying on an external identity source to grant short-lived, scoped access to resources you are not a permanent member of.
Let us start with a foundational idea. In AWS, an IAM Role (Identity and Access Management Role) is an identity that you can assume, but it does not have any long-term credentials attached to it. Think of a role like a jacket hanging in a cloakroom. Anyone can put on that jacket temporarily, but the jacket itself is not owned by any one person. When you 'assume a role', AWS gives you a temporary set of credentials that work only for a short period (usually between 15 minutes and 12 hours). After that time, those credentials become invalid. This is fundamentally different from an IAM User, which has a username and a password or access keys that last until you manually change or delete them.
Now, what is identity federation? Federation is a mechanism that allows an external identity system (like your corporate Microsoft Entra ID, or even a social login such as 'Sign in with Google') to grant access to AWS resources. Instead of creating a separate IAM user for every single employee, you configure a trust relationship between AWS and your external identity provider (IdP). When a user logs into the IdP (for example, entering their corporate credentials), the IdP sends a token (a cryptographically signed piece of data) to AWS. AWS verifies this token against a configured 'identity provider' resource (like an IAM SAML provider) and, if valid, issues back temporary credentials via the AssumeRoleWithSAML or AssumeRoleWithWebIdentity API calls.
Why does this matter? Imagine a company with 10,000 employees. Managing 10,000 IAM users, each with their own password and access keys, is a security and operational nightmare. Federation means the company manages access in one central directory (Microsoft Entra ID, Okta, etc.) and that directory tells AWS who someone is. The employee never touches an AWS password.
There are three main scenarios you must know for the exam.
First, SAML 2.0 federation: commonly used with corporate directories like Microsoft Entra ID or Okta. A user accesses a corporate portal, authenticates with their corporate password, and the portal forwards a SAML assertion to AWS. AWS then calls the AssumeRoleWithSAML API to get temporary credentials.
Second, Web Identity Federation: used for mobile apps or websites that let users sign in with public identity providers like Login with Amazon, Facebook, Google, or any OpenID Connect (OIDC) compatible provider (including Amazon Cognito). The app gets an identity token from the social provider, then calls AssumeRoleWithWebIdentity to exchange it for AWS temporary credentials.
Third, cross-account access: this is not federation in the strict sense of using an external IdP, but it uses roles and temporary credentials. You create a role in Account A and grant Account B permission to assume it. Users in Account B can then 'switch roles' and receive temporary credentials to work in Account A without creating a new IAM user there.
The core mechanics are always the same. A request is made to the AWS Security Token Service (STS). STS is a global web service that issues temporary, limited-privilege credentials. The user (or application) requests credentials by calling an API like AssumeRole, GetFederationToken, or AssumeRoleWithSAML. STS checks the policies: the permissions policy attached to the role (what the role is allowed to do) and any policy attached to the user or session (what the requester is allowed to delegate). The effective permission is the intersection of these policies. STS then returns three pieces of data: an Access Key ID, a Secret Access Key, and a Session Token. The Session Token is the secret sauce. You must include it in every request to AWS while those credentials are valid. Once the token expires, those keys become useless.
The old way of doing things was to create long-lived access keys for IAM users, embed them in application configuration files, and rotate them manually every 90 days. Federation and temporary credentials replace that with a system where credentials are generated on demand, expire automatically, and can be revoked instantly by removing the trust relationship with the identity provider.
Step 1: Configure the Identity Provider in AWS
Navigate to IAM > Identity Providers. Create a new provider (SAML or OIDC). Upload the metadata document or enter the provider's URL and thumbprint. This tells AWS which external system it should trust for authentication.
Step 2: Create an IAM Role with a Trust Policy
Create a new role of type 'Web Identity' or 'SAML 2.0 Federation'. Define the trust policy to allow the identity provider you just created to call sts:AssumeRoleWithSAML or sts:AssumeRoleWithWebIdentity. This is the crucial security gate that permits the IdP to request credentials on behalf of a user.
Step 3: Attach Permissions Policies
Attach one or more managed or inline policies to the role. These define what the federated user can do (e.g., read S3 buckets, launch EC2 instances). Remember: the user gets permissions equal to the intersection of the role's permissions and any SCPs in the account.
Step 4: Configure the External Identity Provider
In your IdP (e.g., Microsoft Entra ID), create an application registration for AWS. Configure attribute mappings and role assignments. Map Microsoft Entra ID groups to the IAM role ARN. This step tells the IdP which AWS role to request for which users.
Step 5: User Authenticates and Assumes the Role
The user logs into the IdP (e.g., via a corporate portal). The IdP authenticates the user and sends a SAML assertion or OIDC token to AWS. AWS verifies the token against the provider, then calls STS to issue temporary credentials. The user gains access to AWS resources.
You are a security engineer at 'FinServ Corp', a financial firm with 500 employees, all using Microsoft Entra ID to log into their laptops and internal apps. The company is migrating a critical application to AWS and needs the development team to access an S3 bucket containing transaction logs.
You do not create 500 IAM users. Instead, you set up a SAML 2.0 federation between AWS and Microsoft Entra ID. Here is exactly what you do step by step:
Log into the AWS Management Console and navigate to IAM > Identity Providers. You create a new provider of type 'SAML', upload the metadata XML file provided by Microsoft Entra ID. This tells AWS to trust any SAML token issued by that specific directory.
Create an IAM Role called 'DeveloperS3Access'. Attach a policy that allows read and list access to the specific S3 bucket. Set the trust policy of this role to allow the SAML identity provider you just created to call sts:AssumeRoleWithSAML. This is the crucial step: the role trusts the identity provider.
In Microsoft Entra ID, configure the application registration for AWS. Map your Microsoft Entra ID groups (e.g., 'Developers') to the AWS IAM Role ARN. Now, when a developer logs into the Microsoft Entra ID portal, they see a tile called 'AWS Console'.
The developer clicks that tile. Behind the scenes, Microsoft Entra ID authenticates them, generates a SAML assertion (a digitally signed document that contains their identity and group memberships), and sends it to the AWS sign-in endpoint.
AWS receives the SAML assertion, verifies the signature against the IdP you configured in step 1, and then calls the AWS STS AssumeRoleWithSAML API. STS checks the trust policy of the DeveloperS3Access role. Because the developer's group membership matches, STS issues temporary credentials: an Access Key ID, Secret Access Key, and Session Token, valid for one hour.
The developer is now redirected into the AWS console with a federated identity. They never typed an AWS password. Their session expires in exactly one hour. If they leave the company next week, you simply disable their Microsoft Entra ID account, and they instantly lose all ability to get new temporary credentials.
For programmatic access (e.g., a script run by a CI/CD tool like Jenkins), you would use the same role but request credentials via the AWS CLI. The Jenkins server would call AssumeRoleWithSAML (or use a more modern approach called 'AWS IAM Roles Anywhere' for on-premises servers that are not in AWS). The key principle is the same: the server never stores a permanent AWS key. It gets a temporary one that expires.
Another common real-world task is setting up cross-account access. Imagine FinServ Corp acquires 'DataStartup Inc'. DataStartup has an S3 bucket full of customer data that FinServ needs to analyse, but the bucket is in DataStartup's own AWS account. FinServ does not want to copy all the data. Instead, the FinServ security engineer creates an IAM role in their own account, and the DataStartup engineer creates a cross-account role with a trust policy that specifies FinServ's root account or a specific FinServ role. The FinServ engineer then 'switches roles' in the console or uses the AWS CLI with the --role-arn parameter to assume the DataStartup role, receiving temporary credentials that allow direct S3 access. The whole process uses temporary STS credentials and never requires sharing static access keys between companies.
The SCS-C02 exam will test your understanding of identity federation and temporary credentials heavily. Expect at least five to eight questions across the exam covering this topic. The exam loves to test the following:
The difference between an IAM Role and an IAM User: this is the most common beginner trap. An IAM User has long-term credentials (password, access keys). An IAM Role is assumed and gives temporary credentials via STS. If a question describes a scenario where an employee only needs access for a few hours, the correct answer will always involve a role and federation, not creating an IAM user.
The purpose of the AWS Security Token Service (STS): you must know that STS is the service that issues temporary credentials. Know the API calls: AssumeRole, GetFederationToken, AssumeRoleWithSAML, AssumeRoleWithWebIdentity. The exam will ask which API call is appropriate for a given scenario. For example, if a mobile app lets users log in via Facebook, the correct API is AssumeRoleWithWebIdentity. If a company uses Microsoft Entra ID, the correct API is AssumeRoleWithSAML.
The difference between a role's trust policy and its permissions policy: the trust policy defines who (which principal) is allowed to assume the role. The permissions policy defines what actions that role can perform. A common exam trap is giving a role a very permissive S3 policy but forgetting to set the trust policy to allow the identity provider to assume it. The result is that nobody can use the role.
The session token: the exam will test that all API calls made with temporary credentials must include the session token. If a question describes an application that gets temporary credentials but does not include the session token in subsequent requests, the requests will fail.
The maximum session duration for a role: the default is 1 hour, but you can set it up to 12 hours for roles assumed via the console or CLI. For SAML or web identity federation, the maximum is also 12 hours. The exam may include a question where an application needs a session longer than 12 hours and the correct answer is to re-assume the role to get fresh credentials.
Revocation of access: a key exam trap is knowing how to revoke access for a federated user. You cannot delete an IAM user that does not exist. Instead, you disable the user in the external identity provider (e.g., Microsoft Entra ID) or you modify the trust policy or permissions policy of the role.
The 'PassRole' permission: the exam will test that when you allow a user to pass a role to an AWS service (e.g., EC2), you must grant them the iam:PassRole permission. Without it, even if they can assume the role themselves, they cannot assign it to a compute resource.
Differences between SAML 2.0 and OpenID Connect (OIDC): SAML uses XML assertions, OIDC uses JSON web tokens (JWT). Amazon Cognito is a common service used with OIDC. The exam may ask which protocol to use for a mobile app.
The 'Service Control Policy' (SCP) effect: if an SCP in the organisation denies a specific action, even a federated user with a permissive role cannot bypass the SCP. The exam loves testing that SCPs act as an overarching guardrail.
IAM roles have no long-term credentials; they are assumed to receive temporary credentials from AWS STS.
Federation delegates authentication to an external identity provider (like Microsoft Entra ID) while authorisation stays in AWS via IAM roles.
All API calls made with temporary credentials must include the session token, or they will be rejected.
Revocation of federated user access is done at the identity provider, not by deleting an IAM user (because no IAM user exists).
The maximum session duration for a role assumed via the console or CLI is 12 hours, after which you must re-assume the role.
Cross-account access between AWS accounts always uses roles and temporary credentials, never long-term access keys.
These come up on the exam all the time. Here's how to tell them apart.
IAM User
Has long-term credentials (password, access keys).
Permanent identity until manually deleted.
Cannot be used for federation with external IdPs.
IAM Role
Has no credentials; issues temporary STS credentials when assumed.
Temporary identity; session expires automatically.
Used for federation, cross-account access, and service access.
Temporary Credentials (STS)
Include a session token that must be sent with each request.
Expire automatically (15 min to 12 hours).
Cannot be stored in plain text for reuse; must be re-requested.
Long-Term Access Keys (IAM User)
No session token required.
Do not expire until manually rotated or deleted.
Often stored in configuration files, creating a security risk.
SAML 2.0 Federation
Uses XML-based SAML assertions.
Commonly used with enterprise directories (Microsoft Entra ID).
User authenticates via a corporate portal or SSO.
Web Identity Federation (OIDC)
Uses JSON Web Tokens (JWT).
Commonly used with social IdPs (Google, Facebook) or Amazon Cognito.
User authenticates via a mobile app or web browser pop-up.
AssumeRole API
Used to assume a role for a federated user or a service.
Trust policy of the role controls who can assume it.
Returns temporary credentials with the role's permissions.
GetFederationToken API
Used to give a federated user a token based on a custom policy.
No role needed; you supply a policy inline.
Returns temporary credentials scoped to the inline policy you provide.
Mistake
Temporary credentials from STS are equivalent to long-term IAM user credentials; you can just reuse them indefinitely.
Correct
Temporary credentials include a session token that expires. You cannot refresh them. You must call STS again to get a new set of credentials. Reusing expired credentials results in an 'ExpiredTokenException'.
People are familiar with passwords that last forever. The concept of a credential that self-destructs is counterintuitive. Beginners assume they can save the Access Key ID and Secret Access Key and use them like permanent keys.
Mistake
Setting up federation means you no longer need IAM roles at all; the external identity provider replaces them.
Correct
Federation does not replace IAM roles. You still create an IAM role to define the permissions. The identity provider only handles authentication (who you are), while the IAM role handles authorisation (what you can do). Both are required.
The word 'federation' sounds like it does everything. Beginners think the external IdP magically grants AWS access without needing any AWS-side configuration. They miss that you must configure a trust relationship and a role.
Mistake
If you federate with Microsoft Entra ID, you can revoke a user's AWS access instantly by removing their IAM role in AWS.
Correct
You must revoke the user in Microsoft Entra ID (the IdP). The IAM role is just a permission template. If you delete the role in AWS, all federated users who relied on that role lose access. But for individual revocation, you disable the user in the IdP. AWS has no record of that user to delete.
Beginners think 'users' live in IAM. But with federation, the user accounts live outside AWS. They naturally assume they can manage everything from the AWS console.
Mistake
You can assign a role directly to a user in the external identity provider without creating any role in AWS first.
Correct
The external IdP does not have the AWS role. The IdP only maps groups to role ARNs (Amazon Resource Names). The role must first exist in AWS with a trust policy that allows the IdP to assume it. The IdP merely tells AWS 'this user belongs to the Developers group, which should map to this ARN.'
This comes from confusion about how the 'mapping' works. Beginners think the IdP creates the role. In reality, the role creation and trust policy must be done in AWS first.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, absolutely. That is the primary purpose of federation. You configure a trust relationship with an external identity provider, and that provider authenticates the user. They never get an IAM user in your account.
An IAM user is a permanent identity with long-term credentials (password or access keys). An IAM role is an identity without credentials that can be assumed temporarily to receive STS temporary credentials. Roles are used for federation, cross-account access, and services like EC2.
The default is 1 hour for roles assumed via the console, but you can configure a duration from 15 minutes up to 12 hours. For federation with SAML or web identity, the maximum is also 12 hours. After expiry, you must request new credentials.
The session token is a unique identifier returned alongside the Access Key ID and Secret Access Key when you assume a role. You must include it in every AWS API request. Without it, AWS will reject the request because the credentials are not recognised as valid temporary ones.
Yes, you can create multiple identity providers in IAM (multiple SAML providers, multiple OIDC providers) and map each one to different roles. A user from IdP A can assume Role A, and a user from IdP B can assume Role B, all within the same AWS account.
The user will be unable to obtain new temporary credentials because the IdP will reject their authentication attempt. Any existing temporary credentials will remain valid until they expire (up to 12 hours). For immediate revocation, you must also modify the IAM role's trust policy or add an explicit deny.
You've finished IAM Identity Federation and Temporary Credentials. Continue through the SCS-C02 study guide to build a complete picture of the exam.
Done with this chapter?