高效的 OAuth2.0 服务器/提供者将如何工作? [英] How would an efficient OAuth2.0 server / provider work?

问题描述

我可能需要为我正在创建的 API 实现 OAuth2.0 服务器.此 API 将允许第 3 方代表用户执行操作.

I may need to implement an OAuth2.0 server for an API I'm creating. This API would allow 3rd parties to perform actions on the user's behalf.

OAuth2.0 有 3 个电源调用.首先，有一个电话提示用户同意.这将返回一个 code.第二个是 code 与 access token 交换的地方.最后，access token用于代表用户调用API.

OAuth2.0 has 3 mains calls. First, there is a call to prompt the user for consent. This returns a code. The second is where the code is exchanged for a access token. Finally, the access token is used to call the API on the user's behalf.

为了实现，我认为第一次调用会生成一个随机字符串，它充当 code.code 然后存储在数据库中，带有指向当前用户的指针和随机 HMAC Key，然后将随机数据作为 返回给第 3 方代码.

For implementation, I was thinking the first call generates a random string which acts as a code. The code is then stored in a database with a pointer to the current User and a random HMAC Key, then the random data is returned to the 3rd party as the code.

当第 3 方请求 access token 时，会生成另一条随机数据并与 code 连接.此字符串使用步骤 1 中的 HMAC 密钥 进行签名，然后将此签名字符串和签名与签名一起返回以形成 访问令牌.

When the 3rd party requests an access token, another piece of random data is generated and concatenated with the code. This string is signed using the HMAC key from Step 1, then this signed string and signature is returned with the signature to form the access token.

当API调用发生时，从数据库中检索对应于提供的access_token的hmac key.access_token 的签名使用 hmac 密钥进行验证.

When the API call occurs, the hmac key corresponding to the provided access_token is retrieved from the database. The signature of the access_token is verified using the hmac key.

用户只需从其授权 HMAC 密钥列表中删除一个 HMAC 密钥，即可撤销第 3 方访问权限.此外，但只是签署随机数据，我可以避免存储每个创建的每个 access_token，而是维护一个简短的 hmac 密钥列表.

The user can revoke 3rd party access by simply removing an HMAC key from their list of authorized HMAC keys. Furthermore, but just signing random data, I can avoid storing every single access_token every created, and instead maintain a short list of hmac keys.

无论如何，这是我第一次尝试思考这个问题.令人惊讶的是，关于有效实现 OAuth2.0 的服务器端的信息很少.我宁愿在数据库中保留尽可能少的信息.签署随机数据然后撤销 HMAC 密钥的优点是我不必存储每个授权调用生成的每个 access token.

Anyway, this is my first attempt as thinking through this. Surprisingly, there is little information about implementing the server side of OAuth2.0 efficiently. I would prefer to keep as little information as possible in the database. The advantage of signing random data then later revoking the HMAC key is that I don't have to store every single access token generated by every single authorization call.

需要思考！一定有更好的方法！

Thoughts needed! There has got to be a better way!

我不是在寻找实现.不过还是谢谢！另外，我假设整个系统将通过 HTTPs 运行.另外，我说的是纯 OAuth2.0 流程，我不是在谈论带有签名和客户端密钥的 OAuth1.0.我在问如何设计 OAuth2.0 服务器背后的密码学，它的工作方式与(例如)Google 的 OAuth2.0 流程类似.

I'm NOT looking for an implementation. Thank you though! Also, I assume this whole system will run over HTTPs. Also, I'm talking about the pure OAuth2.0 flow, I'm not talking about OAuth1.0 with signatures and client keys. I'm asking how to design the cryptography behind an OAuth2.0 server that would work in a similar fashion to (for example) Google's OAuth2.0 flow works.

推荐答案

我没有确切的答案，但让我们试着把这些碎片放在一起 -

i) 我不太确定您是否需要将授权码长期保存在数据库中.这就是 Facebook 所说的 -

I don't have an exact answer to this, but let's try to put the pieces together -

i) I am not too sure if you need to save the authorization code in your database for long. This is what Facebook says -

OAuth 授权码的新安全限制我们将只允许将授权代码交换为访问令牌一次，并要求将它们交换为访问令牌令牌创建后 10 分钟内.这符合OAuth 2.0 Spec 从一开始就声明授权代码必须是短命且一次性使用的".有关更多信息，请查看出我们的身份验证文档.

New security restrictions for OAuth authorization codes We will only allow authorization codes to be exchanged for access tokens once and will require that they be exchanged for an access token within 10 minutes of their creation. This is in line with the OAuth 2.0 Spec which from the start has stated that "authorization codes MUST be short lived and single use". For more information, check out our Authentication documentation.

查看此链接，https://developers.facebook.com/roadmap/completed-changes/(12 月 5 日，变化).

See this link, https://developers.facebook.com/roadmap/completed-changes/ (December 5, changes).

ii) 在第 1 步之前做什么，将授权码和 HMAC 密钥保存在数据库中.让我们有 10 分钟的授权码(或任何你认为有必要的)，然后删除授权码.

ii) What about doing what you are doing till step 1, keep the authorization code and HMAC key in the DB. Let's have the authorization code for 10 mins (or whatever you feel is necessary) and then remove the authorization code.

iii) 假设您有一个单点登录服务来验证客户端的凭据.当客户端应用程序访问令牌交换端点(访问令牌的身份验证代码)时，您需要获取 HMAC 密钥并返回访问令牌.为什么不添加(一些随机数据+时间戳+客户ID/客户名称(或可用于唯一标识用户的东西))并使用密钥对其进行签名并将所有这些数据作为访问令牌返回.
您可以考虑使用新的 HMAC 密钥并替换旧的.

iii) Let's say you have a single sign-in service that authenticates a client's credentials. When the client app hits the token exchange endpoint (auth code for access token) you'd need to fetch the HMAC key and return the access token. Why not add (some random data + timestamp + customerID/customer name(or something that can be used to uniquely identify the user)) and sign it with the key and return all this data as the access token.
You can think about using a new HMAC key perhaps and replacing the old one.

iv) 当客户端使用令牌访问任何 API 端点时，让服务在内部调用 CustomerIDExtractorService，该服务从数据库中获取 HMAC 密钥并解密访问令牌并将客户 ID 返回给相关 API.然后，独立进程可以使用客户 ID 来获取数据.所以基本上，我要求您将登录/令牌生成/令牌信息提​​取过程分离到一个单独的单元中.

iv) When the client hits any API endpoint with the token, let the srvice internally call a CustomerIDExtractorService that fetches the HMAC key from the DB and decrypts the access token and returns the customerID to the relevant API. The independent process can then use to the customer ID to fetch data. So basically, I ask you to separate the login/token generation/token info extraction process to a separate unit.

让我们尝试将其映射到 Google 如何做这样的事情
i) 您使用应用并登录 Google Oauth.(让谷歌的黑匣子 X 处理登录).
ii) 您的应用程序访问令牌交换端点 -> 服务在内部检查代码是否有效.如果是，服务会结合一些数据 + 客户 ID 并对其进行签名并将其作为访问令牌返回给应用程序.
iii) 应用程序现在点击(比如说)google+ 端点.在内部，该服务将令牌传输到黑匣子 X，后者解密令牌并将客户 ID 返回给 G+ 服务.然后 g+ 将 C_ID 映射到相关的客户数据.

Let's try to map this to how Google could be doing something like this
i) You use an app and sign in to Google Oauth. (Let a black box X from google handle the login).
ii) Your app hits the token exchange endpoint -> The service internally checks if the code is valid. If it is, the service combines some data + customerID and signs it and returns it to the app as an access token.
iii) The app now hits (say) the google+ endpoint. Internally, the service transfers the token to black box X, which decrypts the token and returns customer ID to G+ service. g+ then maps the C_ID to relevant customer data.

另一个建议

根据应用请求的范围，您可以向访问令牌添加更多信息.可能会根据应用程序选择的范围创建一个 JSON 对象并添加/删除字段.将 JSON 字符串签名为访问令牌.

Another suggestion

Depending on the scope that the app requested, you can add more info to the access token. Maybe create a JSON object and add/remove fields according to the scope selected by the app. Sign the JSON string as the access token.

这篇关于高效的 OAuth2.0 服务器/提供者将如何工作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！