Because most OAuth libraries are very incomplete.
They implement a few happy parths of the standard, but a lot of things are just not there.
Why is OAuth still hard in 2023?
71–80 of 290 posts
Re: Why is OAuth still hard in 2023?
#72Example: What is the purpose of OAuth having specifications for redirect URI allowlist AND PKCE? None. They are entirely duplicative features. But ... reason, reason, reason ... they both exist, and are going to exist, forever. EDIT: I should say, PKCE is a functional superset of redirect URI allowlist.
Correct me if I'm wrong, but what you're implying here is that PKCE and URI allowlist are the same feature because if you specify URI allowlist while initializing the flow - it somehow helps public clients to prove they're the apps that initialized the flow and are the ones who are finalizing it?
Could you please expand on that thought, I'm genuinely curious if you actually might be right or whether this assumption of yours is how we get security holes.
Re: Why is OAuth still hard in 2023?
#73OAuth sucks. It's one of the worst abstractions of our time. It's incredibly easy to implement some half assed spaghetti and call it "standard OAuth".
It doesn't suck, it's literally bare-minimum what you need in order to securely retrieve the token. It's by far not THE worst, you're spouting total nonsense. What's THE worst is lack of attention, and one needs quite literally 10 minutes to read the RFC and understand it's fairly simple protocol with minimal number of parameters. I'm sorry you had a hard time with OAuth, but have you ever thought the problem is in y…
> and one needs quite literally 10 minutes to read the RFC
rfc 6749 is 4259 words according to wc -l. You mean that it takes 10 minutes to carelessly skim it.
Never mind that there are several other OAuth RFCs.
Re: Why is OAuth still hard in 2023?
#74Because 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…
Auth0 has a business incentive to have people think their core competency is more difficult than it is.
[deleted]
Re: Why is OAuth still hard in 2023?
#75Because 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…
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-dependent webpage, with implementation-dependent parameters (which ones are required are--you guessed it--implementation-dependent), telling them to redirect you to your page when you're done. Well, actually, that assumes you're building a website. If you're a desktop application, you'll do something else. If you're on an embedded system that can't open up a webpage, there's another option. And there's yet more flows. Which ones are supported by the provider? You guessed it, it's all implementation-dependent. Oh, and maybe you need to refresh tokens to login the future. When? If? You guessed it, implementation-dependent!
It makes writing a generic OAuth client library hard because there's basically no commonality there. Really, it makes me long for Kerberos as a much saner SSO system than OAuth.
Re: Why is OAuth still hard in 2023?
#76Related gripe: Your API doesn't always need OAuth. If I'm using your product as your customer and I directly want to leverage my own product data via your API then I shouldn't be forced to have to implement [your almost invariably non-standard and difficult] OAuth implementation. An API key should be an option or HMAC if the extra security is felt to be warranted, but not the absurdity of needing to go through a clie…
If you want to have password reset, OTP, 2FA, webauthn and so on, you probably want to use an external authentication provider. Integrating it with oidc/oauth is much easier, than doing all that stuff by yourself.
Re: Why is OAuth still hard in 2023?
#77Because 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.
Re: Why is OAuth still hard in 2023?
#78I never understood how Oauth as a user experience is supposed to be distinguishable from phishing.
Re: Why is OAuth still hard in 2023?
#79Is 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.
Re: Why is OAuth still hard in 2023?
#80Related gripe: Your API doesn't always need OAuth. If I'm using your product as your customer and I directly want to leverage my own product data via your API then I shouldn't be forced to have to implement [your almost invariably non-standard and difficult] OAuth implementation. An API key should be an option or HMAC if the extra security is felt to be warranted, but not the absurdity of needing to go through a clie…
I ran into that recently trying to connect a web shop we've built to an accounting platform. The web shop handles the entire checkout flow, but the owners also want a copy of the invoice stored in their accounting platform. The platform has an API. So our web shop can ping the accounting platform after an order is placed, and sent them a record of what was purchased? No. Because the API requires authorization. So the admin has to occasionally log into our website and hit a button to send invoices to the accounting platform. (At least we can send multiple invoices at once, so it doesn't require them to hit a button on each individual one.)