Question

我正在开发oAuth服务（我这么想。可能不完全一样。）打开我们的一个后端API给商家。

基本上用户可以从Merchant的电子商务网站购买商品，并可以使用我们的支付网关付款。

我们为商家和用户提供注册系统，我们正在向他们发放ID（公开可用的字母数字）。

我的计划是oAuth服务。

   1) First merchant sends above mentioned id to our oAuth server.
   2) Then oAuth server sending token, refresh token and expiry time as response.
   3) Then merchant sends that token with other required information such as amount again to oAuth server to open our payment gateway web interface.
   4) user use that interface to provide his ID and pin to confirm the transactions.
   5) Then from over oAuth server we call our back end RESTFull service to do the actual transaction (Merchant account receive money and customer account will debited)
   6) After completion of transaction we redirect user again to merchant's website.

*所有通讯均通过https频道完成。

我对

有疑问

    1) Whether  my approach is correct to secure the above given flow.
    2) Do I really need a tokens here or only ID is enough? If I only used ID what I'm going to missing here.
    3) Is there any possibility that some one can cheat the process.

期待你的建议。

Answer 1

您和商家网站是否有相关的用户ID？基于我们已经完成的类似实现，需要注意一些要点。

你肯定需要一个代币。
IMO，您应该将令牌标记为用户ID，这意味着商家应该在初始请求中发送用户ID。
我不明白为什么您需要将到期时间发送回商家应用。只需令牌即可。你应该有一个过期使用过令牌的服务。
考虑以某种方式加密令牌。

Answer 2

这听起来不像是OAuth。您可以将商家和用户视为最终用户。在OAuth中，用户是关键角色，客户（商家）仅在用户同意后代表用户行事。

您不需要OAuth授权商家访问您的API（只需使用客户端ID和客户端密码），您需要OAuth授权商家代表用户访问您的API

如果您尝试将OAuth协议用于您的目的，则商家将成为客户端应用程序，并且需要注册（一次）并获得客户端ID并且可能是您的支付系统中的客户端密码。不会仅为客户（商家）发放令牌。

然后，客户应要求用户（买方）代表他授权访问付款服务。如果用户登录并提供同意，则会发出令牌。令牌通常绑定到客户端+用户。

但OAuth协议在此步骤中不足以满足您的需求：OAuth支持用户同意的范围，但您需要同意付款 - 至少是金额，但可能还有其他一些信息。也许你可以使用额外的参数传递信息。

在用户同意后，客户（商家）会获得一个令牌，并可能代表用户调用您的支付系统。也许商家可以再次使用令牌询问付款细节。

正确的方法来保护后端服务 - oAuth

2 个答案: