Add Sign On policies for applications

You can add 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.-based sign-on policy to allow or restrict access to applications.

Note: Some options described in this topic are 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. features which may not be available in your orgThe Okta container that represents a real-world organization.. To enable them, contact Okta Support.

By default, all ClientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. 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:

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-AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. 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:

  1. 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.
  2. Require Device Trust or MFA for app access.
  3. Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.
Note: In September 2019, Apple changed the way that Safari reports the device user agent on iPads running on iPadOS. Due to this change, Okta cannot differentiate between app requests coming from macOS devices and app requests coming from Safari on iPadOS devices. For how to mitigate the effects of this change, see App sign-on policies that apply to macOS devices will also apply to iPadOS+Safari requests

Important to know about MFA and legacy protocols

While you can configure your App Sign-On Policies to prompt end usersEnd users are people in your org without administrative control. They can authenticate into apps from the icons on their My Applications home page, but they are provisioned, deprovisioned, assigned, and managed by admins. 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:



  1. From the Administrative Dashboard, go to the Applications > Applications.
  2. Click the desired app.
  3. Click the Sign On tab.ClosedScreenshot
  4. Scroll down to the Sign On Policy section.
  5. Create a rule:
    1. Click Add Rule.
    2. Enter a name in the Rule Name field.
    3. 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.
    4. To exclude specific groups and users from the policy rule, select Exclude the following users and groups from this rule and then specify groups and users.
  6. Configure Conditions:
  7. 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).

  8. Configure the Actions that you want to enforce based on the conditions you specified in the Conditions section:
  9. Access:

    1. In the setting When all the conditions above are met, sign on to this application is select either Allowed or Denied.
    2. (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 an app, sending a SAMLResponse to the configured SP. A session is established with the SP, and the end user is authenticated. 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 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 do not support re-authentication, you cannot change the sign-on method from SAML to SWA if re-authentication is selected.

    3. 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).
  10. Click Save.

Prioritize rules

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.

Manage rules

  1. To edit a rule, click the pencil icon and select the Edit rule option.
  2. To disable a rule, click the pencil icon and select the disable rule option.
  3. To delete a rule, click the X icon.ClosedScreenshot

User experience

If a user is blocked from an app, the following message will be displayed:

Access to this application is not allowed at this time due to a policy set by your administrator.
If you're wondering why this is happening, please contact your administrator.
If it's any consolation, we can take you to your Okta home page.

Note: Early Access features may cause blocked users to see a Sign in failed message rather than instructions above. This is a known issue.

Related topics

From Okta

Office 365 Client Access Policies

Device Trust

External sources

How modern authentication works for Office 2013 and Office 2016 client apps

Using Office 365 modern authentication with Office clients