最近，公司推动了安全开发生命周期过程（SDL）的实施。基于目前的业务发展，有很多以API的形式提供的数据访问接口。为此，对所有系统API接口进行了梳理，梳理过程中发现部分接口存在安全隐患，包括未授权访问、数据校验不完整、敏感数据访问等。因此，听说了一些针对API可能带来的安全问题的安全解决方案，一起交流学习。随着业务开放的发展趋势，为了应对快速增长的业务和灵活的程序需求，API（ApplicationProgrammingInterface）在程序中的应用变得越来越重要。灵活性和创新性。但与此同时，API应用也带来了一系列安全问题，如任意访问、数据泄露、用户信息被盗等。API的不当使用可能会破坏数据的机密性、完整性和可用性。安全的API仅对使用它的用户、应用程序和服务可见，以确保信息的机密性；此外，还必须保证客户端与服务器之间交换的信息没有被第三方篡改过，从而保证信息的完整性。为满足信息的保密性和完整性，对呼叫者和终端用户的身份认证是前提。身份验证可以说是安全世界的核心。API创建者需要能够识别使用API的用户、应用程序和服务，因此需要有一个身份存储库来识别和确认用户和应用程序身份的有效性。身份存储最常用的解决方案是LDAP服务，而ActiveDirectory(AD)目前是LDAPVPN的一种实现。LDAP服务主要存储用户名、密码、数字证书等与用户相关的身份信息和用户组织信息，应用程序身份信息也可以存储在这里。身份提供者（IP）是专门用于管理与身份库交互以进行身份??验证和授权的软件。APP可以将身份认证和授权的工作交给身份提供者，是一种更加安全和可取的方法。当调用者使用应用程序ID和用户名调用您的API时，API需要能够识别调用者提供的信息的有效性。这种有效性验证主要是通过验证共享秘密信息来完成的。当您的API作为身份提供者时，它通常会将相同的身份验证信息传递给LDAP服务以进行身份??验证。下面介绍几种常用的API认证方式。第一种是用户名密码方式，也是最简单的认证方式。这样实现系统间鉴权时，鉴权密码可能会在多个API之间共享。不推荐使用用户名和密码的认证方式，主要基于两方面的考虑：一是由于密码的可猜测性，密码是人为生成的，安全性较低；其次，密码维护困难，比如修改一个API的密码来进行身份认证，会影响到所有关联的应用。第二种是多因素认证（MFA），即在用户知道什么的前提下，通过用户拥有什么来进一步验证身份，通过获得的一次性令牌进一步验证用户的身份证明用户。此令牌可以是MFA服务提供商发送的文本消息，也可以是数字密钥。目前已有成熟的第三方数字密钥服务商。开源的有GoogleAuthenticator和FreeOTP，商业的有RSASecurID。第三种方式是基于Token的身份认证凭证，它是对用户名和密码安全性的补充，为用户名和密码的认证和授权提供了更安全的方式。身份提供者根据用户名和密码的身份凭证生成一个独立的令牌。随后与应用程序的交互只需要将令牌传递给应用程序，因此大大减少了通过网络来回切换的用户名/密码凭证的数量。同时，令牌设置了过期时间，可以撤销，保证了令牌使用的安全性。更重要的是，为每个应用程序生成相应的独立令牌。当某个token被撤销或作废时，其他应用仍然可以正常使用自己的token，无需重新验证用户名和密码。如下图所示，用户Gary登录到应用程序。应用程序验证其用户名和密码身份信息，并向身份提供者申请令牌。身份提供者验证身份存储库中Gary身份的有效性。验证通过后，身份提供者向应用返回token，然后应用就可以使用这个token作为调用API的身份凭证。这也是目前网络认证协议Kerberos的基本原理。接下来要介绍的是联邦身份认证机制。基于令牌的身份验证允许将令牌的颁发与其验证分开，从而促进身份管理的集中化。API开发者只需要关心用户调用API时的验证逻辑，不需要关心具体的身份认证逻辑。这部分由中心化身份提供者完成。API只需要在请求中带上token，然后由中心化的正式身份提供者完成token的验证，如果生成的token有权限发起这个请求，API就会被调用。身份提供者可以根据存储在身份库中的身份信息和共享密码来识别和验证用户、应用程序和APP的身份。但是，您的API并不总是暴露给身份提供者可以识别的应用程序和用户。如果你想把你的API暴露给外部用户控制的应用程序，外部用户可能来自其他公司或者公司内部的其他业务部门。此时如何控制API的安全性？特别是对于大公司来说，他们有很多安全上下文，每个安全上下文都包含一个独立的身份存储库和身份提供者。这时，应该使用联合身份机制。这样，联合身份提供者就可以对来自不同安全上下文的用户进行身份验证和授权。联邦身份认证机制的流程如下图所示，与普通的基于token的身份认证流程类似，只是在流程中增加了物流API和物流系统身份提供者两个角色，应用使用订单系统身份提供者返回的有效token申请访问物流API。物流API向物流系统身份提供者申请验证token的有效性，但不知道token是否有效。它必须向订单系统身份提供者申请验证令牌，而不是在物流身份库中检索它。这个token的信息，这里的订单系统的身份提供者和物流系统的身份提供者是联合身份提供者。身份认证完成后，需要根据用户的身份进行授权，其权限的大小由其身份决定。下面介绍API安全中使用的几种授权模式。第一种是最常用的基于角色的访问控制模型。每个企业或组织的员工都根据其业务职责分为不同的部门或小组。这些组织内的员工然后根据他们的分组来定义他们的权限。组信息可以应用在应用交互中，根据应用权限限制用户访问，为应用中的不同组设置访问规则，用户所在的组决定了其在应用中的角色和权限。轻型目录访问协议(LDAP)服务利用组的概念。身份提供者负责从身份存储中获取分组信息，角色是应用程序访问控制权限的具体定义，用户可以采用应用程序定义的多个角色。基于角色的访问控制是一种非常简单的访问控制机制。应用程序不需要维护每个用户可以访问的数据和功能。它只需要通过角色抽象出数据和功能的访问权限，只需要根据用户的角色分配不同的访问权限即可。第二种授权方法是基于属性的访问控制模型(ABAC)。与静态的基于角色的访问控制方式不同，基于属性的访问控制旨在根据用户调用API时的环境信息动态分配访问控制权限。环境信息包括诸如访问时间、角色、API的地理位置、应用程序的地理位置以及其他决定访问程度的条件的组合信息。可扩展访问控制标记语言(XACML)是一种基于XML的开放标准语言。它是一种通用的访问控制策略语言，用于确定请求/响应和实现授权策略的框架。它可以在调用API时定义访问控制规则，这种规则可以在不同的API调用时动态变化，是典型ABAC环境下的策略描述语言。三是基于Oauth2.0的代理访问控制方式。基于HTTP的OAuth2.0框架允许应用程序代表自己或代表用户访问API资源。因此，它允许用户将访问控制委托给第三方应用程序。为此，您的API接口必须与OAuth2.0授权服务器合作，以检查每次请求访问令牌时是否都经过授权服务器的验证。授权服务器向请求者返回响应，表明访问令牌是否有效，是否由OAuth提供者生成且未过期，同时验证令牌可以访问的范围。说到联合身份机制，就不得不提到安全断言标记语言（SAML）。安全断言标记语言(SAML)是一种行业标准，已成为企业级身份联合的事实标准。它允许身份提供者以标准方式将有关用户的身份验证和授权信息传递给服务提供者。SAML断言可以由一个安全上下文中的身份提供者发布，并由另一个安全上下文中的身份提供者理解。SAML断言通常将有关用户的信息传递给另一个身份提供者，包括用户所属的组织以及断言的到期时间，而不提供密码信息。验证断言有效性的身份提供者必??须与发布断言关系的身份提供者建立信任。在企业中使用SAML的主要场景是单点登录(SSO)。用户无需为每个需要登录的应用单独维护一套身份信息，只需向服务商注册登录一次，即可畅通无阻地访问其他应用。.这里介绍一种常用的单点登录身份认证协议——OpenIDConnect。OpenIDConnect基于OAuth2.0构建，提供身份联合来保护您的API。不仅可以支持原生和移动应用，也适用于企业级应用。其基于JSON/REST的协议使其应用程序更简单、更快速。它是一种更轻量级的企业内单点登录解决方案。与Oauth2.0的accesstoken不同，OpenIDConnect使用JWTIDtoken，其中包含已认证用户的标准格式信息。API可以通过调用身份提供者上的用户信息端点来确定访问控制策略，以验证用户是否属于某个角色。与SAML断言一样，JWTID令牌经过数字签名，因此联合身份提供者可以根据他们与颁发它们的身份提供者的信任关系来决定是否接受此令牌。认证和授权是API安全的先决条件。一个安全的API应该能够识别系统和调用它的最终用户的身份。本文介绍了几种身份验证和授权机制，以增强API的安全性。在实际应用场景中，可以根据具体情况采用不同的实现方式，希望大家多多交流API安全方面的经验和问题。
