[Feature Request] Client capabilities support

[henrik-me]

Smart Session Management (SSM) sometimes referred to as the long lived tokens (LLT) scenario require MSAL to allow developers to resolve challenges (formatted as claims request parameters) to be resolved silently rather than interactively. Current releases of MSAL assume that interaction is required whenever a claims request parameter is included in the request.

This change in behavior requires the client to indicate that it's aware of a new calling pattern relative to the use of MSAL.

See additional details of requirements in:
AzureAD/microsoft-authentication-library-for-dotnet#1545

API/Design details:
https://identitydivision.visualstudio.com/DevEx/_git/AuthLibrariesApiReview?path=%2FClientCapabilities%2Foverview.md&version=GBdev
Is your feature request related to a problem? Please describe.

Related internal work item:
https://identitydivision.visualstudio.com/Engineering/_workitems/edit/824806

[rayluo]

Self-note from recent research:

• Happen to notice that a related internal work item for MSAL Python was marked as "declined". But I guess we are now still planning to implement this.

• Per API Design/Review conclusion, "Client Capability" is about the requirements below, Nothing more. Nothing less.

  1. class ClientApplication constructor accepting a list of arbitrary strings provided by caller.
     (Note: So that the CP1 magic string (more on this later) should be provided by caller, rather than hardcoded inside MSAL.)

  2. wrap them inside claims parameter, like this: {"accessToken":{"xms_cc": ["CP1"]}}

  3. merge it with the actual claims parameter (if any),

  4. now send them to authorize and token endpoint.

• Client Capability and another feature named "Claims Challenge (this doc contains a diagram)" can be used separately or in combination. Claims Challenge is in term used to implement CAE (Continuous Access Evaluation).
  The Claims Challenge document mentions 2 different claims format could be emitted from resource, one with base64 encoding, one without.
  Would need to double check during our implementation and testing phrase. MSAL would accept only non-base64-encoded content. Quoted from the same design doc:

  Client to STS scenarios
  Note that in all scenarios, the JSON payload is sent to the server, not the Base 64 encoded payload. Clients must Base-64 decode the payload in the claims challenge header prior to sending the claims request to the STS. The ADAL/MSAL/WAM APIs expect non-base-64 encoded content to be passed in for the claims request.

• MSAL would need to accept a new claims parameter for all acquire_token methods, including acquire_token_silent(). In acquire_token_silent(..., claims=..., ...), it should bypass AT cache (but not RT cache) when claims parameter presents, i.e. treat the existence of claims parameter as if force_refresh=True. See also this conversation.

• There is yet another scenario of CAE, that is CAE for Web App which mainly uses ID token for authentication. So MSAL would also need to follow the summary at the end of this "SSM Web apps" design doc to have similar merge logic for "id_token".
  UPDATE at 2020-8: It is not yet clear whether the "client capability in an id_token" is needed, so our implementation this time will not bring this behavior to id_token.