Ask HN: Why is web auth not a solved issue? | Hacker News Reader

Ask HN: Why is web auth not a solved issue?

2 pointszwnow4 comments

Personally, every project I start, I quit due to not being comfortable with the auth implementation.

I've been into web development for 4 years now. During my research regarding auth in this timeframe, I have found a million reasons on why I should not roll it myself. The reason is always it being to difficult to implement, too much responsibility and basically no matter how I'd do it, it would be unsafe.

The general consensus among web developers seems to be to just let a third party do it. And I understand the reasoning, they are experts and have decades of experience on that specific thing. It makes sense as long as you're fine with third party service dependencies for your application. However, I don't want that. I do not feel comfortable submitting my users data to tech giants for obvious reasons.

I am wondering why it's so difficult to implement secure auth? Why can frameworks like Laravel or Phoenix just generate auth solutions? Why should I trust them, if everyone is saying I shouldn't roll it myself?

After all, if Laravels or Phoenix generated auth isn't safe, I am the one taking responsibility anyway, no?

To my understanding web auth has been an issue for decades now, why aren't there protocols in place to solve it? Or if they are, why aren't they talked about a lot?

Considering how often I read about auth breaches with the big players in the game (Firebase as an example) I am not comfortable trusting third parties with that task either.

So how is one supposed to do it? There are so many JWT tutorials on youtube, but apparently JWTs aren't safe either. Then there are session cookies, which also aren't safe? Why is that?

I am also not talking about authorization. I specifically mean authentication. If I wanted a micro blog platform where users can log into their accounts and write about stuff, how would I make sure it's secure without having to trust third parties, especially big tech companies who repeatedly prove they cant be trusted over and over again?

> if Laravels or Phoenix generated auth isn't safe

What makes you think they're not safe? Zillions of successful apps have been built using Laravel and Phoenix and (afaik) no-one has hacked their auth code yet. The code is open-source for anyone to inspect for vulnerabilities. I wouldn't feel unsafe using them.

You seem to misunderstand what it means to "roll your own auth".

"Don't roll your own auth" doesn't mean "use a third-party auth provider". It means "use an existing, expert-made auth solution and don't try to write it yourself."

That can be a third-party provider like Firebase, it can be a code dependency like Rails's Devise, it can be generated by `phx.gen.auth` in Phoenix, it doesn't matter - the point is that you're using a tried-and-tested auth solution written by someone who knows what they're doing.

Writing your own auth code is generally a bad idea because it's complicated, time-consuming and easy to get wrong. But there are zillions of off-the-shelf solutions you can use that have been created by security experts and battle-tested in thousands of production apps. As far as I'm concerned, web auth is a solved problem.

Interesting. When I generate auth for Phoenix the API endpoints are not piped through any security pipes. Only the browser endpoints. Why wouldn't I secure my API endpoints? The same kind of requests that are made for browser requests are sent to the API routes, so this is really confusing.

Ah yes. `phx.gen.auth` generates a cookie-based auth system, which is fine for the :browser pipeline but it's not generally what you want for a JSON API.

The Phoenix docs include a suggestion for how you can extend `phx.gen.auth` to add token-based authentication to your API: https://hexdocs.pm/phoenix/api_authentication.html

(No, this isn't "rolling your own auth" either, it's using someone else's pre-written auth code.)

> The general consensus among web developers seems to be to just let a third party do it.

Outside of personal projects, third-party auth providers must be audited (think GDPR or PIPL), budget must be allowed, contracts signed, etc. so web developers rarely, if ever, have their say on the matter. The decision is taken long before anyone wrote a single line of code. From a project management perspective, it's an easy trade-off to make: one sprint for integrating Okta versus who knows how many for badly implementing something that requires a level of expertise that no one on the team has reached.

For personal projects, the trade-off is a bit different. Resources are scarce so, even if implementing auth is actually not very complicated(1) and can even be quite fun, there are probably more immediately interesting things to do. So you integrate a third-party solution in a wednesday night and you move on.

[1] https://thecopenhagenbook.com/

Reply on news.ycombinator.com