Security Models

By the end of this lesson you'll be able to tell authentication from authorization, and lock down an ASP.NET Core app three ways — by role , by policy , and by claim — choosing the right model for each rule and defaulting to deny so you never leak an endpoint by accident.

Learn Python, JavaScript, Java and more with free interactive lessons, real projects and AI-powered help. Beginner-friendly.

Part of the free C# course at LearnCodingFast — hands-on lessons with examples you run in your browser, plus practice exercises and a quick quiz.

Think of getting around a secure office building. A role badge (role-based) opens whole categories of door at once — "Staff", "Manager" — simple, but everyone with that badge gets the same access. A keycard policy (policy-based) is a named rule the reader enforces — "Staff and fire-trained and after 6pm" — a reusable combination of conditions. Personal attributes (claims-based) are the facts printed on the badge itself — your clearance level, your department, your date of birth — and the door decides from those facts, not from your job title. Most real buildings use all three: a badge for the easy cases, policies for the combinations, and the printed facts when a job title is too blunt an instrument.

In ASP.NET Core these aren't rivals — a role is just a claim of type role , and a policy is the general mechanism that role checks and claim checks both run through. Reach for the simplest model that expresses the rule.

1. Authentication vs Authorization

These two words look alike and are constantly confused, but they answer different questions. Authentication (authn) proves who you are — logging in, validating a token. Authorization (authz) decides what you're allowed to do once your identity is known. A user can be perfectly authenticated and still be forbidden: that's a 403 , not a 401 . Authorization always comes second. Read this worked example, run it, then you'll write the role check yourself.

2. Role-Based Authorization (RBAC)

Role-based access control is the simplest model: each user carries a list of role labels, and you grant access when a required label is present. At its core it's just roles.Contains("Admin") . In ASP.NET Core you rarely write that if yourself — you declare it with [Authorize(Roles = "...")] and the framework enforces it. Comma-separated roles mean OR (any one matches); stacking the attribute means AND (all required). First, finish the plain check below.

Your turn. The program below authorizes by role — fill in the two ___ blanks using the hints, then run it.

Here's how the same check looks in a real ASP.NET Core controller. Notice there's no if at all — the [Authorize] attribute is the rule, and the framework returns 403 for you when it isn't met.

3. Claims-Based Authorization

Roles are blunt: "is this person an Admin?" tells you nothing about why . A claim is a single fact about the user — a (type, value) pair like ("age", "21") or ("email_verified", "true") — and claims-based authorization decides access from those facts directly. This is more honest: instead of inventing an "Over18" role, you check the age claim. A policy here is simply a predicate over the user's claims. Read the worked example, then write your own age check.

Now you try. Authorize by a claim rather than a role: read the age fact and apply an 18+ policy. Fill in the two ___ blanks:

4. Policy-Based Authorization in ASP.NET Core

Policy-based authorization is the model the others run through. You register a named policy once with AddAuthorization(o => o.AddPolicy(...)) , combine as many requirements as you like (roles, claims, custom logic), and reuse the name with [Authorize(Policy = "...")] . Inside the app, the signed-in user is a ClaimsPrincipal — you read facts off it with FindFirst , HasClaim , and IsInRole . Crucially, a FallbackPolicy makes the whole app default-deny : every endpoint needs a login unless you explicitly opt out.

Least privilege means every user, token, and service gets the minimum access needed to do its job — and nothing more. A reporting service that only reads data should never hold write credentials; a support agent who resets passwords shouldn't also be able to delete accounts. The blast radius of a stolen token or a compromised account is exactly the privilege it carried.

Two habits make this concrete in C#. First, default-deny : set a FallbackPolicy requiring an authenticated user, then add [AllowAnonymous] only to the genuinely public endpoints. A new endpoint is then locked by default — you can't forget to protect it. Second, authorize by capability, not by person : a policy named "CanRefund" survives reorganisations and new roles, whereas Roles = "SeniorManager" rots the moment the org chart changes.

Q: What's the real difference between authentication and authorization?

Authentication proves who you are (login, token validation) and produces a failed result of 401 Unauthorized . Authorization decides what you may do and fails with 403 Forbidden . You're authenticated first, then authorized.

Use a role for coarse, stable groups ("Admin", "Staff"). Use a claim when the decision depends on a fact about the user — age, department, subscription tier, email-verified. If you're tempted to invent a role like "Over18" , that's really a claim.

Q: Aren't policy-based and claims-based the same thing?

Closely related. A policy is the named container of requirements; a claim requirement is one kind of requirement you can put in it. Claims-based authorization is usually implemented as a policy that requires certain claims.

Q: Why can't I just trust the claims the browser sends?

Because the client controls them. An attacker can set isAdmin=true in a header or an unsigned token. Only authorize on claims your server issued and signed — for example the claims inside a JWT you validated against your signing key.

Default-deny. Set a FallbackPolicy that requires an authenticated user so every endpoint is protected unless you mark it [AllowAnonymous] . That way forgetting to add [Authorize] can't leak a private endpoint.

No blanks this time — just a brief and an outline. Write a tiny authorizer that grants access only when the user has both the "Editor" role and a signed ("email_verified", "true") claim — combining role-based and claims-based checks the way real policies do. Run it and match the expected output.

Practice quiz

• Browse all free courses
• Cheat sheets & quizzes
• Coding dictionary