Lesson 20 of 40 Security Advanced 60 min

Security: Authentication & Authorization

In this lesson, you will learn how modern .NET applications verify identity, control access, and protect resources. Authentication and authorization are closely related, but they solve different problems and should be designed carefully.

← Back to Visual Studio 2026 Tutorial Home

What you will learn

The difference between authentication and authorization
How cookies, tokens, and identity-based login approaches differ
How to protect routes, controllers, and APIs
How policy-based authorization improves flexibility
How to avoid common security mistakes

Why this matters: Security is not just a feature that you add at the end. It affects login flows, role management, API protection, and how you trust user actions throughout the application.

Part 1: Authentication vs authorization

Authentication answers the question, Who are you? Authorization answers the question, What are you allowed to do?

A user may be authenticated successfully but still not have permission to access an admin page, approve orders, or call a restricted API endpoint.

Concept	Purpose
Authentication	Verifies identity
Authorization	Controls access after identity is known

Part 2: Securing controllers and endpoints

.NET makes it straightforward to restrict access to controllers, actions, and API endpoints using authorization attributes and middleware configuration.

[Authorize]
public class OrdersController : Controller
{
    public IActionResult Index() => View();
}

[Authorize(Roles = "Admin")]
public IActionResult AdminOnly() => View();
    

This is simple and effective, but roles alone are not always the best long-term design for larger systems.

Part 3: Policy-based authorization

Policy-based authorization is often more flexible than hardcoded role checks. Instead of saying only “Admin can do this,” you can express more meaningful business rules.

builder.Services.AddAuthorization(options =>
{
    options.AddPolicy("CanApproveOrders",
        policy => policy.RequireClaim("Permission", "ApproveOrders"));
});
    

Policies are useful because they let you evolve access rules without scattering role checks throughout the codebase.

Better design: Prefer capability-based or policy-based access rules when your application is likely to grow in complexity.

Part 4: Cookies, tokens, and common approaches

Different applications use different authentication mechanisms depending on whether they are traditional web apps, APIs, single-page applications, or distributed systems.

Cookie authentication: common in server-rendered web apps
JWT or token-based authentication: common in APIs and SPAs
External identity providers: useful for enterprise or social login integration

Choosing the right mechanism depends on the type of client, hosting model, and security requirements.

Part 5: Common security mistakes

Mistake	Why it is dangerous
Trusting client-side checks only	The client can be modified or bypassed
Overusing broad admin roles	Gives more access than necessary
Hardcoding secrets	Exposes sensitive information
Weak input validation	Can lead to injection or logic abuse
Missing HTTPS	Can expose credentials and session data

A practical security workflow

Step 1: Decide how users or systems authenticate

Step 2: Protect endpoints with clear authorization rules

Step 3: Prefer policies over scattered hardcoded checks

Step 4: Store secrets securely outside source code

Step 5: Validate input and protect sensitive actions

Step 6: Review access rules regularly as the app grows

Best practices

Use HTTPS everywhere
Apply least-privilege access
Prefer clear, centralized authorization rules
Keep secrets out of the repository
Validate and sanitize user input
Review both login flows and post-login permissions

Summary

In this lesson, you learned how authentication verifies identity, how authorization controls access, and why policy-based security design often scales better than simple role checks.

In the next lesson, you will dive into Razor Pages.