我们目前正在开发一个 native 移动应用程序，我们需要使用我们的身份服务器(使用 thinktecture 身份服务器 v3 制作)和/或外部社交身份提供商对最终用户进行身份验证， 消耗我们系统中的一些资源。
我们正在尝试使用 OIDC 来获取访问 token 和 ID token 。 在完美的世界中，我们希望 native 移动应用程序最终用户无限期地保持登录状态(即使 native 应用程序重新启动)，直到最终用户决定注销。
首先，我们选择了隐式流。 但我们发现刷新 token 在此流程中不可用。
<强>1。为什么隐式流规范禁止刷新 token ？哪儿是 危险？
<强>2。换句话说，为什么 token 端点无法通过隐式流“可达”？
然后，我们测试了混合流来获取刷新 token (非常非常长，但可撤销)和访问 token (短期)。 问题是将 client_secret 嵌入到 native 公共(public)客户端中。 (OIDC 规范中描述的不良且不安全的做法)
3)那么……原生公共(public)应用程序无法使用混合流……嗯？
因此，我们目前想知道自定义代码流解决方案是否是一个好主意: 创建一个“代理”/“前端”Web api，可以使用自己的安全 client_secret 到达 token 端点 因此，将 code/refresh_token/access_token 请求从 native 客户端应用程序中继到授权服务器 token 端点？
4)对此有何评论？
最佳答案
OAuth 2.0 隐式授权主要是为了对无法保守客户端 secret 的浏览器内客户端的授权代码授权进行优化，因此可以假设这些客户端也无法保留刷新 token secret ，至少在重新启动时是这样，因为挑战是相同的。
您可以使用授权代码授予并将您的 native 移动应用注册为公共(public)客户端，即它没有客户端 key ，只有注册的 redirect_uri。
请注意，刷新 token 与用户登录没有任何关系，也不用于刷新用户登录状态。您只能使用它来获取新的访问 token 以代表用户使用/操作。在初次收到 id_token 后，您可以决定将用户永久登录视为仅在应用程序内做出的决定，与授权服务器 (AS) 或任何授权服务器上的用户状态无关。 token (access_token/refresh_token/id_token)。如果您想考虑 AS 的登录状态，您可以发送带有 prompt=none 参数的授权请求，并检查授权响应中的 id_token 或错误。
关于oauth-2.0 - 开放 ID Connect 和 native 公共(public)应用程序...没有隐式流程，没有混合流程...那又怎样？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27949250/