
OAuth for the Open Web - buovjaga
https://aaronparecki.com/2018/07/07/7/oauth-for-the-open-web
======
colemickens
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.

~~~
dane-pgp
> Why not OpenID Connect?

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

[https://indieweb.org/indieauth-vs-openid-
connect](https://indieweb.org/indieauth-vs-openid-connect)

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

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

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

------
woranl
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

[https://developer.mastercard.com/blog/why-mastercard-
doesnt-...](https://developer.mastercard.com/blog/why-mastercard-doesnt-use-
oauth-20)

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

~~~
function_seven
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.

------
jakubriedl
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](https://openid.net/specs/openid-connect-
discovery-1_0.html)

\- client registration: [https://openid.net/specs/openid-connect-
registration-1_0.htm...](https://openid.net/specs/openid-connect-
registration-1_0.html)

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

~~~
hardwaresofton
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...

~~~
Boulth
Google and Microsoft are two big companies supporting OIDC.

~~~
detaro
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.

~~~
user5994461
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.

~~~
detaro
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.

~~~
user5994461
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.

~~~
detaro
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".

~~~
user5994461
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.

~~~
detaro
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.

~~~
dwaite
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.

------
jtl999
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.

~~~
user5994461
The product is OpenAM from Forgerock, that is both open source and expensive.
[https://www.forgerock.com/](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...](https://thehftguy.com/2015/10/14/iam-benchmarks-openam-vs-wshttpso2-vs-
simplesamlphp-vs-shibboleth-2/)

~~~
jsiepkes
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](https://wrensecurity.org) ). Disclosure: I work on
that project ;-)

~~~
user5994461
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.

~~~
willow9886
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.

------
justinsaccount
Persona
([https://en.wikipedia.org/wiki/Mozilla_Persona](https://en.wikipedia.org/wiki/Mozilla_Persona))
had it right :(

~~~
fiatjaf
See [https://portier.github.io](https://portier.github.io)

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

------
lstamour
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.

~~~
daveid
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.

~~~
dane-pgp
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:

[https://developer.mozilla.org/en-
US/docs/Web/API/Credential_...](https://developer.mozilla.org/en-
US/docs/Web/API/Credential_Management_API)

which although experimental does have some level of browser support.

~~~
dwaite
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.

------
amaccuish
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.

------
amaccuish
I'd have preferred improvements to OAuth, see:
[https://hueniverse.com/oauth-2-0-and-the-road-to-
hell-8eec45...](https://hueniverse.com/oauth-2-0-and-the-road-to-
hell-8eec45921529) and
[https://vimeo.com/52882780](https://vimeo.com/52882780)

------
EGreg
Here are some thoughts for distributed auth:

[https://github.com/Qbix/auth](https://github.com/Qbix/auth)

~~~
fiatjaf
Too much about what it does, zero about _how_.

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

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

~~~
jakubriedl
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](https://openid.net/specs/openid-connect-
discovery-1_0.html)

\- client registration: [https://openid.net/specs/openid-connect-
registration-1_0.htm...](https://openid.net/specs/openid-connect-
registration-1_0.html)

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

~~~
floatboth
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.

~~~
dwaite
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.

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

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

