在已经存在的服务器应用程序上执行客户端的 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 个不同的端口,希望你能走运。作为附加 措施,如果您的应用程序被挤到角落 - 反击并提出关闭竞争应用程序。