3

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

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

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

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

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

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

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

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

自定义代码流程图

4) 对此有何评论？

4

1 回答 1

7

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

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

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

于 2015-01-14T22:43:53.483 回答