anchor.diff:  
   So all we need to do is teach the client to send credentials with every request.
   
  -== Token Authentication
  +//== Token Authentication
  +== トークン認証
   
   The internet, and people's Spring backend projects, are littered with custom token-based authentication solutions. Spring Security provides a barebones `Filter` implementation to get you started on your own (see for example https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/authentication/preauth/AbstractPreAuthenticatedProcessingFilter.java[`AbstractPreAuthenticatedProcessingFilter`] and https://github.com/spring-projects/spring-security/blob/master/core/src/main/java/org/springframework/security/core/token/TokenService.java[`TokenService`]). There is no canonical implementation in Spring Security though, and one of the reasons why is probably that there's an easier way.
   
   Remember from <<_the_login_page_angular_js_and_spring_security_part_ii,Part II>> of this series that Spring Security uses the `HttpSession` to store authentication data by default. It doesn't interact directly with the session though: there's an abstraction layer (https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/context/SecurityContextRepository.java[`SecurityContextRepository`]) in between that you can use to change the storage backend. If we can point that repository, in our resource server, to a store with an authentication verified by our UI, then we have a way to share authentication between the two servers. The UI server already has such a store (the `HttpSession`), so if we can distribute that store and open it up to the resource server, we have most of a solution.
   
  +//=== Spring Session
   === Spring Session
   
   That part of the solution is pretty easy with https://github.com/spring-projects/spring-session/[Spring Session]. All we need is a shared data store (Redis is supported out of the box), and a few lines of configuration in the servers to set up a `Filter`.
  
positive.code: [[_the_resource_server_angular_js_and_spring_security_part_iii]]
  = The Resource Server
  
  In this section we continue <<_the_login_page_angular_js_and_spring_security_part_ii,our discussion>> of how to use http://projects.spring.io/spring-security[Spring Security] with http://angularjs.org[Angular JS] in a "single page application". Here we start by breaking out the "greeting" resource that we are using as the dynamic content in our application into a separate server, first as an unprotected resource, and then protected by an opaque token. This is the third in a series of sections, and you can catch up on the basic building blocks of the application or build it from scratch by reading the <<_spring_and_angular_js_a_secure_single_page_application,first section>>, or you can just go straight to the source code in Github, which is in two parts: one where the https://github.com/dsyer/spring-security-angular/tree/master/vanilla[resource is unprotected], and one where it is https://github.com/dsyer/spring-security-angular/tree/master/spring-session[protected by a token].
  
  
negative.code: Reminder: if you are working through this section with the sample application, be sure to clear your browser cache of cookies and HTTP Basic credentials. In Chrome the best way to do that for a single server is to open a new incognito window.
  ____
  
  //== A Separate Resource Server
  == 分割されたリソースサーバ
  
  //=== Client Side Changes
  === クライアント側の変更
  
  On the client side there isn't very much to do to move the resource to a different backend. Here's the "home" controller in the https://github.com/dsyer/spring-security-angular/blob/master/single/src/main/resources/static/js/hello.js[last section]:
  
  