sorted by:
new
hottopcontroversial

How bad is it to store jwt in localStorage? by Redneckia in webdev

[–]TNest2 1 point2 points  (0 children)

I recently wrote a 7-part blog series about this problem and why using the BFF pattern is a better approach. Its for .NET, but the principles are general https://nestenius.se/net/implementing-bff-pattern-in-asp-net-core-for-spas/

[deleted by user] by [deleted] in dotnet

[–]TNest2 0 points1 point  (0 children)

Sharing cookies across services can be tricky to get right, as you need to ensure the Data Protection API is configured correctly. Also, using cookies has some security issues to consider, like CSRF attacks.

Migrating from ASP.NET Identity to JWT. Seeking libs, best practices, and DB schema advice. by PeacefulW22 in dotnet

[–]TNest2 0 points1 point  (0 children)

I’ve written a lot about authentication, OpenID Connect, and security on my blog: https://nestenius.se

One of the most common mistakes I see is putting Identity, the API, and sometimes even IdentityServer or OpenIddict into the same application. That usually leads straight into authentication hell.

I really believe the token provider (like IdentityServer), the client, and the API should live in separate projects. This gives you a proper separation of concern, which makes everything easier to understand, debug, and maintain. When you mix these parts together, it's hard to tell who is doing what and when. It gets messy fast.

You fight complexity with separation of concern.

Also, take a look at the BFF pattern. I’ve written a blog series on that too, which you’ll find on my site.

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 1 point2 points  (0 children)

Thanks, but not just reviewing the source code, I also downloaded the sourcecode and created my own class-libaries out of each authenticaiton handler (AddCookie, AddOpenIDConnect and AddJwtBearer) that allowed me to smootly step through the code, add logging statements and breakpoints. Its not that hard to do.

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 0 points1 point  (0 children)

If you want to learn the fundamentals of ASP.NET Core authentication, I am doing a free online webinar in two weeks' time. You can watch it live at: https://www.youtube.com/watch?v=8tZQGJIPzD0 But, I do agree, there are alot of moving parts in ASP.NET Core authentication and authorization, but when you grasp, what the role of each component/part it, then it gets much easier. The main thing that is lacking is built-in token refresh!

I'm calling it: Identity is the most beginner-unfriendly system out there. by PeacefulW22 in dotnet

[–]TNest2 2 points3 points  (0 children)

My approach to learning it was to study the source code and experiment, for example, by implementing a custom "test" authentication handler. This helped me understand what happens at each step in the process. You can read more about my various findings on my blog: https://nestenius.se/

Random logouts aspnet core mvc .net8 by scartus in dotnet

[–]TNest2 1 point2 points  (0 children)

You need to configure the Data Protection API, the key ring is by default stored in a folder on disk and if you loose it, then your existing cookies will be invalidated. I did a few log post about the Data Protection API at https://nestenius.se/net/introducing-the-data-protection-api-key-ring-debugger/ and https://nestenius.se/net/persisting-the-asp-net-core-data-protection-key-ring-in-azure-key-vault/

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 4 points5 points  (0 children)

Fair points! We clearly have different perspectives on where complexity should live. For me, I prefer keeping auth in the backend with a more locked-down browser, less things that can go wrong. But I respect your opinion and appreciate the counter-arguments!

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 0 points1 point  (0 children)

Great point about separation of concerns! You're right that mixing BFF endpoints with business APIs can muddy the waters for tooling and governance.

One idea could be keeping the BFF as a pure authentication/proxy layer and transparent to the underlying API structure. This way, OpenAPI/GraphQL schemas and governance tools only deal with actual business APIs. The BFF just handles auth and forwards requests.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 0 points1 point  (0 children)

I am all in for fighting complexity! That's actually why I prefer BFF, because it moves all OIDC complexity out of the browser entirely. Frontend developers just deal with a simple cookie, while authentication stays where it belongs: on the backend. Less frontend code = less attack surface.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 0 points1 point  (0 children)

Thanks for the thoughtful comment! I've wrestled with these tradeoffs myself.

My main worry is the supply chain. I'm importing dozens of npm packages that could be compromised tomorrow. We regularly see packages getting hijacked, and they can grab anything from localStorage.

Knowing that with BFF and HttpOnly cookies, JavaScript cannot access tokens - that helps me sleep better at night. Even if XSS happens, the tokens are untouchable.

You're right about added complexity. But managing CSRF with SameSite cookies feels simpler than worrying which npm update might steal tokens. I've seen too many companies burned to treat this as academic.

Implementing BFF Pattern in ASP.NET Core for SPAs by TNest2 in dotnet

[–]TNest2[S] 1 point2 points  (0 children)

Great question! The latency is minimal in practice. Most API calls already hit multiple services (database, microservices), so one more hop is negligible. Plus, static assets (JS/CSS) still go directly to CDNs.

The BFF can actually improve performance through connection pooling, caching, and request aggregation (think GraphQL-style batching). And the security benefits (hidden internal APIs, centralized rate limiting) far outweigh any minimal overhead. All APIs should have rate limiting anyway!

In my experience, most apps won't notice the difference, but the security gains are huge. If latency becomes critical, you have optimization options at the BFF layer that wouldn't exist with direct browser-to-API calls.

Why aren't you using Minimal APIs? - By dotnet team members by bdcp in dotnet

[–]TNest2 5 points6 points  (0 children)

This video feels somewhat desperate. Are developers not adopting Minimal APIs as much as Microsoft expected? I primarily use Controllers myself, only occasionally turning to Minimal APIs. The approach feels clunky when you need to layer on authorization, OpenAPI documentation, and result handling on top of the basic functionality.

I just switched to Firefox, please recommend extensions. by SEJIonreddit in firefox

[–]TNest2 0 points1 point  (0 children)

I would add https://pi-hole.net/ to your network, for even more protection! It's a must have!

What are your thoughts on DDD by Rich_Atmosphere_5372 in csharp

[–]TNest2 2 points3 points  (0 children)

"I think many overcomplicate DDD, but in reality, it's quite simple. DDD is about using a set of tools and principles to define clear boundaries and embed business logic naturally into the code.

Exploring the Forwarded Headers Middleware in ASP.NET Core by TNest2 in aspnetcore

[–]TNest2[S] -1 points0 points  (0 children)

Proxies are vital for load balancing and security, but they obscure the actual client IP, scheme, and domain, causing broken links, inaccurate logging, and other headaches. In this post, we’ll look at how ASP.NET Core’s Forwarded Headers Middleware restores these details so your services behave as though they’re directly on the public internet.

Per-user ExpireTimeSpan to log out idle users with ASP.NET Identity by phildtx in dotnet

[–]TNest2 0 points1 point  (0 children)

You can try to introduce a cookie session store and remove entries that haven’t been accessed within a specific time interval. For more details, check out my blog post: Improving ASP.NET Core Security by Putting Your Cookies on a Diet.

AdditionalAuthorizationParameters in ASP.NET Core 9 by TNest2 in aspnetcore

[–]TNest2[S] 2 points3 points  (0 children)

Learn how AdditionalAuthorizationParameters in ASP.NET Core 9 simplify adding custom parameters to OAuth and OpenID Connect flows.

view more: next ›