Enabling single sign-on for AWS Transform with Okta Workforce Identity

Enabling single sign-on for AWS Transform with Okta Workforce Identity ensures that the dozens, sometimes hundreds, of people involved in enterprise migration programs all work inside a single platform. That platform is governed by the same access controls and security policies that your organization already enforces, making it essential for running migrations at scale.

AWS Transform is an AI-powered modernization service that provides a unified web experience for planning and executing large-scale migrations, whether you are modernizing mainframe applications, migrating VMware workloads to Amazon Elastic Compute Cloud (Amazon EC2), or moving SQL Server databases to Amazon Aurora. AWS Transform uses your existing corporate identity provider using the OpenID Connect (OIDC) protocol. Once connected, your users sign in with the same credentials they use for email and every other enterprise application, with your existing multi-factor authentication (MFA) policies applied automatically.

This post walks you through the complete configuration for Okta Workforce Identity. You will create an OIDC application in Okta, configure a custom authorization server with the scope AWS Transform requires, enable AWS Transform with your organization’s identity provider, and verify that a test user can sign in successfully.

Figure 1 shows the AWS Transform console home page after sign-in.

Figure 1 – AWS Transform console home page displaying workspace navigation after SSO Authentication.

Prerequisites

1. An AWS account with administrator access.
2. AWS Transform not yet enabled, or enabled with third-party identity provider selected as the access method.
3. An Okta organization with Super Administrator privileges.
4. Users in your Okta organization with display name, email address, and username (preferred_username) attributes populated in their Okta profile.
5. AWS Transform exchanges the authorization code for an ID token and an access token by calling the identity provider’s token endpoint.
6. Familiarity with Okta authorization servers and OIDC application configuration.

Note: You choose your identity provider once during initial AWS Transform setup and cannot change it later. If you have already enabled AWS Transform with a different identity provider, you cannot switch to Okta without recreating the profile.

How Authentication Works

Understanding the OIDC authorization code flow makes the configuration steps easier to follow. Figure 2 shows the complete flow for AWS Transform.

Figure 2 shows the full OIDC authorization code flow for AWS Transform.

Figure 2 – OIDC authorization flow between the user’s browser, AWS Transform, Okta, and AWS Secrets Manager.

When a user opens the AWS Transform web application URL, AWS Transform redirects the browser to the Okta authorization endpoint with an OIDC request that includes the transform:read_write scope. The user authenticates with Okta, and MFA and access policies are enforced. Okta redirects the browser back to the /login/callback URL with a short-lived authorization code.

AWS Transform exchanges that code for an ID token and access token by calling the Okta token endpoint directly, using the client secret stored in AWS Secrets Manager. AWS Transform validates the tokens. For user identity, Transform uses the sub claim from the ID token (the stable, unique identifier Okta assigns to each user) and the uid claim from the access token as a secondary reference.

Configuring Okta Workforce Identity

Okta’s OIDC model separates the application (which holds the client credentials) from the Authorization Server (which owns scope definitions and issues tokens). You need both. The Authorization Server must list your application as an allowed audience before it will issue tokens for it. Working through these in order keeps the configuration clear.

Step 1: Create an OIDC Web Application

Start by creating the application integration for AWS Transform in your Okta org.

1. Sign in to the Okta Admin console and navigate to Applications, then Applications.
2. Choose Create App Integration.
3. Select OIDC – OpenID Connect as the sign-in method and Web Application as the application type, then choose Next.
4. Name the application, for example AWS-Transform. Leave the Grant Type as Authorization Code (the default) and leave the sign-in redirect URIs blank for now.
5. Configure Assignments to control which Okta users or groups can authenticate into AWS Transform, then choose Save.
6. From the application’s General tab, copy the Client ID. Under Client Secrets, choose Generate new secret and copy the value immediately.

Figure 3 shows the General tab of the new OIDC Web Application with the Client ID and Client Secrets section.

Figure 3 – The Okta Admin console OIDC Web Application General tab showing the Client ID and Client Secrets section.

Step 2: Set the Issuer to Okta Uniform Resource Locator (URL)

AWS Transform requires a static issuer URL scoped to your Okta organization. The default Dynamic setting produces a different issuer per request, which Transform can’t validate.

1. In the application, open the Sign On tab.
2. Under OpenID Connect ID Token, find the Issuer field and change it from Dynamic to Okta URL.
3. Choose Save.

Figure 4 shows the Sign On tab with the Issuer field set to Okta URL.

Figure 4 – The Okta application Sign On tab with the Issuer field changed to Okta URL.

Step 3: Create a custom Authorization Server and add the required scope

In Okta, OAuth 2.0 scopes are owned by Authorization Servers, not applications. You need a custom Authorization Server that defines the transform:read_write scope and lists your AWS Transform application as an allowed audience.

1. In the Okta Admin console, navigate to Security, then API.
2. Choose Add Authorization Server. Give it a name such as AWS-Transform-AuthServer.
3. Set the Audience to the Client ID of the OIDC application you created in Step 1. This binds the Authorization Server to your application.
4. Choose Save. On the Settings tab of the new Authorization Server, copy the Issuer URI. You use this when creating the AWS Transform profile.
5. Open the Scopes tab and choose Add Scope. Set the name to transform:read_write, provide a display phrase such as “Access AWS Transform”, and choose Create.

Figure 5 shows the custom Authorization Server Scopes tab with the transform:read_write scope added.

Figure 5 – The custom Authorization Server Scopes tab showing the transform:read_write scope.

Figure 6 shows the Authorization Server Settings tab with the Issuer URI to copy.

Figure 6 – The Authorization Server Settings tab showing the Issuer URI to copy for use in AWS Transform.

Step 4: Add an Access Policy

An Access Policy on the Authorization Server controls which applications can request tokens. Without one, requests from your AWS Transform application denies token requests regardless of correct credentials.

1. In the Authorization Server, choose the Access Policies tab, then Add Policy.
2. Name the policy, for example AWS-Transform-Policy. Under Assign to, select the following clients and add your AWS-Transform application.
3. Choose Create Policy.
4. Choose Add Rule. Permit the Authorization Code grant type for the users or groups you want to access AWS Transform, then choose Create Rule.

Figure 7 shows the Access Policies tab with the policy assigned to the AWS-Transform application and an active rule configured.

Figure 7 – The Access Policies tab showing the policy assigned to the AWS-Transform client with an active rule.

Step 5: Create the AWS Transform profile

With the Okta configuration complete, return to the AWS Management Console to create the AWS Transform profile.

1. In the AWS console, navigate to AWS Transform. Under User access, choose third-party identity provider.
2. Enter the Issuer URL from your Okta Authorization Server Settings tab (Step 3), the Client ID from the Okta application (Step 1), and the Client Secret (Step 1).
3. Choose Enable AWS Transform. Copy the Web application URL from the Settings tab once provisioning completes.

Figure 8 shows the AWS Transform identity provider configuration form with the Okta values entered.

Figure 8 – The AWS Transform identity provider configuration form with Okta values entered.

Step 6: Add the redirect URI in Okta

With the Okta configuration complete, return to the AWS Management Console to create the AWS Transform profile.

1. In the Okta Admin console, return to your AWS Transform OIDC application and open the General tab.
2. Under Sign-in redirect URIs, choose Edit and add your Web application URL followed by /login/callback.
3. Choose Save.

Figure 9 shows the Okta application General tab with the sign-in redirect URI pointing to the AWS Transform callback address.

Figure 9 – The Okta application General tab showing the sign-in redirect URI pointing to the AWS Transform callback address.

Optional: post-logout redirect. If you want users redirected back to AWS Transform after signing out of Okta, add the Web application URL as a trusted origin. Navigate to Security, then API, then Trusted Origins, choose Add Origin, enter the URL, enable both Cross-Origin Resource Sharing (CORS) and Redirect, and save.

Assigning users

When you use a third-party identity provider, the IdP controls all user access to AWS Transform, not the Transform console. For Okta, the Assignments configuration on the OIDC application you created in Step 1 determines who can sign in.

In the Okta Admin console, open your AWS-Transform application and choose the Assignments tab. Assign the users or groups who need access. Okta enforces this at authentication time; users not assigned will receive a denial from Okta before ever reaching Transform.

Once assigned, ask a test user to navigate to the Web application URL. They will see an option to sign in with their Okta credentials. After completing authentication, including any MFA challenge enforced by your Okta access policies, they arrive at the AWS Transform welcome experience where they can create a workspace or be added to an existing one by a workspace admin.

User profile information, including display name, email, and username, is stored in AWS Transform only after each user’s first successful login. A user’s name will not appear in Transform’s workspace invite search until they have completed that first sign-in.

Note: If you also need programmatic or automation-based access alongside your IdP users, you can enable IAM credential access under Settings by toggling Enable IAM access. IAM principals and IdP users can collaborate in the same workspaces, but a user who authenticates both ways appears as two separate identities in AWS Transform and their work is not linked between the two sessions.

Security considerations

Client secrets have expiry dates; when the secret rotates, update both Okta and AWS Transform under Settings in the same maintenance window to avoid an authentication outage. Using a customer managed key in AWS Key Management Service (AWS KMS) for the AWS Transform profile gives you direct control over encryption for stored user data.

Because authentication is fully delegated to Okta, any access policies you enforce there, including MFA requirements, network zone restrictions, and device trust, apply to AWS Transform logins automatically. To revoke a user’s access, remove them from the applications assignment in Okta. No changes in the AWS Transform console are needed.

AWS CloudTrail logs all AWS Transform activity with the user’s Okta sub/uid claim as the caller identity, giving you a consistent identifier to correlate across your Okta System Log and CloudTrail.

Troubleshooting

Authentication fails with an invalid redirect URI error. The redirect URI registered in Okta must exactly match what AWS Transform sends. Double-check that you have entered <web-application-url>/login/callback with no trailing slash, using the URL from the AWS Transform Settings tab.

Token validation fails with an invalid issuer error. Confirm you copied the Issuer URI from the custom Authorization Server Settings tab, not from the application’s Sign On tab or from the Okta Org Authorization Server. Each has a different issuer format and only the custom Authorization Server’s issuer is valid for AWS Transform.

Okta returns an invalid scope error. The transform:read_write scope must exist on the custom Authorization Server, not the Okta Org Authorization Server. Verify it appears under the Scopes tab of your custom Authorization Server.

The user authenticates but is denied access to AWS Transform. Verify the user, or a group they belong to, is assigned to the OIDC application under the Assignments tab in the Okta Admin console.

Token requests are blocked by the Access Policy. Confirm an Access Policy exists on the Authorization Server that lists your AWS-Transform application as an assigned client and includes a rule permitting the Authorization Code grant type.

A user’s profile shows an outdated display name or email. AWS Transform stores profile information on first login and does not automatically sync subsequent IdP changes. The user needs to sign in again after updating their Okta profile.

Conclusion

In this post, we showed how to connect Okta Workforce Identity to AWS Transform using your existing corporate credentials. Your Okta access policies, including MFA, network zones, and device trust, apply consistently without separate configuration in AWS Transform. The custom Authorization Server model adds a few additional steps compared to Entra ID, but it also gives you precise control over which applications can request tokens and under what conditions.

Together, the two posts in this series cover the identity provider options most commonly deployed in enterprise environments. Your organization might run on Microsoft Entra ID, Okta, or both. In each case, AWS Transform integrates with your existing identity stack so that access control for your migration program stays consistent with the rest of your environment.

To get started, open the AWS Transform console, choose Get started, and follow the prompts to enable the service with Okta as your identity provider. For complete setup instructions, see Setting up AWS Transform in the AWS Transform User Guide.

If you have questions or feedback about this post, leave a comment in the Comments section below.

Additional resources

• Setting up AWS Transform (AWS Transform User Guide)
• Managing users in AWS Transform (AWS Transform User Guide)
• Create an Okta OIDC app integration (Okta documentation)