Okta’s platform essentially does 3 things: authentication, authorization & user/directory synchronization. Depending on what your goal is determines how you should think about this.

Within the identity field, Okta is an IdP, identity provider. Applications like Notion, GitHub, Slack are called SPs (service providers).

Most IdPs like Okta offer “workforce identity” & “customer identity”. There’s now even claims that these are Gartner magic quadrant segments like “CIAM” (Customer Identity & Access Management. I mention this because it can get confusing when Okta is brought up. Okta owns Auth0 & Okta has their own CIAM platform. For example, Adobe cloud products use Okta for authentication on the backend, and if you a consumer, log into Adobe, you’re actually using Okta. This muddles some of the advice you read online.

It sounds like you’re interested in the workforce side of IAM. I’ll explain here why someone would go with Okta & what the use cases are within each. That should help with determining what type of alternatives to consider depending on the problem you’re seeking to solve.

Authentication

There’s authentication to the IdP (logging into Okta) and then Authentication to the Service Provider (SP) (Okta logging you into GitHub)

IdP Authentication (logging into Okta)

The reasons you might want to standardize authentication for your workforce:

• Better employee experience, it’s nice to not manage a million MFA integrations

• Standardization for compliance framework like SOC2

  • Easier to enforce MFA at the Okta level and be able to make a blanket statement like “If the service is behind Okta, it conforms to our password policy & mfa guidelines

• Meet requirements for more niche compliances like FedRamp & FIPS compliance

  • https://www.okta.com/blog/2023/07/a-summary-of-oktas-fips-compliance/

  • (I’ve successfully argued that Okta FedRamp + FIPS compliant MFA + AWS Gov Cloud hosted was enough)

• Enforce device trust - meaning only devices that are managed can access company systems

• Ensure immediate cease of further access for terminated or compromised accounts

• Ensure greater visibility of workforce access logs centralized in one place

SP Authentication (Okta logging you into a service)

There’s two prevailing authentication protocols that are most common, with SAML being by far the most common and usually what triggers an “SSO tax”. Every major identity provider supports at this point. You can integrate with a SAML SP from: Okta, Rippling, Google Workspace, etc.

The only unique benefit to SAML that Okta officers is the ability to set a unique signed certificate for each SAML integration (https://support.okta.com/help/s/article/Replace-SP-Signing-Certificate-In-OKTA?language=en_US). Some security contentious teams are concerned about a vulnerability in SAML where if the SP doesn’t validate the audience restriction, the SAML assertion could be used for a different service then the one it was intended for. The ability to set unique certificates in Okta helps mitigate this.

OIDC is the other common protocol used for authentication. Sometimes mixed in with oAuth. This is how like “sign in with google works”. Built upon the concept of delegated access, it’s used by sharing the user’s unique identifier (email) to log them into a SP. Okta has a fairly flexible OIDC & oAuth offering that can be beneficial with internal tools especially. If you have a unique need to authenticate your workforce into an internal service that has needs to use oAuth (maybe to delegate access across multiple systems/pull data from Okta during authentication) an complex IdP like Otka might be warranted.

It’s important to note, Okta doesn’t actually manage the user session within SPs. Okta/IdPs often send a SAML assertion, that authorizes the SP to grant a sessions. So if Slack is set to indefinite session length, a user authenticates with SAML, and you disable the Okta account, the user will still be signed into Slack. See User/Directory Synchronization section.

Authorization:

Okta serves as a way to manage permission sets via group membership across an array of services. This could be as high level as “all go engineering gets GitHub”. Or like “users outside of the US can not access this AWS resource”. Limiting who has access to what services is a big part of an IdP. Because Okta has so many integrations, it could be ideal over something like Google Workspace.

Maybe you want to import employee managers into your IdP from Workday, doing that within something like Google Workspace is extremely challenging. Okta makes it easy.

User/Directory Synchronization

Next to SAML, SCIM is the next more ubiquitous standardization for managing users in IdPs/SPs. This is another option that triggers the SSO tax. SAML & OIDC can pass information about users at time of authentication, but not at time of hire or termination. But SCIM does. This is how a service like Okta provisions user accounts, populates SP directory fields, or shares group memberships.

Okta historically has the most amount of SCIM integrations. While both SAML & SCIM are open standards, it’s not common for SPs to broadly support SCIM, instead there’s usually an “integration” with the IdP. Okta has always made custom SCIM integrations challenging too, wanting to review them, or even charge for them.

Okta also has deep integrations with on-prem systems such as Active Directory, Radius, LDAP, etc. If there’s a need to get cloud service identity to an on-prem or legacy system, Okta is has a lot to offer.

Okta has a few more product offerings on their platform such as workflows (Think like workato or zapier), SSH authentication/authorization, and several other niche offerings.