公共客户端上的客户端身份验证

Question

• 应如何管理它们？

一些更具体的问题：

1. 根据定义，本机应用程序（实际上是公共客户端）不能安全地存储其凭据(client_id+secret)。是未注册的客户吗？如果我不能使用秘密来验证/验证它，我还应该做什么？
2. 客户端注册≠endpoint注册：第一个是关于注册客户端凭据(client_id+secret)；第二个关于注册客户端重定向endpoint。重定向endpoint注册是否足以授予客户端的真实性？
3. 客户端凭据授予是否使用相同的凭据(client_id+secret)进行客户端注册？

Answer 1

TL；DR：

无法使用 client_id和 client_secret对本机客户端进行身份验证。如果需要对客户机进行身份验证，则必须实现一个身份验证方案，该方案不将共享秘密委托给客户机（或者在客户机身份验证讨论中涉及最终用户）。根据应用程序的安全模型，您可能不需要对客户端进行身份验证。
1. 重定向终结点通常不足以对客户端进行身份验证（尽管存在异常）。
2. “客户端凭据”授权类型可以使用授权服务器支持的任何客户端身份验证机制，包括在客户端注册时提供的凭据。

我读到的要点是，您可以信任机密客户机的client_id（读：“username”）和client_secret（读：“password”）来用您的服务对它们进行身份验证。第三方应用程序不可能用该客户机的凭据来表示自己，因为它们被合理地假定是安全地存储在远离窥探的地方。

The authorization server MUST NOT issue client passwords or other
client credentials to native application or user-agent-based
application clients for the purpose of client authentication.

The authorization server MAY issue a client password or other
credentials for a specific installation of a native application
client on a specific device.

不是每个本机应用程序都能满足这些条件，基于浏览器的应用程序肯定不能，因为在它运行的环境中没有任何可唯一识别或难以欺骗的东西。这导致了两种选择-- ，您可以将客户机视为未经身份验证，或者您可以提出一种更合适的身份验证机制。

身份验证舞蹈的关键是一个共享的秘密-- ，它只有授权服务器和身份验证客户端知道。对于公共客户端，客户端本身中的任何内容都不是秘密。谢天谢地，有选择，我不只是说RFID钥匙和生物识别技术（尽管这些是完全可以接受的）。

作为一个思想实验，让我们考虑一个基于浏览器的客户端。我们可以合理地假设以下几点：它运行在浏览器中，从特定的域提供服务，并且该域由客户机的作者控制。身份验证服务器应该已经有一个客户机重定向URI，所以我们在那里有一些东西，但正如规范所要求的：

A valid redirection URI is not sufficient to verify the client's
identity when asking for resource owner authorization but can be
used to prevent delivering credentials to a counterfeit client
after obtaining resource owner authorization.

然而，实用主义可能会胜出-- 一个未经身份验证的客户机从根本上来说，与您的浏览器无法验证站点SSL证书的真实性时偶尔会看到的SSL“错误”没有什么不同。浏览器将立即拒绝进行任何进一步的操作，并确切地报告原因，但允许用户通过担保服务器的身份来自己接受风险。类似的工作流可能对许多OAuth2应用程序都有意义。

为什么验证客户的身份很重要？不这样做，信任链就断了。您的应用程序的用户信任您的应用程序。授权工作流确定您的用户也信任客户端，因此您的应用程序应该信任客户端。无需验证客户端标识，另一个客户端就可以承担受信任客户端的角色，并拥有其所有的安全权限。关于客户端身份验证的一切都是为了防止这种违反信任的行为。

希望这能帮上忙！

The authorization server is encouraged to consider stronger
authentication means than a client password.