Okta + AWS SSO: Single Sign-On to AWS Console (2026)

Okta and AWS IAM Identity Center (formerly AWS SSO) can integrate to provide single sign-on to the AWS console. This means users can log in with their Okta credentials and gain access to AWS accounts and applications without needing separate AWS credentials.

Here’s how it works conceptually:

1. User Initiates Login: A user tries to access an AWS console application or an AWS account.
2. Okta Redirect: The user is redirected to Okta’s login page.
3. Okta Authentication: The user authenticates with their Okta credentials.
4. SAML Assertion: Okta generates a Security Assertion Markup Language (SAML) assertion, which is a digitally signed XML document containing information about the authenticated user and their permissions.
5. Assertion to AWS: Okta sends this SAML assertion to AWS IAM Identity Center.
6. AWS IAM Identity Center Validation: AWS IAM Identity Center validates the SAML assertion, verifying the user’s identity and permissions.
7. Access Granted: Based on the validated assertion and the user’s assignment in IAM Identity Center, the user is granted access to the specified AWS account and console.

Let’s look at a typical setup and how you might configure it.

Configuration Steps (High Level):

1. In Okta:

   • Create an AWS IAM Identity Center application integration.
   • Configure SAML settings, including the Identity Provider (IdP) metadata URL and certificate.
   • Assign users or groups to this application in Okta.

2. In AWS IAM Identity Center:

   • Configure your AWS organization to use IAM Identity Center.
   • Set up your external identity provider (Okta) by uploading the IdP metadata from Okta.
   • Configure the SAML authentication response (e.g., mapping Okta attributes to AWS IAM Identity Center attributes).
   • Assign users or groups to specific AWS accounts and permission sets.

Example AWS IAM Identity Center Configuration (using CLI):

After setting up the IdP in the AWS console or via Okta’s setup wizard, you’d typically verify and manage assignments. To list your configured identity providers, you might use:

aws sso-admin list-identity-providers --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxx

To list permission sets for an account:

aws sso-admin list-permission-sets --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxx --account-id 111122223333

To assign a user to a permission set for an account:

aws sso-admin put-user-assigned-permission-set \
    --instance-arn arn:aws:sso:::instance/ssoins-xxxxxxxxxxxxxxxxx \
    --principal-id u-xxxxxxxxxxxxxxxxxxxxxx \
    --permission-set-arn arn:aws:sso:::permissionSet/ssoins-xxxxxxxxxxxxxxxxx/ps-xxxxxxxxxxxxxxxxx \
    --target-id 111122223333

The principal-id is the Okta user’s ID, and the permission-set-arn defines the AWS roles and policies the user will assume.

The Mental Model:

Think of Okta as the gatekeeper for your identity. It knows who you are. AWS IAM Identity Center is the orchestrator within AWS that takes Okta’s confirmation of your identity and then, based on predefined rules, tells you which doors (AWS accounts) you can open and what tools (permission sets) you can use once inside. The SAML assertion is the verified ID card and permission slip that Okta hands over.

The most surprising thing about this integration is how decoupled the identity management (Okta) is from the authorization within AWS (IAM Identity Center). Okta doesn’t need to know what you can do in AWS; it only needs to confirm who you are. IAM Identity Center then takes that identity and applies your AWS-specific access policies. This separation allows for robust identity management without giving your IdP direct control over your cloud resources.

The next concept to explore is how to manage fine-grained access within an AWS account using AWS IAM Identity Center’s permission sets, which often involves creating and assigning IAM roles that grant specific permissions.