引入CIBA实现安全交易验证
数字应用程序不断处理身份信息。在应用程序"前门"通过认证验证身份至关重要。用户认证方面存在多种成熟复杂的技术和标准,如OpenID Connect(OIDC)和安全断言标记语言(SAML),允许受信任的身份提供商(IDP)在允许访问应用程序之前安全地认证用户。
然而,前门认证并非唯一需要验证身份的场景。
考虑以下场景:
- 通过银行客服更新电子邮件地址
- 通过HelpDesk恢复用户ID/密码
- 在零售POS系统安全执行交易
- 使用浏览器受限设备(如智能音箱)进行认证
- 从共享终端进行认证
在上述每种情况下,虽然需要验证身份,但可能无法或不适合让用户通过交互式登录界面(如网页浏览器)执行认证。
目录
- 应用程序当前如何处理身份验证
- 逐步了解身份验证场景
- 更新银行账户电子邮件地址
- 销售点(POS)支付
- 使用CIBA安全一致地验证身份交易
- CIBA实现流畅的认证体验
- CIBA基于OAuth 2.0和OIDC构建
- 使用CIBA时的安全考虑
- Okta中的CIBA支持
- 在应用程序中使用CIBA进行安全身份验证
- 了解更多关于CIBA、Okta和身份验证的信息
应用程序当前如何处理身份验证
虽然利用安全IDP和标准通过登录界面提供初始认证很流行,但上述场景中的身份验证是以临时方式构建的。根据设计,某些应用程序以糟糕的客户体验低效地执行此操作,而其他应用程序则安全性较低且易受攻击。
逐步了解身份验证场景
考虑在无法依赖传统用户认证流程时的身份验证需求,例如涉及多方或浏览器受限系统的情况。让我们检查这些案例并识别身份安全陷阱。
更新银行账户电子邮件地址
考虑用户致电客户服务以更新与其银行账户关联的电子邮件地址。通常,热线人员会询问用户某些个人身份信息(PII)答案,如姓氏、出生日期和社会安全号码最后四位数字。验证后,热线人员通过客户关怀应用程序更新电子邮件地址,该应用程序在银行身份数据库上执行特权操作以更改用户记录。
这种方法存在问题。
首先,客户体验不佳。客户还需要提供PII信息进行验证,攻击者可以通过猜测或社会工程获得这些信息。这很容易导致账户接管,欺诈行为者可以成功通过验证并使用新电子邮件ID渗透账户。
第二个问题是客户关怀应用程序需要在没有认证的情况下从后端更改用户配置文件。应用程序通常会使用强大的凭据来执行此类特权操作。例如,应用程序可以获取并使用具有用户管理权限的令牌来调用用户更新API。这样的令牌允许更新银行系统目录中的用户账户,但如果令牌泄露,可能会被滥用。
如果能够获得某种形式的令牌,为应用程序提供仅够更新调用用户配置文件的权限,那不是很好吗?这样,它就可以遵循安全的最小权限原则。
销售点(POS)支付
这是另一个有趣的场景。当用户尝试在零售销售点(POS)系统中使用银行账户付款时,他们不会愿意在共享设备上登录其银行账户并提供凭据。
相反,如果POS系统允许使用替代验证形式进行安全支付,而用户无需在公共系统中提供凭据,那将是理想的!
我们能否采取措施将用户认证与应用程序分离?
使用CIBA安全一致地验证身份交易
其思想是将认证与应用程序分离,以便可以在一个设备上启动并在另一个设备上验证。客户端启动的后端认证(CIBA)正好允许这种分离。
CIBA是一种基于OAuth 2.0的相对较新的认证流程,客户端可以启动交互流程以认证用户,而无需来自消费设备的最终用户交互。该流程涉及从客户端到OAuth 2.0授权提供商的后端通信,而无需通过用户的浏览器(消费设备)重定向。认证将从用户拥有并安全注册到提供商的单独认证设备(如手机或智能手表)独立验证。
CIBA实现流畅的认证体验
考虑以下针对我们银行电子邮件地址用例的流程。
- 客户关怀应用程序为用户启动认证事件。它向授权服务器发送直接的CIBA请求。
- 与常规登录页面不同,授权服务器向用户的手机发送推送通知。
- 当用户在其手机/智能手表上接受通知时,授权服务器会收到通知。
- 然后授权服务器向应用程序发出用户令牌。应用程序使用用户范围的令牌完成目标操作,即更新电子邮件地址。
这种方法的一些好处是:
- 验证期间用户体验更加流畅。它还可以让用户确信系统安全运行。
- 推送通知比其他带外用户认证方法(如短信一次性代码OTP)提供更高的安全性。
- 应用程序令牌可以严格限定于用户,提供最小特权访问。
以下是使用CIBA进行交易的简化流程。
CIBA基于OAuth 2.0和OIDC构建
CIBA是OIDC之上的扩展,而OIDC本身基于OAuth 2.0框架。它在系列中引入了一种新的OAuth 2.0授权类型:urn:openid:params:grant-type:ciba
。按照OIDC发现端点的惯例,CIBA引入了额外的元数据参数,如backchannel_token_delivery_modes_supported
和backchannel_authentication_endpoint
。发现文档负载如下所示:
|
|
backchannel_token_delivery_modes_supported
参数需要一些额外说明。规范定义了三种不同的通知客户端认证完成的方式。
- 轮询(Poll):在此模式下,客户端持续轮询授权服务器,直到认证完成或事件超时。如果认证成功,最终轮询将令牌返回给应用程序。此模式是最简单且最容易实现的。
- 推送(Ping):当认证完成时,它将回调到客户端的注册URL,通知状态。客户端向授权服务器发出令牌请求。
- 推送(Push):当认证完成时,它将使用令牌回调到客户端的注册URL。
Ping和Push模式实现起来更复杂,需要在客户端进行额外的元数据和实现步骤。但是,它节省了轮询周期引起的网络往返。
由于CIBA请求使用后端通道,它必须包含授权服务器可用于识别用户的参数。通常,使用请求的login_hint
或id_token_hint
参数提供该参数。
认证设备执行带外认证,而不是传统的认证流程,其中客户端与授权服务器顺序交互。在实际实现中,它将是向手机或智能手表等设备发送的推送通知。该设备需要安全地注册到授权服务器以供用户使用,以便它知道将授权请求发送到哪里。推送通知可以通过将机制嵌入应用程序的移动应用程序或使用配套认证器应用程序来传递。
使用CIBA时的安全考虑
CIBA容易受到类似于MFA疲劳攻击的攻击。考虑攻击者猜测用户ID或渗透用户账户并重复尝试执行使用CIBA授权实现的敏感交易的情况。真实用户可能会被重复的推送通知淹没并接受一个。
相关场景是当攻击者拥有用户ID列表并为每个用户启动交易。虽然大多数用户会忽略推送提示,但一小部分用户可能会批准请求。
总之,CIBA存在一个弱点,即攻击者可以强制启动授权事件。在某些场景中,更安全的替代方案是设备代码流,用户可以使用二维码或一次性代码在其设备上主动启动授权。
此外,CIBA不应在消费设备和认证设备相同的同设备场景中使用。
Okta中的CIBA支持
CIBA尚未广泛实施。Okta一直是CIBA标准的早期采用者。
CIBA在银行业迅速获得关注。基于OAuth 2.0令牌模型开发的FAPI规范包括CIBA配置文件。CIBA与补充产品产品(如演示持有证明(DPoP))一起构成了高度监管身份所需的关键组件。
在欧洲,CIBA可以帮助实现PSD2和英国开放银行概述的解耦认证流程。澳大利亚的消费者数据权(CDR)预计很快将包括该规范。
除了银行业,CIBA有望为Helpdesk、客户服务、零售销售点(POS)、交互式语音应答(IVR)和基于共享终端的应用程序提供增强的安全性和用户体验。
Okta在轮询模式下支持CIBA,此功能称为交易验证。Okta授权服务器包括CIBA授权作为支持的一部分。
通过允许使用Okta设备SDK创建移动推送认证器来支持认证过程。此SDK可以轻松嵌入组织的移动应用程序或作为单独的配套应用程序。查看iOS和Android指南,了解如何使用SDK实现品牌推送认证器。这些指南包括示例应用程序,帮助您快速开始构建体验。
在应用程序中使用CIBA进行安全身份验证
数字应用程序对每个业务都至关重要,保护它们至关重要。仅通过认证保护前门是不够的。应用程序必须在操作期间始终保持警惕,并在零信任模型上运行。CIBA是一个重要工具,可确保应用程序在适当上下文中强制执行持续安全的授权,而不会影响用户体验。
了解更多关于CIBA、Okta和身份验证的信息
如果您想了解更多关于CIBA、Okta和身份验证的信息,请查看以下资源:
- CIBA规范
- 使用Okta配置CIBA
在Twitter上关注我们并订阅我们的YouTube频道以获取更多身份内容。请随时在下面留下评论,告诉我们您想了解的身份主题。