On This Page
Okta offers multiple integration options for designing an authentication experience. The two most recommended options are integrating the Okta-hosted Sign-In Widget and the customer-hosted Sign-In Widget. Both of these Okta-built experiences provide easy implementation and maintenance, industry best practice, user self service, and built-in user registration. You can customize the Okta URL domain and the Okta-hosted or customer-hosted Sign-In Widget style. See Customize the Okta URL domain and Style the Widget.
For both Okta-hosted and customer-hosted sign-in experiences, you can configure policies in the Okta Admin Console to determine the behavior of the app.
- Go to Security > API.
- In the Authorization Servers tab, select an authorization server and click the edit icon beside it.
- On the authorization server page, select the Access Policies tab and scroll down to the Rules list.
- Click the edit icon beside the Rule you want to modify. The Edit Rule window appears where you can update the settings for the access policies.
The Okta-hosted Sign-In Widget is considered the easiest and most secure means of integration. This is because the Sign-In Widget itself is hosted by Okta, maintained by Okta, and kept secure by Okta. The Okta-hosted Sign-In Widget is recommended for most integrations. The OpenID Connect authorization code flow is used to redirect users to Okta, where the user authenticates and is redirected back to a pre-configured redirect URI for the application. This design is considered a security best practice.
You can use a custom domain so that your users don't see
okta.com in the URL. The look and feel of the sign-in experience, as well as the enabled features, are all configured within the Okta Admin Console. HTML customization of the page is accessible in the Admin Console, which provides a moderate level of customization to the experience itself.
You can customize your Okta organization by replacing the Okta domain name with your own domain name. This allows you to create a seamless branded experience for your users so that all URLs look like your application.
Okta organizations host pages on subdomains such as
example.okta.com. Using this feature aliases your Okta organization's domain name to another subdomain that you own, such as
- Easy to maintain with no updates to install.
- Hosted and secured by Okta.
- XSS (opens new window) (cross-site scripting) attacks on your application will not affect the sign-in experience.
- Easy to integrate manually or with a generic OpenID Connect client.
- Complex logic changes that require source code access are limited.
- The user is redirected out of the application, to Okta, and then back to the application.
- Moderate maintenance may be required. If using a CDN, maintenance is more limited as it is being kept up-to-date by Okta. NPM packages a specific version of the widget, which means that it may need to be updated in the project periodically. Customized or local versions of the Sign-In Widget source code would require regular updating.
- Still considered very secure if implemented using recommended best practices.
- A great level of source code customization control while being drastically easier, and more secure, than building from scratch.
- Slightly increased risk in security due to Okta not being able to guarantee that the Sign-In Widget has been implemented correctly. Specifically, the application code may have the ability to access the credentials that the user has entered into the Sign-In Widget, which need to be kept secure. This isn't a risk if implemented correctly.
- XSS (cross-site scripting) attacks on your application may result in stolen sign-in credentials.
- Higher level of effort to integrate and maintain compared to the Okta-hosted Sign-In Widget.
- Keeps the user in the application, reducing redirects to and from Okta.
Continue reading about the Okta-hosted Sign-In Widget in the Sign Users In guide.
Continue reading about the customer hosted experience in the Okta Sign-In Widget guide.