基于IdentityServer4的OIDC实现单点登录(SSO)原理简析



基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第1张图片

# 写在前面

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是基于什么原理?

我还是时不时:

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第2张图片

老实说,这些问题我也一懂半懂,还有就是看多了、时间跨度大,有的以为懂了提笔又忘了。这时大佬肯定说:

”谁叫你不去看源码?“

我默默的留下了两行老泪:马上看,马上看。

但是我觉得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闪瞎我的钛合金狗眼了

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第3张图片

我们看下github简介:

”CAS是一个企业级的、与语言无光的Web SSO解决方案,同时也尝试整合授权和鉴权的需求。“

既然它是一个解决方案,那我们看看它到底提出了啥。

CAS的方案泳道图分析

CAS SSO标准流程,看图说话吧。

右键可看查原图

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第4张图片

我们看看发生了啥:

站点App1

  1. 用户首次访问web App1,App1发现用户未登录,携带目前访问地址302到CAS Server登录页。

  2. CAS Server登录页检查登录Session不存在,返回一个登录页面。

  3. 填写账号,点击登录。

  4. CAS Server验证账号信息成功,创建一个Ticket Granting Ticket(TGT),这个TGT就是当前登录用户的session key。同时,创建一个service ticket并携带service ticket key,st key 作为参数跳转回App1。

  5. App1用get发送st key 去CAS Server验证,验证通过后返回登录用户信息。

  6. App1使用返回的登录用户信息构建当前系统的登录状态,并用一个JSESSIONID标记(JSESSIONID是Apache的默认名),并携带这个JSESSIONID重新访问App1。

  7. App1验证JSESSIONID,登录成功,展示登录成功页面。

  8. 第二次访问,验证JSESSIONID,直接访问。

站点App2

  1. 用户首次访问web App2,App2发现用户未登录,携带目前访问地址302到CAS Server登录页。

  2. CAS Server登录页携带有App1生成的TGT,那么直接做TCT的验证,验证成功不需要登录,创建一个App2的st key,302回App2。

  3. 后续和以上的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服务端配置:

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第5张图片

配置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
    {
        IdentityServerConstants.StandardScopes.OpenId,
        IdentityServerConstants.StandardScopes.Profile,
        IdentityServerConstants.StandardScopes.Email
    }
}

ok,我们用下抓包工具观察下登录流程。

1、受保护客户端页面的访问

sso.client.net是客户端,而登录页在sso.client.net服务端

我们先打开需要登录才可以访问的:http://sso.client.net/Home/Secure

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第6张图片

这里302到了授权端点 http://odic.server.net/connect/authorize

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

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第7张图片

我们先看看这些参数

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 //认证成功后的回调地址,就是我们配置里面的

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

  1. 先判断待过来的参数是否合法,比如clientid是不是配置里面的,参数有没有按要求、规范传过来,参数是否被篡改,未验证通过会报错。

  2. 授权与否的校验,根据携带的参数,判断如果登录,就直接回调 redirect_uri参数地址:http://sso.client.net/signin-oidc,否,302到登录页,引导用户登录。

3、登录

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第8张图片

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第9张图片

of course Yes!

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

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第10张图片

可以清楚的看到去到了:

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

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第11张图片

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

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

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第12张图片

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

iss:token发放的服务器地址

aud:clientid

sid:会话信息

kid:当前token的标识符

name:用户名

此外还有比如id_token的发放时间,过期时间,nonce,用户非机密信息等等。还有蓝色部分需要使用客户端公钥验证的签名等等。

这个时候客户端已经拿到登录用户的信息了,这时客户端直接使用登录用户信息,构建当前应用sso.client.net的登录状态即可。

比如下面的这个 Set名为Implicit的Cookie:

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第13张图片

这个Cookie是可以删掉的,它本身只维持了在sso.client.net的登录状态而已,如果你删掉它,它就会重新跑到授权端点:http://odic.server.net/connect/authorize 去验证一下,发现当前会话还是处于登录状态的,然后又302到登录回调地址http://sso.client.net/signin-oidc,然后/signin-oidc从state参数里面取出redirect_url,302回到当前页面。

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

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第14张图片

单点登出

单点登出我就不细说了,使用:

//指定登录方案的方式登出
await HttpContext.SignOutAsync(IdentityServerConstants.DefaultCookieAuthenticationScheme);

//或者直接
await HttpContext.SignOutAsync();

暴力点删除cookie也可以,不过那只能算是半退出状态吧。

总结

通过对以上一个使用Id4构建的OIDC实现的登录流程来看,OIDC的SSO它完全无光域名的,id4登录成功后,客户端通过使用id_token来构建自身的登录状态,一个client如此,N个皆然。

大家好像感觉这个SSO的实现方式跟前面的CAS流程很像诶,我们再看一遍前面CAS的图

基于IdentityServer4的OIDC实现单点登录(SSO)原理简析_第15张图片

好像是发现了啥不得了的东西。

没错:openid也是基于CAS流程的一个实现(我根据理解猜的 没有证据)。

再多说两句

id4确实是好东西,暂时用不上也要多了解、学习,最好写个博客做个笔记加深下理解。

在理解的基础上不要去背各种Flow有啥区别什么的,知道什么场景下用那种流程就行,也没几个。

善用官方文档、Sample。

本文示例源码

https://github.com/gebiWangshushu/cnblogs-demos

参考

https://yq.aliyun.com/articles/636281

https://www.cnblogs.com/linianhui/p/oidc-in-action-sso.html

文章博客园地址请点击“阅读原文”

你可能感兴趣的:(cookie,java,http,jwt,移动开发)