Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why is OAuth still hard in 2023?

nango.dev

Post reply on HN
Print view View original

131–140 of 290 posts

Re: Why is OAuth still hard in 2023?

#131

Post by lmm »

klabb3 wrote: post #54
remus wrote: post #12

It'd be interesting to hear about people who have had a good time implementing OAuth, as my experience is similar to that in the article. I've played with adding it to a few side projects and the process usually goes: 1. Read loads of docs, end up pretty confused 2. Find a library that seems to do what I want 3. Install this huge library full of opaque code doing...things 4. Have an impossible time troubleshooting is…

We really deserve a less over-engineered actual standard that has a very restricted feature set. In practice, isn’t OAuth predominantly used to verify proof of email ownership? If so, why not just use magic links as sign up & sign in? 1. Sign in/up: Enter email (can be pre-filled by browser/app) 2. Click the email verification link or enter code if on different device. 3. Profit. No manual typing necessary, only clic…

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't want to have to switch apps a bunch, and may not have my email with me; doing it all in the browser is much nicer.

(On a side note, I'm constantly annoyed/frustrated that after about 20 years of development, authentication codes/apps and smartcode verification are starting to be almost as secure and usable as the HTTPS client certificate support that was built into every browser as far back as the '90s)

Re: Why is OAuth still hard in 2023?

#132

Post by danesparza »

thepasswordis wrote: post #61

Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…

Yeah -- I think you just described OpenID (not OAuth).

And to be honest, this is part of the problem. We use confusing (and sometimes conflicting) terminology to describe both authentication (identifying somebody) and authorization (making sure you have the right permissions to do something).

More information: https://stackoverflow.com/a/1087071/19020

Re: Why is OAuth still hard in 2023?

#133

Post by jiggawatts »

thepasswordis wrote: post #61

Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…

My personal frustration with the docs is that very similar words are used in sequence and for both generic and specific meanings.

“The possessor of the bearer token is authorised to re-request a refresh token code cookie.” is only a very slight exaggeration.

I also want to slap the Microsoft employees that use six different similar terms for three GUIDs that look identically random. E.g.: “Client ID (Principal ID)”.

It’s maddening.

Re: Why is OAuth still hard in 2023?

#134

Post by hencq »

lukeed wrote: post #32

It's easy with https://btn.social/ :D I made this because I was tired of asking the same question. There are a bunch of services out there trying to address the same thing, but unfortunately they get wildly expensive and they own/control your user data. Professionally, I've been a consultant and freelance developer for 10+ years. Time and time again I'd see teams start with Auth0/etc, only to eventually: 1. duplicate…

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 could do something similar to what you're doing in your guide [0] and do a POST from the onlogin callback, but how does my backend know that the payload is valid?

[0] https://docs.btn.social/guides/#link-a-payload-with-a-db-rec...

Re: Why is OAuth still hard in 2023?

#135

Post by matthewaveryusa »

paulddraper wrote: post #77
thepasswordis wrote: post #61

Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…

One reason is that the protocol itself is more complicated than you've described. For example, Google won't give you a long-lived access token. You need a refresh token, and then you use that to retrieve access tokens, and continue doing that as they expire. Why? I have not a flipping idea. Please, HN enlighten me how refresh/access token dichotomy improves the API.

There's the issue of scale, but also the issue of reducing the scope of a compromise.

If a short-lived token gets leaked the damage is limited to the TTL of the short-lived token.

If you were to pass around the long-lived token you would need to do forensics on the entire life of the token to figure out how/if the credential was used.

Just think very pragmatically about the probability to keep a short-lived token secret across all the places it's being transmitted vs. keeping the single API that exchanges the refresh token for a short-lived token super secure.

Re: Why is OAuth still hard in 2023?

#136

Post by dwaite »

haswell wrote: post #115
zmxz wrote: post #82

Earlier quoted context omitted.

You need 10 minutes of focused reading to understand what the purpose of the protocol is and you don't need all of the OAuth RFCs to implement the bare-minimum nor do you have to support all the grants available. Most people I worked with don't understand the purpose of OAuth and that's what the 10 minutes should be invested into. Or, you can, you know - nitpick and live in the world of gloom and doom where everythin…

For what it’s worth, I taught a series of classes/labs intended to help developers within my former employer’s ecosystem understand OAuth. What I learned after delivering the content to hundreds of devs over the years: OAuth confuses people, and for completely understandable reasons. Most people think about auth in terms of usernames/passwords or API keys. The mental models associated with these do not transfer to OA…

> Most people think about auth in terms of usernames/passwords or API keys.

OAuth is hard to explain here because it is not an authentication protocol, and without extensions has severe security flaws in being one. OpenID Connect is the most popular effort extending OAuth to also handle authentication.

But that doesn't change that the thing OAuth is most associated with is not what it actually sets out to accomplish.

Re: Why is OAuth still hard in 2023?

#137

Post by lukev »

Given that this seems to describe a real problem, why hasn't anyone launched a proxy service that normalizes across the varying implementations?

Why should tens of thousands of developers have to discover the particular quirks of an implementation instead of doing it once and re-using the results?

Re: Why is OAuth still hard in 2023?

#138

Post by eddiezane »

danesparza wrote: post #132
thepasswordis wrote: post #61

Because the documentation is bad. Oauth is really simple: Lets say you want to use google as an auth provider. You do this: "Hey google who is this guy? I'm going to send them to google.com/oauth, send them back to example.com/oauth, and in the headers of the request include the word "Authorization: bearer" followed by a bunch of text" Google says "Oh yeah I know that guy, here I'll send them back to where you said w…

Yeah -- I think you just described OpenID (not OAuth). And to be honest, this is part of the problem. We use confusing (and sometimes conflicting) terminology to describe both authentication (identifying somebody) and authorization (making sure you have the right permissions to do something). More information: https://stackoverflow.com/a/1087071/19020

I recently gave a talk on this and agree. While it was fun to learn, the difference between oauth and oidc isn't clear. Especially with what I've been referring to as oidc "wave 2" - machine to machine authentication without OAuth seemingly involved at all.

https://youtu.be/nW3xK6sh1Ck

Re: Why is OAuth still hard in 2023?

#139

Post by dwaite »

kierank wrote: post #79

Is there any good way to do OAuth on a headless system? I want to be able to run batch jobs without a browser involved. There's OAuth for devices but that has limited real world use.

OAuth is typically meant for a user (resource owner) to delegate some authorizations on a protected resource to a client. If your headless system is trying to hit an API with authorizations granted by particular users, you'll need some way for the users to grant that access.

But the client credential flow assumes the client _is_ a resource owner and already has authorizations to do its business. Thats what you would typically use for pure system-to-system use cases, and basically amounts to "hit this endpoint periodically to get the current API key"

Re: Why is OAuth still hard in 2023?

#140

Post by waboremo »

gigatexal wrote: post #113
majormajor wrote: post #91

Earlier quoted context omitted.

This is my experience. It's hard because it's very complex. As a non-domain-expert it's hard to separate necessary complexity from unnecessary complexity, but it feels like there's a lot of the latter, plus enough gotchas in the former ("oh, you didn't specify an encryption algorithm that we support in your request, and our logs are terribly unhelpful for realizing that") to make it a giant pain.

Is Webauthn a better standard?

If you were generally comparing standards: yes. Documentation with it is a breeze.

If you're talking about a "replace one standard with the next" type of comparison, then no. You can read more about why here https://oauth.net/webauthn/

Post reply on HN