《白帽子讲 Web 安全》之身份认证

引言

一、概述

二、密码安全性

三、认证方式

（一）HTTP 认证

（二）表单登录

（三）客户端证书

（四）一次性密码（OTP）

（五）多因素认证

（六）FIDO

四、攻击方式与单点登录

（一）暴力破解和撞库

（二）单点登录

（三）Aereo CAS 安全注意事项

五、认证相关安全概述

六、OAuth 相关

刷新令牌机制

七、OIDC 相关

八、SAML 相关

九、CAS 相关

总结

引言

在 Web 应用的安全领域中，身份认证是至关重要的一环。吴翰清和叶敏所著的《白帽子讲 Web 安全》一书中的身份认证章节，为我们深入剖析了这一关键领域。接下来，让我们一同对这一章节的内容进行全面总结与知识分享。

一、概述

在 Web 应用的安全体系里，“认证” 和 “授权” 是两个截然不同却又紧密关联的概念。

认证，其核心作用在于识别用户究竟是谁，就好比在一个大型派对门口，保安通过查看邀请函或者证件来确认每一位来宾的身份。

而授权，则是决定用户能做什么，比如在派对中，有些区域只有 VIP 嘉宾才能进入，这就是授权在发挥作用。身份认证作为 Web 应用的基本安全功能，是保障用户数据和应用功能安全的第一道防线。

常见的认证方式中，用户名与密码的组合是最为大众所熟知的，无论是我们日常使用的社交账号、电子邮箱，还是各种在线服务平台，用户名和密码的输入框总是如影随形。

二、密码安全性

密码，作为最为常见的认证手段，拥有使用成本低的显著优势。几乎所有互联网用户都能轻松理解并运用密码来保护自己的账户。然而，它也存在一个致命的弱点，那就是极易被破解。在现实生活中，我们常常能听到一些用户因为设置了过于简单的密码，导致账户被盗用的新闻。为了提升密码的安全性，在设计密码策略时，诸多因素需要纳入考量。

密码长度是一个重要因素，一般来说，长度越长的密码，其被破解的难度就越大。例如，一个 8 位纯数字密码，通过计算机暴力破解可能只需要几分钟甚至更短时间，而一个 16 位包含数字、字母、特殊字符的密码，破解时间则可能会延长到数年甚至更久。

密码复杂度同样不容忽视。复杂的密码应包含大小写字母、数字以及特殊字符的组合。

以 “Abc@123456” 这样的密码为例，它既有大写字母 “A”，小写字母 “bc”，数字 “123456”，还有特殊字符 “@”，相较于单纯的数字或字母密码，安全性大大提高。同时，用户应避免使用弱密码，像 “123456”、“password”、“admin” 这类过于简单且常见的密码，几乎是黑客破解账户的首选目标。

对于网站和应用开发者而言，存储密码时进行哈希处理并 “加盐” 是至关重要的操作。

哈希处理是将密码通过特定的哈希函数转换为一串固定长度的哈希值进行存储，这样即使数据库被泄露，黑客获取到的也只是哈希值而非明文密码。而 “加盐” 则是在哈希处理前，向密码中添加一段随机字符串，增加密码的复杂度。比如，用户密码为 “mypassword”，盐值为 “randomsalt”，那么实际进行哈希处理的是 “mypasswordrandomsalt”，这使得黑客通过彩虹表等方式破解密码的难度大幅增加。

import hashlib
import os

password = "mypassword"
salt = os.urandom(16)   # 生成随机盐值
hashed_password = hashlib.pbkdf2_hmac('sha256',  password.encode('utf-8'),  salt, 100000)

print(f"盐值: {salt}")
print(f"哈希后的密码: {hashed_password}")

三、认证方式

（一）HTTP 认证

基本认证：基本认证是 HTTP 协议中较为简单的一种认证方式。当用户访问需要认证的资源时，服务器会返回一个 401 Unauthorized 响应，提示用户输入用户名和密码。用户输入的用户名和密码会以明文的形式，经过 Base64 编码后在 HTTP 请求头中发送给服务器。例如，用户名 “user” 和密码 “password” 经过 Base64 编码后变为 “dXNlcjpwYXNzd29yZA==”，并在请求头中以 “Authorization: Basic dXNlcjpwYXNzd29yZA==” 的形式发送。这种方式存在明显的密码泄露风险，因为 Base64 编码很容易被解码，一旦网络被监听，用户名和密码就会暴露无遗。
摘要认证：摘要认证在一定程度上弥补了基本认证的安全缺陷。它不再以明文形式传输密码，而是通过计算密码的哈希值来进行认证。在摘要认证过程中，服务器会发送一个包含随机数（nonce）的挑战信息给客户端，客户端使用用户名、密码、随机数以及其他相关信息计算出一个摘要值，再将这个摘要值发送给服务器。服务器收到摘要值后，使用相同的算法和信息计算出一个预期的摘要值，若两者一致，则认证成功。这种方式相较于基本认证，安全性更高，因为即使黑客截获了网络数据包，也无法轻易获取用户的密码。

（二）表单登录

表单登录是我们在日常上网过程中最为常见的登录方式。无论是购物网站、社交媒体平台还是在线办公系统，几乎都采用表单登录的形式。用户在登录页面输入用户名和密码，点击登录按钮后，表单数据会被提交到服务器进行验证。

然而，这种登录方式面临着钓鱼攻击的严峻威胁。钓鱼攻击通常通过仿冒正规网站的登录页面，诱使用户输入用户名和密码。

例如，黑客可能会创建一个与知名银行网站极为相似的假网站，当用户误以为是真实银行网站而输入账号密码时，这些信息就会被黑客获取。

在表单登录过程中，前端加密密码的实际意义并不大。因为前端代码是运行在用户浏览器中的，黑客可以通过各种手段，如查看网页源代码、使用浏览器插件等，轻松获取前端加密的方式和密钥，从而破解加密后的密码。此外，应用在处理用户登录错误时，应模糊给出错误信息。

比如，当用户输入错误的用户名或密码时，统一提示 “用户名或密码错误”，而不是明确指出是用户名错误还是密码错误。这是因为如果明确指出错误类型，黑客可以通过不断尝试用户名，根据错误提示来确定有效的用户名，进而进行针对性的密码破解攻击。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>表单登录示例</title>
</head>
<body>
    <form action="login.php"  method="post">
        <label for="username">用户名:</label>
        <input type="text" id="username" name="username"><br>
        <label for="password">密码:</label>
        <input type="password" id="password" name="password"><br>
        <input type="submit" value="登录">
    </form>
</body>
</html>

（三）客户端证书

客户端证书主要用于验证服务器的可信性，在企业内部网络环境中应用较为广泛。

其工作原理是客户端和服务器之间通过交换数字证书来验证彼此的身份。数字证书由权威的证书颁发机构（CA）颁发，包含了证书持有者的公钥、身份信息以及 CA 的数字签名等内容。

例如，企业内部的员工在访问公司的内部办公系统时，员工的电脑上安装有公司颁发的客户端证书，当员工尝试访问系统时，服务器会要求客户端提供证书进行验证。只有当服务器验证客户端证书合法且与员工身份匹配时，才允许员工访问系统。

客户端证书的安全性极高，因为证书的私钥存储在客户端设备中，只有拥有该设备的用户才能使用证书进行认证。而且，证书的颁发和管理由企业或权威机构严格把控，大大降低了被伪造的风险。然而，实施客户端证书认证也存在一定的成本。企业需要投入资金建立证书颁发机构，为员工发放和管理证书，同时员工也需要在设备上安装和维护证书，这在一定程度上增加了企业的管理成本和员工的使用成本。

（四）一次性密码（OTP）

一次性密码，也就是我们常说的动态口令，是一种基于密钥和时间戳生成的临时密码。它的工作机制是一个典型的挑战 / 应答过程。以常见的基于时间的一次性密码（TOTP）为例，用户在使用支持 OTP 的应用时，首先需要在手机上安装相应的 OTP 生成器应用，并将其与需要认证的账户进行绑定。绑定过程中，服务器会为用户生成一个唯一的密钥，并将其存储在服务器端和用户的 OTP 生成器应用中。

当用户需要登录时，OTP 生成器应用会根据当前的时间戳以及之前绑定的密钥，按照特定的算法生成一个一次性密码。这个密码在一定时间内（通常为 30 秒到 1 分钟）有效。用户将这个一次性密码输入到登录页面，服务器收到密码后，使用相同的密钥和当前时间戳，按照同样的算法计算出一个预期的一次性密码。若两者一致，则认证成功。这种方式极大地提高了账户的安全性，因为即使黑客获取了用户的用户名和密码，由于一次性密码的时效性，他们也无法利用这些信息成功登录。

import pyotp

# 生成一个新的密钥
secret = pyotp.random_base32() 
totp = pyotp.TOTP(secret)

# 获取当前的一次性密码
current_otp = totp.now() 
print(f"当前的一次性密码: {current_otp}")

OTP动态口令实现

// Google Authenticator算法核心
public class TOTP {
    public static String generateCode(String secret) {
        long time = System.currentTimeMillis() / 30000;
        byte[] key = Base32.decode(secret);
        byte[] data = ByteBuffer.allocate(8).putLong(time).array();
        // HMAC-SHA1运算...
        return truncate(hash).toString();
    }
}

（五）多因素认证

多因素认证，顾名思义，是通过多种不同类型的认证因素来确认用户身份。

常见的认证因素包括用户知道的信息（如密码）、用户拥有的物品（如手机、令牌）以及用户本身的生物特征（如指纹、面部识别）。多因素认证的强度明显高于单因素认证。

例如，在银行的网上转账业务中，用户不仅需要输入密码，还需要输入手机收到的动态验证码，甚至可能需要进行指纹识别。这样，即使黑客获取了用户的密码，由于他们没有用户的手机或指纹，也无法完成转账操作。

在实际应用中，正常情况下可以使用单因素认证，以提高用户体验的便捷性。

比如用户在日常登录一些普通的资讯类网站时，使用用户名和密码进行认证即可。但当出现异常情况，如用户在异地登录、更换设备登录或者进行涉及资金等重要操作时，就需要启用多因素认证来提升安全性，确保用户账户的安全。

（六）FIDO

FIDO（Fast Identity Online）发布了开放的身份认证标准，其中包含 UAF（Universal Authentication Framework）和 U2F（Universal Second Factor）协议。

FIDO 标准支持生物识别等多种认证方式，为用户提供了更加便捷和安全的认证体验。以 U2F 协议为例，它允许用户使用支持 U2F 的设备，如 USB 密钥、手机等，作为第二因素进行认证。当用户登录支持 U2F 的网站时，网站会向用户的 U2F 设备发送一个挑战信息，用户只需将 U2F 设备插入电脑或在手机上确认操作，设备就会生成一个响应信息发送回网站，完成认证过程。

这种方式可以实现无密码或多因素认证。对于无密码认证场景，用户可以通过生物识别（如指纹、面部识别）解锁 U2F 设备，然后使用设备进行认证，无需再记忆复杂的密码。而在多因素认证场景中，结合用户已有的用户名和密码，再加上 U2F 设备的认证，大大增强了账户的安全性。FIDO 标准的推广和应用，有望改变传统的密码认证模式，为用户提供更加安全、便捷的身份认证解决方案。

FIDO无密码认证流程

sequenceDiagram
    participant User
    participant Client
    participant Authenticator
    participant Relying Party

    User->>Client: 发起登录
    Client->>Relying Party: 获取挑战
    Relying Party->>Client: 返回挑战+参数
    Client->>Authenticator: 签名请求
    Authenticator->>User: 生物识别验证
    User->>Authenticator: 完成验证
    Authenticator->>Client: 返回签名
    Client->>Relying Party: 提交认证
    Relying Party-->>Client: 登录成功

四、攻击方式与单点登录

（一）暴力破解和撞库

暴力破解：暴力破解是一种简单粗暴的攻击方式。黑客事先准备好一个包含大量弱密码的列表，同时结合常用的用户名列表，通过自动化工具不断尝试用这些用户名和密码组合去登录目标系统。例如，黑客可能会使用一个脚本，从用户名列表中依次取出用户名，再从弱密码列表中依次取出密码，不断向目标网站的登录接口发送请求。如果某个组合能够成功登录，那么黑客就获取了用户的账户信息。这种攻击方式对于那些使用弱密码的用户来说，具有很大的威胁性。
撞库：撞库攻击利用了用户在不同网站使用相同用户名和密码的习惯。黑客通过各种非法手段获取到某个网站的用户数据库，其中包含用户名和密码（可能是经过哈希处理的）。然后，他们将这些用户名和密码在其他网站上进行尝试登录。因为很多用户为了方便记忆，会在多个网站使用相同的账号密码组合，所以撞库攻击往往能够成功获取用户在其他网站的账户信息。比如，黑客获取了一个小型论坛的用户数据库，然后用其中的用户名和密码尝试登录一些知名的电商平台或社交网站，一旦有用户在这些平台使用了相同的账号密码，其账户就可能被盗用。

现代撞库攻击链

# Hydra暴力破解示例
hydra -L userlist.txt -P passlist.txt ftp://192.168.0.1

# 防御策略四层架构：
1. 网络层：IP信誉库（如Cloudflare防火墙）
2. 应用层：验证码（Google reCAPTCHA v3）
3. 数据层：密码策略（zxcvbn强度评估）
4. 监控层：异常登录检测（UEBA系统）

（二）单点登录

在传统的应用架构中，每个应用都拥有独立的账号系统。这意味着用户在使用多个应用时，需要分别在每个应用中注册账号并记住不同的用户名和密码。例如，用户在使用公司内部的办公系统、邮件系统、文件共享系统等多个应用时，需要为每个应用设置不同的账号密码，这给用户带来了极大的不便。而且，对于企业来说，管理多个独立的账号系统也增加了管理成本和安全风险。

单点登录（Single Sign-On，简称 SSO）的出现，有效地解决了这一问题。单点登录允许用户使用一组凭证（如用户名和密码）登录到一个中心认证系统，然后在访问其他相关应用时，无需再次输入用户名和密码。以企业内部的办公环境为例，用户通过单点登录系统登录到公司的统一认证平台后，当他访问公司的邮件系统、OA 系统等其他内部应用时，这些应用会自动从单点登录系统获取用户的认证信息，确认用户身份后允许用户直接访问，无需用户再次进行登录操作。这样，不仅提高了用户的使用便捷性，也降低了企业的管理成本和安全风险。

（三）Aereo CAS 安全注意事项

Aereo CAS 是一种特定的单点登录解决方案。官方建议通过服务管理工具来处理 service 中的 URL，这是因为如果直接公开 service 中的 URL，可能会导致互联网上的非法用户轻易访问到相关服务，从而引发安全风险。同时，要避免 service 中的 URL 跳转至不可信网站。例如，如果一个恶意攻击者通过某种手段篡改了 service 中的 URL，使其跳转到一个钓鱼网站，那么用户在使用 Aereo CAS 进行单点登录时，就可能会在不知情的情况下将自己的账号密码输入到钓鱼网站，导致账户信息泄露。

在使用 Aereo CAS 时，默认密钥问题也需要特别关注。在一些低版本的 Aereo CAS 中，存在反序列化漏洞风险。黑客可以利用这些漏洞，通过构造恶意的序列化数据，在应用程序反序列化这些数据时执行任意代码，从而获取系统权限或者进行其他恶意操作。为了避免这种风险，用户应及时修改默认密钥，使用高强度、随机生成的密钥，以增强系统的安全性。

CAS协议安全实现

@startuml
actor User
participant "应用系统 (SP)" as SP
participant "CAS Server" as CAS

User -> SP: 访问资源
SP -> User: 重定向到CAS登录
User -> CAS: 提交凭证
CAS -> User: 颁发Service Ticket
User -> SP: 提交Ticket
SP -> CAS: 验证Ticket
CAS -> SP: 返回用户身份
SP -> User: 授权访问资源
@enduml

五、认证相关安全概述

认证在 Web 应用安全中起着至关重要的作用，它解决了 “用户是谁” 的关键问题，是保障整个应用安全的核心环节。认证手段多种多样，不同的认证方式各有其优缺点。通过将多种认证方式组合使用，可以有效地增强安全强度。例如，结合密码认证和一次性密码认证，即使密码被泄露，由于一次性密码的时效性，黑客也无法轻易登录用户账户。

传统的密码认证方式虽然使用广泛，但由于弱密码的存在以及密码泄露的风险，正逐渐受到新的认证方式的挑战。随着技术的不断发展，如生物识别技术、FIDO 标准等新的认证方式和标准不断涌现，它们为用户提供了更加安全、便捷的认证体验。

主流的单点登录系统在提升用户登录便捷性方面发挥了重要作用。然而，如果使用不当，也会带来一定的风险。比如，单点登录系统的认证中心一旦被攻破，黑客就可能获取到所有用户的认证信息，进而访问用户在各个相关应用中的账户。此外，在一些单点登录系统中，还存在用户无法完全退出的问题。例如，用户在使用完某个应用后，虽然在该应用中点击了退出登录，但由于单点登录系统的某些机制问题，用户在其他相关应用中仍然处于登录状态，这可能会导致用户的账户信息在不知情的情况下被泄露。

六、OAuth 相关

OAuth 2.0 是目前互联网领域中极为重要的授权协议。它定义了不同类型的授权模式，每种模式都有其特定的适用场景和操作流程。

授权码模式：这是 OAuth 2.0 中最为常用的授权模式。以用户使用第三方应用（如某音乐播放器）登录到某音乐平台为例，用户在音乐播放器中点击登录该音乐平台的按钮后，音乐播放器会将用户重定向到音乐平台的授权页面。在授权页面，用户需要输入自己在音乐平台的账号密码进行登录，并授权音乐播放器访问自己在音乐平台的相关资源（如音乐收藏列表）。音乐平台验证用户身份并获得用户授权后，会生成一个授权码，并将用户重定向回音乐播放器，同时在重定向的 URL 中带上这个授权码。音乐播放器收到授权码后，使用自己在音乐平台注册时获得的客户端 ID 和客户端密钥，向音乐平台的令牌端点发送请求，换取访问令牌。音乐播放器获得访问令牌后，就可以使用这个令牌访问用户在音乐平台的相关资源。
隐式授权模式：隐式授权模式适用于一些纯前端的应用，如在浏览器中运行的 JavaScript 应用。在这种模式下，用户同样在第三方应用中发起登录请求，第三方应用将用户重定向到授权服务器的授权页面。用户授权后，授权服务器会直接在重定向回第三方应用的 URL 中返回访问令牌，而不需要通过中间的授权码交换步骤。这种模式的优点是简单直接，但由于访问令牌直接暴露在 URL 中，存在一定的安全风险，所以适用于一些对安全性要求相对较低且资源访问权限有限的场景。
客户端凭证模式：客户端凭证模式主要用于服务端应用之间的授权。例如，一个企业内部的数据分析系统需要访问企业的数据库获取数据进行分析。在这种情况下，数据分析系统作为客户端，向授权服务器申请访问令牌时，使用的是自己的客户端 ID 和客户端密钥，而不需要用户的参与。授权服务器验证客户端的身份后，会为其颁发访问令牌，客户端使用这个令牌就可以访问授权范围内的资源，如数据库中的特定数据表。

刷新令牌机制

在 OAuth 2.0 中，刷新令牌机制是一项重要的特性。访问令牌通常有较短的有效期，这是为了降低令牌泄露带来的风险。一旦访问令牌过期，应用就无法再使用它访问受保护的资源。而刷新令牌的作用就是在访问令牌过期时，用于获取新的访问令牌，而无需用户再次进行完整的授权流程。

继续以音乐播放器为例，当音乐播放器使用授权码模式获取到访问令牌和刷新令牌后，在访问令牌的有效期内，它可以顺利访问用户在音乐平台的资源。假设访问令牌的有效期是 1 小时，当 1 小时过去后，音乐播放器再次尝试访问资源时，音乐平台会返回一个表示令牌过期的错误响应。

七、OIDC 相关

OIDC（OpenID Connect）构建于 OAuth 2.0 协议之上，它为 OAuth 2.0 增添了关键的身份认证功能，从而使开发者能够轻松实现用户身份的验证与授权。许多知名社交网站，如 Google、Facebook 等，都大力支持 OIDC，这为用户登录各类应用带来了极大的便利。

从技术层面深入剖析，OIDC 在 OAuth 2.0 的基础上引入了一系列新的概念与规范。它定义了专门用于描述用户身份信息的 ID 令牌（ID Token）。当用户使用支持 OIDC 的社交账号登录第三方应用时，流程如下：用户在第三方应用中点击使用社交账号登录的按钮，第三方应用随即引导用户跳转至对应的社交网站授权页面。用户在该页面输入账号密码并授权第三方应用访问其部分信息后，社交网站作为 OIDC 的身份提供者（Identity Provider，简称 IdP），会生成一个包含用户身份信息的 ID 令牌以及用于访问用户资源的访问令牌。这两个令牌会通过特定的重定向流程传递回第三方应用。第三方应用收到令牌后，通过验证 ID 令牌的签名等方式，确认用户身份的真实性与合法性，进而完成整个登录过程。

以用户使用 Google 账号登录一款在线文档编辑应用为例，用户在文档编辑应用中选择用 Google 登录，页面跳转到 Google 的登录与授权界面。用户登录并授权后，Google 会向文档编辑应用返回 ID 令牌和访问令牌。文档编辑应用验证 ID 令牌，从中获取用户的邮箱、姓名等身份信息，为用户创建或关联对应的应用账号，使用户能便捷地开始使用应用功能，而无需在该应用中重新注册账号。这种方式不仅简化了用户注册登录流程，还减少了用户因需记忆众多不同平台账号密码而带来的困扰，同时借助社交平台强大的安全体系，提升了整个登录过程的安全性。

八、SAML 相关

SAML（Security Assertion Markup Language），即安全断言标记语言，在身份提供者（IdP）和服务提供者（Service Provider，简称 SP）之间扮演着关键的数据交换桥梁角色，主要用于交换身份验证和授权数据。它采用 XML 格式来结构化和传输这些重要信息，具有良好的通用性和扩展性。

在简化的 SAML 协议认证流程中，用户首先访问服务提供者（SP）的应用系统。

例如，一家企业员工试图访问外部合作公司提供的特定业务应用（该应用作为 SP）。当员工尝试访问时，该应用发现员工未经过身份验证，于是将用户的浏览器重定向到身份提供者（IdP）的认证页面，通常是企业内部的统一身份认证系统。员工在身份提供者页面输入自己的企业账号密码进行登录。身份提供者验证员工身份无误后，会生成包含用户身份信息、权限信息等内容的 SAML 断言（Assertion）。这个断言本质上是一个经过数字签名的 XML 文档，以确保信息的完整性和真实性。随后，身份提供者将用户的浏览器重定向回服务提供者的应用，并在重定向的请求中携带 SAML 断言。服务提供者接收到断言后，通过验证签名等步骤确认断言的有效性，从而获取用户的身份和授权信息，完成用户的认证过程，允许用户访问相应的应用功能。

SAML 协议在企业间的跨域单点登录场景中应用极为广泛。比如，企业与多个合作伙伴有业务往来，员工需要访问合作伙伴提供的各类服务系统。通过 SAML 协议，企业内部的身份认证系统作为身份提供者，能够与合作伙伴的服务提供者系统进行高效对接，实现员工在不同企业应用间的便捷切换，无需重复登录，同时保障了身份验证和授权信息在不同系统间安全、准确地传递。

九、CAS 相关

CAS（Central Authentication Service），即中央认证服务，是一种广泛应用的单点登录解决方案。它致力于解决用户在访问多个相互关联的应用系统时，避免重复输入用户名和密码的繁琐问题。

其工作流程具有清晰的逻辑架构。当用户尝试访问某个应用（我们称之为客户端应用）时，客户端应用首先检查用户是否已经通过认证。若未认证，客户端应用会将用户的请求重定向到 CAS Server。

例如，在一个大型企业内部，员工试图访问公司的财务报销系统，而该系统与 CAS Server 集成。当员工访问报销系统时，报销系统发现员工未登录，于是将员工的浏览器重定向到公司统一的 CAS Server 登录页面。员工在 CAS Server 页面输入自己的企业账号密码进行认证。CAS Server 验证用户身份成功后，会为用户生成一个唯一的票据（Ticket），这个票据类似于一把临时钥匙。随后，CAS Server 将用户的浏览器重定向回客户端应用（财务报销系统），并在重定向的 URL 中附上这个票据。客户端应用接收到票据后，会将票据发送回 CAS Server 进行验证。CAS Server 确认票据有效后，向客户端应用返回用户的身份信息，客户端应用据此确认用户身份，允许用户访问系统资源，完成整个认证流程。

通过 CAS 实现单点登录，大大提升了企业内部多个应用系统的用户体验，员工只需在 CAS Server 进行一次登录，即可顺畅访问多个关联应用，同时减轻了企业对多个应用系统分别进行用户认证管理的负担，集中化的认证管理也有助于提高整体的安全性，降低因多套认证系统带来的安全风险。