如何通过OAuth2.0与Azure Functions实现受保护API调用（授权码流）

你担心重定向破坏应用状态的问题完全可以避免：授权码流的重定向仅在首次授权/授权过期重新走同意流程时触发，令牌持久化存储后，后续所有业务API调用都不需要再触发重定向，不会干扰正常业务逻辑运行。

前期配置准备 #

• 先在目标API对应的身份提供方完成应用注册，重定向URI直接配置为固定的Function回调地址：线上环境格式为https://<你的Function应用名>.azurewebsites.net/api/oauth/callback，本地调试时额外把http://localhost:7071/api/oauth/callback加入重定向白名单即可，不要在线上地址里加自定义端口，Azure Function线上仅对外暴露443端口，自定义端口会导致回调失败。
• 记录好5个核心参数：客户端ID、客户端密钥、身份提供方的授权端点、令牌端点、目标API要求的权限范围，所有参数存在Function应用配置中，禁止硬编码到代码里。

核心代码实现 #

总共只需要两个HTTP触发的Function，搭配一个持久化缓存（Azure表存储、Redis都可以，本地调试用内存缓存也行）存令牌即可：

• 授权发起端点（路由可设为/api/oauth/start）：收到请求后先生成随机字符串作为state参数（用于CSRF校验，也可绑定调用上下文标识），存入缓存并设置10分钟过期，随后拼接标准授权URL返回302重定向，引导至身份提供方的授权页面。核心拼接逻辑参考：

var encodedRedirectUri = WebUtility.UrlEncode(redirectUri);
var encodedScope = WebUtility.UrlEncode(apiScope);
var authUrl = $"{idpAuthorizeEndpoint}?client_id={clientId}&response_type=code&redirect_uri={encodedRedirectUri}&scope={encodedScope}&state={state}";
return new RedirectResult(authUrl);

• 授权回调端点（路由就是之前配置的/api/oauth/callback）：接收身份提供方重定向带回的code和state参数，先校验state和缓存中预存的值是否一致，拦截伪造请求。校验通过后，向身份提供方的令牌端点发POST请求，携带授权码、客户端凭证、重定向URI，换取access_token、refresh_token和令牌过期时间，将三个值加密后存入持久化缓存，最后返回授权成功提示或重定向回业务前端即可，到这一步首次授权流程就全部完成。
• 公共令牌拦截逻辑：所有需要调用目标受保护API的业务接口，执行前先从缓存取令牌，如果令牌剩余有效期不足5分钟，就用存储的refresh_token调用令牌端点换取新令牌，更新缓存后再用新令牌发起目标API调用，整个过程自动完成，不需要用户参与，也不会触发重定向。

注意事项 #

• 回调端点不要开启Function自带的授权校验，否则身份提供方发起的重定向请求会被拦截，拿不到授权码。
• 存储refresh_token时必须做加密处理，禁止明文存储，避免令牌泄露。
• 如果你的服务是无用户交互的后台服务场景，只需要在部署完成后手动访问一次/api/oauth/start接口走完一次授权流程，后续服务会自动通过refresh_token续期令牌，不需要人工干预，完全不会影响业务接口的正常运行。
• 不要在回调逻辑里写和业务状态强绑定的操作，回调只负责令牌的获取和存储，业务逻辑和授权流程完全解耦就不会出现状态被破坏的问题。

内容的提问来源于stack exchange，提问作者DONAR144-Release