3. 主流同步协议对比

做跨平台设备同步，选协议是第一道坎。

我见过不少团队，上来就拍脑袋选OAuth 2.0，结果发现需要用户信息时还得再调接口。也有人迷信SAML，部署完才发现移动端根本跑不动。说白了，没有银弹。

这一章，我把四种主流方案掰开揉碎讲清楚。你听完就能根据场景直接选型。

3.1 OAuth 2.0：授权框架，不是身份协议

很多人把OAuth 2.0当成登录协议用，这是个经典误区。

OAuth 2.0的核心是授权——它让一个应用（比如你的手机App）获得访问另一个服务（比如Google Drive）资源的权限。它不关心你是谁，只关心你有没有权限。

我在项目中遇到过这种情况：客户端拿到Token后，每次请求都要去用户中心查一次用户信息。高并发时，用户中心直接被打挂。嗯，这就是典型的「把授权当身份用」的坑。

OAuth 2.0的四种授权模式

模式	适用场景	安全等级
授权码模式	服务端应用、Web应用	高
隐式模式	纯前端应用（已不推荐）	低
密码模式	受信任的第一方应用	中
客户端凭证模式	服务间通信、后台任务	高

3.2 OpenID Connect：OAuth 2.0的身份层

OpenID Connect（OIDC）是在OAuth 2.0之上加了一层身份认证。说白了，它让OAuth 2.0的Token里包含了用户身份信息。

OIDC引入了一个新东西——ID Token。这是个JWT格式的令牌，里面直接包含了用户ID、姓名、邮箱等信息。客户端拿到ID Token就能知道是谁在登录，不需要再调额外接口。

OIDC的核心流程

1. 客户端发起认证请求
2. 授权服务器验证用户身份
3. 返回ID Token（JWT格式）和Access Token
4. 客户端验证ID Token签名，提取用户信息
5. 使用Access Token调用API获取资源

你想想看，OIDC把身份认证和资源授权合并成一次交互，这在跨设备同步场景下特别有用。比如你在手机上登录，平板端通过OIDC的Session Management就能感知到登录状态变化。

3.3 SAML：企业级的老大哥

SAML（Security Assertion Markup Language）是XML-based的协议，在企业内部用了十几年。它通过断言（Assertion）传递用户身份信息。

说实话，SAML很成熟，但也很重。它的消息格式是XML，解析起来比JSON慢不少。而且它基于浏览器重定向，移动端体验很差。

对比维度	SAML	OIDC
消息格式	XML	JSON
传输方式	浏览器重定向	HTTP请求
移动端支持	差	好
Token格式	断言（Assertion）	JWT
学习曲线	陡峭	平缓

我曾经帮一家金融客户做SSO方案，他们坚持用SAML。结果移动端开发周期比Web端多了两倍，光处理XML签名就折腾了半个月。嗯，选协议时一定要考虑终端类型。

3.4 自定义Token方案：灵活但危险

有些团队喜欢自己造轮子——自己定义Token格式，自己写签发和验证逻辑。好处是灵活，坏处是容易出安全漏洞。

我见过最离谱的自定义Token：直接把用户ID和过期时间拼在一起，用Base64编码就当Token用。这跟把密码写在便利贴上有什么区别？

自定义Token的常见坑

• 签名缺失：Token可以被任意篡改
• 过期机制不严谨：Token永久有效
• 缺乏刷新机制：过期后用户必须重新登录
• 信息泄露：敏感信息直接放在Token里

3.5 协议对比总览

下面这张表，我建议你收藏。选型时直接对照。

协议	核心能力	身份信息	移动端	企业级	推荐场景
OAuth 2.0	授权	需额外获取	好	中	第三方API授权
OIDC	认证+授权	内嵌在ID Token	好	中	跨设备登录同步
SAML	认证	断言内包含	差	强	企业内部SSO
自定义Token	灵活	自行定义	看实现	看实现	极端定制场景

3.6 核心流程图：协议选型决策

为了让你更直观地理解选型逻辑，我画了一张决策流程图。

3.7 我的选型建议

做了这么多年跨平台同步，我总结了一个简单粗暴的原则：

• 面向消费者的跨设备同步：无脑选OIDC。它原生支持身份认证，Token自带用户信息，移动端体验好。
• 企业内部系统对接：SAML仍然是标准，尤其是对接微软生态时。
• 第三方API授权：OAuth 2.0就够了，别上OIDC增加复杂度。
• IoT或嵌入式设备：可以考虑自定义Token，但一定要用标准加密库，别自己写签名逻辑。