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

181–190 of 290 posts

Re: Why is OAuth still hard in 2023?

#181

Post by throwaway2037 »

mattpallissard wrote: post #152
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…

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

As a developer that needs to use Kerberos for authentication between hosted services, I can say that Kerberos is simply awful to debug. When you have a failed login (refuse to auth), it is so hard for the _average_ developer to debug. We have pages and pages of cookbook solutions to various problems. Some issues are purely due to Kerberos complexity, and other issues are due to each programming language and their implementation of Kerberos. Most developers have no idea how SPNEGO works (Kerberos auth over HTTPS). I spend a lot of time on these issues, and I only have a surface understanding of SPNEGO. Oh yeah, and there are many subtle issues of Microsoft Active Directory (AD) vs MIT Kerberos.

Re: Why is OAuth still hard in 2023?

#182

Post by wildrhythms »

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 completely agree. What I want 99% of the time is basically a Javadoc showing the methods, the inputs, and the outputs, and all of the types. And if there's a short summary and an example as supplemental material, that's great.

Unfortunately, developers seem to think their contrived examples are a stand-in for actually documenting the methods. I deal with a lot of Javascript libraries like this and it drives me insane.

Re: Why is OAuth still hard in 2023?

#183

Post by codebje »

derefr wrote: post #120
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…

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…

There's a single URL for OIDC IdPs too. It's not supported in every web app for the same reason SAML isn't: it's a two-way exchange to set up, not a one-way exchange. In OIDC (OAuth 2) you need to register a client first. In SAML you need to register a Service Provider first. Only after you've done those steps will you be able to plug the magic configuration in and have it work.

SAML is too limited to compete with OIDC/OAuth2 on the web, but it's got some advantages for enterprise authentication, so it won't be going anywhere.

Re: Why is OAuth still hard in 2023?

#184

Post by idlewords »

mdavidn wrote: post #124
idlewords wrote: post #78

I never understood how Oauth as a user experience is supposed to be distinguishable from phishing.

Password managers mitigate this. If the form doesn't offer to fill my saved password, that immediately raises red flags in my head. I immediately bail out or manually validate domains.

I've found that if I haven't updated Chrome then my password manager plugin stops working, which happens frequently enough that this would no longer raise red flags for me. Every layer of security conspires to defeat every other one.

Re: Why is OAuth still hard in 2023?

#185

Post by codebje »

pl4nty wrote: post #155
pas wrote: post #147

Earlier quoted context omitted.

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

https://datatracker.ietf.org/doc/rfc7591/

The only reason an authorisation server would support dynamic client registration, however, is because it's meant to be pluggable as the back-end for an API integration suite like Kong Enterprise.

The solutions that are one big well-known IdP have no reason to want it, so Google Auth, Amazon Cognito, and similar all don't support it.

The solutions that are aimed at letting organisations be an IdP do have reason to offer it: it makes being an IdP easier, because you can stand up a client registration service without using vendor-specific interfaces.

No-one who operates an IdP wants arbitrary, uncontrolled public client registration. It'll get abused directly, and it'll enable further abuse of the systems the IdP is meant to protect.

Re: Why is OAuth still hard in 2023?

#186

Post by onetimeusename »

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 have seen a lot of people get caught up on things like the client_id, client_secret, redirect URL, and scopes. This is relevant when you have a lot of tenancies for your customers and want them to log in via some OAuth provider. Do you create a new client_id for every tenant? Should you distribute a client_secret? Did you properly configure the redirect? Proving identity is the easy part though. Are scopes too broad or too narrow to accomplish the app's goals? Are there unintended consequences? Those kinds of things can slow down development.

Re: Why is OAuth still hard in 2023?

#187

Post by rtpg »

LukeShu wrote: post #163
skissane wrote: post #150

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. Many people when they say “OAuth” they are only thinking of one or two of those scenarios, and ignoring all the others which aren’t relevant to them personally-but may be relevant to someone else I worked on a system where we had a micro-service which ha…

> > 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 beginning of the "standard" OAuth flow you can pass in client state. So you generate a signed nonce. Remember, you are starting this flow, so you mix in some user data (avoids CSRF problems), and you are pointing to some HTTPS site.

This is not 100% perfect compared to "remote server has some signing" but it does allow purely local verification of tokens when they are first received, as you can stick stuff into the "state" request parameter (as anyone should be anyways to avoid trickery).

Re: Why is OAuth still hard in 2023?

#188

Post by magicalhippo »

Aeolun wrote: post #126
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…

When I stopped using libraries and implemented my own things got a lot less frustrating. Still a pain in the ass, but I didn’t feel like the errors came out of nowhere any more anyway.

Yeah I've just implemented it myself. Google, Microsoft and some other OIDC provider.

I abstracted it away behind a "token provider" interface, so I can just instantiate the right one for the job.

There's some incantations to get the request right, but I found most documentation decent so just follow that.

One service required I implemented RFC 8693 token exchange, which turned out to be trivial since I could represent it as one "token provider" instance wrapping another.

Failures can still be opaque though, especially when using the tokens.

Re: Why is OAuth still hard in 2023?

#189

Post by xyst »

Personally, I have transitioned away from these third party IdPs. I have turned to spinning up my own authentication and authorization stack using an open source ecosystem like "Ory".

With just a single helmfile, I can deploy the entire application stack on my local machine (authN, authZ, smtp server,app db, application). Gives me ease that I don't have to rely on a third party vendor just for testing simple app flows. Transitioning to production is a simple swap of DSNs (database connection strings, real smtp servers, ...). Also, no more burning money when running simple tests or performing load tests with dummy users when using an external/managed IdP.

Still need to experiment with how upgrading will work and migration of user data. But otherwise I am a happy user/developer.

Re: Why is OAuth still hard in 2023?

#190

Post by magicalhippo »

dekhn wrote: post #62
9dev wrote: post #57

Earlier quoted context omitted.

Right. Do all of those dumb dialogs that allow you to sign in using your Google account, import data from one cloud to another, add integrations from third party providers to other apps… they are all solving problems you don’t have? OAuth is one of that pieces of infrastructure that power lots of things without people even noticing them, but don’t bode well with armchair engineers.

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.

Post reply on HN