Hacker News new | past | comments | ask | show | jobs | submit login
OAuth for the Open Web (aaronparecki.com)
149 points by buovjaga on July 7, 2018 | hide | past | favorite | 79 comments

Why not OpenID Connect? Not only does it have discovery for OAuth2 endpoints, it also specifies how to discovery the OIDC endpoint from a bare domain and username via WebFinger. It also has extensions for dynamic client registration, supports flows that work with input-restricted clients, as well as single page apps, and the UserInfo endpoint.

And it's also already implemented and supported in lots of places. There are tools like Dex that offer OIDC and can use "upstream" OIDC providers for the actual user management.

I'm not getting why IndieAuth is needed beyond what OIDC offers?

Also, for those mentioning Persona/BrowserID/Portier, it is an OpenID Connect provider, and I've just recently sent PRs for it and Dex that allow them to work together.

> Why not OpenID Connect?

Someone asked that in the comments of the article and the author responded with this link:


The answer seems to boil down to IndieAuth being more decentralized.

Aha, one more bit of indirection ala OpenID v1 to make the base identity portable. I like it. Thanks for the link!

Not at all. The answer is that the guy is pushing for his own product and company.

There is no company and product, there is a community and open specifications.

The author works for a company in the Auth space, but said company has no products based on this specification, and it was created prior to him working there.

OAuth 1.0a includes authentication and authorization. OAuth 2.0 is designed for authorization only and could be vulnerable to account takeover/impersonation attacks. MasterCard uses OAuth 1.0a instead of 2.0


The authentication part is called OpenID Connect and that's a subset of the OAuth 2.0 spec.

Thus OAuth 2.0 supports both authorization and authentication. However providers are free to pick what features they want to provide to clients.

Given that OAuth 2.0 uses TLS, could you please explain how such an attack could actually be executed?

A MITM TLS-busting proxy. Like on many corporate networks and in many country firewalls.

Might seem like a remote chance from a user's point of view, but could be a threat from a payment processor's view, with billions of daily transactions.

Also, easier to prove the integrity of the message when you're handling the authentication piece yourself rather than assuming TLS was correctly enforced end-to-end.

This seems to me as just a subset what OpenID Connect is. OIDC is an addition to OAuth2 and supports all mentioned

- user identity: core user info endpoint

- discovery: https://openid.net/specs/openid-connect-discovery-1_0.html

- client registration: https://openid.net/specs/openid-connect-registration-1_0.htm...

And also other features which are important for more complex cases than just simple "login using X" button.

The battle between OAuth 1.0a, 2.0, and OIDC is really long and drawn out and doesn't seem to have a clear winner which I think is hurting everyone (though of course some companies are winning because they can support everything and offer that as value).

I sure do wish people would just standardize on OIDC...

It’s unfortunate. Big companies are pushing for OAuth 2.0 and trying to blindsided people as if it is an upgrade to OAuth 1.0a. It is not. OAuth 1.0a provides authenticity, integrity, and non-repudiation. Something that OAuth 2.0 does not provide.

large providers will drag their feet kicking and screaming because the prominent 'login with facebook / google' link are both selling point of their platform and monitoring opportunities for third party users.

Google and Microsoft are two big companies supporting OIDC.

But not the extensions the GP cites as meaning OIDC solves the same problem. And even if they did, I don't think it allows to isolate your identity from the identity provider you currently use, which seems to be a key aspect of IndieAuth: You can delegate the role of Identity Provider to a third party, but can change that third party, similar to how you could in "original" OpenID.

Of course you can isolate the identity from the identify provider. It's fully supported by OIDC. It's a main use case for every website that wants to manage its user accounts.

Right, seems I misunderstood it last time I looked at that spec or was misremembering, re-reading it one could of course point to an external service. Is there an actual implementation of that in the wild, that I e.g. could use with my e-mail address at my domain? Even support for discovery at all seemed basically non-existent.

It's already available if you use any of the major email provider.

If you want to provide it from your own domain, it's perfectly doable, but it takes a lot of work to setup. This won't be usable from other sites though because they won't trust yoursite.com

Discovery is non existent because it makes zero sense in practice.

Ok, so you confirm that while the standards theoretically exist, OpenID Connect doesn't provide those features from OpenID in practice (where they did make sense for some reason?)

You don't need trust to the domain if you just want "an identity" to recognize a user, which is the use case for many services: basically as soon as you allow e-mail + password sign-up, that's the only thing you get. OpenID did the same.

Delegation is helpful exactly because it is somewhat difficult to implement OAuth nicely. OpenID did the same.

Which I guess answers the original question of "why not OpenID Connect" with "because nobody in that ecosystem cares about those features, even if someone at some point wrote down how they can work".

I don't understand your complaint. I suspect you have a fundamental misunderstanding of identity management in practice, irrelevant of whether it's implemented with OpenID, OpenID Connect or SAML.

If you want people to register with anything, then just let them register with an arbitrary username and password. You don't even need an email or a domain.

I want what OpenID provided me: I give a site a URL to a page I control, and it goes there to figure out what service of my choosing to use to sign me in. I want this to be open, so I don't have to check with each site what whitelist of providers they accept.

I thus do not need to remember/manage a username/password pair per site, and am not tied to a specific service that might die, which was a big problem with the OpenID infrastructure dying bit by bit: those wo didn't use URLs they controlled to delegate lost their ability log in when the provider they used went away.

But in practice, OpenID 1/2 were a nightmare.

Most of the implementations were incomplete/broken, everyone wanted to provide OpenID while nobody wanted to consume it, and the few parties that did consume it got left holding the bag when the OPs ripped out support and left users without a way to prove their identity to recover their accounts.

You want at least a weak unilateral arrangement, such as Google or Microsoft or Facebook saying they have no plans to rip the feature out from under you any time soon.

Also, OpenID adoption was never going to happen with users being identified by URLs. No party was going to step up and explain to users why they should go through the effort of learning all this tech to use it vs. using the passwords they were already familiar with.

This won't be usable from other sites though because they won't trust yoursite.com

Why do they have to trust it at all?

Because otherwise anyone could make an authentication provider that's authenticating as you@gmail.com and assume your identity.

Remember that the goal is to delegate authentication, user profile and/or user creation. It's implicitly trusting everything coming from the third party. For instance when supporting google login, it's expected that google only validate user accounts that really exist and are hosted by google.

Well, no, it would only accept IDs of the format *@yoursite.com for the provider yoursite.com (or the provider yoursite.com has delegated to).

Authentication cannot be bound to any email or format.

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

If you want to rely on emails, just use emails.

For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.

That's what delegation is for.

OpenID Connect is a subset of the OAuth 2.0 spec. They come in a bundle.

It's not a subset, it's a superset (or built upon Oauth 2.0 if that's the more accurate way to put it) -- I just read through the OpenID Core spec[0] today since I felt like I didn't know enough about it.

[0]: https://openid.net/specs/openid-connect-core-1_0.html

Does anything actually implement discovery? I looked at various OpenID Connect implementations a while back and nobody seemed to support it. It's a pretty big user-education problem if you can't just say "you can use OpenID Connect", but have to explain "you can use OpenID Connect, provided your provider supports Extensions X and Y, and they probably don't clearly document that they do, so please just try logging in here and see if it works".

Quite a few things implement discovery. Most IDPs advertise metadata, and many RP libraries consume it by default. IDPs even motivate them to consume it by rotating signing keys pretty often.

Not many things support dynamic client registration, which means the list of IDPs a site can use are pretty static.

I was looking into SAML a while back for a project (preexisting compatibility) and the lack of functional open source IdP's is depressing.

I tried Gluu and it's a RAM hog for what it does (IMO). I took a look at the developer docs and it seems all but impossible to override the password hashing method with your own (query passwords from your own database instead of LDAP hashed) was one use case I was looking into)

Even storing my custom hashes in LDAP would have been acceptable.

Keycloak is a personal fave for this general space


Had a good look into this, also quite a complicated solution.

I've been looking for a good solution to the "I have 3 small web apps that are used by the same people, I should centralise authentication and authorization" problem, and yet to find something sensible for that usecase.

Why not a cloud provider like Google Identity, Okta, OneLogin, etc?

Why not use Azure AD B2C or Firebase Authentication?

The product is OpenAM from Forgerock, that is both open source and expensive. https://www.forgerock.com/

Gluu is just a facade company that's recompiling it from source and distributing the binaries for free.

It supports pretty much everything you can dream of, including different password hashing and you can write your own plugins to interface with anything you like.

However it's a very complicated product. It's for a large company or a country with a dedicated team to run and customize.

P.S. Not affiliated to any of these companies. I had to do the performance assessment of these products some year ago for a government contract. https://thehftguy.com/2015/10/14/iam-benchmarks-openam-vs-ws...

Gluu isn't based on OpenAM. Gluu is based on a whole bunch of other products (like Shibboleth) but not OpenAM. OpenAM originated from Sun's OpenSSO when Oracle bought Sun and FrogeRock was created. Incidentally this is the same time Gluu was created.

OpenAM is also no longer opensource. The source was closed by Forgerock in the beginning of 2018.

One of the forks that sprung from this source closing is wren:security ( https://wrensecurity.org ). Disclosure: I work on that project ;-)

Good to know. Gluu was built upon and dependent on ForgeRock products last I was working with it. I guess they're having a pretty bad time if ForgeRock pulled the sources.

The Gluu Server bundles a fork of OpenDJ 3.0 for persistence, the last open source build. It also supports OpenLDAP, and will soon support Couchbase.

Gluu writes its own software, like the OAuth2 Authorization Server, oxAuth, and bundles other open source software like the Shibboleth SAML IDP.

Shibboleth, simplesamlphp. Both offer easy ways to add custom login handlers.

Shibboleth is _the_ gold standard when it comes to SAML. I'm at the point where I don't recommend anything else, and I'm willing to help people deploy it (contact info in profile).

For this use case, they'd also need to configure JAAS.

I'll give just Shibboleth a try later.

I've been thinking of writing my own SAML IdP in Python (since I have plenty of experience with the language) and I'm not naive to the various security things that can go wrong, but I'm no expert cryptographer either.

I'll join the chorus recommending against inventing the wheel, unless you're doing that to learn SAML in which case I say more power to you. You should look into the existing work done by Roland Hedberg, SUNET, and others on pysaml2, which is now part of the IdentityPython project:



That said, I can't think of anyone using pysaml2 to implement identity providers aside from SATOSA, an IdP proxy. Nearly everyone I know runs either Shibboleth or SimpleSAMLphp. I recommend you run Shibboleth because there's a whole litany of interoperability issues you _won't_ encounter if you do. (The same goes for SimpleSAMLphp, but I have less experience with it.)

The IdentityPython and Shibboleth projects have a lot of overlap in terms of membership, and if you want to meet them and connect to the research and education side of the federated IdM community, which drives a lot of the open source work, you should come to the Internet2 Technology Exchange this year and stay for ACAMP. It's a super smart bunch of people. You'll learn a lot.

Not to be dismissive but better look for an alternative solution. The SAML spec is a beast, you can work on it for months, you will hardly get a few percents of it working.

If you're doing that for a small company, maybe try to get a Microsoft active directory instead. It's a lot easier to setup and maintain and everything does their best to integrate with it.

I realize it's a little late to say this, but AD FS is garbage. I've run AD FS both as an InCommon IdP and an InCommon SP, with both as full federation partners. While I solved the metadata consumption, attribute scope checking, and discovery UX issues, I encountered lots of little interoperability issues that required disabling request/assertion encryption or switching between SHA-1/SHA-256 on individual CP/RP trusts. Ultimately, we replaced the IdPs with Shibboleth and moved the SPs behind SATOSA, which works a LOT better.

> but I'm no expert cryptographer either.

You don't have to be, as you would not implement any cryptographic algorithms (ciphers, hash methods) yourself. Solid experience with software security in general is a requirement of course.

Aaron is one of the cofounders (with Tantek Çelik) of the IndieWeb community.

Great, it’s de-centralized OAuth. All we need now is a replacement for the hideous URL login prompt. My preference would be for an AccountChooser-style list of accounts you’ve recently used so you can pick one and sign in—and enter a URL (or email) only if you need to.

Unless there's gonna be native browser support, the different websites you visit won't be able to know which accounts you've recently used elsewhere.

If browsers were to support this, there would be some tricky UI/UX questions about how readily the browser provides information to a new website about accounts you have on other sites.

Such a feature might best be specified as an extension to this API:


which although experimental does have some level of browser support.

The web credential API is meant to be an integration point for passwords and AccountChooser in your browser. But I don't know if any other browsers than Chrome plan to implement it.

Don't expose it to the web page, but treat it as a native UI control.

Unless you centralize the list as AccountChooser.com does using Local Storage.

You mention "URL (or email)", so I think it is worth pointing out that there is a standardized way of converting an email address into an HTTP URL, namely WebFinger.

The RFC even includes an example of doing something very similar to this use case:


The problem is, where do you store this list? The Web doesn’t have a way to store things except at a particular domain, and that domain will then know everything.

Anyone remember xAuth effort led by Meebo and others? It ran into the same objections for using a centralized domain for the time being even though it was great.

Browsers could implement that part of the UI. Like address autofill.

And until then what do we do?

Cry in our beverages of choice.

I made a bookmarklet that will store a url for you, and sign you in. You can create your own at: https://unicyclic.com/usb

The existing AccountChooser interface, which was Google’s preferred SSO strategy until their recent experiments with zero-click SSO, was hosted at AccountChooser.com by the OpenID folks.

If URLs are to be used for user IDs, it'd make sense to require TLS, so we can remove the scheme from the IDs, so it's more memorable.

Also the mockups are really confusing, you're logging in with a URL, not a "domain". Also, having the example text as "you.domain.com" would confuse users who have "github.com/user", as used in the previous examples.

Here are some thoughts for distributed auth:


Too much about what it does, zero about _how_.

I don't understand why the need for this new protocol; what's missing from OpenID?

People replying to you are missing the point. What's missing from OpenID is adoption.

OpenID doesn't provide API access like OAuth does, does it?

From Wikipedia : "the third generation of OpenID technology, OpenID Connect, is an authentication layer that sits on top of the OAuth 2.0 authorization framework.[82] It allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain the basic profile information about the end-user in an interoperable and REST-like manner. In technical terms, OpenID Connect specifies a RESTful HTTP API, using JSON as a data format. OpenID Connect allows a range of organizations, including web-based, mobile and JavaScript clients, to request and receive information about authenticated sessions and end-users".

My favorite implementation: Keycloak.

What do you mean by API access? OpenID Connect adds more features & standardization to OAuth2. So it supports everything that OAuth2 does.

It all mentioned

- user identity: core user info endpoint

- discovery: https://openid.net/specs/openid-connect-discovery-1_0.html

- client registration: https://openid.net/specs/openid-connect-registration-1_0.htm...

And also other features which are important for more complex cases than just simple "login using X" button.

When people talk about just "OpenID", they usually mean the original one, not Connect. The old OpenID did not have the ability to authenticate requests to the domain you signed in with.

OpenID Connect adds lots of bloat, it's very large and complicated. IndieAuth is actually easy to understand and implement.

Depends on your point of view. IndieAuth has a bunch of modifications to OAuth2 behaviors that may not be compatible with existing deployments, and requires software to implement things like full HTML parsing libraries to read out link tags. There were many incomplete OpenID 1/2 implementations, and compatibility greatly suffered as a result.

As someone who maintained an OpenID 1/2 OP for a few years, I would much rather implement OpenID Connect Basic Profile than IndieAuth.

IndieAuth, like OpenID 1/2, also assumes the user has a known profile page or even knows what a URL is, which are both statistically unlikely.

Exactly, it doesn't. Instead, OpenID had tons of weird bloat no one ever needed. XRI, XRDS, Yadis, WTF

I know that maintaining a OAUth provider is a pain in the ass, not at all doable by anyone.

Do you mean to say it is impossible or do you mean something like the more idiomatic "by just anyone"?

Applications are open for YC Winter 2022

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