Is it possible to provide test data to create a ConfidentialClientApplication and to acquire_token_for_client?

[jacotcher]

I am working on a project where we need to authenticate against someone else's Azure AD app. We don't use Azure ourselves.

I am creating a ConfidentialClientApplication and setting the 'verify=False' and 'validate_authority=False' parameters, and am hoping to provide fake data (authority, client_id, scopes etc) to be able to use the MSAL library to connect to our mock version of the external service that we are connecting to.
I am having a lot of issues with this, the library seems to be tied to Microsoft and makes unavoidable verification calls or validations which is stopping me from being able to point the library at my mock service. If we can't do this, then I won't be able to mock the flow of MSAL and we won't be able to use it.

Am I missing something, or is this a limitation of the library?

Thank you

[rayluo]

Interesting. Within its first 18 hours, this question received 4 upvotes. Are the other 3 voters your relatives, James?

Joking aside, the verify and validate_authority parameters are documented and they are not for the purpose that you described.

What you want seems to be one of two different things.

1. to provide test data to create a ConfidentialClientApplication and to acquire_token_for_client?

If you want to mock the token acquisition requests, you shall look into Python's built-in mock library. We use it in some of our own unit tests, too. That being said, I do not even think mock is the most convenient way to approach this. If your project will eventually authenticate against AAD using real authority, client_id, scopes, etc., you might as well just create your own AAD test account, for free.

2. working on a project where we need to authenticate against someone else's Azure AD app. We don't use Azure ourselves.

Not sure what that means. If that someone's app - for example a web api - is already in AAD's ecosystem, it would probably expect its consumers to also be another entity in AAD, in order to let the whole user consent mechanism to work.

If, on the other hand, you are really developing a project to auth against a 3rd-party identity provider, then MSAL (Microsoft Authentication Library) does not currently support it, as explained in the first sentence in our repo's README.