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

281–290 of 290 posts

Re: Why is OAuth still hard in 2023?

#281

Post by p_l »

cryptonector wrote: post #280
p_l wrote: post #277

Earlier quoted context omitted.

The most painful part of getting Kerberos logins working on web apps in one of my jobs was getting Firefox to accept Negotiate headers from our domains and actually perform GSSAPI exchange using users keytab. Windows has it somewhat centralized and well supported across many applications (especially those that simply use system-provided HTML widget), and at least Chrome automatically picks up system-wide config.

Just use a reverse proxy. Envoy, Nginx, whatever.

The problematic part wasn't handling Negotiate w/ GSSAPI on server side, it was handling Negotiate w/ GSSAPI on client side.

On keycloak side, it took a small configuration change (provide it with keytab, pretty much). By also using OIDC with Keycloak, I could ensure that access based on LDAP group membership was checked before accessing the application.

Re: Why is OAuth still hard in 2023?

#282

Post by cryptonector »

p_l wrote: post #281
cryptonector wrote: post #280

Earlier quoted context omitted.

Just use a reverse proxy. Envoy, Nginx, whatever.

The problematic part wasn't handling Negotiate w/ GSSAPI on server side, it was handling Negotiate w/ GSSAPI on client side. On keycloak side, it took a small configuration change (provide it with keytab, pretty much). By also using OIDC with Keycloak, I could ensure that access based on LDAP group membership was checked before accessing the application.

Hmm? All browsers, and curl, support Negotiate. There's support in many HTTP libraries for various languages as well. It's not universal though, that's for sure. At $WORK we have a [proprietary] client-side proxy to do Negotiate for apps that don't.

Re: Why is OAuth still hard in 2023?

#283

Post by dekhn »

magicalhippo wrote: post #190
dekhn wrote: post #62

Earlier quoted context omitted.

I'm an application develop who uses oauth, but it's only one in many authentication systems I've used, and certainly one of the worst.

Which others have you used which solves similar problems, but better? Genuinely curious.

Well, I use oauth only for authentication (IE, use it to get a trusted email address for the web user of my app), not authorization. Of all the systems I've used, kerberos has been the best authn solution, then basic auth to log in as a user where authorization is done in another ACL system (FS acls, for example).

My complaints are almost entirely about the ergonomics of writing oauth code in a server, provisioning the resources to make it work (like DNS), and then debugging 900 redirect_uri errors.

Re: Why is OAuth still hard in 2023?

#284

Post by lowdownfork »

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…

I recently did an OAuth integration with an API that documented its OAuth endpoints like all its other endpoints: including a mention of OAuth in the description but giving explanations and examples with curl, just like it would if there were no standard.

It was way easier than anything else I've done with OAuth (except log in as a user).

Re: Why is OAuth still hard in 2023?

#285

Post by mooreds »

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…

Does this meet your needs: https://fusionauth.io/docs/v1/tech/oauth/ (Curious because I work for them.)

I think the reason OAuth is so successful and prevalent is because it is so flexible. This let folks implement what they needed and not what they didn't.

Overspecifying things didn't help SAML, after all. There are still holes and unimplemented/incompatible options. Authentication and authorization, especially across systems and organizations, is hard.

Is there a simpler standard for third party delegated authorization?

Re: Why is OAuth still hard in 2023?

#286

Post by migf »

paulddraper wrote: post #265
ikiris wrote: post #121

Earlier quoted context omitted.

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

Don't the clients have to do a billion qps as their retrieve access/refresh tokens from their data stores?

Yeah, but it's a negligible rounding error of cpu time for each client.

Distributing this work ironically makes it much easier to centralize the authentication.

Re: Why is OAuth still hard in 2023?

#289

Post by sansnom »

lll-o-lll wrote: post #48
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.

The problem is "client credential" flow is not always available... And even if it were it might not as easy as you claim. In particular if you want to have an access token working on several instances. Most implementation allows only one access token at once so you need to have a shared storage and synchronization just for that...

If you are developing an API please have mercy: provide something other than OAuth. For me, avoid OAuth unless there is 3 distinct parties.

Re: Why is OAuth still hard in 2023?

#290

Post by lukeed »

sho wrote: post #206
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.

insane indeed. btn.social is 1 cent for 100 logins. no MAU shenanigans. won't bankrupt/drain most startups
Post reply on HN