背景:我正在构建一个web应用程序,允许用户使用OAuth2.0集成多个服务,如Google、Twitter、Github等。
目前,我在登录时检索刷新令牌以服务,并将其存储在我的DB中。(在存储前加密)。(访问令牌在使用后被丢弃)。
应用程序托管在AWS上,尽管AWS上可用的服务数量非常多--我已经浏览过它们,并在写入DB之前选择了用于加密应用程序中的令牌的KMS。我研究了Secrets,但是定价不适合存储用户令牌。
问题我想知道是否有更好的方法来存储刷新令牌,而不是加密和存储在DB中。如果不是,在使用DB刷新令牌时,是否需要记住一些特定的事情来确保安全性?
发布于 2021-08-10 14:21:29
如果可以的话,我会把你的问题抽象成“我有一些需要存储的短而安全的东西--我能把它储存在哪里?”秘密经理和RDS都是存储小东西的合法场所。其他存储东西的地方包括:车载硬盘、Dynamo和S3存储桶。
您提到令牌被丢弃得很快--车载硬盘可能是存储这些短暂数据的好地方(但它不能扩展到多种用途!)
Dynamo Db非常快速,可以同时处理许多不同的AWS服务的读写--如果您有一种情况,即单个用户在几秒钟内将访问十几个不同的服务,那么并发性将是一个问题,Dynamo Db (也是RDS)将很好地处理这个问题。如果有很多微服务访问API并依赖访问令牌的情况,扩展将是一个需要考虑的问题,Dynamo将很好地处理这个问题。一定要在一段时间后删除旧的访问令牌。
S3可以很好地处理扩展--但是您需要为并发性构建架构。也就是说,对于访问令牌,您应该有一个特定的桶和“文件夹”(S3是键值,S3中的文件夹不是真实的),并且为每个用户都有一个单独的文件。一个文件将包含用户登录的每个访问令牌--然后在您的软件端,当不同的服务将要读写时,您必须避免读取和写入该文件。如果您很少从3-5服务中写入,那么避免并发性并不是一个大问题,但是如果您有几十个经常编写的服务(这就是为什么您应该为每个用户创建一个单独的文件),那么就很难处理。此外,当您完成旧的访问令牌时,一定要清除它们。
https://softwareengineering.stackexchange.com/questions/430700
复制相似问题