是否可以使用客户端凭证授予类型来验证将由 SailPoint(IAM) 使用的 WEB API

Posted 2023-03-31

【中文标题】是否可以使用客户端凭证授予类型来验证将由 SailPoint(IAM) 使用的 WEB API

【英文标题】：Is it okay to use client credentials grant type for authentication of a WEB API going to be consumed by SailPoint(IAM)

【发布时间】：2021-02-15 11:09:39

【问题描述】：

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

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

我是 OAuth 新手，以下是我遇到的授权类型。但不确定在这种特定情况下我应该使用哪一个。 1.隐式授予 2.资源所有者密码凭证授予 3.客户凭证授予 4.授权码授予

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

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

【参考方案1】：

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

查看这篇文章了解更多详情 - https://dzone.com/articles/four-most-used-rest-api-authentication-methods（我自己的粗体部分）

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

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

隐式 — 此流程要求客户端检索 直接访问令牌。它在用户的情况下很有用 凭据不能存储在客户端代码中，因为它们可以 很容易被第三方访问。适用于网页、桌面、 和不包含任何服务器组件的移动应用程序。

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

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