RESTful authentication using Spring Security on Spring Boot, and jQuery as a web client

In a previous article, I started touching on some very basic Spring Security-based authentication on top of Spring Boot. That should have given you something to start with… as long as you stuck with Spring MVC, that is.

Indeed, Spring Security gives you all of the tools almost out-of-the-box when securing against Java Server Pages: redirection to the login page, redirection to the right controller after user has authenticated, JSP taglibs, etc.

The fact is, there are a lot of modern web applications that rely on accessing back-end web services while implementing a rich and responsive user experience on the front-end, such as AngularJS-based web applications. And things can get a little trickier when authentication is done using web services: no redirection after login, the returned HTTP status codes are not necessarily the right ones… the web services’ client inherits a lot of responsibilities that were previously handled by the back-end.

In this post, I will do my best to describe one possible solution to implement RESTful authentication on the back-end, accessed a jQuery-based web client on the front-end. I will examine both the back-end and front-end, so that by the end of this tutorial you will hopefully have a starting point for implementing your own solution.

The full code discussed here below is available at for your convenience.

But first, the basics of securing Spring-based REST

Let’s start with a few links and resources I found useful to understand the topic.

To begin with, the Spring Framework has a very convenient way to turn controllers into REST-enabled controllers. Since Spring 4 it’s even easier thanks to the @RestController annotation. Feel free to browse their excellent reference manual.

I haven’t found that much information about securing RESTful services in Spring Security’s reference manual. Instead, I have found a great deal on the topic at Baeldung. He has a full section about REST services with Spring, including securing those services. Check this and this for instance. In fact, <biased advice warning> do yourself a favor and subscribe to his newsletter. I can’t count how many times I dug up one of his articles when I was stuck. </biased advice warning>

Okay, let’s set it up!

So let’s get out hands dirty. We start by configuring a Maven project. We will rely on Spring Boot to provide us with a default, working configuration which we can then bend according to our needs.

<project xmlns="" xmlns:xsi=""

  <name>Rest Authentication</name>



As you guessed, we’ll run the application in an embedded Jetty. Note how easy it is to include Spring Security:ย  just add that spring-boot-starter-security starter POM, and off you go!

Spring Boot recommends using Java to configure the application. You can of course use XML files instead, but I like the idea of configuring an application with Java: I find it kind of intuitive.

package codesandnotes.restsecurity;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;

public class Application {

  public WebSecurityConfigurerAdapter webSecurityConfigurerAdapter() {
    return new ApplicationSecurity();

  public static void main(String[] args) {
    SpringApplication application = new SpringApplication(Application.class);;

The class acts as the main entry point for our Spring Boot-based application. You can of course define whatever bean is needed for your application here, but the one that we will focus on is our custom implementation of the WebSecurityConfigurerAdapter, which will allow us to configure Spring Security.

Configuring the back-end security

Here’s what a the implementation of theย WebSecurityConfigurerAdapter might look like:

package codesandnotes.restsecurity;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.annotation.Order;

import codesandnotes.restsecurity.RESTAuthenticationEntryPoint;
import codesandnotes.restsecurity.RESTAuthenticationFailureHandler;
import codesandnotes.restsecurity.RESTAuthenticationSuccessHandler;

public class ApplicationSecurity extends WebSecurityConfigurerAdapter {

  private RESTAuthenticationEntryPoint authenticationEntryPoint;
  private RESTAuthenticationFailureHandler authenticationFailureHandler;
  private RESTAuthenticationSuccessHandler authenticationSuccessHandler;

  protected void configure(AuthenticationManagerBuilder builder) throws Exception {

  protected void configure(HttpSecurity http) throws Exception {

We first configure the authentication aspects by overriding the configure(AuthenticationManagerBuilder builder) method. For our tutorial we set up a simple in-memory authentication context like we did in this post, so we can log in using some test user profiles.

The interesting part comes as we override theย configure(HttpSecurity http) method in order to customize our security handling.

  • The 1st statement tells Spring Security that we will intercept all requests matching the specified Ant matcher and make sure that they come from an authenticated user. Any request starting with “/rest/” in the URL will only be accessible to authenticated users. Easy.
  • The 2nd statement disables CSRF (Cross Site Request Forgery). This is understandably enabled by default by Spring Security, but we’ll disable it for simplicity sakes (and because I haven’t had time to figure out how to implement this in a REST context, sorry!). It’s an important aspect of REST security so, by all means, read about it here and here. Also check the solution kindly provided by Allan Ditzel here!
  • The 3rd statement tells Spring Security what happens when an unauthenticated client tries to access a restricted resource. In an MVC application we would be redirected to a login page… But remember: this is a web service! The service should return a 401 HTTP status code and let the client direct its users to some login page. A custom authentication entry point is used to implement that behavior (see below for an implementation example).
  • The 4th statement indicates that we will request the client to submit a user’s login credentials as a form. How convenient, my web client is great at submitting forms! Of course you can also chose to implement Basic HTTP Authentication or Digest Authentication (have a peek here for more information on this). We also specify our custom authentication success handler in case the user successfully authenticates (more on this below).
  • Finally, the 5th and last statement allows to specify a custom authentication failure handler.

Fine, you say, but what’s inside those custom entry point and handlers classes? Why do we need to override them?

Let’s examine each custom class one by one…

The custom authentication entry point

By implementing our own authentication entry point, we can tell Spring Security exactly what to do if someone tries to access a protected resource without being authenticated. But we are dealing with web services here, so what we actually want our system to do is: “if the client accesses a resource but is not authenticated, we respond with a 401 Unauthorized status“.

package codesandnotes.restsecurity;


import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.stereotype.Component;

public class RESTAuthenticationEntryPoint implements AuthenticationEntryPoint {
  public void commence(HttpServletRequest request, HttpServletResponse response, AuthenticationException authException)
      throws IOException, ServletException {

The above code simply responds with a 401 Unauthorized status code as soon as there’s an authentication problem.

The custom authentication success handler

So let’s say that the client responds by sending some login credentials, and that those credentials are valid: Spring Security then invokes our specified authentication success handler. This is where Spring Security would clear the authentication attributes, apply some redirection strategy to a defined target URL and even retrieve a cached request to submit it (so that after a successful login the system re-submits the request that triggered the redirection to an authentication page; in other words, it allows resuming the flow that was interrupted by a login request).

But, once again, we’re dealing with web services here so we only want the server to respond with a 200 HTTP status that the login was successful. The client will be responsible on what to do next. So here we go then:

package codesandnotes.restsecurity;


import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.stereotype.Component;

public class RESTAuthenticationSuccessHandler extends SimpleUrlAuthenticationSuccessHandler {

  public void onAuthenticationSuccess(HttpServletRequest request, HttpServletResponse response,
      Authentication authentication) throws IOException, ServletException {


There’s nothing more to it, really. We make sure we clean up any authentication attributes left in the HttpServletRequest instance, and by default the method will trigger a 200 status instead of a 301 normally sent by a Spring Security form login.

Okay then, one more handler to go.

The custom authentication failure handler

This is an example of a custom authentication failure handler:

public class RESTAuthenticationFailureHandler extends SimpleUrlAuthenticationFailureHandler {

  public void onAuthenticationFailure(HttpServletRequest request, HttpServletResponse response,
      AuthenticationException exception) throws IOException, ServletException {
    super.onAuthenticationFailure(request, response, exception);

As you can see, there’s not much customization going on: everything is delegated to SimpleUrlAuthenticationFailureHandler. If you don’t need to customize the failure behavior (such as logging the failure or triggering a special action), you can in fact directly use a SimpleUrlAuthenticationFailureHandler instance in your ApplicationSecurity class. Easy!

The REST web service

We need a simple web service that will allow us to test our security setup. Since I’m writing this part of the article on the night of Halloween, I propose you a “HelloweenWebService“. That will change us from the usual “HelloWorld” stuff ๐Ÿ˜‰

package codesandnotes.restsecurity;

import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestMethod;
import org.springframework.web.bind.annotation.RestController;


public class HelloweenWebService {

  @RequestMapping(value = "/hello", method = RequestMethod.GET, produces = MediaType.APPLICATION_JSON_VALUE)
  public ResponseEntity<HelloweenResponse> hello(Principal principal) {

    return new ResponseEntity<HelloweenResponse>(
        new HelloweenResponse("Happy Halloween, " + principal.getName() + "!"), HttpStatus.OK);

  public static class HelloweenResponse {
    private String message;
    public HelloweenResponse(String message) {
      this.message = message;
    public String getMessage() {
      return message;
    public void setMessage(String message) {
      this.message = message;

Nothing exceptional here: the services class is annotated with @RestController, which is a useful Spring 4 shortcut for annotating the class with @Controller and @ResponseBody. We map our hello() method to the “/rest/hello” path and we send a HelloweenResponse as a response entity, which will be automatically converted to JSON courtesy of Jackson and Spring’s HttpMessageConverter.

The important thing to note here is the “/rest” bit in the path: remember we told Spring Security that everything under “/rest/**” is only accessible to authenticated users. This means that if a user tries to access this service without being authenticated, Spring Security will fire our custom authentication entry point and therefore return a 401. Good, that’s exactly the behavior we need!

Also note that we are able to access a Principal instance, automatically filled by Spring Security for authenticated users. Cool!

Okay, let’s move on to the web client now…

The web client

The tricky thing with the web client is that it’ll have much more responsibilities that what we were used to. Mainly, the web client must:

  • detect the 401 response and redirect to a login page
  • submit the login credentials to Spring Security and handle Spring Security’s response
  • redirect the user once he has successfully logged in

So let’s get started!

The secured main page

This simple HTML page and its associated JavaScript code displays a “hello” message that embeds the logged user’s username. This means of course that the user must be logged for this to work, which is exactly what the JavaScript code will make sure of:

<!DOCTYPE html>
<head lang="en">
  <meta charset="UTF-8">
  <title>Halloween Application</title>

  <script src="lib/jquery.min.js"></script>
  <script src="lib/jquery.cookie.js"></script>
  <script src="index.js"></script>
  Here's what our Helloween service is saying to you:
  <div id="helloweenMessage"></div>
jQuery(document).ready(function($) {
    type: 'GET',
    url: '/rest/hello'

  }).done(function (data, textStatus, jqXHR) {

  }).fail(function (jqXHR, textStatus, errorThrown) {
    if (jqXHR.status === 401) { // HTTP Status 401: Unauthorized
      var preLoginInfo = JSON.stringify({method: 'GET', url: '/'});
      $.cookie('restsecurity.pre.login.request', preLoginInfo);
      window.location = '/login.html';

    } else {
      alert('Houston, we have a problem...');

The main page’s JavaScript uses jQuery’s ajax() method to send a GET request to our “/rest/hello” service and uses the service’s returned information to display the resulting message inside the #helloweenMessage div tags.

Of course the first time this code runs Spring Security will send back a 401 response. That’s because we protected that resource from unauthorized access. So the fail() method must handle this case and redirect the user to the login.html page.

But even before we redirect the user, we are going to store the details of the request that provoked the login into a cookie. Why? Because we can then use those details to continue where we left of before being asked to log in. In other words, after the client is successfully logged, we can redirect him to this page (or any other page we store in the cookie).

So how do we implement the login page then?

The login page
<!DOCTYPE html>
<head lang="en">
  <meta charset="UTF-8">
  <title>Login Page</title>

  <script src="lib/jquery.min.js"></script>
  <script src="lib/jquery.cookie.js"></script>
  <script src="login.js"></script>
<form id="loginform" name="loginform">
  <label for="username">Username: </label><input id="username" name="username"><br/>
  <label for="password">Password:</label><input id="password" name="password"><br/>
  <button type="submit">Login!</button>

The login page is a simple form, really. Remember, we are implementing form-based authentication!

However note that instead of specifying an action attribute inside the form tag, we will handle the submission process with our own JavaScript code. This will allow us to control the flow depending on the login service’s response: 200 if the user successfully logged in or 401 if he provided the wrong credentials, according to our implemented custom authentication success or failure handlers.

jQuery(document).ready(function ($) {
  $('#loginform').submit(function (event) {
    var data = 'username=' + $('#username').val() + '&password=' + $('#password').val();
      data: data,
      timeout: 1000,
      type: 'POST',
      url: '/login'

    }).done(function(data, textStatus, jqXHR) {
      var preLoginInfo = JSON.parse($.cookie('dashboard.pre.login.request'));
      window.location = preLoginInfo.url;

    }).fail(function(jqXHR, textStatus, errorThrown) {
      alert('Booh! Wrong credentials, try again!');

By default Spring Security exposes a “/login” service which accepts form data to submit credentials. The form parameters must be named “username” and “password” for this to work out-of-the box. Don’t worry, Spring Security allows you to specify different parameter names if you need to.

If the user successfully logs in, we retrieve the pre-login request from the cookie and redirect the user accordingly. Neat, isn’t it? Of course the redirection logic could be improved, for example to handle situations where the user was posting a form: we could store the form and post URL into the cookie and re-submit the form at successful login, before we redirect the user to the next page.

Running our application

So go ahead, start the application by running’s main() method.

Head to “http://localhost:8080“: you’ll see that you are automatically redirected to the login page. So far so good!

Now type some valid credentials, such as “user/user” or “admin/admin“: you should be redirected to the main “index.html” page, with your username inserted in the “Happy Halloween” message. Great!!!

Now reload the page: you are still logged in, so your Halloween message is still displayed to you and you are not required to log in again. Which is what we need, really. Unless you want to force your user to login at each request, of course, but then be ready to run for your life…


How come our application remembers that we’re logged in?

Not quite session-less…

Well, when Spring Security took in the valid credentials, it sent back a cookie that holds a JSESSIONID parameter. The cookie got automatically stored by the browser, which sends it back at every request.

A session is effectively established between our web application and our server, allowing Spring Security to know if the client sending the request is already authenticated or not.

Whether this behavior is acceptable or not depends on what you need.

From here, the world’s your oyster…

This was a very simple proposal on how to implement REST-based authentication for rich, web applications, using Spring Security on the back-end. The example is simplistic of course, but you should be able to build your way from here.

The important points to remember are:

  • For REST-based authentication, some of Spring Security’s behavior and responses must be adapted. This is quite easily done by implementing our own entry points and authentication handlers.
  • The client is responsible of handling the flow, depending on the HTTP responses it gets. We leverage jQuery’s ajax() function for that purpose: it allows is to easily provide the logic for successful and failed authentication.
  • The client is also responsible for redirecting the user after a successful login.

So are we safe then?

…but there’s room for improvement!

This authentication setup (form-based) works fine when clients are web applications. But what about other, non web-based systems? They probably won’t know what to do of a session cookie! So for non-web clients we might need to add Basic HTTP authentication or Digest authentication.

Furthermore, there’s possibly a lot of security aspects to be enforced.This setup would work good for an enterprise application, where clients access the services within an intranet.

For a publicly-available service, there’s still some work to do: use HTTPS for a start, implement CSRF security, etc. A good start would be to have a look at OWASP’s REST Security Cheat Sheet and browse through all topics of that page. They’re professionals: they know what they’re talking about!

Maybe I’ll post another security article in a forthcoming future, where I would try to cover these security aspects… But for the moment we’ll stop here: this tutorial is long enough as it is!

So I hope this post got you started on RESTful authentication. Should you find a bug in the code or if you just want to propose a better way of implementing this, please feel free to drop me a line!



BTW: the full code is available here for you to download. Go ahead and feel free to improve it if you want to!

BTW-2: Helloween. Yes, I used to listen to that ๐Ÿ˜‰


Updated (Nov. 3rd): Allan Ditzel has provided a very neat solution to expose the CSRF tokens generated by Spring Security in the response’s header (see comments below). This way the web client is able to include the CSRF token in, for example, the header of the response sent back to the server. I have updated the tutorial’s code consequently. Kudos to Allan for coming up with that one!



  1. Allan Ditzel Reply
    03/11/2014 at 16:20

    You use a filter to expose the CSRF tokens on responses that your javascript client could then use. Here’s an example of how to do something like that.

    • codesandnotes Reply
      03/11/2014 at 18:09

      Thank you Allan, this looks perfect indeed! As soon as I can find me 15 spare minutes I’ll add it to the tutorial’s code on GitHub. Tnx a lot!

  2. Harold Reply
    23/01/2015 at 14:56

    Why not include logout?

    • codesandnotes Reply
      25/01/2015 at 13:51

      Hi Harold,
      Indeed, I’ve stopped short of the “logout” process for this post. Not really sure why… So here’s the deal: I’m incredibly busy these days, but give me a week and I’ll find some time to write a follow-up post for the logout process AND update the Git code accordingly.
      Stay tuned, and thanks for pointing that out!

    • codesandnotes Reply
      05/02/2015 at 12:23

      UPDATE – The tutorial code now includes a logout implementation… and CSRF protection handling. Cheers!

      • Abhishek Reply
        09/02/2015 at 11:08

        Thanks a lot for the great tutorial.
        However, I am not able to start up the application, may be the spring configuration files etc. are missing?

        • codesandnotes Reply
          09/02/2015 at 12:40

          Hello Abhishek,

          I’ve tried deleting and checking out the project using SourceTree, then I opened the project in IntelliJ (make sure the external libraries are downloaded: in IntelliJ you can use the Maven Projects tab…).

          I’ve then right-clicked on codesandnotes.restsecurity.Application and requested IntelliJ to run it as a simple Java application. The application started without problems. From there I was able to access is by going to http://localhost:8080 (use “user/user” as the username/password.

          Feel free to post more details to see if I can guess where the issue lies (full error message, IDE you use, etc).


  3. […] my previous article regarding REST security, I have decided to further push my exploration of CSRF implementation in the case of web clients […]

  4. Matt Reply
    04/03/2015 at 00:09

    This code doesn’t work for me in the slightest and I’ve copied and pasted all of it. Every request gets a 401 response even when i send the user and password.

    I’m using curl to test the service and sending this:

    localhost:8080/rest/hello -u user:user

    • codesandnotes Reply
      04/03/2015 at 09:04

      Hello Matt,

      It’s hard for me to understand the issue without seeing the code as a whole… I have not tested my code using curl requests. Remember though that the authentication must be done by Spring Security too, because it’ll keep track of your authentication success. This means that a POST has to be sent to the right URL (/login) with the username and passwords in the body for Spring to authenticate you.

      But before you try all the above, you might want to download the full code at . I know that code works for having made the whole process from the GitHub checkout up to making it the whole thing run. It as also been tested by a colleague of mine, so I’m pretty sure about it.

      Maybe you can start from that code base and adapt it step by step to obtain what you need?

      Spring Security and security in general are very touchy: change one line of code and all hell breaks lose. So my advice is don’t give up, start with the code on GitHub and let me know if there’s anything else I can help you with.


    • Tarmo Kalling Reply
      28/09/2015 at 18:01

      This usually means that for whatever reason your webSecurityConfigurerAdapter bean is not registered. This kind of problem might come up if you try to refactor the webSecurityConfigurerAdapter bean out from the Spring boot main runner class for example and forget to register the new class as a Component. This is what actually happened to me but if I added the Component annotation to the new class, it started working. And it also works with cURL (tested it myself).

  5. Neuro fuse Reply
    21/07/2015 at 02:41

    Awesome! Its truly amazing post, I have got much clear idea concerning from this post.

  6. Sridhar Reply
    21/08/2015 at 11:46

    I have used the same approach mentioned here. I have Angular js client code running on node js and Spring boot application with the security component mentioned in this article. The authentication was success full from a login page and I see a log, but its session id is null inPrincipal:
    Authentication success. Updating SecurityContextHolder to contain: Principal: Username: user; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: ROLE_USER; Credentials: [PROTECTED]; Authenticated: true; Details: RemoteIpAddress:; SessionId: null; Granted Authorities: ROLE_USER

    The subsequent requests are getting 401, as some how session is not maintained also the JsessionId cookie was not appearing in the request headers of these subsequent requests. What could be he issue. Thanks

    • codesandnotes Reply
      21/08/2015 at 19:10

      Hello Sridhar,
      I’m not sure what you mean by running AngularJS client code on nodeJS… Isn’t Node supposed to run JS for backend?
      Anyways, if the session is not maintained it is because the JSESSIONID is missing in your subsequent requests. When running a client in a browser, the browser automatically gets the cookie with the JSESSIONID, stores it and sends it back at each request. This won’t happen if cookies are disabled in the browser, or if your code is not really running in a browser…

  7. Peter Reply
    02/10/2015 at 00:48

    Great tutorial… works excellent.
    I am dealing with cookie “helloween”. Where is that name set, and how can I change it?

    • codesandnotes Reply
      02/10/2015 at 20:33

      Hi Peter, the name of the cookie is hard-coded in src/main/webapp/utils.js.

  8. Marc Collin Reply
    05/10/2015 at 20:56

    strangely when i load your apps, i see a web page who display

    Here’s what our Helloween service is saying to you:

    In the console debug mode, i see

    GET http://localhost:8084/rest/hello 404 (Not Found)

    >>>>> When GET /rest/hello fails jqXHR X-CSRF-TOKEN = null
    utils.js:8 >>>>> When GET /rest/hello fails no JSESSIONID cookie was found
    utils.js:16 >>>>> When GET /rest/hello fails no restsecurity cookie was found

    I click on Post something…

    and that fail because

    cookie is null… so can’t read csrf property

    • codesandnotes Reply
      05/10/2015 at 21:38

      Hi Marc,
      Say, why is the URL pointing to port 8084? Are you running the application on a Tomcat by any chance?
      The example code is based around Spring Boot. The idea of Spring Boot is that it provides us with a default, ready-to-use environment so we don’t have to take a bunch of details into account. So to run the code, one is meant to run the Application.class main() method: this will start an embedded Jetty server on 8080, load the Spring environment along with some default settings and expose the web application (still on 8080). You will have a server running the Spring web services and the web application on the same port.
      Try to run the app using that Application.class (just create a “standard” Java run configuration in your IDE): I’m quite sure it will solve your problem.
      If not, drop me a line ๐Ÿ˜‰

      • Marc Collin Reply
        06/10/2015 at 19:50

        i took the project and run it with netbeans.

        spring boot load automaticlay tomcat

        • codesandnotes Reply
          07/10/2015 at 09:36

          Hi Marc,
          This is the strangest thing. Looking at the pom.xml you can see that we enforce Jetty:


          And at startup my console displays:
          2015-10-07 09:16:35.899 INFO 7940 — [ main] .s.b.c.e.j.JettyEmbeddedServletContainer : Jetty started on port: 8080
          2015-10-07 09:16:35.901 INFO 7940 — [ main] codesandnotes.restsecurity.Application : Started Application in 3.476 seconds (JVM running for 4.245)

          I DID notice however that spring-boot-starter-web is adding a dependency to three Tomcat libraries…
          So I’ve updated the pom to exclude them from the web starter, just in case:


          I’m not sure those extra dependencies are the culprit. Maybe NetBeans insisted on giving priority to Tomcat?
          Check out the latest revisions from GitHub and try again: make sure tomcat is not listed as a dependency anymore. If NetBeans insists on running it with Tomcat, then it means NetBeans is not executing Application.class but rather running the project inside its own Tomcat.

          • Marc Collin
            09/10/2015 at 20:39

            ah now that work

  9. Marc Collin Reply
    09/10/2015 at 20:40

    is there a way to know if we are connected?

    is ask for this use case:

    a user connect to the site, go to multiple page, return to login without logout. maybe could be a good idea to don’t allow the user to go to login page.

  10. Priyadarshini B Reply
    26/10/2015 at 20:22


    First of all, thank you for the well explained and excellent article on implementing spring security at the backend in the restful web service. There are lot of websites that has either very outdated code or complex to understand. I am a fan of bloggers who keep it simple and also writes to serve the purpose of the topic. I am a blogger myself writing on spring security with spring boot. I wanted to first of all, learn and implement the same approach what you have explained here.

    I have one question though, hope you would not mind to share with me your thoughts on this. This whole approach will work for a public facing application, with the client just using html and javascript (say a mobile app) and everything including authentication is wrapped up in the rest service. My only concern here is, if I go about using this solution, I am sending user credentials in javascript to be verified by the rest service, which I feel is more vulnerable to attacks. I am not a security expert and I don’t even know what type of attack it is or if it is truly a vulnerable one. So can you please share some insights on this? If in case, this is not a good way to send credentials to the rest service, then what would be the best way to send user credentials to rest service using javascript, some kind of encrypting or hashing instead of passing plain username and password?


    • codesandnotes Reply
      27/10/2015 at 09:13

      Hello Priya,

      It’s actually a very important point you’re making! I believe the attack you are describing is a MITM (man in the middle) attack: “an attack where the attacker secretly relays and possibly alters the communication between two parties who believe they are directly communicating with each other” (from Wikipedia).

      Sending credentials in JavaScript (or any other means!) comes with risks which one can mitigate by adding layers of security: you can always imagine someone intercepting your data, but we can make it very hard for him/her to do so. But then we have to go further than a simple REST authentication.

      We know we have to send something to the REST service, either credentials to open a session or access tokens if we use OAuth. In any case, there’s an exchange of data!
      So can we encrypt that data? We could use an AES key (symmetrical. Shared between the client and the server): the key is both known by the client and the REST service and is used to encrypt data. That helps preventing MITM attacks… as long as the attacker does not go and find the key in the JavaScript code! Shall we try to avoid writing the key in the JavaScript code? Okay, let’s make a service that sends back a unique AES for that client, which the client can use to encrypt the credentials… Okay but then we need to send its username. Oh and the attacker still could read the AES key that is sent back!
      Let’s move to RSA keys then, which are at the core of PGP! The client uses the REST service’s public key to encrypt the data, and the REST service uses the client public key to reply. It’s slower, but it could work right? Well… the client needs to know the REST service’s public key for that. So we must make sure that the server’s public key obtained by the client is the genuine one, not a fake one that the attacker is serving you… That’s the SSL certification system! Okay but what if the attacker is injecting JS code to steal your credentials? It’s not a MITM attack anymore, it’s actually easier than that…

      Okay, so my point is: the web is hard in terms of protection! The fact that the code of your client application is actually served through the net means that your client application itself can be compromised at any point! We must apply a stack of techniques to prevent an array of attacks. But cheer up, security passionates have found this series of techniques which, combined together, provide a fairly safe set of protection layers!

      First, you could definitely implement CORS (Cross Origin Resources Sharing). This technique basically ensures that the requests received by the server come from the right place: “okay, the request comes from, so it should be fine”.
      Second, you can implement CSRF tokens. These tokens are exchanged between the server and the client to ensure that requests are coming from the right client (and not from an attacker). It’s quite tricky to explain in a few lines, but I’ve blogged about this (start here).
      Third, you can actually protect your login page so that, thanks to CSRF tokens, you make sure it’s the client, not the attacker, that’s trying to login (see
      Finally, there’s SSL certificates. Ideally everything you send through the Internet (credentials included) would be better off on HTTPS.

      This setup should already give you a pretty good protection stack. Unless you’re victim of a the Poodle attack (how cute!). See, one security approach in itself is not safe enough, but once they are combined they do a pretty good job.

      Feel free to read my series of posts explaining CORS and CSRF (). The code is available on GitHub, and it adds these layers of security to a real client-server structure.
      Adding SSL certificates on top should keep you on the safe side. If not, it probably means you’ve become bigger than Facebook or Google ๐Ÿ˜‰

  11. Priyadarshini B Reply
    28/10/2015 at 18:11

    Thank you very much for the detailed reply. I have already implemented csrf in spring security (nothing pretty much to implement, spring does everything and we just need to enable it) and now I am going to look at CORS now. As far as passing credentials in javascript is concerned, what I understand from your reply is “it can be considered safe with SSL certificate”. All these combined, reduce potential risks of our application being compromised.

    I am going to write a detailed article on this, with all the knowledge I gathered here and elsewhere on the web. Thank you once again ๐Ÿ™‚

  12. Vijay Reply
    01/12/2017 at 11:08

    As said “By default Spring Security exposes a โ€œ/loginโ€ service which accepts form data to submit credentials. “.

    In the sample code after login it is invoking “/hello” service. where is the code written to invoke “/hello” service after login.

    I want to do same with my application.
    In my project we are coding UI and Backend as a separate modules UI is using the services exposed by backend Spring boot application.
    So after successful login I want to show home page with some data. How can I achieve this?

    Please help

  13. codesandnotes Reply
    02/12/2017 at 10:59

    Hello Vijay!

    After the login the JavaScript code redirects the user to the window location “/” that was retrieved by the cookie.
    This in turns reloads the index.html page and its accompanying index.js script file.
    As soon as the page is done loading, the “/rest/hello” AJAX call is re-executed so that the right info is displayed in that


    For your application, you could take the same approach: the home page executes a script with the REST call, but it initially fails because the user is not logged. He is redirected to your login page, where he authenticates successfully. That in turn reloads your home page, except that this time the session cookie is there, so that REST call succeeds and the data is displayed as expected.

    Hope this helped!

  14. amit Reply
    07/02/2018 at 23:40

    Hi Diego,
    Thanks for the nice article. I am trying to implement something which is close to this. HTML + jQuery + Spring Boot + LDAP authenication. Do you have any sample project for that?


  15. Remzi Zayid Reply
    28/05/2018 at 10:12

    Thank you for the tutorial, this is exactly what I was looking for!

    Quick question though – how does Spring Boot know where to look for the index.html which runs on localhost:8080 ? Is there a configuration file that controls that? If so, how can I modify it?

    • Diego Reply
      28/05/2018 at 17:48

      Hello Remzy,

      Thanks for your cheers: hearing that my posts are helping other always makes me happy ๐Ÿ˜‰

      Regarding your question, yes, Spring Boot redirects to index.html by default, as explained here:

      To override the default, you can add your own WebMvcConfigurerAdapter bean in

      public WebMvcConfigurerAdapter webMvcConfigurerAdapter() {
      return new ApplicationMVC();

      The implementation may look like this:

      public class ApplicationMVC extends WebMvcConfigurerAdapter {
      public void addViewControllers(ViewControllerRegistry registry) {

      If you are using later versions of Spring Boot, I think you can even specify the index page in the, though I’ve never tried that myself:


      • Remzi Zayid Reply
        29/05/2018 at 16:53

        That makes perfect sense, thanks a ton Diego!

  16. Tatiana Reply
    17/07/2018 at 23:18

    This is really nice, thank you!

    • Diego Reply
      18/07/2018 at 08:51

      You’re welcome!

  17. aaahmad Reply
    19/08/2019 at 08:59

    what if want to have a full rest authentication? i mean: user sends a {user,pass} json request (not a x-www-form-urlencoded) and we send sessionId in response as a json.

    • Diego Reply
      20/08/2019 at 18:27

      Hi there!

      It’s certainly do-able. The question has been answered on SO already:
      Essentially, it implies writing your own filter that parses a JSON message instead of a “form-encoded”. In fact, you could extend and register the UsernamePasswordAuthenticationFilter class and override the logic inside obtainUsername() and obtainPassword() methods!
      However that will still return the sessionID as a cookie… which is preferable! I mean you are probably safer keeping that ID in a cookie that is secure (sent only on https) and httpOnly (the session ID cannot be read by the browser): that mitigates external attacks.

      If you really want to send the cookie as a response (again, I’d advise against that) then the problem you’ll encounter is to retrieve that session ID after the authentication filter has done its work, in order to return it in a JSON message.
      You’ll probably have to implement another filter, to be registered at the end of the chain, that does that using RequestContextHolder.currentRequestAttributes().getSessionId() to obtain the session ID…
      Again that is very risky because you’ll expose the session ID in a plain JSON. It might be hijacked to impersonate the logged user. I really would stay clear of that…

      At this point I wonder whether you’d be better off implementing a “fully stateless” solution, as I explain here:
      That approach drops HTTP sessions completely (which effectively maintain a state on the server-side) to switch to JWTs.

      All in all, it’s a tough decision you’ll have to make. Personally I’d either choose option 1 (JSON submission, but keep the session ID in a cookie) or option 3 (go JWT) depending on your project’s context…

Leave A Comment

Please be polite. We appreciate that. Your email address will not be published and required fields are marked

This site uses Akismet to reduce spam. Learn how your comment data is processed.