能否修改Microsoft Graph API重定向URI的code参数名称？

首先直接给结论：Microsoft Graph API不支持自定义授权码的参数名称——因为OAuth 2.0授权码流程中，code是标准定义的参数名，Graph严格遵循这个规范，没法修改它返回的授权码参数名。不过我们可以从Azure Functions这边调整，避开参数冲突的问题，下面是几个可行的解决方案：

方案1：改用HTTP请求头传递函数密钥 #

Azure Functions支持通过x-functions-key请求头来传递函数访问密钥，而不是依赖查询字符串的code参数。这样你的重定向URI可以保持为https://<your-function-app>.azurewebsites.net/api/processCode，当Graph API重定向过来时，请求里的code参数是授权码，而你可以在函数的请求处理逻辑中，通过读取请求头x-functions-key来验证密钥（如果你的函数设置了需要密钥的授权级别）。

比如用C#编写Azure Function时，读取密钥的代码示例：

var functionKey = Request.Headers["x-functions-key"];
// 此处添加密钥验证逻辑

方案2：调整函数的授权级别 #

如果业务场景允许，可以将processCode函数的授权级别改为匿名（在函数的function.json里设置authLevel为anonymous）。这样就不需要传递任何函数密钥，Graph API的code参数可以直接被函数接收。

⚠️ 重要提醒：设置匿名授权后，任何人都可以访问这个函数，所以一定要在函数内部添加额外安全验证：

• 验证Graph返回的state参数：发起授权请求时生成一个随机的state值并存在会话或缓存中，在processCode函数中检查返回的state是否与之前生成的一致，防止CSRF攻击。
• 验证授权码的合法性：调用Microsoft Graph的令牌端点交换令牌时，确保请求的来源和参数符合预期，避免恶意提交无效的code。

方案3：添加中间层转发请求 #

如果上面两种方案都不适合你的场景，可以搭建一个简单的中间层（比如另一个Azure Function或者Azure API Management实例）：

• 用中间层的地址作为Graph API的重定向URI，接收包含code参数的请求。
• 中间层将函数密钥通过x-functions-key头或其他非查询字符串方式传递，再把请求转发到你的processCode函数。
• 中间层承担参数转换的工作，彻底避免code参数的冲突。

额外安全提示 #

• 无论采用哪种方案，都要确保函数密钥的安全性，不要在客户端代码、公开日志或URI中暴露密钥。
• 处理授权码时，要尽快调用Graph的令牌端点交换令牌，授权码有有效期且只能使用一次，避免被窃取滥用。

内容的提问来源于stack exchange，提问作者miguelarcilla