App sign-on policies allow or restrict access to applications. By default, all Client options in the App Sign On Rule dialog 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 a user is or which groups they belong to
- Whether they're 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 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, be aware that such actors may target the least restrictive CAP rule(s) in your policies. For this reason, make sure that your CAP rules comply with your company's security needs. Consider using an allowlist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:
- Implement an allowlist 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.
MFA and legacy protocols
Legacy protocols such as POP or IMAP don't 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