Comment by inkyoto
10 hours ago
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.
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.