Something I've been thinking about recently is that a full web browser is a hard dependency of OAuth2-based systems. That's 20-30 million lines of code even for the simplest systems, even though you're basically just using the browser as a form renderer and a central space to store tokens.
I feel like there's room for a simpler protocol designed to operate on HTTP plus a minimal UI language (maybe JSON-based) used to describe forms for granting access. This would make it much easier to develop for devices that don't have browsers. You could even make CLI interfaces for authorization flows.
> and integrated over time 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…
>> and integrated over time
> I'm reading too much into this sentence fragment and it fills me with fear.
I know it doesn't cover everything Auth0 and Okta presumably provide, but Keycloak is OSS and has RedHat support, and is honestly one of the best IDPs I've ever used in terms of capabilities and friendliness. I know there's also the ory suite in the more cloud-native/recent space, though I can't personally speak to its maturity. Maybe I'm biased by the large bank I currently work at, but in general, it seems like IAM…
I’ve started using KeyCloak by default for my personal projects. Once you know how to integrate it and configure it, you never have to worry about users or roles again. I haven’t used the groups feature yet but I’m optimistic considering how easy Keycloak is to configure. Overall it’s a great tool to have in your tool belt.
There's just so much value in the fact that I can run it locally, deploy it wherever, play with it and learn it for free and even feel safe enough to expose it publicly due to its maturity and backing. As long as I stick with the standards (remind yourself and your users "you build OpenID Connect clients, not 'keycloak' clients," I can even (easily) move somewhere else if I want, and now I understand Oauth2/OIDC better and probably have a much more scalable authn/z system in place thanks to the way federated authn asks you to design your (fine-grained) authz.
If anyone's looking for an Auth0 alternative, come check out FusionAuth!
It's been built from the ground up for developer experience with a distinct lack of jargon, amazing customizability, an API first approach and great docs. Plus, enterprise features too, including SSO/SAML, OIDC, and more.
More information on the ppt Auth0 200M ARR 50% Growth 120%+ Net Retention Rate https://investor.okta.com/static-files/83f1811e-2f92-4c08-a1... What a great acquisition. Congrats to both teams!
Really? I am in this space and didn't see this at all. Auth0 (and other competitors) seemed to be growing quickly. I don't know why they wanted to sell; must be a really good offer + some synergies.
I hope this gives rise to another, smaller viable party outside of Amazon, Google, and Microsoft. Perhaps I'm jaded, perhaps hopelessly biased - but I can only see this as a net negative. Okta's open source packages receive a pitiful amount of attention (for example: https://github.com/okta/okta-oidc-js/issues?q=is%3Aissue+is%... ) with forks almost becoming a requirement. Auth0 by contrast has been "on the ball" for…
Have you heard of https://fusionauth.io/ ? I'm not a user of the product, but I know some of the folks behind it. Might be time for them to shine here.
Thanks for the mention. We already do see quite a few Auth0 converts. I expect to gain a lot of new customers as a result of this merger in the coming months. No complaints here.
That's the same fear some people have about password managers... IMO, the answer is simple: I would rather security be done by a company where security is THE feature. In other words, I trust 1Password's security team over, say, Hulu's or something.
Sure, but it's not a 1-1 comparison. If Hulu gets compromised you only lose your (hopefully unique) Hulu credentials. If your password manager gets compromised a single attacker gets access to _all_ of your accounts. The security standard for a password manager is much, much higher than pretty much any other service. Password managers are still the best option for most cases, but having to put such an incredible amou…
The problem is a password manager becomes such a valuable target. Sure, they have more security resources given the nature of their business, but it's that password management company's security staff versus a world's-sized quantity of potential bad actors, and one of those two groups has more resources than the other.