Hacker News Reader

Comment by blm126 | Hacker News Reader

OpenID Connect actually has all the machinery needed to support federated login as part of its dynamic discovery and dynamic registration specifications. The issue is that absolutely no one uses them or implements them.

Smaller tech companies don't want federated login to happen. They are, as a rule, far to happy to rely on the SSO tax to up-sell enterprise customers. The major authentication companies don't want federated login to happy because it invites more competitors and threatens their absurd margins.

Until someone manages to solve the business side, no amount of improved technology will change a thing. I'm pretty sure the few small interoperability gaps OpenID Connect has could be corrected in a matter of months if the stakeholders actually cared.

View on HN

As someone with a vested interest/being/been many of the parties you mention... Do you think support for "federated login via OIDC" would _not_ fall under the SSO tax?

Who do you think would host the "federated login" system that would replace the major authentication companies?

You can already stand up a SAML or OIDC provider using OSS and run the IdP for your company. I have many customers that do! And you bet we still charge them for SSO, and that they're every six months asking how bad the migration to a "big auth company" would be.

With dynamic client registration, I could host my own IdP server at home, or with a provider of my choice, and it would just work everywhere without any coordination work for anyone, manual signups to be assigned a client id/secret, etc. The entire point is that you won't let me do that because you want to charge extra for better, simpler, cheaper security for everyone. That is the SSO tax.

I should be able to just give my email or domain name, and it kicks off an oauth flow to that domain no matter who I use for my email/identity. In the same way that I can give you my email address and you'll just email me without me having to pay extra for enterprise email.

GP was probably thinking of Azure AD / Entra as the "SSO tax".

https://sso.tax/

Thanks!

OpenID started its life as an attempt at a federated login standard.

From vague memory, the other stuff in OpenID Connect was layered over the original OpenID identity verification part.

There is nothing left from the OpenID 1.0 and 2.0 protocol in OpenID Connect, except for the core features (identity federation, identity information encoding and updates).

OpenID Connect is basically OpenID reimagined on top of OAuth 2.0, with using JWT for the identity data.

The core OpenID Connect spec is still purely a federated identity standard. There are many other standards pushed by the OpenID foundation, but OpenID Connect itself was never meant to be anything more. The main feature differentiator from the OG OpenID is that it's built on top of OAuth, so you can add other features supported by OAuth (like authorization) ad-hoc.

OpenID Connect is OAuth2 extended to cover a similar feature set as OpenID.

Yeah I’m so old, I remember when LiveJournal (probably when bradfitz was still involved) were among the first to support original OpenID.

Why haven't (we?) these federation features been used?

Federation sounds like decentralization to me. Decentralized is like a dirty word when you’re in the business of either selling SaaS or pushing private citizens to go all in on the GOOG/AAPL/MSFT ecosystems. And everyone with any influence over what gets adopted and used, is in those categories.

They are being used. Workload Identity Federation is often used to assign oidc identities to workloads and the Client ID Metadata Document (basically dynamic client registration) is used in protocols such as MCP and atproto

Reply on news.ycombinator.com