在已经存在的服务器应用程序上执行客户端的 OAuth fat 任务。问题是客户端只有在某个系统注册后才能连接到服务器，不仅要指定连接地址，还要指定客户端端口。
那是
- 管理员注册客户端地址和端口（例如，localhost:12346）
- 客户端在 localhost:12346 上运行轻量级 http 服务器
- 然后客户端向服务器发送请求，请求中的参数为redirectUri=localhost:12346
- 服务器执行它需要做的事情，检查注册并将重定向发送到指定的 localhost:12346
- 客户端读取它需要的内容，关闭 Web 服务器并继续工作。
这样一个简单的回调服务器，用于在系统中实现 OAuth。这里的问题是，事实证明，您需要在所有客户端上硬编码某个端口。客户端预装软件未知。尝试在客户端上运行该端口时，无法保证该端口是空闲的。
那么问题来了，有没有专门为这种临时连接设计的端口池呢？
到目前为止，我倾向于在iana中保留一个动态端口- 即 49152 - 65535 之间的某个值，但我仍然不知道如何选择正确的端口。为了降低风险，可以为每个应用程序指定最多 4 个端口，但您需要选择在任何客户端上同时被占用的概率最小的那些端口。
使用嵌入式浏览器
如果可以使用内置浏览器（CefSharp形式的WebKit，或者至少是WebBrowser Control），那么就不需要监听端口了。该代码作为 GET 参数返回，并且可以在重定向时直接从 URL 中检索。
在这种情况下，您应该指定 urn:ietf:wg:oauth:2.0:oob 或 urn:ietf:wg:oauth:2.0:oob:auto 形式的返回 URL 而不是 localhost:port - 这就是例如，AzureAD 的标准客户端就是这样，它们通常在桌面上与谷歌集成。
主要缺点是内置浏览器要么已经过时（WebBrowser），要么重量很大（WebKit）。
使用系统浏览器+自定义方案
在注册表中，您可以注册一个自定义url 方案 (mysuperscheme://)，它将导航到您的应用程序。这就是 Slack 登录的完成方式。缺点之一 - 将启动一个新实例，并且必须手动组织它们之间的交互。此外，一些浏览器在使用自定义方案启动应用程序时会要求确认。
共享端口 80
标准System.Net.HttpListener允许多个应用程序与 IIS 同时侦听端口 80。您可以选择一个相当独特的 URL 前缀 - 并且很有可能同时解决端口可预测性问题和防火墙可预测性问题。缺点 - 所有内容都可以由 / 上的一个站点或某种 Skype 一次占用。
我很幸运
尝试只调查你的同事（突然有人已经实施了这样的方案）并从端口池中丢弃他们绑定的那些端口。如果可能，从目标机器收集开放端口的统计信息。然后选择 4 个不同的端口，希望你能走运。作为附加 措施，如果您的应用程序被挤到角落 - 反击并提出关闭竞争应用程序。