移动身份验证方法、JWT 和刷新令牌

Question

上下文

我正在与我的开发团队一起开发客户端-服务器架构中的移动应用程序，因为也会有一个 web 客户端，允许一些用户（管理员）从浏览器执行某些操作。

REST Api 目前通过以 JWT 的形式返回访问和刷新令牌来对用户进行身份验证。本地（用户名/密码）和 OAuth2.0（目前只有 Google）流程都可用，因为我为用户提供了这两种不同的身份验证选项。

问题

当从 webclient 调用 API 时，接下来的流程工作得很好，但是现在我们已经开始开发移动应用程序，出现了一个大问题：**如何在刷新后保持用户在移动应用程序上的身份验证令牌过期了？**

所有著名的应用程序都不会提示用户进行身份验证，比如说每周或最糟糕的每天，但我仍然确信他们的身份验证实践（几乎）完美无缺。

尝试过的路径

我已经阅读了许多博客文章和文章，以及下面报道的一些 StackExchange 问答，但在移动设备上处理身份验证和访问持久性的正确方法仍不清楚。

• 我是否应该创建一个（或多个）特定端点以仅在 User-Agent 标头告诉 API 正在被移动设备调用时提供不会过期的令牌？

• 如JWT (JSON Web Token) automatic prolongation of expiration 中所述，Auth0 放弃了移动端的 JWT，转而使用随机生成的字符串。在这种情况下有哪些可用的实现？我应该将此字符串用作已验证设备的永无止境的 id 并批准所有附加它的 API 调用吗？

• 在 OAuth 情况下，我是否应该（我不知道如何）对 OAuth 提供者执行静默调用以取回新的 idToken，然后使用它向我自己的 API 请求新令牌？

• 在本地情况下，我应该将用户凭据存储在本地吗？如果是这样，我该如何安全地做到这一点？

咨询资源

• What's the right OAuth 2.0 flow for a mobile app
• JWT refresh token flow
• Authenticating a mobile application with JWT and refresh tokens
• https://softwareengineering.stackexchange.com/questions/318471/jwt-refresh-token-exponentially
• https://auth0.com/docs/best-practices/mobile-device-login-flow-best-practices
• https://auth0.com/blog/refresh-tokens-what-are-they-and-when-to-use-them/
• https://mobile-security.gitbook.io/mobile-security-testing-guide/general-mobile-app-testing-guide/0x04e-testing-authentication-and-session-management
• https://tech.justeattakeaway.com/2019/12/04/lessons-learned-from-handling-jwt-on-mobile/（更专注于改进已经建立的架构）

...还有更多我没有报告超出问题的范围。

这个问题最初发布在这里，https://softwareengineering.stackexchange.com/questions/430302/mobile-authentication-approaches-jwts-and-refresh-tokens/430315#430315

一些图表

这些是我们当前实现的流程，当 API 被 web 客户端使用时，它们会按预期工作。

本地

---

OAuth2.0

Answer 1

我认为该要求的格式不完善，感觉它是基于产品所有者的全面陈述，没有考虑成本与收益：

• Gmail 让我永远保持登录状态，我希望我的应用能够像这样工作

大型供应商

Google 之类的公司经常使用定制解决方案来分析用户模式，定期获得 2 因素确认和其他对普通公司来说非常昂贵的操作。

OAUTH

对于普通软件公司，问题已通过 OAuth 和 AppAuth 模式解决。 Curity Guides 如果您不熟悉它，请提供一个很好的起点：

• 编码后，您可以使用多种身份验证选项，而您的 UI 和 API 中的代码更改为零
• 支持用户友好的无密码选项，例如 WebAuthn
• 如果需要，您甚至可以支持高级选项，例如 App2App Logins
• 移动代码和架构在所有情况下都保持简单

用户同意

另请注意，OAuth 是围绕用户在一段时间内使用其详细信息同意应用而构建的。我经常停下来想如果我在滥用这个 - 如果用户的设备被盗会有什么影响 - 不确定这对你的场景有多相关......

中间地带

对于大多数公司，我会推荐这种类型的选项，以便更好地使用：

• 从用户友好的选项开始，例如 30 天刷新令牌
• 如果您使用密码登录，请确保密码自动填充有效 - AppAuth 将启用此功能

代币

这些是由非您开发的授权服务器 (AS) 发布的。将其视为提供 HTTPS 端点的 Docker 容器 - 使用免费或低成本的。

您提到的 Auth0 点背后的动机在 this article 中有很好的解释。移动应用程序只是将访问令牌发送到 API。您的代码中没有令牌发行，它仍然很简单。

摘要

首选经过行业标准验证且成本效益好的选项。 OAuth 具有高度的架构性，并且您的公司需要管理一个学习曲线。