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

101–110 of 290 posts

Re: Why is OAuth still hard in 2023?

#101

Post by smackeyacky »

My various brushes with OAuth and OIDC and FAPI have been horrible. The spec is written poorly, everybody seems to have their own idea of how it should work, nobody seems to implement the same thing.

Add to that the various version of OAuth/OIDC/FAPI and no clear migration path laid out to upgrade and it's a basic nightmare.

The Australia CDR (Consumer Data Right) notionally supports FAPI but they have their own interpretation of what is right so you simply can't use an off-the-shelf library to do anything.

The only way to preserve any kind of inter-operability is to wait for some other sucker to release their interpretation of this standard and everybody else in the eco-system has to test against that and eventually call it good.

Add to that - I just can't see why it has to be that complicated. Sometimes you can request signed+encrypted tokens, sometimes not, you can query the provider to ask them what they support but there are holes and gray area defaults for algorithms and encryption schemes and the whole thing needs to be set fire to and abandoned.

Re: Why is OAuth still hard in 2023?

#102

Post by 0x457 »

anarchogeek wrote: post #81

Because OAuth 2.0 sucks and got all bloated. The 1.0 version worked great for everybody but super big companies like google and facebook. But then big companies came in and made it a bloated standard that doesn't meet the needs of most users.

That's not entirely true. OAuth 1.0 and 2.0 didn't cover much, and everything was implementation specific. Both standards only cover authorization, while the majority of consumers wanted to use it as authentication.

Big companies had to roll out their own authentication layer on top. When OIDC came into play, it was already too late.

Re: Why is OAuth still hard in 2023?

#103

Post by rad_gruchalski »

dflock wrote: post #87
paulddraper wrote: post #77

Earlier quoted context omitted.

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.

It's really trying to solve a problem they created by statlessly handing out tokens instead of keeping session state on the backend - they have no way to revoke a token once issued, so long lived tokens are a liability. Solution? More complexity! Hand out very short lived tokens, along with a slightly longer lived refresh token, which only allows you get a new bearer/access token.

Don't they still require some state to be able t invalidate refresh tokens?

Re: Why is OAuth still hard in 2023?

#104

Post by radlad »

rad_gruchalski wrote: post #103
dflock wrote: post #87

Earlier quoted context omitted.

It's really trying to solve a problem they created by statlessly handing out tokens instead of keeping session state on the backend - they have no way to revoke a token once issued, so long lived tokens are a liability. Solution? More complexity! Hand out very short lived tokens, along with a slightly longer lived refresh token, which only allows you get a new bearer/access token.

Don't they still require some state to be able t invalidate refresh tokens?

Yes, but checking refresh tokens will occur much less frequently than checking access tokens. So you can imagine, for example, access tokens being JWT, so they are cheap to check. But every so often you have to validate the refresh token against MySQL (or BigQuery or what-have-you), which is more expensive.

Re: Why is OAuth still hard in 2023?

#105

Post by jkubicek »

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…

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 providers" OK, that must be the Mastodon service.

> ... to write many APIs that users

"users" That must be me

> ... can securely authorize third party consumers

"consumers" OK... that's also me?

Re: Why is OAuth still hard in 2023?

#106

Post by Operyl »

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…

Users are your users shared with the users of that API service (which may include you if you use your own service), consumer in this case is you (the application you're running).

Re: Why is OAuth still hard in 2023?

#107

Post by TallGuyShort »

znpy wrote: post #96
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…

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

OpenID Connect, specifically, where a lot of people mix those up and start looking at using OAuth for authentication. And if I'm not mistaken, logging out is implementation-dependent in OpenID Connect. There's some pseudo-standards but implementations vary in my experience. And OpenID Connect also has multiple flows for different kinds of applications. There's still a lot of confusion and complexity here.

Re: Why is OAuth still hard in 2023?

#108

Post by btilly »

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…

That is why there is a terminology section: https://metacpan.org/dist/LWP-Authen-OAuth2/view/lib/LWP/Aut...

If you're trying to write a Mastadon client, then the Mastadon service is the service provider, you are the consumer, and the people who wish to use your client are the users.

Re: Why is OAuth still hard in 2023?

#109

Post by rad_gruchalski »

radlad wrote: post #104
rad_gruchalski wrote: post #103

Earlier quoted context omitted.

Don't they still require some state to be able t invalidate refresh tokens?

Yes, but checking refresh tokens will occur much less frequently than checking access tokens. So you can imagine, for example, access tokens being JWT, so they are cheap to check. But every so often you have to validate the refresh token against MySQL (or BigQuery or what-have-you), which is more expensive.

That's all clear to me. But technically there exists a method to revoke an issued token. It's just that long lived tokens mean potentially lots of them == increased storage cost. It would be pretty silly not to check for revocation. How would one implement logout otherwise? Relying on just clearing session cookies? What if I obtained those cookies using something else than a browser and I can hold on to the cookie jar? Not checking for revocation == doing it wrong.

The purpose of a refresh token to allow the app to short circuit the login process. Regardless of how long the token is issued for. It's perfectly okay to ignore refresh tokens altogether, if one wants to.

Re: Why is OAuth still hard in 2023?

#110

Post by klabb3 »

p_l wrote: post #85
klabb3 wrote: post #54

Earlier quoted context omitted.

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…

It would simply not handle pretty much any case that I have used OAuth2 to implement so far. For example - login system that merged LDAP/Kerberos/client cert/long-lived application token authentication into single system, that also linked said authentication system into all applications in the network, including making it possible to login to AWS Console using Kerberos (that one was twisty to get running, not because…

For service accounts, email is clearly not the right choice. I don’t have experience with enterprise auth, are Kerberos etc not using company email for human identity?

> this proposed system requires that every app has ability to send emails, which honestly is less simple than it sounds

For humans and especially end-users of consumer services, my observation is that the elaborate auth dances are using email ownership as last resort anyway, ie for account recovery and/or a trusted 3p that has verified the email. So the thought is simply to make that flow more convenient. Perhaps this is misguided.

Post reply on HN