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

我正在开发一个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.

---

期待您的建议。

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

你肯定需要一个代币

依我看，您应该将令牌标记为用户id，这意味着商户应该在初始请求中发送用户id

我不明白您为什么需要将到期时间发送回商家应用程序。只要一个代币就够了。您应该有一个过期已用令牌的服务

考虑以某种方式加密令牌

---

这听起来不像是非统组织。你混合了商家和用户，将两者视为最终用户。在OAuth中，用户是关键参与者，客户（商家）仅在用户提供同意后代表用户行事

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

如果您试图使用OAuth协议来实现您的目的，那么商户将是一个客户应用程序，它需要注册（一次）并从您的支付系统中获取客户id和可能的客户机密。不单独为客户（商户）发行代币

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

但是OAuth协议在这一步对您的案例来说是不够的：OAuth支持用户同意的范围，但是您需要支付的同意-至少是金额，但可能还有一些其他信息。也许你可以使用额外的参数来传递这些信息

---

在用户同意后，客户（商户）获得代币，并可以代表用户调用您的支付系统。也许商户可以使用代币再次询问付款详细信息。

您和商户网站是否有相关的用户ID？是的，在注册过程中我们会发布一个ID。你认为有没有可能有人会欺骗这个过程？互联网上没有任何东西是完全安全的，IMHO:）。这就是说，https上的加密令牌交换机制是合理的。您应该将令牌附加到用户。您理解我的问题，并且回答得很好。我理解您使用oauth的方法。但是我不能这样做，所以你可以建议我一种方法来确保api与我上面的步骤保持一致。