在AngularJS应用程序中保护OAuth clientId / clientSecret

作者: 不浪漫
发布时间: 2025-01-04 04:43:57 (18天前)
转自：

3 条回复

0#
回复此人
v-star*위위 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 我来到这里寻找这个问题的答案 - 如何处理SPA中的秘密/身份证。我提出了自己的解决方案，隐藏了服务器中的秘密，但我想确认我在做什么是最好的做法。因此，由于答案可以避免这种情况，我将解释我的流程，希望能帮助那里的任何人。 我们的架构 - 我们有一个ruby服务器作为api服务器和一个提供Angular应用程序的快速服务器。 通常所有的通信都是通过api简单地完成的，所以节点服务器只是提供静态文件，并没有真正做很多事情。 由于我们正在实现登录/注册流程，我遇到了 - 对我来说是什么新东西 - OAuth 2.0流程如何处理事情。 在我们向服务器提出任何请求之前，服务器将认真对待我们，我们需要让自己获得Bearer令牌。我选择将其实现为节点端点，从而隐藏节点服务器本身内的客户端秘密。 因此，我们的客户输入了他们所有多汁的数据，并且在我们的应用程序中点击提交按钮后变得很红。 <OL> <LI> 应用程序向节点服务器发出请求以获取一个我们可以用作承载的美味令牌。我选择将客户端ID作为GET请求查询参数传递。首先，我在节点服务器中有客户端ID和秘密，但感觉id可以/应该在客户端上。所以我就这样走了。 </LI> <LI> 节点服务器通过GET请求接收客户端ID，然后继续向主机（ruby api）发出POST。构建url + grant类型+客户端id +客户端密钥。从而将实现隐藏起来。 </LI> <LI> ruby服务器返回一个令牌供我们使用，然后我们返回到初始化注册请求的客户端。 </LI> <LI> SPA现在有一个Bearer令牌，我们可以在注册请求的标题中使用。 </LI> </醇> 从而完成了我们的流程，并从世界隐藏了一个隐藏的秘密。 由于我们有一个具有一定生命周期的令牌，我们还有一个请求错误拦截器，它将捕获已过期的令牌，从而发出新的令牌请求，然后重新启动失败的调用。 我选择在Angular方面使用这个lib来为用户提供流量。 <a href="https://github.com/sahat/satellizer" rel="nofollow"> https://github.com/sahat/satellizer </A> 它是一个非常方便的lib，它可以获取所有无聊的样板代码，每当我们希望应用程序通过电子邮件/密码进行身份验证以及通过oauth进行身份验证时，必须编写这些代码....非常方便。 因此，这是我自己对如何做这些事情的解释 - 请求反馈。 </DIV>

编辑
1#
回复此人
荧惑 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 记住这一点的 OAuth的 </强> 更少关于防止冒充，更多关于保护凭据。第三方在不泄露用户凭据的情况下为您验证用户的身份。由于令牌不是凭证，黑客可以做的伤害量和他的行动窗口是有限的。 但的 OAuth的 </强> 与常规用户名/密码认证相比，您的应用程序本身并不安全。在客户端应用程序上，所有代码都可供全世界查看！如你提到过，客户端加密是一个值得怀疑的策略。 <HR /> 的 虽然没有建立保护客户互动的最佳做法，但以下是一些最小化您的风险的方法： </强> 的 1）SSL： </强> 银子弹？也许。你可以使用的越多的 SSL </强> 在您的网站和您的请求中，您的用户请求会更安全。老实说，我认为所有特权请求都应该由加密请求提出。 的 2）短令牌寿命： </强> 令牌的寿命越短，嗅探它的激励/优势就越少。 OAuth 2.0通过为身份验证令牌交换刷新令牌的身份验证令牌，从身份验证中创建一个持续的聊天。你，正在开发人员正在开发一个健谈的应用程序，它做了很多“你的令牌是什么，这是另一个令牌，问我一个令牌，这是你的新令牌......所以你想要什么？” ......“哎呀，时间到了，你的刷新令牌在哪里？” 如果这听起来像是一种痛苦，那就有点儿了。 OAuth 2.0旨在让开发人员更轻松地完成此过程。但重要的是，您的令牌的使用寿命越短，黑客就越难以保持欺诈性身份。的 <a href="http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-1.5"> 刷新令牌参考 </A> </强> 的 3）强制执行您的域名： </强> 想要给嗅探器更少的机会滥用你的盔甲中的缝隙？不允许跨域请求！ 当然，我们经常有分布式环境。但如果您的Facade在客户域上，您的曝光率会减少（单词选择可疑）。 强迫黑客使用您的域名，限制他们的创造力。 的 4）使用第三方API尽可能频繁地维护您的访问权限： </强> 的 谷歌 </强> 和的 Facebook的 </强> API和服务已经过单元测试，战斗测试和演变。您越依赖它们来维护用户的身份，您将完成的工作就越少，您的机会就越少。 的 5）检查IP地址： </强> 几乎任何东西都可以伪造，但黑客必须知道IP地址是验证的一部分。这是所有实践中最不确定的，但结合1,2或更多，黑客利用的差距变小，努力的收益逐渐减少。 的 6）使用“秘密”或第二个参数： </强> 您可以为您的用户传递多个令牌。你可以通过自己的Alter-Token。 假装它是来回传递的ID数据。以非显而易见的方式命名param。将其设为数字（例如年龄，身高，地址）。重要的一点是，你的黑客对另一方的要求知之甚少或根本不知道！ 你可以通过3个参数作为安全来抛出一个严重的猴子扳手。 的 7） </强> 不要给错误消息通知黑客他们被抓住了。给出超时消息而不是“得到你！”如果入侵者没有意识到欺诈被抓住了，他们也不会适应。 <HR /> 的 我说不够--SSL可以省去很多麻烦。 </强> 的 注意： </强> 我见过的所有客户端提供商都允许访问他们的API而不暴露Secret。的 秘密不应该暴露在客户端。 </强> <UL> <LI> 客户端上公开的任何数据都可以闪烁 </LI> <LI> 您使用的任何加密算法都将在客户端上公开。 </LI> </UL> </DIV>

编辑

登录后才能参与评论