作者回复: 这个和你的钥匙被别人偷去是一个问题，没有办法绝对避免，但是可以减轻风险。一些措施，采用https保证传输层的安全，设置合理的token过期时间，提供主动吊销token的接口，复杂的还可以把token和设备id进行绑定。

作者回复: 你好，微服务场景下，考虑token而不是session，主要考虑是： 1.) 微服务场景下，不仅有传统Web应用(session适合)，还有单页，无线原生，甚至其它设备等不用浏览器的场景，这些场景token更合适。 2.) oauth2/token/jwt是目前业界服务间授权认证的开放标准。 简单讲，session主要适用于传统web场景，而token可以同时适用于各种微服务场景(同时包括你讲的第一方和第三方场景)，所以，综合考虑采用统一token方式，这样不需要维护两套体系。 当然，如果你理解底层原理，session和token本质上是类似， 只是形式有变化。

作者回复: 我的课程架构图都是用ppt制作(windows的话用powerpoint, mac用keynote)。 架构图其实和工具关系不大，关键要心中有图+一定的抽象总结能力:)

作者回复: web主要指传统mvc应用，带服务器端动态生成页面的。html5和单页spa应用类似，属于js+html应用直接住在用户浏览器里头的，通过API直接调用后台获取数据的。h5应用是有些公司特定叫法，单页spa应用是更通用叫法。

作者回复: 下一节有方案，V3.6基于JWT的安全认证方案，这个方案是全程无状态，Auth Serivce不需要维护状态，网关也不需要维护状态。 基于JWT的安全认证方案是目前微服务架构的一种主流方案，尤其适合安全不是特别敏感场景。

作者回复: token可以缓存起来(例如放redis)，让网关集中校验的话，可以非常快，每次校验可以做到小于10ms，对性能影响可控。 如果安全不敏感，也可以考虑jwt无状态校验，就不需要集中校验。

作者回复: AuthService可以做成只负责令牌颁发和校验等逻辑，不包括具体的用户身份(user identity)数据，它实际需要用户数据(或者去认证用户）的时候，可以再去调用User或者Account相关的API。 可以看一下Spring Security OAuth2，它可以内置带UserDB，也可以对接其它的User/Account API。 另外也可以看一下hydra(https://github.com/ory/hydra)这个oauth2/oidc开源产品，它只是负责oauth2/oidc相关逻辑，不负责用户和认证，但是可以对接不同的用户身份(user identity)服务。

作者回复: 这个架构假设是企业第一方场景，也就是前端应用、认证授权服务、网关和后台服务，都是企业自己开发的，都是可信任的。 oauth2.0授权码模式，可以用于三方授权认证场景，比如某企业开发一个三方应用，通过google或者github的oauth2服务实现联合登录。当然，oauth2授权码模式，也可以用于第一方场景，不过流程会比上面的架构要复杂。

作者回复: auth service是一个独立的服务，不是网关，网关和auth service配合，可以实现基于网关的集中式认证鉴权。

作者回复: 下门课程会展示一个电商中台案例，会展开鉴权模块的设计和实现，欢迎关注。