通用OAuth客户端集成 [英] Generic OAuth clients integrations
问题描述
我有一个产品可以调用多个第三方rest api来获取某些数据. 有多个需要oAuth支持的供应商api.他们可以授予我帐户和客户端访问其api的权限，但是我的服务需要使用这些帐户及其CI生成令牌.
I have a product which invokes multiple third party rest api's for certain data fetch. There are multiple vendor api's which requires oAuth Support. They can grant me account and Client for accessing their api's but my service needs to generate a token using those account and their CI.
如何构建通用框架来支持多个供应商CI. 我认为这有点复杂，因为有些供应商使用oAuth1，有些使用oAuth 2. 有没有现成的解决方案? 如何处理令牌刷新?
How can I build a generic framework to support multiple vendor CI's. I consider this bit complex , since some vendors use oAuth1 , some use oAuth 2.. Is there any existing solution for this? How do I handle token refresh?
例如:
一个供应商可以使用google CI成为google 其他供应商可以使用其CI作为Facebook.
One vendor can be google using google CI other Vendor can be Facebook using their CI.
推荐答案
Facebook和Google之间的工作流程几乎相同，因此后端(和前端在某种程度上是)可以肯定地以通用方式进行设计:
The workflow is pretty much the same between Facebook and Google, so the backend (and the frontend, to some extent) can definitely be designed in a generic manner:
- 仅为实际客户端应用程序(因此
Authorized JavaScript origins)(而不是后端)设置客户端ID(仅 ). - 将每个客户端与每个OAuth提供程序集成
- 通过常见的抽象模型向后端/API发送数据(提供商令牌)
- 在服务器端验证令牌(对于每个提供程序，此操作均不同，但是您可以具有IProviderAuthValidator和多个实现)
- 创建帐户/登录等
- setup client IDs only for the actual client applications (hence the
Authorized JavaScript origins), and not for the backend, too. - integrate each client with each OAuth provider
- send data (provider token) the backend/API through a common abstracted model
- validate the token on the server side (this is done differently for each provider, but you could have a IProviderAuthValidator and several inmplementations)
- create account/login etc
因此，唯一特定的位应该是这些2: -获取提供商令牌客户端 -验证所述令牌服务器端
Thus, the only particularized bits should be these 2: - fetch provider token client side - validate said token server side
这篇关于通用OAuth客户端集成的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
