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

201–210 of 290 posts

Re: Why is OAuth still hard in 2023?

#201

Post by arwhatever »

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…

OAuth document writers love abstract, lofty nomenclature for everything.

I like what you’ve done here with your explanation - I can practically envision a couple (or three!) literal sock puppets giving me this perfectly adequate overview.

Re: Why is OAuth still hard in 2023?

#202

Post by codebje »

jcranmer wrote: post #196
codebje wrote: post #177

Earlier quoted context omitted.

Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. OAuth was invented to avoid the need to do that. If I use some finance package and I'd like it to download my transactions from my bank, I'd really rather not have to give it my username and password, with the full access that grants including the ability to lock me out of my bank account and transf…

> Kerberos just doesn't solve the same problem: it starts by giving your username and password to a fully trusted client. Not really. In practice, Kerberos means just loading the gssapi or sspi library, essentially using the user's login to already have the ticket-granting-ticket generated and usable for the subsequent tickets. As the client application, I never see the user's password; it's all handled for me by the…

The OS is the fully trusted client - but you can't repeat that trick for a web app running on a remote server.

Re: Why is OAuth still hard in 2023?

#203

Post by Rapzid »

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.

Asp.Net authentication is 10 times worse in this regard.

Re: Why is OAuth still hard in 2023?

#204

Post by sytringy05 »

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…

It's interesting to hear that because IHMO one of the reasons OAuth and JWT took over the world is that you can base64 decode the tokens and see whats inside them, compared to Kerb or NTLM which you eventually learn to spot based on their binary headers or whatever (eg NTLM tokens in HTTP Headers always start with "TRIM" for some reason)

I get the problem though, many of the libraries are not great or simply difficult to use

Re: Why is OAuth still hard in 2023?

#205

Post by izacus »

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

That doesn't explain what the library is trying to do and how it implements it though.

Re: Why is OAuth still hard in 2023?

#206

Post by sho »

domrdy wrote: post #180

I've been using WorkOS for my SaaS products and I'm pretty satisfied with it. It's straightforward to set up Google/Microsoft/MagicLink (free), including staging and production environments. The best part, though, is that it lets my enterprise customers configure their own SAML/OpenID Connect IDPs. I get charged per connection, so I just pass that cost onto my customers. As a solo developer, I'd have a hard time supp…

Their product looks great but the price seems insane. $125/m per connection? That's very hard to swallow for a SAAS looking to charge maybe $10-30 per seat. I get it, "enterprise!", but that's a pretty high barrier to entry for a company still establishing itself.

Re: Why is OAuth still hard in 2023?

#207

Post by krinchan »

LukeShu wrote: post #198
rtpg wrote: post #187

Earlier quoted context omitted.

In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? > How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): At the beginnin…

> In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon…

...what?

The server generates the auth code and redirects the user agent to your callback. You exchange that code with the IDP (over HTTPS which yeah that's its own nest of wormy trust) to get back a token. They can't inject a token because you don't get the token from them, just the one time code. If it's opaque you introspect it to validate or you just validate the JWT signature after pulling the keys from the JWKS endpoint. Introspection is standardized and an RFC. The state param is just a fucking session identifier.

All these URLs are defined and provided via the .well-known/openid-configuration endpoint. If your IDP publishes that endpoint correctly, most OAuth2 client libraries Just Work (TM) when pointed at the IDP domain.

Do EITHER of you even use OAuth2 outside of just cargo culting something you found off GitHub?

Re: Why is OAuth still hard in 2023?

#208

Post by phendrenad2 »

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…

This. Unfortunately, the problem is, the people making these tutorials don't know that OAuth is that simple. They just know how to use the library that the 3 lines of code are hidden within.

Re: Why is OAuth still hard in 2023?

#209

Post by krinchan »

evntdrvn wrote: post #197
cogman10 wrote: post #169

Earlier quoted context omitted.

> And that’s totally a use case the OAuth RFCs support (there is even an RFC specifically on token exchange), but a person wanting to add a “login with Google” button to their website isn’t interested in anything remotely like that. That's because OAuth in the industry has been changed to only talk about authentication (AuthN) and not (or very lightly) authorization (AuthZ). And, for the better, AuthZ is so use-case…

huh? OAuth is literally a "delegated authorization framework"

It isn't. OAuth2 really did away with AuthZ and focused on AuthN, regardless of what anyone says.

You have scopes but even those outside of the OIDC scopes are wishy washy and meaningless outside of each implementation.

Re: Why is OAuth still hard in 2023?

#210

Post by rtpg »

LukeShu wrote: post #198
rtpg wrote: post #187

Earlier quoted context omitted.

In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? > How do you validate tokens? (Either on the resource-server end, or on the client-end to know if trying to talk to a resource-server is a waste of time, or to know if your post-redirect-uri is getting spoofed): At the beginnin…

> In all honesty, though, "I have to look at the provider's documentation to determine like 4 URLs to add to a configuration" is not that wild of a thing? How much friction is too much friction? If it's something dumb/simple like grabbing a JWKS URL and an "issuer" URL, and then doing JWT validation, sure. Maybe you need to make a weird bespoke request to some other endpoint. Maybe you need to implement some uncommon…

One thing I could imagine here is a signature flow happening from the sender side where they sign the nonce + the token, to avoid forgery. I don't know what the signature validation looks like in that model though (if you request a public key from the provider, are you requesting that at every request flow? If you're not, now you're adding a request to every normal, non-malicious validation flow)

> Maybe you need to implement some uncommon signature verification. It could be anything.

So my feeling on this is that at the very least OAuth tends to be "well it's going to look like this, but there might be some tweaks".

I have set up OAuth verification with multiple services in the past. The social aspects and the business aspects have always been more complicated, but at least "it's OAuth" (much like "it's REST" for APIs) establishes a core understanding very quickly.

I'm open to saying that we should add more standard stuff to the flow, if it's optional then people who use oauth libraries will end up with a lot of this stuff by default. But I think the status quo is pretty nice, all things considered.

Post reply on HN