search

Azure / azure-sdk-for-net

This repository is for active development of the Azure SDK for .NET. For consumers of the SDK we recommend visiting our public developer docs at https://learn.microsoft.com/dotnet/azure/ or our versioned developer docs at https://azure.github.io/azure-sdk-for-net.
MIT License
5.36k stars 4.71k forks source link

ClientModel: Add cloud-agnostics OAuth credential to System.ClientModel #42852

Open annelo-msft opened 6 months ago

annelo-msft commented 6 months ago

At a first-pass, this would be a type analogous to TokenCredential in Azure.Core.

This issue represents:

  1. the work to understand the requirements coming from TypeSpec,
    1. understand prior-art in Azure.Core and how much would need to be duplicated in ClientModel/could be reused by the Azure.Core type wrapping or otherwise leveraging the new ClientModel type
    2. what would be needed to update the generator to generate clients that would use this credential type
    3. work with the generator team to find a solution that minimized the costs to update the generator to support this feature e2e as part of the "unbranded toolchain"
  2. the work to implement the feature in ClientModel and track resolution for other parts necessary to fully support this out of the box for clients generated from TypeSpec.

One known requirement today is, per @tg-msft, the ClientModel type should be something we can use with DefaultAzureCredential.

annelo-msft commented 6 months ago

Additional context from @tg-msft - possibly slightly out of date but added to help with compiling requirements:

[In System.ClientModel...] Our TokenCredential base class will also "move" into System.* and then we'll have new options to pass DefaultAzureCredential into libraries with no Azure dependencies. Ideally we can work with 3rd party libraries to support the new System.*.Credential directly. Failing that, we can wrap the glue code to map a System.*.Credential into a connection string in the Aspire Component - and maybe also experiment with different ways to automatically refresh tokens on a library by library basis. Azure customers will have to add Azure.Identity separately to use with a 3rd party Aspire Component and we'd have to explore how the config would light up, but we could iterate on that until we have a clean end-to-end story.

Here's our thinking on how to best expose Managed Identity in Aspire Components:

  • We should still just include Azure.Identity for any Aspire Components for Azure services
  • We should try to align the 3rd party Aspire Component story around the upcoming System.*.Credential either directly in the original 3rd party library or via our Aspire Component wrapping it
  • If schedules don't align, we could start with an imperfect ServiceConnector story today that we additively extend to support System.*.Credential shortly after.