Feat: Added MCD Support by tanya732 · Pull Request #199 · auth0/auth0-java-mvc-common

tanya732 · 2026-01-27T06:55:46Z

Changes

Please describe both what is changing and why this is important. Include:

Endpoints added, deleted, deprecated, or changed
Classes and methods added, deleted, deprecated, or changed
Screenshots of new or changed UI, if applicable
A summary of usage if this is a new feature or change to a public API (this should also be added to relevant documentation once released)
Any alternative designs or approaches considered

References

Please include relevant links supporting this change such as a:

support ticket
community post
StackOverflow post
support forum thread

Testing

Please describe how this can be tested by reviewers. Be specific about anything not tested and reasons why. If this library has unit and/or integration testing, tests should be added for new functionality and existing tests should complete without errors.

This change adds test coverage
This change has been tested on the latest version of Java or why not

Checklist

I have read the Auth0 general contribution guidelines
I have read the Auth0 Code of Conduct
All existing and new tests complete without errors

src/main/java/com/auth0/test/CallbackServlet.java

src/main/java/com/auth0/DomainResolver.java

src/main/java/com/auth0/IdTokenVerifier.java

src/main/java/com/auth0/test/Auth0Provider.java

tanya732 · 2026-02-04T09:55:00Z

src/main/java/com/auth0/RequestProcessor.java

+        }
+
+        // Apply deferred settings
+        client.setLoggingEnabled(loggingEnabled);


In general, the fix is to stop calling the deprecated AuthAPI.setLoggingEnabled(boolean) method and instead configure logging using the non-deprecated mechanism provided by the Auth0 Java SDK. In recent versions, HTTP/logging behavior is configured via HttpOptions rather than on AuthAPI directly, so the correct approach is to ensure that an HttpOptions instance with the desired logging configuration is supplied to the AuthAPI constructor.

Within RequestProcessor.createClientForDomain, the behavior today is:

If httpOptions is non-null, use it to build the AuthAPI.

Otherwise, create an AuthAPI with the 3-arg constructor.

Then, regardless, call client.setLoggingEnabled(loggingEnabled).

To preserve behavior without using the deprecated method, we can:

When httpOptions is null, create a new HttpOptions instance and set its logging flag according to loggingEnabled, then pass it into the 4-arg AuthAPI constructor.

When httpOptions is non-null, derive a new HttpOptions (or mutate the existing one if that is acceptable in this context) with the logging flag set based on loggingEnabled, and then pass that into the constructor.

Remove the direct call to client.setLoggingEnabled(loggingEnabled) entirely.

Because we cannot assume other parts of the code, we will keep the logic local and simple: if httpOptions is null, we create a fresh HttpOptions and configure logging; if it is not null, we reuse it and simply set logging on it before using it. This preserves existing semantics (a single HttpOptions object shared across clients, if that is what the rest of the code expects) while routing logging configuration through the non-deprecated HttpOptions API. No new imports are needed because HttpOptions is already imported.

Concretely, in createClientForDomain:

Introduce a local variable HttpOptions localHttpOptions that is either the existing httpOptions or a new one.

Set logging on localHttpOptions according to loggingEnabled.

Always use the 4-arg AuthAPI constructor with localHttpOptions.

Remove line 179: client.setLoggingEnabled(loggingEnabled);.

Ignore for now

kailash-b · 2026-01-27T11:28:10Z

src/main/java/com/auth0/RequestProcessor.java

+            this.signatureVerifier = signatureVerifier;
+        }
+
+//        Builder(AuthAPI client, String responseType, IdTokenVerifier.Options verifyOptions) {


Is commenting this piece of code intended?

src/main/java/com/auth0/RequestProcessor.java

kailash-b · 2026-01-27T11:48:33Z

src/main/java/com/auth0/RequestProcessor.java

+        String originDomain = domainProvider.getDomain(request);
+        AuthAPI client = createClientForDomain(originDomain);
+        String originIssuer = getIssuer(originDomain);
+        verifyOptions.setIssuer(originIssuer);


Can this cause issues? Similar to how Domain was causing issues?

Looks like the verifyOptions is tied to the RequestProcessor instance that is created during init using the AuthenticationController.

If we modify the verifyOptions in-flight, will it cause problems when multiple calls are happening, since this is a common instance across?

Need to verify this once.

Yes, that's correct I have updated verifyOptions

kailash-b · 2026-01-27T11:52:51Z

src/main/java/com/auth0/RequestProcessor.java

        return new Tokens(accessToken, idToken, refreshToken, type, expiresIn);
    }

+    private String getIssuer(String domain) {


Minor suggestion, since we are actually constructing the Issuer here, we can name this better. Something like ToIssuer()?

Also, consider moving this to a Utils class?

Have renamed to constructIssuer

src/main/java/com/auth0/Tokens.java

kailash-b · 2026-01-27T12:00:03Z

src/main/java/com/auth0/test/Auth0Provider.java

Is this change intended? There already is a test folder.

If yes, it would be easier if some detail is added as to what we are trying to test

I have added a note.. before merging will remove the test and docker file

src/main/java/com/auth0/RequestProcessor.java

-        return new Tokens(request.getParameter(KEY_ACCESS_TOKEN), request.getParameter(KEY_ID_TOKEN), null, request.getParameter(KEY_TOKEN_TYPE), expiresIn);
+    private Tokens getFrontChannelTokens(HttpServletRequest request, String originDomain, String originIssuer) {
+        Long expiresIn = request.getParameter(KEY_EXPIRES_IN) == null ? null
+                : Long.parseLong(request.getParameter(KEY_EXPIRES_IN));


In general, the fix is to ensure that parsing the expires_in request parameter into a Long does not allow a NumberFormatException to propagate unchecked. This is best achieved by surrounding the Long.parseLong(...) call with a try/catch that handles NumberFormatException and falls back to a safe behavior (e.g., treating the value as absent) or, if appropriate, wrapping it in a domain-specific exception.

The single best way to fix this, without changing existing functionality for valid inputs, is to catch NumberFormatException inside getFrontChannelTokens. When KEY_EXPIRES_IN is present but not parseable as a Long, the behavior that least surprises callers is to treat it the same as if the parameter were missing and set expiresIn to null. That keeps the method’s signature and returned Tokens construction unchanged while making it robust against malformed client input. Concretely, in src/main/java/com/auth0/RequestProcessor.java, adjust lines 475–479 so that the computation of expiresIn is enclosed in a try/catch (NumberFormatException e) that sets expiresIn to null on failure, then pass that expiresIn to the Tokens constructor as before. No new imports or methods are required, as NumberFormatException is in java.lang.

src/main/java/com/auth0/test/CallbackServlet.java

src/test/java/com/auth0/AuthenticationControllerTest.java

-        assertThat(signatureVerifier, is(notNullValue()));
-        assertThat(signatureVerifier, instanceOf(AlgorithmNameVerifier.class));
-        assertThat(verificationOptions, is(controller.getRequestProcessor().verifyOptions));
+        Tokens result = controller.handle(request);


src/test/java/com/auth0/AuthenticationControllerTest.java

+
+        NullPointerException exception = assertThrows(
+                NullPointerException.class,
+                () -> controller.handle((HttpServletRequest) null));


src/test/java/com/auth0/AuthenticationControllerTest.java

-        assertThat(requestProcessor.verifyOptions.clock, is(nullValue()));
-        assertThat(requestProcessor.verifyOptions.nonce, is(nullValue()));
-        assertThat(requestProcessor.verifyOptions.getMaxAge(), is(nullValue()));
+        AuthorizeUrl result = controller.buildAuthorizeUrl(request, redirectUri);


src/test/java/com/auth0/AuthenticationControllerTest.java

-        assertThat(requestProcessor.verifyOptions.clockSkew, is(12345));
+        NullPointerException exception = assertThrows(
+                NullPointerException.class,
+                () -> controller.buildAuthorizeUrl(null, "https://redirect.to/me"));


src/test/java/com/auth0/AuthenticationControllerTest.java

-        assertThat(requestProcessor.verifyOptions.getMaxAge(), is(12345));
+        NullPointerException exception = assertThrows(
+                NullPointerException.class,
+                () -> controller.buildAuthorizeUrl(request, (String) null));


src/test/java/com/auth0/RequestProcessorTest.java

+        assertThat(exception.getCode(), is("access_denied"));
+        // Note: getDescription() is deprecated but still available
+        @SuppressWarnings("deprecation")
+        String description = exception.getDescription();


To fix the problem, the test should stop invoking the deprecated InvalidRequestException.getDescription() method and instead use the non-deprecated accessor that exposes the same error description. In most Auth0 Java APIs, InvalidRequestException (or similar OAuth error exception classes) provide a getErrorDescription() method that replaces getDescription(). The test should assert against this new accessor rather than the deprecated one. This removes the need for @SuppressWarnings("deprecation") and resolves the CodeQL finding while preserving the assertion on the error description.

Concretely, in src/test/java/com/auth0/RequestProcessorTest.java, within the shouldThrowExceptionWhenErrorInRequest test (around lines 381–396), remove the comment and the @SuppressWarnings("deprecation") annotation that justify using the deprecated method, replace the call to exception.getDescription() with exception.getErrorDescription(), and keep the assertion checking that the description equals "The user denied the request". No other parts of the test need to change, and no new imports are required.

Feat: Added MCD Support

dd57b0e

github-advanced-security bot found potential problems Jan 27, 2026

View reviewed changes

Minor fixes

fd770aa

github-advanced-security bot found potential problems Jan 27, 2026

View reviewed changes

kailash-b requested changes Feb 3, 2026

View reviewed changes

Modified tests

4a039eb

github-advanced-security bot found potential problems Feb 4, 2026

View reviewed changes

@@ -169,14 +169,15 @@
                 AuthAPI createClientForDomain(String domain) {
                     final AuthAPI client;
-                    if (httpOptions != null) {
-                        client = new AuthAPI(domain, clientId, clientSecret, httpOptions);
-                    } else {
-                        client = new AuthAPI(domain, clientId, clientSecret);
+                    HttpOptions localHttpOptions = httpOptions;
+                    if (localHttpOptions == null) {
+                        localHttpOptions = new HttpOptions();
                     }
+                    localHttpOptions.setLogging(loggingEnabled);
+                    client = new AuthAPI(domain, clientId, clientSecret, localHttpOptions);
                     // Apply deferred settings
-                    client.setLoggingEnabled(loggingEnabled);
                     if (telemetryDisabled) {
                         client.doNotSendTelemetry();
                     } else {

@@ -473,8 +473,15 @@
                  *         parameters.
                  */
                 private Tokens getFrontChannelTokens(HttpServletRequest request, String originDomain, String originIssuer) {
-                    Long expiresIn = request.getParameter(KEY_EXPIRES_IN) == null ? null
-                            : Long.parseLong(request.getParameter(KEY_EXPIRES_IN));
+                    Long expiresIn = null;
+                    String expiresInParam = request.getParameter(KEY_EXPIRES_IN);
+                    if (expiresInParam != null) {
+                        try {
+                            expiresIn = Long.parseLong(expiresInParam);
+                        } catch (NumberFormatException ignored) {
+                            expiresIn = null;
+                        }
+                    }
                     return new Tokens(request.getParameter(KEY_ACCESS_TOKEN), request.getParameter(KEY_ID_TOKEN), null,
                             request.getParameter(KEY_TOKEN_TYPE), expiresIn, originDomain, originIssuer);
                 }

Conversation

tanya732 commented Jan 27, 2026

Changes

References

Testing

Checklist

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Check notice

Uh oh!

Copilot Autofix

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Check notice

Copilot Autofix

Uh oh!

Check notice

Uh oh!

Copilot Autofix

Check notice

Uh oh!

Copilot Autofix

Check notice

Uh oh!

Copilot Autofix

Check notice

Uh oh!

Copilot Autofix

Check notice

Uh oh!

Copilot Autofix

Check notice

Uh oh!

Copilot Autofix

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants