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

261–270 of 290 posts

Re: Why is OAuth still hard in 2023?

#261

Post by [deleted] »

asdfman123 wrote: post #157
znpy wrote: post #98

Earlier quoted context omitted.

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.

[deleted]

Re: Why is OAuth still hard in 2023?

#262

Post by Hizonner »

rtpg wrote: post #187
LukeShu wrote: post #163

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 > OAuth supports lots of different scenarios. But it's literally only the skeleton of a protocol ("framework" of a protocol, as the actual spec puts it). That important "Then later on you can take the token and say 'Hey google, somebody gave me this token, who is it?'" part is totally unspecifie…

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…

Any friction whatsoever is too much friction. By default, any user should be able to use any provider for any service, with no prearrangement between the service and the provider.

Anything less than that predictably leads to the situation we have now where a very small number of very large providers control identity and authentication for way too fucking many things.

Re: Why is OAuth still hard in 2023?

#263

Post by elevation »

madeofpalk wrote: post #145
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've reimplemented oauth for the same provider (bungie.net) countless times. I think it might seem daunting, but when you break it down into the steps it's pretty simple: - Send user to example.com - Eventually they're sent back to yoursite.com with a ?code=abc - Call example.com/OAuth to exchange ?code=abc for access token and refresh token - You're done (for now) - When access token expires, call example.com/OAuth…

I have an application with this flow already implemented to authenticate a user.

But the application currently has it's own authorization policy in a flat file which organizes users into groups and gives groups permission to take certain actions, a simple RBAC. I'd like to refactor this so that the authorization is delegated to the OAuth server.

Ideally I want to be able to ask a keycloak/okta server "now that user X is authenticated, are they part of the group Y?".

Since this isn't a common use case and everything is so abstract it's been very difficult to find an obvious path forward.

Re: Why is OAuth still hard in 2023?

#264

Post by paulddraper »

0x457 wrote: post #88
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.

Very simple, actually. Access tokens are short-lived and are irrevocable - google services only check validity and expiration of those tokens. Refresh tokens are more like session tokens/cookies - those get checked every time. At Google scale, checking it probably expensive, so they are using refresh tokens. These aren't for end-user or development experience, those are for AS performance.

That just pushes the problem around, yes?

So now the client servers have store/check the lifetime of tokens rather than resource servers.

Does that actually improve OAuth as a whole?

Re: Why is OAuth still hard in 2023?

#265

Post by paulddraper »

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.

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

Re: Why is OAuth still hard in 2023?

#266

Post by cryptonector »

p_l wrote: post #239
cryptonector wrote: post #220

Earlier quoted context omitted.

But let's tell the truth: this is NOT user-friendly. Compare to Negotiate.

Oh boy, Negotiate. The wonderful system that works easily only on Windows. I love it though, I use it as part of OIDC flows, because then I don't need to directly implement it for every application, I just make them call to Keycloak for it.

It works on Unix, what are you talking about.

Re: Why is OAuth still hard in 2023?

#267

Post by paulddraper »

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

The difference is that the RFC covers everything, whereas OAuth providers choose a subset of what they actually want to support.

Search engine > Encyclopedia

Re: Why is OAuth still hard in 2023?

#268

Post by paulddraper »

webhamster wrote: post #228
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.

That's not correct. There are a number of attacks that can be mitigated by both, but PKCE serves as a very effective defense in case an authorization code leaks to an attacker. Such a leak can be caused by a malicious script on the redirect URI, referer headers, system or firewall logs, mix-up attacks and other problems even when the redirect URIs are restricted. There is a good reason why we mandate both redirect UR…

Your comment doesn't explain what attack can be mitigated by redirect allowlist but not PKCE.

Re: Why is OAuth still hard in 2023?

#269

Post by hencq »

lukeed wrote: post #256
hencq wrote: post #200

Earlier quoted context omitted.

Ah great, thanks! It would be great to see a larger example on your site to see how this all ties together. For example, I don't really understand what's stopping anyone from opening dev console and just calling my 'onlogin' callback and passing it fake data to impersonate another user. It seems to me that somewhere I'd still need to verify the user data with the provider. I fully realize that that's probably due to…

For sure! There are some larger examples coming so that people can see it plugged into a more real-world application. RE: onlogin, that method accepts a callback handler that is added to an internal/private array of callbacks to run once the `popup` or `redirect` sequence has finalized. It's the only externally-facing "doorway" into the OAuth flow. Everything else is inciting action (`popup()` and `redirect()`) or a…

Thanks!

Re: Why is OAuth still hard in 2023?

#270

Post by mattpallissard »

codebje wrote: post #177
mattpallissard wrote: post #152

Earlier quoted context omitted.

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

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.

That's incorrect. The client doesn't need to be trusted at all. There is also there anonymous auth, certs via pkinit (which give you yubiki and piv/cac cards as well), and otp.

> Kerberos was never popular with the web crowd because it's not capable of solving the problem of authorizing web applications.

In MS kerberos, group membership comes over with a TGT in the from of a PAC.

> Before OAuth everywhere just asked for your username and password to log in on your behalf.

I'm taking about kerberos, you'd use a TGT to log into that service.

> And the only reason Kerberos works well today is that it's always now a single-vendor solution, homogeneous across the deployment. It's an interoperability nightmare otherwise.

There are a lot of cross realm trusts between MIT/AD and Heimdall/AD, and they just work. It really isn't difficult. As I said in my original comment, it's just that it wasn't packaged up nicely. All the parts are there.

Post reply on HN