目前为止已经完成了完整的用户逻辑
目前的问题是，用户在登陆的时候，用户名提交的是给前端服务器的。每个前端服务器的开发人员都可能接触到前端的用户名密码。
每一个客户端应用都要去处理登陆的逻辑，一单我的登陆逻辑有变化，可能我所有的客户端应用都要去改，重新部署。一个是安全性，一个是耦合
，开发起来会比较麻烦。我们希望的场景是什么呢？
用户在需要登陆的时候，浏览器直接跳到我们的认证服务器上，完成认证这个动作是在认证服务器上来完成的。这样前端服务器(客户端应用)本身完全接触不到用户的用户名和密码，它也不会有登陆的逻辑，登陆的逻辑都是认证服务器上。那么逻辑发生变化的话 只要改认证服务器这一处就可以了。这是我们想要的一个效果。
写代码之前，先讲一些理论。
适用于App的场景，客户端应用是我可以完全信任他的，我们自己开发的app提供给用户用，用户把用户名和密码输给客户端应用，、
但是这种模式并不适合在web场景下用，因为在web下面。我去填用户名密码的时候，并不是直接填给我自己写的应用的，而是填在一个浏览器的页面上的，浏览器是我自己的客户端应用的一个代理。浏览器没法保证安全性。所以这个模式不适合在web下用。
双重认证 一是用户的身份认证，二是客户端的身份认证，
用户的身份认证：一般是让用户去填写用户名和密码‘
客户端的身份认证：客户端发请求的时候带着clientId和ClientSecret
这样没有任何的敏感信息放在浏览器里的，这样就是web环境下最安全的授权模式，
一般不会用这种模式，
客户端证书
改成Authorization code grant的模式
之前做的是用户没登陆就显示登陆页面，现在删掉，没登陆直接跳到认证服务器上。
ts的构造函数内判断下，如果没登陆就跳到认证服务器
跳过去的时候，要带着一些参数，这样认证服务器才能知道是哪个客户端应用跳过来的，处理完以后，再调回去。
第四个参数state，记录前端服务器跳走之前客户端应用的状态。可以认为是当前是哪个页面，也可以认为是SPA出了哪个路由上。
实际上就是任意一个字符串来标识当前的状态，认证完成以后，你可以根据这个状态，恢复到应用跳走之前的状态。
这里就写一个abc吧。
x现在已经不需要登录了，现在已经是在认证服务器上来完成，所以这里我们直接在login上面去修改。
需要几个参数，首先是授权码。应@RequestParam表示这个参数是一定要有的。
引入日志
我们把传回来的state打印一下
下面就是要向授权服务器发送令牌请求了
Spring cloud微服务安全实战-5-5实现授权码认证流程（1）
原文：https://www.cnblogs.com/wangjunwei/p/11962507.html