对于即将进行的项目，我想实现具有不同访问级别（用户、管理员等）的 REST API。保护此 API 的 Oauth2.0 似乎是当今的标准，但它带来了一定程度的复杂性（如果运行您自己的服务）或成本（如果使用 aus auth0 等服务）。
作为替代方案，我可以想象一个更基本的身份验证，其中凭据交换访问令牌，在每个请求期间根据数据库检查访问令牌（因此可以撤销），或者访问令牌与刷新令牌相结合。< /p>
如果我使用 TLS 实现这样一个看起来相当微不足道的系统，我会面临什么风险？与 Oauth2.0 相比，这种方法本质上更危险的是什么？
这种解决方案有多普遍？在线搜索表明每个人都在使用 Oauth，但实际上，许多移动/桌面应用程序无需重定向到浏览器即可登录，因此至少没有使用推荐的 oauth 流程！此外，像 Firebase 这样的服务似乎也跳过了浏览器。 **编辑：**大多数网站当然也不会将 oauth 用于他们的第一方登录体验
有哪些好的资源/指南可以用来实现这样的基本安全？使用某种形式的这种基本身份验证的移动应用程序数量与在线资源之间似乎存在严重的不平衡。一般答案是：“使用oauth2.0”
对于一个有时间或金钱的项目，像 oauth 这样的标准当然是有意义的，但对于时间/金钱受限的项目，这总是正确的选择吗？