javascript - 移动设备隐式流上的静默刷新令牌

为了支持多种类型的本机应用程序，您的服务器将需要支持注册三种类型的重定向 URL，每种类型都支持略有不同的用例。

自定义 URL 方案

某些平台（例如 iOS）允许应用注册自定义 URL 方案，该方案将在浏览器或其他应用中打开具有该方案的 URL 时启动应用。使用自定义 URL 方案支持重定向 URL 允许客户端启动外部浏览器以完成授权流程，然后在授权完成后重定向回应用程序。

应用程序开发人员应该选择一个全球唯一的 URL 方案，并且他们可以断言对其进行控制。由于操作系统通常没有特定应用程序是否声明了 URL 方案的注册表，因此理论上两个应用程序可以独立选择相同的方案，例如 myapp://。如果您想帮助防止应用程序开发人员使用自定义方案发生冲突，您应该建议（甚至强制）他们使用一种方案，该方案是他们控制的域的反向域名模式。至少，您可以要求重定向 URL 至少包含一个 . 以免与mailto或ftp等其他系统方案发生冲突。

例如，如果一个应用程序有一个名为 photoprintr.example.org 的相应网站，则可用作其 URL 方案的反向域名将是 org.example.photoprintr。开发者注册的重定向 URL 将以 org.example.photoprintr:// 开头。通过强制执行此操作，您可以帮助鼓励开发人员选择不会与其他已安装应用程序冲突的显式 URL 方案。

使用自定义 URL 方案的应用程序将正常启动授权请求，如授权请求中所述，但将提供具有其自定义 URL 方案的重定向 URL。授权服务器仍应验证此 URL 之前是否已注册为允许的重定向 URL，并且可以将其视为 Web 应用程序注册的任何其他重定向 URL。

当授权服务器将本机应用程序重定向到具有自定义方案的 URL 时，操作系统将启动该应用程序并使整个重定向 URL 可供原始应用程序访问。该应用程序可以像普通的 OAuth 2.0 客户端一样提取授权码。

HTTPS URL 匹配

某些平台允许应用程序注册 URL 模式，指示应用程序应在系统浏览器访问与注册模式匹配的 URL 时启动。这通常被应用程序用于“深度链接”到本机应用程序，例如在浏览器中查看 Yelp URL 时打开餐厅页面的 Yelp 应用程序。

应用程序也可以使用此技术来注册 URL 模式，该模式将在授权服务器重定向回应用程序时启动应用程序。如果平台提供此功能，这是本机应用程序的推荐选择，因为这提供了应用程序属于它匹配的 URL 的最大完整性。在平台不支持应用声明的 URL 的情况下，这也提供了合理的回退。

环回 URL

本机应用程序可用于支持无缝重定向的另一种技术是在环回接口的随机端口上打开一个新的 HTTP 服务器。这通常仅在桌面操作系统上完成，因为移动操作系统通常不向应用程序开发人员提供此功能。

这种方法适用于命令行应用程序以及桌面 GUI 应用程序。该应用程序将启动 HTTP 服务器，然后开始授权请求，将重定向 URL 设置为环回地址，例如http://127.0.0.1:49152/redirect并启动浏览器。当授权服务器将浏览器重定向回环回地址时，应用程序可以从请求中获取授权码。

为了支持这个用例，授权服务器必须支持注册以http://127.0.0.1:[port]/和http://::1:[port]/和http:/开头的重定向 URL /localhost:[端口]/。授权服务器应该允许任意路径组件以及任意端口号。请注意，在这种情况下，使用 HTTP 方案而不是 HTTPS 是可以接受的，因为请求永远不会离开设备。

登记

与服务器端应用程序一样，本机应用程序也必须向授权服务器注册其重定向 URL。这意味着除了服务器端应用程序的传统 HTTPS URL 之外，授权服务器还需要允许与上述所有模式匹配的已注册重定向 URL。

当授权服务器发起授权请求时，服务器将验证所有请求参数，包括给定的重定向 URL。授权应拒绝请求中无法识别的 URL，以帮助避免授权代码拦截攻击。

参考：https ://www.oauth.com/oauth2-servers/oauth-native-apps/redirect-urls-for-native-apps/

javascript - 移动设备隐式流上的静默刷新令牌

问题描述

解决方案

自定义 URL 方案

HTTPS URL 匹配

环回 URL

登记

推荐阅读