使用/uaa/
来转发基于uaa的认证请求至auth组件
来转发请求至account组件，并标记serviceId为account-service，与图一中的withClient对应。
图一为浏览器打开应用入口后，输入用户名和密码后，发出的认证请求：
认证url为/uaa/oauth/token，这是uaa模式下标准的请求获取token的url
表单中包含了字段scope(认证范围)和字段password(认证类型)
图二为图一发出认证请求的返回结果：
Access_token为有效认证token，将来被其他请求使用
图三为发出获取当前用户的信息的请求：
在请求里的Authorization的值为图二中获得的access_token
图一为Account组件在Config组件(配置中心)定义的OAuth2协议下获取token的方式，这里定义了：
clientID和clientSecret
accessTokenUrl，这里指定了auth组件的uaa获取token的url
grant-type，即认证类型，这里指定为client_credentials
scope，这里指定了server，说明是这个认证请求只适用在各微服务之间的访问。
图二为Accout组件业务代码中定义了需要使用Auth组件进行事先鉴权的方法：
[email protected]
annotation中可以指定认证范围的具体条件，这里是限定了server或者是demo账户，才有权限发起认证。
最后小结下Spring Cloud Security的特点：
基于UAA，使用OAuth2协议。不会暴露用户的敏感信息
基于认证类型和认证范围，实现细粒度的鉴权机制
非浏览器客户端下良好的操作性
Q&A
问题：Basic Auth + Central Auth DB这种方式中，每个服务有自己的鉴权DB，这块只是一个缓冲吗?如果中途通过别的方式修改了中心DB的数据，而缓冲又没过期，这个时候有什么解决方案吗?
答：不是缓冲，这里的Central Auth DB是指各个微服务共用一个数据库。
问题：微服务架构需要服务路由和服务注册么?跟esb的区别在哪里?
答：服务路由组件和服务注册组件和是相对必要的，他们保证了用户请求能发到正确的微服务中去。ESB企业服务总线是相对比较重的组件，而不是像微服务组件一样只负责单个业务。
问题:在微服务中，对于数据权限的粒度，是可以集中在在gateway中进行还是由每个微服务自己独立配置?
答：推荐由那个专门负载权限的微服务组件来配置。
问题：您好，辛苦了，请问现在有类似SAML协议，但是不基于XML，而是基于JSON或者其他简化格式的协议吗?
答：目前据我所知没有基于JSON的SAML协议。有个叫JWT(JSON web token)的协议，它是完全基于JSON的，Spring Cloud架构中也使用了JWT。
问题：对于这个架构，服务划分的粒度有没有什么好的建议?另外登录凭证保存在客户端如何解决报文被拦截的安全漏洞?
答：服务划分需要按具体业务来说，一般来说，一个业务实体作为一个微服务。使用https可以一定程度上提高安全性。
问题:spring cloud security可以解决token重放攻击么?
答：token重放攻击不是特别了解，可能是数据弱一致性导致的，建议设计尽可能短的过期时间。
问题：我们公司现在在设计DMP，从行业的状况来看，采用了微服务，但是有一点，首先对于应用本身暴露出来的服务，是和应用一起部署的，也就是并非单独的部署，那么业务组件接口暴露部署是否合理呢?
答：业务组件的接口一般可以通过统一网关来管理。也可以对业务接口像spring cloud中设置访问scope限制。
问题：所有暴露的微服务是否需要一个统一的服务管控和治理平台?
答：是的，一般有服务网关和服务发现组件来管理用户请求。
问题：微服务的gateway需要实现底层多个细粒度的API组合的场景，我们现在一部分使用异步，但是遇到了没办法全面的解藕。我想问问，对于此，使用响应式?还是异步回调式?它们的区别点会有哪些呢?