我想开发一个使用OAuth 2.0 Authorization从资源API访问受保护资源的本机应用程序（用于移动电话）。根据{{3}}中的定义，我的客户的类型是public。
注册后，授权服务器提供client_id用于公开识别和redirect_uri。
客户端将使用section 2.1从授权服务器接收授权授权。对于中间的任何攻击者来说，这一切似乎都是安全的（如果正确实施）。
在Authorization Code客户端模拟进行了讨论。在我的情况下，资源所有者通过用户代理向授权服务器提供其凭证来授予客户端授权。本节讨论授权服务器：
应该利用其他手段来保护资源所有者免受此类攻击 潜在的恶意客户。例如，授权服务器 可以让资源所有者协助识别客户和 它的起源。
主要关注点是，在检索到client_id和redirect_uri后，我很容易冒充我的客户。
由于公共客户的性质，这可以很容易地逆向工程。或者就我而言，该项目将是开源的，因此可以从网上检索这些信息。
就我从第10.2节所理解的情况而言，资源所有者有责任通过与授权服务器进行比较来检查客户端是否合法应该协助。
根据我从第三方应用程序请求授权授权的经验，我得到的是一个页面，其中包含有关客户实际应该请求该授权的一些信息。基于纯粹的逻辑意义，我只能判断请求授权的客户端是否实际上是授权服务器告诉我应该是谁的客户端。
因此，无论何时我们处理section 10.2（我认为经常发生），如果资源所有者只是授予他们（这可能与我的相同，模仿者）可以轻松访问受保护的资源，这是不正确的合法客户）授权？
答案 0 :(得分：1)
TLDR - 您希望仅向有效客户发放oauth访问令牌 - 在这种情况下是安装了您的应用的设备，是吗？
首先--Oauth2有多个用于发放令牌的工作流程。当您运行Oauth2服务及其向运行您的应用程序的设备发放令牌时，授权代码/重定向URL不是相关的工作流程。我建议你在这里阅读我的答案 - https://stackoverflow.com/a/17670574/116524。
第二 - 这里没有运气。只需在HTTPS上完全运行您的服务即可。没有真正的方法可以知道客户端注册请求是否来自官方应用商店中安装的应用。您可以在应用程序中存储一些秘密，但可以通过逆向工程找到它。这可能发生的唯一可能方式可能是应用商店本身提供的某种身份验证信息，但尚不存在。