Authentication vs Authorization

Authentication asks who you are; authorization asks what you're allowed to do. A web app proves who you are once, at sign-in, then remembers you with a cookie on every request after.

Apprentice · ASP.NET Core · Web Development · Updated

After this lesson you can

  • Tell authentication from authorization, and explain how a sign-in cookie keeps you signed in

Key takeaways

  • Authentication asks who you are, once at sign-in; authorization asks whether you're allowed to do this, on every protected page or action.
  • After sign-in, the server sends a signed, encrypted cookie, and the browser sends it back with every request, so the site knows it's still you.
  • A site never stores passwords as typed: it keeps a one-way hash, and compares hashes at sign-in.

Two security words sound alike and mean different things. Every app that has accounts needs both.

Who are you? Authentication

Authentication is proving who you are. At a website, that's usually a user name and a password: if they match, the site knows it's you.

What may you do? Authorization

Authorization is deciding what you're allowed to do, once the site knows who you are. Anyone may read the product list; only signed-in staff may open the order history; only an administrator may add products.

Authentication Authorization
Question Who are you? Are you allowed to do this?
When Once, at sign-in On every page or action that's protected
Fails with "That user name and password don't match." "You're signed in, but your account can't open that page."
In ASP.NET Core SignInAsync, after checking the password [Authorize], [Authorize(Roles = "Admin")]

An office building works the same way: your ID badge says who you are (authentication), and the doors it opens depend on your job (authorization).

Remembering who you are: the cookie

Each request to a web app is separate: the server doesn't remember the last one. So how does a site know it's still you on the next page?

  1. You sign in. The server checks your password.
  2. The server sends back a cookie: a small, signed and encrypted piece of data that says who you are and what roles you have.
  3. The browser sends that cookie back with every request to the site.
  4. On each request, the server reads the cookie, checks it hasn't been tampered with, and knows who you are, without asking for the password again.
  5. Signing out deletes the cookie.

That's cookie authentication, the usual way for sites made of pages, such as an MVC app. (Web APIs called from Angular usually send a token instead, which you'll meet in the Angular module.)

Passwords are never stored

A site must never keep passwords as typed. It keeps a hash: the result of a one-way scramble that can't be turned back into the password. At sign-in, it hashes what you typed and compares the two hashes. If the database is ever stolen, the passwords aren't in it.

Check yourself

1 question to try on the lesson page.

So what

Authentication proves who someone is; authorization decides what they may do. A signed cookie carries the first from request to request, so the second can be checked on every page.

Key terms

Cheat sheets