Hacker News Reader

> 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.

OAuth is usually overkill, period.

There are only two real use cases for the complexity of OAuth.

1. SAAS model and you're allowing your customers to use their own IDP

2. You really and truly have a lot of disparate internal systems that need SSO.

And 2 generally has better solutions.

> And 2 generally has better solutions.

you fail to mention them.

because it depends on the specific needs. It could be as simple as LDAP integration or as complex as OAuth.

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.

Isn't ldap in the browser just something like NTLM?

Negotiate uses the OS LDAP tokens on 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.)

I think this is only true if you want to use a MS Ldap server and only the ms brower used to support this. NTLM being a windows thing.

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

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.

^ This.

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.

There's even an xkcd on this one: https://xkcd.com/792/

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?

name something that doesn't have downsides.

go on, I'll wait.

Yikes ignoring that there can be different severity and type of downside

somehow "depends on the specific needs." got turned into "ignoring different severity and downsides".

Who knows what goes through people's heads.

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...

To hear you describe it, SSO didn't exist before OAuth.

And yet it did.

Nononono, i'm just saying it's going to be a requirement for whatever system.

> it was purely server-to-server access, but for some reason wrapped in OAuth... because... architects and compliance something something]

That sometimes feels like the bane of my existence. Everything has to be OAuth and use refresh tokens, certificates etc. when I never care or use any user data. No one logs in. This is all our server talking to their server. Revokable Bearer Tokens used to be used, but every API that updates switched to OAuth which makes everything more complicated.

This is what the client_credentials grant flow is intended for. If you're using any interactive grant flows to secure S2S communications, you're doing it wrong.

The oaith spec requires a callback URL to work and usually that url has to be “registered”/authorised with the server. Most of these apps are using the api “unofficially” and the only way to do that is with browser automation. Otherwise once the login is complete the redirect with the authorised token won’t get to your app - it will go to the official website or app.

They then pluck the authorised token out of the cookie store.

Not really. The libraries should do what my own app does: render the vendor website (Tesla or whoever) in a browser window and let the user enter their creds securely. You can then capture the auth code from the redirect just fine.

There are right and wrong ways to do OAuth both in server and client, and many, many implementations do it wrong.

> You can then capture the auth code from the redirect just fine.

Not when you don't have an 'official' redirect URL.

If you control the client, you can. Because when you get the redirect response, you then take the auth code that is included there, and you don’t follow the redirect.

Then you send the auth code to your backend instead.

Typically if you farm the job out to a browser, per the discussion, then you don't have control over the client.

I took it to mean that they render the login page in a web view still controlled by their app

Right, so my app is an electron app, and you can hook into the redirect. It’s still a little bit hacking the flow but not as bad as full browser automation

That works for GUI apps I agree though doesn’t work for server side stuff. Which I suspect the software the OP meant is. But yes better than storing the password if you are on a desktop.

> because... architects and compliance something something

At work the tooling we use for our services outright requires OAuth if you want authentication. And yeah, that's a large factor implying we should use something else, but there are many coordination problems for that.

I imagine plenty of people have a similar problem.

Anyway, if your client is saving your password, then I'd say that's not a good use-case for OAuth. At this point I'm not sure there exist a good use-case for OAuth.

What I hate about OAuth is how slow and cumbersome it makes the process across the web. Everything requires login with google for example, but that flow is so slow that it’s what I dread the most of all auth. Especially when I see the page reloading multiple times because it wants so many other things besides just auth.

If you have an IAM with underlying IDP's it will legit be a stack of redirects with callbacks, sometimes deeper than 1 or 2. It's nuts.

Tesla only just recently opened the ability to be an official oauth application, so all apps before now either required storing username+password or the long-lived token it sends back once you authenticate.