我已经使用 Azure AD / Oauth2 / Graph 测试了以下登录流程（伪代码）。它工作完美：
在浏览器中重定向到 MS365 获取令牌：https://login.microsoftonline.com/$tenantid/oauth2/v2.0/authorize?client_id=$appid （设置更多 GETters，为简洁起见省略） 这意味着租户 ID 和应用 ID 对每个人都是完全可见的。
如果已经登录，MS 令牌将通过重定向返回到我的应用程序。如果未登录，则初始化 MS365 身份验证过程，成功后执行带有令牌的重定向。
我的服务器使用标题“Authorization：Bearer $ms365token”进行反向通道连接到https://graph.microsoft.com/v1.0/me/。检查返回的值是否有 userPrincipalName，并且假定该用户已登录（我完全意识到这会导致令牌窃取，在这个测试阶段这并不重要）。
我的问题如下：
a) 应用程序 ID 真的存在安全风险吗？在许多地方都提到不应以明文形式显示。然而，这似乎很难避免，如果不加密整个字符串，或者执行一些先前的反向通道“登录令牌”请求（我不知道是否有这样的方法）。一些 MS 消息来源似乎承认隐藏应用程序 ID 确实毫无意义。
b）我根本没有使用过客户端密钥。在这种情况下该如何实施呢？真的会增加安全性吗？
该流程完全正常工作，我只是不确定流程的有效性，以及如果我必须在其位置发送客户端密钥，则尝试隐藏应用程序 ID 的意义。
我来回答一下问题吧
a) 应用程序 ID 安全性： 客户端ID的暴露，通常认为客户端知道client_id不需要保密是可以接受的。授权服务器 (Azure AD) 使用它来识别发出请求的应用程序。
暴露 client_id 的安全风险是最小的，特别是当您使用授权代码流程并在服务器端正确验证令牌时。仅客户端 ID 不足以让某人冒充您的应用程序。
b）客户端密钥用于机密客户端场景，其中客户端（您的服务器）可以安全地存储和使用密钥。它用于在令牌交换期间向授权服务器验证您的应用程序。
如果您的应用程序是公共客户端，这意味着它在无法信任安全存储密钥的设备上运行，则使用客户端密钥可能不合适。相反，公共客户端经常使用其他身份验证方式，例如 PKCE。
PKCE 是为无法安全存储客户端机密的公共客户端提供的额外安全层。它涉及为每个授权请求创建一个秘密并在令牌交换期间验证它。