Client credentials authentication - token cache returns unintended auth token

[malkaviancz]

Driver version

> 12.2.x

SQL Server version

Microsoft Azure SQL Data Warehouse (RTM) - 12.0.2000.8

Client Operating System

macOS Sonoma 14.3.1

JAVA/JVM version

jdk 17

Problem description

Using client credentials to authenticate, create 2 connections with a valid and an invalid client secret (in that order)

Expected behavior

The second connection attempt should throw SQLException stating invalid client secret provided

Actual behavior

The second connection succeeds, no exception was thrown

Any other details that can be helpful

With client credentials, after any successful authentication attempt, the auth token will be saved in the token cache, and subsequent connection with only client secret changed incorrectly returns the previous token
Tested and reproduceable on versions > 12.2.x
Previous versions doesn't use the token cache and behaved as expected

Repro code

public class Application {

    public static void main(String[] args) throws SQLException {
        String url = "jdbc:sqlserver://**************************-**************************.datawarehouse.fabric.microsoft.com;authentication=ActiveDirectoryServicePrincipal";
        String clientId = "clientId";
        String clientSecret = "clientSecret";
        String invalidClientSecret = "invalidClientSecret";

        try (Connection connection = DriverManager.getConnection(url, clientId, clientSecret);
             Connection invalidConnection = DriverManager.getConnection(url, clientId, invalidClientSecret)) {
        }
    }
}

[tkyc]

I reached out to the MSAL4J project to get their insight on the topic.

AzureAD/microsoft-authentication-library-for-java#787

[tkyc]

This is expected behaviour from MSAL. You can refer to the MSAL thread above for the detailed explanation. It's still up to debate whether we want to fail subsequent connections ourselves within the driver (since MSAL doesn't). I'm of the opinion that it's fine as right now an invalid secret will fail next validity check once the cached token expires.

[malkaviancz]

This still feels wrong to me, so if my app has 2 users trying to connect to the same database using client credentials, there could be cases where the second user gets access without entering the correct client secret?
Is there a way to disable this caching behavior?

[tkyc]

It doesn't look like it's possible to disable the cache. I'll discuss this more with the team to see the direction that we'd want to take.

[David-Engel]

FWIW, in the SqlClient library, we something similar to what the MSAL team commented. We cache a hash of passwords for AAD Password auth. If a new password is used, we don't try to get a token silently. We should do the same in the JDBC driver for AAD Password and AAD SP Secret. MSAL's behavior is appropriate for single-user apps, but not for us, since we might be in a multi-user/tenant environment.

[tkyc]

Hm, I was too quick to judge since the behaviour was from MSAL. I'll make the necessary changes.