使用OAuth密碼憑證授予優惠令牌訪問身份驗證

Question

我正在爲使用Rails 5的移動應用程序創建一個API。目前，我不需要三腳授權，因爲API只會被我們自己的移動應用。

我想選擇這兩個選項之一：

1. 守門人+設計：我可以使用看門實施的OAuth 2.0，但我將只使用密碼憑據格蘭特，至少現在。
2. Rails自己的ActionController::HttpAuthentication::Token模塊+設計：這似乎是更簡單的方法。

老實說，我看不出Token Access Authentication方法和OAuth 2.0's Password Credentials Grant之間的區別。

如何選擇一個而不是另一個？是否還有其他選擇需要考慮？

Answer 1

兩個在概念上是不同的東西：

• 「令牌訪問身份驗證」指定描述（可能是長期）令牌應該如何提交給服務器安全的協議。它沒有說明令牌的來源或應該如何解釋。
• 「密碼憑據授予」是完整的OAuth流程的一部分，描述了獲取（通常是短暫的）令牌的手段。

從某種意義上說，您可以使用Password Credentials Grant來使用OAuth獲取令牌，然後在Token授權標頭中使用此令牌獲取訪問權限。

然後問題就變成了：當我們可以使用存儲在應用程序中的（永久和祕密）令牌來爲（臨時）令牌交換（永久和祕密）憑證的額外往返時，無論如何，授權立即。

正如我所看到的，使用完整的OAuth流程有兩個潛在的好處。首先，它允許您自然地爲第三方添加其他授權方式。其次，它可以讓您隨時撤銷令牌，並使用其他方式強制重新授權（當然，如果您實施這些方式），而不必發明任何車輪。

另一方面，您可以隨時在需要時添加任何其他「令牌生成」部件。因此，如果您目前的計劃是在代碼中對代碼憑證進行硬編碼，那麼我會懷疑您最好依靠Token授權。如果攻擊者嗅探一個Bearer令牌，他們（通常）會（通常）獲得對服務器的完全令牌訪問權限，直到它到期爲止。如果攻擊者嗅探到Bearer令牌， 。 Token令牌（通常）不是這種情況。當然，如果攻擊者無論如何都可以從您的應用中提取共享密鑰，那麼這一切都不是非常重要。

Answer 2

如果您所擁有的只是「單一目的API」（僅適用於移動應用程序），則在安全性方面沒有太大差異。

但是，如果您希望擴展此API以供外部服務使用，那麼使用Doorkeeper實現OAuth 2.0時您將處於更好的位置，因爲您可以輕鬆配置，例如授權代碼授予他們。 所以，我會說「門衛+設計」選項更具前瞻性，因爲它提供了更多的選項，而HTTP Token authentication實現起來要簡單得多。