I've had a very positive experience with Keycloak and given its low barrier to deploy I don't really get why Auth as a service exists. I've seen more install/setup magic invoked just getting vscode configured. (slightly tongue in cheek).
Mind you, data residence and provenance may be more important in the use cases/applications I'm familiar with.
Then again, it is good to see a healthy standards based Authn/z ecosystem - good luck to all.
EDIT:
After reviewing the site closer I'm not seeing anything about standards compliance.
I’d argue that Keycloak is also Auth as a Service. Even if you may be hosting that service yourself.
If you only have a single web application (yes, that still exists) you don't need any of this. Use your backend framework's "native" auth package and you're good to go.
Working for $veryBigOrg passing all the compliance stuff off to Auth0/Okta/whoever is a big plus. Besides, they'll probably do better securing and auditing their user databases than we ever could.
> I'm not seeing anything about standards compliance
Thanks! We'll make a section to highlight them. We use the JWT standard (not sure if that is what you mean?), Oauth 2.0, SAML, etc... there are lots of standards in this space
I believe that they actually meant more like NIST/FIPS compliance type stuff so that big orgs that have to meet certain certifications will know if they can use your product or not.
I would highly recommend building in key rotation and a well-known endpoint for retrieving public keys. In the Node.js documentation (https://userfront.com/examples/nodejs.html), the expectation seems to be that a single public key is hard-coded into all customer applications. If UserFront's private key is compromised for whatever reason, it should be trivial to rotate keys without requiring all customers to update their application with the new public key.
This is exactly what we're rolling out in the next few weeks. We already have it trivial to rotate API keys [1], and we have a JWKS endpoint [2], so rotating the primary JWT private key is next on the list.
This is a tough one to balance. Ideally you want applications to be able to pull new public keys if the private keys are rotated, but equally you’ve now just introduced a path via which an attacker with control of the domain that we’ll known endpoint is hosted on with a path to replace your keys.
I actually thought the landing page was pretty good. It describes the product reasonably well and is very clear about "why pick us". I agree because of the crowded market it is in it needs a very comprehensive comparison section to help people decide why them vs other established solutions.
In short, it's a second-gen platform that doesn't have to support a bunch of legacy customers, so we can make it much less complex to use.
We started doing auth because our dev customers kept telling us how much of a pain it was with the first-gen companies (Auth0 et al). With Userfront, you don't have to learn all the standards/protocols or deal with browser quirks, and things like testing, access control, and multi-tenancy are first-class features instead of things you spend lots of time on.
Does anyone have suggestions for a small scale (dozens of users) user management system that supports the LDAP protocol?
Currently I am self-hosting several web applications for the same userbase and just want them to have the same username and password for each app (SSO not required).
After much pain and confusion, I have an OpenLDAP instance functioning basically how I want, but it just feels like there must be a better way!
Keycloak will work just fine and can be somewhat quick to setup - it will link with LDAP, can be even made to provide password change option with write access, can import groups, attributes (including custom ones), etc.
It will also provide you with SAML and OIDC web authentication, and can support WebAuthN, U2F, certificate auth, and so on for your apps, as well as integrate Google Authenticator compatible MFA (out of the box) or link with privacyIdea for more complex authentication setup. It can even link kerberos with HTTP, if you need it :)
Pretty much everything that supports custom OIDC (or SAML) will work with Keycloak out of the box.
Nice docs. Needs status page and perhaps some sort of accessible changelogs/content in panel that shows that it's more 'alive' without visiting GitHub.
Some confusion how additional roles are created (didn't dive into API, just exploring the panel) - guess this is tenancy?
Thanks! We have what you mentioned so will make it more accessible from the landing/guide/dashboard pages.
Yes you can do multi-tenancy natively, with each tenant having the same power as its parent in terms of roles, separate login pages, etc. Our architecture is "tenants all the way down".
Co-founder here. It's fun to see your work on the front page at 6am, and I guess I'll stop lurking now. I'm happy to try to answer any questions you may have.
When will anonymous (guest) accounts be available, and how will they work? Will there be a simple way to promote them to regular user accounts?
As you may know, HN never fails to complain about having to create a new user account to try a service out. Sometimes when you can try a service out before signing up, it's a better experience.
We're hoping Q2 release, and we're dogfooding it now. Our dashboard will soon allow full navigation with a guest account, and we'll use those learnings to deliver a polished product. Guests get a JWT like any other user, but the token is denoted as being a guest, and your application can handle that however you like.
Mind you, data residence and provenance may be more important in the use cases/applications I'm familiar with.
Then again, it is good to see a healthy standards based Authn/z ecosystem - good luck to all.
EDIT: After reviewing the site closer I'm not seeing anything about standards compliance.