This guide demonstrates how to use Quarkus OpenID Connect (OIDC) Extension to protect your Quarkus HTTP endpoints using OpenId Connect Authorization Code Flow supported by OpenId Connect compliant Authorization Servers such as Keycloak.
The extension allows to easily authenticate the users of your web application by redirecting them to the OpenID Connect Provider (e.g.: Keycloak) to login and, once the authentication is complete, return them back with the code confirming the successful authentication. The extension will request ID and access tokens from the OpenID Connect Provider using an authorization code grant and verify these tokens in order to authorize an access to the application.
Please read the Using OpenID Connect to Protect Service Applications guide if you need to protect your applications using Bearer Token Authorization.
Please read the Using OpenID Connect Multi-Tenancy guide how to support multiple tenants.
Prerequisites
To complete this guide, you need:
-
less than 15 minutes
-
an IDE
-
JDK 11+ installed with
JAVA_HOME
configured appropriately -
Apache Maven 3.8.1
-
Docker
Architecture
In this example, we build a very simple web application with a single page:
-
/index.html
This page is protected and can only be accessed by authenticated users.
Solution
We recommend that you follow the instructions in the next sections and create the application step by step. However, you can go right to the completed example.
Clone the Git repository: git clone https://github.com/quarkusio/quarkus-quickstarts.git
, or download an archive.
The solution is located in the security-openid-connect-web-authentication-quickstart
directory.
Creating the Maven Project
First, we need a new project. Create a new project with the following command:
mvn io.quarkus.platform:quarkus-maven-plugin:2.4.0.CR1:create \
-DprojectGroupId=org.acme \
-DprojectArtifactId=security-openid-connect-web-authentication-quickstart \
-Dextensions="resteasy,oidc" \
-DnoExamples
cd security-openid-connect-web-authentication-quickstart
If you already have your Quarkus project configured, you can add the oidc
extension
to your project by running the following command in your project base directory:
./mvnw quarkus:add-extension -Dextensions="oidc"
This will add the following to your pom.xml
:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-oidc</artifactId>
</dependency>
Writing the application
Let’s write a simple JAX-RS resource which has all the tokens returned in the authorization code grant response injected:
package org.acme.security.openid.connect.web.authentication;
import javax.inject.Inject;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import org.eclipse.microprofile.jwt.JsonWebToken;
import io.quarkus.oidc.IdToken;
import io.quarkus.oidc.RefreshToken;
@Path("/tokens")
public class TokenResource {
/**
* Injection point for the ID Token issued by the OpenID Connect Provider
*/
@Inject
@IdToken
JsonWebToken idToken;
/**
* Injection point for the Access Token issued by the OpenID Connect Provider
*/
@Inject
JsonWebToken accessToken;
/**
* Injection point for the Refresh Token issued by the OpenID Connect Provider
*/
@Inject
RefreshToken refreshToken;
/**
* Returns the tokens available to the application. This endpoint exists only for demonstration purposes, you should not
* expose these tokens in a real application.
*
* @return a map containing the tokens available to the application
*/
@GET
public String getTokens() {
StringBuilder response = new StringBuilder().append("<html>")
.append("<body>")
.append("<ul>");
Object userName = this.idToken.getClaim("preferred_username");
if (userName != null) {
response.append("<li>username: ").append(userName.toString()).append("</li>");
}
Object scopes = this.accessToken.getClaim("scope");
if (scopes != null) {
response.append("<li>scopes: ").append(scopes.toString()).append("</li>");
}
response.append("<li>refresh_token: ").append(refreshToken.getToken() != null).append("</li>");
return response.append("</ul>").append("</body>").append("</html>").toString();
}
}
This endpoint has ID, access and refresh tokens injected. It returns a preferred_username
claim from the ID token, a scope
claim from the access token and also a refresh token availability status.
Note that you do not have to inject the tokens - it is only required if the endpoint needs to use the ID token to interact with the currently authenticated user or use the access token to access a downstream service on behalf of this user.
Please see Access ID and Access Tokens section below for more information.
Configuring the application
The OpenID Connect extension allows you to define the configuration using the application.properties
file which should be located at the src/main/resources
directory.
Configuring using the application.properties file
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated
This is the simplest configuration you can have when enabling authentication to your application.
The quarkus.oidc.client-id
property references the client_id
issued by the OpenID Connect Provider and, in this case, the application is a public client (no client secret is defined).
The quarkus.oidc.application-type
property is set to web-app
in order to tell Quarkus that you want to enable the OpenID Connect Authorization Code Flow, so that your users are redirected to the OpenID Connect Provider to authenticate.
For last, the quarkus.http.auth.permission.authenticated
permission is set to tell Quarkus about the paths you want to protect. In this case,
all paths are being protected by a policy that ensures that only authenticated
users are allowed to access. For more details check Security Authorization Guide.
Configuring CORS
If you plan to consume this application from another application running on a different domain, you will need to configure CORS (Cross-Origin Resource Sharing). Please read the HTTP CORS documentation for more details.
Starting and Configuring the Keycloak Server
To start a Keycloak Server you can use Docker and just run the following command:
docker run --name keycloak -e KEYCLOAK_USER=admin -e KEYCLOAK_PASSWORD=admin -p 8180:8080 quay.io/keycloak/keycloak:15.0.2
You should be able to access your Keycloak Server at localhost:8180/auth.
Log in as the admin
user to access the Keycloak Administration Console. Username should be admin
and password admin
.
Import the realm configuration file to create a new realm. For more details, see the Keycloak documentation about how to create a new realm.
Running and Using the Application
Running in Developer Mode
To run the microservice in dev mode, use ./mvnw clean compile quarkus:dev
.
Running in JVM Mode
When you’re done playing with "dev-mode" you can run it as a standard Java application.
First compile it:
./mvnw package
Then run it:
java -jar target/quarkus-app/quarkus-run.jar
Running in Native Mode
This same demo can be compiled into native code: no modifications required.
This implies that you no longer need to install a JVM on your production environment, as the runtime technology is included in the produced binary, and optimized to run with minimal resource overhead.
Compilation will take a bit longer, so this step is disabled by default;
let’s build again by enabling the native
profile:
./mvnw package -Pnative
After getting a cup of coffee, you’ll be able to run this binary directly:
./target/security-openid-connect-web-authentication-quickstart-runner
Testing the Application
To test the application, you should open your browser and access the following URL:
If everything is working as expected, you should be redirected to the Keycloak server to authenticate.
In order to authenticate to the application you should type the following credentials when at the Keycloak login page:
-
Username: alice
-
Password: alice
After clicking the Login
button you should be redirected back to the application.
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 (eg. 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
, etc.
Dealing with 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 JAX-RS 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, etc.
Here is an example of how to configure an RP initiated logout flow:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.client-id=frontend
quarkus.oidc.application-type=web-app
quarkus.oidc.tenant-logout.logout.path=/logout
quarkus.oidc.tenant-logout.logout.post-logout-path=/postlogout
# Only the authenticated users can initiate a logout:
quarkus.http.auth.permission.authenticated.paths=/logout
quarkus.http.auth.permission.authenticated.policy=authenticated
# Logged out users should be returned to the /welcome.html site which will offer an option to re-login:
quarkus.http.auth.permission.authenticated.paths=/welcome.html
quarkus.http.auth.permission.authenticated.policy=permit
You may also need to set quarkus.oidc.authentication.cookie-path
to a path value common to all of the application resources which is /
in this example.
See Dealing with Cookies for more information.
Accessing ID and Access Tokens
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 javax.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 javax.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 IdToken does not provide enough information about the currently authenticated user then you can set a quarkus.oidc.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 javax.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 is 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 as documented here.
Token Verification And Introspection
Please see link:security-openid-connect#token-verification-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, etc. 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 link:security-openid-connect#token-introspection-userinfo-cache for more information about using a default token cache or registering a custom cache implementation.
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 authoriization 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 back 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.
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.
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 javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;
import io.quarkus.arc.AlternativePriority;
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
@AlternativePriority(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);
}
}
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 javax.enterprise.context.ApplicationScoped;
import javax.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().getCredential(IdTokenCredential.class).getRoutingContext();
vertxContext.put("listener-message", String.format("event:%s,tenantId:%s", event.getEventType().name(), tenantId));
}
}
Single Page Applications
Please 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, please 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");
}
});
}
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>
and configure Google OIDC properties:
quarkus.oidc.auth-server-url=https://accounts.google.com
quarkus.oidc.application-type=web-app
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 you would like to save on the discovery endpoint roundtrip, you can disable the discovery and configure them with relative path values, for example:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus
quarkus.oidc.discovery-enabled=false
# Authorization endpoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/auth
quarkus.oidc.authorization-path=/protocol/openid-connect/auth
# Token endpoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/token
quarkus.oidc.token-path=/protocol/openid-connect/token
# JWK set endpoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/certs
quarkus.oidc.jwks-path=/protocol/openid-connect/certs
# UserInfo endoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/userinfo
quarkus.oidc.user-info-path=/protocol/openid-connect/userinfo
# Token Introspection endoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/token/introspect
quarkus.oidc.introspection-path=/protocol/openid-connect/token/introspect
# End session endoint: http://localhost:8180/auth/realms/quarkus/protocol/openid-connect/logout
quarkus.oidc.end-session-path=/protocol/openid-connect/logout
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.
Token Propagation
Please see Token Propagation section about the Authorization Code Flow access token propagation to the downstream services.
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/auth/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.secret=mysecret
or
quarkus.oidc.auth-server-url=http://localhost:8180/auth/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/auth/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
# This is a key which will be used to retrieve a secret from the map of credentails 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/auth/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
:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
quarkus.oidc.credentials.jwt.secret=AyM1SysPpbyDfgZld3umj1qzKObwVMkoqQ-EstJQLr_T-1qS0gZH75aKtMN3Yj0iPS4hcgUuTwjAzZr1Z9CAow
# This is a token key identifier 'kid' header - set it if your OpenId Connect provider requires it,
quarkus.oidc.credentials.jwt.token-key-id=mykey
or with the secret retrieved from a CredentialsProvider:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/realms/quarkus/
quarkus.oidc.client-id=quarkus-app
# This is a key which will be used to retrieve a secret from the map of credentails 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:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/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
quarkus.oidc.credentials.jwt.token-key-id=mykey
private_key_jwt
with the key store file:
quarkus.oidc.auth-server-url=http://localhost:8180/auth/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=mykey
# This is a token key identifier 'kid' header - set it if your OpenId Connect provider requires it,
# Note it can be different to the `quarkus.oidc.credentials.jwt.key-id` value
quarkus.oidc.credentials.jwt.token-key-id=mykey
Using client_secret_jwt
or private_key_jwt
authentication methods ensures that no client secret goes over the wire.
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>
Wiremock
Add the following dependency:
<dependency>
<groupId>io.quarkus</groupId>
<artifactId>quarkus-test-oidc-server</artifactId>
<scope>test</scope>
</dependency>
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/auth/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/auth/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 above.
The only difference is that @QuarkusTestResource
is no longer needed:
@QuarkusTest
public class CodeFlowAuthorizationTest {
}
KeycloakTestResourceLifecycleManager
If you need to do the integration testing against Keycloak then you are encouraged to do it with Dev Services For Keycloak.
Use KeycloakTestResourceLifecycleManager
for your tests only if there is a good reason not to use 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>
which provides io.quarkus.test.keycloak.server.KeycloakTestResourceLifecycleManager
- an implementaion of io.quarkus.test.common.QuarkusTestResourceLifecycleManager
which starts a Keycloak container.
And configure maven.surefire.plugin
as follows:
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<!-- or, alternativey, 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 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 above.
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
Please 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
.
How to check the errors in the logs
Please enable io.quarkus.oidc.runtime.OidcProvider
TRACE
level logging to see more details about the token verification errors:
quarkus.log.category."io.quarkus.oidc.runtime.OidcProvider".level=TRACE
quarkus.log.category."io.quarkus.oidc.runtime.OidcProvider".min-level=TRACE
Please enable io.quarkus.oidc.runtime.OidcRecorder
TRACE
level logging to see more details about the OidcProvider client initialization errors:
quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".level=TRACE
quarkus.log.category."io.quarkus.oidc.runtime.OidcRecorder".min-level=TRACE
Running 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, see Running behind a reverse proxy Vert.x documentation section for more information.
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 calcuated 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 a SSL terminating reverse proxy.
External and Internal Access to OpenId Connect 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.
Customize 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
Configuration Reference
Configuration property fixed at build time - All other configuration properties are overridable at runtime
Type |
Default |
|
---|---|---|
If DevServices has been explicitly enabled or disabled. When DevServices is enabled Quarkus will attempt to automatically configure and start Keycloak when running in Dev or Test mode and when Docker is running. |
boolean |
|
The container image name to use, for container based DevServices providers. |
string |
|
Indicates if the Keycloak container managed by Quarkus Dev Services is shared. When shared, Quarkus looks for running containers using label-based service discovery. If a matching container is found, it is used, and so a second one is not started. Otherwise, Dev Services for Keycloak starts a new container.
The discovery uses the |
boolean |
|
The value of the |
string |
|
The class or file system path to a Keycloak realm file which will be used to initialize Keycloak. |
string |
|
The JAVA_OPTS passed to the keycloak JVM |
string |
|
The Keycloak realm name. This property will be used to create the realm if the realm file pointed to by the 'realm-path' property does not exist, default value is 'quarkus' in this case. If the realm file pointed to by the 'realm-path' property exists then it is still recommended to set this property for Dev Services for Keycloak to avoid parsing the realm file in order to determine the realm name. |
string |
|
Indicates if the Keycloak realm has to be created when the realm file pointed to by the 'realm-path' property does not exist. Disable it if you’d like to create a realm using Keycloak Administration Console or Keycloak Admin API from |
boolean |
|
Grant type which will be used to acquire a token to test the OIDC 'service' applications |
|
|
Optional fixed port the dev service will listen to. If not defined, the port will be chosen randomly. |
int |
|
The WebClient timeout. Use this property to configure how long an HTTP client will wait for a response when requesting tokens from Keycloak and sending them to the service endpoint. |
|
|
The Keycloak users map containing the user name and password pairs. If this map is empty then two users, 'alice' and 'bob' with the passwords matching their names will be created. This property will be used to create the Keycloak users if the realm file pointed to by the 'realm-path' property does not exist. |
|
|
The Keycloak user roles. If this map is empty then a user named 'alice' will get 'admin' and 'user' roles and all other users will get a 'user' role. This property will be used to create the Keycloak roles if the realm file pointed to by the 'realm-path' property does not exist. |
|
|
If the OIDC extension is enabled. |
boolean |
|
Enable the registration of the Default TokenIntrospection and UserInfo Cache implementation bean. Note it only allows to use the default implementation, one needs to configure it in order to activate it, please see |
boolean |
|
The base URL of the OpenID Connect (OIDC) server, for example, |
string |
|
Enables OIDC discovery. If the discovery is disabled then the 'token-path' property must be configured. |
boolean |
|
Relative path of the OIDC token endpoint which issues access and refresh tokens using either 'client_credentials' or 'password' grants |
string |
|
The client-id of the application. Each application has a client-id that is used to identify the application |
string |
|
The maximum amount of time connecting to the currently unavailable OIDC server will be attempted for. The number of times the connection request will be repeated is calculated by dividing the value of this property by 2. For example, setting it to |
||
The number of times an attempt to re-establish an already available connection will be repeated for. Note this property is different to the |
int |
|
The amount of time after which the current OIDC connection request will time out. |
|
|
The maximum size of the connection pool used by the WebClient |
int |
|
Client secret which is used for a |
string |
|
The client secret value - it will be ignored if 'secret.key' is set |
string |
|
The CredentialsProvider name which should only be set if more than one CredentialsProvider is registered |
string |
|
The CredentialsProvider client secret key |
string |
|
Authentication method. |
|
|
If provided, indicates that JWT is signed using a secret key |
string |
|
The CredentialsProvider name which should only be set if more than one CredentialsProvider is registered |
string |
|
The CredentialsProvider client secret key |
string |
|
If provided, indicates that JWT is signed using a private key in PEM or JWK format |
string |
|
If provided, indicates that JWT is signed using a private key from a key store |
string |
|
A parameter to specify the password of the key store file. If not given, the default ("password") is used. |
string |
|
The private key id/alias |
string |
|
The private key password |
string |
|
Key identifier of the signing key added as a JWT 'kid' header |
string |
|
JWT life-span in seconds. It will be added to the time it was issued at to calculate the expiration time. |
int |
|
The host (name or IP address) of the Proxy. Note: If OIDC adapter needs to use a Proxy to talk with OIDC server (Provider), then at least the "host" config item must be configured to enable the usage of a Proxy. |
string |
|
The port number of the Proxy. Default value is 80. |
int |
|
The username, if Proxy needs authentication. |
string |
|
The password, if Proxy needs authentication. |
string |
|
Certificate validation and hostname verification, which can be one of the following values from enum |
|
|
An optional trust store which holds the certificate information of the certificates to trust |
path |
|
A parameter to specify the password of the trust store file. |
string |
|
A parameter to specify the alias of the trust store certificate. |
string |
|
A unique tenant identifier. It must be set by |
string |
|
If this tenant configuration is enabled. |
boolean |
|
The application type, which can be one of the following values from enum |
|
|
Relative path of the OIDC authorization endpoint which authenticates the users. This property must be set for the 'web-app' applications if OIDC discovery is disabled. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC userinfo endpoint. This property must only be set for the 'web-app' applications if OIDC discovery is disabled and 'authentication.user-info-required' property is enabled. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC RFC7662 introspection endpoint which can introspect both opaque and JWT tokens. This property must be set if OIDC discovery is disabled and 1) the opaque bearer access tokens have to be verified or 2) JWT tokens have to be verified while the cached JWK verification set with no matching JWK is being refreshed. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC JWKS endpoint which returns a JSON Web Key Verification Set. This property should be set if OIDC discovery is disabled and the local JWT verification is required. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC end_session_endpoint. This property must be set if OIDC discovery is disabled and RP Initiated Logout support for the 'web-app' applications is required. This property will be ignored if the discovery is enabled. |
string |
|
Public key for the local JWT token verification. OIDC server connection will not be created when this property is set. |
string |
|
Path to the claim containing an array of groups. It starts from the top level JWT JSON object and can contain multiple segments where each segment represents a JSON object name only, example: "realm/groups". Use double quotes with the namespace qualified claim names. This property can be used if a token has no 'groups' claim but has the groups set in a different claim. |
string |
|
Separator for splitting a string which may contain multiple group values. It will only be used if the "role-claim-path" property points to a custom claim whose value is a string. A single space will be used by default because the standard 'scope' claim may contain a space separated sequence. |
string |
|
Source of the principal roles. |
|
|
Expected issuer 'iss' claim value. Note this property overrides the |
string |
|
Expected audience 'aud' claim value which may be a string or an array of strings. |
list of string |
|
Expected token type |
string |
|
Life span grace period in seconds. When checking token expiry, current time is allowed to be later than token expiration time by at most the configured number of seconds. When checking token issuance, current time is allowed to be sooner than token issue time by at most the configured number of seconds. |
int |
|
Name of the claim which contains a principal name. By default, the 'upn', 'preferred_username' and |
string |
|
Refresh expired ID tokens. If this property is enabled then a refresh token request will be performed if the ID token has expired and, if successful, the local session will be updated with the new set of tokens. Otherwise, the local session will be invalidated and the user redirected to the OpenID Provider to re-authenticate. In this case the user may not be challenged again if the OIDC provider session is still active. For this option be effective the |
boolean |
|
Refresh token time skew in seconds. If this property is enabled then the configured number of seconds is added to the current time when checking whether the access token should be refreshed. If the sum is greater than this access token’s expiration time then a refresh is going to happen. This property will be ignored if the 'refresh-expired' property is not enabled. |
||
Forced JWK set refresh interval in minutes. |
|
|
Custom HTTP header that contains a bearer token. This option is valid only when the application is of type |
string |
|
Allow the remote introspection of JWT tokens when no matching JWK key is available. Note this property is set to 'true' by default for backward-compatibility reasons and will be set to |
boolean |
|
Allow the remote introspection of the opaque tokens. Set this property to 'false' if only JWT tokens are expected. |
boolean |
|
The relative path of the logout endpoint at the application. If provided, the application is able to initiate the logout through this endpoint in conformance with the OpenID Connect RP-Initiated Logout specification. |
string |
|
Relative path of the application endpoint where the user should be redirected to after logging out from the OpenID Connect Provider. This endpoint URI must be properly registered at the OpenID Connect Provider as a valid redirect URI. |
string |
|
Relative path for calculating a "redirect_uri" query parameter. It has to start from a forward slash and will be appended to the request URI’s host and port. For example, if the current request URI is 'https://localhost:8080/service' then a 'redirect_uri' parameter will be set to 'https://localhost:8080/' if this property is set to '/' and be the same as the request URI if this property has not been configured. Note the original request URI will be restored after the user has authenticated if 'restorePathAfterRedirect' is set to 'true'. |
string |
|
If this property is set to 'true' then the original request URI which was used before the authentication will be restored after the user has been redirected back to the application. Note if |
boolean |
|
Remove the query parameters such as 'code' and 'state' set by the OIDC server on the redirect URI after the user has authenticated by redirecting a user to the same URI but without the query parameters. |
boolean |
|
Both ID and access tokens are fetched from the OIDC provider as part of the authorization code flow. ID token is always verified on every user request as the primary token which is used to represent the principal and extract the roles. Access token is not verified by default since it is meant to be propagated to the downstream services. The verification of the access token should be enabled if it is injected as a JWT token. Access tokens obtained as part of the code flow will always be verified if |
boolean |
|
Force 'https' as the 'redirect_uri' parameter scheme when running behind an SSL terminating reverse proxy. This property, if enabled, will also affect the logout |
boolean |
|
List of scopes |
list of string |
|
If enabled the state, session and post logout cookies will have their 'secure' parameter set to 'true' when HTTP is used. It may be necessary when running behind an SSL terminating reverse proxy. The cookies will always be secure if HTTPS is used even if this property is set to false. |
boolean |
|
Cookie path parameter value which, if set, will be used to set a path parameter for the session, state and post logout cookies. The |
string |
|
Cookie path header parameter value which, if set, identifies the incoming HTTP header whose value will be used to set a path parameter for the session, state and post logout cookies. If the header is missing then the |
string |
|
Cookie domain parameter value which, if set, will be used for the session, state and post logout cookies. |
string |
|
If this property is set to 'true' then an OIDC UserInfo endpoint will be called |
boolean |
|
Session age extension in minutes. The user session age property is set to the value of the ID token life-span by default and the user will be redirected to the OIDC provider to re-authenticate once the session has expired. If this property is set to a non-zero value then the expired ID token can be refreshed before the session has expired. This property will be ignored if the |
|
|
If this property is set to 'true' then a normal 302 redirect response will be returned if the request was initiated via JavaScript API such as XMLHttpRequest or Fetch and the current user needs to be (re)authenticated which may not be desirable for Single Page Applications since it automatically following the redirect may not work given that OIDC authorization endpoints typically do not support CORS. If this property is set to |
boolean |
|
Default TokenStateManager strategy. |
|
|
Default TokenStateManager keeps all tokens (ID, access and refresh) returned in the authorization code grant response in a single session cookie by default. Enable this property to minimize a session cookie size |
boolean |
|
Allow caching the token introspection data. Note enabling this property does not enable the cache itself but only permits to cache the token introspection for a given tenant. If the default token cache can be used then please see |
boolean |
|
Allow caching the user info data. Note enabling this property does not enable the cache itself but only permits to cache the user info data for a given tenant. If the default token cache can be used then please see |
boolean |
|
Maximum number of cache entries. Set it to a positive value if the cache has to be enabled. |
int |
|
Maximum amount of time a given cache entry is valid for. |
|
|
Clean up timer interval. If this property is set then a timer will check and remove the stale entries periodically. |
||
Additional properties which will be added as the query parameters to the authentication redirect URI. |
|
|
Type |
Default |
|
The base URL of the OpenID Connect (OIDC) server, for example, |
string |
|
Enables OIDC discovery. If the discovery is disabled then the 'token-path' property must be configured. |
boolean |
|
Relative path of the OIDC token endpoint which issues access and refresh tokens using either 'client_credentials' or 'password' grants |
string |
|
The client-id of the application. Each application has a client-id that is used to identify the application |
string |
|
The maximum amount of time connecting to the currently unavailable OIDC server will be attempted for. The number of times the connection request will be repeated is calculated by dividing the value of this property by 2. For example, setting it to |
||
The number of times an attempt to re-establish an already available connection will be repeated for. Note this property is different to the |
int |
|
The amount of time after which the current OIDC connection request will time out. |
|
|
The maximum size of the connection pool used by the WebClient |
int |
|
Client secret which is used for a |
string |
|
The client secret value - it will be ignored if 'secret.key' is set |
string |
|
The CredentialsProvider name which should only be set if more than one CredentialsProvider is registered |
string |
|
The CredentialsProvider client secret key |
string |
|
Authentication method. |
|
|
If provided, indicates that JWT is signed using a secret key |
string |
|
The CredentialsProvider name which should only be set if more than one CredentialsProvider is registered |
string |
|
The CredentialsProvider client secret key |
string |
|
If provided, indicates that JWT is signed using a private key in PEM or JWK format |
string |
|
If provided, indicates that JWT is signed using a private key from a key store |
string |
|
A parameter to specify the password of the key store file. If not given, the default ("password") is used. |
string |
|
The private key id/alias |
string |
|
The private key password |
string |
|
Key identifier of the signing key added as a JWT 'kid' header |
string |
|
JWT life-span in seconds. It will be added to the time it was issued at to calculate the expiration time. |
int |
|
The host (name or IP address) of the Proxy. Note: If OIDC adapter needs to use a Proxy to talk with OIDC server (Provider), then at least the "host" config item must be configured to enable the usage of a Proxy. |
string |
|
The port number of the Proxy. Default value is 80. |
int |
|
The username, if Proxy needs authentication. |
string |
|
The password, if Proxy needs authentication. |
string |
|
Certificate validation and hostname verification, which can be one of the following values from enum |
|
|
An optional trust store which holds the certificate information of the certificates to trust |
path |
|
A parameter to specify the password of the trust store file. |
string |
|
A parameter to specify the alias of the trust store certificate. |
string |
|
A unique tenant identifier. It must be set by |
string |
|
If this tenant configuration is enabled. |
boolean |
|
The application type, which can be one of the following values from enum |
|
|
Relative path of the OIDC authorization endpoint which authenticates the users. This property must be set for the 'web-app' applications if OIDC discovery is disabled. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC userinfo endpoint. This property must only be set for the 'web-app' applications if OIDC discovery is disabled and 'authentication.user-info-required' property is enabled. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC RFC7662 introspection endpoint which can introspect both opaque and JWT tokens. This property must be set if OIDC discovery is disabled and 1) the opaque bearer access tokens have to be verified or 2) JWT tokens have to be verified while the cached JWK verification set with no matching JWK is being refreshed. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC JWKS endpoint which returns a JSON Web Key Verification Set. This property should be set if OIDC discovery is disabled and the local JWT verification is required. This property will be ignored if the discovery is enabled. |
string |
|
Relative path of the OIDC end_session_endpoint. This property must be set if OIDC discovery is disabled and RP Initiated Logout support for the 'web-app' applications is required. This property will be ignored if the discovery is enabled. |
string |
|
Public key for the local JWT token verification. OIDC server connection will not be created when this property is set. |
string |
|
Path to the claim containing an array of groups. It starts from the top level JWT JSON object and can contain multiple segments where each segment represents a JSON object name only, example: "realm/groups". Use double quotes with the namespace qualified claim names. This property can be used if a token has no 'groups' claim but has the groups set in a different claim. |
string |
|
Separator for splitting a string which may contain multiple group values. It will only be used if the "role-claim-path" property points to a custom claim whose value is a string. A single space will be used by default because the standard 'scope' claim may contain a space separated sequence. |
string |
|
Source of the principal roles. |
|
|
Expected issuer 'iss' claim value. Note this property overrides the |
string |
|
Expected audience 'aud' claim value which may be a string or an array of strings. |
list of string |
|
Expected token type |
string |
|
Life span grace period in seconds. When checking token expiry, current time is allowed to be later than token expiration time by at most the configured number of seconds. When checking token issuance, current time is allowed to be sooner than token issue time by at most the configured number of seconds. |
int |
|
Name of the claim which contains a principal name. By default, the 'upn', 'preferred_username' and |
string |
|
Refresh expired ID tokens. If this property is enabled then a refresh token request will be performed if the ID token has expired and, if successful, the local session will be updated with the new set of tokens. Otherwise, the local session will be invalidated and the user redirected to the OpenID Provider to re-authenticate. In this case the user may not be challenged again if the OIDC provider session is still active. For this option be effective the |
boolean |
|
Refresh token time skew in seconds. If this property is enabled then the configured number of seconds is added to the current time when checking whether the access token should be refreshed. If the sum is greater than this access token’s expiration time then a refresh is going to happen. This property will be ignored if the 'refresh-expired' property is not enabled. |
||
Forced JWK set refresh interval in minutes. |
|
|
Custom HTTP header that contains a bearer token. This option is valid only when the application is of type |
string |
|
Allow the remote introspection of JWT tokens when no matching JWK key is available. Note this property is set to 'true' by default for backward-compatibility reasons and will be set to |
boolean |
|
Allow the remote introspection of the opaque tokens. Set this property to 'false' if only JWT tokens are expected. |
boolean |
|
The relative path of the logout endpoint at the application. If provided, the application is able to initiate the logout through this endpoint in conformance with the OpenID Connect RP-Initiated Logout specification. |
string |
|
Relative path of the application endpoint where the user should be redirected to after logging out from the OpenID Connect Provider. This endpoint URI must be properly registered at the OpenID Connect Provider as a valid redirect URI. |
string |
|
Relative path for calculating a "redirect_uri" query parameter. It has to start from a forward slash and will be appended to the request URI’s host and port. For example, if the current request URI is 'https://localhost:8080/service' then a 'redirect_uri' parameter will be set to 'https://localhost:8080/' if this property is set to '/' and be the same as the request URI if this property has not been configured. Note the original request URI will be restored after the user has authenticated if 'restorePathAfterRedirect' is set to 'true'. |
string |
|
If this property is set to 'true' then the original request URI which was used before the authentication will be restored after the user has been redirected back to the application. Note if |
boolean |
|
Remove the query parameters such as 'code' and 'state' set by the OIDC server on the redirect URI after the user has authenticated by redirecting a user to the same URI but without the query parameters. |
boolean |
|
Both ID and access tokens are fetched from the OIDC provider as part of the authorization code flow. ID token is always verified on every user request as the primary token which is used to represent the principal and extract the roles. Access token is not verified by default since it is meant to be propagated to the downstream services. The verification of the access token should be enabled if it is injected as a JWT token. Access tokens obtained as part of the code flow will always be verified if |
boolean |
|
Force 'https' as the 'redirect_uri' parameter scheme when running behind an SSL terminating reverse proxy. This property, if enabled, will also affect the logout |
boolean |
|
List of scopes |
list of string |
|
Additional properties which will be added as the query parameters to the authentication redirect URI. |
|
|
If enabled the state, session and post logout cookies will have their 'secure' parameter set to 'true' when HTTP is used. It may be necessary when running behind an SSL terminating reverse proxy. The cookies will always be secure if HTTPS is used even if this property is set to false. |
boolean |
|
Cookie path parameter value which, if set, will be used to set a path parameter for the session, state and post logout cookies. The |
string |
|
Cookie path header parameter value which, if set, identifies the incoming HTTP header whose value will be used to set a path parameter for the session, state and post logout cookies. If the header is missing then the |
string |
|
Cookie domain parameter value which, if set, will be used for the session, state and post logout cookies. |
string |
|
If this property is set to 'true' then an OIDC UserInfo endpoint will be called |
boolean |
|
Session age extension in minutes. The user session age property is set to the value of the ID token life-span by default and the user will be redirected to the OIDC provider to re-authenticate once the session has expired. If this property is set to a non-zero value then the expired ID token can be refreshed before the session has expired. This property will be ignored if the |
|
|
If this property is set to 'true' then a normal 302 redirect response will be returned if the request was initiated via JavaScript API such as XMLHttpRequest or Fetch and the current user needs to be (re)authenticated which may not be desirable for Single Page Applications since it automatically following the redirect may not work given that OIDC authorization endpoints typically do not support CORS. If this property is set to |
boolean |
|
Default TokenStateManager strategy. |
|
|
Default TokenStateManager keeps all tokens (ID, access and refresh) returned in the authorization code grant response in a single session cookie by default. Enable this property to minimize a session cookie size |
boolean |
|
Allow caching the token introspection data. Note enabling this property does not enable the cache itself but only permits to cache the token introspection for a given tenant. If the default token cache can be used then please see |
boolean |
|
Allow caching the user info data. Note enabling this property does not enable the cache itself but only permits to cache the user info data for a given tenant. If the default token cache can be used then please see |
boolean |
|
About the Duration format
The format for durations uses the standard You can also provide duration values starting with a number.
In this case, if the value consists only of a number, the converter treats the value as seconds.
Otherwise, |