OAuth2隐含流是否总是三条腿？

Question

我正在使用OAuth2授权/身份验证设置网络服务。如果我理解正确，隐式流应该用于本机桌面应用程序，因为反编译和其他进程可能会暴露客户端的秘密。

隐式流程需要有效的重定向URI，但我不明白应该如何使用这些URI。我不通过Facebook应用程序或其他东西寻找三足认证，但是可以直接访问我自己的网络服务。就像Facebook和Twitter应用程序本身一样。

我的问题是：OAuth2隐式流程总是三条腿吗？如果是这样，Facebook和Twitter的应用程序如何确保客户机密不会泄露？如果他们 使用隐式流程，他们的重定向方案如何工作？

Answer 1

我今天也有同样的问题，也找不到任何答案或帖子。

所以到目前为止我发现了：

1）是的，隐式授权流程总是由两个/三个步骤组成（取决于您的计算方式）：

• 用户被重定向到授权页面;

• 用户确认他授予访问此应用的权限;

• 用户被重定向回消费者应用程序，访问令牌作为散列片段参数传递。

2）完全没有使用隐式授权流程的客户机密钥。无论如何它都没有意义 - 它将在明显的视线中。但是，仍然存在一些安全措施：隐式授权通常需要预先批准的重定向URL，因此只有指定的可信URL才能获得访问令牌。

3）是的，我也注意到即使Facebook / Twitter大量使用OAuth2，当您使用自己的Web应用程序时，您也不会看到这些步骤。我有几个怀疑：

• 他们可能根本不会将OAuth2用于自己的网络应用程序;

• 他们可以使用自己的，未记录的流程传递令牌;

• 他们可能会预先授权自己的应用，以便跳过授权步骤。

我个人为我的申请选择了后一种选择。我创建了一个不需要用户明确批准的内部应用程序列表。

Answer 2

Redirect-URI是必需的，因为服务提供商需要在登录/用户同意后重定向回您的应用程序。对于桌面应用程序，您可能会打开浏览器以获得登录/用户同意，并需要将授权代码或访问令牌重新发送回桌面应用程序。

基本上有3种方法可以做到这一点：Using OAuth 2 with desktop c# Application

Google很好地描述了有问题的和可用的选项： https://developers.google.com/accounts/docs/OAuth2InstalledApp