Can Okta override group membership to deny specific user access to an app? Skip to main content
How satisfied are you with the Okta Help Center?
Thank you for your feedback!
How satisfied are you with the Okta Help Center?
Very Dissatisfied
Very satisfied
Enter content less than 200 characters.
Ask Search:
Tom ConklinTom Conklin 

Can Okta override group membership to deny specific user access to an app?

Does Okta have the ability to assign a group to an app but set an override for a specific user so that one user, although a member of a group, does not get the app assigned to them?

For example can I push an engineering group to Dropbox, but set an override so that "John Smith" who is part of the engineering group does not get Dropbox?
Jerrell GaryJerrell Gary (Okta, Inc.)
Hello Tom,

Here is some archive documentation that shows how Okta uses Sign-On Policy for Applicaitons.

You can add an app-based sign-on policy, which allows you to create rules allowing or restricting access to applications based on location or users and groups. 

To add a new sign on policy, find the app from which you wish to set up a policy:

From the Administrative Dashboard, go to the Applications tab.
Click Applications and find the desired app.
Click the Sign On tab for the app.
Scroll down to the Sign on Policy section.
Click the Add Rule button. The App Sign On Rule page appears.
Creating a Rule

Enter a name in the Rule Name field
Decide to whom the rule applies by selecting an option under the People section.
Users assigned this app – applies the rule to all users who are assigned this specific app.

The following groups and users – fields open allowing you to assign the rule to groups or specific users who have been assigned the app.
You can exclude specific groups and users from the policy rule by selecting Exclude the following users and groups from this rule checkbox.

The Location section allows you apply the policy by location: Anywhere, On network, and Off network.
If you select On network, the global list of "on network IPs" define which IPs are on or off network. This list is shared by Desktop SSO and Multifactor Authentication.


The Access section allows you to choose the conditions by which sign on is allowed for the app. You can indicate a maximum time allowed for re-authentication (SAML apps only) or require a multifactor prompt.
Prompt for Re-authentication
Re-authentication allows you to to indicate the maximum time for valid authentication. After this time period, the user must authenticate again. Re-authentication is available for all SAML apps on an app-by-app basis.
Note: Since SWA apps do not support re-authentication, you cannot change the sign-on method from SAML to SWA if re-authentication is selected.
Prompt for Factor
This option forces users to choose a MFA option. The Multifactor Settings link takes you to the Multifactor Authentication page, where you can choose your factor(s).
Click the Save button after entering policy specifications
Prioritizing Rules
Set rule precedence by clicking the blue arrows to set the priority number. For example, a rule with a priority value of 1 has first priority and takes precedence over all other rules.  

Managing Rules

 To edit a rule, click on the pencil icon and select the Edit rule option.
 To disable a rule, click on the pencil icon and select the disable rule option.
 To delete a rule, click the X icon.

User Experience

When users are blocked from an app
Srinivasa GayamSrinivasa Gayam
Thanks Jerrell. Can we go an extra step and hide the chiclet completely from the user  (instead of locking it using the procedure mentioned above using denied option) and if provisioning was enabled on that chiclet then dont provision it to the denied user or list of users defined in that rule (thus saving cost on licenses). Is that possible? Or may be something like "Exclude Users" option under Assignment tab for any give app. I know we can do this manually but its not fun.