Configure Okta with AWS IAM Identity Center: Federated access done right

Managing AWS access without a federated identity provider means IAM users: long-lived credentials, manually managed access keys, and an offboarding process where missing a single IAM user leaves a former employee with valid AWS credentials indefinitely.

Connecting Okta to AWS IAM Identity Center (formerly AWS Single Sign-On) solves this. Users authenticate with Okta using their corporate credentials and MFA. AWS access is provisioned and deprovisioned automatically via SCIM. When someone leaves the organisation and their Okta account is deactivated, their AWS access disappears within minutes rather than depending on someone remembering to revoke an IAM user.

Step 1: Create the SAML application in Okta

Start in the Okta admin console. Navigate to Applications > Browse App Catalogue and search for "AWS IAM Identity Center". Add the application to your Okta tenant.

In the application's Sign On tab, download the Okta SAML metadata XML file. This contains the IdP entity ID, the SSO URL, and the IdP certificate. You will upload this to AWS in the next step.

Configure the SAML settings in the Okta application: - Set the application username to email address format (not the Okta username) - Set the attribute statement to include email and any additional attributes your permission set mappings need (department, job title, or group membership if you map those to AWS permission sets) - Set session duration to a value that balances security with usability (4-8 hours is typical for production)

Generate and note the Client ID and Client Secret from the application's Provisioning tab. You will need these for SCIM in Step 2.

Step 2: Configure IAM Identity Center with Okta as the identity provider

In the AWS console, navigate to IAM Identity Center. Under Settings > Identity source, select Change identity source.

Choose External Identity Provider. Upload the SAML metadata XML downloaded from Okta. AWS parses the metadata to extract the IdP entity ID, SSO URL, and certificate.

After uploading the metadata, AWS provides a service provider metadata XML and the ACS (Assertion Consumer Service) URL. Download the AWS service provider metadata. Return to the Okta application and upload this SP metadata in the application settings. This completes the bidirectional SAML trust: Okta knows AWS's endpoints, AWS knows Okta's endpoints.

Test the SAML connection before proceeding: in IAM Identity Center, use the Test configuration option to verify that SAML assertions are flowing correctly between Okta and AWS.

Step 3: Enable SCIM provisioning for automatic user synchronisation

SAML handles authentication (who you are). SCIM handles provisioning (what you can access). Without SCIM, you would manually create user accounts in IAM Identity Center to match your Okta users, defeating the purpose of federated identity.

In IAM Identity Center Settings > Identity source > Actions, select Enable automatic provisioning. Copy the SCIM endpoint URL and bearer token displayed.

Return to the Okta application's Provisioning tab. Enable provisioning and enter the SCIM endpoint URL and bearer token from IAM Identity Center. Test the SCIM connection to confirm Okta can reach the IAM Identity Center SCIM API.

Configure the provisioning settings: - Enable "Create Users" and "Update User Attributes" under To App settings - Enable "Deactivate Users" so deactivated Okta users lose AWS access automatically - Map Okta profile attributes to the IAM Identity Center SCIM attributes (the default mapping covers the required fields)

Once enabled, SCIM synchronisation pushes your Okta users and groups to IAM Identity Center. Users do not need individual accounts created in AWS.

Step 4: Create permission sets and map to Okta groups

Permission sets define what AWS access a user gets in a specific account. They wrap an IAM policy and a session duration. Examples: - ReadOnly: ViewOnlyAccess managed policy, 4-hour session - Developer: PowerUserAccess managed policy, 8-hour session (no IAM management) - Operations: AdministratorAccess managed policy, 1-hour session, requires MFA - BillingViewer: Billing managed policy, 4-hour session

Create permission sets in IAM Identity Center under Permission Sets > Create permission set. Assign each permission set to specific AWS accounts and specific groups.

Map Okta groups to permission sets: for example, the Okta group aws-production-developers gets the Developer permission set on the production account; the aws-operations group gets the Operations permission set on the production account.

When a user is added to the aws-production-developers group in Okta, SCIM propagates the group membership to IAM Identity Center, which provisions the Developer permission set access on the production account for that user. The provisioning happens automatically without any manual AWS configuration.

Step 5: Configure MFA and test the integration

Enforce MFA for AWS access through Okta's sign-on policy for the AWS IAM Identity Center application. Set the policy to require MFA for every authentication. Okta MFA (TOTP, push notification, or hardware key) satisfies the requirement before the SAML assertion is issued to AWS.

For highly privileged permission sets (operations, administration), add a step-up MFA requirement: even users already authenticated with MFA are challenged again before accessing those permission sets.

Test the integration end-to-end:

  1. Log in to the AWS access portal URL (provided in IAM Identity Center settings) with an Okta user who has group assignments
  2. Confirm the user sees the correct accounts and permission sets
  3. Click into a permission set and confirm the correct IAM role is assumed
  4. Confirm the session duration matches the permission set configuration

Test the deprovisioning path: deactivate a test user in Okta and confirm they lose access to the AWS access portal within the SCIM synchronisation window (typically 5-10 minutes).

Maintenance and ongoing operations

SAML certificates in Okta expire. Monitor certificate expiry dates and rotate them before they expire: an expired certificate causes complete authentication failures across all AWS access. Okta sends email reminders before expiry; do not ignore them.

Review permission set assignments quarterly. Teams change, roles evolve, and group memberships accumulate. A quarterly review catches users with access they no longer need.

Where Critical Cloud comes in

Federated identity correctly configured means zero standing IAM users, automatic deprovisioning, and a single control point for AWS access governance. Getting the SAML trust, SCIM provisioning, and permission set design right from the start prevents the sprawl of long-lived credentials that accumulates when identity is managed ad-hoc. As the world's first Powered by Datadog accredited partner, we integrate identity provider signals alongside infrastructure and application monitoring, so authentication anomalies appear in the same operational view as performance data. See how Critical Support works.