So it's better if your ReST application contains its own authentication mechanism (or better, a pre-debugged non-container one, like maybe Spring Security). The simplest way to do that is to have a ReST call that sends userID and password as an encrypted request and receives a token (basically, a "jsessionid" from the app instead of the container). This would then be used for the duration of the conversation as an add-on to the ReST calls. The main difference is that the authentication environment wouldn't be in the webapp or the webapp server, but in whatever common backend all the webapps in the cluster shared.
Stephan van Hulst wrote:How did you get your assumptions?
using formbased authentication and using cookies to drive the security of our APIs is an option, but definitely not the best way to go. Driving authentication with cookies has wellknown issues and so we're going to move past formbased authentication really quickly and we're going to make our way towards better solutions. The next option is basic authentication and basic authentication is a very simple algorithm. It's very mature and very well supported in clients. However, of course, this simplicity is also the reason why it's not very secure and not very flexible either............
...In Basic Auth, each interaction is essentially going to resend the credentials over the wire. So this is where tokenbased solutions come in. And the first solution we're going to discuss is of course OAuth.
If I am not wrong, the Basic Authenticate and Login prompt window are two different concepts in spring security.
Stephan van Hulst wrote:Anyway, you can use HTTP Basic and let the browser handle the login prompt, or you can just create your own login form and send the credentials like you would in any other POST request.
Stephan van Hulst wrote:Do users need to provide their credentials somewhere or does your client application have a "hardcoded" secret with which it authenticates itself without the user having to do anything?