> I've worked with a lot of third party vendor API's where it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something
As someone who's implemented a bunch of these..
It's less about compliance and more about getting everything "speaking OAuth"
Once you've converted your user-facing flows to use OAuth and you're dealing with scopes, tokens, etc, converting the backend to also use it makes a lot of sense. Then you have ONE path for token validation, inspecting/validating scopes, and client id/secret issuance whether you're on the front or back end. Having one model for people to understand makes things tangibly simpler and shrinks the libraries/tools you need.
If you ONLY have backend (service to service) flows with a simple authZ model, OAuth is usually overkill.
Look I'll sing LDAP's praises when it's appropriate but this really isn't it. It's less of SSO and more "Same Password Everywhere" which are not at all the same experience from the user perspective. It also teaches your users to plug their creds into random login screens instead of the one-true-login-page they can verify is us.
Like as hackers we make fun of the phishing training that teaches you to avoid sketchy links in emails while simultaneously the real emails have the sketchiest links of all time. Using LDAP for this use-case is our version of that.
We should teach users to put their passwords into very few, limited, and trusted places. The cool new social app is NOT trusted. That random app on your phone is NOT trusted.
That xkcd is about the downside of using the dame password on many services. No service is really trusted so what we should teach people to do is, as usual, to use a password manager to randomly generate a new password for every service. Maybe that's what you were advocating but it was not clear to me.
We should also teach to ourselves to throw away all those weird rules about passwords, like 6 to 15 characters max, letters and digits and a random set of punctuation characters liked by the site owner. Why those limits when they are storing a hash anyway?
Well lets talk about your average 'bigcorp'. You've got laptops you need to log into, you've got network shares you need to log into, you've got internal web applications you need to log into, you've got external saas bullshit you need to log into, you have some cloud accounts you need to access... You need to manage this for thousands of people, probably 10s of thousands of people.
You don't want your average user to have a great many usernames and passwords, maybe two or three at most to manage. You also probably don't want to have them share those credentials.. though without 'one big system' you can't really prevent that. You also probably want some kind of system with 2factor support through a few different methods, rolling code, sms, yubikey, etc.
LDAP ain't it.
From where I set Oauth seems to be the current solution with the least number of downsides. It's complicated for sure, the flows are easy to fuck up, but I haven't seen a better solution.
Maybe Passkey is it, i keep meaning to read the rundown but I just haven't found the time... and also it's realativly new enough that support and open source solutions might be a little sparse...
One really shitty thing is that people keep inventing those badly-though protocols like OAuth, and yet nobody (as in no browser) ever implemented LDAP over the web.
Windows has that stupid rule where LDAP runs all over the OS or nowhere at all, and Linux has that idea that LDAP is some add-on you assemble by connecting a jigsaw of pieces. Nothing makes it reasonable to publish a domain on the web, where people can authenticate on many of them, and send the tokens where needed.
(Well, actually Firefox does most of it, and you can use it and assemble the Linux pieces so it works. It just doesn't work in practice.)
The thing is MS LDAP pretty much sucks all the air out of the room in the LDAP world. If you're going to write anything that supports LDAP you pretty much are going to write it to support Windows then most people just suggest to use Windows in the first place
As someone who's implemented a bunch of these..
It's less about compliance and more about getting everything "speaking OAuth"
Once you've converted your user-facing flows to use OAuth and you're dealing with scopes, tokens, etc, converting the backend to also use it makes a lot of sense. Then you have ONE path for token validation, inspecting/validating scopes, and client id/secret issuance whether you're on the front or back end. Having one model for people to understand makes things tangibly simpler and shrinks the libraries/tools you need.
If you ONLY have backend (service to service) flows with a simple authZ model, OAuth is usually overkill.