y8265 (y8265) asked a question.
I'm having a hard time understanding the authorization flow in app-specific authentication policies, and am looking for specifics on how this is implemented.
My understanding of the flow is that Okta is only involved during initial authentication to the application, and once this is completed authentication to subsequent applications is taken care of via auth cookies, which means Okta is no longer involved in any subsequent request. My question is, how are individual application authentication policy criteria (specific device state/platform, IP range, group membership etc...) checked? Are these checked even after authentication to Okta itself (IdP-initiated) and after an auth cookie is created? And if so, how often are these criteria checked? If I changed an authentication policy to check for specific IP addresses, for instance, would all existing sessions coming from excluded IP's be instantly closed?
Hi & Thanks for your question!
So first and foremost, org sign-on policies are evaluated first and then then individual Application sign on policies are evaluated. They are really there for more granular control over certain applications, but do not necessarily override the org policies for initial login.
A good example is I am ok with allowing my employees to access their Okta homepages from home, but not so ok with them accessing certain applications unless they are connected via VPN. This condition can be specified in an app sign on policy.
These give good examples : Configure Okta Sign-On and App Sign-On Policies
Configure an app sign-on policy will also help to build it out and talks about some of the finer points on an app sign on policy too.
As for changes to policies when considering active sessions, Okta does state that "Note: After you create a new policy, you must close all active sessions for the new policy to take effect."
Source - Configure Okta Sign-On and App Sign-On Policies
Please let me know if this did or did not help to address your question. Glad to help further if need be! Thanks!!
I see, thanks for the response Don. The links you gave direct to Okta classic - are things the same on Identity Engine?
Hey, apologies for the long delay. OIE is pretty similar, with different terminology (mostly). In this case, it would first run the user through the "global session policy", then the "authentication policies".
Here Okta talks about what an authentication policy is "Authentication policies share some conditions with global session policies, but they serve different purposes. A user who gains access to Okta through the global session policy doesn't automatically have access to their apps. You can create a unique policy for each app in your org, or create a few policies and share them across multiple apps. You can also use Okta preset policies for apps with standard sign-on requirements. If you decide later to change an app’s sign-on requirements, you can modify its policy or switch to a different policy."
See links for Authentication Policies and Global Session Policies and here for Sign-on Policies & Rules
I hope this helps!! Thanks and feel free to write back with any questions.