Most of your business-critical applications are provisioned and authenticated through your identity provider. That’s a great starting point. This already saves you tons of work creating, updating, and deleting user accounts in various applications. However, the users are still required to sign in with a username, lengthy password, and 2-factor authentication (2FA). Each day, on every device they want to use. Why? Because you want to make sure your data is safe, and configurations like shorter session lengths and complicated passwords help mitigate risks. Right?

At NextNovate, we often see security being achieved at the cost of user experience. Something that’s unnecessary and unwanted, we believe. A lot of ‘friction’ in the sign-in process for the end-user has been deemed a necessity to keep critical information safe. Did you know there are options available to lower end-user friction while maintaining a high (or even higher!) security level? Leveraging available contextual information can help during the sign-in process to determine the authenticity of the request and lower friction; win-win!

What is ‘context’?

During a sign-in, modern identity providers like Google and Okta can use available information that we call ‘context’. Think about:

User information:

• User attributes
• Group memberships
• User status

Device information

• The IP-address
• The location (perhaps derived from IP)
• The device type
• The security posture of the device
• Information about the device

And lots more, we won’t discuss in-depth. The bottom line is that signing in is not a case of merely checking the credentials anymore. With all available context, we can create some truly smart solutions.

How does context influence authentication?

In an ideal scenario, we require the minimum amount of effort for an employee to sign in to a business application, while maintaining maximum security. However, If organizations opt to make every sign-in a hassle, we’ll never achieve the goal of minimizing the friction experienced by the end-user. On the other hand, if we stop testing the user on the validity of his sign-in, how will we protect our valuable data? This is where context comes into play.

With Context-Aware Access (Google) or Authentication Policies & Device trust (Okta) you can create policies where different applications and sign-ins require different information. This allows you to create different risk levels between applications and gives you the ability to require more or less friction during a sign-in, depending on the context.

Is a user trying to sign in to Chat on his mobile? A password or fingerprint might be enough! Is the same user, later on, trying to manipulate business-critical information in the ERP system? We’ll only allow this on a company-owned computer, with up-to-date protection and within the business networks – and of course the fingerprint.

Application Authentication Policies

Application Authentication Policies simply allow you to configure different policies depending on the application. For instance, in Okta, you can create a policy and assign this policy to any of your applications. Then, in the policy, you can create different rules and prioritize these. There always is a catch-all, for sign-ins that do not meet any of the rules.

Device trust

With Device Trust integrations (IDP), the identity provider gathers more information specific to the device during sign-in. Think for instance about information about the security posture of the device, generated by the anti-virus software on the device. Or information about the management status of the device: If the device is managed by an MDM, it will meet certain configuration requirements.

If the IDP is aware of information like this during the authentication process, administrators can create rules that limit the friction for the end-user, while still maintaining or even bettering the security posture. You can for instance allow users to only use biometrics while authenticating on managed and secure devices.

Differences between Google Workspace and Okta

Okta and Google both provide controls to implement Context Aware authentication. The main difference is that Okta is foremost an Identity and access management suite. For Google Workspace, this is only a small part of the services offered. As with many implementations of Google, the services are good and reliable, but only focus on the essentials. Do you need fine-grained controls or best-in-class integrations with third-party services? Okta is your go-to party.

Need help or want to learn more?

At NextNovate we are passionate about creating the best possible experiences in the digital workspace. And, we are eager to help you in your quest to achieve this for your organization. Feel free to reach out to us if you want to know more about this topic.