一个显著的障碍我有一个问题，关于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服务器上部署应用程序端点。这是一种常见的部署方案。但是，这对于本地客户来说通常并不实用。