OpenID Connect authorization code flow mechanism for protecting web applications
To protect your web applications, you can use the authorization code flow mechanism provided by the Quarkus OpenID Connect (OIDC) extension.
Overview of the OIDC authorization code flow mechanism
The Quarkus OpenID Connect (OIDC) extension can protect application HTTP endpoints by using the OIDC Authorization Code Flow mechanism supported by OIDC-compliant authorization servers, such as Keycloak.
The Authorization Code Flow mechanism authenticates users of your web application by redirecting them to an OIDC provider, such as Keycloak, to log in. After authentication, the OIDC provider redirects the user back to the application with an authorization code that confirms that authentication was successful. Then, the application exchanges this code with the OIDC provider for an ID token (which represents the authenticated user), an access token, and a refresh token to authorize the user’s access to the application.
The following diagram outlines the Authorization Code Flow mechanism in Quarkus.

-
The Quarkus user requests access to a Quarkus web-app application.
-
The Quarkus web-app redirects the user to the authorization endpoint, that is, the OIDC provider for authentication.
-
The OIDC provider redirects the user to a login and authentication prompt.
-
At the prompt, the user enters their user credentials.
-
The OIDC provider authenticates the user credentials entered and, if successful, issues an authorization code then redirects the user back to the Quarkus web-app with the code included as a query parameter.
-
The Quarkus web-app exchanges this authorization code with the OIDC provider for ID, access, and refresh tokens.
The authorization code flow is completed and the Quarkus web-app uses the tokens issued to access information about the user and grants the relevant role-based authorization to that user. The following tokens are issued:
-
ID token: The Quarkus web-app uses the user information in the ID token to enable the authenticated user to log in securely and to provide role-based access to the web-app.
-
Access token: The Quarkus web-app might use the access token to access the UserInfo API to get additional information about the authenticated user or propagate it to another endpoint.
-
Refresh token: (Optional) If the ID and access tokens expire, the Quarkus web-app can use the refresh token to get new ID and access tokens.
See also the OIDC configuration properties reference guide.
To learn about how you can protect web applications by using the OIDC authorization code flow mechanism, see Protect a web application by using OIDC authorization code flow
If you want to protect your applications by using Bearer Token authentication, see OIDC Bearer authentication. For information about how to support multiple tenants, see Using OpenID Connect Multi-Tenancy.
Using the authorization code flow mechanism
Accessing ID and access tokens
The OIDC code authentication mechanism acquires three tokens during the authorization code flow: IDToken, Access Token, and Refresh Token.
ID Token is always a JWT token and is used to represent a user authentication with the JWT claims.
One can access ID Token claims by injecting JsonWebToken
with an IdToken
qualifier:
import jakarta.inject.Inject;
import org.eclipse.microprofile.jwt.JsonWebToken;
import io.quarkus.oidc.IdToken;
import io.quarkus.security.Authenticated;
@Path("/web-app")
@Authenticated
public class ProtectedResource {
@Inject
@IdToken
JsonWebToken idToken;
@GET
public String getUserName() {
return idToken.getName();
}
}
Access Token is usually used by the OIDC web-app
application to access other endpoints on behalf of the currently logged-in user. The raw access token can be accessed as follows:
import jakarta.inject.Inject;
import org.eclipse.microprofile.jwt.JsonWebToken;
import io.quarkus.oidc.AccessTokenCredential;
import io.quarkus.security.Authenticated;
@Path("/web-app")
@Authenticated
public class ProtectedResource {
@Inject
JsonWebToken accessToken;
// or
// @Inject
// AccessTokenCredential accessTokenCredential;
@GET
public String getReservationOnBehalfOfUser() {
String rawAccessToken = accessToken.getRawToken();
//or
//String rawAccessToken = accessTokenCredential.getToken();
// Use the raw access token to access a remote endpoint
return getReservationfromRemoteEndpoint(rawAccesstoken);
}
}
Note that AccessTokenCredential
will have to be used if the Access Token issued to the Quarkus web-app
application is opaque (binary) and can not be parsed to JsonWebToken
.
Injection of the JsonWebToken
and AccessTokenCredential
is supported in both @RequestScoped
and @ApplicationScoped
contexts.
RefreshToken is only used to refresh the current ID and access tokens as part of its session management process.
User info
If the ID token does not provide enough information about the currently-authenticated user, then you can set a quarkus.oidc.authentication.user-info-required=true
property for a UserInfo JSON object from the OIDC userinfo endpoint to be requested.
A request will be sent to the OpenID Provider UserInfo endpoint using the access token returned with the authorization code grant response and an io.quarkus.oidc.UserInfo
(a simple jakarta.json.JsonObject
wrapper) object will be created. io.quarkus.oidc.UserInfo
can be either injected or accessed as a SecurityIdentity userinfo
attribute.
Configuration metadata
The current tenant’s discovered OpenID Connect Configuration Metadata is represented by io.quarkus.oidc.OidcConfigurationMetadata
and can be either injected or accessed as a SecurityIdentity
configuration-metadata
attribute.
The default tenant’s OidcConfigurationMetadata
is injected if the endpoint is public.
Token claims and SecurityIdentity roles
The way the roles are mapped to the SecurityIdentity roles from the verified tokens is identical to how it is done for the Bearer tokens with the only difference being that ID Token is used as a source of the roles by default.
Note if you use Keycloak then you should set a Microprofile JWT client scope for ID token to contain a groups
claim, please see the Keycloak Server Administration Guide for more information.
If only the access token contains the roles and this access token is not meant to be propagated to the downstream endpoints then set quarkus.oidc.roles.source=accesstoken
.
If UserInfo is the source of the roles then set quarkus.oidc.authentication.user-info-required=true
and quarkus.oidc.roles.source=userinfo
, and if needed, quarkus.oidc.roles.role-claim-path
.
Additionally, a custom SecurityIdentityAugmentor
can also be used to add the roles. For more information, see SecurityIdentity customization.
Token verification and introspection
Please see Token Verification And Introspection for details about how the tokens are verified and introspected.
Note that in case of web-app
applications only IdToken
is verified by default since the access token is not used by default to access the current Quarkus web-app
endpoint and instead meant to be propagated to the services expecting this access token, for example, to the OpenID Connect Provider’s UserInfo endpoint, and so on. However, if you expect the access token to contain the roles required to access the current Quarkus endpoint (quarkus.oidc.roles.source=accesstoken
) then it will also be verified.
Token introspection and UserInfo cache
Code flow access tokens are not introspected unless they are expected to be the source of roles but will be used to get UserInfo
. So there will be one or two remote calls with the code flow access token, if the token introspection and/or UserInfo
are required.
Please see Token Introspection and UserInfo cache for more information about using a default token cache or registering a custom cache implementation.
JSON web token claim verification
Please see JSON Web Token Claim verification section about the claim verification, including the iss
(issuer) claim.
It applies to ID tokens but also to access tokens in a JWT format if the web-app
application has requested the access token verification.
Redirection
When the user is redirected to the OpenID Connect Provider to authenticate, the redirect URL includes a redirect_uri
query parameter which indicates to the provider where the user has to be redirected to once the authentication has been completed.
Quarkus will set this parameter to the current request URL by default. For example, if the user is trying to access a Quarkus service endpoint at http://localhost:8080/service/1
then the redirect_uri
parameter will be set to http://localhost:8080/service/1
. Similarly, if the request URL is http://localhost:8080/service/2
then the redirect_uri
parameter will be set to http://localhost:8080/service/2
, etc.
OpenID Connect Providers may be configured to require the redirect_uri
parameter to have the same value (e.g. http://localhost:8080/service/callback
) for all the redirect URLs.
In such cases, a quarkus.oidc.authentication.redirect-path
property has to be set, for example, quarkus.oidc.authentication.redirect-path=/service/callback
, and Quarkus will set the redirect_uri
parameter to an absolute URL such as http://localhost:8080/service/callback
which will be the same regardless of the current request URL.
If quarkus.oidc.authentication.redirect-path
is set but the original request URL has to be restored after the user has been redirected back to a callback URL such as http://localhost:8080/service/callback
then a quarkus.oidc.authentication.restore-path-after-redirect
property has to be set to true
which will restore the request URL such as http://localhost:8080/service/1
, and so on.
Cookies
The OIDC adapter uses cookies to keep the session, code flow, and post-logout state.
quarkus.oidc.authentication.cookie-path
property is used to ensure the cookies are visible especially when you access the protected resources with overlapping or different roots, for example:
-
/index.html
and/web-app/service
-
/web-app/service1
and/web-app/service2
-
/web-app1/service
and/web-app2/service
quarkus.oidc.authentication.cookie-path
is set to /
by default but can be narrowed to the more specific root path such as /web-app
.
You can also set a quarkus.oidc.authentication.cookie-path-header
property if the cookie path needs to be set dynamically.
For example, setting quarkus.oidc.authentication.cookie-path-header=X-Forwarded-Prefix
means that the value of HTTP X-Forwarded-Prefix
header will be used to set a cookie path.
If quarkus.oidc.authentication.cookie-path-header
is set but no configured HTTP header is available in the current request then the quarkus.oidc.authentication.cookie-path
will be checked.
If your application is deployed across multiple domains, make sure to set a quarkus.oidc.authentication.cookie-domain
property for the session cookie be visible to all protected Quarkus services, for example, if you have 2 services deployed at:
then the quarkus.oidc.authentication.cookie-domain
property must be set to company.net
.
Logout
By default, the logout is based on the expiration time of the ID Token issued by the OpenID Connect Provider. When the ID Token expires, the current user session at the Quarkus endpoint is invalidated and the user is redirected to the OpenID Connect Provider again to authenticate. If the session at the OpenID Connect Provider is still active, users are automatically re-authenticated without having to provide their credentials again.
The current user session may be automatically extended by enabling a quarkus.oidc.token.refresh-expired
property. If it is set to true
then when the current ID Token expires a Refresh Token Grant will be used to refresh ID Token as well as Access and Refresh Tokens.
User-initiated logout
Users can request a logout by sending a request to the Quarkus endpoint logout path set with a quarkus.oidc.logout.path
property.
For example, if the endpoint address is https://application.com/webapp
and the quarkus.oidc.logout.path
is set to "/logout" then the logout request has to be sent to https://application.com/webapp/logout
.
This logout request will start an RP-Initiated Logout and the user will be redirected to the OpenID Connect Provider to logout where a user may be asked to confirm the logout is indeed intended.
The user will be returned to the endpoint post logout page once the logout has been completed if the quarkus.oidc.logout.post-logout-path
property is set. For example, if the endpoint address is https://application.com/webapp
and the quarkus.oidc.logout.post-logout-path
is set to "/signin" then the user will be returned to https://application.com/webapp/signin
(note this URI must be registered as a valid post_logout_redirect_uri
in the OpenID Connect Provider).
If the quarkus.oidc.logout.post-logout-path
is set then a q_post_logout
cookie will be created and a matching state
query parameter will be added to the logout redirect URI and the OpenID Connect Provider will return this state
once the logout has been completed. It is recommended for the Quarkus web-app
applications to check that a state
query parameter matches the value of the q_post_logout
cookie which can be done for example in a Jakarta REST filter.
Note that a cookie name will vary when using OpenID Connect Multi-Tenancy. For example, it will be named q_post_logout_tenant_1
for a tenant with a tenant_1
ID, and so on.
Here is an example of how to configure an RP initiated logout flow:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.credentials.secret=secret
quarkus.oidc.application-type=web-app
quarkus.oidc.logout.path=/logout
# Logged-out users should be returned to the /welcome.html site which will offer an option to re-login:
quarkus.oidc.logout.post-logout-path=/welcome.html
# Only the authenticated users can initiate a logout:
quarkus.http.auth.permission.authenticated.paths=/logout
quarkus.http.auth.permission.authenticated.policy=authenticated
# All users can see the welcome page:
quarkus.http.auth.permission.public.paths=/welcome.html
quarkus.http.auth.permission.public.policy=permit
You may also need to set quarkus.oidc.authentication.cookie-path
to a path value common to all the application resources which is /
in this example.
For more information, see the Cookies section.
Note that some OpenID Connect providers do not support RP-Initiated Logout specification (possibly because it is still technically a draft) and do not return an OpenID Connect well-known end_session_endpoint
metadata property. However, it should not be a problem since these providers' specific logout mechanisms may only differ in how the logout URL query parameters are named.
According to the RP-Initiated Logout specification, the quarkus.oidc.logout.post-logout-path
property is represented as a post_logout_redirect_uri
query parameter which will not be recognized by the providers which do not support this specification.
You can use quarkus.oidc.logout.post-logout-url-param
to work around this issue. You can also request more logout query parameters added with quarkus.oidc.logout.extra-params
. For example, here is how you can support a logout with Auth0
:
quarkus.oidc.auth-server-url=https://dev-xxx.us.auth0.com
quarkus.oidc.client-id=redacted
quarkus.oidc.credentials.secret=redacted
quarkus.oidc.application-type=web-app
quarkus.oidc.tenant-logout.logout.path=/logout
quarkus.oidc.tenant-logout.logout.post-logout-path=/welcome.html
# Auth0 does not return the `end_session_endpoint` metadata property, configure it instead
quarkus.oidc.end-session-path=v2/logout
# Auth0 will not recognize the 'post_logout_redirect_uri' query parameter so make sure it is named as 'returnTo'
quarkus.oidc.logout.post-logout-uri-param=returnTo
# Set more properties if needed.
# For example, if 'client_id' is provided then a valid logout URI should be set as Auth0 Application property, without it - as Auth0 Tenant property.
quarkus.oidc.logout.extra-params.client_id=${quarkus.oidc.client-id}
Back-channel logout
Back-Channel Logout is used by OpenID Connect providers to log out the current user from all the applications this user is currently logged in, bypassing the user agent.
You can configure Quarkus to support Back-Channel Logout
as follows:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.credentials.secret=secret
quarkus.oidc.application-type=web-app
quarkus.oidc.logout.backchannel.path=/back-channel-logout
Absolute Back-Channel Logout
URL is calculated by adding quarkus.oidc.back-channel-logout.path
to the current endpoint URL, for example, http://localhost:8080/back-channel-logout
. You will need to configure this URL in the Admin Console of your OpenID Connect Provider.
Note that you will also need to configure a token age property for the logout token verification to succeed if your OpenID Connect Provider does not set an expiry claim in the current logout token, for example, quarkus.oidc.token.age=10S
sets a number of seconds that must not elapse since the logout token’s iat
(issued at) time to 10.
Front-channel logout
Front-Channel Logout can be used to logout the current user directly from the user agent.
You can configure Quarkus to support Front-Channel Logout
as follows:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.credentials.secret=secret
quarkus.oidc.application-type=web-app
quarkus.oidc.logout.frontchannel.path=/front-channel-logout
This path will be compared against the current request’s path and the user will be logged out if these paths match.
Local logout
If you work with a social provider such as Google and are concerned that the users can be logged out from all their Google applications with the User-initiated logout which redirects the users to the provider’s logout endpoint then you can support a local logout with the help of the OidcSession which only clears the local session cookie, for example:
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import io.quarkus.oidc.OidcSession;
@Path("/service")
public class ServiceResource {
@Inject
OidcSession oidcSession;
@GET
@Path("logout")
public String logout() {
oidcSession.logout().await().indefinitely();
return "You are logged out".
}
Session management
If you have a Single Page Application for Service Applications where your OpenID Connect Provider script such as keycloak.js
is managing an authorization code flow then that script will also control the SPA authentication session lifespan.
If you work with a Quarkus OIDC web-app
application then it is Quarkus OIDC Code Authentication mechanism which is managing the user session lifespan.
The session age is calculated by adding the lifespan value of the current IDToken and the values of the quarkus.oidc.authentication.session-age-extension
and quarkus.oidc.token.lifespan-grace
properties. Of the last two properties only quarkus.oidc.authentication.session-age-extension
should be used to significantly extend the session lifespan if required since quarkus.oidc.token.lifespan-grace
is only meant for taking some small clock skews into consideration.
When the currently authenticated user returns to the protected Quarkus endpoint and the ID token associated with the session cookie has expired then, by default, the user will be auto-redirected to the OIDC Authorization endpoint to re-authenticate. Most likely the OIDC provider will challenge the user again though not necessarily if the session between the user and this OIDC provider is still active which may happen if it is configured to last longer than the ID token.
If the quarkus.oidc.token.refresh-expired
then the expired ID token (as well as the access token) will be refreshed using the refresh token returned with the authorization code grant response. This refresh token may also be recycled (refreshed) itself as part of this process. As a result the new session cookie will be created and the session will be extended.
Note, quarkus.oidc.authentication.session-age-extension
can be important when dealing with expired ID tokens, when the user is not very active. In such cases, if the ID token expires, then the session cookie may not be returned to the Quarkus endpoint during the next user request and Quarkus will assume it is the first authentication request. Therefore, using quarkus.oidc.authentication.session-age-extension
is important if you need to have even the expired ID tokens refreshed.
You can also complement refreshing the expired ID tokens by proactively refreshing the valid ID tokens which are about to be expired within the quarkus.oidc.token.refresh-token-time-skew
value. If, during the current user request, it is calculated that the current ID token will expire within this quarkus.oidc.token.refresh-token-time-skew
then it will be refreshed and the new session cookie will be created. This property should be set to a value which is less than the ID token lifespan; the closer it is to this lifespan value the more often the ID token will be refreshed.
You can have this process further optimized by having a simple JavaScript function periodically emulating the user activity by pinging your Quarkus endpoint thus minimizing the window during which the user may have to be re-authenticated.
Note this user session can not be extended forever - the returning user with the expired ID token will have to re-authenticate at the OIDC provider endpoint once the refresh token has expired.
OidcSession
io.quarkus.oidc.OidcSession
is a wrapper around the current IdToken
. It can help to perform a Local logout, retrieve the current session’s tenant identifier and check when the session will expire. More useful methods will be added to it over time.
TokenStateManager
OIDC CodeAuthenticationMechanism
is using the default io.quarkus.oidc.TokenStateManager
interface implementation to keep the ID, access and refresh tokens returned in the authorization code or refresh grant responses in a session cookie. It makes Quarkus OIDC endpoints completely stateless.
Note that some endpoints do not require the access token. An access token is only required if the endpoint needs to retrieve UserInfo
or access the downstream service with this access token or use the roles associated with the access token (the roles in the ID token are checked by default). In such cases you can set either quarkus.oidc.token-state-manager.strategy=id-refresh-token
(keep ID and refresh tokens only) or quarkus.oidc.token-state-manager.strategy=id-token
(keep ID token only).
If the ID, access and refresh tokens are JWT tokens then combining all of them (if the strategy is the default keep-all-tokens
) or only ID and refresh tokens (if the strategy is id-refresh-token
) may produce a session cookie value larger than 4KB and the browsers may not be able to keep this cookie.
In such cases, you can use quarkus.oidc.token-state-manager.split-tokens=true
to have a unique session token per each of these tokens.
Note that TokenStateManager
will encrypt the tokens before storing them in the session cookie.
For example, here is how you configure it to split the tokens and encrypt them:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.secret=secret
quarkus.oidc.application-type=web-app
quarkus.oidc.token-state-manager.split-tokens=true
quarkus.oidc.token-state-manager.encryption-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU
The token encryption secret must be at least 32 characters long. If this key is not configured then either quarkus.oidc.credentials.secret
or quarkus.oidc.credentials.jwt.secret
will be hashed to create an encryption key.
quarkus.oidc.token-state-manager.encryption-secret
should be configured if Quarkus authenticates to OpenId Connect Provider using either mTLS or private_key_jwt
(where a private RSA or EC key is used to sign a JWT token) authentication methods, otherwise a random key will be generated which will be problematic if the Quarkus application is running in the cloud with multiple pods managing the requests.
If you need you can disable encrypting the tokens in the session cookie with quarkus.oidc.token-state-manager.encryption-required=false
.
Register your own io.quarkus.oidc.TokenStateManager' implementation as an `@ApplicationScoped
CDI bean if you need to customize the way the tokens are associated with the session cookie. For example, you may want to keep the tokens in a database and have only a database pointer stored in a session cookie. Note though that it may present some challenges in making the tokens available across multiple microservices nodes.
Here is a simple example:
package io.quarkus.oidc.test;
import jakarta.annotation.Priority;
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.inject.Alternative;
import jakarta.inject.Inject;
import io.quarkus.oidc.AuthorizationCodeTokens;
import io.quarkus.oidc.OidcTenantConfig;
import io.quarkus.oidc.TokenStateManager;
import io.quarkus.oidc.runtime.DefaultTokenStateManager;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;
@ApplicationScoped
@Alternative
@Priority(1)
public class CustomTokenStateManager implements TokenStateManager {
@Inject
DefaultTokenStateManager tokenStateManager;
@Override
public Uni<String> createTokenState(RoutingContext routingContext, OidcTenantConfig oidcConfig,
AuthorizationCodeTokens sessionContent, TokenStateManager.CreateTokenStateRequestContext requestContext) {
return tokenStateManager.createTokenState(routingContext, oidcConfig, sessionContent, requestContext)
.map(t -> (t + "|custom"));
}
@Override
public Uni<AuthorizationCodeTokens> getTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig,
String tokenState, TokenStateManager.GetTokensRequestContext requestContext) {
if (!tokenState.endsWith("|custom")) {
throw new IllegalStateException();
}
String defaultState = tokenState.substring(0, tokenState.length() - 7);
return tokenStateManager.getTokens(routingContext, oidcConfig, defaultState, requestContext);
}
@Override
public Uni<Void> deleteTokens(RoutingContext routingContext, OidcTenantConfig oidcConfig, String tokenState,
TokenStateManager.DeleteTokensRequestContext requestContext) {
if (!tokenState.endsWith("|custom")) {
throw new IllegalStateException();
}
String defaultState = tokenState.substring(0, tokenState.length() - 7);
return tokenStateManager.deleteTokens(routingContext, oidcConfig, defaultState, requestContext);
}
}
Proof key for code exchange (PKCE)
Proof Key for Code Exchange (PKCE) minimizes the risk of the authorization code interception.
While PKCE
is of primary importance to the public OpenID Connect clients (such as the SPA scripts running in a browser), it can also provide an extra level of protection to Quarkus OIDC web-app
applications which are confidential OpenID Connect clients capable of securely storing the client secret and using it to exchange the code for the tokens.
You can enable PKCE
for your OIDC web-app
endpoint with a quarkus.oidc.authentication.pkce-required
property and a 32 characters long secret, for example:
quarkus.oidc.authentication.pkce-required=true
quarkus.oidc.authentication.pkce-secret=eUk1p7UB3nFiXZGUXi0uph1Y9p34YhBU
If you already have a 32 characters long client secret then quarkus.oidc.authentication.pkce-secret
does not have to be set unless you prefer to use a different secret key.
The secret key is required for encrypting a randomly generated PKCE
code_verifier
while the user is being redirected with the code_challenge
query parameter to OpenID Connect Provider to authenticate. The code_verifier
will be decrypted when the user is redirected back to Quarkus and sent to the token endpoint alongside the code
, client secret and other parameters to complete the code exchange. The provider will fail the code exchange if a SHA256
digest of the code_verifier
does not match the code_challenge
provided during the authentication request.
Listening to important authentication events
One can register @ApplicationScoped
bean which will observe important OIDC authentication events. The listener will be updated when a user has logged in for the first time or re-authenticated, as well as when the session has been refreshed. More events may be reported in the future. For example:
import jakarta.enterprise.context.ApplicationScoped;
import jakarta.enterprise.event.Observes;
import io.quarkus.oidc.IdTokenCredential;
import io.quarkus.oidc.SecurityEvent;
import io.quarkus.security.identity.AuthenticationRequestContext;
import io.vertx.ext.web.RoutingContext;
@ApplicationScoped
public class SecurityEventListener {
public void event(@Observes SecurityEvent event) {
String tenantId = event.getSecurityIdentity().getAttribute("tenant-id");
RoutingContext vertxContext = event.getSecurityIdentity().getAttribute(RoutingContext.class.getName());
vertxContext.put("listener-message", String.format("event:%s,tenantId:%s", event.getEventType().name(), tenantId));
}
}
Single-page applications
Check if implementing SPAs the way it is suggested in the Single-page Applications for Service Applications section can meet your requirements.
If you prefer to use SPA and JavaScript API such as Fetch
or XMLHttpRequest
(XHR) with Quarkus web applications, be aware that OpenID Connect Providers may not support CORS for Authorization endpoints where the users are authenticated after a redirect from Quarkus. This will lead to authentication failures if the Quarkus application and the OpenID Connect Provider are hosted on the different HTTP domains/ports.
In such cases, set the quarkus.oidc.authentication.java-script-auto-redirect
property to false
which will instruct Quarkus to return a 499
status code and WWW-Authenticate
header with the OIDC
value. The browser script also needs to be updated to set X-Requested-With
header with the JavaScript
value and reload the last requested page in case of 499
, for example:
Future<void> callQuarkusService() async {
Map<String, String> headers = Map.fromEntries([MapEntry("X-Requested-With", "JavaScript")]);
await http
.get("https://localhost:443/serviceCall")
.then((response) {
if (response.statusCode == 499) {
window.location.assign("https://localhost.com:443/serviceCall");
}
});
}
Cross-origin resource sharing
If you plan to consume this application from a Single-page application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). For more information, see the HTTP CORS documentation.
Integration with GitHub and other OAuth2 providers
Some well known providers such as GitHub or LinkedIn are not OpenID Connect but OAuth2 providers which support the authorization code flow
, for example, GitHub OAuth2 and LinkedIn OAuth2.
The main difference between OpenID Connect and OAuth2 providers is that OpenID Connect providers, by building on top of OAuth2, return an ID Token
representing a user authentication, in addition to the standard authorization code flow access
and refresh
tokens returned by OAuth2
providers.
OAuth2 providers such as GitHub do not return IdToken
, the fact of the user authentication is implicit and is indirectly represented by the access
token which represents an authenticated user authorizing the current Quarkus web-app
application to access some data on behalf of the authenticated user.
For example, when working with GitHub, the Quarkus endpoint can acquire an access
token which will allow it to request a GitHub profile of the current user.
In fact this is exactly how a standard OpenID Connect UserInfo
acquisition also works - by authenticating into your OpenID Connect provider you also give a permission to Quarkus application to acquire your UserInfo on your behalf - and it also shows what is meant by OpenID Connect being built on top of OAuth2.
To support the integration with such OAuth2 servers, quarkus-oidc
needs to be configured to allow the authorization code flow responses without IdToken
: quarkus.oidc.authentication.id-token-required=false
.
It is required because quarkus-oidc
expects that not only access
and refresh
tokens but also IdToken
will be returned once the authorization code flow completes.
Note, even though you will configure the extension to support the authorization code flows without IdToken
, an internal IdToken
will be generated to support the way quarkus-oidc
operates where an IdToken
is used to support the authentication session and to avoid redirecting the user to the provider such as GitHub on every request. In this case the session lifespan is set to 5 minutes which can be extended further as described in the session management section.
The next step is to ensure that the returned access token can be useful to the current Quarkus endpoint.
If the OAuth2 provider supports the introspection endpoint then you may be able to use this access token as a source of roles with quarkus.oidc.roles.source=accesstoken
. If no introspection endpoint is available then at the very least it should be possible to request UserInfo from this provider with quarkus.oidc.authentication.user-info-required
- this is the case with GitHub.
Configuring the endpoint to request UserInfo is the only way quarkus-oidc
can be integrated with the providers such as GitHub.
Note that requiring UserInfo involves making a remote call on every request - therefore you may want to consider caching UserInfo
data, see Token Introspection and UserInfo cache for more details.
Alternatively, you may want to request that UserInfo
is embedded into the internal generated IdToken
with the quarkus.oidc.cache-user-info-in-idtoken=true
property - the advantage of this approach is that by default no cached UserInfo
state will be kept with the endpoint - instead it will be stored in a session cookie. You may also want to consider encrypting IdToken
in this case if UserInfo
contains sensitive data. For more information, see Encrypt tokens with TokenStateManager.
Also, OAuth2 servers may not support a well-known configuration endpoint in which case the discovery has to be disabled and the authorization, token, and introspection and/or userinfo endpoint paths have to be configured manually.
Here is how you can integrate quarkus-oidc
with GitHub after you have created a GitHub OAuth application. Configure your Quarkus endpoint like this:
quarkus.oidc.provider=github
quarkus.oidc.client-id=github_app_clientid
quarkus.oidc.credentials.secret=github_app_clientsecret
# user:email scope is requested by default, use 'quarkus.oidc.authentication.scopes' to request different scopes such as `read:user`.
# See https://docs.github.com/en/developers/apps/building-oauth-apps/scopes-for-oauth-apps for more information.
# Consider enabling UserInfo Cache
# quarkus.oidc.token-cache.max-size=1000
# quarkus.oidc.token-cache.time-to-live=5M
#
# Or having UserInfo cached inside IdToken itself
# quarkus.oidc.cache-user-info-in-idtoken=true
See OpenID Connect providers for more details about configuring other well-known providers.
This is all what is needed for an endpoint like this one to return the currently-authenticated user’s profile with GET http://localhost:8080/github/userinfo
and access it as the individual UserInfo
properties:
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import io.quarkus.oidc.UserInfo;
import io.quarkus.security.Authenticated;
@Path("/github")
@Authenticated
public class TokenResource {
@Inject
UserInfo userInfo;
@GET
@Path("/userinfo")
@Produces("application/json")
public String getUserInfo() {
return userInfo.getUserInfoString();
}
}
If you support more than one social provider with the help of OpenID Connect Multi-Tenancy, for example, Google which is an OpenID Connect Provider returning IdToken
and GitHub which is an OAuth2 provider returning no IdToken
and only allowing to access UserInfo
then you can have your endpoint working with only the injected SecurityIdentity
for both Google and GitHub flows. A simple augmentation of SecurityIdentity
will be required where a principal created with the internally generated IdToken
will be replaced with the UserInfo
based principal when the GiHub flow is active:
package io.quarkus.it.keycloak;
import java.security.Principal;
import jakarta.enterprise.context.ApplicationScoped;
import io.quarkus.oidc.UserInfo;
import io.quarkus.security.identity.AuthenticationRequestContext;
import io.quarkus.security.identity.SecurityIdentity;
import io.quarkus.security.identity.SecurityIdentityAugmentor;
import io.quarkus.security.runtime.QuarkusSecurityIdentity;
import io.smallrye.mutiny.Uni;
import io.vertx.ext.web.RoutingContext;
@ApplicationScoped
public class CustomSecurityIdentityAugmentor implements SecurityIdentityAugmentor {
@Override
public Uni<SecurityIdentity> augment(SecurityIdentity identity, AuthenticationRequestContext context) {
RoutingContext routingContext = identity.getAttribute(RoutingContext.class.getName());
if (routingContext != null && routingContext.normalizedPath().endsWith("/github")) {
QuarkusSecurityIdentity.Builder builder = QuarkusSecurityIdentity.builder(identity);
UserInfo userInfo = identity.getAttribute("userinfo");
builder.setPrincipal(new Principal() {
@Override
public String getName() {
return userInfo.getString("preferred_username");
}
});
identity = builder.build();
}
return Uni.createFrom().item(identity);
}
}
Now, the following code will work when the user is signing in into your application with both Google or GitHub:
import jakarta.inject.Inject;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import io.quarkus.security.Authenticated;
import io.quarkus.security.identity.SecurityIdentity;
@Path("/service")
@Authenticated
public class TokenResource {
@Inject
SecurityIdentity identity;
@GET
@Path("/google")
@Produces("application/json")
public String getUserName() {
return identity.getPrincipal().getName();
}
@GET
@Path("/github")
@Produces("application/json")
public String getUserName() {
return identity.getPrincipal().getUserName();
}
}
Possibly a simpler alternative is to inject both @IdToken JsonWebToken
and UserInfo
and use JsonWebToken
when dealing with the providers returning IdToken
and UserInfo
- with the providers which do not return IdToken
.
The last important point is to make sure the callback path you enter in the GitHub OAuth application configuration matches the endpoint path where you’d like the user be redirected to after a successful GitHub authentication and application authorization, in this case it has to be set to http:localhost:8080/github/userinfo
.
Cloud services
Google Cloud
You can have Quarkus OIDC web-app
applications access Google Cloud services such as BigQuery on behalf of the currently authenticated users who have enabled OpenID Connect (Authorization Code Flow) permissions to such services in their Google Developer Consoles.
It is super easy to do with Quarkiverse Google Cloud Services, only add the latest tag service dependency, for example:
<dependency>
<groupId>io.quarkiverse.googlecloudservices</groupId>
<artifactId>quarkus-google-cloud-bigquery</artifactId>
<version>${quarkiverse.googlecloudservices.version}</version>
</dependency>
implementation("io.quarkiverse.googlecloudservices:quarkus-google-cloud-bigquery:${quarkiverse.googlecloudservices.version}")
and configure Google OIDC properties:
quarkus.oidc.provider=google
quarkus.oidc.client-id={GOOGLE_CLIENT_ID}
quarkus.oidc.credentials.secret={GOOGLE_CLIENT_SECRET}
quarkus.oidc.token.issuer=https://accounts.google.com
Provider endpoint configuration
OIDC web-app
application needs to know OpenID Connect provider’s authorization, token, JsonWebKey
(JWK) set and possibly UserInfo
, introspection and end session (RP-initiated logout) endpoint addresses.
By default, they are discovered by adding a /.well-known/openid-configuration
path to the configured quarkus.oidc.auth-server-url
.
Alternatively, if the discovery endpoint is not available, or if you would like to save on the discovery endpoint round-trip, you can disable the discovery and configure them with relative path values, for example:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.oidc.discovery-enabled=false
# Authorization endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/auth
quarkus.oidc.authorization-path=/protocol/openid-connect/auth
# Token endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token
quarkus.oidc.token-path=/protocol/openid-connect/token
# JWK set endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/certs
quarkus.oidc.jwks-path=/protocol/openid-connect/certs
# UserInfo endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/userinfo
quarkus.oidc.user-info-path=/protocol/openid-connect/userinfo
# Token Introspection endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/token/introspect
quarkus.oidc.introspection-path=/protocol/openid-connect/token/introspect
# End session endpoint: http://localhost:8180/realms/quarkus/protocol/openid-connect/logout
quarkus.oidc.end-session-path=/protocol/openid-connect/logout
Sometimes, your OpenId Connect provider supports a metadata discovery but does not return all the endpoint URLs required for the authorization code flow to complete or for the application to support the additional functions such as a user logout. In such cases, you can simply configure a missing endpoint URL locally:
# Metadata is auto-discovered but it does not return an end-session endpoint URL
quarkus.oidc.auth-server-url=http://localhost:8180/oidcprovider/account
# Configure the end-session URL locally, it can be an absolute or relative (to 'quarkus.oidc.auth-server-url') address
quarkus.oidc.end-session-path=logout
Exactly the same configuration can be used to override a discovered endpoint URL if that URL does not work for the local Quarkus endpoint and a more specific value is required. For example, one can imagine that in the above example, a provider which supports both global and application specific end-session endpoints returns a global end-session URL such as http://localhost:8180/oidcprovider/account/global-logout
which will logout the user from all the applications this user is currently logged in, while the current application only wants to get this user logged out from this application, therefore, quarkus.oidc.end-session-path=logout
is used to override the global end-session URL.
Token propagation
For information about Authorization Code Flow access token propagation to the downstream services, see the Token Propagation section.
OIDC provider client authentication
quarkus.oidc.runtime.OidcProviderClient
is used when a remote request to an OpenID Connect Provider has to be done. It has to authenticate to the OpenID Connect Provider when the authorization code has to be exchanged for the ID, access and refresh tokens, when the ID and access tokens have to be refreshed or introspected.
All the OIDC Client Authentication options are supported, for example:
client_secret_basic
:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.secret=mysecret
or
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.client-secret.value=mysecret
or with the secret retrieved from a CredentialsProvider:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider
quarkus.oidc.credentials.client-secret.provider.key=mysecret-key
# Set it only if more than one CredentialsProvider can be registered
quarkus.oidc.credentials.client-secret.provider.name=oidc-credentials-provider
client_secret_post
:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.client-secret.value=mysecret
quarkus.oidc.credentials.client-secret.method=post
client_secret_jwt
, signature algorithm is HS256:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.jwt.secret=AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow
or with the secret retrieved from a CredentialsProvider:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
# This is a key which will be used to retrieve a secret from the map of credentials returned from CredentialsProvider
quarkus.oidc.credentials.jwt.secret-provider.key=mysecret-key
# Set it only if more than one CredentialsProvider can be registered
quarkus.oidc.credentials.jwt.secret-provider.name=oidc-credentials-provider
private_key_jwt
with the PEM key file, signature algorithm is RS256:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.jwt.key-file=privateKey.pem
private_key_jwt
with the key store file, signature algorithm is RS256:
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.jwt.key-store-file=keystore.jks
quarkus.oidc.credentials.jwt.key-store-password=mypassword
quarkus.oidc.credentials.jwt.key-password=mykeypassword
# Private key alias inside the keystore
quarkus.oidc.credentials.jwt.key-id=mykeyAlias
Using client_secret_jwt
or private_key_jwt
authentication methods ensures that no client secret goes over the wire.
Additional JWT authentication options
If client_secret_jwt
, private_key_jwt
authentication methods are used or an Apple post_jwt
method is used, then the JWT signature algorithm, key identifier, audience, subject and issuer can be customized, for example:
# private_key_jwt client authentication
quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.jwt.key-file=privateKey.pem
# This is a token key identifier 'kid' header - set it if your OpenID Connect provider requires it.
# Note if the key is represented in a JSON Web Key (JWK) format with a `kid` property then
# using 'quarkus.oidc.credentials.jwt.token-key-id' is not necessary.
quarkus.oidc.credentials.jwt.token-key-id=mykey
# Use RS512 signature algorithm instead of the default RS256
quarkus.oidc.credentials.jwt.signature-algorithm=RS512
# The token endpoint URL is the default audience value, use the base address URL instead:
quarkus.oidc.credentials.jwt.audience=${quarkus.oidc-client.auth-server-url}
# custom subject instead of the client id :
quarkus.oidc.credentials.jwt.subject=custom-subject
# custom issuer instead of the client id :
quarkus.oidc.credentials.jwt.issuer=custom-issuer
Apple POST JWT
Apple OpenID Connect Provider uses a client_secret_post
method where a secret is a JWT produced with a private_key_jwt
authentication method but with Apple account specific issuer and subject claims.
quarkus-oidc
supports a non-standard client_secret_post_jwt
authentication method which can be configured as follows:
# Apple provider configuration sets a 'client_secret_post_jwt' authentication method
quarkus.oidc.provider=apple
quarkus.oidc.client-id=${apple.client-id}
quarkus.oidc.credentials.jwt.key-file=ecPrivateKey.pem
quarkus.oidc.credentials.jwt.token-key-id=${apple.key-id}
# Apple provider configuration sets ES256 signature algorithm
quarkus.oidc.credentials.jwt.subject=${apple.subject}
quarkus.oidc.credentials.jwt.issuer=${apple.issuer}
Mutual TLS (mTLS)
Some OpenID Connect providers may require that a client is authenticated as part of the Mutual TLS
authentication process.
quarkus-oidc
can be configured as follows to support mTLS
:
quarkus.oidc.tls.verification=certificate-validation
# Keystore configuration
quarkus.oidc.tls.key-store-file=client-keystore.jks
quarkus.oidc.tls.key-store-password=${key-store-password}
# Add more keystore properties if needed:
#quarkus.oidc.tls.key-store-alias=keyAlias
#quarkus.oidc.tls.key-store-alias-password=keyAliasPassword
# Truststore configuration
quarkus.oidc.tls.trust-store-file=client-truststore.jks
quarkus.oidc.tls.trust-store-password=${trust-store-password}
# Add more truststore properties if needed:
#quarkus.oidc.tls.trust-store-alias=certAlias
Introspection endpoint authentication
Some OpenID Connect Providers may require authenticating to its introspection endpoint using Basic authentication with the credentials different to client_id
and client_secret
which may have already been configured to support client_secret_basic
or client_secret_post
client authentication methods described in the OIDC provider client authentication section.
If the tokens have to be introspected and the introspection endpoint specific authentication mechanism is required, then you can configure quarkus-oidc
like this:
quarkus.oidc.introspection-credentials.name=introspection-user-name
quarkus.oidc.introspection-credentials.secret=introspection-user-secret
Testing
Start by adding the following dependencies to your test project:
<dependency>
<groupId>net.sourceforge.htmlunit</groupId>
<artifactId>htmlunit</artifactId>
<exclusions>
<exclusion>
<groupId>org.eclipse.jetty</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
<scope>test</scope>
</dependency>
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-junit5</artifactId>
<scope>test</scope>
</dependency>
testImplementation("net.sourceforge.htmlunit:htmlunit")
testImplementation("io.quarkus:quarkus-junit5")
Wiremock
Add the following dependency:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-test-oidc-server</artifactId>
<scope>test</scope>
</dependency>
testImplementation("io.quarkus:quarkus-test-oidc-server")
Prepare the REST test endpoints, set application.properties
, for example:
# keycloak.url is set by OidcWiremockTestResource
quarkus.oidc.auth-server-url=${keycloak.url}/realms/quarkus/
quarkus.oidc.client-id=quarkus-web-app
quarkus.oidc.credentials.secret=secret
quarkus.oidc.application-type=web-app
and finally write the test code, for example:
import static org.junit.jupiter.api.Assertions.assertEquals;
import org.junit.jupiter.api.Test;
import com.gargoylesoftware.htmlunit.SilentCssErrorHandler;
import com.gargoylesoftware.htmlunit.WebClient;
import com.gargoylesoftware.htmlunit.html.HtmlForm;
import com.gargoylesoftware.htmlunit.html.HtmlPage;
import io.quarkus.test.common.QuarkusTestResource;
import io.quarkus.test.junit.QuarkusTest;
import io.quarkus.test.oidc.server.OidcWiremockTestResource;
@QuarkusTest
@QuarkusTestResource(OidcWiremockTestResource.class)
public class CodeFlowAuthorizationTest {
@Test
public void testCodeFlow() throws Exception {
try (final WebClient webClient = createWebClient()) {
// the test REST endpoint listens on '/code-flow'
HtmlPage page = webClient.getPage("http://localhost:8081/code-flow");
HtmlForm form = page.getFormByName("form");
// user 'alice' has the 'user' role
form.getInputByName("username").type("alice");
form.getInputByName("password").type("alice");
page = form.getInputByValue("login").click();
assertEquals("alice", page.getBody().asText());
}
}
private WebClient createWebClient() {
WebClient webClient = new WebClient();
webClient.setCssErrorHandler(new SilentCssErrorHandler());
return webClient;
}
}
OidcWiremockTestResource
recognizes alice
and admin
users. The user alice
has the user
role only by default - it can be customized with a quarkus.test.oidc.token.user-roles
system property. The user admin
has the user
and admin
roles by default - it can be customized with a quarkus.test.oidc.token.admin-roles
system property.
Additionally, OidcWiremockTestResource
set token issuer and audience to https://service.example.com
which can be customized with quarkus.test.oidc.token.issuer
and quarkus.test.oidc.token.audience
system properties.
OidcWiremockTestResource
can be used to emulate all OpenID Connect providers.
Dev services for Keycloak
Using Dev Services for Keycloak is recommended for the integration testing against Keycloak.
Dev Services for Keycloak
will launch and initialize a test container: it will create a quarkus
realm, a quarkus-app
client (secret
secret) and add alice
(admin
and user
roles) and bob
(user
role) users, where all of these properties can be customized.
First, prepare application.properties
. You can start with a completely empty application.properties
as Dev Services for Keycloak
will register quarkus.oidc.auth-server-url
pointing to the running test container as well as quarkus.oidc.client-id=quarkus-app
and quarkus.oidc.credentials.secret=secret
.
But if you already have all the required quarkus-oidc
properties configured then you only need to associate quarkus.oidc.auth-server-url
with the prod
profile for `Dev Services for Keycloak`to start a container, for example:
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
If a custom realm file has to be imported into Keycloak before running the tests then you can configure Dev Services for Keycloak
as follows:
%prod.quarkus.oidc.auth-server-url=http://localhost:8180/realms/quarkus
quarkus.keycloak.devservices.realm-path=quarkus-realm.json
Finally, write a test code the same way as it is described in the Wiremock section.
The only difference is that @QuarkusTestResource
is no longer needed:
@QuarkusTest
public class CodeFlowAuthorizationTest {
}
Using KeycloakTestResourceLifecycleManager
Use KeycloakTestResourceLifecycleManager
for your tests only if there is a good reason not to use Dev Services for Keycloak
.
If you need to do the integration testing against Keycloak then you are encouraged to do it with Dev services For Keycloak.
Start with adding the following dependency:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-test-keycloak-server</artifactId>
<scope>test</scope>
</dependency>
testImplementation("io.quarkus:quarkus-test-keycloak-server")
which provides io.quarkus.test.keycloak.server.KeycloakTestResourceLifecycleManager
- an implementation of io.quarkus.test.common.QuarkusTestResourceLifecycleManager
which starts a Keycloak container.
And configure the Maven Surefire plugin as follows:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<!-- or, alternatively, configure 'keycloak.version' -->
<keycloak.docker.image>${keycloak.docker.image}</keycloak.docker.image>
<!--
Disable HTTPS if required:
<keycloak.use.https>false</keycloak.use.https>
-->
</systemPropertyVariables>
</configuration>
</plugin>
(and similarly the Maven Failsafe plugin when testing in native image).
And now set the configuration and write the test code the same way as it is described in the Wiremock section.
The only difference is the name of QuarkusTestResource
:
import io.quarkus.test.keycloak.server.KeycloakTestResourceLifecycleManager;
@QuarkusTest
@QuarkusTestResource(KeycloakTestResourceLifecycleManager.class)
public class CodeFlowAuthorizationTest {
}
KeycloakTestResourceLifecycleManager
registers alice
and admin
users. The user alice
has the user
role only by default - it can be customized with a keycloak.token.user-roles
system property. The user admin
has the user
and admin
roles by default - it can be customized with a keycloak.token.admin-roles
system property.
By default, KeycloakTestResourceLifecycleManager
uses HTTPS to initialize a Keycloak instance which can be disabled with keycloak.use.https=false
.
Default realm name is quarkus
and client id - quarkus-web-app
- set keycloak.realm
and keycloak.web-app.client
system properties to customize the values if needed.
TestSecurity annotation
See Use TestingSecurity with injected JsonWebToken section for more information about using @TestSecurity
and @OidcSecurity
annotations for testing the web-app
application endpoint code which depends on the injected ID and access JsonWebToken
as well as UserInfo
and OidcConfigurationMetadata
.
Checking errors in the logs
To see details about the token verification errors, you must enable io.quarkus.oidc.runtime.OidcProvider
TRACE
level logging:
quarkus.log.category."io.quarkus.oidc.runtime.OidcProvider".level=TRACE
quarkus.log.category."io.quarkus.oidc.runtime.OidcProvider".min-level=TRACE
To see details about the OidcProvider client initialization errors, enable io.quarkus.oidc.runtime.OidcRecorder
TRACE
level logging:
quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".level=TRACE
quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".min-level=TRACE
Running Quarkus application behind a reverse proxy
OIDC authentication mechanism can be affected if your Quarkus application is running behind a reverse proxy/gateway/firewall when HTTP Host
header may be reset to the internal IP address, HTTPS connection may be terminated, etc. For example, an authorization code flow redirect_uri
parameter may be set to the internal host instead of the expected external one.
In such cases configuring Quarkus to recognize the original headers forwarded by the proxy will be required, for more information, see the Running behind a reverse proxy Vert.x documentation section.
For example, if your Quarkus endpoint runs in a cluster behind Kubernetes Ingress then a redirect from the OpenID Connect Provider back to this endpoint may not work since the calculated redirect_uri
parameter may point to the internal endpoint address. This problem can be resolved with the following configuration:
quarkus.http.proxy.proxy-address-forwarding=true
quarkus.http.proxy.allow-forwarded=false
quarkus.http.proxy.enable-forwarded-host=true
quarkus.http.proxy.forwarded-host-header=X-ORIGINAL-HOST
where X-ORIGINAL-HOST
is set by Kubernetes Ingress to represent the external endpoint address.
quarkus.oidc.authentication.force-redirect-https-scheme
property may also be used when the Quarkus application is running behind an SSL terminating reverse proxy.
External and internal access to the OIDC provider
Note that the OpenID Connect Provider externally accessible authorization, logout and other endpoints may have different HTTP(S) URLs compared to the URLs auto-discovered or configured relative to quarkus.oidc.auth-server-url
internal URL.
In such cases an issuer verification failure may be reported by the endpoint and redirects to the externally accessible Connect Provider endpoints may fail.
In such cases, if you work with Keycloak then please start it with a KEYCLOAK_FRONTEND_URL
system property set to the externally accessible base URL.
If you work with other Openid Connect providers then please check your provider’s documentation.
Customizing authentication requests
By default, only the response_type
(set to code
), scope
(set to 'openid'), client_id
, redirect_uri
and state
properties are passed as HTTP query parameters to the OpenID Connect provider’s authorization endpoint when the user is redirected to it to authenticate.
You can add more properties to it with quarkus.oidc.authentication.extra-params
. For example, some OpenID Connect providers may choose to return the authorization code as part of the redirect URI’s fragment which would break the authentication process - it can be fixed as follows:
quarkus.oidc.authentication.extra-params.response_mode=query
Customizing the authentication error response
If the user authentication has failed at the OpenID Connect Authorization endpoint, for example, due to an invalid scope or other invalid parameters included in the redirect to the provider, then the provider will redirect the user back to Quarkus not with the code
but error
and error_description
parameters.
In such cases HTTP 401
will be returned by default. However, you can instead request that a custom public error endpoint is called in order to return a user-friendly HTML error page. Use quarkus.oidc.authentication.error-path
, for example:
quarkus.oidc.authentication.error-path=/error
It has to start from a forward slash and be relative to the base URI of the current endpoint.
For example, if it is set as '/error' and the current request URI is https://localhost:8080/callback?error=invalid_scope
then a final redirect will be made to https://localhost:8080/error?error=invalid_scope
.
It is important that this error endpoint is a public resource to avoid the user redirected to this page be authenticated again.