TL;DL not really, but you may as well use some of it.
Almost any single page application needs some way of communicating with the server to get the data they want to work with. And many of them want to have personal data, with means knowing who the user is. The traditional way of doing this was with session state, but this doesn't scale well. More recently there is more emphasis on access tokens - essentially session state stored on the client instead. This scales a lot better, but you need some way to get a token to use.
This is often where things like OAuth2 or OpenID Connect come in. These offer frameworks in which a client can obtain an access token to use to talk to the server. And they are very hard to implement correctly.
My personnel recommendation is to ignore the bulk of OAuth2 for now. Implement access token auth in your server, and implement a simplified version of OAuth2 implicit flow, and leave it there.
What do I mean by the simplified implicit flow? You simply have a single page you open for the user to log in with, that redirects to a hard coded URL with the access token details. This hard coded page can then access a JavaScript function in its windows parent and pass the access token to that. Job done. No need to worry about Client Auth, Scopes, Redirect URIs, Refresh Tokens, support for multiple flows, or any of the other stuff needed.
Doing this, you're also in a position that, should you need to, you can actually implement OAuth2 in the future and it just drops in. Or you can use third party auth - e.g. Google or Twitter - and it just works. Very simple to implement and very little to change should it need to be reimplemented in the future.
Remember - YAGNI and MVP are king. Don't do things until you need to, because you might never need to.
Top comments (7)
Or you could use a decent open source identity and access management system, like OpenAM? Writing your own security code seems to me like a very dubious practice, and is surely not core to your business?
I strongly agree! The standard is pretty complex and implementing it without vulnerabilities is nothing you do just btw.
Is the assumption here session == cookie? I'm not aware of any framework that uses session for auth.
Tomcat, for example, manages a user session where it stores the session ID in either a cookie or the URL - for browsers that don't have cookies enabled. This session then lets the server store arbitrary serialisable data which is available on all future requests, and it can be configured such that this session is shared between multiple servers if you are running load balanced sets. I've seen - and personally written - several applications where the authenticated user was simply stored in the session and the container managed it. It works, but if you don't get it set up right then the user finds themselves logged out when they hit a different server for their request.
Ah, yeah, seems to be pretty standard in Java stuff, which I avoided because of some experiences with Tomcat. ASP.NET uses a separate auth cookie from the session cookie. Even way back when I was doing PHP, it never occurred to me to lump the auth in with the session.
Sessions have made it on my list of top hated things, I wouldn't use them for anything. But, comparing auth cookie without session vs auth token, tokens look like the better option.
Are you sure your hand-rolled protocol will resist replay attacks, Login CSRF, etc? There are good reasons why these protocols are complex.
I think whats being said is that OAuth/OpenID is harder than it should be to get going. I think is more a way to say - Here's a cheap way to create a place holder for OAuth so you dont loose 8-16 hours on a weekend tripped up over some small thing you forgot to tod. I'd rather spend 16 hours building out your cool idea and find out if THAT works and then put in OAuth when my idea is taking shape