别吃错药:四大身份验证场景的协议选择

安全 应用安全 数据安全
不同应用场景选错身份验证协议的后果很严重,因为错误的身份验证协议会破坏安全架构基础,并限制未来扩展。那么,常见的身份验证用例都有哪些推荐协议呢?

不同应用场景选错身份验证协议的后果很严重,因为错误的身份验证协议会破坏安全架构基础,并限制未来扩展。那么,常见的身份验证用例都有哪些推荐协议呢?

[[311793]]

身份验证系统无论安装在内部,还是托管在外部,都需要谨慎选择合适的身份验证协议。符合您用例的正确协议,可以使整个系统安全高效运行,并且驱动未来扩展和兼容各种标准。此外,若想使用户身份可被外部服务识别,还需考虑如何在保证过程安全的情况下,便于这些服务摄入用户身份数据。

身份验证指的是通过某种方式识别用户身份,授权资源访问。本文所讨论的身份验证协议包括 SAML 2.0、OpenID Connect (OIDC) 和 OAuth2。注意,OAuth2 并非身份验证协议,但因其使用广泛,可使用户通过 Facebook、亚马逊等社交服务提供商登录,而纳入讨论。

身份、身份验证和授权协议。

这三个协议在功能上常有重叠。

  • 身份协议提供关于用户的信息,比如永久标识符、电话或电子邮件地址,可用作该用户登录您系统的长期标识,从而验证该用户并授权资源访问。SAML 和 OIDE 是最常见的例子。
  • 身份验证协议未必需要个人标识符。比如说,Kerberos 系统就基于透明匿名密钥交换,密钥本身不包含标识数据。
  • OAuth2 和 UMA 等身份验证协议提供的方法,无需资源拥有者共享凭证,即可获得受保护资源的访问权限。此类协议的一个重要方面是交互式用户许可。OAuth2 协议常用于临时身份和身份验证,使用标识符等 OAuth2 过程中返回的用户数据。

由于其灵活性,身份协议在政府、企业和消费领域越来越常用,作为身份验证的最佳实践方法,广泛应用于 Web、移动应用和桌面应用程序。这些协议可能被用于单点登录 (SSO) 应用,需注意 OAuth2 相关问题。

去中心化身份

说到身份验证,不得不提 DID(或称自主身份)。这种身份系统依赖用户存储在移动设备上的身份属性,使用分布式账本技术验证这些属性的持有情况。当前,将这些系统与成熟标准身份协议集成的建议不断提出,现状就是复杂自定义协议,比如 uPort。因此,目前不推荐在通用身份或身份验证用例中使用 DID。不过,Avoco Secure 等提供的编排 API,倒是有望通过转译为标准协议而跨越这个障碍。

四大身份验证用例协议推荐

1. 物联网设备及相关应用

此用例中,应用采用数字身份控制对应用及应用相关云资源的访问,比如说,亚马逊 Alexa 等物联网设备。Alexa 用于创建数据存储账户,然后从中共享数据。

协议选择:OIDC/OAuth2

这是个授权访问资源的简单用例,OAuth2 就很合适,尤其是考虑到智能设备使用相对简单的情况,比如无键盘或屏幕的智能设备。

2. 消费者身份提供商 (IdP)

需向依赖方 (RP) 提供身份数据的在线银行或政府服务归属该类用例。IdP 持有敏感数据,用户属性通过所谓了解客户 (KYC) 过程验证,提供达到标准水平的身份。仅受许可的 RP 能够访问 IdP。

协议选择:SAML、OIDC

SAML 适用于安全要求高的场合。RP 和 IdP 之间的交换都能被双方数字签署和验证。这就保障了双方身份的真实性,防止出现某一方被假冒的情况。此外,还可以加密来自 IdP 的断言,以便不仅仅依赖 HTTPS 防止攻击者触及用户的数据。若想进一步夯实安全性,还可以定期轮转签名和加密密钥。

OIDC 若要达到相同的安全水平,需要额外的加密密钥,如开放银行 (Open Banking)扩展中呈现的那样,其设置和维护可能相对较繁琐。但是,OIDC 得益于 JSON 的使用,相对 SAML 更容易为移动应用所用。

3. 医疗数据共享门户

该用例中,此门户需支持高敏感医疗数据的多种数据共享方式。

协议选择:OIDC、UMA

此处相对合适的选项是 OIDC,因为可能涉及多种设备,其中有些不是基于浏览器的,也就排除掉了 SAML。与 OIDC 关联的内置许可强化了数据共享的隐私性。此外,还可运用签名和加密增强安全性,达到处理此类数据所需的合规要求。

4. 支持身份服务大环境中多服务提供商的系统

保险服务协会就是该用例的一大样本。系统需向用户提供使用现有身份账户连接这些服务的方式。用户可能需要添加所需附加数据。

协议选择:OIDC、OAuth2 和 SAML

用户应能选择一家 IdP,以便已经在不同 IdP 处拥有账户的用户可以方便操作。举个例子,有些用户可能持有政府颁发的身份;其他用户可能仅拥有亚马逊账户或淘宝账户。

赋予用户不同账户类型的选择,可以使用户无需先经历在线注册和验证过程,就能很方便地访问各保险服务。但这就要求每个 RP 支持多个协议,并需处理一家提供商的身份可能不支持全部所需主张或属性的问题。而解决方案就是使用身份编排代理,或采用能够翻译 RP 所需协议和收集全部所需属性的代理服务。

【本文是51CTO专栏作者“李少鹏”的原创文章,转载请通过安全牛(微信公众号id:gooann-sectv)获取授权】

戳这里,看该作者更多好文   

 

责任编辑:赵宁宁 来源: 51CTO专栏
相关推荐

2021-08-31 11:59:41

API安全事件身份验证

2014-12-11 10:05:13

ASP.NET

2024-05-11 08:14:53

2010-09-06 11:24:47

CHAP验证PPP身份验证

2010-07-17 00:57:52

Telnet身份验证

2019-10-29 14:11:55

安全多因素身份验证智能

2023-02-02 09:37:59

消息队列MQ

2012-04-10 09:36:58

2020-05-26 14:18:41

RPC协议NTLM

2019-11-21 14:53:10

多因子身份验证MFA密码

2013-07-21 18:32:13

iOS开发ASIHTTPRequ

2011-02-21 10:54:45

2012-10-23 16:12:35

2022-10-31 10:00:00

2010-07-19 17:30:47

2009-04-09 23:44:08

软件身份验证用户

2023-10-12 08:32:39

Windows微软

2010-11-30 15:31:38

SharePoint Kerberos

2021-07-05 09:18:08

UPS电源

2021-07-19 10:10:15

身份验证漏洞Windows Hel
点赞
收藏

51CTO技术栈公众号