Give people temporary access—not permanent keys
Separate employees, workloads, partners, and application users, then give each population the right temporary identity path.
LESSON GOALS
By the end, you can
- Match workforce, workload, partner, and application identities to the right access path.
- Separate who may assume a role from what the resulting session may do.
01
First identify who is signing in
Do not start by choosing an identity service. First classify the caller. Employees are workforce identities. Software running on AWS is a workload identity. A vendor using its own AWS account is a partner identity. Shoppers using your application are consumer identities.
These populations have different owners and lifecycles. Employees may already live in a corporate identity provider. Workloads should receive credentials from their compute role. Partners need cross-account trust. Application users need application tokens and sometimes narrowly scoped temporary AWS credentials.
AWS IAM Identity Center is for workforce access to AWS accounts and applications. Amazon Cognito user pools are application-user directories and token issuers; identity pools can exchange supported identities for temporary AWS credentials. Cognito is not a replacement for workforce account administration.
Write down the source of truth for each population. A corporate directory may own employee status, while the application database owns customer profiles. Keeping those sources separate makes removal predictable: employee departure changes workforce access, while closing a shopper account changes only application access.
Also ask what credential the caller actually needs. A person opening the AWS console needs an account session. An application user may need only an application token. Issuing AWS credentials when an application token is enough enlarges the permission boundary for no benefit.
02
Prefer sessions that expire
Connect Identity Center to the authoritative workforce identity source when corporate groups, MFA, joining, role changes, and offboarding must remain central. Map those groups to permission sets for the required accounts instead of creating an IAM user in every account.
AWS Security Token Service, or STS, issues temporary credentials for role sessions. For workloads, use the role supplied by the compute environment rather than storing an access key. For a partner, use a dedicated cross-account role instead of emailing a shared key.
A third-party external ID can help prevent the confused-deputy problem when a vendor assumes roles for several customers. It supplements a trusted principal and narrow permissions; it is not a password and does not replace either one.
Temporary does not mean ungoverned. Choose the shortest practical duration, restrict the role to the required resources, and record who created each session. Rotation is handled by issuing a new session, but authorization still depends on correct trust and permissions.
Avoid copying credentials into source code, configuration files, chat, or tickets. A workload role and workforce federation remove that distribution problem by letting the trusted environment obtain a bounded session when it is needed.
03
Separate trust from permission
A role has two different questions. Its trust policy answers “who may create a session?” Its permission policies answer “what may that session do?” Cross-account role assumption normally needs both caller permission for sts:AssumeRole and matching trust in the target role.
Set a session duration that fits the task, preserve source identity or session tags where useful, and log the resulting session principal. Disabling a corporate user prevents new sessions, but credentials already issued follow their lifetime and available revocation controls. Test expiration and removal, not only successful sign-in.
Use a resource policy instead of role assumption only when one supported resource can express the exact direct grant you need. If the caller becomes a large consumer population, move to application identity rather than stretching workforce federation to fit.
During offboarding, trace the complete path: directory user, group membership, permission-set assignment, account role, active session, and logged principal. Removing only one copied permission may leave another assignment intact. The path also shows whether a vendor entered through its dedicated role rather than an employee path.
A successful sign-in is only half the test. Verify that the session expires, that a removed user cannot start a new session, and that the role cannot perform a nearby forbidden action. These checks prove both lifecycle control and least privilege.
DECISION TABLE
Compare the architecture constraints
| requirement | choose | because | reject |
|---|---|---|---|
| Employees use a corporate IdP across many AWS accounts | Identity Center and permission sets | Workforce lifecycle stays central and sessions are temporary. | An IAM user in every account. |
| Code running on AWS calls AWS APIs | A workload role | The compute environment supplies rotating credentials. | A stored human access key. |
| A vendor AWS account needs temporary access | A dedicated cross-account role | Trust, permission, duration, and attribution remain explicit. | A shared IAM user or emailed key. |
GUIDED WORKED SCENARIO
Reason from the stated constraints
This is a guided example, not a question to memorise. The knowledge check uses new situations to test the same reasoning.
Six hundred employees use a corporate SAML identity provider across 18 AWS accounts. A vendor needs a four-hour read-only production audit from its own AWS account. No one may receive a copied access key.
Requirements
- Keep the corporate identity provider authoritative.
- Centralize workforce offboarding and account assignments.
- Require MFA for privileged employees.
- Give the vendor a temporary, attributable, read-only session.
- Allow rapid removal of future access.
Reasoning path
- Classify employees as workforce and the vendor as a partner.
- Connect the workforce identity source to Identity Center and map groups to permission sets.
- Create a narrow production role trusted to the vendor principal and require the agreed external ID.
- Set and log the temporary session, then test expiration and revocation.
Why it wins
- Employee lifecycle remains in one authoritative directory.
- Vendor trust and production permission can be changed independently.
- Both paths use attributable temporary sessions instead of copied keys.
Why the alternatives lose
Credential/offboarding sprawl.
Becomes correct when: Tiny non-federatable exception.Application customer identity, not account workforce.
Becomes correct when: Retail application users.Poor attribution/rotation and leakage risk.
Becomes correct when: Only a narrowly managed legacy exception.INTERACTIVE ARCHITECTURE VISUAL
Separate role trust from session permission
A vendor needs a two-hour audit session. Both sides of role assumption must match before session permissions exist.
× Request stopsThe target role trusts a different principal, so STS creates no session.
Read the diagram as text
Follow two paths: employee identity provider → Identity Center → permission set → temporary account session; vendor account → target-role trust → STS session → read-only production actions.
KNOWLEDGE CHECK
Answer one question at a time
Pass every question to complete this lesson. Each answer includes reasoning before you continue.
KEY TERMS
Glossary
- Federation
- Using an existing identity source to obtain access without creating a separate long-lived AWS identity.
- Workforce identity
- An employee or contractor who needs access to AWS accounts or business applications.
- Workload identity
- Software that receives permissions through its compute environment rather than a stored human key.
- Partner identity
- An external organization or AWS account that needs controlled access to your resources.
- Consumer identity
- A customer who signs in to your application rather than administering your AWS accounts.
- IAM Identity Center
- AWS workforce access for accounts and applications, commonly connected to a corporate identity source.
- AWS Security Token Service (STS)
- The AWS service that issues temporary credentials for role sessions.
- Trust policy
- The role policy that states who may create a session by assuming the role.
- Permission policy
- A policy that states which actions the resulting role session may perform.
- External ID
- A value that supplements third-party role trust to reduce confused-deputy risk; it is not a password or principal.
PRIMARY SOURCES
Verify the claims
- primaryWhat is IAM Identity Center?aws-idc-overview · retrieved 2026-07-29
- primaryTemporary security credentials in IAMaws-iam-temporary-security-credentials · retrieved 2026-07-30
- primarySecurity best practices in IAMaws-iam-security-best-practices · retrieved 2026-07-30
- primaryCross account resource access in IAMaws-iam-cross-account-resource-access · retrieved 2026-07-30
- primaryAmazon Cognito user poolsaws-cognito-user-pools · retrieved 2026-07-30
- primaryAmazon Cognito identity poolsaws-cognito-identity-pools · retrieved 2026-07-30
- primaryIam External Idaws-iam-external-id · retrieved 2026-07-30