2

我有一个用 VB.NET 编写的带有 SQL Server 后端的旧 Windows 应用程序。目前，新用户的添加、删除、添加权限等由旧的审批工作流系统管理。获得批准后，将用户详细信息和权利手动插入到 SQL Server 数据库表中。

我正在尝试将此应用程序与SailPoint 的身份和访问管理集成。所以新用户的添加、删除更新和添加权限等都将通过Sailpoint来完成。为此，我需要创建一个可由 Sailpoint 调用的 WEB API 并公开功能（添加用户/删除用户/添加权利）。此 API 的唯一使用者是 SailPoint。

我是 OAuth 新手，以下是我遇到的授权类型。但不确定在这种特定情况下我应该使用哪一个。
1.Implicit Grant 2.Resource
Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant

我已经研究了我们可以用来保护 web api 的不同身份验证方法。但是仍然对在这种情况下应用哪一个感到困惑，因为这个新的 web api 将在互联网上提供。我已经尝试使用OAuth 2.0和密码授权类型来开发 POC，参考这篇文章。但是当我在互联网上阅读文章时，我发现密码授予类型并不那么安全并且已被弃用。

您能否建议在这种情况下使用哪种授权类型（客户端凭据/授权代码/隐式）。我相信当用户直接尝试访问 API 时会使用授权码。在这种情况下，SailPoint 将在其 UI 中插入新用户时以编程方式在后端调用 API。

4

1 回答 1

1

我认为在这种情况下使用客户端凭据是一种很好的方法，因为 IIQ 和您的 Web API 之间的通信可以被认为是 API 到 API 的通信，我的意思是，IIQ 在这种通信中代表自己行事。

有关更多详细信息，请参阅本文 - https://dzone.com/articles/four-most-used-rest-api-authentication-methods（我自己的粗体部分）

OAuth 2.0 提供了几种适用于不同类型 API 客户端的流行流程：

授权码——最常见的流程，主要用于服务器端和移动 Web 应用程序。此流程类似于用户使用其 Facebook 或 Google 帐户注册 Web 应用程序的方式。

隐式 — 此流程要求客户端直接检索访问令牌。当用户的凭据无法存储在客户端代码中时，它很有用，因为第三方可以轻松访问它们。它适用于不包含任何服务器组件的 Web、桌面和移动应用程序。

资源所有者密码 — 需要使用用户名和密码登录。在这种情况下，凭证将成为请求的一部分。此流程仅适用于受信任的客户端（例如，API 提供者发布的官方应用程序）。

客户端凭据—— 用于服务器到服务器的身份验证，此流程描述了客户端应用程序代表自己而不是代表任何单个用户时的方法。在大多数情况下，此流程提供了允许用户在客户端应用程序中指定其凭据的方法，因此它可以访问客户端控制下的资源。

于 2021-04-21T13:43:21.077 回答