【发布时间】:2019-08-24 16:54:48
【问题描述】:
我们正在考虑下一个应用的架构,但在 api 之间传递令牌时遇到了问题。我们将拥有:
- 前面 -->(调用)自己的登录 api(如果一切正常,我们创建一个自己的令牌,命名为 ownToken)-->(调用)第三方 api --> 返回一个 JWT 令牌(命名为 1token)- ->
一切正常后:
- 前面 --> 用户做一些任务-->(With ownToken Call to) 自己的业务 api (如果 ownToken ok, do some stuff)--> (with the 1token Call to) 第三方api (return some stuff ) --> 向用户显示信息。
我们希望避免每次从该 api 获取信息时调用第三方 api,但我们也不想向用户显示该 JWT(我的意思是 localstorage、sessionstorage...)。
更多信息,我们将使用c#语言和sql server作为数据库。
我们的问题:
如何在 API 之间维护 1token?
【问题讨论】:
-
"我们希望避免每次我们想要从该 api 获取信息时调用第三方 api"...也许您可以缓存数据,如果它不经常更改,或者将其复制到你自己的数据库。目前还不清楚这与“你如何在 API 之间维护 1token?”有什么关系?尽管?通常访问令牌会在一段时间后过期,因此您可以将它存储在您的数据库中,直到它过期,但您通常应该从其他 API 获取刷新令牌,您可以使用更长时间,以获取新的访问令牌。或者它可能支持带有客户端密码的流,因此不需要重新验证
-
我不能完全弄清楚你在担心什么,但如果你希望用户可以直接从前端应用程序调用第 3 方 API(我猜它是浏览器或应用程序?),这样数据就不会每次都通过您的服务器,那么第 3 方 API 必须能够信任前端应用程序。因此,要么用户必须自己直接使用该 API 进行身份验证,要么您必须使用您在服务器上生成的令牌信任该应用程序 - 正如您正确指出的那样,这可能是有风险的。也许您可以准确地澄清您对数据和令牌的关注点?
-
首先感谢您的回答。 @ADyson 无法缓存该信息,关系是我们需要 1token 才能从第三方 api 的每次调用中获取信息。是的,存储在数据库中是我们想到的第一个选项,但我们想知道是否还有其他选项。问题是我们不希望任何人从我们的应用程序中访问该 1token。
-
好吧,如果您正确地保护了您的数据库和服务器,就不会有这种危险。但是,无论您在令牌的生命周期中将令牌存储在何处,都需要对其进行保护。数据库是一个非常合理的选择,因为大多数数据库都具有很好的安全功能,并且您的 API(如果它是唯一可以直接访问数据库的应用程序)也可以提供帮助。如果您将令牌存储在文件中,则必须改为控制对文件的访问。如果您的 API 不是完全无状态的,并且会话持续时间足够长,您可以将其存储在内存中的会话中