ASP身份OAuth令牌 - 我应该在移动应用流程中使用ValidateClientAuthentication()和Secret吗?

时间:2015-04-11 14:10:58

标签: asp.net-web-api oauth asp.net-identity owin access-token

我有一个移动应用程序,它与后端的ASP WebAPI进行通信 我已经实现了令牌流认证(在Taiseer's guide的帮助下)。

仍然有一个我无法理解的概念: CleintId ClientSecret

据我所知,客户端秘密(以及客户端ID)的意思是 阻止访问生成令牌的API中的终点。通过这种方式,可以保护终端免受恶意用户的攻击,并试图通过各种输入调用它来获取某些信息。

意思是,只有持有秘密的客户才能启动真实流程。在我的情况下,我只有一个客户端是一个移动应用程序,它的秘密存储在一个安全的地方(KeyChain for iOs)。但我已经读到,这些钥匙链可以很容易地被倾倒并解剖秘密。

所以我想出的结论是,我可以摆脱整个客户端的秘密逻辑,主要是将ValidateClientAuthentication()留空:

public async override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context)
{

    context.Validated();
    return;
}

对我而言,这似乎不是一个安全漏洞,而是现在流动的一层薄薄的一层。因为,任何持有安装了应用程序的移动设备的恶意用户都可以轻松地揭示客户机密,并且一旦获得它,这层安全就没用了。

这些假设是不正确的?

我可以将ValidateClientAuthentication()方法留空吗?

1 个答案:

答案 0 :(得分:3)

正如您已经想到的那样,移动应用程序无法将其凭据保密,因为它们可以从应用程序二进制文件中提取。更不用说使用代理服务器和流量分析器(如Fiddler或Wireshark)可以轻松拦截请求。

使用授权代码流(1)或资源所有者密码凭据授予,如果客户端无法安全地存储其凭据,则客户端身份验证不是必需的,因此不能将其视为“机密”应用程序(请参阅http://tools.ietf.org/html/rfc6749#section-4.1.3http://tools.ietf.org/html/rfc6749#section-4.3.2)。

对于非机密应用程序,可以安全地致电context.Validated()

就个人而言,我尽量避免资源所有者密码凭据授予,因为它明显违背了OAuth2的目的:保密密码并提供受限制的授权。如果您的应用程序完全受信任,那么它应该不是问题。


  1. 实际上,使用授权代码流而不强制执行客户端身份验证是非常罕见的,因为使用移动客户端应用程序的隐式流程更简单,在这种情况下提供类似的安全级别(更不用说它避免了第二次)往返于令牌端点)。