如何构建和设计以确保 API 的安全性
|
可见，对于那些拥有管理员、项目所有者、服务客户经理等多种角色的企业应用来说，切换用户的不同角色并不会对JWT立即生效。例如：管理员修改了某个授权用户的角色，那么只要他不去刷新JWT，也就无法获悉该变更。 下面是OpenID Connect的三种实现用例： · 出栈方向的Web单一登录(SSO)：向企业用户提供对于SaaS应用、以及合作伙伴应用的访问管控，但并不公开本企业的用户名与密码。 · 入栈方向的Web单一登录：允许社交账号/第三方登录，但无需存储外部用户与密码。 · 实现各种本地应用的原生单一登录。 OAuth和OpenID Connect都支持OAuth2规范所指定的四种授权类型，下图描述了其中一种授权流程图。API开发人员可以根据手头项目所需的约束与实现方案，来选用不同的授权类型。 4. 数据保密与屏蔽个人身份信息 众所周知，由于密码、安全令牌和API密钥包含了不同程度的内部信息，它们不应该出现在URL中，或者被Web服务器的日志所捕获。此外，诸如UserID、密码、帐号、信用卡号码等个人身份信息，也应该处于“被打码”的状态，哪怕是在交易和审计日志中。 公共API的安全实践 由于独立于任何用户，因此公共API的设计初衷就是为了公开各种非敏感、以及只读的数据(例如天气类API)，当然也就不必添加任何身份验证与授权环节。不过，我建议您通过如下的方面，来打造能够应对各种威胁与滥用的API： · 在IP地址级别上应用速率限制的相关策略。 · 使用API密钥验证的方式。通过存储在网关上的方式，保证API的密钥不会被公布给任何客户端。因此，当拒绝服务攻击使用无效密钥访问API、或是在其他策略已无法阻断黑客攻击时，API密钥验证方式能够有效地发挥作用。 · 采用配额策略(单个或多种配额机制)，来实现API的使用限制。 · 如果API被用于特定地理区域的服务器进行通信，那么就应当在地理级别上(县/区等)采取IP地址的筛选。 · 开发人员应尽量采用一次性注册的方式，并使用自己的API密钥去调用API。 结论 在企业内部、以及企业之间需要集成不同的应用时，开发人员能够通过API来快速且方便地予以实现。不过，如果没有恰当地保护好API，那么就会让整个企业面临各种风险与威胁。因此，我们需要在开发和实施之前，就对API的安全性进行良好的构建和设计，从而提高企业的整体安全态势。 【凡本网注明来源非中国IDC圈的作品，均转载自其它媒体，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。】 延伸阅读：
（编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
