OAuth for the Open Web
aaronparecki.com
aaronparecki.com
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.
Someone asked that in the comments of the article and the author responded with this link:
https://indieweb.org/indieauth-vs-openid-connect
The answer seems to boil down to IndieAuth being more decentralized.
https://developer.mastercard.com/blog/why-mastercard-doesnt-...
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.
Thus OAuth 2.0 supports both authorization and authentication. However providers are free to pick what features they want to provide to clients.
- 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.
I sure do wish people would just standardize on OIDC...
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.
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".
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 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.
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.
Why do they have to trust it at all?
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.
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.
That's what delegation is for.
Not many things support dynamic client registration, which means the list of IDPs a site can use are pretty static.
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.
For this use case, they'd also need to configure JAAS.
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.
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.
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.
https://github.com/IdentityPython
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.
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.
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...
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 ;-)
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.
Such a feature might best be specified as an extension to this API:
https://developer.mozilla.org/en-US/docs/Web/API/Credential_...
which although experimental does have some level of browser support.
The RFC even includes an example of doing something very similar to this use case:
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.
My favorite implementation: Keycloak.
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.
OpenID Connect adds lots of bloat, it's very large and complicated. IndieAuth is actually easy to understand and implement.
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.