一個顯著的障礙我有一個問題，關於RFC 6749約的OAuth 2.0 ..爲什麼部署TLS是許多客戶端開發人員
在這一節中，我讀出：
3.1。 2.1。 端點請求保密
如在第1.6節中描述 當所請求的響應類型是「代碼」或「令牌」， 或當重定向請求將導致的傳輸重定向端點應該要求使用TLS的
開放網絡上的敏感憑證。由於在撰寫本文時，要求客戶端部署TLS的
對於許多客戶端開發人員來說是一個重大障礙，因此本規範確實不要求使用TLS。如果TLS不可用，則授權服務器 應該在資源擁有者關於重定向之前的
（例如，在授權
請求期間顯示消息）之前警告非安全端點。缺乏傳輸層安全性，可對客戶的
安全，它被授權
訪問受保護的資源造成了嚴重影響。當授權過程被用作
由客戶端委派的最終用戶認證（例如，第三方
登錄服務）的形式時，傳輸層安全的使用尤其是重要的。
..in特別是：
該規範並不強制使用TLS，因爲在 時間寫這篇文章，要求客戶部署TLS是許多客戶端開發人員 顯著障礙。
爲什麼部署TLS對許多客戶端開發人員來說是一個很大的障礙？
公鑰基礎設施非常複雜，並且很多開發人員都不瞭解它，即使在客戶端也可以實現它。這會導致錯誤的安全性，這會導致安全性更差（因爲它會誤導人）。
作爲一個例子，我記得最近的一項研究顯示，在許多Android應用程序中，客戶端軟件使用SSL/TLS，但是如果沒有適當的驗證就會接受任何證書。這導致了MITM攻擊的可能性，更糟糕的是，用戶（設備的擁有者）認爲他是安全的，而事實上並非如此。
更糟的是，開發商不想投資於安全相關的教育，因爲這不會增加利潤。
這段文字很不幸，我會打開一篇針對RFC 6749的編輯勘誤。我對這種語言的理解是，它意味着允許「本機客戶端」（桌面/平板電腦/移動應用）提供非SSL URL。通常，這採用「自定義URL方案」的形式。
這個想法是，瀏覽器將「本地重定向到」這些客戶端，併爲他們提供授權碼。所以代碼永遠不會通過網絡傳輸，因此不需要安全的重定向URL。當重定向URL的形式爲h-t-t -p localhost：xyz/redirect_endpoint時，也會採用類似的注意事項。
一般來說，開發人員不需要做任何事情來部署SSL。管理員必須啓動https端口並在Web服務器上部署應用程序端點。這是一種常見的部署方案。但是，這對於本地客戶來說通常並不實用。