IAM Identity Center (SSO)

Most real companies do not run on a single AWS account. They run on many: one for production, one for staging, one for the data team, and so on. IAM Identity Center (formerly called AWS Single Sign-On, or AWS SSO) is the AWS service that gives your people one login to reach all of those accounts. Instead of creating a separate username and password in every account, each person signs in once and then picks which account and role they want to use. This is the modern, recommended way to give humans access to AWS.

What IAM Identity Center is

IAM Identity Center is a service that connects an identity source (where your user list lives) to your AWS accounts. SSO stands for “single sign-on” — one set of credentials unlocks many systems.

The identity source can be:

The built-in directory that Identity Center provides (good for small teams, no extra setup).
An external identity provider (IdP) — a system that already stores your company logins, such as Okta, Microsoft Entra ID (formerly Azure AD), or Google Workspace.

Once connected, a user opens a personal web page (the AWS access portal), signs in once, and sees a tidy list of every account and role they are allowed to use.

Identity Center is free. You only pay for the AWS resources people use after they sign in. There is no per-user charge for the service itself.

Permission sets — the key idea

A permission set is a reusable bundle of permissions (built from IAM policies) that you assign to a group of people in one or more accounts. Think of it as a job template: “Developer”, “ReadOnlyAuditor”, “BillingAdmin”.

When you assign a permission set to a user in an account, Identity Center automatically creates a matching IAM role in that account behind the scenes. The user assumes that role when they sign in. You define the permission set once and apply it across dozens of accounts.

Concept	What it is	Example
Identity source	Where users/groups are stored	Built-in directory, Okta, Entra ID
Permission set	A reusable permission template	`DeveloperAccess`, `ReadOnly`
Assignment	Linking a user/group + permission set + account	”Dev group gets DeveloperAccess in the Staging account”

Why this beats IAM users per account

The old approach was to create an IAM user (a long-lived identity with a password and access keys) inside every account for every person. That does not scale.

	IAM users per account	IAM Identity Center
Logins per person	One per account	One, total
Credentials	Long-lived passwords and access keys	Short-lived, auto-expiring
Offboarding	Delete the user in every account	Disable once at the source
Best for	A single account, break-glass only	Any multi-account or team setup

For human access, Identity Center should be your default. Reserve IAM users only for rare edge cases like a single emergency “break-glass” account.

The big gotcha: short-lived credentials

This is the part people miss. Identity Center does not hand out permanent access keys. When you sign in, it issues temporary credentials that expire (often after 1 to 12 hours, configurable). This is a security win — leaked credentials stop working quickly — but it changes how you use the CLI.

You must stop using aws configure to paste in long-lived access keys. Instead, configure an SSO profile and refresh it with aws sso login.

Set up an SSO profile (AWS CLI v2)

aws configure sso

The wizard asks for your portal URL and Region, then lets you pick an account and role. It writes a named profile to ~/.aws/config.

Output:

SSO session name (Recommended): devcraftly
SSO start URL [None]: https://d-9067abc123.awsapps.com/start
SSO region [None]: us-east-1
Attempting to automatically open the SSO authorization page in your default browser.

The only AWS account available to you is: 111122223333
Using the account ID 111122223333
The only role available to you is: DeveloperAccess
Using the role name "DeveloperAccess"

CLI default client Region [us-east-1]:
CLI default output format [json]:
CLI profile name [DeveloperAccess-111122223333]: dev

To use this profile, specify the profile name using --profile, as shown:
aws s3 ls --profile dev

When the temporary credentials expire, you do not reconfigure — you just log in again:

aws sso login --profile dev
aws s3 ls --profile dev

Never run aws configure and paste an access key for a human user. Long-lived keys are the #1 source of AWS credential leaks. SSO profiles refresh automatically and leave nothing permanent on disk.

Setting it up in the console

Open the IAM Identity Center console. (It must be enabled in your AWS Organizations management account.)
Choose Enable. AWS sets up the service for your organization.
Under Settings, pick your identity source: keep the default directory or choose External identity provider to connect Okta/Entra ID.
Go to Users (or Groups) and create or sync your people.
Go to Permission sets > Create permission set. Pick a predefined one (like ReadOnlyAccess) or build a custom one from policies. Set the session duration (e.g. 4 hours).
Go to AWS accounts, select the target accounts, choose Assign users or groups, pick the group, and pick the permission set.

The CLI equivalent

You manage assignments with the sso-admin API. First find your Identity Center instance:

aws sso-admin list-instances