While Spring Framework – and in particular Spring Security – provides many ways to deal with authentication and authorization, there are some new approaches that are becoming increasingly popular. As in most cases, the requirements of the cloud along with that of mulitenant applications have been the driving force of this evolution.
For example, while SSL is definitely a secure layer, many (if not most) home grown applications simply do not want to pay for a signed certificate (even less in face of the fact that such a certificate is mostly restricted to a single domain) and, thus, simply do not use SSL. Of course, this is worst, but still common practice.
Also, basic authentification is, presumingly with respect to its simplicity, still widespread. However, basic authentification in combination with a non-secure transport layer is a security black hole.
And finally, with SaaS rising, comfortable single sign-on in a multitenant environment must be considered in modern software design. Latter issue, cloud based single sign-on, is supported by the Spring Security (see ref. manual).
There are some more requirements emerging from the evolving cloud: for example, RESTful web services as part of asynchronous data transfer need to be secured on user level. While such scenarios can definitely be realized with the Spring Security, it definitely focuses on securing classic synchronous data transfer and flows (for instance, I would rather not choose Spring Web Flow to implement the flow of an highly AJAXian web application). In order to implement flows based on highly asynchronous communication between the client and server, there is definitely some hacking to do (see e.g. this tutorial).
However, the most important issue in times of millions of home grown smartphone apps is sharing credentials with such a client. Using same password over and over again, because you cannot remember millions of different passwords? Of course, this is worst, but still common practice. Now, what if your credentials are misused by your app? Wouldn’t it be much better, if you would not share your credentials with the client at all?
OAuth is an open protocol to allow secure API authorization in a simple and standard method from desktop and web applications. It has been developed with most of the issues that emerged from cloud-based authentification and authorizastion in mind. Furthermore, it is being used by global players like Digg, Jaiku, Flickr, Twitter, and developers of OAuth are hopeful to see Google, Yahoo, and others soon to follow. With so many heavy weight service providers relying on OAuth, it may definitely be considered as quasi standard. Unfortunately, Spring Security is not (yet) shipped with out-of-the-box support of OAuth, although I am pretty sure that the extremely capable Springsource team will deliver Spring with OAuth support as soon as possible.
For those who cannot (and should not) wait, a promising approach is described in OAuth for Spring Security. The purpose of this project is to provide an OAuth implementation for Spring Security. I have tested their implementation, and hereby I strongly recommend their approach. For me, the most striking advantage of this design is the combined power of both, OAuth and Spring Security. While you still have the comfort of Spring and its AOP framework, you have implemented the security of OAuth.