身份验证协议详解

1. 介绍

这几天学习DDoS攻击流程的时候经常碰到SAML、LDAP等身份验证协议，加上之前做开发的时候也经常碰到JWT、OAuth等身份认证协议，老是分不清。因此专门搜集了常见的身份认证协议，对比他们之间的异同。

用户登录（身份认证、权限管控）是应用系统的基本能力。应用服务要知道当前是谁在使用系统，现实世界中的人要向虚拟世界证明自己的身份。最简单手段就是双方约定一个独一无二的口令（龙门飞甲，便知真假），即用户名+密码。因为用户名密码只有用户自己和服务系统知道，通过判断这两个信息的有效性，服务器才能知道你就是你。口令不能够每次见面都讲一次，因为讲得越多，非常麻烦且泄露的风险就越高，于是便有了token（一段时间有效，可以代替口令）。同时了保证安全性，整个验证过程会加入很多加密手段（传输加密、存储加密、多次错误锁定、密码强度校验、双因素验证等）。同时还会加入图片验证码来防止暴力破解，验证码从最早的数字+干扰线模式开始一路发展出很多形态，如汉字识别、数学公式、图形判断、滑块等等。验证码技术的升级增加了服务的安全性，但也降低了用户体验，反面教材中以12306抢票系统为首。

随着时代的发展，人们越来越依赖手机，同时手机号也基本实现了实名制，基于手机的登录模式占比越来越高。最常见的就是手机号 + 短信验证码登录，该模式是目前应用最为广泛的登录方式之一。

还有由运营商提供的sim卡登录服务，该模式通过系统限制短信验证码的触发频率，可以淘汰图形验证码这一反人类元素（部分系统仍然保留了），用户仅需输入手机号码（甚至部分运营商已经开放给应用程序获取用户手机号码的协议，登录的时候连手机号码都不需要输入），登录体验极佳，大有一统天下的趋势。

再后来出现了一些生物识别技术，如指纹、面部识别等等。这些认证手段解决了最原始的身份认证问题，但随着时代的发展，信息系统越来越庞大，分布式高可用的微服务体系大行其道。各个系统之间紧密通讯，但又相互独立。跨系统、跨平台之间的身份认证变得非常必要，于是便有了SSO。

2. SSO

百科：单点登录（Single Sign On），简称为 SSO，是比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统

要实现SSO，需要构建以下两个主要内容：

1、所有应用系统共享一个身份认证系统

需要有一个集中的认证系统，这个认证系统要完成以下几个基本工作：

存储和维护所有的用户信息，用户信息的增删改查，密码修改重置，用户冻结解锁等
完成登录认证，下发token
验证token的有效性

为了保持大型系统的灵活性，用户信息必要时允许下发给子系统存储，但增删改操作只能在中心认证系统执行，执行完通过某种途径同步给子系统（一般是消息队列）。子系统本地存储的数据仅能做信息查询，并保持和中心服务器的通讯，以保证用户信息的时效性。

2、所有应用系统能够识别和提取当前登录用户的token信息

在SSO的场景下，当用户在身份认证系统完成登录操作后，后续所有的系统间交互都是基于认证系统下发的token来进行了。下游系统应该可以获取token，发送请求时携带token，并可向认证系统进行token有效性的校验。

优点：

用户一次登录，多端访问，提高了用户使用的效率
独立的认证系统，简化了应用程序开发，提高了开发人员效率
用户信息集中维护，简化了管理，提供了运营人员效率
便于构建大型分布式系统

缺点：

系统复杂度提升，开发和维护成本高，小型项目不适用
因可能牵扯太多下游系统，不利于重构，需尽可能保证兼容性升级
部分敏感系统可能被过度暴露（可通过敏感内容可做二次身份确认避免该问题）

3. JWT

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息，以便于从资源服务器获取资源，也可以增加一些额外的其它业务逻辑所必须的声明信息，该token也可直接被用于认证，也可被加密。

简单地说jwt是一种token的生成规则, 并不是一种身份认证协议。这个token包含了部分用户信息，同时带有自签名和过期时间。自签名可以防止信息篡改，过期时间可以控制token有效期。这和oauth完全是两个概念的东西，没有可比性。

一串完整的JWT由三段落组成，每个段落用英文句号连接（.）连接，他们分别是：头部（Header）、负载（Payload）、签名（Signature），所以JWT内容格式是这样的：AAA.BBB.CCC。其中Header和Payload是用base64UrlEncode编码的，一般如果未做额外加密，是可以直接通过base64解码后阅读内容的。Signature是以Header和Payload为基础，使用密钥（仅服务器知道，绝对不可泄漏）通过加密算法（具体哪种算法在header中会写明）计算得出。因此jwt token一旦颁发，Signature便是固定值。token内的任何信息被修改，都会导致Signature的不一致，确保了token无法被伪造和修改。

Signature = HmacSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)
以下是一段示例jwt，密钥是：admin123456

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJkYXRhIjpbeyJuYW1lIjoi5byg5LiJIn0seyJhZ2UiOiIxOCJ9XSwiaWF0IjoxNjY3OTk1MDQ1LCJleHAiOjE2Njc5MjMxOTksImF1ZCI6IiIsImlzcyI6IiIsInN1YiI6IiJ9.8AV7MJplq_jHt3juYE5v4yzAJJm6zJ7QB7qxgqo637E


Header：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
base64解码后：{"alg":"HS256","typ":"JWT"}

Payload：eyJkYXRhIjpbeyJuYW1lIjoi5byg5LiJIn0seyJhZ2UiOiIxOCJ9XSwiaWF0IjoxNjY3OTk1MDQ1LCJleHAiOjE2Njc5MjMxOTksImF1ZCI6IiIsImlzcyI6IiIsInN1YiI6IiJ9

base64解码后：
{"data":[{"name":"张三"},{"age":"18"}],"iat":1667995045,"exp":1667923199,"aud":"","iss":"","sub":""}

3. OAuth

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。

OAuth协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAuth是安全的。同时，任何第三方都可以使用OAuth认证服务，任何服务提供商都可以实现自身的OAuth认证服务，因而OAuth是开放的。

OAuth角色:

Consumer：消费方
Service Provider：服务提供者
User：用户

OAuth流程：

用户访问客户端的网站，想操作用户存放在服务提供方的资源。
客户端访问服务提供方的临时令牌页面申请一个临时令牌。
服务提供方验证客户端的身份后，授予一个临时令牌。
客户端获得临时令牌后，将用户引导至服务提供方的授权页面请求用户授权。在这个过程中将临时令牌和客户端的回调连接发送给服务提供方。
用户在服务提供方的网页上输入用户名和密码，然后授权该客户端访问所请求的资源。
授权成功后，服务提供方引导用户返回客户端的网页。
客户端根据临时令牌访问服务提供方的访问令牌页面 获取访问令牌。
服务提供方根据临时令牌和用户的授权情况授予客户端访问令牌。
客户端使用获取的访问令牌访问存放在服务提供方上的受保护的资源。

4. OAuth2

OAuth2.0是OAuth协议的延续版本，但不向前兼容OAuth 1.0(即完全废止了OAuth1.0)。 OAuth 2.0关注客户端开发者的简易性。要么通过组织在资源拥有者和HTTP服务商之间的被批准的交互动作代表用户，要么允许第三方应用代表用户获得访问的权限。同时为Web应用，桌面应用和手机，和起居室设备提供专门的认证流程。2012年10月，OAuth 2.0协议正式发布为RFC 6749 [1] 。

OAuth（开放授权）是一个开放标准，允许用户让第三方应用访问该用户在某一网站上存储的私密的资源（如照片，视频，联系人列表），而无需将用户名和密码提供给第三方应用。OAuth允许用户提供一个令牌，而不是用户名和密码来访问他们存放在特定服务提供者的数据。每一个令牌授权一个特定的网站（例如，视频编辑网站)在特定的时段（例如，接下来的2小时内）内访问特定的资源（例如仅仅是某一相册中的视频）。这样，OAuth允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要分享他们的访问许可或他们数据的所有内容。

OAuth2.0很可能是下一代的“用户验证和授权”标准。现在百度开放平台，腾讯开放平台等大部分的开放平台都是使用的OAuth 2.0协议作为支撑。

OAuth 2.0的新特性 - 6种全新流程:

User-Agent Flow – 客户端运行于用户代理内（典型如web浏览器）。
Web Server Flow – 客户端是web服务器程序的一部分，通过http request接入，这是OAuth 1.0提供的流程的简化版本。
Device Flow – 适用于客户端在受限设备上执行操作，但是终端用户单独接入另一台电脑或者设备的浏览器
Username and Password Flow – 这个流程的应用场景是，用户信任客户端处理身份凭据，但是仍然不希望客户端储存他们的用户名和密码，这个流程仅在用户高度信任客户端时才适用。
Client Credentials Flow – 客户端使用它的身份凭据去获取access token，这个流程支持2-legged OAuth的场景。
Assertion Flow – 客户端用assertion去换取access token，比如SAML assertion。

OAuth 2.0的新特性:

持信人token - OAuth 2.0 提供一种无需加密的认证方式，此方式是基于现存的cookie验证架构，token本身将自己作为secret，通过HTTPS发送，从而替换了通过 HMAC和token secret加密并发送的方式，这将允许使用cURL发起APIcall和其他简单的脚本工具而不需遵循原先的request方式并进行签名。
签名简化 - 对于签名的支持，签名机制大大简化，不需要特殊的解析处理，编码，和对参数进行排序。使用一个secret替代原先的两个secret。
短期token和长效的身份凭据 - 原先的OAuth，会发行一个有效期非常长的token(典型的是一年有效期或者无有效期限制)，在OAuth 2.0中，server将发行一个短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期。
角色分开 - OAuth 2.0将分为两个角色： Authorization server负责获取用户的授权并且发布token； Resource负责处理API calls。

	OAuth	OAuth2.0
token有效期	有效期非常长的token(典型的是一年有效期或者无有效期限制)	短有效期的access token和长生命期的refresh token。这将允许客户端无需用户再次操作而获取一个新的access token，并且也限制了access token的有效期
协议	http	https
过程	伴随复杂的签名算法等	轻量，提供多种方式

OAuth 2.0 规定了四种获得令牌的流程, 这四种模式实现过程和使用场景都不相同，但其实都是通过使用事先约定的信息，向主系统获取一次授权的令牌，后续所有的系统交互还是基于这个令牌来操作的。子系统获得令牌后，通过接口请求到需要的信息（用户信息），之后一般还会在子系统后台完成初始化用户、权限配置、登录等隐藏操作。

授权码（Authorization Code）

该模式是使用最广，安全级别最高的模式，适用于拥有前后端的应用授权。一般讲到oauth对接都指的是这种模式。大家日常使用最多的微信登录和支付宝登录都是基于这种模式实现的。在这个过程中，code是主系统通过redirect_uri + 参数传递给子系统的，token是子系统发起后端post请求得到的。

微信授权流程如下：

微信授权流程

第三方发起微信授权登录请求，微信用户允许授权第三方应用后，微信会拉起应用或重定向到第三方网站（redirect_uri），并且带上授权临时票据 code 参数；
通过 code 参数加上 AppID 和AppSecret等，通过 API 换取access_token；
通过access_token进行接口调用，获取用户基本数据资源或帮助用户实现基本操作。

支付宝授权流程如下：

支付宝授权流程

隐藏式（Implicit）

适用于只有前端，没有后端的应用。

1、三方系统向主系统发起授权请求： https://xxx.com/oauth/authorize?client_id=CLIENT_ID&redirect_uri=CALLBACK_URL

2、主系统收到请求后，校验收到的 CLIENT_ID 和 CALLBACK_URL 与系统内预留的信息是否一致

3、校验通过后主系统直接重定向到redirect_uri ，将令牌作为redirect_uri 参数，通发令牌给三方系统，隐藏了授权码这个步骤。

https://CALLBACK_URL#token=ACCESS_TOKEN

这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。
密码式（Resource Owner Password Credentials）

直接把用户名和密码告诉第三方系统，第三方系统拿着账号、密码、客户端 ID（client ID）来发起http请求，主系统直接返回包含令牌的JSON 数据。该模式会产生很多安全问题。用户账密多端存储，容易产生数据不一致问题，也增加了信息泄露的风险

对于受信任的系统之间，如果选用该方式对接，应尽可能走内网接口。如暴漏在公网，应做好数据传输的加解密工作。
客户端凭证（Client Credentials）

客户端凭据模式主要应用于后端系统之间的通信，没有用户参与的场景。比如某些开放平台，允许注册应用获取一些平台公共资源，比如平台的介绍信息，注册应用本身的信息，这些理论上是不需要用户进行授权的，而且也跟用户没有归属关系，这个时候就可以使用此模式。三方系统只需要携带客户端 ID（client ID）和客户端密钥（client secret）来发起http请求，主系统直接返回包含令牌的JSON 数据。

5. OpenID

OpenID 是一个以用户为中心的数字身份识别框架，它具有开放、分散性。OpenID 的创建基于这样一个概念：我们可以通过 URI （又叫 URL 或网站地址）来认证一个网站的唯一身份，同理，我们也可以通过这种方式来作为用户的身份认证。

OpenID是一个去中心化的网上身份认证系统。对于支持OpenID的网站，用户不需要记住像用户名和密码这样的传统验证标记。取而代之的是，他们只需要预先在一个作为OpenID身份提供者（identity provider, IdP）的网站上注册。OpenID是去中心化的，任何网站都可以使用OpenID来作为用户登录的一种方式，任何网站也都可以作为OpenID身份提供者。OpenID既解决了问题而又不需要依赖于中心性的网站来确认数字身份。

需要强调一点，OpenID只管身份认证，不做资源授权管理。OpenID2.0使用了XML和自定义消息签名，开发人员有时很难做到这一点。

OAuth和OpenID的区别：
OAuth关注的是authorization授权，即：“用户能做什么”；
而OpenID侧重的是authentication认证，即：“用户是谁”。

6. OIDC

OpenID Connect (OIDC) 是第三代OpenID技术，扩展了 OAuth 2.0 授权协议，在OAuth2.0上构建了身份层，使其可用作身份验证协议。 OIDC 通过一个称作“ID 令牌”的安全令牌在支持 OAuth 的应用程序之间启用单点登录 (SSO)。

OpenID（认证）+OAuth 2.0（授权）=OpenID Connect（认证+授权）。

使用标准的JWT令牌，REST/JSON消息流，允许开发人员跨网站和应用程序验证其用户，而无需拥有和管理密码。OpenID Connect的设计支持web程序、本地应用程序和移动应用程序。

完整的协议包含以下部分，其中Core是最小核心：

OpenID协议

OpenID Connect Core 1.0规范定义了核心OpenID Connect功能：基于OAuth 2.0构建的身份验证，以及使用声明来传递有关最终用户的信息。它还描述了使用OpenID Connect时的安全和隐私注意事项。

核心步骤：

OpenID核心步骤

1、RP（接入的客户端 Relying Party）向OP（认证服务提供端 OpenID Provider）发送请求。

2、OP验证用户并获得授权。

3、OP使用ID令牌和访问令牌进行响应。

4、RP可以向UserInfo端点发送带有访问令牌的请求。

5、UserInfo端点返回有关最终用户的声明。

OpenID Connect对OAuth 2.0进行的主要扩展是ID令牌数据结构（JWT）,以下为一个例子，iss、sub、and、exp、lat为必需：

 {
   "iss": "https://server.example.com",  //颁发者的URL,https
   "sub": "24400320",                    //唯一标识
   "aud": "s6BhdRkqt3",                  //OAuth 2.0 client_id
   "nonce": "n-0S6_WzA2Mj",
   "exp": 1311281970,                    //过期时间
   "iat": 1311280970,                    //JWT下发时间
   "auth_time": 1311280969,
   "acr": "urn:mace:incommon:iap:silver"
  }

阿里的OIDC：https://help.aliyun.com/document_detail/174228.html
微软的OIDC： https://learn.microsoft.com/zh-cn/azure/active-directory/develop/v2-protocols-oidc

7. CAS

CAS 是由耶鲁大学实验室 2002 年出的一个开源的统一认证服务中的标准协议，也是很多企业内部系统登录所使用的标准协议，如阿里巴巴等。作为 C 端登录协议如支付宝、淘宝等。详细协议标准可以参考 https://apereo.github.io/cas/6.4.x/protocol/CAS-Protocol-Specification.html 。其核心是服务端返回 ticket 作为认证条件，由客户端判断条件是否存在，存在则通过验证接口验证用户登录状态，同时返回用户信息，否则进行登录。同时客户端可以自定义登录流程，通过服务端提供的接口进行认证。

CAS服务器是基于Spring Framework构建的Java servlet，其主要职责是通过签发和验证票据来验证用户并授予对支持CAS的服务（CAS客户端程序）的访问权限。

CAS客户端是一个软件包，可以与各种软件平台和应用程序集成，以便通过某些身份验证协议（例如CAS、SAML、OAuth）与CAS服务器通信。

客户端通过几种受支持的协议中的任何一种与服务器通信。除了自己的CAS协议外，市面上主流的基本都支持，如SAML、OpenID Connect、OpenID、OAuth 2.0等。

协议过程如下：

CAS协议过程

7. SAML 2.0

安全断言标记语言（英语：Security Assertion Markup Language，简称SAML）是一个基于XML的开源标准数据格式，它在系统之间交换身份验证和授权数据，尤其是在身份提供者和服务提供者之间交换。SAML解决的最重要的需求是Web端应用的单点登录，目前能见到的基本都是最新版本 2.0 。

协议古老且内容庞大，特点是使用xml传输，SP（Service Provider）和IDP（Identity Provider）之间不直接通讯，而是通过用户的浏览器进行两次重定向完成认证跳转。

SAML流程

8. LDAP

轻型目录访问协议（英文：Lightweight Directory Access Protocol，缩写：LDAP）。是一个开放的，中立的，工业标准的应用协议，通过IP协议提供访问控制和维护分布式的目录信息。LDAP起源于上个世纪，延续至今在企业内部（OA、ERP）的地位依然牢不可破。一个常用用途是单点登录，用户可以在多个服务中使用同一个账密，常用于公司内部网站的登录认证。
简单地说：

1、DAP是一个协议（X.500），LDAP是他的一个轻量级变种协议

2、LDAP（轻型目录访问协议）是一种目录访问协议，而目录信息是存储在目录数据库内的。实现了LDAP协议的目录数据库有很多，其中最出名、影响最广的就是 Microsoft Active Directory。除此之外，还有Sun one Directory、IBM directory server。以及开源的openldap（OpenLDAP, Main Page）、Apache Directory LDAP（Welcome to Apache Directory — Apache Directory）

3、我们常说的LDAP服务器，是指部署了某一目录数据库（如微软的Active Directory）的应用服务器，该服务器对外提供LDAP服务。
4、目录数据以树形结构存储，不支持事务，读性能远大于写性能。
目录数据库由服务端和客户端组成，这一点和我们常用的关系型数据库（mysql）一样。但不同的是，LDAP数据库的客户端和服务端通讯是遵循标准的LDAP协议的，故对于同一个客户端程序，底层的服务端理论上是可以直接切换不同厂商的。

LDAP以树形结构存储数据，不支持事务，读性能远大于写性能。整棵树的任何一个分支都可以单独放在一个服务器中进行分布式管理，不仅有利于做服务器的负载均衡，还方便了跨地域的服务器部署。这个优势在查询负载大或企业在不同地域都设有分公司的时候体现尤为明显。

LDAP目录中存储了用户名和密码信息，使用LDAP登录的时候其实和普通的数据库登录没什么大的区别，客户端连接服务端后，搜索比对存储的用户名和密码信息。

springboot集成ldap：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-ldap</artifactId>
 </dependency>

9. SCIM

SCIM (System for Cross-domain Identity Management)跨域身份管理，主要用于多租户的云应用身份管理。

SCIM 是一种用户和组管理的新兴标准，通常用于替代传统 LDAP 协议。 SCIM 提供了 HTTP REST、跨企业和云应用程序部署所需的灵活性。由于许多云服务不会提供 LDAP 接口，因此您可以使用与底层协议不同的 SCIM。

SCIM (System for Cross-domain Identity Management)跨域身份管理，主要用于多租户的云应用身份管理。

SCIM组织架构

对资源的操作，SCIM提供了一套REST API，包含丰富但简单的操作集，支持从修改特定用户的特定属性到进行批量更新的所有内容。

Create: POST https://example.com/{v}/{resource}
Read: GET https://example.com/{v}/{resource}/{id}
Replace: PUT https://example.com/{v}/{resource}/{id}
Delete: DELETE https://example.com/{v}/{resource}/{id}
Update: PATCH https://example.com/{v}/{resource}/{id}
Search: GET https://example.com/{v}/{resource}?ﬁlter={attribute}{op}{value}&sortBy={attributeName}&sortOrder={ascending|descending}
Bulk: POST https://example.com/{v}/Bulk

10. IAM

IAM（Identity and Access Management 的缩写），身份识别与访问管理（又称4A）。具有单点登录、强大的认证管理、基于策略的集中式授权和审计、动态授权、企业可管理性等功能。

4A是指：认证Authentication、授权Authorization、账号Account、审计Audit，中文名称为统一安全管理平台解决方案。即将身份认证、授权、记账和审计定义为网络安全的四大组成部分，从而确立了身份认证在整个网络安全系统中的地位与作用。

11 Kerberos

Kerberos协议被广泛运用在大数据生态中，甚至可以说是大数据身份认证的事实标准。其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据(ticket-granting ticket)访问多个服务，即SSO。不同于其他网络服务，Kerberos协议中不是所有的客户端向想要访问的网络服务发起请求，他就能建立连接然后进行加密通信，而是在发起服务请求后必须先进行一系列的身份认证，包括客户端和服务端两方的双向认证，只有当通信双方都认证通过对方身份之后，才可以互相建立起连接，进行网络通信。即Kerberos协议的侧重在于认证通信双方的身份，客户端需要确认即将访问的网络服务就是自己所想要访问的服务而不是一个伪造的服务器，而服务端需要确认这个客户端是一个身份真实，安全可靠的客户端，而不是一个想要进行恶意网络攻击的用户。

Kerberos协议中存在三个角色，分别是：

客户端(Client)：发送请求的一方
服务端(Server)：接收请求的一方
密钥分发中心(Key distribution KDC)

密钥分发中心又分为两个部分，分别是：
- AS(Authentication Server)：认证服务器，专门用来认证客户端的身份并发放客户用于访问TGS的TGT(票据授予票据)
- TGS(Ticket Granting ticket)：票据授予服务器，用来发放整个认证过程以及客户端访问服务端时所需的服务授予票据(ticket)

Kerberos 的特点：

Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密Ticket，认证将无法通过。
客户端将依次与 Authentication Service, Ticket Granting Service 以及目标Service进行交互，共三次交互。
客户端与其他组件交互是，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。
客户端想要访问的目标服务，将不会直*与KDC交互，而是通过能否正确解密出客户端的请求来进行认证。
KDC Database 包含有所有 principal 对应的密码。
Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。

12. IDaaS

IDaaS的全称是Identify as a Service，身份即服务，是一种构架在云上的身份服务。IDaaS是云化的身份和访问管理（IAM)，IDaaS=SaaS+IAM。

阿里的：https://help.aliyun.com/document_detail/112323.html
腾讯的：https://cloud.tencent.com/product/tcid

13. 分析

上述协议实在太多，如何进行区分呢？

我们可以将其分为：身份、身份验证和授权协议。

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

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

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

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

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

协议选择：OIDC/OAuth2。这是个授权访问资源的简单用例，OAuth2 就很合适，尤其是考虑到智能设备使用相对简单的情况，比如无键盘或屏幕的智能设备。
消费者身份提供商 (IdP)。需向依赖方 (RP) 提供身份数据的在线银行或政府服务归属该类用例。IdP 持有敏感数据，用户属性通过所谓了解客户 (KYC) 过程验证，提供达到标准水平的身份。仅受许可的 RP 能够访问 IdP。

协议选择：SAML、OIDC。SAML 适用于安全要求高的场合。RP 和 IdP 之间的交换都能被双方数字签署和验证。这就保障了双方身份的真实性，防止出现某一方被假冒的情况。此外，还可以加密来自 IdP 的断言，以便不仅仅依赖 HTTPS 防止攻击者触及用户的数据。若想进一步夯实安全性，还可以定期轮转签名和加密密钥。OIDC 若要达到相同的安全水平，需要额外的加密密钥，如开放银行 (Open Banking)扩展中呈现的那样，其设置和维护可能相对较繁琐。但是，OIDC 得益于 JSON 的使用，相对 SAML 更容易为移动应用所用。
医疗数据共享门户。该用例中，此门户需支持高敏感医疗数据的多种数据共享方式。

协议选择：OIDC、UMA。此处相对合适的选项是 OIDC，因为可能涉及多种设备，其中有些不是基于浏览器的，也就排除掉了 SAML。与 OIDC 关联的内置许可强化了数据共享的隐私性。此外，还可运用签名和加密增强安全性，达到处理此类数据所需的合规要求。
支持身份服务大环境中多服务提供商的系统。保险服务协会就是该用例的一大样本。系统需向用户提供使用现有身份账户连接这些服务的方式。用户可能需要添加所需附加数据。

协议选择：OIDC、OAuth2 和 SAML。用户应能选择一家 IdP，以便已经在不同 IdP 处拥有账户的用户可以方便操作。举个例子，有些用户可能持有政府颁发的身份；其他用户可能仅拥有亚马逊账户或淘宝账户。赋予用户不同账户类型的选择，可以使用户无需先经历在线注册和验证过程，就能很方便地访问各保险服务。但这就要求每个 RP 支持多个协议，并需处理一家提供商的身份可能不支持全部所需主张或属性的问题。而解决方案就是使用身份编排代理，或采用能够翻译 RP 所需协议和收集全部所需属性的代理服务。

目录CONTENT

网络中身份验证协议详解