Most software gets written under pressure to ship. That pressure rewards a specific kind of thinking: see the task, solve the task, move to the next task. It rarely rewards the slower question that sits underneath almost every recurring engineering headache — why does this keep being hard? Not "how do I fix this instance of the bug," but "why does my codebase keep producing this category of bug in the first place?"
Authorization is a good example of a problem that looks solved long before it actually is. A team needs to restrict who can do what, so they add a role check. Then another one. Then a permission flag, then a special case for one client, then a hardcoded exception for a VP who needed access last quarter, and nobody ever revoked it. Every individual change was the obviously correct, fastest path to "done." Nobody made a bad decision. And yet five years later the application has an authorization system nobody fully understands, built entirely out of locally reasonable choices.
That's what happens when a problem gets solved at the speed it's noticed rather than the speed it's understood. The fix for any one ticket is fast. The fix for the pattern requires stopping long enough to ask why the pattern exists — and that's a much less comfortable question, because the honest answer is usually "we never separated this concern from that one, so every change to it touches code that has nothing to do with it."
Authentication and authorization get bundled together constantly, simply because they show up in the same sentence so often. But sitting with the question for a while reveals they aren't variations of the same problem. Authentication answers "who is this?" Authorization answers "what is this person allowed to do right now?" — a question that changes shape constantly, follows the org chart instead of the login flow, and has almost nothing to do with how someone proved their identity. Treating them as one problem is exactly the kind of shortcut that feels efficient under deadline and feels expensive every year afterward.
AuthorizationHub is what you get when someone takes the slower question seriously instead of patching the symptom again. It's a plug-in for ASP.NET Core applications built around a clear division of labor: identity stays identity — it works alongside whatever provider you already have — while authorization gets its own model entirely: users, groups, roles, and an organizational tree, all turned into claims as a request moves through the ASP.NET pipeline, where they plug into ASP.NET's existing authorization policies.
Role-based and claims-based access control aren't new ideas. What changed was the willingness to stop and ask why authorization kept being hard, instead of accepting the next ticket and the next role check as just the cost of doing business. It's the difference between a system that gets simpler over time and one that only gets more tangled, one reasonable decision at a time.