Customization Skip to main content
https://support.okta.com/help/oktaarticledetailpage?childcateg=&id=ka02a0000005uflsaq&source=documentation&refurl=http%3a%2f%2fsupport.okta.com%2fhelp%2fdocumentation%2fknowledge_article%2fcustomization-1510363316
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
1
2
3
4
5
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Customization
Published: Jan 31, 2018   -   Updated: Jun 22, 2018

 

 

okta-doc-source

Customization

Configure a custom URL domain

Configure a custom Okta-hosted sign-in page

Configure a custom error page

Configure a custom email domain

Manage dashboard tabs for end users

Add custom email templates for multiple languages

Configure your custom end user portals to leverage the Okta browser plugin



Configure whether user passwords and personal information are managed by Okta or externally

If you provide your users an external application through which to manage their personal information and/or password, use the options in this section to configure custom redirect links to that application. The links will appear in your users' Account page. The Forgot password? link on the Okta Sign In page will also redirect to the change password redirect URL, if configured. You can also add link labels and custom messages.

Note: Due to a lack of broad support across various browsers, do not use X-Frame-Options to host the custom personal information or change password flows that you configure in this section, as Okta loads these flows as iframes.

Personal information

  1. If your org integrates more than one profile master, the User Identity Master drop down displays. Select the identity master that manages the users whose Account page you want to customize. A user can be mastered by only one identity master at a time.
  2. Click Edit in the User Account section.
  3. If applicable, select Personal information is managed by Okta. If personal information is managed outside of Okta by another application:
    1. Select Personal information is managed by a different application.
    2. Enter a custom message.
    3. Enter a link label.
    4. In the Custom link URL field, enter the redirect URL of the website you want users to visit to change their personal information.

Password management

Select the appropriate option to specify whether users' passwords are managed in Okta or by a different application.

Note: If you select Password is managed by a different application, you must also enter values in the Expired Password section.

CHANGE PASSWORD

  1. Click Edit in the User Account section.
  2. If applicable, select Password is managed by Okta. If passwords are managed outside of Okta by another application:
    1. Select Password is managed by a different application. Note: If you select this option, you must also enter values in the Expired Password section.
    2. Enter a custom message.
    3. Enter a link label.
    4. In the Custom link URL field, enter the redirect URL of the website you want users to visit to change their password.

EXPIRED PASSWORD

This option allows you to redirect end users whose password has expired to a website that presents your org's password recovery instructions.

  1. Click Edit in the User Account section.
  2. Make sure that Password is managed by a different application is selected in the Password Management section above.
  3. In the Expired Passsword section, enter the name of the website to which users are redirected when they try to sign in to Okta with an expired password.
  4. In Link URL, enter the redirect URL to the website.
  5. Click Save.


Configure a secondary email option for end users

When you enable the secondary email option, your end users can provide a secondary email address in their Accounts page to which password reset and account creation notices are sent. If this option is disabled, such notices are sent only to your end users' primary email address.

  1. Click Edit in the Optional User Account Fields section.
  2. Set the Secondary Email option to Enabled.
  3. Click Save.


Configure a security image for the Sign-In page

You can configure a security image to appear when users enter a valid Okta username in the Sign-In page. The appearance of the security image helps protect end users against phishing attacks. When a security image is configured, users signing in to Okta for the first time are prompted to select an image. The browser receives a cookie containing the selected security image. The cookie is signed by the site certificate to ensure that an attack site cannot access and load the security image. When users recognize their selected security image, they are reassured that they are logging in to their org.

Note: Because the browser must first create the cookie before displaying the image, the security image is not displayed in the following circumstances:

  • First login
  • First login from a new browser or device
  • First login after clearing cookies
  1. Click Edit in the Optional User Account Fields section.
  2. Choose whether new end users are prompted to select a Security Image the first time they sign in to Okta.
  3. Click Save.

Okta recommends using Multifactor Authentication (MFA) as a further layer of Security.



Opt out of Okta user communication
  1. Click Edit in the Okta User Communication section.
  2. Select to Opt Out of Okta User Communication.
  3. Click Save.


Enable deprovisioning workflow

Some apps must be manually deprovisioned. When this option is enabled, the Deprovisioning Task Manager helps admins keep track of these tasks by listing them in Dashboard > Tasks. When disabled, Okta does not alert you with tasks or send you emails when you deactivate or unassign an application from a user.

  1. Click Edit in the Deprovisioning Workflow section.
  2. Select Enable Deprovisioning Workflow.
  3. Click Save.


JIT Provisioning

Just In Time (JIT) provisioning enables automatic user account creation in Okta the first time a user authenticates with AD Delegated Authentication, Desktop SSO, or inbound SAML.

JIT account creation and activation only works for end users who are not already Okta end users. (JIT updates the accounts of existing end users during full imports.) This means that end users who are confirmed on the import results page, regardless of whether or not they were subsequently activated, are not eligible for JIT activation. When JIT is enabled, users do not receive activation emails.

When using JIT provisioning with AD users, the procedure depends on whether delegated authentication is enabled.

  • If you have delegated authentication enabled, you do not need to import users from AD first for JIT provisioning to create Okta accounts.
  • If you do not have delegated authentication enabled, you must import the AD accounts first, and they must appear on the imported users list for JIT provisioning to create Okta accounts.

To enable JIT, click Edit under Just In Time Provisioning, and then click Enable Just In Time Provisioning.



Configure the browser plugin

You can configure browser plugin settings to manage plugin installations and upgrades, as well as some browser behaviors. This option is useful in locked-down environments where end users can't install or manage the Okta Plugin on their computers.

  1. Click Edit in the Browser Plugin section and configure the following items:
    • IT manages Okta Plugin: Select Yes to enable; No to disable. If enabled, the messages prompting users to install or upgrade the plugin are hidden. Note: When this option is enabled, end users must have the browser plugin installed on their device in order to access SWA apps from their Okta dashboard.
    • Enable Okta toolbar for group: Specify the group(s) that can use the toolbar to access their app outside of Okta.
    • Warn when visiting new organizations: Select Yes to enable; No to disable. Enabling this setting displays a warning message in the browser when an Okta user attempts to log in to an unknown org. This security feature prompts end users to use caution before they enter their login credentials for an org that is not their primary org.
    • This is an Early Access feature. To enable it, please contact Okta Support.

      Note: When enabled, the following EA option replaces the option Warn when visiting new organizations above.

    • Security Warning: Select an option to help end users avoid logging in to fake or unauthorized organizations.
      • Don't show warning: Select if you don't want to display a warning when end users try to log in to an org that is not their primary org.
      • Show warning: Select if you want to display a warning when end users try to log in to an org that is not their primary org.
      • Specify organizations: You can create a whitelist of up to 10 organizations that your end users are permitted to visit. Your current org is automatically added to the whitelist. Choose an Okta domain from the drop down list.
  1. Click Save.


Allow iFrame embedding

Enable this option to allow your org to embed Okta in an iFrame.

  1. Click Edit in the iFrame Embedding section.
  2. Select Allow iFrame embedding.
  3. Click Save.


Configure the display language

You can specify an org-wide display language for all end users, and individual end users can specify their own language for their own experience. The user's preference overrides the org-wide display language setting.

What's localized
  • All the end user views including Dashboard, Settings, etc.
  • The Get the Mobile App page
  • All the sign in flows, including MFA
  • The login Help page
  • Recovery flows
  • All orginal Okta-provided emails sent to end users. These are based on the email templates available in Settings > Emails. Note that only the original Okta-provided email templates are sent automatically in Okta-supported languages. Email templates that you edit are no longer provided automatically in the user's preferred language, but you can still send them to end users. For details, see Custom Email Templates for Multiple Languages.
  • Browser plugin and messages generated by the plugin
  • Okta Verify
What's not localized
  • Admin pages (with the exception of the Email Templates)
  • Customized labels in the Sign-In Page, if they are in a language other than what is specified in Display Language.
How Okta determines the language displayed to end users

Existing end users (activated) — Okta evaluates these sources in the following order to determine which supported language is displayed to activated end users in their Okta instance:

  1. (First priority) End users' Display Language setting.
  2. Cookie that holds the browser's current language setting. More

    Relevant in a shared-terminal scenario where multiple operators use the same browser. The browser displays in the language that the most-recently authenticated user configured in their Okta Home page Display Language setting (assuming they've configured a language; for details, seeCustomize the end-user display language).

  3. Language configured in the browser settings.
  4. Value of the user's locale property.
  5. (Last priority) Org-wide display language is displayed to all users unless overridden by any of the preceding sources.

New end users (not activated) — The Welcome email that Okta sends to new end users is localized in the language in users' locale property (if specified) instead of the display language configured for your org (if different).

Change the display language for an org

To set or change the default language for your entire org, do the following:

  1. Go to Settings > Customization.
  2. In the Display Language section, click Edit.
  3. Select a language for your org. List of supported languages:
  4. Čeština (Czech) (beta)Malay (beta)
    Dansk (Danish)Nederlands (Dutch)

    Deutch (German)

    język polski (Polish) (beta)

    ελληνικά (Greek) (beta)Português (Portuguese)

    English

    Română (Romanian) (beta)

    Español (Spanish)

    Pу́сский (Russian)

    Suomi (Finnish)

    Svenska (Swedish)

    Français (French)

    ภาษาไทย (Thai)
    magyar (Hungarian) (beta)Türkçe (Turkish) (beta)
    Bahasa Indonesia (beta)

    українська (Ukranian) (beta)

    Italiano (Italian)

    简体中文 (Simplified Chinese)

    日本語 (Japanese)繁體中文 (Traditional Chinese)
    한국어 (Korean) 
  1. Click Save.

End users can set their Display Language

End users can select from a list of supported languages to customize their own Okta experience. The End users see the Okta user interface in their selected language after they are fully authenticated into Okta. Also, all Okta-generated emails sent to these end users are localized in their selected language.

  1. From the end user Okta Dashboard, end users click their name and then choose Settings.

  2. Click Edit Profile.
  3. Click Edit in the Display Language section.
  4. Select a language.
  5. Click Save.


Customize Sign In Page headings, links, labels, and placeholders

Note: If your org implements a custom Okta-hosted sign in page and you are familiar with using HTML, click the Custom Sign In tab at the top of the Customization page as an alternative to using this option. The Custom Okta-hosted sign-in page feature allows you to modify the current HTML/CSS and JavaScript as much as you like, or paste your own code in the embedded editor to create a completely transformed sign-in experience. For details, see Configure a custom Okta-hosted Sign-In page.

You can customize the headings, links, and labels on the Sign In Page. You can also customize the placeholder text that appears in recovery flows when end users click account recovery links (for example, Forgot password and Unlock account). Screenshot.

CustHelpLink_PlaceholderText

Note: For the Sign-In page to display correctly, your browser must be at least 750px in height.

  1. Go to Settings > Customization.
  2. Click Edit in the Sign-In Page section.
  3. Customize links, labels, and headings as desired. If you leave a label field blank, Okta will display the default text.
  4. Note: Although Okta displays default labels, links, and headings in the end user's Display language or the browser language, Okta does not display localized versions of your custom text and links. If you entered custom text and links in a different language than the end users' Display or browser language, the Sign-In page will have text in more than one language.

  5. Click Save.


Configure a custom Sign-Out Page redirect URL

You can change the page to which users are redirected when they sign out of Okta.

  1. In the Sign-Out Page section, click Edit, and select Use a custom sign out page.
  2. Add the URL for your custom page.

    Note: Although Okta displays default links in the end user's Display language or the browser language, Okta does not display localized versions of your custom links. If you entered a custom link in a different language than the end users' Display or browser language, the Sign-Out page will have text in more than one language.

  3. Click Save.


Configure an Application Access error page

If end users try to access an app that has not been assigned to them, you can configure Okta to redirect them to the default Okta URL or to a custom URL that you provide. Unassigned users are more likely to try to access apps if you embed app links in your portal or other sites outside of Okta.

Note: This is a global setting. To specify a custom error page for an individual app, see Redirect unassigned users to a custom error page.

To specify a custom error page for all apps:

  1. Click Edit.
  2. In the Application Access Error Page section, select one of the following options:
    • Use the default Okta error page
    • Use a custom error page

      For custom error pages, enter a URL to redirect unassigned users to a custom error page. This setting applies to your entire org. Optionally, you can configure a different URL on a per-app basis. An app-specific URL overrides the org-level URL that you specify here. For details, see Using the Okta Applications Page.

    Note: Although Okta displays default links in the end user's Display language or the browser language, Okta does not display localized versions of your custom links. If you entered custom a link in a different language than the end users' Display or browser language, the custom error page will have text in more than one language.

  3. Click Save.


Manage the Okta interstitial page

You can disable the default Okta loading animation (interstitial page) that appears when users are redirected to custom applications. End users are shown a blank interstitial page, instead. This allows you to present a more branded end-user experience.

  1. Go to Settings > Customization.
  2. Click Edit in the Okta Interstitial dialog box.
  3. Select Disable the interstitial page for custom applications.
  4. Click Save.


Exempt specified URLs from login form inspection (IE browser plugin)

Through the Windows registry, you can prevent the Okta IE browser plugin from inspecting specified URLs for the presence of login and change password forms. This effectively creates a blacklist of URLs that the plugin will not inspect. In some cases, this may allow pages to load faster.

  1. Open the Registry Editor: From the Windows Start menu, enter regedit.
  2. Go to HKEY_CURRENT_USER\Software\AppDataLow\Software\Okta\IE Plugin.
  3. On the Edit menu, click New, click String Value, and then name the key SkipUrls.
  4. Right-click the SkipUrls key you created and then click Modify.
  5. Enter the URL(s) that you want the IE browser plugin not to inspect. Separate multiple URLs by a semicolon and a space. Screenshot
  6. SkipURL-reg-key

  7. Click OK.
  8. Close the Registry Editor.

Top