简析认证加授权如何使API更安全

近期在公司推广实施安全开发生命周期流程(SDL)，基于目前业务的发展，有很多以API形式提供的数据访问接口，为此专门对所有系统的API接口进行了一次梳理，在梳理过程中发现了部分接口存在的安全隐患，包括未授权访问、数据校验不完整、访问敏感数据等问题。因此在这里针对API可能带来的安全问题听过一些安全解决措施，大家一起交流学习。

随着业务开放性的发展趋势，为了应对快速发展的业务及灵活多变的程序需求，API(Application Programming Interface)在程序中的应用显得愈发重要，API为外部业务对接、系统间的调用提供了灵活性和创新性。然而与此同时，随之而来的则是API应用带来的一系列安全问题，任意访问、数据泄露、窃取用户信息等，API的使用不当都可能破坏数据的保密性、完整性和可用性。

一个安全的API仅可对其用户、应用程序、以及消费它的服务可见，以此确保信息的保密性;除此之外，同时要保证客户端和服务端间交互的信息没有被第三方篡改，以此保证信息的完整性。要满足信息的保密性和完整性，对调用方和终端用户进行身份认证是前提条件。

身份验证可以说是安全界的核心。API创建者需要有能力识别消费API的用户、应用以及调用API的服务，那么就需要有一个身份存储库来识别并确认用户和应用的身份有效性。身份存储库目前最常用的解决方案就是LDAP 服务，而活动目录(AD)是目前对LDAP最流行的一种实现。LDAP服务主要存储用户名、密码、数字证书以及其他用户相关的身份信息和用户所属机构组织信息，应用的身份信息同样可以存储在这里。身份提供者(IP)是专用于管理与身份存储库的交互以用于身份验证和授权的软件，APP可以将身份验证及授权的工作交由身份提供者处理，这是一种更加安全和可取的方法。

当调用者使用应用ID和用户名调用你的API时，API需要有能力识别调用者提供的信息的有效性，这种有效性验证主要是通过验证共享的秘密信息来完成的。当你的API作为身份提供者时，通常会传递同样的身份认证信息到LDAP服务进行验证。下面介绍几种常用的API身份验证的方法。

第一种就是用户名密码方式，这也是最简单的一种认证方式。系统间身份认证使用这种方式实现时，身份认证使用的密码可能会在多个API间进行共享。用户名密码身份认证方式并不推荐使用，主要是基于两方面的考虑：首先是由于密码的可猜测性，密码是人为生成，安全性较低;其次是密码的维护工作也存在困难，例如修改某个API进行身份认证的密码，那么所有相关联的应用都会受到影响。

第二种是多因素认证方式(MFA)，即在用户知道什么的前提下，进一步通过用户有什么进行身份验证，通过用户获取到的一次性token来进一步验证用户身份凭证。这个token可以是MFA服务提供者发送的短信，也可以是数字key，目前已经有成熟的第三方数字key服务提供商，开源的有Google Authenticator、FreeOTP，商用的则有RSASecurID。

第三种方式是基于Token的身份认证凭证，是对用户名密码安全性的补充，为用户名密码的认证和授权提供了一种更加安全的方式。身份提供者基于用户名密码的身份凭证生成一个独立的token，后续与应用的交互，只需要将该token传递给应用，因此通过网络来回切换的用户名/密码凭证大幅减少。同时，token被设置了过期时间并且可以被撤销，从而保证了token使用上的安全性。更重要的是，针对每个应用都生成对应的独立token，当撤销或者失效某一个token时，其他应用仍可以正常使用自己的token，无需再次进行用户名密码认证。

如下图所示，用户Gary登录应用，应用验证其用户名密码身份信息，并向身份提供者申请token，身份提供者在身份存储库中验证Gary的身份有效性，验证通过后，身份提供者向应用返回token，接下来应用就可以使用这个token作为调用API的身份凭证。这也是目前网络认证协议Kerberos的实现基本原理。

接下来要介绍的是联合身份认证机制。基于令牌的身份认证方式允许将令牌的发布与其验证分开，从而促进身份管理的集中化。API的开发者只需要关心用户在调用API时的验证逻辑，不需要关心具体的身份认证逻辑，这部分是由集中式身份提供者完成的，API只需要在请求中带上token，然后由集中式身份提供者完成对token有效性的验证，如果生成的token有权限发起这次请求，则API将被允许调用。身份提供者能够对用户、应用及APP的身份进行识别和认证，是基于它们的身份信息和共享密码都存储在身份存储库中。但是，你的API不会始终暴露给身份提供者能识别的应用和用户，如果你希望将你的API暴露给外部用户控制的应用，外部用户可能来自于其他公司或者公司内部的其他业务部门，这时候该如何控制API的安全性呢?尤其是对于大公司而言，他们有很多的安全上下文，每个安全上下文都包含有独立的身份存储库和身份提供者，此时，联合身份机制应运而生，联合身份提供者能够对来自不同安全上下文的用户进行认证和授权。

联合身份认证机制的流程如下图所示，与普通的基于token的身份认证流程类似，但流程中增加了物流API和物流系统身份提供者两个角色，应用利用订单系统身份提供者返回的有效token申请访问物流API，物流API向物流系统身份提供者申请验证token有效性，但它并不知道此token是否有效，，必须向订单系统身份提供者申请验证此token，而不是在物流身份存储库中检索此token的信息，这里的订单系统身份提供者和物流系统身份提供者就是联合身份提供者。

身份认证完成之后，就需要根据用户的身份对其进行授权，其权限的大小由其身份决定。下面就介绍几种在API安全中使用的授权模式。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!