anchor.diff:  
   NOTE: As in previous sections, try to use a different browser for "/trace" so that there is no chance of authentication crossover (e.g. use Firefox if you used Chrome for testing the UI).
   
  -== The Logout Experience
  +//== The Logout Experience
  +== ログアウト体験
   
   If you click on the "logout" link you will see that the home page changes (the greeting is no longer displayed) so the user is no longer authenticated with the UI server. Click back on "login" though and you actually _don't_ need to go back through the authentication and approval cycle in the authorization server (because you haven't logged out of that). Opinions will be divided as to whether that is a desirable user experience, and it's a notoriously tricky problem (Single Sign Out: http://www.sciencedirect.com/science/article/pii/S2214212614000179[Science Direct article] and https://wiki.shibboleth.net/confluence/display/SHIB2/SLOIssues[Shibboleth docs]). The ideal user experience might not be technically feasible, and you also have to be suspicious sometimes that users really want what they say they want. "I want 'logout' to log me out" sounds simple enough, but the obvious response is, "Logged out of what? Do you want to be logged out of _all_ the systems controlled by this SSO server, or just the one that you clicked the 'logout' link in?" We don't have room to discuss this topic more broadly here but it does deserve more attention. If you are interested then there is some discussion of the principles and some (fairly unappetising) ideas about implementations in the http://openid.net/connect/[Open ID Connect] specification.
   
  -== Conclusion
  +//== Conclusion
  +== 結論
   
   This is almost the end of our shallow tour through the Spring Security and Angular JS stack. We have a nice architecture now with clear responsibilities in three separate components, UI/API Gateway, resource server and authorization server/token granter. The amount of non-business code in all layers is now minimal, and it's easy to see where to extend and improve the implementation with more business logic. The next steps will be to tidy up the UI in our authorization server, and probably add some more tests, including tests on the JavaScript client. Another interesting task is to extract all the boiler plate code and put it in a library (e.g. "spring-security-angular") containing Spring Security and Spring Session autoconfiguration and some webjars resources for the navigation controller in the Angular piece. Having read the sections in thir series, anyone who was hoping to learn the inner workings of either Angular JS or Spring Security will probably be disappointed, but if you wanted to see how they can work well together and how a little bit of configuration can go a long way, then hopefully you will have had a good experience. http://projects.spring.io/spring-cloud/[Spring Cloud] is new and these samples required snapshots when they were written, but there are release candidates available and a GA release coming soon, so check it out and send some feedback https://github.com/spring-cloud[via Github] or https://gitter.im/spring-cloud/spring-cloud[gitter.im].
   
   The <<_multiple_ui_applications_and_a_gateway_single_page_application_with_spring_and_angular_js_part_vi,next section>> in the series is about access decisions (beyond authentication) and employs multiple UI applications behind the same proxy.
   
  -== Addendum: Bootstrap UI and JWT Tokens for the Authorization Server
  +//== Addendum: Bootstrap UI and JWT Tokens for the Authorization Server
  +== 付録: Bootstrap UI と認証サーバ向け JWT トークン
   
   You will find another version of this application in the https://github.com/dsyer/spring-security-angular/tree/master/oauth2[source code in Github] which has a pretty login page and user approval page implemented similarly to the way we did the login page in <<_the_login_page_angular_js_and_spring_security_part_ii,Part II>>. It also uses http://jwt.io/[JWT] to encode the tokens, so instead of using the "/user" endpoint, the resource server can pull enough information out of the token itself to do a simple authentication. The browser client still uses it, proxied through the UI server, so that it can determine if a user is authenticated (it doesn't need to do that very often, compared to the likely number of calls to a resource server in a real application).
positive.code: 
  NOTE: the `userInfoUri` is by far not the only way of hooking a resource server up with a way to decode tokens. In fact it's sort of a lowest common denominator (and not part of the spec), but quite often available from OAuth2 providers (like Facebook, Cloud Foundry, Github), and other choices are available. For instance you can encode the user authentication in the token itself (e.g. with http://jwt.io/[JWT]), or use a shared backend store. There is also a `/token_info` endpoint in CloudFoundry, which provides more detailed information than the user info endpoint, but which requires more thorough authentication. Different options (naturally) provide different benefits and trade-offs, but a full discussion of those is outside the scope of this section.
  
  == Implementing the User Endpoint
  
  On the authorization server we can easily add that endpoint
  
  
negative.code: 
  (substitute the value of the access token that you obtain from your own authorization server to get that working yourself).
  
  //== The UI Server
  == UI サーバ
  
  The final piece of this application we need to complete is the UI server, extracting the authentication part and delegating to the authorization server. So, as with link:#changing-the-resource-server[the resource server], we first need to remove the Spring Session and Redis dependencies and replace them with Spring OAuth2.
  
  