I'm reading too much into this sentence fragment and it fills me with fear.
I smell breaking domain changes in the future. They can't allow the .auth0.com tenants to operate as-is forever, which means existing tenants will get grandfathered in and eventually forced off the .auth0.com domain onto okta's domains.
I smell messy login sites in the future. I like Auth0's implementation of their Universal Login page, which didn't require JavaScript. In the quest for 'one single brand identity' someone will force a migration to Okta's login implementation instead.
That will come with changing client IDs, client secrets, M2Ms and everything else needed in their setup.
I might as well create a Jira ticket for this now.
The idea of outsourced identity is just so contradictory it makes my blood pressure shoot up when people sincerely suggest it.
I'll make an exception for Office 365 / AAD when an organization has already got their userbase added, but after that I'd wager if an org is big enough to need their own federated authX, then they're big enough to deploy IdentityServer and be done with it.
Welcome to the future of the internet and web! Originally everyone was supposed to run their own servers and websites, but instead we have... The cloud?
Hardly surprising that it didn't stop with that, and today you can basically build an app on 100% rented hardware/software via services. So if we're already outsourcing everything else, why not identity?
That's a bad wager to make. In B2B it's not unusual for small, under-resourced companies to have big customers that all require an integration with their own identity solutions.
That’s my point: IdentityServer (for example) is what enables any org capable of running a website themselves to integrate with other OIDC-conformant identity solutions via federation without having to cede any control over their identity system.
A good business case is a where a company (or public department) outsources their identity system to a company that doesn't have a 24/7 emergency phone line and people can't login and it's a business emergency - but I recognize this scenario is the same as "outsourcing is cheaper than in-sourcing, but outsourcing with the same level of quality and service as in-sourcing costs more than in-sourcing". YMMV.
Because Okta just acquired Auth0. If we look at previous acquisitions, the usual flow is something like this:
1) Company A acquires company B, promises nothing will change
2) Company A hints that company B will slowly be integrated into Company A
3) Everything Company B did becomes deprecated and migration plans are made for 70% of features to get integrated into Company A
4) Users who need the rest of 30% need to find a different service when things start to get turned off
I see no reason why this Okta/Auth0 acquisition would be different. Especially anything that is branded as Auth0 will disappear or get renamed to Okta. So at least the domain will change, which will require both infrastructure, backend and frontend changes most likely. Sucks, as the change is not needed and doesn't improve anything, it's just needed for Okta to rebrand Auth0.
There are companies that keep purchased brands for years and years. Costs may go up as it becomes "legacy", but corporations do what makes sense.
To assume any product/brand is going to exist indefinitely is unrealistic unless you as a customer have that in your contract (and even then mergers break this routinely).
I'm reading too much into this sentence fragment and it fills me with fear.
I smell breaking domain changes in the future. They can't allow the .auth0.com tenants to operate as-is forever, which means existing tenants will get grandfathered in and eventually forced off the .auth0.com domain onto okta's domains.
I smell messy login sites in the future. I like Auth0's implementation of their Universal Login page, which didn't require JavaScript. In the quest for 'one single brand identity' someone will force a migration to Okta's login implementation instead.
That will come with changing client IDs, client secrets, M2Ms and everything else needed in their setup.
I might as well create a Jira ticket for this now.