Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We've recently moved to Auth0. I'm no security expert. Whats the recommended alternative that provides the same features and price, but without the risks suggested here?


Heya, I work for FusionAuth. We have a comparable product for many use cases.

Happy to chat (email in profile), or you can visit our comparison page[0] or detailed technical migration guide[1].

0: https://fusionauth.io/compare/fusionauth-vs-auth0

1: https://fusionauth.io/docs/lifecycle/migrate-users/provider-...


It's not difficult to implement OAuth2. There are good libraries, and even the spec is not complicated. Or use AWS Cognito.


Constructing a new OAuth2/OIDC Identity Provider from the ground up is an undertaking fraught with complexity – and not of the elegant variety. The reasons are numerous, entrenched, and maddeningly persistent.

1. OAuth2 and OIDC are inherently intricate and alarmingly brittle – the specifications, whilst theoretically robust, leave sufficient ambiguity to spawn implementation chaos.

2. The proliferation of standards results in the absence of any true standard – token formats and claim structures vary so wildly that the notion of consistency becomes a farce – a case study in design by committee with no enforcement mechanism.

3. ID tokens and claims lack uniformity across providers – interoperability, far from being an achievable objective, has become an exercise in futility. Every integration must contend with the peculiarities – or outright misbehaviours – of each vendor’s interpretation of the protocol. What ought to be a cohesive interface degenerates into a swamp of bespoke accommodations.

4. There is no consensus on data placement – some providers, either out of ignorance or expedience, attempt to embed excessive user and group metadata within query string parameters – a mechanism limited to roughly 2k characters. The technically rational alternative – the UserInfo endpoint – is inconsistently implemented or left out entirely, rendering the most obvious solution functionally unreliable.

Each of these deficiencies necessitates a separate layer of abstraction – a bespoke «adapter» for every Identity Provider, capable of interpreting token formats, claim nomenclature, pagination models, directory synchronisation behaviour, and the inevitable, undocumented bugs. Such adapters must then be ceaselessly maintained, as vendors alter behaviour, break compatibility, or introduce yet another poorly thought-out feature under the guise of progress.

All of this – the mess, the madness, and the maintenance burden – is exhaustively documented[0]. A resource, I might add, that reads less like a standard and more like a survival manual.

[0] https://www.pomerium.com/blog/5-lessons-learned-connecting-e...


None of this rings true, and I've implemented both OAuth2 and OpenID Connect multiple times, also reading the specs, which are quite direct. I'm sure you're right that vendors take liberties -- that is almost always the case, and delinquency of e.g. Okta is what started this thread.


It's an AI bot. One for @dang


By the same token, if one can use the keyboard, it does not make them a human. Parrots (the non-stochastic kind) and monkeys spring to mind.


Why do you suspect that?


I have also designed and implemented enterprise grade OAuth2 / OIDC IdP's.

Beyond the aforementioned concerns, one encounters yet another quagmire – the semantics of OIDC claims, the obligations ostensibly imposed by the standard, and the rather imaginative ways in which various implementations choose to interpret or neglect those obligations.

Please allow me to illustrate with a common and persistently exasperating example: user group handling, particularly as implemented by Okta and Cognito. The OIDC spec, in its infinite wisdom, declines to define a dedicated claim for group membership. Instead, it offers a mere suggestion – that implementers utilise unique namespaces. A recommendation, not a mandate – and predictably, it has been treated as such.

In perfect accordance with the standard’s ambiguity, Okta provides no native «groups» claim. The burden, as always, is placed squarely upon the customer to define a custom claim with an arbitrary name and appropriate mapping. User group memberships (roles) are typically sourced from an identity management system – not infrequently, and regrettably, from an ageing Active Directory instance or, more recently, a new and shiny Entra instance.

Cognito, by contrast, does define a claim – «cognito:groups» – to represent group membership as understood by Cognito. It is rigid, internally coherent, and entirely incompatible with anything beyond its own boundaries.

Now, consider a federated identity scenario – Okta as the upstream identity provider, federated into Cognito. In this scenario, Cognito permits rudimentary claim mapping – simple KV rewrites. However, such mappings do not extend to the «cognito:groups» structure, nor do they support anything approaching a nuanced translation. The result is a predictable and preventable failure of interoperability.

Thus, despite both platforms ostensibly conforming to the same OIDC standard, they fail to interoperate in one of the most critical domains for medium to large-scale enterprises: user group (role) resolution. The standard has become a canvas – and each vendor paints what they will. The outcome, invariably, is less a federation and more a fragmentation – dressed in the language of protocol compliance.

> I've implemented both OAuth2 and OpenID Connect multiple times

Whilst I do not doubt that you have made multiple earnest attempts to implement the specification, I must express serious reservations as to whether the providers in question have ever delivered comprehensive, interoperable support for the standard in its entirety. It is far more plausible that they focused on a constrained subset of client requirements, tailoring their implementation to satisfy those expectations alone at the IdP level and nothing else. Or, they may have delivered only the bare minimum functionality required to align themselves, nominally, with OAuth2 and OIDC.

Please allow me to make it abundantly clear: this is neither an insult aimed at you nor an indictment of your professional capabilities. Rather, it is a sober acknowledgement of the reality – that the standard itself is both convoluted and maddeningly imprecise, making it extraordinarily difficult for even seasoned engineers to produce a high-quality, truly interoperable implementation.

> I'm sure you're right that vendors take liberties -- that is almost always the case, and delinquency of e.g. Okta is what started this thread.

This, quite precisely, underscores the fundamental purpose of a standard – to establish a clear, concise, and unambiguous definition of that which is being standardised. When a standard permits five divergent interpretations, one does not possess a standard at all – one has five competing standards masquerading under a single name.

Regrettably, this is the exact predicament we face with OAuth2 and OIDC. What should be a singular foundation for interoperability has devolved into a fragmented set of behaviours, each shaped more by vendor discretion than by protocol fidelity. In effect, we are navigating a battlefield of pluralities under the illusion of unity – and paying dearly for the inconsistency.

Needless to say, OAuth2 and OIDC are still the best that we have had, especially compared to their predecessors, and by a large margin.


https://goauthentik.io/#comparison

They have an enterprise version now (mostly for support and bleeding edge features that later make it into the open source product.)

It's pretty easy to self host. I have been doing it for a small site for years and I couldn't even get any other open source solution to work. They are mostly huge with less features.


No provider has been able to match Auth0 actions unfortunately. Auth0 allows you to execute custom code at any point in the auth lifecycle and allow/deny based on that or enrich user attributes. Super useful when you have a legacy system that is hard to migrate away from. If anyone has any recommendations I'm all ears


I work for FusionAuth.

We have lambdas (basically JavaScript code that can make API calls[0] and be managed and tested[1]) that execute at fixed points in the auth lifecycle:

- before a login is allowed

- before a token is created

- after a user returns from a federated login (SAML, OIDC, etc)

- before a user registers

And more[2].

And we're currently working on one for "before an MFA challenge is issued"[3].

There are some limitations[4]. We don't allow, for instance, loading of arbitrary JavaScript libraries.

Not sure if that meets all your needs, but thought it was worth mentioning.

0: https://fusionauth.io/docs/extend/code/lambdas/lambda-remote...

1: https://fusionauth.io/docs/extend/code/lambdas/testing

2: full list here: https://fusionauth.io/docs/extend/code/lambdas/

3: https://github.com/FusionAuth/fusionauth-issues/issues/2309

4: https://fusionauth.io/docs/extend/code/lambdas/#limitations


thank you I will check you guys out


I am not qualified to say whether Authentik can do all of what you need but it does allow custom python code in a lot of places. Perhaps you can ask whether what you need is available directly. They are very active in Discord.


(authentik maintainer here) It does! Also, not only in the authentication process, but also during individual authorization flows, and in a few other places as well, like when a user edits their settings, or whenever an event (basically whenever something happens in authentik) but that's more a reactive process than inline


Thanks for the mention! (Authentik Security CEO here.) We've become something of Okta migration experts at this point... Cloudflare moved to us a couple years back after they had to be the ones to let Okta know it'd been breached yet again. [1]

[1] https://blog.cloudflare.com/how-cloudflare-mitigated-yet-ano...


Cloudflare??? Damn. that is HUGE! Congratulations. You guys have a super solid product full of features and a decent founder. Maybe enterprises don't care about my favorite feature but it makes securing EVERYTHING a breeze. Embedded proxy! That is GOAT.


If you’re looking for b2b identity, I’m the founder of WorkOS and we power this for a bunch of apps. Feel free to email me, mg@workos.com


We use WorkOS to support some of our offerings but not for our own corporate identity/authentication. I’m not close to the project so I don’t have experience using WorkOS but definitely curious about replacing Okta.


It's not the same as Auth0, but you might be interested in Zitadel, if only because it's open source and you can use it hosted or self-hosted.

(Disclaimer: I work for Zitadel).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: