您的问题类似于this one。区别在于，您将应用程序部署在cloudfoundry中，另一个部署在Azure Web应用程序中。

如果您的应用被强制使用https，则可以简单地强制redirect_uri使用https。

如果您想使用http和https都可以使用的通用解决方案（前提是您已经在Azure门户中将http和https配置为重定向URL），则可以尝试在标头中找到真实的原型。 / p>

Tony Ju提供了与类似问题的出色链接，帮助我缩小范围并最终解决问题。

但是，该解决方案仅提供代码示例，我想多写一些最终实现的方法。

当您的应用程序位于代理服务器和/或负载平衡器之后时，就会出现此问题。代理会模糊有关初始请求的信息（例如原始架构），从而使依赖于此信息的应用程序中的服务行为不正确（例如return_url）。

There is an excellent documentation about how to configure your ASP.NET Core application。

在文档中，这是我问题的根本原因。

  

通过HTTP代理HTTPS请求时，原始方案（HTTPS）   丢失，必须在标头中转发。

还有the Cloud Foundry Security documentation tells the following：

  

协议   从公共互联网到Cloud Controller的所有流量   而UAA通过HTTPS进行。在系统边界内   组件通过发布-订阅（pub-sub）消息总线进行通信   NATS，HTTP和SSL / TLS。

简而言之，您需要使用标准Middleware转发某些HttpHeaders。

services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders = 
        ForwardedHeaders.XForwardedFor | ForwardedHeaders.XForwardedProto;
});

app.UseForwardedHeaders();

但是，当您的应用程序部署在没有IIS作为代理的linux计算机上时，.net core 2.1存在一个已知问题。 当您添加UseHttpRedirection中间件时，这一点变得更加明显。

取自this blog post：

  

OAuth和OIDC在此配置中也会失败，因为它们会生成   错误的重定向。调用UseIISIntegration添加并配置   在IIS上运行时转发的标头中间件，但没有   匹配Linux的自动配置（Apache或Nginx   积分）。有关此问题的修复，请参见   文档文章Forward the scheme for Linux and non-IIS reverse proxies。

这篇文章最终还提供了针对当前情况的工作解决方案。

    services.Configure<ForwardedHeadersOptions>(options =>
    {
        options.ForwardedHeaders = ForwardedHeaders.XForwardedFor | 
            ForwardedHeaders.XForwardedProto;
        // Only loopback proxies are allowed by default.
        // Clear that restriction because forwarders are enabled by explicit 
        // configuration.
        options.KnownNetworks.Clear();
        options.KnownProxies.Clear();
    });

.net core 3看起来不再需要这样，但是SAP尚未更新其dotnet容器，因此在撰写本文时我无法对其进行验证。