[Bug] Broker implementation does not fill out token metadata. Resulting in new token acquisition on each call.

[kristofferpeterhansel]

Library version used

msal4j 1.24.1, msal4j-brokers 1.0.0, javamsalruntime 0.17.4

Java version

11.0.31

Scenario

Other - please specify

Is this a new or an existing app?

This is a new app or experiment

Issue description and reproduction steps

Integrating MSAL4J in a Eclipse RCP-based application running on Windows. We use the broker for the most convenient user experience. As we in our setup can do entirely silent token acquisitions.

However when investigating a large number of threads in the application. I discovered that this integration has some issues.

From what I can tell every call to get acquire a token will result in at least one new thread being created and sitting around idle until the application is closed. Leaving threads like this around:

"Thread-262" #311 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=136.63s tid=0x0000000024ded000 nid=0x6ec in Object.wait()  [0x000000002c6ff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@11.0.31/Native Method)
        - waiting on <no object reference available>
        at java.lang.ref.ReferenceQueue.remove(java.base@11.0.31/Unknown Source)
        - waiting to re-lock in wait() <0x0000000080447818> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@11.0.31/Unknown Source)
        at com.microsoft.azure.javamsalruntime.HandleBase$HandleFinalizerThread.run(HandleBase.java:265)

"Thread-263" #312 daemon prio=5 os_prio=0 cpu=0.00ms elapsed=136.63s tid=0x0000000024dea800 nid=0x4254 in Object.wait()  [0x000000002c7ff000]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(java.base@11.0.31/Native Method)
        - waiting on <no object reference available>
        at java.lang.ref.ReferenceQueue.remove(java.base@11.0.31/Unknown Source)
        - waiting to re-lock in wait() <0x0000000080448080> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(java.base@11.0.31/Unknown Source)
        at com.microsoft.azure.javamsalruntime.HandleBase$HandleFinalizerThread.run(HandleBase.java:265)

This issue is somewhat compounded by a flaw where it seems the token information is not available for tokens retrieved this way. Meaning data like the expiration date is null. And from what I can tell, that results in the internal token cache of the library always failing and acquiring a new one each time.

Relevant code snippets

Broker broker = new Broker.Builder().supportWindows(true).build();
PublicClientApplication pca = PublicClientApplication.builder(config.clientID)
      .authority(config.tenantID).broker(broker).build();

SilentParameters silentParameters = SilentParameters.builder(config.scopes).build();
IAuthenticationResult result = pca.acquireTokenSilently(silentParameters).join()

Expected behavior

Tokens are reused until they expire. And the number of threads does not go up with each token acquisition.

Identity provider

Microsoft Entra ID (Work and School accounts and Personal Microsoft accounts)

Regression

No response

Solution and workarounds

With javamsalruntime seemingly not being open source. Actual solutions are hard to come by.

By current workaround it that I guard calls to MSAL4J with my own cache. Based on parsing the expiration date out of the token in our own code.

[gterminator]

this is nothing related to this repository isnt it?

[kristofferpeterhansel]

It is about using MSAL4J with the broker. How would it not be related to this repository?

I would assume the issue I am seeing is somewhere between msal4j-brokers and javamsalruntime.

[gterminator]

It is about using MSAL4J with the broker. How would it not be related to this repository?

I would assume the issue I am seeing is somewhere between msal4j-brokers and javamsalruntime.

because i cannot change any code here in this repository to solve it.

I mean you said it yourself. There is some other dependencies (javamsalruntime) have this problem.

I couldn't reproduce it myself.
Kristoffer Peterhänsel (@kristofferpeterhansel) I will try it this evening again, but it just looks like that there is some problem with threading of the runtime dependency (We are not handling any threads in this repo, we are just using some interfaces e.g. some HttpClient)

[kristofferpeterhansel]

Right. There is a good chance it is in javamsalruntime changes need to happen.

Think there is any change anyone from Microsoft is going to look at this? Or is there another place this sort of issue can be reported?

[gterminator]

Right. There is a good chance it is in javamsalruntime changes need to happen.

Think there is any change anyone from Microsoft is going to look at this? Or is there another place this sort of issue can be reported?

I'm not working at microsoft.

Avery-Dunn can you help?

[kristofferpeterhansel]

I'm not working at microsoft.

That much was clear. Hence the question ;)