Why is OAuth still hard in 2023? • Hacker News Board

Re: Why is OAuth still hard in 2023?

#191

Post by mekoka » Thu, Apr 27, 2023, 2:10 AM UTC

jkubicek wrote: post #105

btilly wrote: post #26

Earlier quoted context omitted.

I have read many docs. The one that I find easiest to understanding is still the one that I wrote about a decade ago when I first had to work with OAuth 2. All others I understanding by mapping what they said to concepts in mine, and that seems to work pretty well. My document is available at https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut... . Even though you're unlikely to ever use that library or lang…

Your documentation is amongst the best I've seen on OAuth, but it suffers from the same naming confusion I always run into when I'm reading OAuth docs. > OAuth 2 makes it easy for large service providers to write many APIs that users can securely authorize third party consumers If I'm trying to write a Mastodon client, I'm reading this line piece by piece: > OAuth 2 makes it easy for large service providers "service…

I think it's helpful to not stray too far away from the standard terminology. I found that "third party" was an excellent indicator that the consumer is probably not me, especially since I've already qualified as a user.

Re: Why is OAuth still hard in 2023?

#192

Post by smackeyacky » Thu, Apr 27, 2023, 2:11 AM UTC

codebje wrote: post #178

jcranmer wrote: post #75

Earlier quoted context omitted.

In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol. Actually go to the core RFCs for OAuth, and you realize that basically everything is implementation-dependent. You somehow register with the provider as a client (out of band and completely implementation-dependent). Then you ask them to log you in by sending a request to an implementation-dependen…

Dynamic client registration is standardised ( https://www.rfc-editor.org/rfc/rfc7591.html ), the authorization code flow is standardised ( https://www.rfc-editor.org/rfc/rfc6749.html ). The device authorization flow is also standardised ( https://www.rfc-editor.org/rfc/rfc8628.html ). The preferred desktop app authorization process is described in a best current practice document ( https://www.rfc-editor.org/rfc/rfc8…

Just because the standards exist doesn't mean everybody follows them. Most and maybe all implementations have some crazy customisation. It makes the standards and docs almost worthless.

Re: Why is OAuth still hard in 2023?

#193

Post by neurostimulant » Thu, Apr 27, 2023, 2:14 AM UTC

grepfru_it wrote: post #159

neurostimulant wrote: post #146

Earlier quoted context omitted.

I'm still salty about how keycloak changed their openid logout behavior, removed the old behavior in the new version when there are still a lot of oidc clients out there that still expect the old behavior. I have two inatances of keycloak using the same version and somehow both have different iodc logout behaviors. I think it's due to one instance was upgraded from older version and inherited the old behavior, but I…

Can you elaborate on this a bit? My logout process through keycloak is through a hidden (back channel) url. As long as I hit that client url it will end the session. Applications, I find, have different behaviors. Gitea logs out the session, portainer just clears browser cookies but the session remains active I’m using the same keycloak setup for almost 2 years now, with upgrades

I was referring to this one: https://keycloak.discourse.group/t/keycloak-redirect-uri-log...

There is a flag to restore the old behavior but it doesn't work in newer version. Strangely, an older instance of keycloak I run still uses the old behavior even after being upgraded to latest version, so this issue seems to only affect new instance only.

Re: Why is OAuth still hard in 2023?

#194

Post by StillBored » Thu, Apr 27, 2023, 2:27 AM UTC

I don't know, I look at oauth and it seems like its insecurity by design. Huge complex spec, with lots of corner cases, and requires really complex functionality like HTTP and JS. All of which can hide obscure bugs. Its like no one has learned from history.

Frankly, I'm not sure what keeps people from simply putting fake Oauth screens on random phishing emails. Figure out what a companies default auth screen looks like, pop up a similar looking web page.. bam plaintext passwords that can be used to authenticate with real services.

Re: Why is OAuth still hard in 2023?

#195

Post by lmm » Thu, Apr 27, 2023, 2:39 AM UTC

klabb3 wrote: post #149

lmm wrote: post #131

Earlier quoted context omitted.

Email and SMS are inherently insecure, and it would be a lot harder for whoever's on the other end to apply security practices (e.g. look at where logins are coming from, rate-limit authorization attempts). They can't pass extra metadata back (user's name/address/avatar/etc.) and they can't do fine-grained permissions (grant me access to this github repo but not that one, grant me read but not write, ...). Plus I don…

> Email and SMS are inherently insecure But nevertheless widely used as de-facto identity, I assume because account recovery in case of lost credentials is paramount. At least 90% of my accounts would be stolen or lost, today, should I lose access to my email. I don’t particularly like email, for many reasons. Especially that most people’s email can be blocked by a faceless corporation that suddenly bans you. That sa…

> But nevertheless widely used as de-facto identity, I assume because account recovery in case of lost credentials is paramount. At least 90% of my accounts would be stolen or lost, today, should I lose access to my email.

Sure, but that's your choice. If you want to make your Google account require 3 factor authentication and a 10 minute timeout, you can, and from the perspective of any site logging you in via OAuth from Google, nothing changes. Even if 90% of users are going to use email only, it's nice to not force everyone down to that lowest common denominator.

> I agree that client certs are greatly under-utilized and poorly supported by eg reverse proxies, but how would they help here? What’s the user flow for non-technical Joe to acquire a client cert to pay his bills?

I just feel that if we'd put half the effort people put into SMS 2FA, authenticator apps, password managers and all that into making a better UX for client certificates, we'd be further along. Ah well.

Re: Why is OAuth still hard in 2023?

#196

Post by jcranmer » Thu, Apr 27, 2023, 2:49 AM UTC

codebje wrote: post #177

mattpallissard wrote: post #152

Earlier quoted context omitted.

> Kerberos as a much saner SSO system than OAuth. +1, it really solves nearly all the authn and federation problems. You still find KDC installations in places with large *nix footprints. Sometimes it's AD, sometimes it's MIT with a cross-realm trust. It's incredibly flexible and transparent to the user. It's easy for sysadmins, and various service owners to implement as it's basically drop a keytab in place, and set…

Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transf…

> Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client.

Not really. In practice, Kerberos means just loading the gssapi or sspi library, essentially using the user's login to already have the ticket-granting-ticket generated and usable for the subsequent tickets. As the client application, I never see the user's password; it's all handled for me by the OS.

Re: Why is OAuth still hard in 2023?

#197

Post by evntdrvn » Thu, Apr 27, 2023, 2:50 AM UTC

cogman10 wrote: post #169

skissane wrote: post #150

Earlier quoted context omitted.

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol OAuth supports lots of different scenarios. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which ha…

> And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. That's because OAuth in the industry has been changed to only talk about authentication (AuthN) and not (or very lightly) authorization (AuthZ). And, for the better, AuthZ is so use-case…

huh? OAuth is literally a "delegated authorization framework"

Re: Why is OAuth still hard in 2023?

#198

Post by LukeShu » Thu, Apr 27, 2023, 3:04 AM UTC

rtpg wrote: post #187

LukeShu wrote: post #163

Earlier quoted context omitted.

> > In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecifie…

In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? > How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): At the beginnin…

> In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction?

If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon signature verification. It could be anything.

> At the beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site.

So you redirect the user's browser to the IDP, with the nonce in the URL. The user grabs that nonce from the URL bar, then manually navigates to your redirection-endpoint, putting that nonce and their own fabricated token in the URL.

Re: Why is OAuth still hard in 2023?

#199

Post by indus » Thu, Apr 27, 2023, 3:22 AM UTC

Not one mention of flickr in your post...Would have loved it.

Re: Why is OAuth still hard in 2023?

#200

Post by hencq » Thu, Apr 27, 2023, 3:45 AM UTC

lukeed wrote: post #172

hencq wrote: post #134

Earlier quoted context omitted.

First off, congratulations on launching! I'm not sure why you're getting downvoted, because it seems quite relevant to the discussion. I'll definitely look at btn.social for my next hobby project. The pricing is super reasonable and the documentation very clear. One question I have around OAuth in general is whether it only applies for SPAs or if I could also use it for more traditional multi-page apps? I guess I cou…

Thank you! Not sure, just part of the orange site mystery~ Your `onlogin` callback will only ever be invoked by the SDK on successful login. So the data coming thru there is always the result of the OAuth flow itself. For MPAs, you can create your own document cookie and/or modify local/sessionStorage, and then every new page load will pull/load from those storage systems. SPAs can & should do the same – they just ha…

Ah great, thanks! It would be great to see a larger example on your site to see how this all ties together. For example, I don't really understand what's stopping anyone from opening dev console and just calling my 'onlogin' callback and passing it fake data to impersonate another user. It seems to me that somewhere I'd still need to verify the user data with the provider.

I fully realize that that's probably due to my own ignorance and no knock on you. However, maybe there's others like me who'd benefit from some more examples.