2.2.2. Form-based authentication


Quarkus provides form-based authentication that works similarly to traditional Servlet form-based authentication. Unlike traditional form authentication, the authenticated user is not stored in an HTTP session because Quarkus does not support clustered HTTP sessions. Instead, the authentication information is stored in an encrypted cookie, which can be read by all cluster members who share the same encryption key.

To apply encryption, add the quarkus.http.auth.session.encryption-key property, and ensure the value you set is at least 16 characters long. The encryption key is hashed by using SHA-256. The resulting digest is used as a key for AES-256 encryption of the cookie value. The cookie contains an expiry time as part of the encrypted value, so all nodes in the cluster must have their clocks synchronized. At one-minute intervals, a new cookie gets generated with an updated expiry time if the session is in use.

To get started with form authentication, you should have similar settings as described in Enable Basic authentication and property quarkus.http.auth.form.enabled must be set to true.

Simple application.properties with form-base authentication can look similar to this:

quarkus.http.auth.form.enabled=true

quarkus.http.auth.form.login-page=login.html
quarkus.http.auth.form.landing-page=hello
quarkus.http.auth.form.error-page=

# Define testing user
quarkus.security.users.embedded.enabled=true
quarkus.security.users.embedded.plain-text=true
quarkus.security.users.embedded.users.alice=alice
quarkus.security.users.embedded.roles.alice=user
중요

Configuring user names, secrets, and roles in the application.properties file is appropriate only for testing scenarios. For securing a production application, it is crucial to use a database or LDAP to store this information. For more information you can take a look at Quarkus Security with Jakarta Persistence or other mentioned in Enable Basic authentication.

and application login page will contain HTML form similar to this:

<form action="/j_security_check" method="post">
    <label>Username</label>
    <input type="text" placeholder="Username" name="j_username" required>
    <label>Password</label>
    <input type="password" placeholder="Password" name="j_password" required>
    <button type="submit">Login</button>
</form>

With single-page applications (SPA), you typically want to avoid redirects by removing default page paths, as shown in the following example:

# do not redirect, respond with HTTP 200 OK
quarkus.http.auth.form.landing-page=

# do not redirect, respond with HTTP 401 Unauthorized
quarkus.http.auth.form.login-page=
quarkus.http.auth.form.error-page=

# HttpOnly must be false if you want to log out on the client; it can be true if logging out from the server
quarkus.http.auth.form.http-only-cookie=false

Now that you have disabled redirects for the SPA, you must log in and log out programmatically from your client. Below are examples of JavaScript methods for logging into the j_security_check endpoint and logging out of the application by destroying the cookie.

const login = () => {
    // Create an object to represent the form data
    const formData = new URLSearchParams();
    formData.append("j_username", username);
    formData.append("j_password", password);

    // Make an HTTP POST request using fetch against j_security_check endpoint
    fetch("j_security_check", {
        method: "POST",
        body: formData,
        headers: {
            "Content-Type": "application/x-www-form-urlencoded",
        },
    })
    .then((response) => {
        if (response.status === 200) {
            // Authentication was successful
            console.log("Authentication successful");
        } else {
            // Authentication failed
            console.error("Invalid credentials");
        }
    })
    .catch((error) => {
        console.error(error);
    });
};

To log out of the SPA from the client, the cookie must be set to quarkus.http.auth.form.http-only-cookie=false so you can destroy the cookie and possibly redirect back to your main page.

const logout= () => {
    // delete the credential cookie, essentially killing the session
    const removeCookie = `quarkus-credential=; Max-Age=0;path=/`;
    document.cookie = removeCookie;

    // perform post-logout actions here, such as redirecting back to your login page
};

To log out of the SPA from the server, the cookie can be set to quarkus.http.auth.form.http-only-cookie=true and use this example code to destroy the cookie.

import io.quarkus.security.identity.CurrentIdentityAssociation;
import io.quarkus.vertx.http.runtime.security.FormAuthenticationMechanism;
import jakarta.ws.rs.core.Response;
import jakarta.ws.rs.POST;

@Inject
CurrentIdentityAssociation identity;

@POST
public Response logout() {
    if (identity.getIdentity().isAnonymous()) {
        throw new UnauthorizedException("Not authenticated");
    }
    FormAuthenticationMechanism.logout(identity.getIdentity()); 
1

    return Response.noContent().build();
}
1
Perform the logout by removing the session cookie.

The following properties can be used to configure form-based authentication:

🔒 Fixed at build time - Configuration property fixed at build time - All other configuration properties are overridable at runtime

Expand

Configuration property

Type

Default

quarkus.http.auth.permission."permissions".enabled

Determines whether the entire permission set is enabled, or not.

By default, if the permission set is defined, it is enabled.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__ENABLED

boolean

 

quarkus.http.auth.permission."permissions".policy

The HTTP policy that this permission set is linked to.

There are three built-in policies: permit, deny and authenticated. Role based policies can be defined, and extensions can add their own policies.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__POLICY

string

required ⚠️ Required

quarkus.http.auth.permission."permissions".methods

The methods that this permission set applies to. If this is not set then they apply to all methods.

Note that if a request matches any path from any permission set, but does not match the constraint due to the method not being listed then the request will be denied.

Method specific permissions take precedence over matches that do not have any methods set.

This means that for example if Quarkus is configured to allow GET and POST requests to /admin to and no other permissions are configured PUT requests to /admin will be denied.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__METHODS

list of string

 

quarkus.http.auth.permission."permissions".paths

The paths that this permission check applies to. If the path ends in /* then this is treated as a path prefix, otherwise it is treated as an exact match.

Matches are done on a length basis, so the most specific path match takes precedence.

If multiple permission sets match the same path then explicit methods matches take precedence over matches without methods set, otherwise the most restrictive permissions are applied.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__PATHS

list of string

 

quarkus.http.auth.permission."permissions".auth-mechanism

Path specific authentication mechanism which must be used to authenticate a user. It needs to match io.quarkus.vertx.http.runtime.security.HttpCredentialTransport authentication scheme such as 'basic', 'bearer', 'form', etc.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__AUTH_MECHANISM

string

 

quarkus.http.auth.permission."permissions".shared

Indicates that this policy always applies to the matched paths in addition to the policy with a winning path. Avoid creating more than one shared policy to minimize the performance impact.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__SHARED

boolean

false

quarkus.http.auth.permission."permissions".applies-to

Whether permission check should be applied on all matching paths, or paths specific for the Jakarta REST resources.

Environment variable: QUARKUS_HTTP_AUTH_PERMISSION__PERMISSIONS__APPLIES_TO

all: Apply on all matching paths.

jaxrs: Declares that a permission check must only be applied on the Jakarta REST request paths. Use this option to delay the permission check if an authentication mechanism is chosen with an annotation on the matching Jakarta REST endpoint. This option must be set if the following REST endpoint annotations are used: - io.quarkus.oidc.Tenant annotation which selects an OIDC authentication mechanism with a tenant identifier - io.quarkus.vertx.http.runtime.security.annotation.BasicAuthentication which selects the Basic authentication mechanism - io.quarkus.vertx.http.runtime.security.annotation.FormAuthentication which selects the Form-based authentication mechanism - io.quarkus.vertx.http.runtime.security.annotation.MTLSAuthentication which selects the mTLS authentication mechanism - io.quarkus.security.webauthn.WebAuthn which selects the WebAuth authentication mechanism - io.quarkus.oidc.BearerTokenAuthentication which selects the OpenID Connect Bearer token authentication mechanism - io.quarkus.oidc.AuthorizationCodeFlow which selects the OpenID Connect Code authentication mechanism

all

quarkus.http.auth.policy."role-policy".roles-allowed

The roles that are allowed to access resources protected by this policy. By default, access is allowed to any authenticated user.

Environment variable: QUARKUS_HTTP_AUTH_POLICY__ROLE_POLICY__ROLES_ALLOWED

list of string

**

quarkus.http.auth.policy."role-policy".roles."role-name"

Add roles granted to the SecurityIdentity based on the roles that the SecurityIdentity already have. For example, the Quarkus OIDC extension can map roles from the verified JWT access token, and you may want to remap them to a deployment specific roles.

Environment variable: QUARKUS_HTTP_AUTH_POLICY__ROLE_POLICY__ROLES__ROLE_NAME_

Map<String,List<String>>

 

quarkus.http.auth.policy."role-policy".permissions."role-name"

Permissions granted to the SecurityIdentity if this policy is applied successfully (the policy allows request to proceed) and the authenticated request has required role. For example, you can map permission perm1 with actions action1 and action2 to role admin by setting quarkus.http.auth.policy.role-policy1.permissions.admin=perm1:action1,perm1:action2 configuration property. Granted permissions are used for authorization with the @PermissionsAllowed annotation.

Environment variable: QUARKUS_HTTP_AUTH_POLICY__ROLE_POLICY__PERMISSIONS__ROLE_NAME_

Map<String,List<String>>

 

quarkus.http.auth.policy."role-policy".permission-class

Permissions granted by this policy will be created with a java.security.Permission implementation specified by this configuration property. The permission class must declare exactly one constructor that accepts permission name (String) or permission name and actions (String, String[]). Permission class must be registered for reflection if you run your application in a native mode.

Environment variable: QUARKUS_HTTP_AUTH_POLICY__ROLE_POLICY__PERMISSION_CLASS

string

io.quarkus.security.StringPermission

quarkus.http.auth.roles-mapping."role-name"

Map the SecurityIdentity roles to deployment specific roles and add the matching roles to SecurityIdentity.

For example, if SecurityIdentity has a user role and the endpoint is secured with a 'UserRole' role, use this property to map the user role to the UserRole role, and have SecurityIdentity to have both user and UserRole roles.

Environment variable: QUARKUS_HTTP_AUTH_ROLES_MAPPING__ROLE_NAME_

Map<String,List<String>>

 

quarkus.http.auth.certificate-role-attribute

Client certificate attribute whose values are going to be mapped to the 'SecurityIdentity' roles according to the roles mapping specified in the certificate properties file. The attribute must be either one of the Relative Distinguished Names (RDNs) or Subject Alternative Names (SANs). By default, the Common Name (CN) attribute value is used for roles mapping. Supported values are:

  • RDN type - Distinguished Name field. For example 'CN' represents Common Name field. Multivalued RNDs and multiple instances of the same attributes are currently not supported.
  • 'SAN_RFC822' - Subject Alternative Name field RFC 822 Name.
  • 'SAN_URI' - Subject Alternative Name field Uniform Resource Identifier (URI).
  • 'SAN_ANY' - Subject Alternative Name field Other Name. Please note that only simple case of UTF8 identifier mapping is supported. For example, you can map 'other-identifier' to the SecurityIdentity roles. If you use 'openssl' tool, supported Other name definition would look like this: subjectAltName=otherName:1.2.3.4;UTF8:other-identifier

Environment variable: QUARKUS_HTTP_AUTH_CERTIFICATE_ROLE_ATTRIBUTE

string

CN

quarkus.http.auth.certificate-role-properties

Properties file containing the client certificate attribute value to role mappings. Use it only if the mTLS authentication mechanism is enabled with either quarkus.http.ssl.client-auth=required or quarkus.http.ssl.client-auth=request.

Properties file is expected to have the CN_VALUE=role1,role,…​,roleN format and should be encoded using UTF-8.

Environment variable: QUARKUS_HTTP_AUTH_CERTIFICATE_ROLE_PROPERTIES

path

 

quarkus.http.auth.realm

The authentication realm

Environment variable: QUARKUS_HTTP_AUTH_REALM

string

 

quarkus.http.auth.form.login-page

The login page. Redirect to login page can be disabled by setting quarkus.http.auth.form.login-page=.

Environment variable: QUARKUS_HTTP_AUTH_FORM_LOGIN_PAGE

string

/login.html

quarkus.http.auth.form.username-parameter

The username field name.

Environment variable: QUARKUS_HTTP_AUTH_FORM_USERNAME_PARAMETER

string

j_username

quarkus.http.auth.form.password-parameter

The password field name.

Environment variable: QUARKUS_HTTP_AUTH_FORM_PASSWORD_PARAMETER

string

j_password

quarkus.http.auth.form.error-page

The error page. Redirect to error page can be disabled by setting quarkus.http.auth.form.error-page=.

Environment variable: QUARKUS_HTTP_AUTH_FORM_ERROR_PAGE

string

/error.html

quarkus.http.auth.form.landing-page

The landing page to redirect to if there is no saved page to redirect back to. Redirect to landing page can be disabled by setting quarkus.http.auth.form.landing-page=.

Environment variable: QUARKUS_HTTP_AUTH_FORM_LANDING_PAGE

string

/index.html

quarkus.http.auth.form.location-cookie

Option to control the name of the cookie used to redirect the user back to the location they want to access.

Environment variable: QUARKUS_HTTP_AUTH_FORM_LOCATION_COOKIE

string

quarkus-redirect-location

quarkus.http.auth.form.timeout

The inactivity (idle) timeout

When inactivity timeout is reached, cookie is not renewed and a new login is enforced.

Environment variable: QUARKUS_HTTP_AUTH_FORM_TIMEOUT

Duration ℹ️ Duration format

PT30M

quarkus.http.auth.form.new-cookie-interval

How old a cookie can get before it will be replaced with a new cookie with an updated timeout, also referred to as "renewal-timeout".

Note that smaller values will result in slightly more server load (as new encrypted cookies will be generated more often); however, larger values affect the inactivity timeout because the timeout is set when a cookie is generated.

For example if this is set to 10 minutes, and the inactivity timeout is 30m, if a user’s last request is when the cookie is 9m old then the actual timeout will happen 21m after the last request because the timeout is only refreshed when a new cookie is generated.

That is, no timeout is tracked on the server side; the timestamp is encoded and encrypted in the cookie itself, and it is decrypted and parsed with each request.

Environment variable: QUARKUS_HTTP_AUTH_FORM_NEW_COOKIE_INTERVAL

Duration ℹ️ Duration format

PT1M

quarkus.http.auth.form.cookie-name

The cookie that is used to store the persistent session

Environment variable: QUARKUS_HTTP_AUTH_FORM_COOKIE_NAME

string

quarkus-credential

quarkus.http.auth.form.cookie-path

The cookie path for the session and location cookies.

Environment variable: QUARKUS_HTTP_AUTH_FORM_COOKIE_PATH

string

/

quarkus.http.auth.form.http-only-cookie

Set the HttpOnly attribute to prevent access to the cookie via JavaScript.

Environment variable: QUARKUS_HTTP_AUTH_FORM_HTTP_ONLY_COOKIE

boolean

false

quarkus.http.auth.form.cookie-same-site

SameSite attribute for the session and location cookies.

Environment variable: QUARKUS_HTTP_AUTH_FORM_COOKIE_SAME_SITE

strict, lax, none

strict

quarkus.http.auth.form.cookie-max-age

Max-Age attribute for the session cookie. This is the amount of time the browser will keep the cookie.

The default value is empty, which means the cookie will be kept until the browser is closed.

Environment variable: QUARKUS_HTTP_AUTH_FORM_COOKIE_MAX_AGE

Duration ℹ️ Duration format

 

quarkus.http.auth.inclusive

Require that all registered HTTP authentication mechanisms must attempt to verify the request credentials.

By default, when the inclusive-mode is strict, every registered authentication mechanism must produce SecurityIdentity, otherwise, a number of mechanisms which produce the identity may be less than a total number of registered mechanisms.

All produced security identities can be retrieved using the following utility method:

`io.quarkus.vertx.http.runtime.security.HttpSecurityUtils++#++getSecurityIdentities(io.quarkus.security.identity.SecurityIdentity)`

An injected SecurityIdentity represents an identity produced by the first inclusive authentication mechanism. When the mTLS authentication is required, the mTLS mechanism is always the first mechanism, because its priority is elevated when inclusive authentication

This property is false by default which means that the authentication process is complete as soon as the first SecurityIdentity is created.

This property will be ignored if the path specific authentication is enabled.

Environment variable: QUARKUS_HTTP_AUTH_INCLUSIVE

boolean

false

quarkus.http.auth.inclusive-mode

Inclusive authentication mode.

Environment variable: QUARKUS_HTTP_AUTH_INCLUSIVE_MODE

lax: Authentication succeeds if at least one of the registered HTTP authentication mechanisms creates the identity.

strict: Authentication succeeds if all the registered HTTP authentication mechanisms create the identity. Typically, inclusive authentication should be in the strict mode when the credentials are carried over mTLS, when both mTLS and another authentication, for example, OIDC bearer token authentication, must succeed. In such cases, SecurityIdentity created by the first mechanism, mTLS, can be injected, identities created by other mechanisms will be available on SecurityIdentity.

strict

About the Duration format

To write duration values, use the standard java.time.Duration format. See the Duration#parse() Java API documentation for more information.

You can also use a simplified format, starting with a number:

  • If the value is only a number, it represents time in seconds.
  • If the value is a number followed by ms, it represents time in milliseconds.

In other cases, the simplified format is translated to the java.time.Duration format for parsing:

  • If the value is a number followed by h, m, or s, it is prefixed with PT.
  • If the value is a number followed by d, it is prefixed with P.
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동