针对不同的应用场景选择错误的认证协议后果是非常严重的，因为错误的认证协议会破坏安全架构的基础和限制未来的扩展。那么，常见身份验证用例的推荐协议是什么？无论身份验证系统是安装在本地还是外部托管，都需要仔细选择适当的身份验证协议。适合您的用例的正确协议可以使整个系统安全高效地运行，并推动未来的扩展和与各种标准的兼容。此外，如果要让用户身份可以被外部服务识别，还需要考虑如何在保证流程安全的情况下方便这些服务摄取用户身份数据。身份验证是指以某种方式识别用户并授权访问资源。本文中讨论的身份验证协议包括SAML2.0、OpenIDConnect(OIDC)和OAuth2。请注意，OAuth2不是身份验证协议，但由于其广泛用于使用户能够通过Facebook和Amazon等社交服务提供商登录，因此将其包含在讨论中。身份、认证和授权协议。这三个协议通常在功能上重叠。身份协议提供有关用户的信息，例如永久标识符、电话或电子邮件地址，这些信息可用作该用户登录系统的长期标识符，从而验证该用户并授权访问资源。SAML和OIDE是最常见的示例。身份验证协议不一定需要个人标识符。例如，Kerberos系统基于透明和匿名的密钥交换，其中密钥本身不包含识别数据。OAuth2和UMA等身份验证协议提供了无需资源所有者共享凭据即可访问受保护资源的方法。此类协议的一个重要方面是交互式用户许可。OAuth2协议通常用于临时身份和身份验证，使用OAuth2过程中返回的用户数据（例如标识符）。由于其灵活性，身份协议越来越多地用于政府、企业和消费者领域，作为跨Web、移动和桌面应用程序进行身份验证的最佳实践方法。这些协议可能用于单点登录(SSO)应用程序，请注意OAuth2相关问题。去中心化身份说到身份验证，就不得不提到DID（或自主权身份）。该身份系统依赖于存储在移动设备上的用户身份属性，使用分布式账本技术来验证对这些属性的持有。目前，正在提出将这些系统与完善的标准身份协议集成的提案，现状是复杂的自定义协议，例如uPort。因此，目前不建议将DID用于通用身份或身份验证用例。然而，AvocoSecure和其他公司提供的编排API有望通过将其转化为标准协议来克服这一障碍。四种主要身份验证用例的协议建议1.IoT设备和相关应用程序在该用例中，应用程序使用数字身份来控制对应用程序和应用程序相关云资源的访问，例如AmazonAlexa等物联网设备。Alexa用于创建数据存储帐户，然后从中共享数据。协议选择：OIDC/OAuth2这是一个授权访问资源的简单用例，OAuth2很适合，尤其是考虑到智能设备的使用相对简单，比如没有键盘或屏幕的智能设备。2.消费者身份提供者(IdP)需要向依赖方(RP)提供身份数据的在线银行或政府服务属于此类用例。IdP持有敏感数据，用户属性通过所谓的了解你的客户(KYC)流程进行验证，提供标准级别的身份。只有获得许可的RP才能访问IdP。协议选择：SAML、OIDCSAML适用于对安全性要求高的场合。RP和IdP之间的交换可以由双方进行数字签名和验证。这确保了双方身份的真实性，并防止了一方被冒充。此外，来自IdP的断言也可以加密，因此仅依赖HTTPS可以防止攻击者接触用户数据。为了额外的安全性，您还可以定期轮换签名和加密密钥。为实现相同级别的安全性，OIDC需要额外的加密密钥，如开放银行扩展中所示，设置和维护起来相对麻烦。但是，由于使用了JSON，OIDC比SAML更易于用于移动应用程序。3.医疗数据共享门户在这个用例中，门户需要支持高度敏感的医疗数据的多种数据共享方式。协议选择：OIDC、UMA这里比较合适的选择是OIDC，因为可能会涉及到多种设备，其中有些不是基于浏览器的，SAML除外。与OIDC关联的内置权限强制执行数据共享的隐私。此外，签名和加密可用于增强安全性并满足处理此数据所需的合规性要求。4.在身份服务环境中支持多个服务提供者的系统保险服务协会是这个用例的一个很好的例子。系统需要为用户提供一种使用其现有身份帐户连接到这些服务的方法。用户可能需要根据需要添加其他数据。协议选择：OIDC、OAuth2、SAML用户应该可以选择IdP，这样已经有不同IdP账户的用户也可以轻松操作。例如，一些用户可能持有政府颁发的身份；其他人可能只有亚马逊账户或淘宝账户。为用户提供不同账户类型的选择，使用户无需先通过在线注册和验证过程即可轻松访问各种保险服务。但这需要每个RP支持多种协议，并处理一个提供者的身份可能不支持所有必需的声明或属性的可能性。解决方案是使用身份编排代理，或者可以翻译RP所需协议并收集所有所需属性的代理服务。【本文为专栏作家“李少鹏”原创文章，转载请通过安安牛（微信公众号id：gooann-sectv）获得授权】点此查看作者更多好文
