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

[SasmitaB]

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:

1. A user being both SuperAdmin and SupportUser
2. 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

[Thaufique_Mod]

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