Tagged dotnet
6 entries carry the tag dotnet, newest first. All tags.
- How do I add a second JWT bearer authentication scheme to an ASP.NET Core API without it conflicting with the existing one?
Register each handler under its own scheme name, `AddJwtBearer("Legacy", ...)` and `AddMicrosoftIdentityWebApi(config, jwtBearerScheme: "EntraId")`; two unnamed ones both default to `"Bearer"` and throw on startup. Pick a scheme per request with `[Authorize(AuthenticationSchemes = "Legacy,EntraId")]`, or automatically via `AddPolicyScheme`'s `ForwardDefaultSelector`, reading the token's unvalidated `iss` claim. Either way each scheme still fully validates the token itself; the selector only routes, it never authenticates.
- How do I validate Microsoft Entra ID access tokens on the server to protect an API?
Register JWT bearer auth with the tenant's Authority and Audience (`AddMicrosoftIdentityWebApi`, or `AddJwtBearer`): it fetches Entra's keys and checks signature, issuer, audience and expiry before any handler runs. A valid signature only proves Entra ID issued the token, not that it targets this API - check the audience, and require a scope or app role with `[Authorize]` plus a permission check. Never decode a bearer token by hand and trust its claims: an unvalidated token is only as trustworthy as a header the caller typed in.
- How do I attach a bearer token to every HttpClient request with a DelegatingHandler?
Override `SendAsync` in a `DelegatingHandler` subclass to set `request.Headers.Authorization`, register the handler `Transient`, and chain `.AddHttpMessageHandler<TheHandler>()` onto the client's `AddHttpClient(...)` registration - never set the header on the client itself.
- What is the right way to authenticate a .NET desktop client against an API that issues JWTs?
Run OAuth 2.0 Authorization Code with PKCE in the system browser, not an embedded WebView, landing the callback on a loopback address or a registered custom URI scheme, rather than collecting the password in app code. Store the access and refresh tokens in the OS credential store (DPAPI-backed on Windows), never in a config file. Treat the JWT as an opaque bearer token the client attaches to requests but never decodes to decide what the user may do.
- What project structure fits a WPF app that calls a REST API with CommunityToolkit.Mvvm?
One project, folders by role - Models, ViewModels, Views, Services (the API client behind an interface) - wired up with the .NET Generic Host in `App.xaml.cs`: it builds the DI container, registers a typed `HttpClient` for the API and the windows/view models, and resolves `MainWindow` from it instead of `StartupUri`.
- Should a WPF app use an MVVM framework, or is plain WPF and modern C# enough?
Use one: CommunityToolkit.Mvvm for the boilerplate (property-changed notification, commands) via source generators, plus Prism if the app also needs region-based navigation or a module system. Prism's DI container is not the reason to add it: the .NET Generic Host gives any WPF app a DI container on its own, and Prism 9's own container is dual-licensed, free only below a revenue or a funding threshold. Modern C# removed the reason to write `INotifyPropertyChanged` by hand, not the value of not writing it.