两个网站如何共用一个会员登陆就类似通行证似的

很多做网站的人都会碰到一个麻烦事。手里头有两个站点，一个主站卖货，一个论坛做内容，两边都有用户注册登录的模块。但用户去了论坛还得重新注册一次，再跑到主站又要再输一遍账号密码。这体验太割裂了，用户嫌麻烦，我们也觉得累。

其实这事没多复杂，核心就是让两个网站认同一把钥匙。说的专业点叫单点登录，说的通俗点就是通行证。你只用一个账号密码，就能在两个站之间自由的晃悠，不用二次登录。

先说一种最简单的实现思路，共享数据库。假如两个网站的代码都是你自己写的，那直接在配置里把用户表指向同一个数据库就行。用户在A站注册了，B站那边查询的时候也去同一个表里找。密码加密方式要统一，加密的盐要一致，不然A站能解开，B站却死活比对不上，那就是自己跟自己打架。这种做法适合两个站的技术栈差不多的场景，PHP写的站和Java写的站想直接用同一个库，倒也不是不行，就是密码处理那块要格外小心，最好都用标准的哈希算法。

共享数据库有个毛病，就是没法跨域。你在www.a.com登录了，浏览器存了一个a.com域下的Cookie，等你跳到www.b.com的时候，浏览器不会把a.com的Cookie发给b.com的服务器。这时候就得靠别的招。

常见的就是用token换身份。A站登录成功之后，后端给返回一个随机的字符串，比如一个uuid，外加一些用户信息。前端拿到这个token，把它存到本地。然后跳转到B站的时候，把token放在链接参数里，或者用一个临时跳转的页面把这个token传过去。B站收到这个token，先去自己的缓存或者数据库里查一下，看这个token是不是有效的、是不是没过期、是对应哪个用户。确认没问题，B站就给自己域下种一个登录态的Cookie。这样你在B站就自动变成已登录状态了，不用再输密码。

这个方案听起来挺顺，但有个细节得留神。token在URL上直接传递有安全隐患，容易被人截胡。稳妥一点的做法是B站拿到token之后，立刻让前端清除掉URL上的参数，再刷新一下页面。或者干脆用一次性的临时票据，用完了就作废。另外token的过期时间不能设太长，半小时或者一小时就够用，毕竟只是过渡用的。

如果你的两个站点不是自己技术团队写的，用的是现成的系统，比如WordPress加DISCUZ，那想打通登录就得另想办法。有人会去装一些现成的插件，比如三方登录整合的插件，让两边都接入同一个第三方平台，像微信扫码或QQ登录。这样用户其实是用第三方账号登录，两个站各自去调用第三方的接口，间接实现了通行证的效果。但是这里有个绕不开的坑，问题在于两个站获得的第三方用户标识可能是同一个openid，才说明是同一个人。可有些插件处理方式不一样，把openid绑定到各自站内已有的账号上，结果就是两边虽然是同一个微信扫的，但后台的用户还是两套，只是在用户感知上觉得省事而已。

真正的通行证，得让底层用户数据打通。我见过一个比较漂亮的方案，是搞一个独立的认证中心，域名就叫sso.a.com。所有跟登录注册相关的操作都扔到这个站点来处理，A站和B站都不直接存储用户的密码，也不直接处理登录请求。用户访问A站想登录时，A站把请求跳到sso.a.com去，用户输账号密码，认证中心验完了，生成一个全局的会话密钥，再带着这个密钥跳回A站。A站拿着这个密钥去认证中心调一个接口，换取用户的昵称、头像这些资料。B站同理，用户没登录B站时，B站也跳转到认证中心，认证中心发现这人已经有会话了，直接跳回B站，B站再去换取资料。这样用户全程只输一次密码，两个站全都通了。

这种模式挺好用，但代价是得开发一套专门的认证服务，普通人搞不定，适合有一定研发能力的团队。

有些小公司图省事，直接用浏览器存储的特性来模拟。比如在A站登录后，把用户的唯一标识写在各级域名都能访问到的domain里，如果两个站是同一个主域名下的子域名，那Cookie可以直接共享，一个a.example.com，一个b.example.com，把Cookie的domain设为.example.com，两边就通用了。但如果是完全不同的域名，比如一个点cn一个点com，这条路就走不通了。

其实用不用通行证，得看你的业务有多重。如果两个站都是小规模，用户量加起来都不到一万，共享数据库就行，连token都省了。用户要是觉得每次都得重新登录不舒服，那就引导他们去注册一次，问题也不大。但如果两个站都是天天有活人在用的，那还是尽早把通行证做了，越拖越麻烦。数据改来改去的，用户资料东一块西一块，后面想合都合不拢。真实遇到过一个同行，两个站点搞了三年的独立账号体系，后来做活动要打通积分，只能手动导表，还碰上手机号被重复绑定的情况，那叫一个心累。代码写得再烂，也别让用户做选择题。