高效的 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一起存储在数据库中，然后将随机数据作为返回给第三方代码.

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 密钥的优点是我不必存储每个授权调用生成的每个 访问令牌.

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!

我不是在寻找实现.不过还是谢谢你！此外，我假设整个系统将通过 HTTP 运行.另外，我在谈论纯 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 规范从一开始就声明授权代码必须是短暂的和一次性的".有关更多信息，请查看出我们的身份验证文档.

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) 您的应用程序访问令牌交换端点 -> 服务在内部检查代码是否有效.如果是，该服务会结合一些数据 + customerID 并对其进行签名，然后将其作为访问令牌返回给应用程序.
iii) 应用程序现在点击(比如)google+ 端点.在内部，服务将令牌传输到黑盒 X，黑盒 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屋！