Previously we have managed to finally get rid of that Session object and transform our RESTful API security to leverage a stateless authentication solution. We replaced our beloved JSESSIONID with a simple string of text, a token, that allowed us to identify a user. But the solution we used is not secure at all. We still need to find a token with the right characteristics to be safe enough in this world of leaks and breaches. Enter JWTs...
Last time we reviewed how to quickly set up stateful authentication on our Spring-based project. That's very nice 'n' all, and in many cases you won't need anything more. However shouldn't we try to get rid of that session-based dependency and attempt to move to a REST-friendly stateless authentication solution? Let's begin...
After a quick introduction we are now ready to begin our journey towards stateless authentication for RESTful APIs... by setting up a stateful example. Yes I know, but we have to start somewhere, right? In this part we'll set up our project and code a couple of simple endpoints. One of those will be secured using Spring Security's session-based authentication.
By now "stateful" or session-based authentication is pretty much well-accepted. Frameworks such as Spring Security or Apache Shiro make it really easy to implement a decent solution in just a few easy steps. I previously discussed how to secure a Spring-based REST API using Spring Security for authentication, CSRF protection and CORS. But in some cases, session-based security might not be good enough...
Software companies used to have one goal: to develop efficient applications that users liked. When people switched from desktop to SaaS / web applications, companies were forced to focus on security to avoid being hacked. Now they will have a new mission: to ensure the privacy of their users. At any costs.
You are developing your web client (AngularJS or any other) against your REST services' server, secured using cookies-based sessions and CSRF tokens sent as cookies. You've done everything by the book, followed the tutorials to make your security work, especially CORS and CSRF tokens. And yet you still get a pesky 403 when trying to login!
In October 2015 me and my partner-in-dev Emad Heydari Beni ran a small survey on how our blog readers, friends and relatives felt about privacy and security on the Internet. The survey was closed November the 11th and we started analyzing the data we had gathered. The short version? We were actually surprised at some of the answers!
One month ago, me and my friend decided to run a survey about your perception of privacy and security on the Internet.
We’ve gathered enough (anonymous) data, so today we decided to close the survey.
I would like to personally thank all of you who took the time to respond. As promised, we will analyze and publish your responses and our conclusions on them in a forthcoming blog post.
Once again: thank you all for your help!
After a summer break we return to our secure web client / REST-based solution: in this post we examine how our AngularJS-based web client should behave in order to comply with the security measures we've enforced on the server side.