Single Sign-On (SSO)

Single Sign-On (SSO) allows users to authenticate once and gain access to multiple AWS accounts and business applications. In AWS, this is implemented through IAM Identity Center (formerly AWS SSO), which provides a user portal where users can see and access all accounts and applications they are authorized for.

Key Features

• Centralized user management with built-in directory or external IdP (Active Directory, Okta)
• Permission Sets - reusable collections of policies assigned to users/groups per account
• Multi-account access from a single portal
• Integration with business applications (Salesforce, Slack, etc.) via SAML
• Temporary credentials - no long-term access keys needed

How It Goes Wrong in Practice

The most common failure is not a broken login flow, it is over-permissioning through convenience. A team stands up IAM Identity Center, creates one AdministratorAccess permission set, and assigns it to everyone across every account because "we will refine it later". Later never comes. The result is single sign-on to full administrative rights everywhere, which turns any single phished workforce credential into organization-wide admin. Permission sets should mirror job functions: a read-only set for analysts, a power-user set without IAM write access for developers, and a tightly held admin set with a short session duration.

The second pattern is the forgotten parallel path. Identity Center becomes the official door, but the old IAM users with long-lived access keys are never deleted. Attackers do not care which door is official; they target the unmonitored one. An SSO migration is only finished when the legacy IAM users are inventoried, their keys deactivated, and console passwords removed.

Session duration is the third lever people ignore. Each permission set has a session duration, 1 hour by default and configurable up to 12 hours. Identity Center provisions IAM roles in each assigned account for each permission set and enforces that duration. Twelve-hour admin sessions are convenient, and they also give a stolen session token a twelve-hour lifetime. Keep privileged permission sets short.

A Practical Check

Inventory your permission sets and ask, for each one, who holds it and whether it is broader than the job requires. First find your Identity Center instance, then list the permission sets:

aws sso-admin list-instances

aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-EXAMPLE1234567890

The first command requires no arguments and returns the InstanceArn and IdentityStoreId you need for every other sso-admin call; both commands are read-only, so they are safe to script into a recurring access review. From there, review assignments in the console under IAM Identity Center, Multi-account permissions, AWS accounts, where you can see which users and groups hold which permission set in each account.

Frequently Asked Questions

Is AWS SSO the same thing as IAM Identity Center? Yes. AWS renamed the AWS Single Sign-On service to AWS IAM Identity Center. The CLI namespaces still reflect the old name in places (sso and sso-admin), which is why commands look the way they do.

How long do SSO sessions to AWS accounts last? The session duration is set per permission set. New permission sets default to 1 hour, and you can configure between 1 and 12 hours. When you change the value, Identity Center reprovisions the permission set in every account that uses it, so the new duration applies everywhere. The IAM roles Identity Center creates are configured with a 12-hour maximum session duration, and by design only Identity Center users can assume them, which keeps the permission set's setting authoritative.

Does IAM Identity Center replace IAM? No. Identity Center sits on top of IAM: for every permission set assignment it creates and manages an IAM role in the target account, and IAM still evaluates the policies attached to that role on every request. What Identity Center replaces is the practice of creating individual IAM users with long-term access keys for humans. People authenticate through the identity source, receive temporary credentials, and you manage access centrally instead of account by account.

Where do the users come from? Either the built-in Identity Center directory, or an external identity provider such as Microsoft Entra ID or Okta connected via SAML for authentication, typically with SCIM for automatic provisioning and deprovisioning. The external IdP option matters for security: when someone leaves the company and is disabled in the corporate directory, their AWS access dies with it, instead of surviving as an orphaned account nobody remembers.