Open bgavrilMS opened 7 months ago
Agreed with the bump of MSAL Py version of course. Yes, with AKV, the token from the AKV specific identity provider is read from a file. Not sure why it was designed like this, but it's besides the point.
I do not understand your point about MI. There are 2 types of FIC:
For 1, we have no way of understanding the lifetime of the token from the external IdP. Not sure we assume it's valid for 1h, I think in AKV case it might be, but in general case it is not. Have a look at the .NET implementation - https://github.com/Azure/azure-workload-identity/blob/main/examples/msal-net/akvdotnet/TokenCredential.cs#L33 - notice how the assertion is not read once and fed to MSAL. Instead, MSAL is fed a callback (a function pointer) which is invoked every time it needs to make the client_credentials flow.
Thanks for clarifying the "(1) federation with external IdP (such as AKV)" and "(2) federation with AAD".
Now I realize that my experiment in my previous message was only good for "(2) federation with AAD". Even so, it seems still valuable to have that syntactic sugar, which was not that straightforward to write and test on-the-fly. It even hides the api://AzureADTokenExchange
detail.
That syntactic sugar probably won't help in scenario "(1) federation with external IdP (such as AKV)". But then it won't make it any worse. In that sense, perhaps it is still OK to keep the ConfidentialClientApplication("client_id", client_credential=SystemManagedIdentity())
usage.
With regard to the file I/O, it is probably insignificant here, because the acquire_token_for_client(["scope"])
will already cache the token for up to the token lifetime. The file I/O will only occur when the token expires.
Great, if file I/O happens when token expires, this is perfect. With some MSALs (.NET in particular) we had to make some changes to accommodate this - i.e. MSAL used to accept user assertion as a string only, but then we added a callback option, so that the app developer can provide a fresh user assertion whenever MSAL needs it.
A new PR was created in that repo.
Perhaps we can close this issue here, and follow up subsequent conversation there?
Investigation result:
acquire_token_for_client()
automatically utilizes token cache. So, that sub-optimal sample becomes acceptable now. (That being said, I'll still send out a PR there to at least bump MSAL Python's version. Currently it unnecessarily pinned to MSAL Python 1.22.)This new pattern automatically takes care of obtaining a new federated JWT on the fly, and cache it for 1 hour. No need to fiddle with an extra file. If you are also OK with that, we can ship it in end-of-March release, and then update the workload identity sample accordingly.