node单点登录是否需要每个系统都有一份user表

首先，你要明确分清“认证系统”和“业务系统”的职责。

一般地，认证系统只负责“登录认证”，业务系统只能从认证系统获得“基本的用户信息”。（比如你使用微信认证，你只能获得openId或者昵称、头像等基本信息）

但是，所有架构都有一个适用范围和场景，如果是一个公司内的大项目分解为多个系统，那除了解藕，还要考虑“效率和性能等”，比如在某些特定场景下，你可能需要在“认证系统”中保存所有子系统用到的用户信息的“全集”。

或者，在“认证系统”之外，有些项目会独立出一个“用户系统”专门负责保存用户相关的内容，比如积分、等级等用户子系统。

还是那句话，“分久必合，合久必分”，说的是架构并不是一成不变的，会根椐需求、规模等各种外部因素来考虑和调整的。回到你的案例：

1. 积分属于业务字段（只有b需要），并不是认证字段，一般不适宜放在认证系统
2. 但如果需求变成积分是一个基础字段呢（现在只有b需要，有没可能过一段时间，c说我也需要）？
3. 如果c也需要，你把它放在a了，后来b跟c又说，你的积分逻辑和我的逻辑不一样，我不想跟你玩了？ .... 所以，并没有一个一定对的方案。考虑好扩展性就行了，比如就算你把积分放在a，也不一定是user表，如果你把积分放在b，更加不是整个user表

node单点登录是否需要每个系统都有一份user表

不管是不是什么“单点登录”，如果你是独立系统（独立服务）， 是不是有一个 user 表，是看你怎么处理数据。

重点，是搞清楚 “单点登录” 是各独立系统的一个决定，而不是从上而下的一个强制设计。

你设计的东西，只是可以让 b, c 在需要的时候，可以从 a 获取到“当前用户信息”，然后，是否登录，是 b, c 自己的事，用户是创建，还是修改，也是 b, c 自己的事。用户信息的保存，是自己有一张 user 表写自己的持久化存储，还是远程调用使用其它服务的 API ，那看你 b, c 怎么处理，都可以啊。

如果你是需要一个建议：

1. a, b, c 三个系统完全独立，都有自己的 user 表。
2. a 实现类似 OAuth2 的协议， b, c 用它这套东西。
3. b, c 在用户每次“新会话”时，都从 a 同步用户信息。（新会话，可以是登录，可以是某个时间段后的回访，也可以是定时的轮询，看你场景吧）

没看懂你的问题，不过我这有一份单点登录的解决方案。 每一次登录（即调用/app/login接口）时，生成一个唯一性token，同时存放在客户端和数据库。客户端调用任何接口（除了login）时都带上token（没有呢？没有就当前用户视为游客或者去登录吧），服务端将之与数据库中所存比对，不等时返回“当前账号已于异地登录”。