微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

node.js – passport-facebook-token vs passport-facebook

对于node.js中的社交认证,我看到许多项目使用 passport-facebook-token软件包而不是认的 passport-facebook.
我正在努力(并努力)理解这两个包之间的差异和好处 – 以及如何从另一个中选择一个.任何见解都表示赞赏.

解决方法

答案

经过一段时间的阅读后,我相信我已经理解(至少是基础知识),并且为了别人的利益而在这里分享

> passport-facebook使用OAuth2 – 授权代码授权流程
> passport-facebook-token使用OAuth2 – 隐式授权流程

有关这些内容的详细信息,请参阅这篇伟大的article on oauth flows.可以在此SO post中找到为这些特定库定制的流程图.

一般混乱

在进行这项研究时已经明显的一点是,围绕身份验证最佳实践存在很多混淆.许多(可能是大多数)确切地说应该使用每种不同的PassportJS策略(或流程)并不清楚.

一些结论:

>授权代码授予比Implicit Flow更安全,因为它不直接与用户代理(通常是Web浏览器)共享第三方访问令牌.尽管有许多相反的文章,只要SPA具有“专用服务器端组件”,例如BFF-API(就像我正在尝试构建的nestjs-bff ……这就是开始这整行的内容),这将与SPA一起使用.首先调查)
>隐式授权表示由于将访问令牌直接暴露给用户代理(通常是Web浏览器)而导致的安全漏洞增加.用例包括没有服务器端组件的SPA应用程序.最近,行业最佳实践已逐渐远离Implicit Grant和授权代码授予,没有客户机密,但使用PCKE(Proof Key Code Exchange)……但通常是recommended for native mobile apps,rather then SPAs.

MY NET TAKE-AWAY:

如果您的客户端有任何专用的服务器端组件,请使用授权代码授予(passport-facebook)而不是隐式授权(passport-facebook-token).

邀请到CHIME!

我希望能帮助那些发现自己有同样问题的人.如果有人发现任何关于我所写内容错误,遗漏或错误的假设,请加入.

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐