网站关键词推广方案,机器人学做玩 网站,网站模板文件不存在,阿里云安装wordpress出错求解#xfeff;#xfeff;# 写在前面IdentityServer4的学习断断续续#xff0c;兜兜转转#xff0c;走了不少弯路#xff0c;也花了不少时间。可能是因为没有阅读源码#xff0c;也没有特别系统的学习资料#xff0c;相关文章很多园子里的大佬都有涉及#xff0c;有系列文… # 写在前面IdentityServer4的学习断断续续兜兜转转走了不少弯路也花了不少时间。可能是因为没有阅读源码也没有特别系统的学习资料相关文章很多园子里的大佬都有涉及有系列文章比如晓晨大佬的https://www.cnblogs.com/stulzq/p/8119928.html蟋蟀 大佬的https://www.cnblogs.com/xishuai/tag/[34]%E5%B0%8F%E8%8F%9C%E5%AD%A6%E4%B9%A0%E7%BC%96%E7%A8%8B-IdentityServer4/李念辉、杨旭大佬均有相关文章翻翻便可找到就不一一列举了。但是不知大家有没有体会好像看了很多id4(IdentityServer4,下同)的文章对oidc究竟是个什么蛤蟆OAuth2.0和OpenId Connect究竟有啥区别id4切确是什么东西id4能干些啥id4为什么这么设计id4各授权流程的区别是啥id4的SSO是基于什么原理我还是时不时老实说这些问题我也一懂半懂还有就是看多了、时间跨度大有的以为懂了提笔又忘了。这时大佬肯定说”谁叫你不去看源码“我默默的留下了两行老泪马上看马上看。但是我觉得id4很多新手和我一样都有这困扰上手门槛确实有的高。诚然看源码是个不错的学习方法但上来就让新人或使用者看源码无疑很不利于推广、直接劝退啊毕竟大部分都是跟我一样的菜逼对不起拖后腿了。对应前面提到的一串问题我不打算在本文一一解答我今天着重想聊的是id4的SSO是基于什么原理写本文的初衷是看到李念辉大佬的https://www.cnblogs.com/linianhui/p/oidc-in-action-sso.html所以本文算算是读博笔记。啥是SSO?SSO全称Single sign-on 在多个应用系统中只需要登录一次就可以访问其他相互信任的应用系统。比如你登录京东后查看我的订单https://order.jd.com 然后再去查看购物车https://cart.jd.com/cart.action就不需要重新登录。虽然这里顶级域名一致但其实单点登录并没有此要求。单点登录很容易望文生义以为单点登录就是限制用户只能在一处登录。下面我们说说我们我们常用的SSO的常用的实现方式。SSO—基于Cookie的实现简析这种方式比较简单使用也比较广泛。比如我有两个系统a.example.com 和 b.example.com很简单只需要搞个 passport.example.com 登录成功后往example.com 这个顶级域写登录成功的cookie就行了。而后不管你是c.example.com还是d.example.com或是∞.example.com都只需要验证登录的cookie就行简单方便。不过这种实现方式有个比较大的缺陷不能跨域不能跨顶级的域。我不能说我登录成功后往jd.com域名下写cookie吧。还有就是每个业务域名都要做登录cookie的校验逻辑 不过这算小问题。既然存在问题就解决问题吧这实在没办法解决发现问题的人啊SSO—基于CAS流程实现简析CAS简介Central Authentication Service简称CAS 是一个单点登录框架或者说解决方案开始是由耶鲁大学的一个组织开发后来归到apereo管理。同时CAS也是开源的遵循apache 2.0协议目前代码放在github上https://github.com/apereo/cas打开就惊呆了看到吧一堆开源项目在用这logo闪瞎我的钛合金狗眼了我们看下github简介”CAS是一个企业级的、与语言无光的Web SSO解决方案同时也尝试整合授权和鉴权的需求。“既然它是一个解决方案那我们看看它到底提出了啥。CAS的方案泳道图分析CAS SSO标准流程看图说话吧。右键可看查原图我们看看发生了啥:站点App1用户首次访问web App1App1发现用户未登录携带目前访问地址302到CAS Server登录页。CAS Server登录页检查登录Session不存在返回一个登录页面。填写账号点击登录。CAS Server验证账号信息成功创建一个Ticket Granting Ticket(TGT),这个TGT就是当前登录用户的session key。同时创建一个service ticket并携带service ticket key,st key 作为参数跳转回App1。App1用get发送st key 去CAS Server验证验证通过后返回登录用户信息。App1使用返回的登录用户信息构建当前系统的登录状态并用一个JSESSIONID标记(JSESSIONID是Apache的默认名)并携带这个JSESSIONID重新访问App1。App1验证JSESSIONID登录成功展示登录成功页面。第二次访问验证JSESSIONID直接访问。站点App2用户首次访问web App2App2发现用户未登录携带目前访问地址302到CAS Server登录页。CAS Server登录页携带有App1生成的TGT那么直接做TCT的验证验证成功不需要登录创建一个App2的st key302回App2。后续和以上的5,6,7,8 补逻辑相同不赘述。CAS的流程大概于此实际的实现可能会复杂一点可能会遇到各式各样的问题。但有理论支撑总体实现起来还是简单可靠有保证的。下面说说基于Id4的OIDC是怎么做单点登录的。SSO—基于Id4的OIDC实现简析先准备环境把官方samples下下来https://github.com/IdentityServer/IdentityServer4/tree/master/samples我删掉了其他项目剩下这两个一目了然分别把这两个站点部署为http://odic.server.nethttp://sso.client.net我们再看一眼Idoc服务端配置配置IdentityServerConfigs添加这么一个客户端// sso implicit client
new Client
{ClientId ssoimplicit, //这个client id 跟 MfcImplicit 里面的配置要一致ClientName sso implicit clinet,AllowedGrantTypes GrantTypes.Implicit,RedirectUris { http://sso.client.net/signin-oidc },PostLogoutRedirectUris { http://sso.client.net/signout-callback-oidc },AllowedScopes new Liststring{IdentityServerConstants.StandardScopes.OpenId,IdentityServerConstants.StandardScopes.Profile,IdentityServerConstants.StandardScopes.Email}
}
ok我们用下抓包工具观察下登录流程。1、受保护客户端页面的访问sso.client.net是客户端而登录页在sso.client.net服务端我们先打开需要登录才可以访问的http://sso.client.net/Home/Secure这里302到了授权端点 http://odic.server.net/connect/authorize2、授权端点对客户端请求的验证这就是步骤1中 302挑战的授权端点携带的参数。我们先看看这些参数client_idssoimplicit //我们前面配置的clinenidreponse_modeform_post //指示oidc服务器返回数据的形式是form表单response_typeid_token //区别于oauth2授权请求的一点必须包含有id_token这一项。scopeopenid profile //区别于oauth2授权请求的一点必须包含有openid这一项。stateoauth2定义的一个状态字符串这里的实现是加密保存了一些客户端的信息让你最后可以在登录成功后带回到客户端这个参数听重要的nonce上一步中写入cookie的值这字符串将来会包含在idtoken中原样返回给客户端做安全校验用。redirect_urihttp://sso.client.net/signin-oidc //认证成功后的回调地址就是我们配置里面的授权端点有很多功能这里主要做了两件事先判断待过来的参数是否合法比如clientid是不是配置里面的参数有没有按要求、规范传过来参数是否被篡改未验证通过会报错。授权与否的校验根据携带的参数判断如果登录就直接回调 redirect_uri参数地址http://sso.client.net/signin-oidc否302到登录页引导用户登录。3、登录初次登录步骤2中的授权端点判断当前未登录还是302跳转登录页引导用户登录授权。点击登录跳转到是否授权页面这个页面不一定展示可通过配置Client的RequireConsentfalse跳过这个页面。of course Yes!4、登录成功客户端构建登录状态我们看看点Yes Alow 之后的请求。可以清楚的看到去到了http://odic.server.net/connect/authorize/callbackcallback哦这是一个登录回调它干了啥呢我们仔细看响应哦它这里响应回了一个页面这个页面只有一个表单当页面一加载完成立刻post表单到action’http://sso.client.net/signin-oidc‘ 这个地址。并且仔细看看表单的参数前面的那些scope、state啊这些参数全都带了过来有意思没错这精妙的设计也是规范之一。这里它为什么不带上clientid呢哈哈客户端自己肯定知道自己的clientid的另外还有中间这一大串的id_token你忘了吗这里面可是可以携带信息的哦。来我们看看这个id_token究竟是何方妖孽。我们看到id_token带有登录用户的信息isstoken发放的服务器地址audclientidsid会话信息kid当前token的标识符name用户名此外还有比如id_token的发放时间过期时间nonce用户非机密信息等等。还有蓝色部分需要使用客户端公钥验证的签名等等。这个时候客户端已经拿到登录用户的信息了这时客户端直接使用登录用户信息构建当前应用sso.client.net的登录状态即可。比如下面的这个 Set名为Implicit的Cookie这个Cookie是可以删掉的它本身只维持了在sso.client.net的登录状态而已如果你删掉它它就会重新跑到授权端点http://odic.server.net/connect/authorize 去验证一下发现当前会话还是处于登录状态的然后又302到登录回调地址http://sso.client.net/signin-oidc然后/signin-oidc从state参数里面取出redirect_url302回到当前页面。最后我们来看一下登录成功的页面单点登出单点登出我就不细说了使用//指定登录方案的方式登出
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);//或者直接
await HttpContext.SignOutAsync();暴力点删除cookie也可以不过那只能算是半退出状态吧。
总结通过对以上一个使用Id4构建的OIDC实现的登录流程来看OIDC的SSO它完全无光域名的id4登录成功后客户端通过使用id_token来构建自身的登录状态一个client如此N个皆然。大家好像感觉这个SSO的实现方式跟前面的CAS流程很像诶我们再看一遍前面CAS的图好像是发现了啥不得了的东西。没错openid也是基于CAS流程的一个实现我根据理解猜的 没有证据。再多说两句id4确实是好东西暂时用不上也要多了解、学习最好写个博客做个笔记加深下理解。在理解的基础上不要去背各种Flow有啥区别什么的知道什么场景下用那种流程就行也没几个。善用官方文档、Sample。本文示例源码https://github.com/gebiWangshushu/cnblogs-demos参考https://yq.aliyun.com/articles/636281https://www.cnblogs.com/linianhui/p/oidc-in-action-sso.html文章博客园地址请点击“阅读原文”
