我正在构建一个WPF.NET窗口应用程序，该应用程序将连接到API。因为我们还有其他API，所以我想开始将所有登录逻辑放入一个以标准化方式处理它的模块/服务中。我认为OpenID Connect(OIDC(是一个很好的协议。
据我所知，使用PKCE的授权代码流是实现这一目标的方法。我希望有人能帮我确认一下我的做法是否正确。以下是我认为需要实现的流程：
- 用户启动应用程序，并通过嵌入式浏览器登录到我们的OIDC提供商(通过PKCE流执行代码(。客户端是我们的本机应用程序，范围仅限于"概要"api">
- 用户登录后，使用应用程序可以拦截的POST重定向返回刷新令牌和访问令牌
- 本机应用程序使用该访问令牌来获取用户信息并在应用程序中显示配置文件信息
- 本机应用程序使用access_token向API发送请求
- api通过检查OP的userinfo端点上的access_token并确保其具有正确的作用域来验证用户
我认为本机客户端应该在向API发送每个请求之前检查access_token。如果access_token已过期或即将过期(可能在<30秒内(，则在发送请求之前获取新的access_toke。
让我感到不确定的是，没有重定向到API。许多流将用户重定向到OP，然后重定向回API。我想它没有这个功能的原因是因为它是原生的，不像浏览器那样直接支持重定向到页面。
我这样做对吗？
我认为OpenID Connect(OIDC(是一个很好的协议
如果您想将用户标识与应用程序分离，那么OIDC和OAuth 2.0是最佳选择。这意味着你不会把它们放在应用程序的末尾，而是通过Azure AD、ADFS甚至谷歌。如果您更喜欢基于令牌的身份验证和授权，这也是正确的选择。这意味着你信任授权服务器(也称为身份提供者或OP(发布的令牌，这比通过基本身份验证传递用户名/密码更安全。
使用PKCE的授权代码流是此处的方法
正确。本机应用程序，例如您正在创建的应用程序，运行在用户的windows机器上，应该使用带auth的PKCE。代码流。
关于流程
我不确定第二步，After the user logs in, the refresh token and access token are returned using a POST redirect that the application can intercept.，我想你是从授权请求中获得令牌吗？不确定您在这里的意思，但理想情况下必须在用户登录浏览器实例后获得授权代码。一旦得到，就必须直接调用身份提供程序的token端点。您通过此令牌请求获得令牌。它还有PKCE完成步骤。
也称为The native application uses that access token to get user info and display profile information in the app。为此，您可以使用令牌响应中的ID令牌。它包含最终用户信息。请从协议的解释中查看更多信息。
从API端，是的，它必须根据API请求附带的访问令牌检查调用的有效性。为此，它可以在第一次看到新的访问令牌时使用user_info端点，然后缓存详细信息。在以后的调用中，它可以使用缓存的信息来检测用户信息。此外，一些OP发送基于JWT的访问令牌，您的API可以读取并检测到期详细信息。
我认为本地客户端应该在向API发送每个请求之前检查access_token
不。！必须由API进行此检查。否则API将盲目接受某些恶意客户端可能发送的令牌。将其实现到API端，如果访问令牌无效，则发送401-未授权响应。