Open ID Connect 和本机公共应用程序......没有隐式流，没有混合流......那又如何？

Posted 2023-03-10

【中文标题】Open ID Connect 和本机公共应用程序......没有隐式流，没有混合流......那又如何？

【英文标题】：Open ID Connect and native public app...no implicit flow, no hybrid flow...so what?

【发布时间】：2015-03-13 00:13:03

【问题描述】：

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

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

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

1.为什么隐式流规范禁止刷新令牌？哪里是 危险？

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

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

3) 所以……原生公共应用不能使用混合流……嗯？

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

custom code flow picture

4) 有没有关于这个的 cmets ？

【问题讨论】：

这里提出并讨论了同样的问题：github.com/IdentityServer/Thinktecture.IdentityServer3/issues/…

【参考方案1】：

OAuth 2.0 隐式授权主要是为了对无法保持客户端机密的浏览器内客户端的授权代码授权进行优化，因此可以假设这些客户端也无法保持刷新令牌秘密，至少在重新启动后，因为挑战是相同的。

您可以使用授权码授权并将您的本机移动应用注册为公共客户端，即它没有客户端密码，只有注册的 redirect_uri。

请注意，刷新令牌与用户登录无关，它不用于刷新用户登录状态。您只能使用它来获取新的访问令牌以代表用户使用/操作。在最初收到id_token 后，您可以决定将用户永久登录视为仅限应用内的决定，与授权服务器 (AS) 或任何令牌 (access_token) 上的用户状态无关/refresh_token/id_token)。如果您想考虑 AS 的登录状态，您可以发送带有 prompt=none 参数的授权请求，并检查授权响应中的 id_token 或错误。