Hacker News Reader

Comment by shadowbanned4 | Hacker News Reader

This is practical, but awful advice. Auth (z or n) has been very badly over engineered. You don't need anything more than http basic auth, the rest is just people with too much time on their hands. Oauth particularly is a travesty that their authors should be ashamed of.

View on HN

OAuth 2.0 took the best features of what was already being deployed by Google, Microsoft, Yahoo, etc. and added in scopes and refresh tokens. The objective was to standardize how to delegate authorization so that developers did not have to learn slightly different ways of doing effectively the same thing.

Typing your username and password into a 3P website so it could crawl your contacts was horrible anti-pattern.

It depends!

(I work for an auth vendor, so where I stand depends on where I sit, to some extent.)

I've seen and built apps that only needed built-in framework or language support. Or, best of all, don't use authentication at all.

I've also seen and/or built apps that needed advanced functionality to support business requirements. For example, if you want to:

* support slack-like workspace switching functionality for a single user

* but allow each organization to control the login methods they want to allow, including magic links, SAML, OIDC, LDAP, etc

* and make all APIs securely and scalably available to single page applications and mobile applications

* across hundreds of thousands or millions of users

You're going to want to use some of the more complicated standards. Basic auth ain't gonna help with that.

I worked for the largest company in Canada who handled billions of dollars. You can make your decision but they won't do anything.

They still used basic auth across all their apps?

No. They used Oauth. I wrote their entire Oauth system. And it was a nightmare reading through Oauth/OIDC specs for something that could be handled trivially with http basic auth.

I work on the cloud security team for a Fortune 500 company. They won’t even consider a third party service that doesn’t provide a enterprise SSO/SAML integration with our auth provider. I suspect this is the more common approach for enterprise level companies given that at 40k+ employees it’s just not possible to manage employee auth across hundreds of services.

Reply on news.ycombinator.com