Tagged jwt
3 entries carry the tag jwt, 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.
- 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.