This feature request proposes a mechanism to deliver token acquisition features that are 1p. The reason for this is twofold:
Do not pollute open source 3p libraries with 1p features, until these are ready for 3p
Increase adoption of DownstreamApi, by not exposing features directly in MSAL
How
MSAL
A strongly typed API and a strongly typed processing. For instance for the Federated User Identities, this is a new method, say:
ConfidentialClientApplication.AddAddIn<1pFeatureAddin>(), with this 1pFeatureAddin belonging to a 1P library, and that would implement methods or be a factory of classes that would implement these methods to:
• Extract the parameters from the extension method and store them in a bag
• Understand the parameters from the bag
• Append the body of the request
• Append the headers of the request
• Append the query string of the request
• Retrieve the info from the response
• Create exceptions for the particular request
• Cache the token (if there are particular things to do)
• Add to a bag in the AuthenticationResult (From which it would be queried by an extension method also part of the Add-In package)
• Change API ID
Note: design not finalized here, but an interface or callback will constitute the integration point. Incremental start - expose only what is necessary.
Id.Web
AcquireTokenOptions has a new public property ExtraParameters: IDictionary<string, object> + associated support from config.
The constructor of TokenAcquisition in IdWeb looks for a TokenAcquisitionAddIn, and, when building the request for AcquireTokenForClient, calls the AddIn method with the AcquireTokenOptions and the AcquireTokenForClientParameterBuilder. The AddIn checks if the tokenAcquisitionOptions.ExtraParameters constains constraints, and if it does, it uses the MSAL methods (or extension methods) to pass-in the constraints.
Not needed in the case of CDT, but the Id.Web add-in could also work on the AuthenticationResult
What
This feature request proposes a mechanism to deliver token acquisition features that are 1p. The reason for this is twofold:
DownstreamApi
, by not exposing features directly in MSALHow
MSAL
A strongly typed API and a strongly typed processing. For instance for the Federated User Identities, this is a new method, say: ConfidentialClientApplication.AddAddIn<1pFeatureAddin>(), with this 1pFeatureAddin belonging to a 1P library, and that would implement methods or be a factory of classes that would implement these methods to: • Extract the parameters from the extension method and store them in a bag • Understand the parameters from the bag • Append the body of the request • Append the headers of the request • Append the query string of the request • Retrieve the info from the response • Create exceptions for the particular request • Cache the token (if there are particular things to do) • Add to a bag in the AuthenticationResult (From which it would be queried by an extension method also part of the Add-In package) • Change API ID
Note: design not finalized here, but an interface or callback will constitute the integration point. Incremental start - expose only what is necessary.
Id.Web
AcquireTokenOptions has a new public property
ExtraParameters: IDictionary<string, object>
+ associated support from config.MISE
Services.Add1pFeature();
For more details see here