在获取访问令牌以代表用户执行 API 请求后，保持用户会话和令牌连接的“正确”方式是啥？

Posted 2023-03-10

【中文标题】在获取访问令牌以代表用户执行 API 请求后，保持用户会话和令牌连接的“正确”方式是啥？

【英文标题】：After fetching the access token to perform API requests on user's behalf, whats the "proper" way to keep the user session and token connected?在获取访问令牌以代表用户执行 API 请求后，保持用户会话和令牌连接的“正确”方式是什么？

【发布时间】：2020-01-26 22:26:41

【问题描述】：

我目前正在开发一个身份 4 服务器、一个受身份服务器上定义的范围保护的 API，以及将使用来自 API 的信息的移动应用服务器。

到目前为止，我已经很好地掌握了如何使用授权和访问令牌以及如何执行正确的流程，但是当我开始查看移动应用程序和服务器之间的用户会话时，我陷入了两难境地。在收到访问和身份令牌后，它基本上用作用户登录/授权的确认，这将是存储它并使会话与应用程序保持活动状态的“正确”方式？

最初我想使用 cookie，但被告知它不适用于移动应用程序（我对 android/ios 几乎一无所知），随后我考虑在服务器上创建 JWT，这似乎考虑到已经产生令牌的身份服务器的存在是错误的。有了这个，我如何将会话与访问令牌相关联以执行 API 请求？

TLDR：

为客户端获取访问权和 id 令牌后，什么是“正确的” 有什么方法可以让客户端和移动应用之间的会话保持活跃？ 当需要 API 请求时，如何将会话与访问令牌相关联？

谢谢！

【问题讨论】：

您的移动应用是“原生”应用，还是托管在浏览器外壳中的网络应用？

此应用是原生应用，但我们将其视为第三方应用/服务器来访问受保护的 API，因为这将是最终目标。

所以你在任何地方都不需要 cookie。

【参考方案1】：

对于现代原生移动应用程序，我建议将授权代码流（通过设备上的默认浏览器）与 PKCE 一起使用，并将刷新令牌存储在设备的安全飞地中。这可以通过内置的 PIN 或生物特征来保护。

使用该（经过仔细保护的）刷新令牌，您可以维持长期会话，而无需与 OIDC 服务进行前端通道（即 Web 浏览器）交互。

【讨论】：

所以，如果我理解正确，我将授权代码保存在服务器中（我从中获取访问代码），并将刷新令牌传递到设备上并将其存储在那里受保护。使用设备上的刷新令牌，无需用户输入（建议的 pin 除外）就可以重新建立会话，并且会话具有访问 API 的令牌。但是我仍然有一个问题：发送刷新令牌以重新建立会话后，我如何让它保持活动状态，一个短暂的 cookie？还是我使用刷新创建的令牌与服务器通信？

您将使用通过刷新令牌获得的访问令牌与您的后端进行通信。当它过期时，您可以使用刷新令牌来获取新令牌，而无需任何用户交互。实际上，参考令牌是您的“会话”，IDP 上根本没有经过 cookie 身份验证的会话。

抱歉回复晚了，我想我明白了正确的做法！谢谢！！