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

Question

我正在开发一个 oAuth 服务（我是这么想的。它可能不完全相同。）向商家开放我们的一个后端 API。

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

我们有商家和用户的注册系统，我们正在向他们颁发一个 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？基于我们已经完成的类似实现，需要注意一些要点。

1. 你肯定需要一个令牌。

2. IMO，您应该将令牌标记为用户 ID，这意味着商家应在初始请求中发送用户 ID。

3. 我不明白您为什么需要将到期时间发送回商家应用程序。只是令牌就足够了。您应该有一项服务会过期使用的令牌。

4. 考虑以某种方式加密令牌。

Answer 2

这听起来不像是 OAuth。您将商家和用户混为一谈，将两者都视为最终用户。在 OAuth 中，用户是关键参与者，客户（商家）仅在用户同意后才代表用户行事。

您不需要 OAuth 来授权商家访问您的 API（只需使用 client-id 和 client-secret），您需要 OAuth 来授权商家代表用户访问您的 API.

如果您尝试将 OAuth 协议用于您的目的，那么商家将是一个客户端应用程序，它需要注册（一次）并从您的支付系统中获取一个客户端 ID 和可能的客户端密码。不会单独为客户（商户）发放代币。

然后，客户应要求用户（买方）代表他授权访问支付服务。如果用户登录并提供同意，这就是颁发令牌的地方。令牌通常绑定到客户端+用户。

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

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