【问题标题】:Strategies for Refreshing OAuth token in a distributed application在分布式应用程序中刷新 OAuth 令牌的策略
【发布时间】:2015-06-08 15:38:12
【问题描述】:

我们有一个分布式 webapi 应用程序,它使用提供者颁发的 OAuth 令牌与 API 进行通信,它会持续特定的时间,

我们正在考虑将令牌存储在数据存储中并在调用 api 之前检索它,并让后台 windows 服务每隔 1 小时左右刷新一次令牌。

是否有关于如何在分布式应用程序中刷新令牌的成熟模式?

谢谢-嫩

【问题讨论】:

标签: c# oauth asp.net-web-api oauth2client


【解决方案1】:

我们开始实现一些非常相似的东西。我们正在查看Redis 缓存来存储令牌。这样,任何数量的分布式应用程序都可以根据需要获取或更新缓存。 Redis 也可以扩展和分布。这消除了对任何同步服务的需求,并且它具有非常简单的通信界面。如果任何客户端读取了过期的令牌,它负责将其从缓存中删除 (circuit breaker) 并通知身份验证服务。我们有一个负责添加缓存的身份验证服务。它可以刷新死令牌,或者如果我们不想自动刷新,则忽略通知。我们还没有完全发挥它的功能,但它运行良好。

【讨论】:

  • 几个问题:1) 假设前端是分布式的,假设我们有 2 或 3 个前端访问 Redis 以获取令牌,假设所有 3 个都获得了令牌及其过期了,谁来更新?这三个?
  • 所有 3 个都将获得过期的令牌,所有 3 个都会向 Redis 发出调用以删除旧令牌,并且所有 3 个都会向 auth 服务发送通知。我们使用 Azure 服务总线进行消息传递。现在客户有几个选择。他们可以在设定的时间内显示加载器,比如 2-3 秒,然后再次尝试缓存。如果身份验证服务刷新了令牌,它就会在那里。或者,客户端可以简单地清除它需要的任何状态并将用户重定向到身份验证服务。这更有可能。这类似于 MS 并将用户重定向到 login.live.com。
  • 由于 Redis 的这种使用是一个简单的键值对,任何删除不存在的键的请求都将被忽略。使用服务总线,我们会忽略重复消息,因此无需担心身份验证服务会尝试多次刷新同一个令牌。即使通过了额外的消息,额外的刷新也不会造成任何伤害。
  • 我最终也使用了 Redis。可能有更好的方法来做到这一点,但是如果正在刷新令牌,我会在 Redis 上设置一个锁定。问题仍然存在,即任务可能处于中间过程并且令牌已更新。在这种情况下,我设置了一个随机时间小于 5 秒的重试。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-09-25
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多