我们目前正在开发本机移动应用程序，我们需要使用我们的身份服务器（使用thinktecture身份服务器v3制作）和/或外部社交身份提供程序对最终用户进行身份验证， 消耗我们系统中的一些资源。
我们正在尝试使用OIDC来获取访问令牌和ID令牌。 在一个完美的世界中，我们希望本机移动应用程序最终用户无限期地（甚至跨本机应用程序重新启动），直到最终用户决定注销。
首先，我们选择了隐式流程。 但我们发现此流程中没有刷新令牌。
1。为什么隐式流规格禁止刷新令牌？哪里是 危险？
2。换句话说，为什么令牌端点不具有隐式流“可达”？
然后，我们测试了混合流以获得刷新令牌（非常长寿但可撤销）和访问令牌（短期）。 问题是将client_secret嵌入到本机公共客户端中。 （OIDC规范描述的不良和不安全的做法）
3）所以...本机公共应用程序不能使用混合流...嗯？
因此，我们目前想知道自定义代码流解决方案是否是一个好主意： 制作一个“代理”/“前端”web api，可以使用自己的安全client_secret到达令牌端点 那么，将来自本机客户端应用程序的code / refresh_token / access_token请求中继到授权服务器令牌端点？
4）对此有何评论？
答案 0 :(得分：7)
OAuth 2.0隐式授权主要是针对无法保密客户端的浏览器内客户端的授权代码授权进行优化，因此可以假设这些客户端也无法保留刷新令牌秘密，至少在重新启动时，因为挑战是相同的。
您可以使用授权代码授权并将您的原生移动应用注册为公共客户端，即它不会有客户机密，只会注册redirect_uri。
请注意，刷新令牌与用户登录无关，也不用于刷新用户登录状态。您只能使用它来获取新的访问令牌以代表用户使用/操作。在初次收到id_token后，您可能决定将用户永远记录为仅限应用内的决定，与授权服务器（AS）或任何令牌（或用户）的用户状态无关（{ {1}} / access_token / refresh_token）。如果您想要考虑AS的登录状态，您可以发送带有id_token参数的授权请求，并检查授权响应中的id_token或错误。
