it can get a bit complex, but to be fair the whole oauth/oauth2.0/openid/openid-connect/saml is quite messy in general.
In particular, I am trying to solve the problem of how I can share client secrets (so they can generate access token using it) with the respective clients.
I don't want to share them over email/ password protected doc.
I tried making one client for each realm and adding one user to it. When I login via user account using GUI, I am unable to see any info related to clients.
What am I doing wrong here?
What are the good practices around this?
Thanks kind folks
Fast self contained binaries, easy to interface with Kubernetes.
Adding some UI around them and managing them via api is nice enough.
The only incognita is whether they're going to handle scaling (I hope I'll have this problem one day).
Hydra is for OpenId though, I'd point to Kratos + Oathkeeper.
In general, if more sites grew proper OpenID auth vs justa subset of providers, we'd see more people run their own OpenID servers to authenticate against external services.
Basically, for an open source/free software service to succeed in this area, it needs to allow both federated and SaaS model because that's how free software people are :) And federated is hard because nobody accepts pure OpenID anymore (and it's funny: you'll trust an email address but not a URL as a unique identifier). But it's probably how hard it was to get working that's the issue.
Because it is a lot of hard, strict and continuous work. Specially if you want - and you kinda need to, if you want anyone to use you - to provide customization for: styling, different databases, languages (both programming and natural), login methods (SSO, email, etc), email delivery systems, user fields, etc.
So people building open source generally will just solve their own problem and might share that, not solve a problem space one up with all of these combination complexity mess. The most "standard" open source I know is Passport.js, but it only solves the problem of login methods.
You can roll any subsystem of it and use off-the-shelf providers for other subsystems (we pay a service to host the server, but we run our own dashboard server to poke into it, others run their own database and use just the API server, etc), but I suppose it's easiest if you run the whole parse backend as a whole.
So, there are options, some I now remember hearing of before.
I'm still interested in more of you thoughts on why they don't have a wider adoption rate.
------------
That said, maybe the HN community can answer something I've wondered about... Why isn't there an Open Source, standardized, self-hosted, version of this kind of service? Or, why hasn't one, or two, options emerged that everyone uses and I would have heard of by now?
User management, authentication, and authorization, are all problems that have been solved in many apps, and there are plenty of best practices. So, just like you shouldn't roll your own hashing algorithm, I'd think we'd want to do the same with this. It would make sense for one of the open source companies or organizations like Canonical, RedHat, Apache or Mozilla to have at least tried to do this.
The closest I can think of to an attempt is Persona...
Anyway, just been wondering about this for a while, and thought I'd take the opportunity to ask.