Blazor Server (.NET 8) authenticated with external REST API

John 20 Reputation points
2024-09-05T12:56:03.4766667+00:00

Hello,

i'm developing a small web application with Blazor Server (.NET 8) relying on a REST API (.NET Framework 4.8) for authentication and data access. I started developing this project last year, before the release of .NET 8, but i aligned the structure to the current standards, wrapping all application with InteractiveServer render mode.

The application is fairly simple, few grids and a couple of forms.

The authentication token is managed with a CustomAuthenticationStateProvider, stored inside .NET protected session storage and used for any call to the back-end. Everything is working well so far.

Will be public and IIS hosted, with few concurrent users (around 10).

I've read a ton of documentation through my development but i can't clear my mind about few points:

  • Architecture: being said that i develop and maintain the REST API but i can't rewrite it from scratch at the moment is the described project structure a valid one? I don't see any major advantage in switching to WASM (and i would really like to avoid that), but i read some devs stating that calling a Rest API with IHttpClientFactory is a better use case for WASM rather than Server with WebSocket.
  • Security: storing the JWT inside session storage is acceptable? I know i have to sanitize the few forms that i have to minimize the risks
  • Session: is there any way to force the session to close after a certain amount of time? Otherwise at the moment the only limit is the token validity timespan (usually a bit too high)

Thanks for any tip

.NET
.NET
Microsoft Technologies based on the .NET software framework.
3,798 questions
Blazor
Blazor
A free and open-source web framework that enables developers to create web apps using C# and HTML being developed by Microsoft.
1,556 questions
0 comments No comments
{count} votes

2 answers

Sort by: Most helpful
  1. Bruce (SqlWork.com) 64,161 Reputation points
    2024-09-05T19:32:52.95+00:00
    • Blazor server fully supports IHttpClientFactory. while REST is the preferred api nowadays, you can use others.
    • you only need to store the JWT in session if you don't want to authenticate between application re-loads. You should just store the token as injected service or cascading property.
    • Not sure what you mean by session? Blazor server is a single request and has persistent state for the life of the circuit. If you mean the browsers local and session storage, they are tied to the site origin. in the case of session storage it is cleared when the browser exits. if you meant asp.net session (not sure why you would use with blazor), its tied to a cookie and the cookie's lifetime, but because blazor server is a single request tied to a websocket, it can not update the session cookie.

  2. Brando Zhang-MSFT 3,606 Reputation points Microsoft Vendor
    2024-09-06T04:54:13.92+00:00

    Hi @John,

    I am calling a Rest API (outside Blazor domain) using IHttpClientFactory injected into a service, deserializing the result and passing it back to the page. Just wanted to clarify if it's a common/viable pattern to use for Blazor Server

    Yes, this is a common pattern to use for the blazor server , blazor server use the httpclientfatory to create the client and send the request to get the response.

    More details, you could refer to this official article.

    By session i meant exactly something like asp.net session. I am aware it's not suited for Blazor, but i would like to not give the user an endless "session", so i was searching for alternatives. I've read that it's possible to track the user interactions with JS and a timer, but it seems overly complicated and would certainly affect performance.

    Actually, there is no this endless session inside the blazor. Inside the blazor, if we want to keep the user state and manage the data, we will consider storing them by using these ways. Server-side storage,URL,Browser storage. More details, you could refer to this article. In my opinion, you could change the token expire time to avoid the user keep the login state to achieve your requirement. If you don't want to use this, you could write the logic for the root for each request to check user login time and delete the storage's token value, if user exceed the expire time.

    Best Regards,

    Brando

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.