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

41–50 of 290 posts

Re: Why is OAuth still hard in 2023?

#41

Post by justrealist »

coderintherye wrote: post #19

Related 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…

Not to mention needing to create awkward shared service accounts to impersonate.

Re: Why is OAuth still hard in 2023?

#43

Post by cellularmitosis »

paulddraper wrote: post #9

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

On iOS, two applications can register as handling the same callback URI scheme. Which one gets the callback is non-deterministic. Thus, it is possible for some other app to get the token. I don’t see how an allowlist would mitigate this.

With PKCE, the other app can still intercept the token, but the token is incomplete and useless.

Re: Why is OAuth still hard in 2023?

#44

Post by agentultra »

My favourite are the appendices that amend the protocol to fix security issues that almost no API seems to implement properly. These can get quite long and are frequently amended with new drafts every year or two.

For example, most APIs don't implement PKCE in order to prevent injection attacks against the authorization code grant type.

Just keeping up with security practices is a full time job for teams.

Re: Why is OAuth still hard in 2023?

#45

Post by butisaidsudo »

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 read so many docs when I was trying to implement OAuth and got more and more confused. This video was a huge help though for explaining all of the concepts:

https://www.youtube.com/watch?v=996OiexHze0

Re: Why is OAuth still hard in 2023?

#46

Post by 411111111111111 »

stcroixx wrote: post #38

Probably because the part most of the world is actually interested in was later renamed 'Open ID Connect' and any attempt to research using the term OAuth will bring you nothing but incorrect, old, ad-hoc implementations and presentations by snake oil selling 'personalities' claiming they understand it.

Naw, the same applies to oidc. Especially in the browser.

The issue itself also sounds easy enough to implement that you might get suckered into rolling your own (you only need to do a redirect and a request every n-minutes) ... But it's surprisingly hard as there are a lot of edge cases with long running timers and potentially multiple browser tabs/windows etc.

Re: Why is OAuth still hard in 2023?

#47

Post by mixmastamyk »

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…

Looks great, taking a look and favoriting.

(Only feedback I can think of is that it would be great to have a few diagrams... like from excalidraw or something. Am largely a visual learner.)

Re: Why is OAuth still hard in 2023?

#48

Post by lll-o-lll »

coderintherye wrote: post #19

Related 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…

OAuth client credential flow is this easy mode you ask for. It’s one call with a secret in it and back comes a token.

Re: Why is OAuth still hard in 2023?

#49

Post by dwaite »

paulddraper wrote: post #34
dwaite wrote: post #28

Earlier quoted context omitted.

If one uses a redirect_uri with PKCE parameters to send a response a non-oauth endpoint, the AS is still acting as a redirector. It's typically not a list. You typically will have one redirect uri (at least, one per AS), because thats the communication endpoint defined by your client. There are other parameters like state to remember what you wanted to do after you had an access token. PKCE exists to bind the front-c…

The redirect_uri parameter is not a list. I am referring to the redirect allowlist registered out-of-band by the client: https://datatracker.ietf.org/doc/html/rfc6749#section-2

right. I was speaking to registration of redirect URIs - most clients should only register one, because they have only one endpoint (for that AS at least) for handling authorization responses. You should not use redirect URI for deep links, for example - you should capture pending actions to take after authorization separately.

You could hypothetically register redirect URI for the DNS names of your individual client cluster nodes, but there's no guarantee an AS will let you register as many URI as you have cluster nodes - and you will have a failure case to handle if the cluster node goes down mid-authorization, and coordination if you need to grow said cluster.

Re: Why is OAuth still hard in 2023?

#50

Post by missingdays »

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…

OAuth specification was the best source for me. All provider docs are simplified and usually specific to the provider
Post reply on HN