Hacker News new | past | comments | ask | show | jobs | submit login

1. Why does every end-point being able to refresh a token (or whatever you want to call it) imply that auth must not be a concern? I will fully admit that I've never worked on really large scale web services, so hopefully that's not a super obvious thing.

I would think that having all pages be able to handle auth is just a architecture question. Maybe I've just been too deep for too long in writing a webserver in Iron [0], but the way you handle auth in it, by using middleware and wrapping any endpoint that needs auth with an auth handler, makes doing something like this trivial.

2. Definitely left out a lot, I mean it doesn't really return anything at all. Just meant it as some shorthand pseudo code to make explaining it shorter. :)

[0] https://github.com/iron/iron

EDIT: Actually now I'm not sure if you're talking server-side or client-side, but I think the argument still stands. I was assuming auth "tokens" could actually be cookies, but even if not, your API library just needs to have a check to see the the request returned updated auth. It's still just in one place, handled in all calls, rather than just the single call that would otherwise handle it.




I was referring to server side. If you're really serious about security, you probably want to isolate the login process to a dedicated server. If your web server is breached, do you really want your auth keys leaked? And do you really want access to your user's creds available en masse to the breached server?

If you're running a small scale service, you're unlikely to build a dedicated login service. If you're running a large scale service, you probably should.

Edit: Based on Thomas's answers here, I am wrong about this, so I guess take my thoughts with a grain of salt.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: