What is the difference between authentication and authorization, and how do role-based and policy-based authorization work in ASP.NET Core?

Say it out loud, then check

Inside one decision

What happens between the request and the action, for the credit officer's approve call, in order.

The story

1. Before

   Navistar Financial's credit team approves truck loans in an internal web app. Behind its screens sits our .NET API: the code that does the work when a screen asks. Two of its jobs: any signed-in user may read a loan application, but only a credit officer may approve one. In the first version the API asked one question only: is this person signed in? Every staff member and every dealer user of the portal was.

   Dealer usersigned in

   Credit APIone question

   Databaseapplications

   approve application 42

   signed in? yes

   1/4Before: the API checks one thing. Is this caller signed in?A dealer user is signed in too, so the approval goes through.Fix: two checks. First who are you, then may you do this?The dealer gets 403 Forbidden: signed in, but not allowed. Only a credit officer gets through.

   BackPlayNext
2. Why it had to change

   Being signed in only proves who someone is. It says nothing about what they may do. When the API treats "signed in" as "allowed", any user can do anything, and the only thing stopping them is which buttons the screen happens to show. A dealer who calls the API directly skips the screen.

3. How it works now

   ASP.NET Core splits this into two steps that run for every request. Authentication answers "who are you?": it reads the caller's token, a signed piece of text the app sends with every request to prove who the user is, and builds a user object from it. Authorization answers "may you do this?": it compares that user with the rule on the endpoint (one address the API answers, like "approve application 42"). A named rule is called a policy. The facts in the token are called claims: one name and one value each. Here is the user that authentication builds from a credit officer's token:

   Tokensent with the request

   1/4The request carries a token. Inside are claims: facts about the user.Authentication checks the token is real, then copies each claim onto a user.A role is just a claim of type role. Here: CreditOfficer.Authorization later reads these claims to decide: may this user approve?

   BackPlayNext
4. What we gained

   Each endpoint now states its own rule, and the API enforces it even when someone skips the screen. The rest of the card follows three calls to the same endpoint through both steps.

In the lending API

The controller: two attributes hold the two rules; the diagram above shows them running.

Only the key lines are shown; Deep walks the whole file.

The code, file by file

The Navistar credit API: start-up, then the controller. Tap Next to walk the three calls.

What they ask next

The follow-ups interviews really ask. Answer out loud, then tap to check.

• What is the difference between 401 and 403?

  401 Unauthorized means the API doesn't know who you are: no token, an expired one or a forged one. The response carries a WWW-Authenticate header that says how to sign in. 403 Forbidden means it knows exactly who you are and you're not allowed. In ASP.NET Core the authorization middleware decides: anonymous user and a rule that needs one → challenge (401); known user who fails the rule → forbid (403).

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Bearer error="invalid_token"

  Next questions, in Deep →
• ReportedRole-based, claims-based or policy-based: which do you use?

  Roles are the simplest: [Authorize(Roles = "CreditOfficer")]. Claims-based checks any fact in the token, like RequireClaim("approval_limit"). Policies wrap either, plus custom requirements, under one name registered in Program.cs. I use policies for anything beyond "signed in", because the rule lives in one place and the controllers only name it. Roles and claims are really both inside policies anyway: [Authorize(Roles = ...)] builds a small policy behind the scenes.

  Next questions, in Deep →Neurealm: ways to handle auth in a .NET Core Web API
• How do you make sure a user can only see their own records?

  Load the record first, then call IAuthorizationService.AuthorizeAsync(User, record, "SameDealer") (the policy is written in the incident). Its handler compares the dealer id claim on the token with the dealer on the record. Attributes can't do this, because they run before the record is loaded. Return 404 rather than 403 for someone else's record, so the API doesn't confirm it exists. The incident in Deep is this exact hole. The full picture: resource-based authorization and BOLA.

  Next questions, in Deep →Walk the incident →

Follow-up tree

Answer, then open the next level. That is the order an interviewer digs in.

Reporteda candidate was asked Intervieweran interviewer asks it

• What is the difference between 401 and 403?

  401 Unauthorized means the API doesn't know who you are: no token, an expired one or a forged one. The response carries a WWW-Authenticate header that says how to sign in. 403 Forbidden means it knows exactly who you are and you're not allowed. In ASP.NET Core the authorization middleware decides: anonymous user and a rule that needs one → challenge (401); known user who fails the rule → forbid (403).

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: Bearer error="invalid_token"

• ReportedRole-based, claims-based or policy-based: which do you use?

  Roles are the simplest: [Authorize(Roles = "CreditOfficer")]. Claims-based checks any fact in the token, like RequireClaim("approval_limit"). Policies wrap either, plus custom requirements, under one name registered in Program.cs. I use policies for anything beyond "signed in", because the rule lives in one place and the controllers only name it. Roles and claims are really both inside policies anyway: [Authorize(Roles = ...)] builds a small policy behind the scenes.

  Neurealm: ways to handle auth in a .NET Core Web API
• How do you make sure a user can only see their own records?

  Load the record first, then call IAuthorizationService.AuthorizeAsync(User, record, "SameDealer") (the policy is written in the incident). Its handler compares the dealer id claim on the token with the dealer on the record. Attributes can't do this, because they run before the record is loaded. Return 404 rather than 403 for someone else's record, so the API doesn't confirm it exists. The incident in Deep is this exact hole. The full picture: resource-based authorization and BOLA.

  Walk the incident →
• What does Roles = "A,B" mean, and two [Authorize] attributes?

  A comma list means either role is enough. Two attributes on the same action must both pass, so [Authorize(Roles = "CreditOfficer")] plus [Authorize(Roles = "CreditManager")] needs a user who has both.

  // either role
  [Authorize(Roles =
    "CreditOfficer,CreditManager")]
   
  // both roles
  [Authorize(Roles = "CreditOfficer")]
  [Authorize(Roles = "CreditManager")]

• How does the API know the user's roles?

  They're claims in the token. At Navistar they are Entra ID app roles: an admin assigns a person to CreditOfficer in Entra, and the next token they get carries it. The API doesn't look them up in a database on every call. The cost: a removed role stays in tokens already issued until they expire, which is why access tokens are short-lived (the JWT card). What a claim is: claims and ClaimsPrincipal.

• ReportedHow do you authenticate an MVC site compared with a Web API?

  An MVC site (a website where the server builds the pages) that renders pages usually signs in with a cookie: the user logs in once, the server sets an encrypted cookie, and the browser sends it with every page. A failed check redirects to the login page. A Web API called by an Angular app or another service uses bearer tokens instead and answers 401 or 403, never a redirect. Authorization ([Authorize], roles, policies) works the same way on both.

  Circulants: authenticating an MVC application
• What happens if [AllowAnonymous] and [Authorize] are both on an action?

  [AllowAnonymous] wins: the authorization middleware skips every rule on that endpoint. That's why it belongs only on things that really must be open, like the health probe or the login endpoint, and why a review checks for it.

• How would you test authorization?

  Integration tests (they start the whole API, here in memory with WebApplicationFactory, and call it like a client). A test sign-in handler stands in for Entra ID, so each test picks the user's claims. For every protected endpoint: no user → 401, wrong role → 403, right role → 200, and for by-id endpoints, another dealer's record → 404. One table-driven test (a single test that loops over a list of endpoints) covers all of them, so a new one can't be forgotten.

• ReportedWhich security checks are there besides authentication and authorization?

  HTTPS everywhere, input validation, rate limiting (a cap on calls per caller), CORS (the browser rule for which websites may call the API; the middleware card), secrets in Key Vault instead of config files, parameterised queries (values sent apart from the SQL text, so input can't change the query: SQL injection), and logs that never contain tokens or personal data. Securing an API end to end is its own card. CORS on its own page: CORS; the card: securing a Web API.

  Tech Mahindra: security besides authn and authz

Production bugs, and how to tell them

Each one: what you see, why, the fix in code, and the line to say.

• Every credit officer got 403 after a token clean-up

  HTTP 403 Forbidden on every approval
  
  Authorization failed. These requirements
  were not met:
  RolesAuthorizationRequirement:User.IsInRole
  must be true for one of the following
  roles: (CreditOfficer)

  Cause

  Entra ID puts a user's app roles in a claim called roles. By default the JWT handler renames incoming claims to long .NET names, and roles becomes the .NET role claim, so role checks work. A PR set MapInboundClaims = false to keep the short names in the logs. Now the claim stayed roles, but role checks still looked for the long .NET role name. User.IsInRole("CreditOfficer") found nothing, and every officer got 403.

  Fix

  Tell the handler which claim holds roles: TokenValidationParameters.RoleClaimType = "roles". A test now calls the approve endpoint with a real-shaped Entra token and expects 200.

  BeforeAfter

  Diagram · step 1Before: the token has roles = CreditOfficer. Mapping is turned off, so the name stays roles.Show diagram

  Tokenfrom Entra ID

  IdentityJWT handler

  PolicyRequire​Role

  roles: CreditOfficer

  claim kept as roles

  1builder.Services.AddAuthentication()2 .AddJwtBearer(options =>3 {4 options.MapInboundClaims = false;5 // no RoleClaimType line here6 });

  Before · Program.cs · line 4 · 1 of 2With mapping off, roles stays roles, and nothing yet tells .NET that roles holds the roles.

  BackNext line

  Say it

  We turned off claim mapping and role checks silently stopped matching, because roles now sat in a claim the framework wasn't looking at. Setting the role claim type fixed it, and a test with an Entra-shaped token guards it.

• Approve crashed with a 500 after a policy was renamed

  System.InvalidOperationException: The
  AuthorizationPolicy named: 'CanAproveLoan'
  was not found.

  Cause

  Policy names are plain text. One action said CanAproveLoan (one p) while Program.cs registered CanApproveLoan. It compiled; the first call to that action threw, and the caller got 500, not 403.

  Fix

  Keep policy names in one class of constants and use them in both places, so a typo fails the build. A startup test requests every endpoint once.

  BeforeAfterUse it

  1[Authorize(Policy = "CanAproveLoan")]2public IActionResult Approve(int id)

  Before · ApplicationsController.cs · line 1 · 1 of 1Typo: no policy with this name exists.

  BackNext file

  Say it

  Policy names are strings, so a typo compiles and only fails at run time. We keep them as constants in one class, so the compiler catches it.

Traps

• Don't say401 means you're not allowed.Say401 means not authenticated: no valid token. 403 means authenticated but not allowed.
• Don't sayThe authentication middleware rejects requests without a token.SayIt only builds the user; with no token the user is anonymous. Authorization rejects, and only on endpoints that need a user.
• Don't sayCheck the role with an if inside each action.SayPut the rule in a named policy in Program.cs and reference it with [Authorize(Policy = ...)], so it's in one place and tested once.
• Don't sayThe Dealer role protects each dealer's records.SayA role says what kind of user it is, not which records are theirs. Load the record and use resource-based authorization.

Traps

What should you say instead? Tap to check.

• Don't say401 means you're not allowed.

  Say instead

  401 means not authenticated: no valid token. 403 means authenticated but not allowed.

• Don't sayThe authentication middleware rejects requests without a token.

  Say instead

  It only builds the user; with no token the user is anonymous. Authorization rejects, and only on endpoints that need a user.

• Don't sayCheck the role with an if inside each action.

  Say instead

  Put the rule in a named policy in Program.cs and reference it with [Authorize(Policy = ...)], so it's in one place and tested once.

• Don't sayThe Dealer role protects each dealer's records.

  Say instead

  A role says what kind of user it is, not which records are theirs. Load the record and use resource-based authorization.