都是本人理解，笔记大致概念，不详细也并非完全正确，所以仅供参考。

什么是联合登录

因为公司产品的发展，会与第三方的一些商户进行对接，商户APP提供入口，进入我们的H5页，从而提供服务。

而商户希望用户在其APP进行账户登录后，进入H5页不再进行登录，所以我们的H5需要拿到用户在商户的账户的标识id（暂时称之PartnerID），然后与我们的产品的账户标识id（暂时称之H5ID）进行一个关联，这样在用户登录APP后，我们能够通过PartnerID去查询关联的H5ID以获取账户信息，这样就可以保持登录的同步了。

解决方案

上述描述中的一个关键点是：如何拿到PartnerID

获取PartnerID大体有以三种方案：

方案1：授权回调式，商户提供授权页面，H5页面需要登录时，先进入商户提供的授权页，由用户同意授权，进而获取PartnerID
方案2：APP接口式，商户APP存在nativeAPI，H5页面调用nativeAPI以获取PartnerID
方案3：凭证解密式，商户APP在H5的url的query上添加加密字符串，H5页面取之解密后获取PartnerID

基本说遇到的联合登录大多以上三种之一，例如微信授权登录，可以视微信为商户，微信的unionid即PartnerID，微信使用的就是方案1。

另外实方案1是方案2的一个完善，商户提供的授权页上其实使用了方案2来获取PartnerID，这样可以保证自己APP的nativeAPI是由自己的H5页所调用，进而增加安全性。

所以说，就安全性的排序为：1 > 2 > 3

越安全开发即越复杂，所以，开发的复杂度也就是以上的排序。

联合登录的详细步骤

代码就不贴了，详细步骤如下：

1：准备进入一个H5页面，它需要登录方可访问
2：在进入之前先取PartnerID，商户APP未登录则进行APP登录，再返回PartnerID
3：得到PartnerID，去查询相应的H5ID，有则存储账户登录信息进入第5步，无关联则进入下一步
4：H5登录页进行登录，登录后得到H5ID，将H5ID与PartnerID进行绑定，并且存储账户登录信息
5：此时已登录，进入页面中

独立代码

方案有三种，但有些代码是必须得写的，总结如下：

配置文件：因为商户不同，则接入类型和配置参数不同，假设有一个 shanghu.js ，如下代码：

module.exports = {
  id: 'a', // 商户名称
  type: 1, // 接入方案类型
}

方案1：“调用进入商户授权页”和“调用商户API获取PartnerID”的两个函数
方案2：“调用nativeAPI获取PartnerID”的函数
方案3：“解密字符串得到PartnerID”的函数

这些根据商户不同代码也是不同的，做不到统一解决方案，so，老老实实写吧。

不过有些代码可以做成通用的，开发完成则后续接入可以不用再管了。

通用代码

方案1：授权回调式

说是最复杂的方案，其实通用代码就两个路由：

前往授权 /toAuth：前往需要登录的页面时（假设地址为A），则先前往此路由，此路由接收一个回调地址（A）并存储在 session 中，然后此路由进入商户授权页（此时调用独立代码中进入商户授权页的函数）

授权回调 /authBack：必须提供给商户的回调路由，当商户授权页面中用户授权后，会返回此路由，用户的token亦会在query上传递回来，通过token去换取PartnerID，即执行联合登录的3、4步后（此时调用独立代码中调用商户API获取PartnerID的函数），则取出session中的回调地址（例子中的A）并进入

方案2：APP接口式

这个方案的通用代码其实就是一个前端函数：

根据商户调用其特定的独立函数：前端能得到PartnerID，所以在需要登录之前，先调用该商户的独立代码中的调用nativeAPI获取PartnerID的函数，得到PartnerID，再执行联合登录的3、4步，最后完成登录操作。

方案3：凭证解密式

这个方案最简单，只是在入口的路由加一个操作：

存储加密凭证字符串：在入口路由上，将加密凭证存入session中，在需要登录前，则调用该商户的独立代码中的解密字符串得到PartnerID的函数，得到PartnerID，再执行联合登录的3、4步，最后完成登录操作。

查询接口

联合登录的第3步中，会存在两个api，这些由我们自己开发，分别是：

查询绑定账户：通过PartnerID查询关联的H5ID，若存在，则返回账户的登录信息，若不存在，则返回无绑定关系，前端根据api结果判断是否进入H5的登录页
进行账户绑定：将PartnerID和H5ID进行绑定，返回账户的登录信息

其他比较特殊的登录

静默登录

在上面的过程中，中间会有一层绑定的操作，此时需要内部H5页进行一次登录，而这样会出现两次登录的情况：APP登录后，首次进入H5，H5中登录并绑定。

所以，有些商户有这样的需求：APP已登录，则在H5内部无需登录，即首次进入H5也无需在H5进行登录绑定就可以有登录状态。

这种样的解决方案其实很简单，在查询的两个接口中，存在查询绑定账户的接口，这个接口的功能是：

通过PartnerID查询关联的H5ID，若存在，则返回账户的登录信息，若不存在，则返回无绑定关系，进入H5的登录页

如果需要满足上述需求，实际是这个接口永远返回登录信息，包括首次登录，如此简单即可。

因为在调用接口时，会传递商户名称和PartnerID，接口开发人员可以根据商户名进行操作。

例如：平台cmb需要静默登录，则后端开发人员在查询绑定账户接口接收参数 partnerName，若 partnerName === 'cmb'，则静默注册一个账号并登录，返回登录信息，其余的则正常流程。

而对于多个商户都有此类需求，可以维护一个 array ，符合array内的条目，进行进行静默注册并登录，不符合则走正常的步骤。

快应用的嵌入

快应用页可以获取用户在开放平台unionid，在进行嵌入开发时，有时候需要拿到unionid和H5的账户进行绑定。

首先，快应用提供了API以获取用户唯一身份标识，其次，快应用本身应该视为一个轻量APP的开发，而快应用也提供了一些方法，我们可以封存一些方法和接口，由H5以nativeAPI的方式进行调用和开发，故而快应用的联合登录应该是方案2：APP接口式。

封装

web组件可以使用：

postMessage：向内部H5推送一个消息
onmessage：监听内部H5的消息

内部H5可以使用：

system.postMessage：向外部web组件推送一个消息
system.onmessage：监听外部web组件传递的消息

故可以在web组件监听 onmessage ，得到网页 system.postMessage 发送的登录请求时，在快应用层去调用登录API，得到PartnerID后，再由web组件的 postMessage 将PartnerID传递给内部H5页面，而H5则得到PartnerID，走正常的联合登录流程。

END

个人特别不建议针对一个商户就写一套方案，浪费时间且大量重复代码，不利于代码维护。

虽说有多种情况，但大部分都是可以围绕三种方案进行延伸拓展，有其他情况再补充，现在就写到这里。。