是的，你说得对，纯文本配置文件只能在开发期间使用，不能用于生产目的.一般来说，可用选项取决于您托管应用的位置和方式.

Yes, you are right, the plain text config file could be used only during development, not for production purpose. And in general, available options depend on where and how you host an App.

如果你有 Azure Web 应用程序，你至少有下一个内置选项 (来自文档):

If you have an Azure Web App, you have at least next built-in options (from the documentation):

• 为 Azure 门户中的 AppSettings 添加 ClientId 和 ClientSecret 值.通过这样做，实际值将不在 web.config 中，而是通过具有单独访问控制功能的门户进行保护.这些值将替换您在 web.config 中输入的值.确保名称相同.

• add the ClientId and ClientSecret values for the AppSettings in the Azure portal. By doing this, the actual values will not be in the web.config but protected via the Portal where you have separate access control capabilities. These values will be substituted for the values that you entered in your web.config. Make sure that the names are the same.

使用客户端 ID 和证书而不是客户端 ID 和客户端密钥对 Azure AD 应用程序进行身份验证.以下是在 Azure Web 应用中使用证书的步骤:

authenticate an Azure AD application is by using a Client ID and a Certificate instead of a Client ID and Client Secret. Following are the steps to use a Certificate in an Azure Web App:

• 获取或创建证书
• 将证书与 Azure AD 应用程序相关联
• 将代码添加到您的 Web 应用程序以使用证书
• 为您的网络应用添加证书

您可能还会找到一种使用环境变量来存储凭据的方法.仅当您可以保证无法在 prod 机器上对 env 变量进行快照时，这才可以.查看认为对您的秘密有害的环境变量了解更多详情.

最后一件事:还有一种基于该想法的技术，即您只需要存储/传递一个 ClientSecret 值，而 ClientId 应根据托管应用程序的机器/容器详细信息(例如 docker容器 ID).我找到了一个 Hashicorp Vault 的例子和一个托管在 AWS 上的应用程序，但总体思路是一样的:使用 Vault 进行秘密管理

And the last one thing: there is also a technic that based on the idea, that you need to store/pass only a ClientSecret value while ClientId should be constructed based on machine/container details where the App is hosted (e.g. docker container id). I have found an example for Hashicorp Vault and an App hosted on AWS, but the general idea is the same: Secret management with Vault