我目前正在开发一个网络应用程序，它由一个前端组成，使用我们编写的REST API来显示和交互数据。唯一使用API的是我们的前端网站，以及我们将开发的移动应用程序。
我已经阅读了很多有关OAuth是保护API的理想机制的文章，现在我开始对它的工作原理有了很好的理解。
我的问题是，既然我永远不会将API授权给第三方客户端，OAuth真的必要吗？是否有任何优势？此外，由于后端只是API，没有用户可以从中进行身份验证的网关（就像如果您使用Twitter API编写应用程序时，当用户验证时，他们将被定向到Twitter页面以授予访问权限，然后重定向回客户端）。
我不太确定该走哪个方向。看起来必须有某种方法介于http身份验证和OAuth之间，适用于这种情况，但我还是不明白。
第三方原生应用程序也是不受信任的。使用您的 API 的恶意开发人员可能会保存您平台的最终用户的凭据。
您的原生应用程序是可信客户端，可以通过简单的用户名、密码和标识您的应用程序的客户端 ID 来管理身份验证。
OAuth 如何帮助？ OAuth 授权码 和 隐式 授权可以帮助您解决此问题。这些流程仅适用于支持重定向的客户端，例如浏览器。并且允许您对不受信任的客户端和用户进行身份验证，以获得对您的授权服务器、资源服务器和 API 的访问权限，而不会暴露凭据。请查看 RFC 以了解其操作方式。
OAuth 的好处在于它不仅支持这些基于重定向的身份验证流程，还支持客户端凭据授权和用户凭据授权。因此，OAuth 授权服务器将涵盖所有情况。
如果你考虑要自己构建OAuth 2.0，那么它最初似乎很麻烦，但大多数编程语言都有一些非常可靠的OAuth 2.0设置，你可以根据需要进行调整。如果你使用像Laravel或RoR这样的框架，那么这几乎不需要什么工作。
如果你不想像帖子中建议的那样重定向用户，那么请忽略其他评论和回答，这些评论和回答谈论了两个腿流。你可以使用client_credentials授权类型，只需提供应用程序的客户端ID和密钥即可获得访问令牌，这非常简单易行。
我会问有多私密，因为如果只有在后端内部交互的系统并且没有与外部世界互动，那么你可能可以将其保持开放，并依靠网络来保护它（VPN/Firewall）。
但如果它是“我们的iPhone应用程序使用它”这种私有意义上的，那么你肯定想选择OAuth 2.0或类似的东西。
移动设备与API层通信应使用Oauth。
然而，在Web UI层到中间层的访问（机器到机器）中，使用Oauth没有任何好处。
另一方面，存在一些潜在问题：
管理访问令牌的过期时间会变得很麻烦。考虑到您的UI必须在集群中的多个节点上缓存访问令牌，并在其过期时进行刷新，而且UI层正在不时地与后端协商安全性，这将需要额外的时间。
在两个步骤的Oauth（OAuth Client Credential，如v2.0中所示）中不支持任何加密。因此，您仍然需要向服务器发送密钥和密码以获取访问令牌。
后端必须实现发放访问令牌、刷新令牌、验证访问令牌等功能，但没有任何显著的好处。
你可能想要使用2-legged OAuth。它基本上是对共享密钥进行哈希处理，但你有不必自己编写代码的优势。
这里有一个相关的问题：寻找关于2-legged OAuth的信息
