基于Onsen框架的Cordova应用Web API 2双认证安全方案咨询

嘿，我来帮你梳理下正确的实现思路，你之前用临时表存令牌比对的方案确实不太稳妥，咱们换更标准、更安全的方式来保障Web API的安全性。

1. 先改掉Cordova端的令牌传递方式 #

你已经能成功获取Facebook访问令牌了，接下来调用Web API时，别随便把令牌塞在请求参数或Body里，规范的做法是把令牌放在Authorization请求头中，格式为Bearer {你的Facebook访问令牌}。举个Cordova里用fetch的例子：

const facebookToken = '你拿到的Facebook令牌';
fetch('https://your-api-domain/api/your-endpoint', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${facebookToken}`,
    'Content-Type': 'application/json'
  }
});

这种方式符合RESTful安全规范，也能避免令牌被意外泄露（比如被日志记录）。

2. Web API端：直接验证Facebook令牌的合法性 #

别自己存令牌做比对！Facebook本身提供了官方的令牌验证接口，咱们直接用它来确认令牌是否有效、是否属于你的应用、对应的用户是谁。具体步骤：

• 在Web API里创建一个自定义的授权过滤器（或者用中间件），每次收到请求时，从Authorization头里提取出Facebook令牌。
• 调用Facebook的debug_token接口验证令牌：
  请求地址是https://graph.facebook.com/debug_token，需要传两个参数：input_token（用户的Facebook访问令牌）和access_token（你的Facebook应用的App Access Token，格式是{你的App ID}|{你的App Secret}，在Facebook开发者后台就能拿到）。
• 解析接口返回的结果：如果is_valid字段为true，且app_id和你的应用ID一致，就说明令牌合法，此时可以拿到用户的Facebook ID，用来关联你的业务逻辑；如果验证失败，直接返回401 Unauthorized。

这样做的好处是完全依赖Facebook的官方验证机制，不用自己维护令牌的过期、注销等状态，安全性拉满。

3. 优化：生成API专属的JWT令牌（推荐） #

如果不想每次请求都调用Facebook的接口（毕竟有网络开销），可以在第一次验证Facebook令牌通过后，给Cordova端返回一个JWT（JSON Web Token）。后续Cordova应用就用这个JWT来调用API，API只需要验证JWT的签名和有效期即可。

具体操作：

• 验证Facebook令牌通过后，用你的API密钥生成JWT，里面可以包含用户的Facebook ID、过期时间、甚至用户的业务权限信息。
• Cordova端把JWT存在本地（比如用localStorage或者Cordova的cordova-plugin-storage），之后每次请求API都把JWT放在Authorization头里。
• API端用对应的密钥验证JWT的合法性，合法就处理请求，否则返回401。

这个方案既减少了对Facebook服务的依赖，响应更快，还能灵活扩展自己的业务权限逻辑。

4. 关联SQL Server用户表的做法 #

如果你想把Facebook登录的用户和自己的SQL Server用户表绑定，可以在第一次验证Facebook令牌通过后：

• 检查数据库里是否存在FacebookUserId等于当前用户Facebook ID的记录。
• 如果不存在，就新建一条用户记录，把Facebook ID存进去；如果存在，就直接关联到该用户。
• 之后生成JWT时，可以把你的SQL Server用户ID也放进JWT里，方便后续业务逻辑处理。

为什么你之前的方案有问题？ #

• 自己存令牌需要手动处理过期、用户注销（比如用户在Facebook上登出了，你这边的令牌还在生效），维护成本极高。
• 没有验证令牌的真实性，万一有人恶意伪造一个令牌插入你的临时表，就能轻易绕过认证，安全性完全没有保障。

总结下来，核心思路就是依赖Facebook官方的令牌验证机制，而非自行维护令牌有效性，再结合JWT优化API性能和扩展性，这样既安全又省心。

内容的提问来源于stack exchange，提问作者Daina Hodges