> Can someone explain why people still choose Okta? I personally feel way more comfortable using GSuite as an IDP.
GSuite as an IDP is very very limited. Sure, it checks that box as "Yes, is IDP"
However if you want to do much beyond "can connect", it's either difficult or impossible.
Take for example you're an organisation that has all employees in GSuite.
You also have an AWS organisation, and need to provide access - well, AWS SSO[1] is the recommended way to do this. I set up the connection, and people can now connect.
However there's some gaps:
There's no automatic user [de]provisioning into AWS SSO, based on GSuite user groups. (You could write some code to do this via the SCIM support in SSO, but you have to maintain it)
There's no way on either the GSuite or AWS SSO side to enforce an MFA check when the SSO session is being set up.
GSuite doesn't let you require an MFA check before authenticating to SAML applications.
AWS SSO doesn't allow forcing MFA check when using an IDP, even though it does if you use it's internal Directory.
Okta, and similar products (can) do those things for you, and allow some of those MFA checks to be based on what endpoint is being used. At least according to their marketing materials and sales people. I've never actually done it myself.
I guess the tl;dr is that Okta provides a lot more options for automation and security glue between the identity provider and consuming application(s).
[1] When I say AWS SSO, I mean specifically the AWS product: "AWS IAM Identity Center (Successor to AWS Single Sign-On)"
Interesting, thank you! I'll note is that GSuite does allow for you to enforce Context Aware Access checks on every SSO, though that does not include a separate 2FA in the traditional sense.
Lack of auto-provisioning seems like the biggest issue to me.
> There's no way on either the GSuite or AWS SSO side to enforce an MFA check when the SSO session is being set up.
I don't know what you mean here but I'm curious if you wouldn't mind?
Much of what you're talking about seems to be when a 2FA is forced. With GSuite it's forced on login, and CAA is forced on SSO, and that's it. If you want other 2FA prompts (such as with AWS) those are configured through that service. I think you're saying that Okta would allow you to force the 2FA on login to and also then when you want to access some other system via SSO it would ask you to 2FA again?
It's only available in the Enterprise plan levels.
> I don't know what you mean here but I'm curious if you wouldn't mind?
Using the prior example where GSuite is my IDP. If I want to require an MFA check before granting access to AWS SSO - I've got no way of doing this.
CAA might help, but if I want to be explicit "Hey, this has access to customer data - we're always going to do an MFA check on this access", there's no good way of doing this.
Using an intermediary like Okta would allow you to do that additional level of checking.
e: To be clear, I'm using AWS SSO as the destination application as an example. There's other applications that you might want to control access to that also have particularly sensitive data where you want to re-verify that someone else hasn't just walked past an unlocked laptop and decided to poke around.
> It's only available in the Enterprise plan levels.
It can be bought separately for Business iirc.
> there's no good way of doing this.
Through GSuite, agreed. But you could just configure the 2FA for the downstream service, no? That's what we did at my company.
> There's other applications that you might want to control access to that also have particularly sensitive data where you want to re-verify that someone else hasn't just walked past an unlocked laptop and decided to poke around.
For sure, I'm not trying to argue or debate or anything, was just curious.
> But you could just configure the 2FA for the downstream service, no?
Only if the downstream service supports it. Lots don't, or at least don't enforce it when you come in via SSO.
AWS SSO being the one I keep coming back to, because it bugs me so much.
For those that do, you now have to also manage the 2FA tokens with that service, using whatever they support. Often that's SMS based 2FA, or maybe TOTP, or their own custom TOTP/Push. Maybe they support FIDO2, but only a single FIDO2 key.
Yeah makes sense, thanks. I think I'm fine with a 2FA on GSuite login + CAA on subsequent SSOs but I do think it would be nice to be able to force another 2FA for sensitive stuff like AWS.
Unfortunately, GSuite seems to move very slowly :\
GSuite as an IDP is very very limited. Sure, it checks that box as "Yes, is IDP"
However if you want to do much beyond "can connect", it's either difficult or impossible.
Take for example you're an organisation that has all employees in GSuite.
You also have an AWS organisation, and need to provide access - well, AWS SSO[1] is the recommended way to do this. I set up the connection, and people can now connect.
However there's some gaps:
There's no automatic user [de]provisioning into AWS SSO, based on GSuite user groups. (You could write some code to do this via the SCIM support in SSO, but you have to maintain it)
There's no way on either the GSuite or AWS SSO side to enforce an MFA check when the SSO session is being set up.
GSuite doesn't let you require an MFA check before authenticating to SAML applications.
AWS SSO doesn't allow forcing MFA check when using an IDP, even though it does if you use it's internal Directory.
Okta, and similar products (can) do those things for you, and allow some of those MFA checks to be based on what endpoint is being used. At least according to their marketing materials and sales people. I've never actually done it myself.
I guess the tl;dr is that Okta provides a lot more options for automation and security glue between the identity provider and consuming application(s).
[1] When I say AWS SSO, I mean specifically the AWS product: "AWS IAM Identity Center (Successor to AWS Single Sign-On)"