General customization options

Customize your Okta orgThe Okta container that represents a real-world organization. for your end usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control.. You can configure external apps to manage the end user information and passwords, change language settings and themes, redirect the end users to custom sign-out or error pages, customize the sign-in page, or manage upgrades for the Okta Browser Plugin.

Configure user account

If you provide your users an external application through which to manage their personal information or password, use the options in this section to configure custom redirect links to that application. The links will appear in the end user dashboard, on the Settings > 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.

When making changes to any of the org settings in the User Account section, if it has been more than 15 minutes since you last entered your password, you are prompted to reauthenticate. If multifactor authentication is configured, you are prompted for MFA verification as well.

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.

 

Manage users personal information in a different app

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.

  1. Go to Settings > Customization > General > User Account > Edit.
  2. Select Personal Information is managed by a different application.
  3. Enter a custom message and a link label for end users.
  4. In the Custom link URL field, enter the redirect URL of the website you want users to visit to change their personal information.

 

Manage users passwords in a different app

Select the appropriate option to specify whether user passwords are managed in Okta or by a different application. If you select Password is managed by a different application, you must also enter values in the Expired Password section.

1. Customize Change Password settings

  1. Go to Settings > Customization > General > User Account > Edit.
  2. Select Password is managed by a different application.
  3. Enter a custom message and a link label for end users.
  4. In the Custom link URL field, enter the redirect URL of the website you want users to visit to change their password.

2. Customize Expired Password settings

Redirect your end users whose password has expired to a website that presents your org's password recovery instructions.

  1. Go to Settings > Customization > General > User Account > Edit.
  2. In the Expired Password section, enter the name of the website to which users are redirected when they try to sign in to Okta with an expired password.
  3. In Link URL, enter the redirect URL to the website.
  4. Click Save.

 

Configure optional user account fields

Enable 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. Go to Settings > Customization > General > Optional User Account Fields > Edit.
  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.

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

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. Go to Settings > Customization > General > Optional User Account Fields > Edit.
  2. Set Security Image option to Enabled.
  3. Click Save.

 

Configure your org's 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.
  1. Go to Settings > Customization > Display Language > Edit.
  2. Select a language for your org. See Supported display languages.
  3. Click Save.

 

Customize text on the 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.

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.

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

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.

  1. Go to Settings > Customization > Sign-in Page > Edit.
  2. Customize links, labels, and headings as desired. If you leave a label field blank, Okta will display the default text.
  3. Click Save.

 

Use custom sign-out page

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

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.

  1. Go to Settings > General > Sign-Out Page > Edit.
  2. and select Use a custom sign out page and enter the sign-out page URL.
  3. Click Save.

 

Use custom application access error page

If end users try to access an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. 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.

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.

Note

  1. Go to Settings > Customization > General > Application Access Error Page > Edit.
  2. Select Use a custom error page and enter the redirect URL.

  3. Click Save.

 

Redirect end users to custom page when the target app is unknown

This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, please contact Okta Support.

You can specify where to redirect end users when they visit your custom or org URL directly and Okta doesn't know which app they are trying to access (app context). Authentication flows initiated by applications are unaffected. Authenticated users in that case are still redirected to the initiating app, not the custom redirect URL that you configure in this procedure.

Additionally, you can use this setting to manage where to redirect users following password and MFA resets, user recovery, and other recovery flows. In this way, this feature lets you hide the Okta Dashboard from your end users by sending them instead to a different default application or domainA domain is an attribute of an Okta organization. Okta uses a fully-qualified domain name, meaning it always includes the top-level domain (.com, .eu, etc.), but does not include the protocol (https). that you specify.

Note

This feature also overrides any default redirect URL that may be configured in Enable self-service registration.

  1. Go to Settings > Customization > General > Default App for Sign-In Widget > Edit.
  2. Select Send to Custom URL and enter the redirect URL.

  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 > General > Okta Interstitial Page > Edit.
  2. Select Disable the interstitial page for custom applications.
  3. Click Save.

 

Embed Okta in an iframe

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

  1. Go to Settings > Customization > General > IFrame Embedding > Edit.
  2. Select Allow IFrame embedding.
  3. Click Save.

 

Manage Okta Browser Plugin installation and upgrade

You can configure the Okta Browser Plugin settings to manage the 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 Browser Plugin on their computers.

You can configure the following settings in Settings > Customization > General > Browser Plugin> Edit:

1. IT manages Okta Plugin

OptionWhat it does
Yes

The messages prompting users to install or upgrade the Okta Browser Plugin are hidden.

When this option is enabled, end users must have the browser plugin installed on their device in order to access SWAAn acronym for Secure Web Authentication. SWA is a SSO system developed by Okta to provide single sign-on for apps that don't support proprietary federated sign-on methods or SAML. Users can enter their credentials for these apps on their homepage. These credentials are stored such that users can access their apps without entering their credentials each time. When users first sign-in to a SWA app from their homepage, they see a pop-up message asking if they were able to sign-in successfully. apps from their Okta dashboard.

NoUsers are prompted to install or upgrade the Okta Browser Plugin, if they haven't already done so.

2. Enable Okta toolbar for group

Specify the group(s) that can use the toolbar to access their app outside of Okta.

3. Security Warning

OptionWhat it does
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 warningSelect if you want to display a warning when end users try to log in to an org that is not their primary org.
Specify organizationsYou 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.

 

Manage Okta user communication

To improve customer satisfaction and the user experience, and to help customers and users implement appropriate security practices, Okta may prompt your end users to share their feedback. Any feedback or information that is provided to Okta by the user in response to such communications shall not constitute Customer Data, and any such feedback may be used by Okta to improve our products and services.

You can select to opt out from such communications by updating your preferences on the Settings page of the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console. If you opt out, Okta will not send such communications to your Org’s users. To opt out:

  1. Go to Settings > Customization > General > Okta User Communication> Edit.
  2. Select Opt Out of Okta User Communication for this org.
  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. Go to Settings > Customization > General > Deprovisioning Workflow > Edit.
  2. Select Enable Deprovisioning Workflow.
  3. Click Save.

 

Enable JIT provisioning

Just In Time (JIT) provisioningusers are created/updated on the fly using the SAML attributes sent as part of the SAML response coming from the Identity Provider. The A user is created during initial login to the Service Provider and updated during subsequent logins. Turning on JIT Provisioning is normally a configuration value in the Service Provider. enables automatic user account creation in Okta the first time a user authenticates with AD Delegated Authentication, Desktop SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones., or inbound SAMLAn acronym for Security Assertion Markup Language, SAML is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) and a service provider (SP). The SAML standard addresses issues unique to the single sign-on (SSO) solution, and defines three roles: the end user, the IDP, and the SP. Here's how SAML works through Okta: SP-initiated flow: the end user requests (principally through a browser) a service from the SP. The SP requests and obtains an identity assertion from the IdP (in this case, Okta). On the basis of this assertion, the SP can decide whether or not to authorize or authenticate the service for the end user. IdP-initiated flow: with Okta as the IdP, an end user goes to the Okta browser and clicks on a chiclet, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated..

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 a custom URL domain

You can customize your Okta org by replacing the Okta domain name with your own URL domain name. With your branding on all URLs, you can create a seamless experience for your users. For example, if the URL of your Okta org is https://example.okta.com, you can configure a custom URL for the org such as https://id.example.com.

For detailed information on usage and set up, see the Customize the Okta URL Domain guide.

 

Related topics

Manage dashboard tabs for end users

Configure a custom Okta-hosted Sign-In page

Configure a custom error page

Top