首页 > 解决方案 > 与 REST API 一起使用时如何保护 oauth

问题描述

REST我有一个与我的api交互的网络应用程序。我决定进行一些oauth身份验证,并且我遵循了一些关于如何实现它的教程,但我仍然在努力理解为什么它是安全的,或者我怎样才能让它安全。

我的实现是这样的......

1. client makes request to Facebook
2. client clicks `allow access`
3. Facebook redirects back to client with code in URL
4. client makes a POST request of the code to the REST API
5. REST API authenticates code via a request to Facebook using the secret key
6. Success/fail response to client from REST API

我的问题是,这如何确保安全?据我所知,该代码保存在浏览器的 URL 中,因此一些恶意代码可以提取此代码如果恶意代码能够在代码过期之前弄清楚是什么 REST 调用对代码进行了身份验证,那么他们就可以将自己作为其他人进行身份验证并访问他们的数据。

我的实现可能是错误的,但是,我尽可能地遵循此以及其他教程。

如果我的方法是错误的,我该怎么做才能确保安全?

标签: restapiauthenticationoauthoauth-2.0

解决方案


稍后我会回答你的问题,但首先让我先说一些预备知识。

Oauth 是关于授权,而不是身份验证。在您的问题中将“身份验证”更改为“授权”。

单击“允许访问”的不是客户端,而是用户。Oauth 的要点是,用户希望在不向客户端提供密码的情况下授予客户端访问其某些数据的权限。Oauth 允许他使用他信任的浏览器执行此操作,因此用户可以放心使用客户端。

如果没有 Ouath 协议,他能够做到这一点的唯一方法就是向客户提供他的密码。想象一下,您每天使用的许多客户端都想要访问您的 Facebook 数据——如果没有 Oauth,您将不得不在这些客户端中输入您的 Facebook 凭据,这将使他们能够完全访问您的所有 Facebook。你会觉得舒服吗?您不应该这样做,因为它会为各种恶意软件滥用打开大门。Oauth 允许限制这些客户端可以从您的 Facebook 帐户(或任何帐户)访问的内容,因此您可以对正在使用的应用程序充满信心。

现在,针对您的问题——URL 中代码的风险。这确实是一个有效的问题,但它是一次性使用的(它被交换为一个访问令牌以供多次访问使用)并且生命周期很短。使用授权码的原因在 Oauth 威胁模型的第 3.4 节中进行了解释。Oauth 威胁模型的第 4.4.1.1 节解决了您所询问的确切问题:

o 根据核心 OAuth 规范,授权服务器和客户端必须确保使用 TLS 等传输层机制保护这些传输(参见第 5.1.1 节)。

o 授权服务器将要求客户端尽可能进行身份验证,因此可以以可靠的方式验证授权“代码”到某个客户端的绑定(参见第 5.2.4.4 节)。

o 对授权“代码”使用较短的到期时间(第 5.1.5.3 节)。

o 授权服务器应该强制执行一次性使用限制(参见第 5.1.5.4 节)。

o 如果授权服务器观察到多次尝试赎回授权“代码”,授权服务器可能想要撤销基于授权“代码”授予的所有令牌(参见第 5.2.1.1 节)。

o 在没有这些对策的情况下,可以使用缩小访问令牌的范围(第 5.1.5.1 节)和到期时间(第 5.1.5.3 节)来减少泄漏时的损害。

o 客户端服务器可能会重新加载重定向 URI 的目标页面,以便自动清理浏览器缓存。

现在, RFC 7636中发布的 Oauth 协议也得到了增强,可防止其他客户端窃取移动设备上特定客户端的授权代码。有关更多详细信息,请参阅 RFC。


推荐阅读