【发布时间】：2020-01-30 23:35:34
【问题描述】：
我正在创建一个新的 .Net Core Web API，供新的 React 客户端应用使用。客户端应用程序和 Web API 都位于不同的主机上并受 Auth0 保护。我在 Auth0 中设置了客户端应用程序和 Web API，然后在 Auth0 中创建了一个机器对机器应用程序，以便能够以静默方式与 Web API 通信（没有用户界面）。安全流程是这样工作的：
- 用户尝试访问客户端应用程序。
- 用户被重定向到 Auth0 以提供凭据。
- Auth0 验证凭据并将用户信息（包括用户 ID + 访问令牌）返回到客户端应用程序。
- 客户端应用程序将用户信息存储在本地存储中以供将来使用，直到过期为止。
- 对第 3 方 API 的任何调用都通过我自己的 Web API 进行路由，因此第 3 方 API 密钥位于服务器上的安全位置，而不是客户端。
- 用户访问的页面需要调用我的 Web API，但我们还没有我的 Web API 的访问令牌。
- 客户端应用程序从 .env 文件中读取 ClientId 和 ClientSecret（硬编码值）并向 Auth0 发出 POST 请求以获取我的 Web API 的访问令牌（这是 Auth0 获取访问令牌的推荐方式Web API 静默，除非它们没有指定 ClientId 和 ClientSecret 的存储位置）。
- Auth0 为我的 Web API 返回一个访问令牌。
- 客户端应用程序将 Web API 访问令牌存储在本地存储中以供将来使用，直到过期为止。
- 客户端应用使用新获取的访问令牌作为标头中的不记名令牌调用我的 Web API。
- Web API 接收访问令牌，使用 Auth0 进行身份验证并满足请求。
以上所有内容都对我有用，但我担心将我的 Web API 的 Auth0 ClientSecret 存储在客户端应用程序中。虽然它在屏幕上或任何地方的 cookie 中都不可见，但任何有能力的用户都可以通过检查网络流量来获取它。
互联网上的许多人似乎都可以将 3rd 方 API 密钥存储在 .env 文件中，而其他人则建议通过您自己的 Web API 路由 3rd 方 API 访问……而我正在做后者。但是我仍然需要 Auth0 ClientSecret 才能访问我自己的 Web API，如果不将它们存储在客户端的某个位置，我无法找到更好的方法来访问它。
我能想到的最后一个解决方案是不通过 Auth0 保护我的 Web API，而是从客户端应用程序到我的 Web API 的每个调用都应该包含一些独特的东西（比如来自 Auth0 的用户 ID）由 Web API 验证。值得庆幸的是，最初设置用户时，来自 Auth0 的用户 ID 将存储在我们的数据库中，因此这实际上是可能的。
鉴于我已经拥有客户端应用程序的访问令牌，Auth0 是否有任何其他方式让我在不提供 ClientSecret 的情况下获取 Web API 访问令牌？我很想知道其他人如何通过 Auth0 保护他们的客户端应用程序和 Web API。
【问题讨论】：