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

91–100 of 290 posts

Re: Why is OAuth still hard in 2023?

#91

Post by majormajor »

jcranmer wrote: post #75
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…

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…

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.

Re: Why is OAuth still hard in 2023?

#92

Post by dathinab »

1. because it's conceptually not an easy thing

2. because the standard was messed up (instead of specificing a protocol with _at most_ one clearly specified flow per use-case (you can use it for more then SSO/Cross App Auth) they specified something more like a framework to build your own standard, but still pretended it's a single protocol, but if you can't use the standard to "blindly" build a client which works without knowing anything about the vendor then it's not a protocol, at least not a complete one)

3. because the standard covers too much potential use cases

4. because vendors haven't yet converged their implementations enough and might never do so (time for OAuth 3 which just specified on specific OAuth2 flow implementation??)

Given that OAuth2 was started with clearly very different goals in mind and the main profiteers of the current situation are a few big companies like Google, Facebook and Microsoft I have heard people stating that OAuth2 being messed up was intentionally. _I don't believe so_, it more looks like a typical case of accidentally over engineering by trying to doing so much.

I still don't like the situation as OAuth2 was too some degree a coffin nail to the idea of generic SSO (i.e. you as a customer can freely choose a SSO provider when signing one) and that sucks really hard and if we had generic SSO passwords would be _way_ less of an issue today (imagine _any_ email provider could _easily_ also provide a SSO service for any side you can have an account with).

Re: Why is OAuth still hard in 2023?

#93

Post by adammarples »

btilly wrote: post #26
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…

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…

I'm bookmarking this to go through the next time I need to bang my head against this wall, thanks

Re: Why is OAuth still hard in 2023?

#94

Post by izacus »

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…

That drove me up the wall in Python so much - ALL the documentation just described how to put a massive library into a cookie cutter example and never explained how it's supposed to work so I could debug the darn thing.

Re: Why is OAuth still hard in 2023?

#95

Post by znpy »

Because authentication and authorization is a hard problem in general.

Hard to make it right, hard to make it secure, hard to make it simple. And exponentially harder to make it versatile.

And if oauth is "hard", wait until you see OpenID and the myriad of extensions...

Re: Why is OAuth still hard in 2023?

#96

Post by znpy »

jcranmer wrote: post #75
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…

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…

> In my experience with OAuth, one of the principle issues is that it's less a protocol and more a skeleton of a protocol.

Because it is, really.

OAuth (2.0) is really the backbone for OpenID.

Re: Why is OAuth still hard in 2023?

#97

Post by lll-o-lll »

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.

Client credential flow. It’s one call with a secret in it, and back comes the Access Token. If you want better security, it’s one call with a JWT signed by a private key. No browser, really easy to implement.

Re: Why is OAuth still hard in 2023?

#98

Post by znpy »

izacus wrote: post #94
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…

That drove me up the wall in Python so much - ALL the documentation just described how to put a massive library into a cookie cutter example and never explained how it's supposed to work so I could debug the darn thing.

when it comes to this kind of things there's really no way around it: you're supposed to read the RFCs:

- https://www.rfc-editor.org/rfc/rfc6749.html: The OAuth 2.0 Authorization Framework

- https://www.rfc-editor.org/rfc/rfc6750.html: The OAuth 2.0 Authorization Framework: Bearer Token Usage

Re: Why is OAuth still hard in 2023?

#99

Post by znpy »

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.

> Why? I have not a flipping idea.

https://www.rfc-editor.org/rfc/rfc6749.html contains everything you might want to know about OAuth in great detail :)

Post reply on HN