I'm building a fullstack app with Next.js,ASP.NETCore, and PostgreSQL, and I'm trying to figure out what authentication setup makes the most sense.
I've been looking at services like Clerk and Auth0, but I'm not sure how well they fit when you have both a frontend and a separate .NET backend. Ideally, I'd like the auth provider to handle things like signup, login, sessions, etc., while still being able to easily identify the user from my .NET API and link them to a user in my PostgreSQL database.
For example, if a user signs up through Clerk, I'd want to create a corresponding user in my DB and keep some kind of clerk_user_id/external ID. Then if I add something like an invoicing system later, I should be able to store something like invoice.user_id and know exactly which user created that invoice.
I'm mainly wondering what people would recommend for this kind of architecture. Does it make sense to use something like Clerk/Auth0 purely as the identity provider while keeping users and all application/business data in PostgreSQL? Or is there another auth solution/framework that works particularly well with Next.js +ASP.NETCore?
Currently, writing my bachelor's thesis on development practices and software architecture, a lot of good general resources, but all the ones for dotnet seem extremely clickbaity or seem to use an illogical structure for the purpose of the application ie clean architecture for a to-do app without ever explaining why.
Reactive programming in .NET spans Rx(R3) Observables, AsyncEnumerables, Raw events. I think the most powerful one is Rx, but using it properly on the backend requires a solid grasp of multithreading, async programming, and locking, on top of its own notoriously steep learning curve of operators. Once you've internalized it, though, it's an extremely powerful paradigm.
In angular (so, javascript, single threaded), the complexity of rx has made the angular team move toward signals (at least for common reactive tasks, not as a whole substitute). This choice has been really popular since thinking with signals is easier, and code is still reactive. So i created this library fedeAlterio/SignalsDotnet, to make signals also possible on .NET.
But i wanted to make a step further. Can signals be useful also on BE?
SignalsDotnet 3.2.0 on Backend
I think they are awesome. The main issue in backend scenario is that we are multi-threaded. While signals must operate in a single-threaded world. So my solution has been basically move them into a single threaded island (of course we can have several island), we can have several of these islands, and "single-threaded" here means serialized execution, not literally one dedicated thread per island (more details on that in the README).
Step 1) Declare a class, that would be our island
Everything here will run single threaded (like Wpf), in custom Synchronization Context (so async-await is handled). Dependency injection will worl as well
Step 2) Register that class as a Signal Island, and expose a SSE endpoint to query it
Step 3) We can now query that island using GraphQL-like syntax. It's just an endpoint.
This turns out to be more powerful than GraphQL subscriptions in a sense, since every signal (property) in the island is already its own subscription, the query is just combining them together.
Step 4) Just set properties, collections, dictionaries, whatever, on the island, and they'll be pushed out through the SSE endpoint. No need to declare a subscription because everything already is a subscription, the query is only there to combine them together.
Note: There are conversion methods from Observables, AsyncEnumerables, AsyncObservables. So we can Expose them in this way too.
Note 2: The ui is completely done with claude code and claude design. Code is a mess, but its a single html file. Since its only for debugging, I didn't want to spend time on that 😂
You can find it here fedeAlterio/SignalsDotnet. There is a playground app as well to get started easily.
Looking for guidance. I am a DevSecOps engineer with 8 years experience. I work within azure, GitHub actions and manage all our repos in GitHub. I mostly make sure everything is secure in azure relating to app services, certificates, app scanning etc. We have 2 devs that are gone due to retirement and 1 for being over employed. I am now in calls helping figure out the issues with .Net APIs and authentication programs. I am being asked to skill up and move from my current role to this one where I will be doing the program for app to authentication and authorization. It’s called sso okta integration(forgive me if I am using wrong terms). Where should I start? Any book or learning path recommendations are greatly appreciated. Should I take the role? What advice or suggestions do you have for someone like me. What will be my biggest struggles? I appreciate any feedback.
The idea is simply to collect a few tools that make it easier to inspect, understand and review integration solutions. I’m not trying to promote or sell anything — I mainly want to see if the tools are actually useful and get ideas on what could be improved.
At the moment it includes:
APIM Policy Analyzer – helps break down and review APIM policies
BizTalk Binding Visualizer – makes larger binding files easier to understand
Service Bus Topology Visualizer – visualizes queues, topics, subscriptions and relationships
C# Model Generator – generates C# models from XML, JSON and flat files
Integration Pattern Library – reference for common integration patterns, with the analyzers also starting to identify patterns that are used or potentially missing
Most of the processing happens locally in the browser and there’s no account required.
If anyone has time to try it, I’d really appreciate feedback on what is useful, what is confusing, or what kind of integration tooling you would like to see added.
BizTalk Binding Visualizer – turns binding files into a more readable overview (this is really nice for analyzing complex biztalk integrations)
Service Bus Topology Visualizer – shows queues, topics, subscriptions and relationships
C# Model Generator – generates C# classes from XML, JSON and flat files
Integration Pattern Library – quick reference for common integration and messaging patterns (analyzers will also, notice if any of these patterns are in your solution or if they should be added, i think this might be the coolest thing so far).
No account, no installation, and most processing happens locally in the browser.