我有一个关于如何使用访问令牌和API密钥构建REST API的问题.
我有一个需要身份验证的API.我想启用两个用例:
用户使用OAuth2(密码授予)登录界面,并被授予临时访问令牌.此令牌用于验证用户身份.因此,使用API的UI可以获取数据并显示它.
我还希望用户有一个API密钥来执行相同的调用,但在其应用程序中.显然,与访问令牌相反,我希望API密钥能够长久存在.此外,与绑定到给定用户的访问令牌相反(如果我们引入团队机制,每个用户将拥有不同的访问令牌,尽管他们访问相同的资源),API密钥对于项目应该是唯一的.
虽然相似,但我不确定我应该如何构建它.我认为,在内部,API密钥和访问令牌都应存储在同一个表中,但API密钥没有到期时间.我对吗？
我不确定的一件事是客户的概念.似乎在规范中,客户端更像是外部应用程序.不过我可以在这里实际使用这个概念吗？
例如,每个"项目"实际上是一个不同的客户端(尽管这里的客户端是相同的应用程序,而不是第三方开发人员创建的应用程序).
因此,如果用户A在系统上创建帐户,则将使用长期访问令牌(也称为API密钥)自动创建客户端A,其中访问令牌绑定到客户端A. 例如,这可以用于直接在他的代码上执行API调用.
然后,如果用户A登录仪表板,将创建一个临时访问令牌,但这次没有应用程序,但与用户关联,生命周期短.
这听起来有道理吗？有没有人已经实现了这样的事情？
谢谢!
Ste*_*esi 14
我认为您不应该将"API密钥"视为访问令牌的替代品.
您无论如何都必须使用访问令牌来承担请求之间的身份验证,因此您实际使用"API密钥"建模的内容并不是通常的承载令牌的替代,而是提供其他授权类型的不同客户端.请求令牌.
我个人实施的流程如下:
client_secret).client_id和a组成client_secret.这些就是你所说的"API密钥".显然,您必须以客户端可以属于特定用户的方式实现您的OAuth2服务器,并且具有不同的可接受授权类型(即您可能不希望允许用户客户端使用密码授权,而您可能希望禁用除了您的Web应用程序客户端的密码之外的任何授权类型.
然后,您将能够在每个客户端或每个授权类型的基础上定义令牌TTL或缺少TTL(例如,通过密码授予请求的访问令牌,仅可由Web应用客户端使用,将具有短TTL,而授权代码授予将提供长寿命代币).
我建议不要完全缺少TTL,而是使用refresh_token授权类型来更新过期的访问令牌.
此外,您可能必须定义某种授权系统(ACL,RBAC,无论如何),以定义哪个客户端可以执行哪些操作.这意味着每个访问令牌应包含对用于创建它的客户端的引用.
总而言之,以下是关系:
用户 有 客户.
客户 有一个 用户.
客户端 有很多 令牌.
令牌 有一个 客户端.
令牌 有一个 用户.
双向的YMMV.
您应该能够使用任何给定平台的最常见OAuth2服务器实现来实现我所描述的所有内容.
TL; DR:"API密钥"实际上是OAuth2 客户端.
| 归档时间： |
|
| 查看次数： |
5931 次 |
| 最近记录： |