Quarkus Security architecture
Quarkus Security 架构提供了多个内置认证机制，并且高度可自定义。在 Quarkus 中保护 HTTP 应用程序的主要机制是 @“28” 接口。
Overview of the Quarkus Security architecture
当客户端发送 HTTP 请求时，Quarkus 安全通过与多个内置核心组件的交互协调安全认证和授权，其中包括 HttpAuthenticationMechanism、IdentityProvider`和 `SecurityIdentityAugmentor。
连续安全验证过程会产生三个结果之一：
-
HTTP 请求获得授权并认证，授予对 Quarkus 应用程序的访问权限。
-
HTTP 请求认证失败，请求方会收到特定于认证机制的挑战，例如 `401`错误、需要重新认证的 URL 重定向，或其他自定义认证挑战响应。要了解有关挑战响应的实际示例，请参见 Quarkus Security Tips and Tricks指南。
-
HTTP 请求授权失败，请求方被拒绝访问 Quarkus 应用程序。
下图介绍了 Quarkus 安全架构的详细流程：
Core components of the Quarkus Security architecture
HttpAuthenticationMechanism
Quarkus 安全使用 HttpAuthenticationMechanism`从 HTTP 请求中提取认证凭证，然后委托 `IdentityProvider`将凭证转换为 `SecurityIdentity。例如，凭证可能来自 `Authorization`标头、客户端 HTTPS 证书或 cookie。
当 Quarkus 安全拒绝认证请求时，`HttpAuthenticationMechanism`将认证挑战返回给客户端。挑战类型取决于认证机制。例如，使用 OIDC OpenID Connect (OIDC) 授权代码流机制，将生成重定向 URL，客户端返回到 OpenID Connect 提供程序进行认证。
IdentityProvider
IdentityProvider`验证认证凭证并将其映射到 `SecurityIdentity，其中包含用户名、角色、原始认证凭证和其他属性。
你可以为每个已认证资源注入一个 `SecurityIdentity`实例，获取已认证的身份信息。
在其他上下文中，可能同时表示相同的某些信息或部分信息的平行表示形式，例如 Jakarta REST 的 SecurityContext`或 JSON Web 令牌 (JWT) 的 `JsonWebToken。
有关更多信息，请参见 Quarkus Identity providers指南。
SecurityIdentityAugmentor
由于 Quarkus 安全是可自定义的，你还可以向 `SecurityIdentity`添加授权角色，并注册和优先考虑一个或多个 `SecurityAugmentor`实现。
`SecurityIdentityAugmentor`的已注册实例在安全认证过程的最后阶段被调用。有关更多信息，请参见“安全提示与技巧”指南的 Security Identity Customization部分。
Supported authentication mechanisms
Quarkus 安全框架支持多种认证机制，它们还可以组合在一起。某些受支持的认证机制内置于 Quarkus 中，而另一些则需要添加扩展。
要了解 Quarkus 中的安全认证以及受支持的机制和协议，请参见 Quarkus Authentication mechanisms in Quarkus指南。
Proactive authentication
Quarkus 中默认启用主动认证。如果传入请求有凭证，即使目标网页不需要认证，请求也会始终被认证。有关更多信息，请参见 Quarkus Proactive authentication指南。
Quarkus Security customization
Quarkus 安全是可自定义的。你可以自定义 Quarkus 的以下核心安全组件：
-
HttpAuthenticationMechanism -
IdentityProvider -
SecurityidentityAugmentor
有关自定义 Quarkus 安全的更多信息，包括响应式安全和如何注册安全提供程序，请参见 Quarkus Security tips and tricks指南。