# 写在前面

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 App1，App1发现用户未登录，携带目前访问地址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 App2，App2发现用户未登录，携带目前访问地址302到CAS Server登录页。
CAS Server登录页携带有App1生成的TGT，那么直接做TCT的验证，验证成功不需要登录，创建一个App2的st key，302回App2。
后续和以上的5,6,7,8 补逻辑相同，不赘述。

CAS的流程大概于此，实际的实现可能会复杂一点，可能会遇到各式各样的问题。但有理论支撑，总体实现起来还是简单，可靠有保证的。

下面说说基于Id4的OIDC是怎么做单点登录的。

SSO—基于Id4的OIDC实现简析

先准备环境

把官方samples下下来：https://github.com/IdentityServer/IdentityServer4/tree/master/samples

我删掉了其他项目，剩下这两个，一目了然：

分别把这两个站点部署为：

http://odic.server.net

http://sso.client.net

我们再看一眼Idoc服务端配置：

配置IdentityServer，Configs添加这么一个客户端：

// 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 List<string>{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/authorize

2、授权端点对客户端请求的验证

这就是步骤1中， 302挑战的授权端点携带的参数。

我们先看看这些参数

client_id：ssoimplicit //我们前面配置的clinenid=
reponse_mode：form_post //指示oidc服务器返回数据的形式是form表单
response_type：id_token //区别于oauth2授权请求的一点，必须包含有id_token这一项。
scope：openid profile //区别于oauth2授权请求的一点，必须包含有openid这一项。
state：oauth2定义的一个状态字符串，这里的实现是加密保存了一些客户端的信息，让你最后可以在登录成功后带回到客户端，这个参数听重要的
nonce：上一步中写入cookie的值，这字符串将来会包含在idtoken中原样返回给客户端，做安全校验用。
redirect_uri：http://sso.client.net/signin-oidc //认证成功后的回调地址，就是我们配置里面的

授权端点有很多功能，这里主要做了两件事：

先判断待过来的参数是否合法，比如clientid是不是配置里面的，参数有没有按要求、规范传过来，参数是否被篡改，未验证通过会报错。
授权与否的校验，根据携带的参数，判断如果登录，就直接回调 redirect_uri参数地址：http://sso.client.net/signin-oidc，否，302到登录页，引导用户登录。

3、登录

初次登录，步骤2中的授权端点判断当前未登录，还是302，跳转登录页，引导用户登录授权。

点击登录，跳转到是否授权页面，这个页面不一定展示，可通过配置Client的RequireConsent=false，跳过这个页面。

of course Yes!

4、登录成功，客户端构建登录状态

我们看看点Yes Alow 之后的请求。

可以清楚的看到去到了：

http://odic.server.net/connect/authorize/callback

callback，哦，这是一个登录回调，它干了啥呢，我们仔细看响应：

哦，它这里响应回了一个页面，这个页面只有一个表单，当页面一加载完成立刻post表单到：action=’http://sso.client.net/signin-oidc‘ 这个地址。并且仔细看看表单的参数，前面的那些scope、state啊这些参数全都带了过来，有意思，没错，这精妙的设计也是规范之一。

这里它为什么不带上clientid呢？哈哈，客户端自己肯定知道自己的clientid的，另外，还有中间这一大串的id_token你忘了吗，这里面可是可以携带信息的哦。

来，我们看看这个id_token究竟是何方妖孽。

我们看到id_token带有登录用户的信息：

iss：token发放的服务器地址

aud：clientid

sid：会话信息

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_url，302回到当前页面。

最后我们来看一下登录成功的页面

单点登出

单点登出我就不细说了，使用：

//指定登录方案的方式登出
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);//或者直接
await HttpContext.SignOutAsync();暴力点删除cookie也可以，不过那只能算是半退出状态吧。