On This Page

Create an Okta app integration

Before you can sign a user in, you need to create an Okta app integration that represents your web application.

  1. Sign in to your Okta organization with your administrator account.

    Go to Admin Console

  2. In the Admin Console, go to Applications > Applications.

  3. Click Create App Integration.

  4. Select OIDC - OpenID Connect as the Sign-in method.

  5. Select Web Application as the Application type and click Next.

    Note: It is important to choose the appropriate application type for apps that are public clients. Failing to do so may result in Okta API endpoints attempting to verify an app's client secret, which public clients aren't designed to have, and would break the sign-in or sign-out flow.

  6. Enter a name for your app integration (or leave the default value).

  7. Enter values for the Sign-in redirect URIs. This is the callback described in Understand the callback route. Add values for local development (for example, http://localhost:8080/authorization-code/callback) and production (for example, https://app.example.com/authorization-code/callback).

    If your OpenID Connect client has multiple redirect URIs and you want to use a single redirect URI with a wildcard for the subdomain, select the Allow wildcard * in sign-in redirect URI checkbox.

    Caution: The use of wildcard subdomains is discouraged as an insecure practice, since it may allow malicious actors to have tokens or authorization codes sent to unexpected or attacker-controlled pages. Exercise caution if you decide to include a wildcard redirect URI in your configuration.

    See the parameter Details section on the Apps API Reference page for configuration guidance on the use of wildcard subdomains.

  8. Add the Base URI of your application during local development, such as http://localhost:3000. Also, add any base URIs where your application runs in production, such as https://app.example.com.

  9. Assign the group that you want (if you set Group Assignments for your app) or leave the Everyone default. See the Assign app integrations (opens new window) topic in the Okta product documentation for instructions on how to assign the app integration to individual users and groups.

  10. Click Save to finish creating the Okta app integration.

  11. On the General tab, the Client Credentials section shows the client ID and client secret values for your app integration.

  12. Copy the Client ID and Client secret values using the Copy to Clipboard button beside each text field. You need to copy some values into your application later, so leave your Admin Console open.

  13. In the General Settings section, click Edit and scroll down to Login. Include a URI in the Initiate login URI box to have Okta initiate the sign-in flow. When Okta redirects to this endpoint (for example, https://example.com/login), the client is triggered to send an authorize request. This URI is also used when users reset their passwords while signing in to the app. Okta redirects the user back to this URI after the password is reset so that the user can continue to sign in.

Enable refresh token rotation

You can choose to get a refresh token along with the access token and/or ID token.

The default refresh token behavior is Use persistent token for web apps.

Rotating refresh tokens is an Early Access feature. You can enable an Early Access (Self-Service) feature for your org in the Settings > Features page inside the Admin Console.

To enable refresh token rotation in your app integration, do the following:

  1. Open the web app integration that you just created and select the General tab.
  2. Scroll to the General Settings panel, and click Edit.
  3. In the Allowed grant types, select Refresh Token.
  4. In the Refresh Token section, select Rotate token after every use.

    Note: The default number of seconds for the Grace period for token rotation is set to 30 seconds. You can change the value to any number between 0 and 60 seconds. After the refresh token is rotated, the previous token remains valid for this amount of time to allow clients to get the new token. Using a value of 0 indicates that there is no grace period.

Enable Trusted Origins

To reduce possible attack vectors, you need to explicitly define the Trusted Origins that can access the Okta API for your app integration. Cross-Origin Resource Sharing (CORS) allows JavaScript hosted on your website to make a request using XMLHttpRequest to the Okta API with the Okta session cookie. For instructions on setting trusted origins, see Grant cross-origin access to websites.

Note: You should only grant access to specific origins (websites) that you control and trust to access the Okta API.