高效的OAuth2.0服务器/提供商如何运作？(How would an efficient OAuth2.0 server / provider work?)

 我可能需要为我正在创建的API实现OAuth2.0服务器。 此API允许第三方代表用户执行操作。 
 
 OAuth2.0有3个主电话。 首先，有一个提示用户同意的电话。 这将返回一个code 。 第二个是code交换access token 。 最后， access token用于代表用户调用API。 
 
 为了实现，我想第一个调用生成一个随机字符串作为code 。 然后将code存储在具有指向当前用户和随机HMAC Key的指针的数据库中，然后将随机数据作为code返回给第三方。 
 
 当第三方请求access token ，生成另一条随机数据并与code连接。 使用步骤1中的HMAC key对此字符串进行签名，然后返回此签名字符串和签名以及签名以形成access token 。 
 
 当API调用发生时，从数据库中检索对应于提供的access_token的hmac key 。 使用hmac密钥验证access_token的签名。 
 
 用户可以通过简单地从他们的授权HMAC密钥列表中删除HMAC密钥来撤销第三方访问。 此外，但只是签署随机数据，我可以避免存储每个创建的每个access_token，而是维护一个简短的hmac键列表。 
 
 无论如何，这是我第一次尝试思考这个问题。 令人惊讶的是，关于有效实施OAuth2.0服务器端的信息很少。 我宁愿在数据库中保留尽可能少的信息。 签署随机数据然后撤销HMAC密钥的优点是我不必存储每个授权调用生成的每个access token 。 
 
 需要的想法！ 必须有一个更好的方法！ 
 
 编辑： 
 
 我不是在寻找实施方案。 谢谢你！ 此外，我假设整个系统将运行HTTPs。 另外，我在谈论纯OAuth2.0流程，我不是在谈论带有签名和客户端密钥的OAuth1.0。 我问的是如何在OAuth2.0服务器后面设计密码术，该服务器的工作方式与（例如）Google的OAuth2.0流程类似。 

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.

原文：https://stackoverflow.com/questions/16200528