Change default auth provider to `AppService` from `StaticWebApps`

[JerryNixon]

Ensure AppService is identical to StaticWebApp

The goal is to ensure AppService is identical to StaticWebApp because we want to stop using StaticWebApp and start using AppService.

data-api-builder/src/Config/ObjectModel/EasyAuthType.cs

Lines 6 to 10 in ebbe989

	public enum EasyAuthType
	{
	StaticWebApps,
	AppService
	}

⚠️ None of this should be done if they are not identical.

Modify the Engine default references to StaticWebApps

These references are scattered throughout the codebase. We're shifting to AppService as the default, so wherever StaticWebApps appears in code or comments, it should be updated. We're not removing support for StaticWebApps, just removing it as the default.

Comment example:

data-api-builder/src/Config/ObjectModel/AuthenticationOptions.cs

Line 9 in ebbe989

/// <param name="Provider">Identity Provider. Default is StaticWebApps.

Code example:

data-api-builder/src/Config/ObjectModel/AuthenticationOptions.cs

Line 14 in ebbe989

public record AuthenticationOptions(string Provider = nameof(EasyAuthType.StaticWebApps), JwtOptions? Jwt = null)

Modify the CLI default references to StaticWebApps

This primarily applies to dab init. The goal is to ensure the CLI no longer defaults to StaticWebApps as the auth provider but to AppService. Users can still configure StaticWebApps, but they must do so manually.

Modify the JSON Schema

Update the schema to change the default value to AppService.

data-api-builder/schemas/dab.draft.schema.json

Lines 275 to 283 in ebbe989

	"authentication": {
	"type": ["object", "null"],
	"additionalProperties": false,
	"properties": {
	"provider": {
	"type": "string",
	"description": "The name of authentication provider",
	"default": "StaticWebApps"
	},

Also update the schema to restrict the provider property to only supported values (including StaticWebApps).

Modify DAB Validate

Update ValidateAuthenticationOptions to log a warning if the runtime host is set to StaticWebApps.

if (Enum.TryParse<EasyAuthType>(runtimeConfig.Runtime.Host.Authentication.Provider, ignoreCase: true, out var provider) &&
    provider == EasyAuthType.StaticWebApps)
{
    _logger.LogWarning("The 'StaticWebApps' authentication provider is deprecated.");
}

data-api-builder/src/Core/Configurations/RuntimeConfigValidator.cs

Line 713 in ebbe989

private void ValidateAuthenticationOptions(RuntimeConfig runtimeConfig)

Modify DAB Init

Ensure dab init generates a config functionally identical to before. However, the default provider should now be AppService instead of StaticWebApps.

data-api-builder/src/Cli/Commands/InitOptions.cs

Lines 91 to 92 in ebbe989

	[Option("auth.provider", Default = "StaticWebApps", Required = false, HelpText = "Specify the Identity Provider.")]
	public string AuthenticationProvider { get; }

[JerryNixon]

I asked Copilot if they were identical.

Based on the analysis of the codebase, both StaticWebApps and AppService authentication providers are implemented with similar logic. Here's a summary of the key points:

Key Files and Logic

1. Parsing Logic:

   • StaticWebApps: Defined in StaticWebAppsAuthentication.cs.
   • AppService: Defined in AppServiceAuthentication.cs.
   • Both handle the x-ms-client-principal header, decode it, and create a ClaimsIdentity.

2. Authentication Setup:

   • EasyAuthAuthenticationBuilderExtensions.cs: Adds schemes for both StaticWebApps and AppService using similar logic.

3. Core Authentication Handling:

   • EasyAuthAuthenticationHandler.cs: Processes authentication metadata for both StaticWebApps and AppService.
   • Uses a switch statement to call the appropriate parsing method based on the EasyAuthType.

4. Configuration and Defaults:

   • AuthenticationOptions.cs: Configures the default provider and related settings.
   • dab.draft.schema.json: Defines the schema for configuration, defaulting to StaticWebApps.

Conclusion

Switching the default auth provider from StaticWebApps to AppService should not result in different behavior since the implementation logic for both providers is identical. The parsing, authentication setup, and core authentication handling are all designed to handle both providers equivalently.

View More Results

If you need to review more details, you can view the full files and additional results on GitHub:

• StaticWebAppsAuthentication.cs
• AppServiceAuthentication.cs

Thus, changing the configuration to use AppService as the auth provider should have no impact on the engine's behavior.

This is just a starter, don't trust it.

[sander1095]

Also update the schema to restrict the provider property to only supported values (including StaticWebApps).

I created an issue for this in #2643, and just created a PR for it, too: #2646 . I vote to remove this sentence from this issue as this is already done when that PR is merged.

[sander1095]

@JerryNixon Can more information be provided on the reason for deprecating SWA auth? If someone chooses to host DAB in SWA, it makes sense (to me) to have the developer choose SWA as the auth provider, instead of App Service.

Also, SWA has DAB integration, whereas app Service does not. Currently it makes sense to have SWA as the default because of this integration. What is the reason for making app service the default?

---

Also, I am pretty sure there are small behavioral differences because of different auth handlers in code. Take a look at my comments in #2610 for more info.

[JerryNixon]

A key step to this task is to validate what if any difference there are between the two types.