Set up your org

This guide outlines how to set up your Okta org with some basic, but important, settings and how to configure it for different use cases.

Set up your org with these steps

Create your Okta account.
Create user accounts.
Create a user group.
Enable an embedded Sign-In Widget.
Create an app.
Set up your org for different use cases.

Create your Okta account

If you don't have an Okta Identity Engine org, you need to sign up for an Okta account and an Identity Engine org.

Tip: To get started quickly, you can sign up for an Integrator Free Plan org.

Sign up (opens new window) for an Okta account.

After you sign up, Okta sends a verification email to the email address that you provide.
Using the activate link in the email from Okta, activate your account and provide a new password. Okta redirects you to the Admin Console of your new Identity Engine org.

The email and password that you use to create your account are used as your admin credentials. Your account is automatically created as an admin with the Super Administrator role.

Create user accounts

After you get access to your org, create two user accounts.

Users are assigned to non-administrator user groups either during or after their creation. Admins must assign users their admin role after their creation.

Create two test accounts

Create two test accounts to test the end-user experience for your apps.

Sign in to your Okta org with your admin account.
- Select Admin in the upper-right corner of the page. You're redirected to the Admin Console.
Go to Directory > People to view the existing users.
Select Add Person.
Configure your user like this:
- First name: John
- Last name: Doe
- Username: john.doe@example.com
- Primary email: john.doe@example.com
- Secondary email: Enter your email address that you used to create your Okta account

Note: Okta supports 3-byte encoded UTF-8 characters for these values.

For Activation, select Activate now.
Select I will set password, and enter a password.
Clear the User must change password on first login checkbox.
Select Save and Add Another.

Create a second test account.

Configure your user like this:
- First name: Alex
- Last name: Doe
- Username: alex.doe@example.com
- Primary email: alex.doe@example.com
- Secondary email: Enter your email address that you used to create your Okta account
For Activation, select Activate now.
Select I will set password, and enter a password.
Clear the User must change password on first login checkbox.
Select Save and Add Another.

For more information about creating users, see Add users manually (opens new window).

Activate the accounts

If you don't activate your test accounts when creating them, you can activate them with this process.

In the Admin Console, select your name in the upper right corner of the page. Copy your domain to your clipboard.
In your browser, open a private browsing window. For example, if you're using Chrome as your browser, open a new incognito window.
Paste your domain into the address bar.
Sign in to your org as alex.doe@example.com.
When prompted, follow the steps to set up Okta Verify.
Select Continue.
Close the window.

Use the same process when you activate other accounts.

Create a user group

Creating user (role) groups and assigning users to them is often done by an automated import process for large companies. However, you can also assign users to groups with a manual, per-user process.

For basic testing scenarios, create a group called Retailers. Assign your John Doe test account to it.

Create a group

In your Admin Console, go to Directory > Groups to view the existing groups in your org.
Select Add group.
Enter Retailers as the name for the group.
Enter All retailers as the description for the group.
Click Save.

Add a user to the group

Under the list of groups, select the Retailers group. Refresh the page if you don't see the group.
Click Assign people.
Click Assign + next to John Doe’s name.
Click Done.

You can embed the Okta Sign-In Widget in your apps rather than have it hosted by Okta. Enable an interaction code to allow communication between the widget embedded in your app and your Okta org.

If you’re using a custom authorization server for your app, you need to enable the interaction code for that particular authorization server.

Enable interaction code for your org

In the Admin Console, go to Settings > Account.
Scroll down to Embedded widget sign-in support, and then click Edit.
Select Interaction Code.
Click Save.

By selecting Interaction Code, admins can use the interaction code as a grant type for their OpenID Connect app integrations and authorization servers.

If you don't select it, then Okta hides the interaction code as a grant type.

Note: You can't use the interaction code for any OpenID Connect app integration or with any access policy rule of an authorization server.

Enable interaction code for a custom authorization server

If you’re using a custom authorization server for your app, follow these steps. If you aren't using a custom authorization server, go to the next section.

In the Admin Console, go to Security > API.
Under Name, select the authorization server to edit.
Select the Access Policies tab.
Click the pencil icon under the Actions column for the default policy rule.
Select IF Grant Type is > Advanced.
Select the Interaction Code checkbox.
Select Update Rule.

Note: If the Interaction Code checkbox doesn’t appear, the Interaction Code grant type isn’t enabled for your org. To enable it, go to Settings > Account > Embedded widget sign-in support. See Verify that the Interaction Code grant type is enabled.

Create an app

Create an app integration that represents the app you want to add authentication to with Okta. For a basic app configuration, follow these steps to set up a web app: Create an app.

Note: When you follow those steps, ensure that you enable interaction code in the app.

If you have a particular type of app that you want to create, see the following types:

Native app

Native apps are desktop or mobile apps designed for a specific platform. They redirect users to a non-HTTP callback.

Android
iOS

Web app

Server-side apps are used in scenarios where authentication and tokens are handled on the server.

Single-Page app

Single-page web apps run in the browser where the client receives tokens.

React

Set up your app to use the Okta APIs

This step is optional. However, you can use your web app to interact with Okta APIs. Follow the steps in Set up Okta for API access and use the app that you created in the previous section.

Set up your Okta org for your use cases

After you create your app integration in your Okta org, configure your app and org to support the authentication use cases that you're implementing:

For a basic password factor-only use case, see Set up your Okta org for a password factor only use case
For a multifactor use case, see Set up your Okta org for a multifactor use case
For a password-optional use case, see Set up your Okta org for a password-optional use case

Set up your Okta org for a password factor only use case

This section shows you how to set up your Okta org and app to support password factor-only use cases. These use cases are intended to use the password factor without any additional factors (such as email or phone SMS). When you create an app, the app is assigned Any two factors. This is the default policy for new apps. It requires a user to verify their identity with any two enabled authentication factors.

First, assign the Password only policy to your app:

Go to Applications > Applications in the Admin Console, and then select your app.
Select the Sign On tab.
Click Edit in the User Authentication section.
Select Password only for the Authentication policy, and then click Save.

Next, check that the password authenticator doesn't require any additional verification:

Go to Security > Authenticators.
Select Edit from the Actions menu on the Password authenticator row.
Scroll down on the Password policy page to the rules section.
Click the pencil icon next to the Default Rule to access the Edit Rule dialog.
Select Not required in the AND Additional verification is section.
Click Update rule.

Set up your Okta org for a multifactor use case

This section shows you how to set up your Okta org and app to support the multifactor use cases. The multifactor use case presented in this guide uses the email and password factors. Perform the following configurations to set up the email and password factors in your Okta org.

Note: The multifactor use cases in this guide implement the password and email factors. However, there are more supported factors that you can use in your embedded authentication app. See Multifactor Authentication (opens new window).

Set up the email authenticator

Open the Admin Console for your org.
Go to Security > Authenticators to see the available authenticators.
Locate the Email authenticator on the Setup tab, and then select Actions > Edit.
Set This authenticator can be used for to Authentication and recovery.
Click Save.

Update your authentication policy with multifactor authentication

Go to Security > Authentication Policies.
Select Any two factors as this is the policy that the app you created is assigned to.
Select Edit from the Actions menu for the Catch-all Rule to access the Edit Rule dialog.
Scroll down to the AND User must authenticate with dropdown menu and select Password + Another Factor.
Click Save.

Note: Because the default authentication policy is a shared policy, changes you make apply to both new and existing apps that are assigned to it.

Set up your Okta org for a password-optional use case

For password-optional authentication, follow these steps first:

Set up the email authenticator for authentication and recovery.
Create a separate group for password-optional users.

To ensure that only specific app integrations can let users sign up without a password, do the following:

Create a user profile policy for password-optional users that adds them to the new group and assign your app to it.
Place this group at the lowest priority (just above the default policy) in the authenticator enrollment policy.

To ensure that only password-optional users can sign in without a password and everybody else is appropriately prompted for it, do the following:

Create a new password-optional authenticator enrollment policy for the group.
Add a global session policy for the group.
Add an authentication policy for the group.
Ensure that password-optional users never fall through to the default policy. The default policy should always have a password as a required authenticator.
Explicitly exclude your main admin account from any further password-optional policies that you create.

Note: See also Set up password-optional sign-in experience (opens new window).

Create a group for password-optional users

Go to Directory > Groups to view the existing groups in your org.
Select Add group.
Enter Password optional as the name for the group.
Enter Group for password optional users as the description for the group.
Click Save.

After you create the Password optional group, add the Alex Doe test account to the group. See Add a user to the group.

To ensure that only specific app integrations can let users sign up without a password, do the following:

Create a user profile policy for password-optional users

A user profile policy determines the minimum information required from a user to create an account. The policy also determines how the user should verify their identity before creating their account.

Go to Security > User Profile Policies.
Click Add user profile policy.
Enter Password-optional user profile policy as the name of the policy. Click Save.
For your new policy, and under Actions, click the pencil icon to edit the policy.
On the Enrollment tab, locate the Profile Enrollment section of the policy and click Edit.
Set Self-service registration to Allowed.
Verify that Required before access is granted is selected for Email Verification.
Set Add the user to group to your Password optional group, and then click Save.
Go to the Apps tab.
Click Add an App to This Policy.
Locate your app integration and click Apply.
Click Close and then verify that the app is in the list of Apps using this policy.

To ensure that only password-optional users can sign in without a password and other users are appropriately prompted for it, do the following:

Create a password-optional authenticator enrollment policy

An authenticator enrollment policy determines which authenticators must challenge a user before they’re successfully signed in. In this case, email is set to Required, while all the other authenticators are set to Optional.

Go to Security > Authenticators.
Go to the Enrollment tab, and then click Add a policy.
Enter Password-optional sign-in policy as the name.
Under Assign to groups, assign the policy to your Password optional group.
Do the following in the Eligible Authenticators section:
- Set Email to Required.
- Set Password to Optional.
- Verify that the remaining authenticators are set to Optional.
Click Create policy.

Create a rule for the policy

Enter Password-optional sign-in policy rule as the name.
Under Exclude users, enter your username to ensure that the policy doesn't apply to your admins.
Leave the other settings at their defaults, and then click Create rule.
Move the new policy immediately above the default policy in the list of policies.

Add a global session policy for password-optional users

A global session policy determines user session length and authentication rules for groups of users. In this case, the policy turns off MFA for all users in the password-optional user group. Therefore, they only need email authentication to sign in.

Go to Security > Global Session Policy.
Click Add policy.
Enter Password-optional global sign-in policy as the name.
Under Assign to groups, assign the policy to your Password optional group.
Click Create policy and add rule. Give the rule a name.
Enter Password-optional GSP rule as the name of the rule.
Verify that Establish the user session with is set to Any factor used to meet the Authentication Policy requirements.
Set Multifactor authentication (MFA) is to Not required.
Leave the other settings at their defaults, and then click Create rule.

Add an authentication policy for password-optional users

Go to Security > Authentication Policies.
Click Add a policy.
Enter Password-optional authentication policy as the name.
Click Save.
Go to the Catch-all Rule of the new policy and select Actions > Edit.
Set User must authenticate with to Any 1 factor type.
In the Possession factor constraints are section, verify the following:
- Verify that no options are selected.
- Verify that Email is listed in the box under 1 factor type.
Click Save.
Select the Applications tab for your newly created policy. Then, click Add app.
Find your app in the list and click Add next to it.
Click Done.
Verify that the app is now listed in the Applications tab of the new policy.

See the Okta Docs (opens new window) for more information on the Admin Console dialogs in this guide:

Edit This Page On GitHub

On this page