You can add an app-based sign-on policy to allow or restrict access to applications.
Note: Some options described in this topic are Early Access features which may not be available in your org. To enable them, contact Okta Support.
By default, all Client options in the App Sign On Rule dialog box are pre-selected. To configure more granular access to the app, selectively apply conditions as you create one or more prioritized rules based on:
- Who users are and/or the groups to which they belong
- Whether they are on or off network or within a defined network zone
- The type of client running on their device (Office 365 apps only)
- The platform of their mobile or desktop device
- Whether or not their devices are Trusted
Important to know about the User-Agent
Okta’s Client Access Policies (CAPs) allow you to manage access to your enterprise apps based on the client type and device platform. Okta CAPs evaluate information included in the User-Agent request header sent from the users’ browser. Because the User-Agent can be spoofed by a malicious actor, you should consider using a whitelist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:
- Implement a whitelist consisting of one or more rules that specify the client type(s) + device platform(s) + trust posture combinations that will be allowed to access the app.
- Require Device Trust or MFA for app access.
- Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.
Important to know about MFA and legacy protocols
While you can configure your App Sign-On Policies to prompt end users for MFA, be aware that legacy protocols such as POP or IMAP do not support MFA even if MFA is configured for Okta sign-in.
To ensure that authentication to apps remains secure, Okta strongly recommends that you evaluate the following:
- The use of legacy protocols with Microsoft Office 365 applications and whether to disable them if necessary
- Whether to enable Modern Authentication on Microsoft Office 365 tenants for improved security
- From the Administrative Dashboard, go to the Applications > Applications.
- Click the desired app.
- Click the Sign On tab.Screenshot
- Scroll down to the Sign On Policy section.
- Create a rule:
- Click Add Rule.
- Enter a name in the Rule Name field.
- Decide to whom the rule will apply by selecting an option under the People section.
- Users assigned this app – Specify the users who are assigned this specific app.
- The following groups and users – Assign the rule to groups or specific users who have been assigned the app.
Location — Specify the location to which you want the policy to apply. Available options are Anywhere, In Zone, or Not in Zone.
If you select In Zone, enter the name of a zone. You configure zone names in Security > Network. For details, see Network.
Client — Choose the conditions that you want to trigger the action(s) you configure in the Access section:
- (Microsoft Office 365 apps only) Under If the user's client is any of these, select the client type(s) that you want to trigger the action(s) you configure in the Actions section (Web browser or Modern Auth client). For details, see Office 365 Client Access Policies.
- Under And the user's platform is any of these, select the mobile and/or desktop platforms that you want to trigger the action(s) you configure in the Access section.
Device Trust — Specify the trust status of the device that you want to trigger the action(s) you configure in the Access section. The Trusted and Not Trusted options are only selectable if Device Trust is configured in Security > Device Trust. Okta Device Trust determines devices to be trusted based on the presence of a trust signal (MDM enrollment; certificate; support for Universal Links).
- In the setting When all the conditions above are met, sign on to this application is select either Allowed or Denied.
- (SAML apps only) Select Prompt for re-authentication and specify how frequently you want users to be prompted to re-authenticate. The time period you specify begins from the moment the user last authenticated into Okta. This feature is available for all SAML-configured apps.
Note: Because SWA apps do not support re-authentication, you cannot change the sign-on method from SAML to SWA if re-authentication is selected.
- Select Prompt for factor if you want to require users to choose an MFA option, and then specify how frequently you want users to be prompted. The Multifactor Settings link takes you to the Multifactor Authentication page, where you can choose your factor(s).
Set rule precedence by clicking the blue arrows to set the priority number. A rule with a priority value of 1 has first priority and takes precedence over all other rules.
- To edit a rule, click the pencil icon and select the Edit rule option.
- To disable a rule, click the pencil icon and select the disable rule option.
- To delete a rule, click the X icon.Screenshot
If a user is blocked from an app, the following message will be displayed:
Note: Early Access features may cause blocked users to see a Sign in failed message rather than instructions above. This is a known issue.