高效的OAuth2.0服务器/提供商如何工作？ [英] How would an efficient OAuth2.0 server / provider work?
问题描述
我可能需要为我创建的API实施OAuth2.0服务器。此API将允许第三方代表用户执行操作。
OAuth2.0具有3个电话呼叫。首先，有一个呼叫提示用户同意。这将返回代码。第二个是代码被替换为访问令牌。最后，访问令牌用于代表用户调用API。
为了实现，我在想第一个调用生成一个随机字符串，它作为代码。然后将代码存储在具有指向当前用户的指针和随机 HMAC Key 的数据库中，然后随机数据以代码返回给第三方。
当第三方请求访问令牌，生成另一条随机数据并与代码连接。此字符串使用步骤1中的 HMAC密钥签名，然后该签名字符串和签名与签名一起返回以形成访问令牌。
当API调用发生时， hmac键从数据库中检索c> access_token 。使用hmac键验证 access_token 的签名。
用户可以通过从授权HMAC密钥列表中删除HMAC密钥来撤消第三方访问。此外，只是签署随机数据，我可以避免存储每一个access_token每个创建，而是保持一个hmac键的短列表。
无论如何，这是我第一次尝试作为思考通过这一点。令人惊讶的是，几乎没有有效地实现OAuth2.0的服务器端的信息。我更喜欢在数据库中尽可能少的信息。签署随机数据然后撤销HMAC密钥的优点是，我不必存储每个授权调用生成的每个访问令牌。
需要思考！必须有更好的方法！
编辑：
我不是在寻找一个实现。谢谢你！此外，我认为这整个系统将运行HTTP。此外，我在谈论纯OAuth2.0流程，我不是谈论带有签名和客户端密钥的OAuth1.0。我要问如何设计OAuth2.0服务器背后的加密技术，以类似的方式（例如）Google的OAuth2.0流程工作。
我没有确切的答案，但让我们尝试把这些片段在一起 -
i）我不太确定，如果你需要保存在您的数据库中的授权码长。这是Facebook说的 -
OAuth授权码的新安全限制
我们只允许授权码交换访问令牌一次，并将要求他们在创建后10分钟内交换访问
令牌。这符合
OAuth 2.0规范，从一开始就声明authorization
代码必须是短期和单次使用。有关详情，请查看我们的身份验证文档中的
。
请参阅此链接，https://developers.facebook.com/roadmap/completed-changes/ （12月5日，更改）。
ii）在步骤1之前做什么，将授权码和HMAC密钥保存在DB中。
p> iii）假设您有一个单一登录服务，用于验证客户端的凭据。当客户端应用程序命中令牌交换端点（访问令牌的授权码）时，您需要获取HMAC密钥并返回访问令牌。 为什么不添加（一些随机数据+时间戳+客户ID /客户名（或可用于唯一标识用户的名称）），并使用键对其进行签名，并返回所有此数据作为访问令牌。
您可以考虑使用新的HMAC密钥或替换旧的HMAC密钥。
iv）当客户端点击任何API端点令牌，让srvice内部调用 CustomerIDExtractorService，它从DB获取HMAC密钥并解密访问令牌，并将customerID返回到相关API 。然后，独立进程可以使用客户ID来提取数据。因此，基本上，我要求您将登录/令牌生成/令牌信息提取过程分离到一个单独的单元。
让我们尝试将此映射为Google可以如何进行此类操作
i）您使用应用并登录Google Oauth。 （让来自google的黑盒X处理登录）。
ii）您的应用程序命中了令牌交换端点 - >服务内部检查代码是否有效。如果是，该服务会合并一些数据+ customerID并对其进行签名并将其作为访问令牌返回给应用程序。
iii）应用程序现在点击（说）google +端点。在内部，服务将令牌传送到黑盒X，其解密令牌并将客户ID返回到G +服务。 g +然后将C_ID映射到相关的客户数据。
另一个建议
根据应用程序请求，您可以添加更多信息到访问令牌。也许创建一个JSON对象，并根据应用程序选择的范围添加/删除字段。将JSON字符串签名为访问令牌。
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 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.
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.
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.
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.
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.
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!
EDIT:
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 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 -
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.
See this link, https://developers.facebook.com/roadmap/completed-changes/ (December 5, changes).
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) 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) 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.
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.
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屋！
