Tutorial: Migrate your applications from Okta to Azure Active Directory

In this tutorial, you'll learn how to migrate your applications from Okta to Azure Active Directory (Azure AD).

Create an inventory of current Okta applications

Before migration, document the current environment and application settings. You can use the Okta API to collect this information. Use an API explorer tool such as Postman.

To create an application inventory:

  1. With the Postman app, from the Okta admin console, generate an API token.

  2. On the API dashboard, under Security, select Tokens > Create Token.

    Screenshot of the Tokens and Create Tokens options under Sercurity.

  3. Enter a token name and then select Create Token.

    Screenshot of the Name entry under Create Token.

  4. Record the token value and save it. After you select OK, got it, it is not accessible.

    Screenshot of the Token Value field and the OK got it option.

  5. In the Postman app, in the workspace, select Import.

    Screenshot of the Import option on Postman.

  6. On the Import page, select Link. To import the API, insert the following link:

https://developer.okta.com/docs/api/postman/example.oktapreview.com.environment

Screenshot of the Link and Continue options on Import.

Note

Don't modify the link with your tenant values.

  1. Select Import.

    Screenshot of the Import option on Import.

  2. After the API is imported, change the Environment selection to {yourOktaDomain}.

  3. To edit your Okta environment select the eye icon. Then select Edit.

    Screenshot of the eye icon and Edit option on Overview.

  4. In the Initial Value and Current Value fields, update the values for the URL and API key. Change the name to reflect your environment.

  5. Save the values.

    Screenshot of Initial Value and Current Value fields on Overview.

  6. Load the API into Postman.

  7. Select Apps > Get List Apps > Send.

Note

You can print the applications in your Okta tenant. The list is in JSON format.

Screenshot of the Send option and the Apps list.

We recommend you copy and convert this JSON list to a CSV format:

Note

To have a record of the applications in your Okta tenant, download the CSV.

Migrate a SAML application to Azure AD

To migrate a SAML 2.0 application to Azure AD, configure the application in your Azure AD tenant for application access. In this example, we convert a Salesforce instance.

  1. To configure the applications, follow the tutorial Azure Active Directory single sign-on (SSO) integration with Salesforce.

To complete the migration, repeat the configuration for all applications in the Okta tenant.

  1. In the Azure Active Directory admin center, select Azure Active Directory > Enterprise applications > + New application.

    Screenshot of the New Application option on All applications.

  2. In Azure AD Gallery, search for Salesforce, select the application, and then select Create.

    Screenshot of applications in the Azure AD Gallery.

  3. After the application is created, on the Single sign-on (SSO) tab, select SAML.

    Screenshot of the SAML option on Single sign-on.

  4. Download the Certificate (Raw) and Federation Metadata XML to import it into Salesforce.

    Screenshot of Certificate (Raw) and Federation Metadata XML entries under SAML Signing Certificate.

  5. On the Salesforce administration console, select Identity > Single Sign-On Settings > New from Metadata File.

    Screenshot of the New from Metadata File option under Single Sign On Settings.

  6. Upload the XML file you downloaded from the Azure AD portal. Then select Create.

  7. Upload the certificate you downloaded from Azure. Select Save.

    Screenshot of the Identity Provider Certificate entry under SAML Single Sign On.

  8. Record the values in the following fields. The values are in Azure.

    • Entity ID
    • Login URL
    • Logout URL
  9. Select Download Metadata.

    Screenshot of the Download Metadata option, also entries for Entity ID and Your Organization.

  10. To upload the file to the Azure AD portal, in the Azure AD Enterprise applications page, in the SAML SSO settings, select Upload metadata file.

  11. Ensure the imported values match the recorded values. Select Save.

    Screenshot of entries for SAML-based sign-on, and Basic SAML Configuration.

  12. In the Salesforce administration console, select Company Settings > My Domain. Go to Authentication Configuration and then select Edit.

    Screenshot of the Edit option under My Domain.

  13. For a sign-in option, select the new SAML provider you configured. Select Save.

    Screenshot of Authentication Service options under Authentication Configuration.

  14. In Azure AD, on the Enterprise applications page, select Users and groups. Then add test users.

    Screenshot of Users and groups with a list of test users.

  15. To test the configuration, sign in as a test user. Go to the Microsoft apps gallery and then select Salesforce.

    Screenshot of the Salesforce option under All Apps, on My Apps.

  16. To sign in, select the configured identity provider (IdP).

    Screenshot of the Salesforce sign-in page.

Note

If configuration is correct, the test user lands on the Salesforce home page. For troubleshooting help, see the debugging guide.

  1. On the Enterprise applications page, assign the remaining users to the Salesforce application, with the correct roles.

Note

After you add the remaining users to the Azure AD application, users can test the connection to ensure they have access. Test the connection before the next step.

  1. On the Salesforce administration console, select Company Settings > My Domain.

  2. Under Authentication Configuration, select Edit. For authentication service, clear the selection for Okta.

    Screenshot of the Save option and Authentication Service options, under Authentication Configuration.

Migrate an OpenID Connect or OAuth 2.0 application to Azure AD

To migrate an OpenID Connect (OIDC) or OAuth 2.0 application to Azure AD, in your Azure AD tenant, configure the application for access. In this example, we convert a custom OIDC app.

To complete the migration, repeat configuration for all applications in the Okta tenant.

  1. In the Azure AD portal, select Azure Active Directory > Enterprise applications.

  2. Under All applications, select New application.

  3. Select Create your own application.

  4. On the menu that appears, name the OIDC app and then select Register an application you're working on to integrate with Azure AD.

  5. Select Create.

  6. On the next page, set up the tenancy of your application registration. For more information, see Tenancy in Azure Active Directory. Go to Accounts in any organizational directory (Any Azure AD directory - Multitenant) > Register.

    Screenshot of the option for Accounts in any organizational directory (Any Azure AD directory - Multitenant).

  7. On the App registrations page, under Azure Active Directory, open the created registration.

Note

Depending on the application scenario, there are various configuration actions. Most scenarios require an app client secret.

  1. On the Overview page, record the Application (client) ID. You use this ID in your application.

    Screenshot of the Application client ID entry on Migration Tenant.

  2. On the left, select Certificates & secrets. Then select + New client secret. Name the client secret and set its expiration.

    Screenshot of New client secret entries on Certificates and secrets.

  3. Record the value and ID of the secret.

Note

If you misplace the client secret, you can't retrieve it. Instead, regenerate a secret.

  1. On the left, select API permissions. Then grant the application access to the OIDC stack.

  2. Select + Add permission > Microsoft Graph > Delegated permissions.

  3. In the OpenId permissions section, select email, openid, and profile. Then select Add permissions.

  4. To improve user experience and suppress user consent prompts, select Grant admin consent for Tenant Domain Name. Wait for the Granted status to appear.

    Screenshot of the Successfully granted admin consent for the requested permissions message, under API permissions.

  5. If your application has a redirect URI, enter the URI. If the reply URL targets the Authentication tab, followed by Add a platform and Web, enter the URL.

  6. Select Access tokens and ID tokens.

  7. Select Configure.

  8. If needed, on the Authentication menu, under Advanced settings and Allow public client flows, select Yes.

    Screenshot of the Yes option on Authentication.

  9. Before you test, in your OIDC-configured application, import the application ID and client secret.

Note

Use the previous steps to configure your application with settings such as Client ID, Secret, and Scopes.

Migrate a custom authorization server to Azure AD

Okta authorization servers map one-to-one to application registrations that expose an API.

Map the default Okta authorization server to Microsoft Graph scopes or permissions.

Screenshot of the Add a scope option on Expose and API.

Next steps