OAuth 2.0在哪里安全存储访问令牌以供长期使用

Question

我正在使用使用OAuth 2.0的API.它的流程是这样的:

一切都适合我,一切都很好,但我不明白的是如何处理给定的访问令牌,以便已经授权访问您的应用程序的用户不必再次访问.等几天后他回到应用程序.它提供了糟糕的用户体验(没有人想要一次又一次地授予访问权限).

注意:我正在使用Quizlet API

Answer 1

首先,访问令牌应该是短暂的.认为它等于短期一次性凭证.如果您不相信,请检查此处链接的" Azure AD令牌生存时间定义""可配置令牌生存期属性".

建议使用定义短期访问令牌,例如在1小时后过期.这样你就可以避免存储它们的复杂性.您只需将它们保存在内存中并使用它们来访问受保护的资源.

我不明白的是如何处理给定的访问令牌,以便已经授权访问您的应用程序的用户不必再次访问.等几天后他回到应用程序.

好吧,在这里你应该谈论刷新令牌.根据OAuth 2.0规范,它的刷新令牌具有更长的使用寿命.如果您查看我之前对Azure的引用,您会发现它们最多可以使用90天.对于Google,刷新令牌将在6个月后过期(如果未使用).人们仍然可以撤销他们.

现在,当您使用刷新令牌时,您不会使用它们来访问受保护的资源.应交换刷新令牌以获取访问令牌.因此,如果有人窃取他们,他们仍然需要客户端身份验证(例如: - 客户端ID,重定向uri和客户端密钥)来获取访问令牌.但是,保护它们是必须的.

无论如何,RFC6819定义了一些可以在5.3.3节中存储秘密(令牌是秘密)的可能性.您可以使用客户端存储机制或利用支持的服务器来存储令牌.

如果您的应用程序有后端,一种可能性是将cookie与令牌相关联.Cookie值可以是您存储在后端(可能在数据库中)的令牌的哈希值.当后端接收到具有有效cookie值的请求时,它可以检索针对它存储的令牌.这与"记住我"功能非常相似.

如果你无法控制令牌的生命周期(它们默认是长寿命的)怎么办？

如果您可以轻松获得令牌,并且如果您可以牺牲最终用户体验,请选择内存存储,您将始终检索新令牌以便进行全新访问.

如果您的应用程序的后端可以维护客户端之间的状态,则在后端推送和存储令牌.将客户端会话与令牌相关联,可能通过cookie /会话.通过后端调用安全API,而不将存储的令牌暴露给客户端应用程序.