Yes after months of writing this .NET core 3.1 API, I am still going back and rewriting the Auth flow.

I talk to a lifelong .Net Guru yesterday to get advise about JWT flow with .NET. His take in summary:

"Oh haha yeah all of these settings you kinda just copy over an forget about them over time. They change drastically between every version anyways. 2.0s approach is so different than 3.0-3.1s. "

We then proceed to spend hours trying to copy other peoples solutions and satisfy the type requirements for different services.

Guys look im trying really really hard to get into .NET. Harder then i should try. I come from .Node & php where you import a JWT library, you get the creds, check em and call on function to issue an Bearer token. You write a 5 line middleware function for getting teh claim and fetching the user into global scope and done.

This has been an ongoing nightmare and im about sick of it. I dont need a framework with an over-opinionated, ever changing way of handling auth.


.NET needs to get its shit together. Most everything else about the framework is proving to be pretty rad though. Im about to get into SignalR though and im sure ill find equal frustration there.

  • 2
    we are in 2020 man. auth is equal to restricting access and that is pure racism! you should not do auth xD
  • 5
    Now you're starting to understand my, "Steve Sanderson ruins everything," mentality.

    This is primarily a complaint with the JWT middleware. The runtime doesn't handle any security itself. I will say the other platforms mentioned can make it simpler because they're only concerned with simple, single track auth stories.

    AspNet auth uses the same base abstractions for every type of auth (identity + claims). It's not just jwt. Apps can also simultaneously have numerous types of auth (OAuth, forms, saml, ws-trust/fed, ntlm, Kerberos, etc). It will automatically analyze requests and determine which to use. All middleware is baked into this paradigm, and every permutation of those auth types.

    There haven't really been any significant changes between the core 2.0 and 3.0 in the auth registration story, or even .Net 3.5 -> present. The endpoint story changed, but that's about it. Thankfully those are separate pipelines.

    This all exists so any auth mechanism can use the same ClaimsPrincipal and Policy abstractions for security. It's necessary so that every security implementation supported on a given application becomes a discrete path of execution and coexists with the other auth methods any application can potentially support.

    The auth story has been essentially the same since Asp.net under 3.5 (2007):

    - register the modules you want
    - set their configuration
    - bind the message transport mechanism
    - register the identity stores
    - register any claim enrichers/transformers as needed
    - define your policies
    - apply annotations to endpoints

    If you understand that set of pipelines, auth is trivial, but it does take some work to grok. The biggest thing I'll levy against MS in regards to .Net is for a number of years they outsourced the docs to the "community," so the content is by and large questionable. Core has made it a little better, but it still has a long way to go to get back to the 2005ish levels of quality.
  • 1
    SignalR you say? Enjoy your neverending reconnecting / disconnecting nightmare if the client is ever behind a slow ass or unstable connection.

    And what about net scalers and the likes? Oh, no, don't get me started with those.

    Also, would you like to ask the back end to send some notification to any interested party? Good luck not hitting that kind of request right at the time your connection is "reconnecting". Enjoy your notifications queue management.

    Moreover, have fun getting it to work with DI...

    And that's about all I have to say about it. It's pretty good, when it's not pretty goddamn awful.
  • 0
    @SortOfTested if you dont mind im going to reference your comment in a medium article. I get that .Net has all teh right abstractions to make our lives easier for the longterm solution and i can appreciate that but also, im building prototypes most of the time and like to conrtol how simple or complex a process is based on what the applications needs are at the time. When I have stakeholders, I prefer having something to show first before having it perfected. Complexities around everyday application needs like this make prototyping very difficult. For big solutions though yeah absolutely i think .NET is astounding. Its clean, so so clean as long as one doesnt overdue their abstractions to the point that it becomes obnoxious but that can be the same with functional languages. Everything can be done wrong.
  • 0
    @no-oxygen your scaring me now man. I was gonna try signalR. I can find another solution utilizing a 3rd party approach.

    Im actually enjoying .Nets built in dependency injection so far though. It can be rather picky at times but its alot cleaner then how were doing DI with php right now
  • 0
    @no-oxygen i enjoy nodes approach the most. Just importing the library needed and moving on with my day. Not trying to meet all kinds of dependency lines
  • 0
    @dUcKtYpEd ahaha sorry dude. You Just gave me a reason to rant over SignalR and I couldn't resist It 😆

    Anyway, I experienced all of the above by developing a WPF client that had to interact with a .NET api server. Your case might differ, but I'm warning you so that you could check It out yourself with a very open and ready mind.
  • 0
    @dUcKtYpEd I know nothing about node so I really cannot help you with It. But if you ever need help with a .NET implementation just ask.
  • 0
    @no-oxygen for sure. Wish you could DM on this platform. Im writing medium articles about the every .Net process im learning just as a prospective from someone coming in fresh to the framework. Its a different beast
  • 1
  • 1
    Will read it after a bit, feel free to claim the ideas are your own.

    No attribution please 😘 this is a safe space for free anonymous expression of real talk.
Add Comment