Decoupling Authentication and Authorization: A Clean Design for Dynamic Role Switching

SasmitaB — Mon, 05 Oct 2026 08:55:39 GMT

Modern enterprise applications commonly use Azure Active Directory (Azure AD) for authentication while maintaining application-specific roles in their own database.

A typical requirement looks like this:

A single Azure AD user can belong to multiple organizations
Each organization maps to different roles in the application
After login, the user selects which organization (or role context) they want to operate in
The UI and authorization rules must respond to that selection

At first glance, this seems straightforward. However, in Blazor Server, things become tricky because of how authentication, authorization, and circuit state interact.

Business Scenario

Consider a procurement system:

A user logs in via Azure AD and may have multiple roles:

Global Administrator
Local Administrator
Service Desk User
Supplier

Instead of maintaining separate Azure AD identities, the application allows the user to switch context dynamically.

Conceptual Flow

The challenge is ensuring that navigation and authorization stay consistent with the selected context.

Role Model

To support multiple roles efficiently, roles are stored as bitwise values instead of strings.

This allows multiple roles to be combined and evaluated using bitwise operations.

For example:

This model enables flexibility such as:

A user being both SuperAdmin and SupportUser
Policies that combine multiple roles without additional logic

Authorization with Policies

ASP.NET Core policies make role checks declarative and reusable.

Instead of writing custom checks in every page, you define policies like:

Under the hood, these policies evaluate a custom authorization requirement that performs bitwise comparisons.

Policy Evaluation:

Simplified handler logic

This keeps authorization logic centralized and consistent across the application.

The First Challenge: AppState vs Authorization

A natural approach in Blazor is to store the selected role in a service like:

AppState.SelectedRole

This works for the UI:

Menus update correctly
Components react to changes

However, authorization attributes like:

do not work with this approach.

Why?

Because:

Authorization runs in ASP.NET Core middleware
AppState exists inside the Blazor circuit
These are completely different runtime contexts

Attempt 1: Updating Claims Dynamically

A common idea is to update claims when the user changes roles.

But this creates problems:

Claims are tied to the authentication cookie
Changing them inside a running circuit is unreliable
The current request context does not automatically refresh

In practice, this leads to inconsistent behavior.

Attempt 2: Reading AppState in Authorization

Another idea is to access AppState inside the authorization handler.

This fails because:

Authorization handlers run in middleware
They do not have access to Blazor services
There is no shared state between these layers

The Core Architectural Insight

The key realization is:

Authentication identity and application context are not the same thing.

Authentication → Who the user is (Azure AD)
Authorization → What the user can do (application roles)
Application context → Which organization the user is acting under

A Practical and Reliable Solution

Instead of forcing these concerns together, separate them:

Azure AD → Authentication only

Application → Role + context management

Recommended Flow

Using a Server-Side Endpoint

When a user switches organization, send the selection to a controller:

POST /account/switch

The controller:

Validates the user
Retrieves the correct role from the database
Stores the selected context

Authorization Based on Context

Instead of relying on UI state, the authorization handler evaluates:

Current user identity
Selected organization / role context

This ensures consistent behaviour across requests.

Security Consideration

Never trust client input directly.

Even if the role is stored in a cookie or selected via UI:

Always validate against the database
Ensure that the selected role belongs to the authenticated user

UI → Cookie → DB Validation → Authorization Decision

Why Page Refresh Is Necessary

One of the most confusing aspects is that role changes do not take effect immediately.

This is expected.

Execution model:

Blazor events → SignalR (no new HTTP request)
Authorization → Requires HTTP request

That’s why:

Page reload
Or forceLoad: true

is required for changes to take effect.

Lessons Learned

During implementation, several approaches were evaluated:

Best Practices

Keep Azure AD for authentication only
Store application roles in your own database
Use policy-based authorization for clarity
Never depend on Blazor UI state for authorization
Always validate role selection on the server

Conclusion

Dynamic role switching in Blazor Server is not just a UI challenge — it is an architecture challenge involving authentication, authorization, and state management.

The key takeaway is:

Authentication defines who the user is, while application logic defines what they are allowed to do in a specific context.

By separating these concerns and using server-side validation with policy-based authorization, you can build a solution that is:

Secure
Maintainable
Scalable

Re: Decoupling Authentication and Authorization: A Clean Design for Dynamic Role Switching

Thaufique_Mod — Tue, 06 Oct 2026 05:04:46 GMT

Thanks for sharing this informative topic. It is very helpful.

topic Decoupling Authentication and Authorization: A Clean Design for Dynamic Role Switching in Software - General

Decoupling Authentication and Authorization: A Clean Design for Dynamic Role Switching

Re: Decoupling Authentication and Authorization: A Clean Design for Dynamic Role Switching