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

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

编程入门访客2021-10-11 13:38:009025A+A-

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

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

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

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

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

1. 身份协议提供关于用户的信息,比如永久标识符、电话或电子邮件地址,可用作该用户登录您系统的长期标识,从而验证该用户并授权资源访问。SAML 和 OIDE 是最常见的例子。

2. 身份验证协议未必需要个人标识符。比如说,Kerberos 系统就基于透明匿名密钥交换,密钥本身不包含标识数据。

3. OAuth2 和 UMA 等身份验证协议提供的方法,无需资源拥有者共享凭证,即可获得受保护资源的访问权限。此类协议的一个重要方面是交互式用户许可。OAuth2 协议常用于临时身份和身份验证,使用标识符等 OAuth2 过程中返回的用户数据。

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

去中心化身份

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

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

01、物联网设备及相关应用

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

协议选择:OIDC/OAuth2

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

02、消费者身份提供商 (IdP)

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

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

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

03、医疗数据共享门户

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

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

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

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

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

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

点击这里复制本文地址 以上内容由黑资讯整理呈现,请务必在转载分享时注明本文地址!如对内容有疑问,请联系我们,谢谢!
  • 5条评论
  • 寻妄岁吢2022-06-02 08:31:43
  • h2 和 UMA 等身份验证协议提供的方法,无需资源拥有者共享凭证,即可获得受保护资源的访问权限。此类协议的一个重要方面是交互式用户许可。OAuth2 协议常用于临时身份和身份验证,使用标识符等 OAuth2 过程中返回的用户数据。由于其灵活性,身份协议在政府、企
  • 弦久等灯2022-06-02 13:07:42
  • 况。当前,将这些系统与成熟标准身份协议集成的建议不断提出,现状就是复杂自定义协议,比如 uPort。因此,目前不推荐在通用身份或身份验证用例中使用 DID。不过,A
  • 性许痴妓2022-06-02 17:06:49
  • 防止攻击者触及用户的数据。若想进一步夯实安全性,还可以定期轮转签名和加密密钥。OIDC 若要达到相同的安全水平,需要额外的加密密钥,如开放银行 (Open Banking)扩展中呈现的那样,其设置和维护可能相对较繁琐。但是,OIDC 得益于 JSON 的使用,相对 SAM
  • 颜于酒岁2022-06-02 09:24:10
  • (KYC) 过程验证,提供达到标准水平的身份。仅受许可的 RP 能够访问 IdP。协议选择:SAML、OIDCSAML 适用于安全要求高的场合。RP 和 IdP 之间的交换都能被双方数字签署和验证。这就保障了双方身份的真实性,防止出现某一方被假冒的情况。此外,还可以加密来自 IdP 的断言,以便不仅
  • 痴妓听弧2022-06-02 12:07:29
  • 的真实性,防止出现某一方被假冒的情况。此外,还可以加密来自 IdP 的断言,以便不仅仅依赖 HTTPS 防止攻击者触及用户的数据。若想进一步夯实安全性,还可以定期轮转签名和加密密钥。OIDC 若要达到相同的安全水平,需

支持Ctrl+Enter提交

黑资讯 © All Rights Reserved.  
Copyright Copyright 2015-2020 黑资讯
滇ICP备19002590号-1
Powered by 黑客资讯 Themes by 如有不合适之处联系我们
网站地图| 发展历程| 留言建议| 网站管理