Should we include an additional interface to include 'sync' secret retrievals?

[stijnmoreels]

Explain the problem/feature you want to have:
Right now, all our ISecretProvider implementations and dependent interfaces uses this asynchronous paradigm to retrieve secrets. In some cases though, like User Secrets, Environment Variables, Docker Secrets..., where there's no external dependency involved, the secret can be retrieved synchronous. This is only 'hidden' behind the asynchronous wall (which is a good thing!).

In some cases though, like when registering the JWT authorization and you request the security token, or you want the instrumentation key of your Application Insights instance... you're stuck with a asynchronous system in a synchronous startup method. It would be cleaner if we introduce an additional interface for the ISecretProvider which synchronously retrieves the secret so when you want to get the instrumentation key, you could do:

public void Configure(IApplicationBuilder app)
{
    var secretStore = app.ApplicationServices.GetRequiredService<ISecretStore>();
    var secretProvider = secretStore.GetProvider<ISecretProviderSync>("EnvironmentVariables");
    string instrumentationKey = secretProvider.GetRawSecret("APPLICATIONINSIGHTS_INSTRUMENTATIONKEY");
}

[tomkerkhove]

Sure, sounds good to me.

Just curious why a new interface instead of adding it? Because of the breaking change?

[stijnmoreels]

Not only breaking change, but also that some providers don't support synchronous calls, so if we create a new interface and only use it where we need, it can be retrieved by their registered name. Sounds good?

[stijnmoreels]

Our in groups, as in #237 .

[tomkerkhove]

Yes