网站地图 | RSS订阅 老铁博客 - 上海SEO优化|上海网站建设|蜘蛛池出租|站群代搭建
你的位置:首页 » 推广营销 » 正文

云调用小程序鉴权正确姿势

2019-6-12 16:31:53 | 作者:老铁SEO | 0个评论 | 人浏览

  互联网的应用,大大小小,不同场景,都离不开鉴权,从简单的可被用户感知的登陆鉴权,到技术侧不被感知的各种技术参数鉴权,都有着形形色色的鉴权方式和表现形式。

  而现代网络设计中,权力的分配一般都是预先分配好的,在鉴别身份之后,拿着身份信息,去权限中心确定权力范围。这样就完成了用户的鉴权过程。

  说起身份证, 据相关史实考证,我国的身份证最早出现在战国时期,商鞅在秦国变法,发明了「照身帖」。照身帖由官府发放,是一块打磨光滑细密的竹板,上面刻着持有人的头像和籍贯信息。国人必须持有, 如若没有,就被认为是黑户或者间谍之类。这可能是身份证的雏形。

  在隋唐时期,我国出现了最早的“身份证”,当时的朝廷发给官员一种类似身份证的“鱼符”,是用木头或者金属所作,形状像鱼,分左右两片,上有小孔,并可有官员姓名、任职衙门、官员品级等。那时,凡亲王、三品以上官员“鱼符”用黄金制作;五品以上用白银;六品以下为铜制。五品以上官员,还备有存放鱼符的专用袋子,称为“鱼袋”。

  从秦朝到清朝的这个阶段,出现的这些身份标识,尽管形式多样,但总体来说,都是属于「身份证明」这一范畴。然而,这样的「身份证」在核验其身份的真实性方面,只能凭眼看,造假很容易蒙混过关,没有人能真正证明其真实性。这种核验身份方法是最初级最原始的方法,是现代身份证雏形的阶段。

  同样,在武侠小说中的令牌,也是如此。最近热播的「倚天屠龙记」中,明教的「圣火令」—— 见之如见教主。「圣火令」就是令牌的一种方式,是一种固定的密钥鉴权方式。

  『我这有一把锁,我把钥匙发给你,你使用资源的时候过来开锁使用就好了。』可以形象的比喻现代互联网中使用的密码鉴权体系。资源管理者只信任密码凭证,无论谁持有了密码,都可以使用对应的权利资源。比如,不管谁持有圣火令,都可以使用明教教主的权利资源。

  想象一种场景,持有圣火令的教主,每次施号发令,都要将圣火令从自己藏的密道中取出来才能发令。那么,如果自己心爱的人正在被屠杀,取个圣火令回来可能人就没了,所以,这里应该是有一个简单的方式来优化这一过程。

  互联网密码鉴权体系中,常常在通过身份验证后,将通过认证的信息保持一段时间,同样,实际武侠江湖中,大家都是有记忆的,圣火令持有者亮出圣火令的一段时间后,看到的人就能记下他已经是圣火令的持有者了,下次发号施令,就不必取来圣火令了。

  在web认证体系下,http协议是一种无状态的协议,用户通过输入密码后获得身份认证,这种状态是无法保持下来的,为了保持这种状态,客户端和服务端可以一起想办法把鉴权状态保留一段时间。比如,客户端可以记下用户的密码,下次只需要把密码自动带入到服务端即可。但这种方式是极为不安全的,客户端和传输端的可能泄漏密码。为了避免这种风险的发生,客户端和服务端通过其他的约定来保持这种状态,比如,通过一种临时密码来降低这种风险发生的危害,这种临时规则可以是session + cookie,也可以是token等等。

  密码鉴权体系一般都是发生在两方之间的鉴权方案。但是回归到武侠世界中,如果一个人拿了伪造的圣火令来发号施令,那岂不是对明教的危害很大?怎么解决这个问题?这就需要一个可以被信任的人,能够先甄别圣火令的真假,然后其他的人信任这个人,最终完成身份的验证。

  所以这就引入了一个可信任的第三方代为鉴别令牌的,然后告知鉴别结果。比如,第三方登录场景下, 平台需要第三方平台代为身份验证后告知平台此人的身份是什么。这就是我们常见到的oAuth鉴权,现在被广泛应用再第三方登陆平台中,比如微信登陆、QQ登陆等等。

  oAuth 2.0分为客户端鉴权和服务器端鉴权两种方式。拿比较常见的qq登陆来举例,第三方平台需要在QQ互联平台申请一个appid,互联平台同时会分配一个私密的appkey(密钥,始终不公开)。

  1.以web版 服务端oAuth鉴权方式举例:1.用户: 点击使用QQ登陆按钮(平台方页面) 2.浏览器: 跳转到QQ互联登陆页面(第三方平台页面)

  3.浏览器: 用户和第三方平台鉴权(第三方平台) 4.浏览器: 第三方平台跳回回调页面(平台方)

  5.服务器:第三方通过token加appkey来获取用户信息(服务端发起,避免appkey暴露)

  通过上述过程完成了第三方平台的鉴权,获取到了第三方平台提供的临时密钥token,平台之后就可以通过这些信息向第三方索取更多的数据和权力,比如获取用户的openid和基本信息等等。

  有过小程序开发经验的开发者,都会或多或少地用上小程序的开放能力,其中为数不少的能力是通过服务端 API 接口的方式提供给广大的开发者。比如,我们常用来发送通知用户给用户的模板消息能力:

  然后如果你查阅这些开放的服务端 API ,会发现几乎每个 API 都需要填一个参数,那就是 access_token。这个参数主要是用于微信侧的服务器鉴权。微信侧的服务器拿到 access_token 后,就会知道该小程序有没有权限可以替用户进行开放能力的操作。

  它是通过一个 auth.getAccessToken 的接口来获取的,它具体的入参出参如下:

  这种调用方式,基本上的思路跟 OAuth 2.0 的客户端模式很类似。OAuth 2.0 比较完整的模型如下图:

  其中步骤 A 里, granttype 表示授权类型,小程序这里的固定值是clientcredentials。外面有的服务还需要填一个 scope 字段,表示 AccessToken 的适用获围,这里则省略了,表示适用所有的服务端 API。

  基于这种 OAuth 2.0 的开发模式,很多公司都会多搭建一个中间服务层,或者直接用中间件,去获取类似 AccessToken 这种跟小程序相关的信息,因为这个令牌是有一定时效性,而且每天都有接口调用的限制,因此不可能每个用户操作的时候,都调用接口获取新的 AccessToken。

  这种开发模式有一定的局限性,那就是在开发微信相关业务的时候,需要额外部署缓存或数据服务,而存储的数据量其实很少,造成了资源的浪费和抬高了维护成本。

  安全性与便利性就像一对互有恩怨情仇的侠侣,总是无法很好地调和。如果希望系统更安全,多设几道防御屏障,用加密级数更高的算法,那便利性、性能等方面就会承受一定的折损。而如果想用户更方便,少设几道安全关卡,那安全方面自然就会大打折扣。

  因此,如果需要自己搭建一套微信小程序的服务,首先微信开放平台的鉴权服务是自然跑不掉的,需要按照文档规范逐一落实。而这套服务跟小程序前端的鉴权,也自然是个棘手的问题。简单一点的,用 JWT (JSON Web Token) 实现去中心化的鉴权,缺点是无法保证用户端的泄漏风险以及过期时间。而高级一点的是自己维护一套有过期时间的中心化 Cookie/Session 体系,看起来是安全些,但对服务的平行扩容却又并不太友好。

  云调用是云开发提供的基于云函数使用小程序开放接口的能力。云调用需要在云函数中通过 wx-server-sdk 使用。在云函数中使用云调用调用服务端接口无需换取 access_token,只要是在从小程序端触发的云函数中发起的云调用都经过微信自动鉴权,可以在登记权限后直接调用如发送模板消息等开放接口。

  从这个例子看出,其实入参并无差异,只是不需要再去获取 access_token。那意味着整个开发的架构,可以简化成这样,架构的复杂度大大降低:

  那目前有哪些的小程序使用场景可以用上云调用呢?统计了一下,主要用户信息获取、访问留存、消息(模板、统一服务、动态)、小程序码、内容安全等十几个大类几十个开放接口已经支持云调用。具体可以参考小程序服务端接口列表,如果接口旁边有一个云调用的标签,表明该接口支持云调用。

  总之,鉴权场景从古至今都是一个高频场景,从古代的鱼符号,现代的身份证,都是一种令牌凭证的鉴权方式,到了线上的系统中,大部分场景也是基于密码鉴权体系,除此之外,基于生物特征的鉴权,比如基于指纹、基于面容ID等等也都在广泛使用起来。

  第三方鉴权体系也随着各大平台的开放而逐渐发展起来,单看小程序体系下鉴权也是无处不在,小程序云开发推出了免鉴权体系,为小程序的开发带来了极大的方便。

  更进一步,未来是否可以有一种不基于密码的授权方式?比如基于机器学习和区块链模式下的鉴权,区块链的信任是去中心化的一种实现方式,未来的鉴权能否也可以做到去中心化的鉴权?

  • 本文来自: 老铁博客,转载请保留出处!欢迎发表您的评论
  • 相关标签:小程序openid  
  • 已有0位网友发表了一针见血的评论,你还等什么?

    必填

    选填

    记住我,下次回复时不用重新输入个人信息

    必填,不填不让过哦,嘻嘻。

    ◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。