[Question] Token cache returns unintended auth token

[tkyc]

Hello, I just want to clarify the following scenario for the mssql-jdbc driver:

            IClientCredential credential = ClientCredentialFactory.createFromSecret(entraPrincipalSecret);
            ConfidentialClientApplication clientApplication = ConfidentialClientApplication
                    .builder(aadPrincipalID, credential).executorService(executorService)
                    .setTokenCacheAccessAspect(PersistentTokenCacheAccessAspect.getInstance())
                    .authority(fedAuthInfo.stsurl).build();

So, in the above code for the mssql-jdbc driver, we use the persistent token cache to cache the auth token. If the driver makes a successful initial connection using a valid initial entra principal service ID and entra principal secret, an auth token is appropriately cached. However, for example, on a subsequent connection after the first, if I use a valid entra principal service ID, but an invalid entra principal secret I successfully auth because of the prior cached auth token. Is this scenario expected? I assume because the entra principal secret has changed, should the token in the cache be invalidated and so in my described scenario I should fail in subsequent connections?

Example below to further to clarify:

1. Use valid entra principal service ID and entra principal secret in auth
2. Successfully auth, and cache auth token,
3. Attempt a subsequent auth with a valid entra principal service ID, but invalid entra principal secret
4. Successfully auth because of prior cached auth token even though an invalid entra principal secret was set

For step 4, is this expected? I expected since the secret changed, the token in the cache should be invalidated and so the auth should fail.

[bgavrilMS]

This is the expected behavior indeed. MSAL libraries do not associate credentails (e.g. secret) and tokens. Once a client has obtained a token, it can use it for its lifetime. Credentials are only checked by the STS for validity.

This is important because the lifetime of credentials can be lower than the lifetime of tokens. There are cases where credentials are rotated every 30 min, but tokens are valid 24h +.. Clients should not make new requests to the STS just because the credentials have been rotated.

From our point of view, if a client managed to get a token, it can anyway cache it on its own and reuse it, so there's no security in associating a token with a cred.

If you need to create this association yourself, then we recommend that you maintain a map of [secret] -> [confidential_client_application] objects. Make sure the CCA objects do not point to the same cache of course.

[tkyc]

Thanks for the clear explanation. This ticket can be closed.