Recently, I wrote about using Okta MFA with Windows 365. As Reddit tends to do, I received “feedback.” How could I dare use Okta with a perfectly lovely Entra ID is available? Today, I am going to take an unbiased look at both Microsoft Entra ID and Okta SSO. Our goal is to find the right solution for enterprise companies. Cost is also a conversation around this as well, which we will cover briefly. We will cover a few different categories below. In Part 1, we will cover the basics:

• What is Entra ID?
• What is Okta?
• Users and Groups
• Authentication
• Policies
• Provisioning**
• Onboarding/Offboarding**
• Security**
• Cost Considerations**

**Covered in Part 2

Let’s get started and see who offers the better solution. As always, there’s no right answer. It comes down to if its gaps are your gaps.

What is Entra ID?

The artist formerly known as Azure AD, is now called Entra ID. As most people know, Entra ID is the cloud version of Active Directory. That is a simplistic approach as Entra ID is so much more. Among the capabilities in Entra ID are:

• Single Sign On (SSO)
• App Integrations
• Authentication like MFA via Microsoft Authenticator
• Conditional Access
• Identity Protection
• Privileged Identity Management (PIM)
• Identity Governance
• Self-Service Portal

Entra ID offers many great features. Outside of being the identity source for the Microsoft Cloud platform, they deliver great capabilities across authentication mechanisms, MFA, and even extend to things like PIM and governance.

In the near future, they have several other products that are coming, which is not the focus for today. Some of those items are ZTNA (Zero Trust Network Access) similar to products like Palo Alto’s Prisma, which Microsoft calls Entra Private Access. They also have Entra Internet Access, which is a Secure Web Gateway (SWG) service that helps tell the Zero Trust story.

We aren’t going to spend too much time on licensing, but this is a collection of the features by Entra license. Most key features in Entra will require P1+ licensing. There is Entra Free, P1, P2, and governance.

What is Okta?

Most of us also know what Okta brings to the table. Okta has grown into a suite of products and services. Their evolution from SSO vendor to a full security suite is respectable. In this article, we will focus on Okta’s OIE (Okta Identity Engine) product. New customers are on OIE and I believe most regular customers have transitioned over from classic. For simplicity, we will focus on OIE, which is a great product.

Okta is an enterprise-grade identity platform that can do more than simply SSO. Their Workforce Identity Cloud suite includes products like:

• Adaptive MFA
• SSO
• Okta FastPass
• Okta Universal Directory
• Workflows
• PIM
• Lifecycle Management
• Okta Access Gateway (OAG)
• Okta Advanced Server Access (ASA)
• Identity Governance
• Identity Threat Protection

Similar to Entra, let’s cover the licenses and features in Okta. OAG and ASA will not be discussed:

As you saw above, Okta has a strict a’la carte model that can be a bit challenging to wrap your head around. We will discuss this more when we get to cost analysis in part two.

Outside of Okta’s recent compliance issues, their platform is strong and tells a good story. They offer a variety of strong tools that give them an advantage in the market. Similar to the challenge with Microsoft, the licensing can really add up. As we will discuss later, OAG, ASA, Identity Governance, Lifecycle Management, PIM, Workflows all have various costs associated. We’ll start our journey with “Users and Groups”

Evaluating Users and Groups with Entra ID and Okta

Users and groups are the lifeblood of Identity and Access Management (IAM). From synchronizing user accounts and groups from your directory to dynamic creation, they are what makes the engine run. Let’s look at how both platforms use users and groups.

How Entra ID Works with Users and Groups

In most circumstances, people leverage Microsoft Entra Connect or the newer Microsoft Entra Cloud Sync to bring users into Entra ID. Of course, there are other ways to bring in users like scripting, manual creation, etc. but most are synchronized from on-prem directories. Now, we ask the question which one do you use?

You can access the full table here, but essentially you need the full client for these capabilities:

• Connecting to LDAP directories
• Device object sync
• Pass-through Authentication (PTA)
• Filtering on object attribute values
• Advanced customization of attribute flows
• Group writeback
• Merging user attributes from multiple domains
• Support for over 150K objects and/or over 50k groups

A major benefit for Entra ID over Okta is support for a Cloud Sync client, which makes life easier and reduces reliance on on-prem infrastructure.

In addition to groups that sync from on-prem, we can also use dynamic group creation to build groups based on attribute values like this below:

The supported properties are:

Entra ID User and Groups Score: 8

How Okta Works with Users and Groups

With Okta, you can leverage agents to integrate with Active Directory, CSV or a generic LDAP server. These integrations require an on-prem component, which makes the integration aspect come up short.

On top of those directories, you also have Okta Universal Directory, which is the built-in Okta local user directly. Directory sync has been challenging for my company. Even Okta Professional Services, pushes you toward using the Okta Universal Directory and synchronizing data to those user accounts.

Some of the value of the Okta user accounts are:

• Unlimited number of users
• Ability to maintain both standard users and non-traditional ones like vendors or contractors
• Real-time syslog that ties up to your SIEM
• Cloud-based LDAP authentication
• Great centralization as you leverage other user profile sources like AD to sync attributes to Okta identities.

The profile design is pretty neat. Basically, every application has a user profile, where you map fields to your Okta user account (that’s where the universal name comes in). A central area where data is being synchronized is very useful and easy. More on this when we discuss provisioning.

Okta has a unique feature called “Custom User Types.” Custom user types will make a copy of the latest Okta user profile with the base 31 attributes. Now, you can add custom attributes and create a distinct profile. A typical use case that Okta references is if a teacher also needed a student account because she wants to take a class. This lets you have two distinct accounts for that user. This isn’t a feature that everyone needs. I could see a standard user and admin as custom user types.

Okta takes some of the ideas behind dynamic groups and takes it a step forward. So, you create/synchronize groups like you do with Entra ID, but they have group rules to make things more exciting.

You can essentially work with any attribute on the Okta profile to use rules to put users into groups. In this example below, we use Okta Expression Language to say any user object that has an objectGUID and assign them to a group that entitles them to Office 365.

You can also use basic conditions to simplify things, which works like Entra ID. The rule testing is also present and is much easier to test than Entra ID. The dynamic nature of Okta mostly makes up for the lack of a cloud sync component.

Okta User and Groups Score: 8

Users and Groups Recap

Users and Groups is pretty close. Entra has an edge with their new Entra Cloud Sync. Okta battles back with their strong efforts with group rules and filtering. Both of them scoring a 8 shows how close it is. Something I don’t get into much is how much easier Okta is to configure.

The Okta onboarding experience is super easy. After you install the agent, the user experience is great. I think Microsoft Entra Connect is a little easier, but not too difficult overall. I don’t cover it much because any decent administrator can do both with ease. With that said, Users and Groups with both platforms checks all of the right boxes. Let’s move onto authentication where things get interesting.

Evaluating Authentication with Microsoft Entra ID and Okta

Authentication is important for any SSO platform. We will discuss the authentication methods available. Both platforms have some unique capabilities, which makes this fun. We will discuss authentication, the user experience, and figure out who has the best product out there. We will flip it around and start with Okta.

Okta Authentication

Okta offers a large family of authentication methods:

• Custom Authenticator/OTP
• Duo
• Email Authentication
• Google Authenticator
• IDP Authenticator (3rd party IDP)
• LDAP Authentication
• Okta Verify
• RADIUS
• Password Authentication
• SMS/Voice Authentication
• RSA SecurID
• FIDO2
• Security Questions/Answers
• Smart Card
• Symantec VIP
• YubiKey OTP

One of the things that I like about how authenticators work in Okta is that you can control enrollment methods (how you’re able to enroll your Okta account) vs. the authentication methods available in policies.

This is an example enrollment policy:

Also, you can decide what authentication methods can be used to reset your account or can be part of an auth policy. As you can see below, you can set that certain auth methods are supported for recovery or authentication.

With Okta, you have 3 main factor types, which are:

• Possession (something you have)
• Knowledge (something you know)
• Inherence (something you are)

Each method has a characteristic:

• Device-bound (associated with a specific device)
• Hardware-protected (require a physical device)
• Phishing-resistant (don’t provide any auth data that can be shared)
• User presence (requires human interaction)
• User verifying (prove a specific user is authenticating)

This table below, summarizes the factor types, methods, and authenticators. Overall, these provides a solid landscape into the ways you can authenticate.

The last thing we should discuss is the key part of their authentication journey with Okta Verify. That is Okta’s MFA application and is critical to their strategy. Let’s discuss it a bit more now.

Okta Verify

Okta Verify is Okta’s application that provides many great features similar to Microsoft Authenticator. Okta Verify today is supported on Android 9+, iOS and iPadOS 16+, macOS12+, and Windows. All of the major browsers are also supported (Chrome, Edge, Firefox, and Safari).

With Okta Verify, we have a few different ways we can authenticate with Okta Verify:

• Input a code

• Push notification and Push notification with number challenge:

• Okta FastPass:

Okta Verify is a strong application that enables MFA in a fairly reliable way. One criticism, which Microsoft does better with is you have a 1/3 chance with number challenge instead of keying in a number.

A few other gaps are:

• The Okta Verify watch app is now EOL. You can authenticate without number challenge as it no longer requires a companion application.
• Only Class 3-strong auth is supported on Android
• Biometrics aren’t supported in Android 12 if its in the work profile
• Number challenge is unsupported on RADIUS and LDAPi
• Okta Verify doesn’t work if HSTS (HTTP Strict Transport Security) is enabled for loopback.

Okta Authentication: 8.5

Microsoft Entra ID Authentication

Entra ID authentication mechanisms can be seen below:

The great thing Microsoft has done recently is introduce certificate-based authentication, which is the best auth method in the Zero Trust era (I said what I said!), but only for Desktops. Please for the love of everyone, do not use that on mobile devices.

Microsoft also supports RADIUS through their NPS Extension. The brilliant thing that they support is when number matching is enabled, it will do TOTP for any RADIUS calls, which provides a more robust experience that the KABOOM that Okta does in those scenarios.

Regarding registration into authentication methods, Microsoft does have a registration campaign capability, which prompts users to setup more secure auth methods. At this time, its limited to Microsoft Authenticator, but I would expect more to come soon:

They also have authentication strength policies that are coupled with conditional access. It’s great as you try to organize your conditional access rules:

Another thing I love is how you can allow users to report suspicious activity. If they do, it will automatically set their device to high risk. This lets you further lean on conditional access. One other area they do a brilliant job on is reporting. Okta reporting can be complicated. Who actually likes reading JSON? Not me, that’s for sure.

Microsoft does an excellent job with exposing registration and reset events, and overall activity. I LOVE dashboards, and here’s a dashboard on this:

Microsoft Authenticator

I’ve written a bit on Microsoft’s authentication brokers. One of those articles can be found here. One of the main differences is Microsoft Authenticator is only available on mobile devices. In the next section, we will discuss MFA more. An example of the flow in Authenticator can be see below:

Basically, Microsoft Authenticator has a few different purposes:

• Handle Microsoft MFA as part of your policies
• Extend more complex authentication flow capabilities like conditional access, FIDO, and more (e.g. device registrations)
• Facilitate password reset

Their implementation of number match can be seen below. It can’t be turned off before you ask:

Overall, Microsoft Authenticator can be a little noisy at times, but it’s a great application. This small application makes anything possible. I would prefer to see more phishing resistant auth methods. The main user experience difference between the two platforms is pressing the user account tile. You can check out my demo here on the iOS experience:

Entra ID Authentication: 8

Authentication Recap

Authentication covered plenty of information. Overall, I think the structure and flexibility of enrollment policy, auth methods, etc. is easier in Okta. We can’t undervalue the love for a desktop client. People love them! Okta Verify delivers on a good user experience across multiple platforms.

Entra ID does an exceptional job leaning into certificate-based authenticate, NPS, and strong architecture. Microsoft has matured quite a bit over the last 12 months on Entra ID. Most people likely haven’t realized how much it has grown. They probably don’t need a desktop client with a strategy focused on Windows Hello for Business (WH4B), but it would help. It’s one thing to say “Entra ID is the greatest.” Our early analysis shows they’re pretty close on the basics.

Authentication Policies of Entra ID and Okta

As we continue down the identity path, we find ourselves at policies. Policies are done differently on each platform. Microsoft uses Entra Conditional Access to deliver policy for its apps. Okta uses authentication policies that it ties directly to applications. Okta uses rules to provide granularity. Both strategies work well, but with different results.

Entra ID Policies

I wrote about conditional access extensively over the last few years like my article here.

If we keep it simple, the policies come down to signals, decisions, and applied policies.

Let’s start with signals. Our signals are:users and groups, devices, apps, locations, etc. Basically, these items:

Signals will use a decision like block or grant access, based on specific capabilities like:

In addition, you have session controls now to combine with the grant access enforcements:

Simply, your app policies run through conditional access to tell a story:

• A group of users accessing Salesforce from Windows or MacOS with machine names that start with CloudPC in the United States require phishing resistant MFA on a compliant device and must re-authenticate every 60 minutes.
• A specific user accessing Microsoft Outlook using modern authentication is granted access if it is protected with an app protection policy.

Overall, Entra Conditional Access is very powerful. It can be confusing. Some challenges like devices that are not marked compliant, policies that conflict, and design issues that can make users lock themselves out. Okta supports multifactor policies that will satisfy the MFA requirements of conditional access as seen below:

One concern that I realized is about policy review and visibility. When you scale up conditional access, manageability is a problem. You can’t really see what policies a given built-in app has. You can for enterprise apps, but apps like AVD and Windows 365 you cannot. That’s a major gap in my opinion that many of us possibly overlook.

Entra ID Protection is the framework for identifying risk behavior. In addition, it integrates directly with Conditional Access to make access decisions. Data can be shipped to your SIEM for investigations as well. There are a few companies who have integrations like:

• Crowdstrike
• KnowBe4 Security Coach

I will update that list more as I find other integrations.

Now, we can move on to discuss policies capabilities in Okta.

Entra ID Policies: 8.25

Okta Authentication Policies

Okta auth policies are a good example of what Okta does well.

Firstly, you can have multiple rules and set priority for different use cases:

As far as the rules themselves, there are many options you can use.

• User Types
• Group Membership
• Device State (Registered or Not)
• Device Assurance Policies e.g. minimum OS versions, passcode, jailbreak detection. TPM, etc. (more on this one shortly)
• Lockdown to platform
• Network Ranges
• Risk Level
• Custom Expressions e.g. request.userAgent.contains(“Windows-AzureAD-Authentication-Provider”)
• Client Types (if it’s a Microsoft policy e.g. Legacy Auth)
• Authenticate with (Password/IdP, Possession Factor, Any 1 factor type/IdP, Password/IdP, Any 2 factor types)
• Re-Auth Frequency

It depends on whose policies meet your needs. In addition, you can integrate a few providers like CrowdStrike, Chrome Device Trust, and Windows Security Center (LOL). After the integration, you can use custom expressions to step-up authentication or block access:

Now, let’s move to discuss device assurance.

Device Assurance Policies

You can access the Okta docs on this here as a reference. Device assurance is device compliance, which you can roll into your policy. Microsoft does something similar. Okta even supports the new Chrome Device Trust connectors. You have this list of options available:

Essentially, device trust is only a major factor if you have Chrome Device Trust implemented. Microsoft Intune has a superior set of capabilities without it. The beauty of the ecosystem with Microsoft as you have many friends that have your back!

Okta Policies: 9.25

Final Thoughts on Policies

Below, I’ve made a video to highlight how policies are handled. Honestly, showing you is the only way we can do them justice. Okta lays out policies in a clean and concise way. Entra Conditional Access can be the bane of our existence. Both are very effective, but Okta has an edge.

In my demo, I will show you how Okta policies and Entra Conditional Access function. Manageability is a problem. Luckily, Conditional Access has become a way of life if you have the licenses. We can be effective with either, but minimizing confusion matters. Even for admins, user experience can make the difference. Opinions are subjective, so check it out for yourself.

It’s Half Time!

We’re at the halfway point! Let’s tally the scores so far:

Remarkably, we’re about even. The score shows how Entra ID has grown in the last year. It’s proof that as a core SSO platform, you can use either. The best platform for you comes down to what you need. In the first half, you could use either product have success. At this point, it comes down to licenses. Windows Premium customers would likely be better suited with Okta. Will that hold up after we cover the advanced features? Come back next week to find out. In our next article, we’ll find out!