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

151–160 of 290 posts

Re: Why is OAuth still hard in 2023?

#151

Post by gpspake »

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 had a good experience when I went in to a project with the attitude that "Ok, I'm going to wire up auth0 in perfect accordance with how they want me to, absolutely from scratch with the most perfect clean official documentation/library (in my case the react auth0 sdk) conforming approach possible.

I spent a lot of time making sure I did everything as by the book as possible and , in the end, I had a good experience and felt confident in my implementation, and like I understood all the moving parts. I even got help in a SO thread from an auth0 employee.

Auth0 could have been anything, here... On the same project, I kind of did the same thing with vite/react/tailwind client and fast api backend where I touched every piece of it, made every decision, and made sure I was really confident. This was in my own little vacuum where a big part of the app was just creating my perfect little sandbox. Stuff gets way more complicated when you have to hustle to get stuff over the line or you're trying to cram so new auth implementation in to an 8 yr old app that's been walked around on by dozens of engineers slamming out slop to close a ticket.

(Note: I know auth0 is a little more on-rails than implementing auth0 without it. They tend to have pretty good guides if you're using current hotness like react or fastapi)

Re: Why is OAuth still hard in 2023?

#152

Post by mattpallissard »

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…

> Kerberos as a much saner SSO system than OAuth.

+1, it really solves nearly all the authn and federation problems. You still find KDC installations in places with large *nix footprints. Sometimes it's AD, sometimes it's MIT with a cross-realm trust.

It's incredibly flexible and transparent to the user. It's easy for sysadmins, and various service owners to implement as it's basically drop a keytab in place, and set an environment variable for many daemons and libraries.

IMO, the only reason it fell out of favor with the web crowd is there wasn't a gaggle of centralized providers that let them stand up services without thinking about the infrastructure. It wasn't packaged up nicely.

Re: Why is OAuth still hard in 2023?

#154

Post by asdfman123 »

ikiris wrote: post #121
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.

You're free to handle a billion qps in authentication requests if you want. I don't suggest it.

Greatly reducing hosting costs at the expense of making someone else do a little more work sounds like a win to me.

Re: Why is OAuth still hard in 2023?

#155

Post by pl4nty »

pas wrote: post #147
derefr wrote: post #120

Earlier quoted context omitted.

And this is why there's five "log in with X" buttons on every webapp, but no "tell us your IdP and we'll send you there"; let alone any kind of magical "we'll take your email address and check the DNS record of the domain to figure out who your IdP is, and then send you there." Not because the "figuring out who to OAuth with from DNS" part would be hard to design; but because there's no way to "autodiscover" all thos…

OIDC Discovery to the rescue! https://swagger.io/docs/specification/authentication/openid-...

As much as I love OIDC, it still doesn't handle out-of-band client registration

Re: Why is OAuth still hard in 2023?

#156

Post by sytringy05 »

TallGuyShort wrote: post #107
znpy wrote: post #96

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

Yes, single log out is an ongoing nightmare. As many here have said the size and range of use cases that OAuth and OIDC support is off its head. And that's with the big boys who have millions of users, throw in ${EveryCorp} that implements its own token server and bespoke implementation of the auth, well.. good luck to the AI trying to take over our jobs.

Re: Why is OAuth still hard in 2023?

#157

Post by asdfman123 »

znpy wrote: post #98
izacus wrote: post #94

Earlier quoted context omitted.

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

As someone who is hired to sling out features as rapidly as possible, that’s not going to happen.

I mean, you might say “but you should” or “it would actually help” or “in an ideal world…” but it is still, realistically, not going to happen.

Re: Why is OAuth still hard in 2023?

#158

Post by asdfman123 »

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…

My preferred development style is

1) skimming for limited context

2) copying and pasting random code

3) trying it with print statements

4) getting stuck

5) repeating steps 1-3 until it works

Re: Why is OAuth still hard in 2023?

#159

Post by grepfru_it »

neurostimulant wrote: post #146
TallGuyShort wrote: post #107

Earlier quoted context omitted.

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.

I'm still salty about how keycloak changed their openid logout behavior, removed the old behavior in the new version when there are still a lot of oidc clients out there that still expect the old behavior. I have two inatances of keycloak using the same version and somehow both have different iodc logout behaviors. I think it's due to one instance was upgraded from older version and inherited the old behavior, but I…

Can you elaborate on this a bit? My logout process through keycloak is through a hidden (back channel) url. As long as I hit that client url it will end the session. Applications, I find, have different behaviors. Gitea logs out the session, portainer just clears browser cookies but the session remains active

I’m using the same keycloak setup for almost 2 years now, with upgrades

Re: Why is OAuth still hard in 2023?

#160

Post by sytringy05 »

rad_gruchalski wrote: post #109
radlad wrote: post #104

Earlier quoted context omitted.

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

The whole point of access tokens is to not do expensive checks on every request. Signature checks out and isn't expired - you are free to go. This is a core design thing of OAuth, once access tokens are out the door they are very hard to stop, so only let them last for 5 or 10 mins and use refresh tokens to get new access tokens.

Refresh tokens are your chance to do all the expensive checks - maybe you are IP restricted or want to step up with MFA etc etc. Check revocation etc

Post reply on HN