Find ways to minimize the effort required to configure authz in an HTTP API by 30%

[This item was copied from the planning repo]

Through Cu, work with partners in AAD and internally within ASP.NET to collaborate on user research and experience measurement to find ways we can ease the burden of configuring popular auth providers like Microsoft Identity Platform or and 2 popular 3rd party providers.

Specifically concentrate on easing the friction and effort (keystrokes, clicks, and internet searches required) for one or all of the following scenarios:

- [ ] Given a Swashbuckle-enabled Web or Minimal API project, add support for authenticating the user on the Swagger UI page.
- [ ] Adding authz to an existing ASP.NET Core API so that it can be called only from an authenticated client.
- [ ] Assessing if we need to add support for the OAuth2 endpoints for Twitter (our docs specifically call out that a 3rd party NuGet package can be used for this, but that package fails to work with ASP.NET Core identity, so customers who want to support Twitter auth are in a broken state; they lack support for the OAuth2 features with our provider but can't authenticate customers with the OSS provider.
- [ ] Asses how many of the authz-related docs specific to social or 3rd-party auth providers in our ASP.NET Core Identity docs section can be completed by PMs on the team according to the docs in [this TOC node](https://docs.microsoft.com/en-us/aspnet/core/security/authentication/social/?view=aspnetcore-6.0&tabs=visual-studio) and establish a content plan, if needed, for resolving hurdles in the experience.

As we improve the scenario with product work, we should accompany that product work with documentation for our testing team so the experience of configuring auth for these key scenarios can be tested repeatedly and so we know when service or API changes result in our needing to update the docs or the experience.