API請求的訪問令牌與用戶名/密碼

Question

我知道這似乎是一個瑣碎的問題，但我找不到答案，至少可以使我安心。

如果移動應用程序正在與服務器進行通信，則通常他們會登錄並獲得訪問令牌，可將其用於會話的其余部分以及將來的任何請求。

為什么不隨每個請求（而不是訪問令牌）通過HTTPS傳遞用戶名和密碼。 訪問令牌將需要與數據庫一起驗證，用戶名/密碼的組合也需要進行驗證。 如果他們做同樣的事情，為什么還要付出更多的訪問令牌呢？ 我知道我錯過了一些東西，但我無法弄清楚

Answer 1

我認為答案是關於安全性的。

始終建議使用訪問令牌代替用戶名和密碼，因為：

• 訪問令牌（在大多數服務中）可以輕松地從您的帳戶生成，阻止，監控其使用情況和統計​​信息，可以設置為過期，可以具有受限權限等等。當然，您可以將其刪除。 用戶名和密碼是主用戶，可以控制訪問令牌。

• 如我所說，訪問令牌更安全，這是最重要的。 如果您在網絡應用程序（或其他應用程序）中使用用戶名和密碼，並且該應用程序被黑客入侵（這種情況經常發生），或者有人查看其源代碼，甚至某些日志系統都保存了請求參數-那么您的用戶名和密碼可以會被第三方查看，並且您的所有帳戶都可能遭到黑客入侵（如果您擁有相同的用戶/密碼，則可能也會被黑客入侵）。 訪問令牌消除了所有這些風險。

• 關於速度-我認為USER＆PW的授權在速度方面沒有任何顯着優勢。

Answer 2

沒錯，訪問令牌的驗證方式幾乎與用戶名和密碼相同。 在訪問令牌有效期間，它與用戶名和密碼相當。 在某些情況下（取決於您的威脅模型），甚至可以隨每個請求發送用戶名和密碼，也許不是從移動應用程序發送，而是例如通過適當的控件在服務器之間發送請求。

但是，您主要不希望在移動應用程序的每個請求中發送密碼，因為那樣一來您就必須存儲它。

密碼（或實際上是用戶）的問題在於它們已被重用。 密碼是很有價值的目標，因為相同的密碼可能會在多個服務上使用。 因此，您將其交換為壽命較短的訪問令牌，如果該令牌被盜，則對用戶的風險較小。 而且，您無法輕易撤消密碼-強迫用戶更改密碼是一件麻煩的事。 撤銷被盜的憑證很容易。

這也是極不可能的，但有時TLS中存在漏洞-並不經常出現，但在過去幾年中有一些漏洞。 此類漏洞可能允許攻擊者解密通過https發送的某些流量，例如，openssl之前存在一個漏洞，攻擊者可以提取部分服務器內存，並可能保留發送的所有用戶。 如果它只是一個訪問令牌，而不是實際的密碼，那就更好了。

還有一點是（在OAuth流程中）有時甚至不允許您的應用訪問實際密碼。 當您的用戶使用第三方身份提供商（例如Facebook）登錄時，他們不希望您的應用接收其Facebook密碼。 他們只是去Facebook，將其憑證交換為訪問令牌，然后您只看到可以根據需要與Facebook驗證的令牌。 但是您實際上從未獲得用戶的facebook密碼。 當然，這僅在身份提供者是第三方時才有效。