2026.1.2 to 2026.1.3
1. Authentication: Explicit access token validation for custom OAuth2 providers
What changed
Version 2026.1.3 introduces explicit access token validation for CUSTOM OAuth2
providers. The Authentication Provider alias now provides the property
accessTokenValidationMode with the following values:
NONE: No access token validation. This is the default value and keeps existing systems working without configuration changes.JWT: Validates a signed JWT access token against the public key that is downloaded automatically from the JWKS endpoint URL.PROCESS: A process has to be im implemented and configured on order to validate an opaque access token by sending it to a predefined endpoint. When this mode is selected, the additional propertyvalidateAccessTokenProcessbecomes visible and must be set to an authentication process that validates the token and returns a boolean value.
Why it matters
Before version 2026.1.3, token validation for custom providers had to be
implemented inside the getUsernameFromAccessTokenProcess, which did not make
this requirement obvious. The default value NONE preserves the previous
behavior of existing systems, but it performs no validation at all. Because the
access token is direct user input, an unvalidated token can be replayed or
forged, so leaving a system on NONE is a security risk.
Recommended actions
- Review every Authentication Provider alias that uses a
CUSTOMOAuth2 provider. - If the provider issues signed JWT access tokens, set
accessTokenValidationModetoJWT. - If the provider issues opaque access tokens, set
accessTokenValidationModetoPROCESSand select an authentication process forvalidateAccessTokenProcessthat validates the token against the provider and returns a boolean value. - Do not keep the default
NONEon production systems. UseNONEonly temporarily while migrating an existing configuration. - For details about the property values and an example validation process, see Token Validation for Custom Providers.