Reducing the cost of building a ClientApplication

[aukeschaap]

Context

I am building a web app that logs a user in and that then accesses a protected web api. I have found that building a ConfidentialClientApplication is costly. Due to tenant discovery, atleast one get request is sent. This means that acquiring a token from the cache incurs this same cost.

Ideally you would build the ClientApplication once, and reuse it. There is, however, some (standard) overhead involved:

• The token cache is unique for each session, and hence the CCA.
• The application might be threaded (in my case it is).

The documentation offers no information on how to address these scenarios, especially now that the move to identity has been initiated. The only relevant information I found was: a comment in the code suggesting the CCA should be "long-lived", a mention in the new identity documentation that the instance is expected to be long-lived.

Questions

I hope you could clarify the following things in the documentation, for me and future developers:

• How long is "long-lived"? A minute, hour, day, or even longer?
• How to create a long-lived, session unique CCA? Specifically, how new requests can use the same CCA.
• What issues arise when using a threaded server in combination with a TokenCache
• How (or if) these threading issues can be avoided

I have done a lot of digging myself, and can identify some threading issues, but it would be nice to include them in the documentation.

Lastly, there is also the question of async support. I see that this issue tracks the progress already, so I have excluded that from this discussion.

[rayluo]

Thanks for your input, Auke. You clearly did your homework. Good job.

How long is "long-lived"? A minute, hour, day, or even longer?

OK, "long-lived" is not about a specific length of time. It is about suggesting you to reuse it. In general, any API that is designed in an Object-Oriented fashion, it kind of implies that you can construct an instance and then reuse it for as long as you possibly can, contrary to a function-based design which is clearly an one-off run for each function call.

How to create a long-lived, session unique CCA? Specifically, how new requests can use the same CCA.

A CCA in the web app context has its unique challenge, indeed. Rather than writing some lengthy how-to documentation (which not necessarily many people would read), we believe it is more efficient to build higher level samples and/or libraries which just implement it precisely right. You can find existing samples from the Scenarios section in MSAL Python documentation, where the blue icons are clickable. The web app sample there is what you need. It works and can be a good starting point for you to understand how it is done.

What issues arise when using a threaded server in combination with a TokenCache
How (or if) these threading issues can be avoided

MSAL Python's token cache implementation already has a built-in threading lock. If you use your own TokenCache implementation, you can fully control threading issues by yourself. With your awareness of threading issues, you would probably do it well.

[aukeschaap]

Thank you for your response, and your clear explanations. I am a documentation reader myself, but you make a strong case. I will do some more digging and experimentation myself!