随着互联网技术的飞速发展，网络安全问题日益凸显，企业信息安全与身份认证系统变得越来越重要，而且安全认证集成方案作为保障网络安全的重要一环，其研究与应用也至关重要。在这种背景下，Pac4j 作为一种流行的身份验证库，广泛应用于 Java 应用程序，旨在为企业级应用提供高效、安全的认证服务。Pac4j 全称为 Powerful Authentication Client for Java，它支持多种身份验证协议，如 CAS、OAuth2、LDAP 等，是构建安全认证的集成方案。它提供了简单易用的 API，使得开发者能够轻松地集成身份验证功能到他们的应用程序中。
Pac4j 的一大特点就是为不同供应商提供了很完善的 Client , 基本上无需定制就可以实现认证的处理。它解决了认证过程的复杂性 , 使用者进行简单的调用就可以直接拿到用户信息。
Why choose pac4j?
1 security library = 1 security model for all frameworks
for al authorization mechanisms
for all authentication mechanisms
从编程角度讲，这种方法论是很棒的！简单高效强壮！
与 Spring Security 对比
作者认为 Spring Security 是一个 library，而 pac4j 是一个 framework，虽然都是搞安全的 secuity。详细分析对比参见作者博客：https://www.pac4j.org/blog/spring-boot-security-choose-spring-webmvc-pac4j.html。
客户端 Client
客户端=在 Web 上的一种认证机制。客户端登录成功的话则返回用户信息（User Profile）。Client 有两种案例：
-
间接的客户端（Indirect clients），这类特征是 UI 程序 有界面的，有状态的（stateful），需要回调的。间接客户端（Indirect clients）在用户认证过程中通常指的是那些不直接与身份服务器进行交互的应用程序。这种情况下，应用程序会通过用户的浏览器重定向到身份服务器来进行认证，然后由身份服务器重定向回应用程序的一个回调端点（callback endpoint）。
-
直接客户端（Direct clients）在 Web 服务认证中指的是那些直接与身份服务器或资源服务器进行交互的应用程序，通常用于后端服务之间的通信。这类客户端不需要通过用户的浏览器重定向来进行认证，而是直接使用凭据（如 API 密钥、客户端 ID 和秘密等）来获取访问令牌，并且每次 HTTP 请求都携带这个令牌。这种模式通常是无状态的（stateless），即服务器不保存任何会话信息，每个请求都需要提供足够的信息来验证用户的身份。
我们可以通过下面的表格来对比两者。
| 直接客户端 Direct clients = Web Service / 接口认证 | 间接的客户端（Indirect clients）= UI 程序 | |
|---|---|---|
| 认证流程 | 每次 HTTP 请求都携带凭证 | 1、原请求地址保存在 session；2、用户跳转到身份供应中心；3、进行登录；4、用户跳转到回调地址；5、返回原请求地址 |
| 登录多少次？ | 每次 HTTP 请求都要。性能方面考量，可以设置缓存 | 登录一次即可 |
| 凭据在哪里？ | 每次 HTTP 请求 | 身份提供者的回调 |
| 用户信息保存在哪里？ | 每次 HTTP 请求（无状态的） | Session（有状态的） |
P.S 关于各种安全认证协议，Pac4j 作者有篇博文介绍得非常好。
Pac4j 把常见的登录认证过程抽象成为这两大类，不得不说是其一种创新，对比 Spring Secuity 就没有了。OAuth, CAS, SAML or OpenID Connect 这类协议都是间接客户端，所以都有一个回调地址。如果用户认证登录成功，那么将由回调地址来发起一次跳转，跳转到目标应用程序中。
支持的客户端
Pac4j 支持下面的客户端：
OAuth protocol
SAML protocol
CAS protocol
OpenID Connect protocol
HTTP protocol
Google App Engine support
Kerberos (SPNEGO Negotiate) protocol
虽然大多数客户端都是独立可用的，但 HTTP 客户端需要定义一个认证器（Authenticator） 来处理凭证校验。
客户端（如授权器 authorizers 和匹配器 matcher）通常在安全配置（security configuration）中定义。
每个客户端都有一个以类名作为默认的名称（如 FacebookClient），但可以使用 setName 方法将其显式设置为另一个值。
代码体系
Pac4j 扩展性强，代码清晰，耦合性低，非常不错。
在这么多体系的情况下 ,通过 Context 完成整体容器的协调 , 在通过 RedirectAction 做统一的 请求重定向。
依赖
Pac4j 依赖很少，有下面这些。
- bcprov-jdk15on Bouncy Castle 是一个开源的密码学库，提供了广泛的加密算法实现，包括但不限于 AES、DES、RSA、DSA、ECDSA 等，以及用于生成和验证数字签名的功能
- jBCrypt 使用 Blowfish 加密算法，不可逆的加密算法，无法通过解密哈希值来获取明文密码
- Nimbus JOSE + JWT 用于处理 JSON Web Tokens (JWT)
- ScribeJava 简单易用的 OAuth 客户端库，它支持 OAuth 1.0a 和 OAuth 2.0 协议，帮助开发者轻松集成第三方认证服务，如 Facebook、Google、Twitter、LinkedIn 等
用户信息 User Profile
在身份验证成功后，你需要从身份验证服务器中提取用户信息，并将其存储在你的应用程序中。这通常涉及到编写代码来获取和解析用户信息。这些已认证的用户信息在 Pac4j 中以UserProfile子类呈现，包括各种的实现例如 FacebookUserProfile、CasUserProfile 等等。
间接客户端的用户信息存储在 Session中；而直接客户端的用户信息存储在每次 HTTP 请求中。
用户信息包括：
- 用户信息唯一标识
- 用户属性（例如性别、姓名等）
- 用户的角色、权限
获取用户信息的几种手段：
- 当前 HTTP 请求，在 Pac4j 中是 WebContext
- SessionStore，在 Session 中获取
- ProfileManager 组件
例子
Authenticator 认证器
Authenticator 认证器用于客户端认证身份。所谓认证所需的元素就在这个接口方法中：
void validate(Credentials credentials, WebContext context, SessionStore sessionStore)
如果一个 client 成功认证了那么就会抛出一个HttpAcion来中止 web 流程，然后跑去跳转（也可以其他的动作）。
内置的 Authenticator 如下。
Credentials 凭据
凭据的校验，由客户端的认证器（Authenticator）进行校验。分两类：
- UsernamePasswordCredentials
- TokenCredentials
所有客户端都有其内置的、默认的认证器执行凭据的校验，根据不同的安全协议，但是除了 HTTP 客户端，它不包括认证器。因为 HTTP 只知道如何获取凭据（例如从参数获取、从 http 头获取等等），而不知道接下来怎么干，于是就需要特定的认证器来完成凭据的校验。例如
另外，其子类 ProfileService不仅验证用户身份，还进行用户信息的创建、更新和删除。
用户的角色权限由AuthorizationGenerator获取。匿名用户使用 AnonymousClient 自动“认证”（其实意思是不用认证），这时候须使用 isAnonymous and isAuthenticated 的授权器。
同一个 URL，可以让多个 client 来认证，例如微信认证、微博认证，默认是这个 list 的第一个。你也可以通过force_client指定一个。
Authorizer 授权器
Authorizer 基于网页上下文信息和用户信息进行权限验证，例如 RequireAnyRoleAuthorizer,，RequireAllRolesAuthorizer，CheckProfileTypeAuthorizer,，CsrfAuthorizer 等。
Logout 登出
登出可以在应用程序本地执行或者在认证中心执行
Matcher 匹配器
Matcher 匹配器定义安全性是否必须应用于安全过滤器。例如某些 URL 开放、某些 URL 须认证保护，自定义安全头等（X-Frame-Options、Strict-Transport-Security）。
Config 配置器
客户端、授权器和匹配器联合一起定义安全配置
ProfileCreator 自定义身份验证
如果你需要自定义身份验证流程，pac4j 提供了丰富的扩展点，你可以编写自己的身份验证提供者。
