使用什么来生成 OAuth 2 访问令牌 [英] What to use to generate OAuth 2 access token

问题描述

所以我正在尝试尽可能接近地为我正在构建的这个 API 实现 OAuth 2.我正处于需要生成 access_token 的地步，但是我正在尝试找出执行此操作的最佳方法.我读过一个地方，人们正在加密 revenant 信息和 access_token(如过期日期、客户端 ID 等)，以防止在每次 API 调用时进行数据库查找.

So I am playing around with trying to implement as closely as I can OAuth 2 for this API I am building. I am at the point where I need to generate the access_token however I am trying to figure out the best method of doing this. I have read in a very place where people are encrypting the revenant information and the access_token (like expired date, client id, etc...) in order to prevent a database lookup on each API call.

我当时想了想，这种生成 access_token 的方式如何处理撤销访问权限?我的意思是使用 OAuth 的优势之一是能够撤销对应用程序数据的访问，如果我只是使用加密数据而不在数据库中查找，如果我撤销应用程序，它仍然可以访问至少直到 access_token 过期.

I was think about that and thought, how does that way of generating the access_token handle revoking access? I mean one of the advantages of using OAuth is the ability to revoke access to your data for an application if I am just using the encrypted data without a look up in the database, if I revoke an application, it is still going to have access to my data until at least that access_token expires.

我认为防止在关系数据库中查找的更好方法是将 access_token 也存储在键/值数据库(如 redis)中，因为这样会更快一些.这样，如果有人撤销对应用程序的访问，它可以删除关系数据库和键/值数据中的记录.

I would think a better to way to prevent a lookup in a relational database would be to also store the access_token in a key/value database (like redis) since that would be a bit faster. This way if someone revokes access to an application, it can delete both the record in the relational database and in the key/value data.

我是否遗漏了什么，有没有办法将加密数据用于 access_token，防止每次 API 调用都进行数据库查找，并且可以随时撤销访问权限?

Am i missing something, is there a way to use encrypted data to the access_token, prevent database look up for each API call, and since be able to revoke access at anytime?

推荐答案

您已经知道这两种方法(数据库中的令牌与自包含令牌)的优缺点，这是您必须做出的选择.大多数提供商都使用自包含令牌，我建议将其作为起点，例如JWS/JWE.

You already know the two approaches (tokens in database vs self-contained tokens) with their pros and cons, it's a choice you have to make. Most providers go for self-contained tokens, I propose the same as a starting point, e.g. JWS/JWE.

但是，我认为您可以稍微调整一下，并通过一个简单的技巧将两个世界中的优点结合起来，而不是简单的自包含令牌(我猜大多数提供商可能会这样做).考虑到令牌撤销是一种特殊情况(至少发生的次数远少于正常的令牌操作)，您可以在数据库中仅保留已撤销令牌的列表.验证令牌，您可以在已撤销令牌列表中搜索它:如果未找到，则可以正常使用其签名或加密的内容.通过这种方式，您仍然拥有一个数据库，但记录明显减少，查找速度更快.例如.您只能使用键/值数据库，而不能同时使用键/值和关系数据库.如果您不希望 API 的流量很大，您甚至可以通过在内存中保留已撤销令牌的列表来保存整个数据库查找，例如在它们无论如何都会过期后，定期将它们从列表中清除.

However, instead of simple self-contained tokens, I think you can tweak it a bit and combine the best of the two worlds with a simple trick (I guess most providers may do the same). Considering token revokes an exceptional case (at least occuring much less than normal token operations), you can keep only the list of revoked tokens in a database. Validating a token, you can search for it in the list of revoked tokens: if not found, its signed or encrypted content can be used as normal. This way you still have a database, but with significantly less records and faster lookups. E.g. you can use only your key/value database instead of having both a key/value and a relational database. If you don't expect heavy traffic for your API, you may even save the whole database lookup by keeping the list of revoked tokens in memory, and e.g. periodically sweeping them from the list after they would expire anyway.

这篇关于使用什么来生成 OAuth 2 访问令牌的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！