作者回复: spring-security是单块应用时代的产物，那个时候的应用形态主要就是web-mvc，安全实现主要就是靠session+cookie+后端用于存储用户和权限数据的存储，总体是一种单体和有状态安全技术。 微服务时代则完全不同，后端都是无状态服务，前端应用形态很多，有单页+无线+Web，spring-security开发设计的时候没有考虑到现在的微服务形态。微服务适合采用oauth/jwt等无状态安全认证机制，具体原理可以进一步学习本章课程。 当然如果你硬是要将spring-security用在微服务上，我想你自己搞些定制也可以工作，但是它开发之初确实不是为微服务设计的，就是为单体spring-mvc应用设计的，后来Pivotal又推出spring-security-oauth2来扩展支持微服务安全，但是也我认为也没有设计好。

作者回复: fusionauth(https://fusionauth.io/downloads)是一个auth as a service产品，它采用我课程中给出的用户角色鉴权模型，fusionauth免费但不开源，但是下载的jar里头有db schema，可以参考。

作者回复: 透明令牌和JWT令牌的区别，在35节《安全认证架构演进：微服务阶段》和38节《JWT有哪两种主要流程？》都有讲解，可以回过头去再看一下视频。简单讲，透明令牌相当于一个无意义的随机字符串，它是实际存储在AuthServer上的会话数据的一个引用标识符，后续可以通过透明令牌去集中AuthServer上查询会话数据；而JWT令牌则是自包含数据的，一般不需要到集中AuthServer上查询会话数据，可以实现无状态认证。做一个类比，透明令牌可以类比Java语言中的引用传递(pass by reference)，而JWT令牌可以类比Java语言中的值传递(pass by value)。

作者回复: 如果安全要求比较严格，也可以考虑一种混合模式，外部使用透明令牌，内部使用自包含的jwt令牌，中间通过网关访问Auth Service进行转换，这种做法Auth Service需要存透明令牌和jwt之间的映射关系。

作者回复: 回答你的一些问题： 1. staffjoy里头的Authorize授权注解是自定义的，没有直接用Spring Security的那一套。之所以这样做，是为了让大家理解背后的原理，也就是自己完全可以定制开发一套简单的安全授权机制，没有必要一定用Spring Security。当然，用Spring Security也可以实现类似功能。 2. App是应用，和Permission不是一个概念。对于一个企业，一般有很多应用(内部的或者外部的)，这些应用 需要先在安全认证系统里头注册，之后可以用于跟踪这些App的登陆访问情况。如果你了解OAuth2的话，App相当于OAuth2里头的Client概念。 3. 如果要控制到前端页面按钮的权限，可以考虑Apache Shiro安全框架，不过这类框架主要针对Web MVC应用,微服务单页应用并不适合。

作者回复: 不一样，构造jwt令牌除了包含用户名等claims，还包含过期时间(当前时间+持续有效时间)，这个每个都不一样。

作者回复: jwt有无状态好处，但是有吊销不及时的问题。有一种优化的办法是引入消息机制，如果吊销或者用户数据变更，可以通过消息传播出去，相关应用可以监听消息，及时吊销或处理用户数据变更。

作者回复: 微服务以后，一个企业一般会有很多的应用，这些应用不是每个用户都可以用的。所以在用户和应用之间增加一个关联概念userRegistration，一个用户只有注册了一个应用，他/她才能使用这个应用。可以把userRegistration理解为用户和应用之间的一个关联表。

作者回复: RBAC是一种通用的基于角色的访问控制机制，和SaaS/多租户并不直接关联。这个机制SaaS/多租户应用可以采用，其它非SaaS应用也可以采用。 Staffjoy的多租户主要由数据库表级别的逻辑隔离(以Company为单位)，加上Faraday网关+基于JWT的安全框架+WhoAmI服务这些机制共同配合实现。相关内容主要分布在第2/4/5章。

作者回复: 你好，spring-security/shiro其实是单块应用时代的安全框架，不是服务，严格讲不适合微服务安全认证场景。课程中提出的是一种认证+鉴权服务(auth & permission as a service)，专门面向微服务场景的，需要单独开发实现，可以参考auth0.com或者fusionauth.io，我本人也正在开发一个类似服务，后面会开源出来。