[azure-identity] `azure-identity` should stop using deprecated `backend` argument in `cryptography`

[jiasli]

• Package Name: azure-identity
• Package Version:
• Operating System:
• Python Version:

Describe the bug
Per

• https://cryptography.io/en/latest/changelog/#v36-0-0
• https://cryptography.io/en/latest/faq/#faq-missing-backend

cryptography stopped requiring the use of backend arguments in version 3.1 and deprecated their use in version 36.0. If you are on an older version that requires these arguments please view the appropriate documentation version or upgrade to the latest release.

Note that for forward compatibility backend is still silently accepted by functions that previously required it, but it is ignored and no longer documented.

Expected behavior
Azure Identity currently requires

azure-sdk-for-python/sdk/identity/azure-identity/setup.py

Line 63 in d840732

"cryptography>=2.5",

and passes backend arguments:

azure-sdk-for-python/sdk/identity/azure-identity/azure/identity/_credentials/certificate.py

Lines 95 to 96 in 07d1063

	private_key = serialization.load_pem_private_key(certificate_data, password, backend=default_backend())
	cert = x509.load_pem_x509_certificate(certificate_data, default_backend())

but the best practice is to bump cryptography to newer version and stop using deprecated backend argument.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member best able to assist.

[xiangyan99]

To help me understand better, what is the benefit for this?

It seems to me the impact is we stop allowing users to use cryptography 2.5.

[jiasli]

To help me understand better, what is the benefit for this?

There is no immediate benefit, but it avoids being broken by cryptography when backend is totally removed.

This issue is merely a tracker. There is no action item currently.

[rayluo]

To help me understand better, what is the benefit for this?

There is no immediate benefit, but it avoids being broken by cryptography when backend is totally removed.

This issue is merely a tracker. There is no action item currently.

FWIW, I also feel @xiangyan99 's reluctance to "the impact is we stop allowing users to use cryptography 2.5".

Besides, crytography does not use semantic versioning, so, there is no obvious way for a mid-tier/downstream library to guard against a potential breaking change.

I end up with a complicated mechanism of wrapping most of MSAL's cryptography usage into a helper function, and then have a unit test case to call that helper. If that test case fails someday, we will know we hit the breaking change.