identityserver4

介绍： wagger也称为Open API，Swagger从API文档中手动完成工作，并提供一系列用于生成，可视化和维护API文档的解决方案。简单的说就是一款让你更好的书写API文档的框架。 我们为什么选择swagger，现在的网站开发结果越来越注重前后端的分离，比如以前的webFrom到现在的mvc模式都是为了这个前后端的分离。就算再如何的分离实现，也是不可避免的要进行数据交互的，那么接口的重要性就提现出来了。他成了前端和后端交互的重要途径，API文档也因此成了前端开发人员与后端开发人员的重要纽带。所有我们有一个API文档框架岂不是美哉。 Swashbuckle有三个主要组件： Swashbuckle.AspNetCore.Swagger：Swagger对象模型和中间件，将SwaggerDocument对象公开为JSON端点。 Swashbuckle.AspNetCore.SwaggerGen：一种Swagger生成器，可SwaggerDocument直接从路由，控制器和模型构建对象。它通常与Swagger端点中间件结合使用，以自动公开Swagger JSON。 Swashbuckle.AspNetCore.SwaggerUI：Swagger UI工具的嵌入式版本。它将Swagger JSON解释为构建丰富的，可定制的Web API功能描述体验。它包括用于公共方法的内置测试线束。

我们在《ASP.NET Core项目实战的课程》第一章里面给identity server4做了一个全面的介绍和示例的练习 ，这篇文章是根据大家对OIDC遇到的一些常见问题整理得出。 本文将涉及到以下几个话题： 什么是OpenId Connect (OIDC) OIDC 对oAuth进行了哪些扩展？ Identity Server4提供的OIDC认证服务（服务端） ASP.NET Core的权限体系中的OIDC认证框架（客户端） 什么是 OIDC 在了解OIDC之前，我们先看一个很常见的场景。假使我们现在有一个网站要集成微信或者新浪微博的登录，两者现在依然采用的是oAuth 2.0的协议来实现 。 关于微信和新浪微博的登录大家可以去看看它们的开发文档。 在我们的网站集成微博或者新浪微博的过程大致是分为五步： 准备工作：在微信/新浪微博开发平台注册一个应用，得到AppId和AppSecret 发起 oAauth2.0 中的 Authorization Code流程请求Code 根据Code再请求AccessToken（通常在我们应用的后端完成，用户不可见） 根据 AccessToken 访问微信/新浪微博的某一个API，来获取用户的信息 后置工作：根据用户信息来判断是否之前登录过？如果没有则创建一个用户并将这个用户作为当前用户登录（我们自己应用的登录逻辑，比如生成jwt）

首先感谢晓晨Master和EdisonChou的审稿！也感谢正在阅读的您！ 引言 通常，服务所公开的资源和 API 必须仅限受信任的特定用户和客户端访问。那进行 API 级别信任决策的第一步就是身份认证——确定用户身份是否可靠。 在微服务场景中，身份认证通常统一处理。一般有两种实现形式： 基于API 网关中心化认证 ：要求客户端必须都通过网关访问微服务。（这就要求提供一种安全机制来认证请求是来自于网关。） 基于安全令牌服务（STS）认证 ：所有的客户端先从STS获取令牌，然后请求时携带令牌完成认证。 而本节所讲的Identity microservice就是使用第二种身份认证方式。 服务简介 Identity microservice 主要用于统一的身份认证和授权，为其他服务提供支撑。 提到认证，大家最熟悉不过的当属Cookie认证了，它也是目前使用最多的认证方式。但Cookie认证也有其局限性：不支持跨域、移动端不友好等。而从当前的架构来看，需要支持移动端、Web端、微服务间的交叉认证授权，所以传统的基于Cookie的本地认证方案就行不通了。我们就需要使用远程认证的方式来提供统一的认证授权机制。 而远程认证方式当属：OAuth2.0和OpenID Connect了。借助OAuth2.0和OpenID Connect即可实现类似下图的认证体系： 而如何实现呢，借助： ASP.NET

ChuanGoing 2019-11-24 　　asp.net core系列已经来到了第五篇，通过之前的基础介绍，我们了解了 事件订阅/发布的eventbus 整个流程， 初探dapper ORM 实现，并且简单的介绍了 领域模型、领域仓储及服务 实现，结合上一篇的 日志、错误处理及事务 和本篇将要介绍的权限，大致的可以形成一个简单的后端系统架构。当然这些都是零散的一些技术概念的介绍，后面如果有时间的话，我想详细的介绍下如何利用领域驱动来实现一个实际案例。 话不多讲，下面来看下本篇的学习曲线： 1.认识Identityserver4 2.Identityserver4实现认证与授权 3.自定义权限的实现 认识Identityserver4 　　关于Identityserver4(ids4)的概念介绍，请查看 IdentityServer4 知多少-简书 一文。我这里要说的是，asp.net core 下的ids4集成了认证与授权两大功能，使得我们非常方便的实现一个开放的认证与授权平台，比如公司内部多个系统的集成登录(单点登录)/第三方系统数据共享/统一的认证中心等。整个业务流程大致为： 1.用户首先的有用户中心的账号信息，因此需要注册一个账号 2.用户访问某个站点应用，需要去到用户中心认证 3.认证通过，用户得到其在用户中心注册的相应信息及其权限时限、范围、大小 4.认证不通过

最近在折腾IdentityServer4，为了简单，直接使用了官方给的QuickStart示例项目作为基础进行搭建。有一说一，为了保护一个API，感觉花费的时间比写一个API还要多。 本文基于ASP.NET CORE 3.1, IdentityServer4 3.1.3。代码皆为关键代码，贴全了太多了。 好不容易跑起来了，最终的任务要落实到授权的工作上来。在API中使用 Authorize 用来限制用户的访问。 [Route("api/[controller]")] [Authorize(Roles = "Administrator")] [ApiController] public class UserInfoController : ControllerBase { /// <summary> /// 无参GET请求 /// </summary> /// <returns></returns> [HttpGet()] [ProducesResponseType(typeof(ReturnData<IEnumerable<UserInfo>>), Status200OK)] public async Task<ActionResult> Get() { var info = new Info<UserInfo>(); return Ok(new ReturnData

最近在折腾IdentityServer4，为了简单，直接使用了官方给的QuickStart示例项目作为基础进行搭建。有一说一，为了保护一个API，感觉花费的时间比写一个API还要多。 本文基于ASP.NET CORE 3.1, IdentityServer4 3.1.3。代码皆为关键代码，贴全了太多了。 好不容易跑起来了，最终的任务要落实到授权的工作上来。在API中使用 Authorize 用来限制用户的访问。 [Route("api/[controller]")] [Authorize(Roles = "Administrator")] [ApiController] public class UserInfoController : ControllerBase { /// <summary> /// 无参GET请求 /// </summary> /// <returns></returns> [HttpGet()] [ProducesResponseType(typeof(ReturnData<IEnumerable<UserInfo>>), Status200OK)] public async Task<ActionResult> Get() { var info = new Info<UserInfo>(); return Ok(new ReturnData