Feat: Added MCD Support

[tanya732]

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

At a high level, the problem is that CallbackServlet persists tokens.getAccessToken() (and similarly tokens.getIdToken()) directly into the HTTP session, even though the Tokens object may contain values that originated in untrusted front‑channel request parameters. To maintain a proper trust boundary, the servlet should either (a) avoid storing raw tokens in the session at all, or (b) only store fields derived from fully verified tokens and/or mark/handle them explicitly as untrusted. Since changing how AuthenticationController and RequestProcessor validate tokens would be intrusive, the least‑disruptive fix is to change CallbackServlet so it no longer stores the raw tokens in the session.

The single best fix that preserves existing behavior as much as possible while resolving the trust‑boundary violation is:

• Remove the lines that write accessToken and idToken directly into the session.
• If the session needs some indication that the user is authenticated, store only a minimal, derived flag (e.g., a boolean "authenticated" attribute) that does not carry attacker‑controlled content. This avoids persisting the token values themselves, so even if an attacker tampers with the access token parameter, it won’t be stored and reused by server‑side code.
• Leave the rest of the logic (using AuthenticationController.handle, printing the domain, and writing the success message) unchanged, since the CodeQL alert is specifically about the session write.

Concretely, in src/main/java/com/auth0/test/CallbackServlet.java, within doGet, replace:

HttpSession session = req.getSession(true);
session.setAttribute("accessToken", tokens.getAccessToken());
session.setAttribute("idToken", tokens.getIdToken());

with something like:

HttpSession session = req.getSession(true);
// Mark the user as authenticated without storing raw token values in the session.
session.setAttribute("authenticated", Boolean.TRUE);

This change removes the tainted data flow into the session while still giving downstream code a way to know that an authentication step has succeeded. No additional imports or helper methods are required.

---

In general terms, we should avoid directly trusting or propagating unvalidated data from HTTP request parameters into a more trusted context (like the HTTP session or HTML responses). For this specific case, there are two issues: (1) storing the raw idToken string (originating from request parameters) in the session; and (2) writing the raw idToken back to the response body. The ID token itself is cryptographically verified inside RequestProcessor, but the servlet layer is not aware of that and CodeQL flags the direct flow. We can resolve the finding and improve security by (a) no longer storing the raw ID token in the session and (b) not echoing it back to the client.

The best fix that preserves core functionality is to store only the access token (which is already being stored) and to remove direct use of tokens.getIdToken() for session storage and response output in CallbackServlet. Typically, the ID token is used server-side to derive user identity (name/email/subject) rather than being stored as-is and printed to the user; however, since we must not change the rest of the codebase, we will simply stop persisting and echoing the raw token. This eliminates the tainted flow to the session and to the response while leaving the Tokens class and RequestProcessor behavior untouched.

Concretely:

• In src/main/java/com/auth0/test/CallbackServlet.java:
  • Remove session.setAttribute("idToken", tokens.getIdToken());.
  • Change the success message so that it does not concatenate tokens.getIdToken() (e.g., just “Login Successful!” or a generic welcome string).
    No changes are needed in Tokens, RequestProcessor, or AuthenticationController for this specific trust-boundary finding.

General fix: Never write untrusted values directly to the HTTP response without appropriate output encoding. In this case, you should not display the raw idToken at all. Instead, either (a) remove the token from the user-facing message entirely, or (b) display a safe, HTML-escaped value derived from trusted/validated data.

Best fix with minimal functional change: Adjust CallbackServlet.doGet so that the success message no longer includes tokens.getIdToken(). The simplest and safest change is to return a generic success message like "Login Successful!" or "Login Successful! Welcome." without any user-controlled content. This preserves the logical behavior (successful login, session attributes set) while eliminating the XSS sink. No other classes (Tokens, RequestProcessor, AuthenticationController) need modification for this issue.

Concretely:

• In src/main/java/com/auth0/test/CallbackServlet.java, update line 31:
  • Replace resp.getWriter().write("Login Successful! Welcome, " + tokens.getIdToken());
  • With a neutral message such as resp.getWriter().write("Login Successful!"); (or similar, but without including idToken or any other request-derived data).
• No new methods or imports are required for this minimal fix.

If in the future you want to display user attributes (e.g., a user’s name), you should:

• Decode the ID token into claims on the server side, and
• HTML-escape any claim values before including them in the response (using a well-known library like Apache Commons Text’s StringEscapeUtils.escapeHtml4), and
• Only display non-sensitive, user-facing fields (never raw tokens).

In general, to fix this class of issues, you should avoid sending raw exception messages or stack traces to the client. Instead, log the detailed error server-side and return a generic, non-revealing message (or appropriate HTTP status code) to the user.

For this specific servlet, the best fix without changing functionality is:

• Keep returning HTTP 403 (forbidden) on authentication failures.
• Replace e.getMessage() in the response body with a generic message like "Authentication failed" or "Authentication failed. Please try again.".
• Optionally log the exception on the server using standard Java logging so developers can still see the root cause.

We are only allowed to modify src/main/java/com/auth0/test/CallbackServlet.java within the shown snippet. To log the error, we can either:

• Use e.printStackTrace(); (not ideal stylistically, but requires no new imports), or
• Add java.util.logging.Logger and use that.

Adding java.util.logging.Logger is a standard, well-known library and fits the constraints. Concretely:

• Add a private static final Logger LOGGER = Logger.getLogger(CallbackServlet.class.getName()); field.
• In the catch block, log the exception with LOGGER.log(Level.WARNING, "Authentication failed", e);.
• Change the line writing the response to: resp.getWriter().write("Authentication failed");.

This preserves existing behavior (403 on auth failure, success path unchanged) while preventing detailed error information from reaching the client.

In general, to fix a deprecated method invocation you should switch to the recommended non-deprecated overload or replacement API described in the library’s documentation, keeping semantics the same. For Apache Commons Lang’s Validate.notNull(T object), the standard replacement is Validate.notNull(T object, String message) or the varargs version with a format string.

In this code, there are two constructors in IdTokenVerifier.Options using the deprecated overload:

159:             Validate.notNull(issuer);
160:             Validate.notNull(audience);
161:             Validate.notNull(verifier);
...
168:             Validate.notNull(audience);
169:             Validate.notNull(verifier);

The best fix is to call the non-deprecated overload that accepts a message, e.g.:

Validate.notNull(audience, "Audience must not be null");

This preserves the null-check semantics, avoids deprecation, and adds helpful context if validation fails. No new imports are needed, and we shouldn’t change other parts of the file. We will update all Validate.notNull(...) calls in this shown region to include a clear, parameter-specific message while leaving the rest of the constructors untouched.

In general, to fix usage of a deprecated validation method like Validate.notNull, you should replace it with a non‑deprecated equivalent that provides the same null‑checking semantics. For null checks, the idiomatic modern replacement is java.util.Objects.requireNonNull, which throws a NullPointerException when the argument is null; you can also supply a custom message.

For this specific case in IdTokenVerifier.Options, we should replace both constructor calls to Validate.notNull(...) with Objects.requireNonNull(...). This maintains the intent (ensuring issuer, audience, and verifier are non‑null) without changing functional behavior in any observable way, beyond the exact exception type/message if previously different. To implement this, within src/main/java/com/auth0/IdTokenVerifier.java:

• Add an import for java.util.Objects; at the top, leaving the existing imports intact.
• In the constructor public Options(String issuer, String audience, SignatureVerifier verifier), replace:
  • Validate.notNull(issuer); with Objects.requireNonNull(issuer, "issuer");
  • Validate.notNull(audience); with Objects.requireNonNull(audience, "audience");
  • Validate.notNull(verifier); with Objects.requireNonNull(verifier, "verifier");
• In the constructor public Options(String audience, SignatureVerifier verifier), replace:
  • Validate.notNull(audience); with Objects.requireNonNull(audience, "audience");
  • Validate.notNull(verifier); with Objects.requireNonNull(verifier, "verifier");

We keep the existing Validate import untouched in this file since we’re not shown its other usages, but we stop using the deprecated notNull method in the provided snippet.

In general, to fix this kind of issue you either (a) implement a meaningful toString() in your own class, or (b) avoid calling toString() on third‑party types that don’t override it, and instead log only relevant, human‑readable information that you control.

For this specific case, Auth0Provider does not own the AuthenticationController class, so we should not add or change toString() there. The simplest, behaviour‑preserving fix is to remove the explicit toString() call and avoid depending on AuthenticationController’s string representation. Since the message already clearly states what happened (“Created AuthenticationController with MCD DomainResolver”), we can just log that without appending the controller instance. This preserves existing functionality (the controller is still created and returned; only the log format changes) and removes reliance on the default toString().

Concretely:

• In src/main/java/com/auth0/test/Auth0Provider.java, line 26, replace System.out.println("Created AuthenticationController with MCD DomainResolver "+controller.toString()); with System.out.println("Created AuthenticationController with MCD DomainResolver");.
• No additional methods, imports, or definitions are required.

In general, the fix is to stop calling the deprecated AuthAPI.setLoggingEnabled(boolean) API and instead configure logging using the currently supported mechanism. In recent Auth0 Java SDKs, HTTP logging is controlled via HttpOptions (for example, by supplying a custom logging implementation) rather than a boolean flag on AuthAPI. In this code, RequestProcessor already has an HttpOptions httpOptions field that is passed into the AuthAPI constructor when non‑null, so the best way to preserve behavior without using the deprecated method is to handle the logging flag via HttpOptions before constructing the client, and stop calling setLoggingEnabled on the AuthAPI instance.

Because we must not change behavior outside the shown snippet and cannot modify other files, the minimal and safest concrete change here is to remove the call to the deprecated method and leave a clear comment indicating that logging should be configured through HttpOptions (which this class already supports), or elsewhere in the codebase. This avoids the deprecated API usage without affecting how the rest of this method works (telemetry, dynamic domain handling, etc.). Specifically, in src/main/java/com/auth0/RequestProcessor.java, in the createClientForDomain(String domain) method, remove line 211 (client.setLoggingEnabled(loggingEnabled);) and optionally add a brief comment explaining that logging configuration should be handled via HttpOptions or other up‑to‑date mechanisms rather than AuthAPI.setLoggingEnabled.