Oauth 2.0 开放ID连接和本机公共应用程序…没有隐式流，没有混合流…那又怎样？

我们目前正在开发一个本地移动应用程序，我们需要使用我们的身份服务器（由thinktecture identity server v3制作）和/或外部社交身份提供商对最终用户进行身份验证， 消耗系统中的一些资源

我们正在尝试使用OIDC获取访问令牌和id令牌。 在一个完美的世界中，我们希望本地移动应用程序最终用户在最终用户决定注销之前保持无限期登录状态（即使在本地应用程序重新启动时）

首先，我们选择隐式流。 但我们发现刷新令牌在此流中不可用

1。为什么隐式流规范禁止刷新令牌？火车在哪里 危险？

2。换句话说，为什么令牌端点不能通过隐式流“到达”？

然后，我们测试了混合流以获得刷新令牌（非常长但可撤销）和访问令牌（短期）。 问题是将客户机密钥嵌入到本机公共客户机中。（OIDC规范中描述的不良和不安全做法）

3）那么……本机公共应用程序不能使用混合流……嗯？

因此，我们目前想知道定制代码流解决方案是否是一个好主意： 制作一个“代理”/“前端”web api，该api可以使用他自己的安全客户端\u secret到达令牌端点 因此，将来自本机客户端应用程序的代码/刷新令牌/访问令牌请求中继到授权服务器令牌端点

---

4）对此有何评论？

OAuth 2.0隐式授权主要是针对无法为客户端保密的浏览器内客户端的授权码授权进行优化，因此可以假设这些客户端也无法为刷新令牌保密，至少在重新启动时是如此，因为挑战是一样的

您可以使用授权码授权并将您的本机移动应用注册为公共客户端，即它没有客户端密码，只有注册的重定向\u uri

---

请注意，刷新令牌与用户登录无关，它不用于刷新用户登录状态。您只能使用它来获取新的访问令牌以代表用户使用/行动。您可以决定将用户永远记录为仅在最初接收到“代码> IDID令牌< /代码>之后，与用户在授权服务器（AS）或任何令牌中的状态无关（<代码> Access令牌< /代码> /<代码> PrimHythGooTe>代码> >代码ID>令牌< /代码>。如果您想考虑AS的登录状态，可以使用

提示符=none

参数发送授权请求，并检查授权响应中的id_标记或错误。

此处提出并讨论了相同的问题：