1. 19
  1. 4

    This formulation worries too much about identity, and identity questions pave the “road to perdition”. Authenticate each request, don’t let users choose passwords, don’t second-guess the user’s delegations, and rate-limit abusive attempts without regard for authentication; these together answer every question, although the resulting system might not be recognizable since it will be oriented around capability URLs and not use typical login/account patterns.

    1. 3

      The ergonomics of those seem quite bad, though. With a password manager or social media sign-in, registering and logging in for things is very easy. With token sign-ins you have to go through your email or a trusted device every time you don’t have a live session.

      @arp242 wrote about their experiences here: https://www.arp242.net/email-auth.html, which match my experience as a user of token-based login systems.

    2. 2

      Folks building new software (and not using hosted auth services like auth0 or Google accounts): are you still building your own auth system from scratch or are you using an existing open source system like keycloak or kanidm?

      1. 9

        As the main back-end guy at my company, I decided to use Keycloak for our system’s authentication. It has pluses and minuses.

        The minuses: Up-front development and setup cost was MUCH higher than a simple username/hashed-password table. I spent a fair bit of time fussing with Java OAuth libraries and Spring Security before I got it working the way I wanted. Stuff like “let users manage their own API keys for non-interactive clients” turns into a minor ordeal involving multiple OAuth tokens and fake Keycloak user identities. Customizing the registration flow is a hassle compared to implementing it as a couple extra pages in our main web app. The admin UI is a little clunky (though, it must be said, still far nicer than any of the other auth packages I evaluated). Its role-based access control setup is not flexible enough for our application and I ended up building my own authorization layer.

        On the plus side, adding a working “log in with Google” button to our app took me all of 5 minutes. Adding “log in with Apple” took longer but was still pretty quick (and most of the blame for it taking longer is on Apple, not on Keycloak). When we wanted to set up a Grafana instance and let employees log in with the same credentials they use for our web app, I just configured Grafana to use our Keycloak server as its OAuth provider, configured Keycloak to only allow access to users with our “employee” role, and it was done. Other internal tools sit behind an oauth2-proxy instance that uses Keycloak for login, and the tools don’t need to know anything about where the user data lives. My expectation is that we’ll be adding other such services over time, some end-user-facing and some not.

        On balance, I think it was the right choice for us, and the advantages will grow over time. But the minuses are significant enough that I can’t say that with absolute confidence; I could envision an alternate reality where it took me less time to do all the “easy in Keycloak” stuff from scratch than it took to mess with Keycloak.

        1. 1

          Thanks for the details!

          Up-front development and setup cost was MUCH higher than a simple username/hashed-password table.

          I think this is always the case with every separate auth system to be fair.

          The admin UI is a little clunky (though, it must be said, still far nicer than any of the other auth packages I evaluated).

          Since you mentioned you evaluated others… any info to share on specifically which other auth systems you ended up not going with?

          1. 2

            I think this is always the case with every separate auth system to be fair.

            Definitely, and going into it I expected it to take longer than a simpler system. I just didn’t appreciate how much more work it was going to be. There were lots of little fussy details that weren’t apparent when I did my initial proof-of-concept implementation as part of the evaluation process.

            Others I seriously evaluated were CAS (which seemed capable but just getting it up and running at all was a nigh-impenetrable configuration nightmare and it didn’t look like it’d get any easier afterwards), OpenAM (seemed okay-ish, but it seems like they started off with a commercial package, half-converted it to a community project, then got bored and released their work in progress, which didn’t give me lots of confidence about its long-term viability), and WSO2 (my second choice after Keycloak, but quite resource-hungry and forces you to muck around with XML to configure permissions).

            Those aren’t the only auth packages out there by a long shot, but they were the only ones I found that met our specific product requirements. Definitely worth figuring out what you really need out of such a system before looking for candidates.

        2. 4

          Building from scratch every time. But I do reuse code from project to project so it’s not entirely “from scratch” as that wouldn’t make any sense. Much auth code can be reused as it’s the same basic functionality with only minor things that change from project to project.

          1. 2

            the second

            1. 1

              Which one are you using?

              1. 3

                Keycloak. Sorry for the dry reply back there.

                Lead the IdP/IAM implementation (customer facing both B2B and B2C type of UX) in my last gig and used Keycloak as its core. Has a fairly impressive out-of-the-box completeness and extensibility is achievable albeit awkward IMO.

                In my current gig I found a Keycloak already in place. Honestly I would rather try something a bit less bulky and have been looking to Ory but haven’t done anything noteworthy yet.

                My main issues with Keycloak have been mostly around extending it. Has that old-school enterprisy Java coding experience going, as it runs on JBoss and does a poor job in hiding that. Clustering on K8S was more hassle than it should too. I think they’re “rewriting” it under Keycloak X, which is both a good and a bad thing. Good because it is targeting a more lightweight “cloud-native” runtime but breakage is sure to happen. Gave me zero issues in production for 3 years with low traffic (dozens TPS tops) but very high criticality (all user and all “microservices” used it for auth)

                I understand it depends on context but rolling out a “user/pass” form like it’s the 00’s really rubs me the wrong way. OIDC comes with a lot of value and I find it frustrating when I use something that doesn’t support auth federation: thinking on self hostable open source stuff but also commercial products

                It’s a lot of work to implement something like Keycloak from the ground up… even if you’re using some framework for it, registration/login/recovery/sso/browser support/email/mfa/“social login”/… in a profissional, product development setting, I would default against that.

          2. 1

            Accurate. Even just using an external OAuth2/OIDC provider, which presumably handles most of that, is crazy complicated.