为什么 Web 应用程序类型 'Android' 不能成为机密客户端？
Why can't web application type 'Android' be a confidential client?
使用授权流程并将信息传递到令牌请求的后台通道，我们不需要在应用程序中保存秘密。
为什么 Azure 会强制我们使用 public 类型？
无法将应用选择为 'web' 类型，因为 redirectUri 不允许是 'https://foo' 以外的任何其他类型，在我们的例子中是 'app://auth'
编辑：更多信息
在 Azure AD 上添加平台时，您目前可以选择
- 网络
- 温泉
- ios/macOS
- android
- 移动和桌面应用程序
所有这些都是 public 客户端，除了 'web' 可以保密，因为后端能够安全地存储秘密。我的问题是为什么 Web 和 android 应用程序之间存在差异？ android 应用程序将以与前端应用程序完全相同的方式进行通信。但是选择 android 应用程序是我可以为我的应用程序配置 redirectURL 的唯一方法
SPA 是 public 是可以理解的，但是强制每个移动应用程序是 public 是我不理解的事情
移动流量
这与网络客户端有一些不同。您打算在没有客户端密码的情况下使用授权代码流 (PKCE)，并通过 Chrome 自定义选项卡登录。请参阅 this Curity tutorial 了解它的外观。不过，请避免为移动客户端使用网络流程。
移动客户端机密
通过附加客户端密码的 API 路由请求不被认为是标准的，因为拥有您的客户端 ID 和重定向 URI 的攻击者仍然可以在 app:/auth 上触发流程。
如果需要移动客户端密码，则建议确保每个设备使用不同的客户端密码。这可以使用 Mobile DCR 来完成。不过，我认为 Azure 不支持此功能。
HTTPS 重定向 URI
如果您不知道，Android 需要应用程序链接才能让移动应用程序接收 HTTPS 重定向 URI 上的授权响应。我很确定 Azure 会支持这一点，这是最佳实践，因为攻击者无法获得响应。在我的 blog post 中有更多相关信息。
Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.
听起来你和一个更新的 Client-Initiated Backchannel Authentication Flow 有关系。 Azure 可能还不支持此流程。
Why then does Azure force us to use a public type?
机密客户端 和 public 客户端 条款源于 OAuth 2。
机密客户端 是能够保护其客户端机密的应用程序。例如。后端应用程序，例如Java、Node.js 或类似的。
A public 客户端 是一个无法保护秘密的应用程序 - 或者存在许多唯一实例的应用程序。例如。 Java编写单页应用程序或移动应用程序的脚本 - 这是可以在任何客户端中提取秘密的地方。现在使用 Public 客户端时通常使用 Proof Key for Public Exchange。
另见 What's the difference between Confidential and Public clients? - OAuth in Five Minutes。
“OAuth 客户端”是与授权服务器对话的应用程序。在您的情况下，您没有移动客户端，因为它实际上是与授权服务器通信的后端。永远不应将移动客户端配置为机密。 Azure 无法假定所有开发人员都会像您一样体贴周到并且不会hard-code他们应用程序中的秘密。
正如@Gary Archer 指出的那样，您应该将您的客户端配置为 Web 机密客户端，并使用 HTTPS 重定向 uris 作为 Android 应用程序 Link 以返回到您的应用程序。
使用授权流程并将信息传递到令牌请求的后台通道，我们不需要在应用程序中保存秘密。
为什么 Azure 会强制我们使用 public 类型？
无法将应用选择为 'web' 类型，因为 redirectUri 不允许是 'https://foo' 以外的任何其他类型，在我们的例子中是 'app://auth'
编辑：更多信息
在 Azure AD 上添加平台时，您目前可以选择
- 网络
- 温泉
- ios/macOS
- android
- 移动和桌面应用程序
所有这些都是 public 客户端，除了 'web' 可以保密，因为后端能够安全地存储秘密。我的问题是为什么 Web 和 android 应用程序之间存在差异？ android 应用程序将以与前端应用程序完全相同的方式进行通信。但是选择 android 应用程序是我可以为我的应用程序配置 redirectURL 的唯一方法
SPA 是 public 是可以理解的，但是强制每个移动应用程序是 public 是我不理解的事情
移动流量
这与网络客户端有一些不同。您打算在没有客户端密码的情况下使用授权代码流 (PKCE)，并通过 Chrome 自定义选项卡登录。请参阅 this Curity tutorial 了解它的外观。不过，请避免为移动客户端使用网络流程。
移动客户端机密
通过附加客户端密码的 API 路由请求不被认为是标准的，因为拥有您的客户端 ID 和重定向 URI 的攻击者仍然可以在 app:/auth 上触发流程。
如果需要移动客户端密码，则建议确保每个设备使用不同的客户端密码。这可以使用 Mobile DCR 来完成。不过，我认为 Azure 不支持此功能。
HTTPS 重定向 URI
如果您不知道，Android 需要应用程序链接才能让移动应用程序接收 HTTPS 重定向 URI 上的授权响应。我很确定 Azure 会支持这一点，这是最佳实践，因为攻击者无法获得响应。在我的 blog post 中有更多相关信息。
Using authorization flow and passing the information to the back-channel for the token request we don't need to save the secret in the app.
听起来你和一个更新的 Client-Initiated Backchannel Authentication Flow 有关系。 Azure 可能还不支持此流程。
Why then does Azure force us to use a public type?
机密客户端 和 public 客户端 条款源于 OAuth 2。
机密客户端 是能够保护其客户端机密的应用程序。例如。后端应用程序，例如Java、Node.js 或类似的。
A public 客户端 是一个无法保护秘密的应用程序 - 或者存在许多唯一实例的应用程序。例如。 Java编写单页应用程序或移动应用程序的脚本 - 这是可以在任何客户端中提取秘密的地方。现在使用 Public 客户端时通常使用 Proof Key for Public Exchange。
另见 What's the difference between Confidential and Public clients? - OAuth in Five Minutes。
“OAuth 客户端”是与授权服务器对话的应用程序。在您的情况下，您没有移动客户端，因为它实际上是与授权服务器通信的后端。永远不应将移动客户端配置为机密。 Azure 无法假定所有开发人员都会像您一样体贴周到并且不会hard-code他们应用程序中的秘密。
正如@Gary Archer 指出的那样，您应该将您的客户端配置为 Web 机密客户端，并使用 HTTPS 重定向 uris 作为 Android 应用程序 Link 以返回到您的应用程序。