How to Integrate Okta with AWS IAM Identity Center to Manage Users, Roles, and Multi-Account Access

# How to Integrate Okta with AWS IAM Identity Center to Manage Users, Roles, and Multi-Account Access

Key Takeaways

• AWS IAM Identity Center (formerly AWS SSO) federates with Okta using SAML 2.0 for sign-in and SCIM for automatic user/group provisioning.
• Once integrated, users log into AWS accounts with their existing Okta credentials, and permission sets (not individual IAM users) control what they can do in each account.
• The okta-aws-cli tool lets developers generate temporary AWS CLI credentials from an Okta session without storing long-lived access keys.
• Deprovisioning a user in Okta automatically removes their AWS access — no manual IAM account cleanup across dozens of accounts.

Why Integrate Okta with AWS IAM Identity Center

If your organization already uses Okta as its identity provider, manually creating and managing IAM users separately in every AWS account is both a security risk (long-lived credentials, inconsistent offboarding) and an operational burden once you have more than a handful of AWS accounts. AWS IAM Identity Center solves this by acting as the single place where permissions are defined once and applied across your entire AWS Organization, while Okta remains the source of truth for who your users are.

<svg viewBox="0 0 800 240" xmlns="http://www.w3.org/2000/svg" style="width:100%;max-width:800px;font-family:sans-serif;color:inherit">
  <style>
    .box { fill: none; stroke: currentColor; stroke-width:1.5; }
    .lbl { fill: currentColor; font-size:13px; }
    .arrow { stroke: currentColor; stroke-width:1.5; marker-end:url(#arrow5); }
  </style>
  <defs>
    <marker id="arrow5" markerWidth="10" markerHeight="10" refX="8" refY="3" orient="auto">
      <path d="M0,0 L8,3 L0,6 Z" fill="currentColor"/>
    </marker>
  </defs>
  <rect class="box" x="10" y="90" width="150" height="60" rx="8"/>
  <text class="lbl" x="35" y="115">Okta</text>
  <text class="lbl" x="35" y="132">(Identity Provider)</text>

  <rect class="box" x="220" y="90" width="180" height="60" rx="8"/>
  <text class="lbl" x="240" y="112">IAM Identity Center</text>
  <text class="lbl" x="240" y="130">(SAML + SCIM)</text>

  <rect class="box" x="460" y="20" width="150" height="50" rx="8"/>
  <text class="lbl" x="480" y="50">Prod Account</text>

  <rect class="box" x="460" y="90" width="150" height="50" rx="8"/>
  <text class="lbl" x="480" y="120">Staging Account</text>

  <rect class="box" x="460" y="160" width="150" height="50" rx="8"/>
  <text class="lbl" x="480" y="190">Dev Account</text>

  <rect class="box" x="660" y="90" width="120" height="60" rx="8"/>
  <text class="lbl" x="675" y="112">Permission</text>
  <text class="lbl" x="675" y="128">Sets</text>

  <line class="arrow" x1="160" y1="120" x2="218" y2="120"/>
  <line class="arrow" x1="400" y1="105" x2="458" y2="45"/>
  <line class="arrow" x1="400" y1="120" x2="458" y2="115"/>
  <line class="arrow" x1="400" y1="135" x2="458" y2="185"/>
  <line class="arrow" x1="610" y1="120" x2="658" y2="120"/>
</svg>

Step 1: Configure SAML in Okta

In the Okta Admin console, create a new SAML 2.0 application pointing at AWS IAM Identity Center's SAML metadata.

1. In Okta: Applications → Create App Integration → SAML 2.0.
2. Set the Single Sign-On URL and Audience URI (SP Entity ID) from your IAM Identity Center's instance metadata (found under IAM Identity Center → Settings → Identity source).
3. Add attribute mappings that IAM Identity Center expects:

Name: Subject         Value: user.email
Name: email           Value: user.email
Name: firstName       Value: user.firstName
Name: lastName        Value: user.lastName

1. Download Okta's SAML metadata XML and upload it into IAM Identity Center's identity source configuration via the AWS console.

Step 2: Enable SCIM Provisioning

SCIM (System for Cross-domain Identity Management) keeps Okta and AWS user/group data in sync automatically — new hires get AWS access the moment they're added to the right Okta group, and offboarded users lose access the moment they're deactivated.

In IAM Identity Center, generate a SCIM endpoint and access token:

aws sso-admin list-instances

# From the console: Settings → Identity source → Automatic provisioning → Enable
# This generates a SCIM endpoint URL and bearer token to paste into Okta

In Okta's app configuration, go to Provisioning → Configure API Integration, paste the SCIM endpoint and token, then enable:

• Create Users
• Update User Attributes
• Deactivate Users

Step 3: Define Permission Sets and Assign Accounts

Permission sets are IAM Identity Center's reusable role definitions — define once, assign to any combination of users/groups and AWS accounts.

aws sso-admin create-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-0123456789abcdef \
  --name "DeveloperAccess" \
  --session-duration "PT4H" \
  --description "Standard developer access to dev/staging accounts"

aws sso-admin attach-managed-policy-to-permission-set \
  --instance-arn arn:aws:sso:::instance/ssoins-0123456789abcdef \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-0123456789abcdef/ps-0abc123 \
  --managed-policy-arn arn:aws:iam::aws:policy/PowerUserAccess

aws sso-admin create-account-assignment \
  --instance-arn arn:aws:sso:::instance/ssoins-0123456789abcdef \
  --target-id 111122223333 \
  --target-type AWS_ACCOUNT \
  --permission-set-arn arn:aws:sso:::permissionSet/ssoins-0123456789abcdef/ps-0abc123 \
  --principal-type GROUP \
  --principal-id <okta-synced-group-id>

Step 4: Using okta-aws-cli for Developer CLI Access

Once SSO is live, developers shouldn't be creating long-lived IAM access keys. The okta-aws-cli tool exchanges an active Okta session for short-lived AWS credentials.

# Install (macOS example via Homebrew)
brew install okta-aws-cli

# Authenticate and generate temporary credentials
okta-aws-cli --org-domain f9infotech.okta.com \
  --oidc-client-id 0oa1b2c3d4e5f6g7h8i9 \
  --aws-acct-fed-app-id 0oa9i8h7g6f5e4d3c2b1

# This writes temporary credentials to ~/.aws/credentials under a named profile
aws sts get-caller-identity --profile okta-dev

This avoids the common anti-pattern of developers creating static access keys that sit unrotated for months. Credentials from okta-aws-cli typically expire in an hour, matching the permission set's session duration.

Alternative: AWS CLI v2 Native SSO Login

If you don't want a separate tool, AWS CLI v2 has native IAM Identity Center support, which also routes through Okta once SAML is configured:

aws configure sso
# Prompts for SSO start URL, region, then opens a browser
# to authenticate through Okta

aws sso login --profile my-sso-profile
aws s3 ls --profile my-sso-profile

Common Pitfalls

• Group sync delay. SCIM provisioning isn't always instant — if a new Okta group member doesn't see AWS access, check the SCIM sync logs before assuming the permission set is misconfigured.
• Attribute mapping mismatches. A mismatched email/Subject mapping between Okta and IAM Identity Center is the most common cause of SAML login failures. Check the exact claim names IAM Identity Center expects.
• Session duration too long for sensitive accounts. Keep production permission set session durations shorter (e.g., 1 hour) than dev/staging.
• Forgetting to deactivate the Okta SCIM token on offboarding an admin. Treat the SCIM bearer token itself as a credential requiring rotation.

FAQ

Does integrating Okta with AWS IAM Identity Center replace individual IAM users? Yes, that's the point — users authenticate through Okta and assume temporary permission-set-based roles, rather than having individual long-lived IAM users and access keys per account.

What is okta-aws-cli used for specifically? It exchanges an authenticated Okta session for short-lived AWS CLI credentials, so developers get programmatic AWS access without creating static IAM access keys.

Does this work across multiple AWS accounts in an AWS Organization? Yes — IAM Identity Center is designed for AWS Organizations; once set up, you assign permission sets to Okta-synced users/groups across any number of member accounts from one place.

What happens to AWS access when a user is deactivated in Okta? With SCIM provisioning enabled, deactivating the user in Okta automatically revokes their AWS access across every account they had permission sets assigned to — no manual IAM cleanup required.

---

Setting up federated identity across a multi-account AWS Organization has a lot of edge cases to get right the first time. f9infotech's AWS security and identity team can help design and implement your Okta/IAM Identity Center integration — contact us to discuss your setup.