Improve .NET 7 JWT Bearer appsettings configuration doco

[laurencee]

Fixes #29307

In real world usage, you usually have a token-issuing server. To validate tokens, you must specify the Authority property in the authentication scheme, so instructions for how to do this has been added to the documentation.

---

Internal previews

📄 File	🔗 Preview link
aspnetcore/fundamentals/minimal-apis/security.md	Authentication and authorization in minimal APIs

[laurencee]

@dotnet-policy-service agree

[guardrex]

Thanks @laurencee! 🚀

We have an INCLUDE that explains how to change the release branch for reference source main branch references. I don't recommend a line number (or range of lines), as the product code churns quite a bit making them rather unstable and prone to break 😈.

[captainsafia]

The JSON-based configuration option are design to be used in conjunction with the user-jwts CLI tool. I would not recommend using them at all for production environments. You should be able to configure this properties on the AddJwtBearer method invocation.

[laurencee]

@captainsafia That's quite a shame if that's the case. 😞

From my reading, there's nothing in this current documentation that indicates this appsettings configuration approach shouldn't be used for production purpose, in fact it reads as the opposite to me right now which is why I posted the issue and this PR in the first place as it looks like an official guide on "how to do authentication with minimal apis".

So, to make the documentation clear, there should be a pretty big disclaimer that this configuration approach is not for production purposes?

For me, this configuration approach would be the preferred way to configure these standard forms of authentication, so it's quite a shame if the only current purpose for this is demo/sample code. It would have trimmed down unnecessary duplication across numerous projects for setting JWT Bearer options and Authentication options in app service configuration code (creating a custom options class and hooking that to the method invocations).

Out of interest, what would you say is the main reason this shouldn't be used in a production setting? I don't see anything obvious in the way the JWT Bearer options are wired up that connects it to the tooling when looking at your JwtBearerConfigureOptions implementation.

I tested it out myself in a test environment and the auth flow all worked as I expected with a 3rd party JWT provider.

[captainsafia]

@laurencee So, in .NET 7, we introduced the notion of "config-based authentication options" for some authentication models (see this issue).

In development scenarios, the the framework already handles populating the signing key information correctly (when used in conjunction with the dotnet user-jwts tool) so the recommendation to include this configuration manually is incorrect.

It's acceptable to use the same config-based strategy in production apps, although I don't think here is the right place to document those configuration options. Technically, anything that you would put in your JwtBearerOptions you can pass through configuration in your appsettings (or likely a more secure configuration strategy when in production).