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.
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
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.
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.
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.
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.
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.
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.
For instance when using google authentication, the user and the email can be anything, because google apps support custom domains for paying customers.
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.
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.
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.
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.
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.
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'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.
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.
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.
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:
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.
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.
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.
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".
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.
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.