How to secure both Blazer server and api ?

Question

How to secure both Blazer server and api ?

Laurent Guigon 331

Hello,
I need an advice.
I'd like to secure a blazor server app with individual user account. This functionality is embedded with the basic setup, and use cookies.
But I also need to protect my web api with the same way. I know about the JWT, but I don't really know how to implement these.

I thought to create a specific api service dedicated to users and consume this in both the front and back end app since I need to great accesses through roles.

Is some-one have a idea ?
P.S. I've seen some tutorials on Youtube which seem to propose a method.

Laurent Guigon 331 Reputation points

2026-01-21T10:29:45.7533333+00:00

Hello
I should be more specific, my bad.

My goal is to build an application with DDD-based functional separation, following a distributed / microservices-style architecture.At the moment, there is only a single API that contains all the domain-specific business layers. There is no API Gateway for now, mainly due to cost and simplicity constraints at this stage.

I follow DRY and SOLID principles.

Another objective is to fully decouple the front-end from the back-end, so that a new front-end can be implemented later without having to rebuild everything. A mobile application might eventually be developed as well.

Given the current state of the project and my budget, I am considering using a single Azure App Service to host everything (although I am not sure this is feasible).

In my business services, I need to be able to restrict access based on user roles, which is why I initially considered using JWT-based authentication at this level.

However, placing user account management logic inside Blazor Server is problematic for me. I have a unified data access layer designed to manage (eventually) multiple databases using polymorphism and the strategy pattern. As mentioned earlier, my goal is to remain as DRY as possible.

This is why I am looking for the best way to secure both the front-end and the back-end as a coherent whole. Paid solutions are not an option: my total monthly budget is €25–30. And if possible, the more auto-scaffolding provided, the better.

Thank you for your help.

4 answers

Your answer

Laurent Guigon 331 Reputation points

2026-01-21T10:29:45.7533333+00:00

Hello
I should be more specific, my bad.

My goal is to build an application with DDD-based functional separation, following a distributed / microservices-style architecture.At the moment, there is only a single API that contains all the domain-specific business layers. There is no API Gateway for now, mainly due to cost and simplicity constraints at this stage.

I follow DRY and SOLID principles.

Another objective is to fully decouple the front-end from the back-end, so that a new front-end can be implemented later without having to rebuild everything. A mobile application might eventually be developed as well.

Given the current state of the project and my budget, I am considering using a single Azure App Service to host everything (although I am not sure this is feasible).

In my business services, I need to be able to restrict access based on user roles, which is why I initially considered using JWT-based authentication at this level.

However, placing user account management logic inside Blazor Server is problematic for me. I have a unified data access layer designed to manage (eventually) multiple databases using polymorphism and the strategy pattern. As mentioned earlier, my goal is to remain as DRY as possible.

This is why I am looking for the best way to secure both the front-end and the back-end as a coherent whole. Paid solutions are not an option: my total monthly budget is €25–30. And if possible, the more auto-scaffolding provided, the better.

Thank you for your help.

Answer 1

Bruce (SqlWork.com) 84,061

Typically for your scenario you would use oauth instead of individual accounts. This would allow the Blazor server app access to the users refresh and access tokens. The main issue is that Microsoft does not supply a oauth authentication server for individual accounts.you will either need to code one (requires good understanding of oauth security) or use third party like:

https://duendesoftware.com/products/identityserver

Laurent Guigon 331 Reputation points

2026-01-21T10:06:31.5033333+00:00

Hello, Thank you for your answer.
I don't want to pay, so duende is not a viable solution.
Kind regards.

Answer 2

AgaveJoe 31,361

Authentication cookies are the standard for browser-based sessions (like a standard ASP.NET Core MVC or Blazor Server app). JWTs are typically used in distributed scenarios where a remote service needs to trust the client application via a signature, often when the client is a separate SPA or mobile app.

To give you the best advice, we need to know your architectural intentions: Is this Web API shared by other applications?

If the Web API only supports the Blazor Server application: You likely do not need a Web API at all. Since Blazor Server code runs on the server, you can simply inject your logic/data services directly into your components. The user is already authenticated via the standard cookie, so you can handle authorization logic right there in the Blazor app without making an extra HTTP call.

If the Web API is shared between multiple applications: You will need a design change. You need a centralized way for different clients (Blazor, Mobile, etc.) to authenticate and obtain a token. This typically involves using an OpenID Connect provider (a token server) that both the Blazor app and the Web API trust.

If you must call a local API from Blazor Server (sometimes done for consistency), you have to manually copy the authentication cookies from the browser request to the HttpClient request, which is tedious. Direct service injection is much preferred.

Laurent Guigon 331 Reputation points

2026-01-21T10:10:30.4266667+00:00

Hello, thank you for your answer. I've added some comment to my first question to be more specific.
AgaveJoe 31,361 Reputation points

2026-01-21T11:05:26.54+00:00
Thank you for the clarifications. I understand you want to follow DDD, keep options open for a future mobile app, and adhere to a strict budget (€25–30/month) using a single Azure App Service.

However, there is a misunderstanding regarding DRY (Don't Repeat Yourself) and how it applies to Blazor Server architecture.

The "DRY" Misconception You mentioned: "Placing user account management logic inside Blazor Server... [violates] DRY."

This is incorrect. "DRY" refers to not duplicating code or logic, not about physically separating the deployment of that logic into a web service.

The Solution: Move your business logic, data access, and strategy patterns into a Shared Class Library (DLL).

The Implementation: Your Blazor Server app references this DLL and injects the services directly. Your future API (for mobile) references the same DLL and injects the exact same services.

The Result: You have zero code duplication (DRY is satisfied), but you avoid the immense complexity of securing a distributed system over HTTP.

The "Magical Solution" Problem You want a distributed architecture (Microservices style) with a decoupled Front-End/Back-End, but you also want it to be free ("paid solutions are not an option") and easy ("auto-scaffolding").

These requirements are contradictory.

The Security Bottleneck: To decouple the Front-End (Blazor) from the API, you cannot use Cookies alone; you need OAuth/OIDC (Tokens).

The Cost of Free: Microsoft does not provide a free, auto-scaffolded OAuth Authorization Server for "Individual User Accounts."

Duende IdentityServer: The standard solution, but it is paid (as you noted).

OpenIddict: This is the free, open-source alternative. However, it is not auto-scaffolded. It requires a deep understanding of OAuth flows to implement securely.

Azure AD B2C: This has a free tier that might fit your budget, but it externalizes your user accounts, which changes your "Individual User Accounts" requirement.

The Realistic Recommendation Given your budget and the fact that you are hosting on a single App Service:

Option A: The Pragmatic Approach (Recommended) Stick to a Monolith structure for now.

Put all logic in a Shared Service Library.

Let Blazor Server use that library directly (Cookie Auth).

Why? It is secure by default, highly performant (no HTTP overhead), fits your budget, and handles your "Polymorphism/Strategy" requirements via standard Dependency Injection.

Future Proofing: When you actually build the mobile app, you can spin up a simple API project that references that same Service Library and implement JWTs only for that API.

Option B: The "Hard" Way (If you insist on decoupling now) If you absolutely must separate them now, you cannot avoid the complexity. You must implement a Token Service.

Look into OpenIddict to build your own token server (free).

Be warned: This is not "auto-scaffolded" and requires significant effort to secure correctly.

I hope this helps clarify why the community is suggesting direct service injection—it is the most robust path for your specific constraints.
Bruce (SqlWork.com) 84,061 Reputation points

2026-01-23T17:19:44.0666667+00:00

As I stated earlier, there is no out of the box support for oauth and individual accounts. You can certainly code an oauth or jwt token server, but unless you are a security expert it is bound to have security flaws. You can find simple implementations via google, but generally they are not secure.

If you want a separate webapi, you could use https certificates or oauth client secrets for the blazor app to call the webapi. You would pass the user name as a parameter to webapi calls. You could add a custom authentication and role manager for the webapi to fill in the roles.

Answer 3

Varsha Dundigalla(INFOSYS LIMITED) 5,025 Microsoft External Staff

Thanks for reaching out.

Blazor Server apps that use Individual User Accounts already authenticate users with cookies, which is the recommended approach for browser‑based applications. When the Blazor app calls a Web API from the browser, the authentication cookie is automatically sent by the browser with each request, so the API can identify the user and their roles without using JWT. In this setup, the Web API can be secured using the same ASP.NET Core Identity configuration and role‑based authorization, giving one login and one permission model for both the UI and the API. JWT tokens are mainly needed when the API is accessed by non‑browser clients (such as mobile apps, desktop apps, or external services) or when the API is hosted separately and shared publicly. If the API is only meant to be used by the Blazor Server app, cookie‑based authentication is simpler, secure, and aligns with Microsoft’s guidance, and role checks work the same way for pages and API endpoints.

Reference :
How to use Identity to secure a Web API backend for SPAs

ASP.NET Core Blazor authentication and authorization

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

Varsha Dundigalla(INFOSYS LIMITED) 5,025 Reputation points Microsoft External Staff

2026-01-12T14:58:54.8866667+00:00

Hope you're doing well. Could you please let us know if the issue still persists or if it has been resolved? If everything is working fine now, we’d appreciate it if you could mark the response as answered. We will proceed with the thread closure by 14 January, so we are hoping for your reply before that.
Varsha Dundigalla(INFOSYS LIMITED) 5,025 Reputation points Microsoft External Staff

2026-01-14T12:59:03.22+00:00

We are closing this thread at this moment since we are unable to investigate this issue further without the requested information. If the issue still occurs, please collect the requested information and share it with us. Upon receipt of the additional information, we will reopen this thread and continue to investigate this issue. Thank you.
Laurent Guigon 331 Reputation points

2026-01-21T10:10:06.03+00:00

Hello
I was on holiday, so I didn't read the forum for a few days.
Laurent Guigon 331 Reputation points

2026-01-21T10:10:52.4466667+00:00

Hello, thank you for your answer. I've added some comment to my first question to be more specific.
Varsha Dundigalla(INFOSYS LIMITED) 5,025 Reputation points Microsoft External Staff

2026-01-23T10:47:43+00:00

Thanks for sharing more context.

What’s causing the confusion is that two different concerns are overlapping: keeping your code reusable (DRY and DDD) and securing communication between parts of the system that run independently. These two things are related, but they are not solved in the same way.

As long as your Blazor Server app and business logic run within the same server‑side application, cookie‑based authentication works naturally. The browser already represents a trusted user session, so user identity and roles can be checked consistently without sending identity information over HTTP.

Once the front end and the API are treated as truly separate components that only communicate through HTTP, that session trust no longer exists. In that case, the API must explicitly know who the caller is on every request, which is why token‑based approaches like JWT appear in distributed and multi‑client scenarios. This isn’t specific to Blazor; it’s a general requirement when systems are decoupled.

It’s also important to note that keeping your domain logic reusable does not require exposing it through an API. Shared libraries can be used by Blazor Server now and by a separate API later without duplicating logic. The added complexity comes only when identity and authorization must cross an application boundary.

So the challenge here isn’t choosing the “right” authentication mechanism, but understanding where the trust boundary is today. Cookie authentication works while everything runs in one backend context. When that boundary moves and multiple clients must call the API independently, additional identity infrastructure becomes necessary.

I hope this helps clarify why different solutions come up and why this is mainly about trade‑offs rather than a missing configuration.

Please let us know if you require any further assistance, we’re happy to help. If you found this information useful, kindly mark this as "Accept Answer". So that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.
Varsha Dundigalla(INFOSYS LIMITED) 5,025 Reputation points Microsoft External Staff

2026-01-28T12:57:25.1166667+00:00

Hope you're doing well. Could you please let us know if the issue still persists or if it has been resolved? If everything is working fine now, we’d appreciate it if you could mark the response as answered. We will proceed with the thread closure by 30 January, so we are hoping for your reply before that.
Varsha Dundigalla(INFOSYS LIMITED) 5,025 Reputation points Microsoft External Staff

2026-01-30T10:13:39.3633333+00:00

We are closing this thread at this moment since we are unable to investigate this issue further without the requested information. If the issue still occurs, please collect the requested information and share it with us. Upon receipt of the additional information, we will reopen this thread and continue to investigate this issue. Thank you.

Answer 4

AI answer

To secure both your Blazor Server app and the associated Web API, you can follow these steps:

Use ASP.NET Core Identity: Start by setting up ASP.NET Core Identity in your Blazor Server application. This will handle user authentication and authorization. You can configure it to use cookie authentication, which is suitable for server-side Blazor applications.
Secure the Web API: For your Web API, you can implement JWT (JSON Web Tokens) for authentication. This allows you to secure your API endpoints by requiring a valid token for access. You can generate JWTs upon user login and validate them for subsequent requests.
Configure Authentication and Authorization:
- Use AddAuthentication and AddAuthorization in your Startup.cs or Program.cs to configure authentication services. This will help you manage user roles and claims effectively.
- For the API, you can use AddJwtBearer to configure JWT authentication.
Role-Based Access Control: Implement role-based access control by defining roles within your application. You can assign roles to users and use policies to restrict access to certain API endpoints based on these roles.
Create a Dedicated API Service: As you mentioned, creating a specific API service dedicated to user management is a good approach. This service can handle user-related operations and can be consumed by both your Blazor app and other backend services.
Secure Sensitive Data: Ensure that sensitive data is not stored in client-side code. Use secure authentication flows and consider using the Secret Manager tool for local development to manage sensitive information securely.

By following these steps, you can effectively secure both your Blazor Server app and your Web API, ensuring that user authentication and authorization are handled consistently across your application.

References:

AI-generated content may be incorrect. Read our transparency notes for more information.

Share via

How to secure both Blazer server and api ?

4 answers

Your answer