zyq025的专栏

前言 原计划打算在春节期间多分享几篇技术文章的，但到最后一篇也没出，偷懒了吗？算是吧，过程是这样的：每次拿出电脑，在孩姥姥家的院子总有阳光沐浴，看不清屏幕，回屋又有点冷(在强行找理由)，于是又带着娃遛弯去啦。哪有那么多理由，就是想偷个懒；不过后面几天把计算机组成原理简单过了过，后面整理整理再单独给小伙伴分享吧。 这次接着IdentityServer4说，之前一直用内存数据进行测试演示，在正式项目中肯定是要存数据库的(除非数据固定，用内存方式实现)；接下来就用Demo实操的过程说说IdentityServ

前言 接着授权模式聊，这次说说Authorization Code(授权码)模式，熟悉的微博接入、微信接入、QQ接入都是这种方式(这里说的是oauth2.0的授权码模式)，从用户体验上来看，交互方式和Implicit没啥改变，随便找个网站瞅瞅，如慕课网(很不错的学习网站)的登录流程，见下图： 但其实在代码流程上是不太一样的，接下来边撸(我说的是敲代码)边聊。 正文 Authorization Code(授权码)模式比Implicit多了一个授权码的流程，即用户认证成功之后，授权服务器..

前言 上一篇Resource Owner Password Credentials模式虽然有用户参与，但对于非信任的第三方的来说，使用这种模式是有风险的，所以相对用的不多；这里接着说说implicit隐式模式，这种模式比较适合于纯前端客户端，比如Vue、Angular、React项目等，相对来说整个流程比较安全，只需在认证服务器进行认证即可，无需在客户端进行相关隐私信息录入，但前提是要客户端保证安全，不然容易被别人钓鱼(安全很重要)，那IdentityServer4不背这个锅。 正文 既然有用户参与，

前言 接着IdentityServer4的授权模式继续聊，这篇来说说 Resource Owner Password Credentials授权模式，这种模式在实际应用场景中使用的并不多，只怪其太开放啦，直接在客户端上拿着用户名和密码就去授权服务器获取AccessToken，这样容易被客户端拿着用户名和密码搞坏事；接下来就详细说说。 正文 Resource Owner Password Credentials授权模式与上一节说到的客户端凭据模式不同，这是有用户参与的，用户就是资源拥有者；通过允许在客户

前言 API裸奔是绝对不允许滴，之前专门针对这块分享了jwt的解决方案(WebApi接口裸奔有风险)；那如果是微服务，又怎么解决呢？每一个服务都加认证授权也可以解决问题，只是显得认证授权这块冗余，重复在搞事情；IT大佬肯定容忍不了，对于微服务架构，统一的认证授权中心那是必须的。 随着.NetCore的发布，IdentityServer4随之而出，是.NetFoundation的成员之一，专门针对.NetCore而出的认证授权框架，当前.Net圈是比较火的啦；再配上微服务认证授权的必要性，我决定以此开始.