我们目前正在开发一个原生移动应用程序，我们需要使用我们的身份服务器（使用 thinktecture 身份服务器 v3 制作）和/或外部社交身份提供商对最终用户进行身份验证，消耗我们系统中的一些资源。
我们正在尝试使用 OIDC 来获取访问令牌和 id 令牌。在理想情况下，我们希望本机移动应用程序最终用户无限期保持登录状态（即使在本机应用程序重新启动期间），直到最终用户决定注销。
因此，首先，我们选择了隐式流。但我们发现刷新令牌在此流中不可用。
1. 为什么隐式流规范禁止刷新令牌？ 危险？
2. 换句话说，为什么令牌端点不能通过隐式流"到达"？
然后，我们测试了混合流以获取刷新令牌（非常非常长但可撤销）和访问令牌（短期生存期）。问题是将client_secret嵌入到本机公共客户端中。（OIDC 规范所述的不良和不安全做法）
3）所以...本机公共应用无法使用混合流...哼？
因此，我们目前想知道自定义代码流解决方案是否是一个好主意：创建一个"代理"/"前端"Web API，该 API 可以使用自己的安全client_secret到达令牌端点因此，将代码/refresh_token/access_token请求从本机客户端应用程序中继到授权服务器令牌终结点？
自定义代码流图片
4） 对此有何评论？
OAuth 2.0 隐式授权主要是针对无法保留客户端机密的浏览器内客户端的授权代码授权进行优化，因此可以假设这些客户端也无法将刷新令牌保密，至少在重新启动时是这样，因为挑战是相同的。
您可以使用授权代码授予并将您的本机移动应用程序注册为公共客户端，即它没有客户端密码，只有注册的redirect_uri。
令牌与用户登录没有任何关系，也不用于刷新用户登录状态。只能使用它来获取新的访问令牌，以代表用户使用/执行操作。 在最初收到id_token后，您可以决定将用户永久登录视为仅应用内的决定，与授权服务器（AS）或任何令牌（access_token/refresh_token/id_token）的用户状态无关。如果要考虑 AS 的登录状态，可以发送带有 prompt=none 参数的授权请求，并检查授权响应中的id_token或错误。