在.Netcore 技术栈中，一直在使用了开源组件IdentityService4进行身份管理，其功能的强大和易用性的确很受开发者喜欢，但是最近其开源组织Duende Software 开始对其进行商业收费，不得不探索其它的解决方案。个人认为，其实在.NetCore 本身是提供一套基AspNetCore.Identity解决方案的，我们只需按照自己的架构意图进行封装，就可以满足我们各种类型的需求。
现在动起手来（Beginning Out With IdentityServer4），开发一个满足自己业务系统的Identity 服务替换IdentityServer4。开发一套基于Microsoft.AspNetCore.Identity的Identity 的框架，需要设计一下IdentityUser、IdentityRole和 用于生成JWT 的 Claim。已即对应的验证逻辑和序列化Provider。我们首先看一下Microsoft.AspNetCore.Identity 的设计架构图，如下图所示，它是一个分层次的架构，每个层次有自己的职责。基于这个架构，可以从网上下载很多的开源框架和源码。
但是，今天我们挑战的是一套自己的一套简易的，高适配的框架，因为在项目开发过程中，人员和角色很多情况下，可能已经在现有的第三方平台上都预定义了，我们的系统需要能够更快、更容易的适配这些系统。一个可持续发展的社会需要包容的秩序，软件行业也是如此，我认为一个好的软件架构设计，要有更高的包容性。所以，我们今天设计的Identity 是一个开放的架构，允许适配现有的人员和角色的框架。
所以，基于职能分离原则，认证组件只负责Token的业务逻辑处理，包括Token 的生成，验证，销毁，以及用RefreshToken进行更新accessToken等功能，而对于持续的Token的序列化工作通过订阅事件的方式由其它模块进行完成，也可以通过接口定义服务，通过注册服务的方式进行分离这块业务。
由于这部分代码比较多，我就把核心的代码和运行测试的效果贴图出来，如果有需要源码的化，可以联系我。
运行效果如下图，生成了目标的JWT格式的token和refreshtoken信息。
通过生成的Token，我们调用测试接口，我们就可以进行了认证的验证，同时，由于Token中基于声明式的策略，我们定义了Role，还可以对接口进行基于声明式Role的权限管理，如下图所示，只有包含该角色的Token才能访问该接口。实现了基于netcore 原生的认证和鉴权。后续将继续增加基于netcore 原生的OpenID的支持。
发布完后，有圈内朋友问我，针对于微服务化怎么实现，昨天想了一下，我有做了一些调整，请看下图，通过事件总线将序列化工作与组件进行脱藕，并实现针对高并发的情况进行方案的整合，实现横向扩展。通过一个API数据服务代理，提供Token数据的反向加载。
您的支持，我的动力！