SharedTokenCacheCredential takes an optional AuthenticationRecord

[chlowell]

This enables users who want to authenticate silently only to initialize the credential with an AuthenticationRecord from a prior authentication. Closes #11448.

[xiangyan99]

Why not from ..__auth_record?

[chlowell]

It's a public class, and I don't want to depend on its internal location.

[xiangyan99]

I don't see we have normalize_authority(authority) in ctor of AuthenticationRecord. So maybe we need it here

[chlowell]

Accounts in MSAL's cache don't have "normalized" authorities, so neither does AuthenticationRecord. This credential's client will normalize the authority it's given.

[xiangyan99]

I expect w/ or w/o auth_record, we should have same behavior here as

environment = urlparse(self._authority).netloc
self._environment_aliases = KNOWN_ALIASES.get(environment) or frozenset((environment,))
?

[chlowell]

Good eye. We don't need to parse the netloc out of the record's authority because the record's authority is already a netloc. As for why I'm ignoring potential aliases: the purpose of the record is to enable an application to use tokens it cached in prior authentications. An AuthenticationRecord and the account it represents will have identical values for authority because they're both results of the same authentication. An account having an alias of the record's authority was cached during a different authentication, and therefore doesn't match the record.

[xiangyan99]

Do we need try catch here? if it is an invalid auth_record, what's our expected behavior?

[xiangyan99]

I mean if it is invalid, we want to raise ValueError or CredentialUnavailableError or ignore it?

[chlowell]

You mean if self._auth_record.home_account_id raises AttributeError? In that case self._auth_record isn't an AuthenticationRecord. Handling that exception seems tantamount to an isinstance check.

[schaabs]

If we're using the Azure CLI client id I believe we should be defaulting to the organizations endpoint rather than common.

[chlowell]

I kept common to maintain the existing behavior. That was probably too conservative given I don't know a scenario the change would break. So, I've switched to organizations.