在线应用程序是否需要刷新令牌

4 回答

• 2

  不，如果用户总是出现在应用程序中，则无需使用刷新令牌 . 推理主要是OP描述的 .

  但是有理由可能仍然需要刷新令牌：

  • 作为OP提到用户可能会看到一些重定向，并且你的团队中的UI专家和品牌人都会讨厌这个

  • 当访问令牌在HTML表单POST操作过程中到期时，重定向可能在返回时丢失了上下文/ POST数据;您可能希望最小化此操作，或者您必须采取适当的（复杂的）POST数据保存操作

  • 如果您的访问令牌到期时间很短，重定向会产生大量开销和麻烦;在处理不同域中的提供商时，您可能无法控制访问令牌到期，并且在与多个提供商打交道时，它们会因它们而异

  • 使用重定向刷新访问令牌时，您的应用程序现在取决于提供者保持SSO会话;并非所有提供商都可以这样做，如果他们这样做，他们可能会以不同的方式进行：SSO会话持续时间可能会有所不同，并且身份验证方法可能会有所不同;例如：不保留SSO会话但使用双因素身份验证的提供商将对用户体验产生巨大影响

  想象一下，您希望使用访问令牌几乎实时地从用户信息 endpoints 更新用户信息，但访问令牌到期时间相对较短 . 您要么必须执行大量的重定向，如上所述，或者您可以使用刷新令牌 .

  回复于 2024-05-10T10:23:32+08:00
• 6

  使用在线应用程序的刷新令牌时，我最担心的是它会从用户那里夺走 transparency .

  刷新令牌有助于长期访问，应安全存储 . 但它们也没有为"sign out"提供一种自然的方式，并且（最重要的是）它变得完全不透明，如何，何时以及从何处访问您的数据，正如经常使用的范围名称 offline_access 所暗示的那样 .

  OIDC提供了一个前端通道机制 prompt=none ，它可以在很大程度上产生相同的效果（即新的令牌），如果在iframe内部执行重新认证，则不需要中间重定向 .

  因此，在我看来，你和谷歌是正确的，答案必须是：不，如果用户在场，不要使用刷新令牌 .

  回复于 2024-05-10T10:23:32+08:00
• 5

  刷新令牌必须是凭据引用，当没有活动用户会话时，客户端可以交换访问令牌 . 例如，如果您想定期将Github中的问题与您的内部系统同步 .

  它经常被滥用，就像某种会话一样 . 将这些事情区分开来是必不可少的 . 范围名称offline_access是有原因的 .

  因此，在简单的情况下 - 您只需依赖OP会话并获取具有授权/令牌 endpoints 组合的新令牌 . 不应该提示您只要会话处于活动状态并且同意该特定应用程序，就会提供凭据 .

  如果你需要做一些背景 - 请求刷新令牌 .

  至于问题：没有 .

  编辑（更深入的解释）：如果我们谈论网络有两个主要案例：客户端可以安全地存储秘密，如通常的Web应用程序与服务器页面呈现和客户端，不能存储机密，如SPA应用程序 . 从这个角度来看，有两个主要流程（省略混合而不是过于复杂）：授权代码流和隐式流 .

  Authorization Code Flow
  在第一次请求时，您的应用程序会检查它自己的会话（客户端会话），如果没有，则重定向到外部OP（OpenID Connect提供程序）授权URL . OP根据请求中表达的要求对用户进行身份验证，收集同意和其他内容并返回授权码 . 然后，客户端向其请求令牌 endpoints ，并在用户授予脱机访问许可的情况下，使用可选的刷新令牌接收access_token / id_token对 . 这很重要，因为用户可以拒绝您的应用 . 此客户端可以请求userInfo endpoints 获取在同意期间授予的所有用户声明 . 这些声明代表用户身份，并且不包含诸如身份验证方法，acr等内容 . 例如，id_token中出现的声明与expiration一起出现 . 在该客户端启动它自己的会话之后，可以选择将其生命周期设置为等于id_token生命周期，或者使用它自己来提供平滑的用户体验 . 此时，如果您不需要访问其他API（例如，access_token中的所有范围都特定于OP和主题），您可以完全丢弃access_token和id_token . 如果您需要访问某些API，则可以存储access_token并将其用于访问 . 它变得无效 - 重定向到新的OP . 由于服务器上的安全环境更加安全，因此过期可能会更加宽松 . 所以即便是1小时也是一种选择 . 根本没有使用刷新令牌 .

  Implicit Flow
  在这种情况下，您可以说Angular app重定向到OP，直接从授权 endpoints 获取其id_token和可选的access_token，并使用它来访问某些API . 在每个请求到期时检查是否需要，客户端向隐藏的iFrame中的OP发送请求，因此只要OP会话处于活动状态，就不会有任何可见的重定向 . 有一些很棒的库，比如openid-client.js . 这里根本不允许刷新 .

  将客户端会话与OP会话，令牌生存期和会话生存期区分开来非常重要 .

  为满足某些特定需求，有Hybrid Flow . 它可用于在一个请求中为您的会话获取授权代码和id_token . 没有通过网络聊天 .

  因此，当您考虑刷新令牌时，只需检查您的需求并将它们映射到规范:)如果您仍然需要它 - 尽可能安全地存储它 .

  回复于 2024-05-10T10:23:32+08:00
• 1

  刷新令牌对于在服务器会话中保持访问令牌的应用程序非常有用 . 例如，如果Web应用程序未使用JavaScript XHR调用受保护的服务，但调用其后端并且后端调用该服务 . 在这种情况下，无论何时需要获取新的访问令牌比向用户请求新的令牌更容易 .

  在浏览器中运行的JavaScript应用程序中，无法使用刷新令牌，因为您需要一个客户机密钥才能从 /token endpoints 获取访问令牌，并且您无法在此类应用程序中保密 .

  获取您描述的新访问令牌的过程可以得到改进 - 应用程序可能会在当前版本到期之前请求新的访问令牌，因此用户不会被重定向到OAuth2服务器，但应用程序会调用 /auth endpoints iframe中的 prompt=none 参数 .

  回复于 2024-05-10T10:23:32+08:00