Basic authentication
HTTP 基本认证是用于对 Web 资源强制实施访问控制最省资源的技术之一。您可以使用 HTTP 基本认证保护您的 Quarkus 应用程序端点。Quarkus 包含用于基本认证的内置认证机制。 基本认证使用 HTTP 标头中的字段，而不依赖于 HTTP cookie、会话标识符或登录页面。
Authorization header
HTTP 用户代理（如 Web 浏览器）使用 Authorization`标头在每个 HTTP 请求中提供用户名和密码。标头指定为 `Authorization: Basic <credentials>，其中的凭证是用户 ID 和密码的 Base64 编码，由冒号连接。
如果用户名为 Alice`且密码为 `secret，则 HTTP 授权标头将为 Authorization: Basic QWxjZTpzZWNyZXQ=，其中 `QWxjZTpzZWNyZXQ=`是 `Alice:secret`字符串的 Base64 编码表示形式。
基本认证机制不为传输的凭证提供机密性保护。传输过程中凭证仅通过 Base64 编码，而不以任何方式加密或哈希化。因此，为了提供机密性，请将基本认证与 HTTPS 结合使用。
基本认证是一个明确、简单的质询和响应方案，所有 Web 浏览器和大多数 Web 服务器都能理解。
Limitations with using Basic authentication
下表概述了使用 HTTP 基本认证保护您的 Quarkus 应用程序时的一些限制：
| Limitation | Description |
|---|---|
凭证以纯文本形式发送 |
将 HTTPS 与基本认证结合使用，以避免暴露凭证。如果负载均衡器终止 HTTPS，因为请求通过 HTTP 转发到 Quarkus，则以纯文本形式暴露凭证的风险增加。此外，在多跳部署中，如果仅在客户端和第一个 Quarkus 端点之间使用 HTTPS，并且凭证通过 HTTP 传播到下一个 Quarkus 端点，则凭证可能会被暴露。 |
每次请求都发送凭证 |
在基本认证中，必须随每个请求一起发送用户名和密码，从而增加了暴露凭证的风险。 |
Application complexity increases |
Quarkus 应用程序必须验证用户名、密码和角色得到安全管理。但是，此过程可能会给应用程序带来相当大的复杂性。根据用例，将用户名、密码和角色管理委托给专门服务的其他身份验证机制可能更安全。 |
Role-based access control
Quarkus 还包括内置安全性，以允许基于 REST 端点和 CDI bean 上通用安全性批注 @RolesAllowed、@DenyAll、`@PermitAll`的角色访问控制 (RBAC)。有关更多信息，请参阅 Quarkus Authorization of web endpoints指南。