- 标清
- 2.0x
- 1.5x
- 1.25x
- 1.0x
- 0.5x
Spring Boot与Kubernetes云原生微服务实践
精选留言(9)
- 2019-08-10Token被截获怎么办？
作者回复: 这个和你的钥匙被别人偷去是一个问题，没有办法绝对避免，但是可以减轻风险。一些措施，采用https保证传输层的安全，设置合理的token过期时间，提供主动吊销token的接口，复杂的还可以把token和设备id进行绑定。
4 
2019-07-31老师你好, web 和 h5 页面有什么区分吗 ? h5页面怎么理解好呢 ?作者回复: web主要指传统mvc应用，带服务器端动态生成页面的。html5和单页spa应用类似，属于js+html应用直接住在用户浏览器里头的，通过API直接调用后台获取数据的。h5应用是有些公司特定叫法，单页spa应用是更通用叫法。
4
2019-08-20老师，在我的理解中，token一般是在第三方认证中无法与第一方服务共享session才使用了token作为访问的令牌，在完全第一方的应用场景下，我觉得以针对课程中这个案例，之前的集中状态会话形式下通过redis多服务共享session也能实现单点登录，只要把基于session的登录接口和逻辑单独抽离出来作为一个单独服务部署，专门用于登录和维护session的生命周期，这样改造也能够满足你这节课所列微服务场景的需要，而案例中所说的架构师放弃了像我这样基于session继续改造的方案而特地弃用session人为造了一个和session差不多作用的token主要是出于哪方面的考虑呢？是session本身有什么局限性吗？如果是的话能否列举一个session做不了而token更适用的第一方场景呢？作者回复: 你好，微服务场景下，考虑token而不是session，主要考虑是：
1.) 微服务场景下，不仅有传统Web应用(session适合)，还有单页，无线原生，甚至其它设备等不用浏览器的场景，这些场景token更合适。
2.) oauth2/token/jwt是目前业界服务间授权认证的开放标准。
简单讲，session主要适用于传统web场景，而token可以同时适用于各种微服务场景(同时包括你讲的第一方和第三方场景)，所以，综合考虑采用统一token方式，这样不需要维护两套体系。
当然，如果你理解底层原理，session和token本质上是类似， 只是形式有变化。 2
2019-10-26波波老师的架构图是用什么工具画的，都挺漂亮的。作者回复: 我的课程架构图都是用ppt制作(windows的话用powerpoint, mac用keynote)。
架构图其实和工具关系不大，关键要心中有图+一定的抽象总结能力:) 1
2019-08-24请问这个是基于oauth2.0的协议的授权码模式吗？授权码换token的过程省略了吗？这样的流程好像没啥问题，那授权码有啥用？作者回复: 这个架构假设是企业第一方场景，也就是前端应用、认证授权服务、网关和后台服务，都是企业自己开发的，都是可信任的。
oauth2.0授权码模式，可以用于三方授权认证场景，比如某企业开发一个三方应用，通过google或者github的oauth2服务实现联合登录。当然，oauth2授权码模式，也可以用于第一方场景，不过流程会比上面的架构要复杂。 1
2019-07-31auth service是不是可以理解为网关？作者回复: auth service是一个独立的服务，不是网关，网关和auth service配合，可以实现基于网关的集中式认证鉴权。
1
2019-11-30波波老师你好，请问一下，那个token验证是放在网guan好还是放在各个微服务内部好了，网guan可以统一处理认证作者回复: 各有利弊，放在网关上统一做的话，就会耦合依赖网关(调试测试不方便)，放在每个服务自己做的话，服务端会引入复杂性。
一般业务规模小的时候，可以放在服务端做，规模大了考虑网关统一(有一定服务治理能力要求)。我在之前企业，两种都见过，都玩得还不错，没有绝对好坏，具体要根据你自己的业务上下文综合权衡。
2019-11-07波波老师，课里说的将token设置在根域下 cookie中实现SSO单点登录，这个是可以实现的，但有个问题，这种SSO的模式相当于由Auth Service统一维护登录态，如果Auth Service不可用，整个微服务架构也就不可用了，不仅不能登录认证，也不能做校验登录和鉴权，这样会不会有些风险？？
之前我们公司在不是微服务架构时使用过基于开源的CAS Server的SSO，使用的模式是，统一在CAS Server登录后，CAS Server维护登录状态，每个应用也维护登录状态，浏览器既有CAS Server给的cookie，也有应用给的cookie，这样如果不是需要单点登录到第二个系统，就暂时不用和CAS Server交互了，只需要和已登录的应用，通过这个应用给的cookie交互即可，这样即使CAS Server挂了，只是不能登录，但不会使得应用也不可用。
请问这种除了中心的Auth Service维护登录状态，每个应用也维护登录状态的方式在微服务SSO场景下可行吗？？如何实现？？
（比如V3.5架构中，可以使用网关维护登录状态，这样后端微服务不变，也不用再管登录认证这些事）展开作者回复: 下一节有方案，V3.6基于JWT的安全认证方案，这个方案是全程无状态，Auth Serivce不需要维护状态，网关也不需要维护状态。
基于JWT的安全认证方案是目前微服务架构的一种主流方案，尤其适合安全不是特别敏感场景。
2019-10-17老师，我想问一下，管理平台，和移动后端服务都使用同一个网关，那么用户鉴权怎么做？因为 管理平台和移动后端是两个不同的用户体系作者回复: 建议管理平台和移动后端服务分开用不同的网关，这样职责分离易于维护。
如果一定要在一起，也可以，因为网关只关心校验令牌，网关上可以有两套校验逻辑，一套负责校验管理后台令牌，另外一套校验移动后端服务令牌，当请求过来，该启用哪个校验逻辑，可以根据域名或者path等条件判断。