[Identity] Explicitly implement TokenCredential protocol

[mccoyp]

Description

Resolves #25175. Per PEP 544, explicitly declaring protocol implementations is discouraged -- as it shouldn't be necessary -- but allowed. Our credentials are structural subtypes of the TokenCredential protocol (as shown by successful isinstance checks enabled by #25187), but PyCharm's third-party type checker still warns that credentials such as DefaultAzureCredential aren't TokenCredentials. Explicitly subtyping the protocol fixes this.

Technically, PyCharm raises these warnings because its type checker is more aggressive than isinstance; to completely implement the TokenCredential protocol's get_token spec, all credential get_token methods need to include claims and tenant_id in their signatures. This probably isn't the solution we want, as we don't actually support these keyword arguments in all credentials due to environment constraints (for example, we can't specify a tenant_id in managed identity authentication).

To choose which credentials to update, I provided each credential type in azure-identity to a Key Vault client and updated those that raised the warning described in #25175.

This also bumps the minimum version of azure-core to 1.23.1, which was the first version of the package to expose the TokenCredential type outside of TYPE_CHECKING.

All SDK Contribution checklist:

• The pull request does not introduce [breaking changes]
• CHANGELOG is updated for new features, bug fixes or other significant changes.
• I have read the contribution guidelines.

General Guidelines and Best Practices

• Title of the pull request is clear and informative.
• There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

• Pull request includes test coverage for the included changes.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

azure-identity

[lmazuel]

Should not be needed anymore now that runtimeChecklable has been puclished

[mccoyp]

Reopening -- runtime_checkable allowed us to perform isinstance checks with the protocol, but it didn't solve our PyCharm typing issue. The description for this PR has more details.

[mccoyp]

@xiangyan99 what do you think of this approach? Adding claims and tenant_id kwargs to the signatures of all get_token methods doesn't make sense to me, since we don't actually honor those arguments in some credentials. So I think explicitly declaring the implementation is our only real option for resolving PyCharm type warnings

[ghost]

Hi @mccoyp. Thank you for your interest in helping to improve the Azure SDK experience and for your contribution. We've noticed that there hasn't been recent engagement on this pull request. If this is still an active work stream, please let us know by pushing some changes or leaving a comment. Otherwise, we'll close this out in 7 days.

[xiangyan99]

Let's not force users to upgrade azure-core. We can use try import catch instead?

[mccoyp]

This was motivated by the TokenCredential import, but that may not actually be necessary. I talked this over with Laurent, and he feels that the best solution would be to actually match the method signatures of the protocol; i.e. document kwargs like claims even if they wouldn't have an effect for a particular credential. I think this does make sense, since it makes the capabilities and limitations of each credential more explicit and more correctly implements the protocol.

I want to first check what pyright thinks of this PR's approach. If explicit subtyping without full implementation raises errors with pyright anyway, then this approach won't be viable regardless and would make the choice easier to make (unless you agree that we should go for the full implementation route regardless).

[mccoyp]

Closing in favor of a new PR that will adjust Identity credential type signatures to match the protocol definition.