适用于桌面应用程序的受OpenID Connect保护的API

Question

我正在构建将连接到API的WPF .NET Windows应用程序。因为我们还有其他API，所以我想开始将所有登录逻辑放到以标准化方式处理它的单个模块/服务中。我认为OpenID Connect（OIDC）是一个很好的协议。

据我所知，PKCE的授权码流程是解决问题的方法。我希望有人为我确认是否要以正确的方式进行操作。以下是我想实现的流程：

1. 用户启动应用程序，并通过嵌入式浏览器（通过带有PKCE流程的代码）登录到我们的OIDC提供程序。客户端是我们的本机应用程序，范围仅限于“配置文件”“ the-api”。
2. 用户登录后，使用应用程序可以拦截的POST重定向返回刷新令牌和访问令牌。
3. 本机应用程序使用该访问令牌来获取用户信息并在应用程序中显示配置文件信息。
4. 本机应用程序使用access_token向API发送请求。
5. api通过检查OP的userinfo端点处的access_token并确保其具有适当的范围来验证用户。

我认为本机客户端应在将每个请求发送到API之前检查access_token。如果access_token已过期或即将过期（可能在<30秒内），则在发送请求之前先获取新的access_token。

让我不确定的是没有重定向到API。许多流程将用户重定向到OP，然后重定向回API。我想它之所以没有，是因为它是本机的，并且不像浏览器那样直接支持重定向到页面。

我要按照正确的方式进行吗？

Answer 1

我认为OpenID Connect（OIDC）是一个很好的协议

如果要将用户身份与应用程序分开，

OIDC和OAuth 2.0是最佳选择。这意味着您不将它们保留在应用程序的末尾，而是通过例如Azure AD，ADFS甚至Google进行访问。如果您更喜欢基于令牌的身份验证和授权，这也是正确的选择。这意味着您信任授权服务器（也称为身份提供者或OP）颁发的令牌，该令牌比通过基本身份验证传递用户名/密码更安全。

使用PKCE进行授权代码是这里的方法

正确。在用户的Windows计算机上运行的本机应用程序（例如正在创建的本机应用程序）应将PKCE与auth一起使用。代码流。

关于流程

我不确定第二步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令牌。它包含最终用户信息。请从protocol's explanation中查看更多信息。

从API端开始，是的，它必须根据API请求随附的访问令牌检查调用的有效性。为此，它可以第一次使用user_info端点，因为它看到一个新的访问令牌，然后缓存详细信息。并且在以后的调用中，它可以使用缓存的信息来检测用户信息。同样，某些OP发送基于JWT的访问令牌，您的API可以读取和检测到期详细信息。

我认为本机客户端应在将每个请求发送到API之前检查access_token。

不！必须是API才能执行此检查。否则，API将盲目接受可以由某些恶意客户端发送的令牌。将此实现到API端，如果访问令牌无效，则发送401-未经授权的响应。