为什么API管理平台必须使用IAM？

英文版下载链接：Why IAM is a Must in API Management

API是任何数字化转型过程中的关键组件。API帮助组织创建新的商业模式，并与合作伙伴和客户建立联系，同时通过将系统和服务链接在一起来提供无缝的数字化体验。 在API经济中，所有现代架构概念都深深地依赖于API。

访问委托是API生态系统中的主要安全要求，委托允许其他人将代表您访问API，并且您需要将相应的访问权限委派给应用程序或服务。用户名和密码的认证方式已经不再是推荐的方式。OAuth 2.0已经成为实际上的访问委托规范。使用OAuth 2.0时，访问令牌（权限和有效时间受限）可以与第三方共享，OIDC和OAuth 2.0一起负责API管理平台的身份认证。

从本质上讲，随着数字产业的发展，黑客也会随之而来。 因此，随着API成为行业规范，黑客已经寻求突破API生态系统的新方法。 暴露的数据的性质和数量，加上API的指数级使用，增加了攻击面和破坏力。 公开敏感数据（例如，个人身份信息（PII））使公司损失了数百万美元的赔偿，并导致公关恶梦。 例如，Facebook因其在Cambridge Analytica数据丑闻中的作用而被英国数据保护监管机构罚款500,000英镑。 雅虎因两次安全漏洞暴露了超过10亿用户的个人信息损失了3.5亿美元。

在典型的API管理平台中，密钥管理组件或授权服务器主要侧重于访问委托或安全地管理访问令牌。 但是，API安全性超出了简单的授权功能。 有关更多详细信息，请参考开放式Web应用程序安全性项目（OWASP）的最新API安全性Top 10。 这就是为什么我们需要API平台中的身份和访问管理（IAM）解决方案来填补此安全漏洞的原因。 IAM解决方案不仅可以增强安全性，还可以带来其他功能以增强数字转型的工作。以下IAM功能在你的API管理平台中必不可少。

• 扩展访问委托功能
• 最终用户身份管理
• 强大的自适应身份认证
• 跨协议单点登录/注销
• 身份联邦和社交账号登录
• 授权增强
• 隐私管理

扩展访问委托功能

OAuth 2.0核心规范定义了四种主要的授权类型：授权码，客户端凭据，设备码和令牌刷新。但是OAuth2.0框架支持扩展以支持更高级别的授权场景，比如SAML 2.0或Kerberos OAuth2的授权。在基于SAML 2.0的授权中，如果已经登录支持SAML协议的应用，可以将相同的SAML 2.0 令牌交换为OAuth2.0 的令牌，而这个过程不影响用户体验，不会提示客户重新授权。如果是在Windows环境中，则可以使用相同的Windows登录凭据并使用Kerberos令牌获取OAuth访问令牌。如果只是一个基本的API管理平台，基本的授权委托已经可以满足要求。但是API管理组件是应用程序的核心，因此需要支持扩展的需求，将API管理平台和IAM解决方案集成可以提供高级的访问委托功能。OAuth 2.0 只提供访问授权但是不显示用户身份。如果需要用户身份，可以使用基于OAuth 2.0的OIDC，OIDC通过访问令牌和一个JWT类型的令牌提供用户信息，这是IAM解决方案的主要功能之一。

最终用户身份管理

API管理平台可以在组织内部或外部使用。不论哪种情况，API都将会被人，设备或万物使用。因此，管理数字身份成为任何API管理平台的重点。解决方案必须处理不同的身份类型：可能是人或设备又或者是人和设备都可以访问相同的系统。访问系统的身份数量可能从数千到数百万不等。这些数字身份通常存储在异构身份存储中。

此外，用户如何更改忘记的密码，如何定义密码强度，最终用户可用来恢复其凭据的机制以及管理员是否可以（经同意）访问用户帐户是所有系统在处理身份认证时必须解决的一些典型问题。

身份管理十分的复杂，但是IAM解决方案可以有效性的管理这些复杂性。身份可以以不同的形式存在于多个身份存储中，也许一个身份可以分布在多个身份存储中。这些只是身份管理带来的众多担忧中的一小部分。在API管理平台的初始阶段，你可能不会遇到这些问题，但是从一开始就拥有正确的IAM系统可以确保您的平台已准备好应对未来的挑战。

强大自适应认证

在API安全性的背景下，通常，我们将重点放在访问委托或安全地管理访问令牌上。 这掩盖了最终用户身份验证的重要性。即使是现在，基于用户名和密码的身份验证仍是最常用的身份验证机制。尽管非常的方便，但是基于用户名和密码的身份呢验证也是最不安全的机制。

多因子认证可以解决用户名和密码认证的安全问题。多因子认证实现了分层防御，使得没有权限的用户更加难以访问目标，比如获取地理位置，计算设备，web服务，网络或数据库。多因子认证基于以下假设：即使有一个因子被破解或破坏，攻击者在访问目标对象之前仍有一个或多个屏障阻碍器非法访问，因此多因子认证更加安全。MFA中的纷纷认证因子从三类独立凭据中选择两个或多个独立凭据。

• 知识因子-只有用户知道，比如密码
• 持有因子-只有用户拥有，比如信用卡
• 固有因子，只有用户是，比如指纹

多因子认证提供的安全级别使其成为当今世界最优秀的认证机制。即使黑客攻破了其中一个因此，黑客攻破其他所有因子的可能姓也十分的低。

相反的，尽管MFA提供了更高的安全性，但是MFA的可用性比较差。静态身份验证流程对不同的用户集不方便。与此相反，自适应身份验证具有基于上下文切换身份验证流程的能力。这不应被误认为是取代MFA的完全不同的机制。自适应身份验证在用户身份验证过程中根据上下文编排不同的身份验证器。最好的部分是，大多数时候用户甚至都不知道身份验证过程已更改。自适应身份验证在当前身份验证过程上下文中智能地收集各种因素，并将身份验证流程提供给用户。

跨协议单点登录/登出

乍一看，API管理平台的重点是安全地管理系统中公开的API。但是，在一个完整的数字转换项目中，API集成只是一小部分，消费者希望访问多个应用程序来执行给定的业务用例。单点登录可以确保使用跨不同数字资产的通用凭据登录的体验一致性。

很少有授权服务器可以支持基于OIDC的单点登录。即使现代应用程序支持基于OIDC的联盟，但是大多数应用程序仍广泛使用SAML，而且有些应用使用Ws。在多数的数字化转型项目中，应用程序使用了所有这些协议，因此我们需要选择一个可以支持所有身份联盟协议的IAS解决方案。IAS解决方案必须能够支持跨协议的单点登录/登出。

如果平台包含使用专有协议进行联盟的旧版应用程序，则您的IAM解决方案也应该能够扩展其对这些非标准化协议的联盟身份验证支持。

授权增强

身份验证通过授权验证用户或设备的身份，以查看已验证身份是否可以执行给定的操作或访问数据。换而言之，授权可确保用户或设备只能访问其有权访问的内容。对于API的授权需要从两个层级考虑：在API入口点验证授权，以查看该用户是否可以执行给定的操作；在代码验证用户是否有权访问开放的数据。

OAuth 2.0的Scope是实施资源级授权的最佳选择。可以在后端服务或API网关实现，推荐在API网关进行验证，这样整体流程更加清晰。在基本的OAuth 2.0请求校验流程中，Scope的校验可以在两个地方完成。在身份验证请求流中（授予访问权限之前），检查经过身份验证的用户是否有资格授予请求的Scope，然后，当涉及到API调用时，应该进行另一个验证，以检查在给定范围内是否可以访问该API。另一个是在初始授权验证中，如果使用基于秘钥管理组件的IAM解决方案，则可以使用更细粒度的XACML或OPA进行授权。

然后，我们需要在API实施级别中验证授权，以防止未经授权访问敏感数据。即使用户有权限调用给定的API，也可能无法访问敏感数据。这需要在代码级别进行验证，这需要传递用户信息。这是JWT令牌的另一个使用场景，可以将已认证的用户信息与JWT令牌一起传递到下游服务中。

身份联邦和社交登录

隐私管理

一个完善的API管理平台应当能够吸引开发者与其交互，而且一个蓬勃发展的开发者社区是平台成功的一个标志。判断一个API管理平台成功的指标之一便是围绕它的开发者社区。开发者通常使用Git，而且至少拥有一个社交帐号，比如Facebook，Twitter和LinkedIn。允许开发者使用社交账号登录API管理平台将会吸引更多的开发者。

即使在内部使用API管理平台，也可能有多个业务部门，业务部门的员工希望使用原来的账号登录API管理平台。对于这种特殊场景，可以使用身份联邦允许内部用户无缝的访问新平台。即使组织的规模不断扩大，例如在收购和兼并之后，可以使用身份联邦简化身份继承并在几分钟之内加入新的用户。

总结

API是任何数字化转型过程中的主要元素。 API使用率的指数级增长使其成为黑客的主要目标，因此API的安全性非常重要。API平台各不相同，因此，API安全基础设施应设计为满足每个API平台的独特要求及其敏感性。

在不断发展的API平台中，消费者是主要资产，身份管理是基础。API使用者需要无缝的登录体验以及增强的安全性。信任和隐私是监管机构和消费者的主要期望。因此，正如我在本文中讨论的那样，将您的API管理解决方案与企业身份和访问管理解决方案相结合现在比以往任何时候都更为关键。