OIDC(OpenID Connect)的标准已经完成许久,然而及的程度一直很低。 我觉得主要的普及障碍之一就是缺少足够的科普教程,最佳实践。 如此复杂的协议,如果没有一个直观的介绍,容易让人失去兴趣。 这个小文章就是想用一个杜撰的故事来给读者一个对于OAuth2和OIDC的直观体验。 但愿有所帮助。

—–

从前,小A做了一个网站A,用户可以在网站上买菜,用户很开心,小明也很开心。 后来,小B做了一个网站B,目标是整合用户在所有买菜的网站上的购物记录。 于是小B找到小A说:能不能把让我获取你的全部用户购买记录呀?

小A说:做梦吧!又不是所有用户都同意呢!

小B说:那要不,我在要访问一个你的用户的购买记录前,我把用户重定向到你的网站,然后你可以问问用户愿不愿意分享这数据。假如同意,你就给我发个你签过名的token如何?

小A:这个可以,那我就开始写啦。

小B:且慢且慢,有这么个协议叫OAuth2哦,大家都用这个来搞定应用间授权(authorization)哦。用了这个协议,要是下一次比如小C想用你的数据,你就不用单独写一套给小C用的代码啦。一旦你实现了这个OAuth2之后,你可以准备一个“开发者”页面,然后别的开发者就可以直接注册。OAuth2的协议里,把除你以外的网站都叫做client哦。

小A:这么棒,那到底咋工作?

小B:很简单啊,你批准了我(也就是client)的注册请求后,按照协议,你要给我颁发client_idclient_credentials哦。每次我想访问你的数据,比如用户在我的网站上点击“连接A网站”,我就把用户带到你的一个授权页面,这个授权页面上会写说类似于“B站想要访问你的X/Y/Z资源,同意否?“信息。

小A:照这么说,我还是要单独为你写一个网页咯?

小B:不用的啦,按照协议,我带用户来你那儿的时会顺便带来我的client_id并且说清我想访问啥数据,并且告诉你如果用户同意之后你要把用户带去哪,所以你只要写一个授权页然后根据client_id和其他数据来显示内容就好啦,以后别的client也用这个数据✌️。

小A:好吧好吧,那在这个授权页,总之用户要是说同意,我就把用户带回你那?

小B:对的,你把用户带回我那儿时,要顺便给我个凭证哦。我可以拿着这个凭证和我的client_credential去你那儿领取最终的权限凭证,按照协议,也就是传说中的access_token啦。咩哈哈哈😂

小A:有了这个你就可以为所欲为?

小B:没没没不用担心😁,我只能做我被scope授权做的事。而且access_token会过期的。最不济,我拿着access_token访问你的服务的时候,你可以再检查一下嘛。

小A:这个好啊!做!

—–

注解:以上的讲解是个简化版OAuth2的Authorization Code Flow,也就是针对传统的服务端渲染网站的client所做的安排,如果client是App之类的,还会需要别的安排。

—–

时光荏苒。小A变强了,也变秃了。小A的网站发展成了横跨生活诸多领域业界巨头,几乎现在人手都有一个小A的账号。 小B还是个小公司。

小B又找到小A:诶,近来用户都不愿意注册登陆了,因为他们抱怨注册了太多服务,反感了。

小A:嘿!我这儿有个好方法哦。记得几年前你跟我提的专门做授权(authorization)的OAuth2协议吗? 现在大家基于这个协议,做了一个叫OIDC(OpenID Connect)的专门做认证(authentication)的协议哦! 我们已经支持了这个协议,所以你可以试试我们最新的“用A登陆”的功能哦,放了这个在你的登陆页上,不想注册的用户就可以直接用A站账号登陆B站啦。

小B:这么厉害!的确如此,仔细一想,认证是授权的子集。难不成,就是在OAuth2的scope中添加一个用户信息然后直接用access_token来当我网站登陆的token,就完事了?

小A:聪慧!这的确是OIDC的环节(scope中包含oidc)。但不完整,OAuth2毕竟不是完全的认证协议。你想,如果用access_token来做登陆凭证,这就意味着你每次想确认一个用户是否登陆,都要拿着access_token到我那儿来做个检查。这可不行呀,增加了你的延迟,也增加了我的负担。

小B:那假如,让access_token中包含用户信息就好啦?只要access_token不过期,用户可以被视为登陆状态,还不用去你的服务器请求用户信息。

小A:这想法可以,OIDC也的确就是这么回事。它修改了OAuth2,让我的服务器返回access_token的同时还返回一个用户凭证(id_token),此凭证包含了主要用户信息。这个凭证是用密钥认证过的,也就是说可以轻松判断是不是A站颁发的,而且和access_token一样,都会过期。这个id_token就可以被用来当你的内部用户token的。

小B:嗯。听起来不错。那总结一下,我去你那儿注册了OIDC后,我就可以在首页上安排一个“用A登陆”的按钮。用户点了这个按钮会被带到你的授权页,用户在这个授权页登陆,授权。然后你把用户带回我的网站并且带着凭证。我拿着凭证和我的client_credentials交换id_token。我把id_token存在cookie,session之类的地方。用户就完成了用A账号登陆的流程。

小A:正是。但你知道这协议威力不只如此,我若是愿意,还可以成为单点登录提供商(SSO Provider)。 也就是说,用户登陆我的平台,他可以看到所有他可以登陆的服务,他只要点击任意服务,比如B站,我就能带他去B站。 这样他就连B站的登陆页面都不用看到。这样用户想去哪,只要通过A站就可以完成,岂不美哉?我岂不是是能赚…….

小B粗暴的打断了小A:土豪坐下!

—–

注解:以上的讲解是简化版的OIDC,但包含了协议核心。 虽然如此,在安全类协议中细节是很重要的。阅读原版的协议文档是很重要的。

但愿这白话足够白