我正在尝试使用ASP.NET Core和IdentityServer4为SPA React客户端实现授权代码流。
有两种情况：
1）用户打开SPA应用程序，我们检查他是否具有访问令牌，如果没有，则生成
之类的网址/connect/authorize?
client_id=*client_id*&
redirect_uri=*redirect_uri*&
response_type=code&
response_mode=fragment&
state=*some_state*&
nonce=*some_nonce*&
code_challenge=*code_challenge*&
code_challenge_method=S256&
scope=openid profile email
因此，授权码流开始。这非常清楚，并且在所有往返之后，用户都使用代码返回SPA应用程序，然后发送令牌请求（包括代码和code_verifier），然后接收令牌，并衷心地继续使用我们出色的应用程序。
2）用户直接打开登录页面，这就是我遇到的问题。 IdentityServer上下文对此用户一无所知，也不了解代码挑战等，因为像往常一样，在转到此页面之前，我们没有向/connect/authorize发出请求。下一步是什么？
我可以直接在登录页面上生成/connect/authorize链接，然后进行丑陋的重定向，然后返回登录页面（我不想做的事情），但是我的SPA应用程序将如何知道我使用了什么code_verifier在这里产生？当然，我可以将其存储在一些共享的跨域Cookie中，但是我认为这应该是更好的方法。
另一种解决方案，我可以将用户从登录页面重定向到我的应用程序，它可以识别出该用户未被授权，因此我们开始了方案1。同样不是我想去的方法。
如果用户直接打开我的身份服务器页面该怎么办？ 是否可以使用授权码流，还是应该考虑将其他一些流与此流结合？
由于OAuth 2.0规范的新建议，我不想使用隐式流程。
答案 0 :(得分：1)
对此的一个简单答案-在第二种情况下-如果用户直接打开IDP登录页面，则他们不想转到您的应用程序。如果您在SPA中使用Google或Facebook或其他已知的IDP之一，那也是一样，而作为用户，我只是去了他们的登录页面。他们可能无法知道我是否打算登录，以便稍后将我重定向到您的SPA。
现在已经说了一切-您可以做些什么来使这项工作更无缝-您可以在用户通过Identity Server 4登录后重定向到SPA的受保护页面（这很简单，因为您拥有登录页面，并且没有此处涉及OAuth）。然后，您的SPA将被触发以启动OAuth2流并将其重定向回Identity Server4。不过，用户在此处仅几秒钟前就已经登录，因此将跳过登录过程，并向用户显示同意页面，或者您的客户端被配置为跳过同意页面-使用常规令牌等将用户重定向到您的SPA。
因此，将其分解为流程：
用户访问IDS4登录页面->用户输入凭据-> IDS4 对用户进行身份验证并重定向到您的SPA保护页面->您的 SPA启动OAuth2流并重定向回IDS4-> IDS4显示 同意页面-> IDS4将身份验证代码发回到您的SPA。
这里当然还有额外的步骤，您的SPA会将身份验证代码交换为访问令牌，但是为了清楚起见，我省略了它，因为它与问题无关。