People in our little corner of the software world (identity and access management) keep coming up with jargon that makes life hard. If you're a software developer or product manager, you might run into the terms AuthN and AuthZ and wonder what the difference is. You might have a hard time navigating some of the overwhelmingly technical guides out there.

It feels like this sometimes:

Here, I'll try and explain the differences between AuthN and AuthZ in maximally simple and minimally technical terms. Seem reasonable? Let's skip ahead to the TL;DR.

TL;DR: what's the difference between AuthN and AuthZ?

AuthN means authentication. It's concerned with determining who someone is. When you're responsible for authenticating a user, that just means you need to confirm their identity. You're making sure that someone claiming to be John Doe is, in fact, John Doe.

AuthZ means authorization. It's all about what someone's allowed to do. Practically speaking, this pretty much always follows after authenticating a person. Once you know someone is John Doe, you need to figure out his authorization status: for example, is he actually allowed to edit a certain document?

Put very simply:

• AuthN is authentication. It just means you're getting proof of identity.
• AuthZ is authorization. It just means you're checking someone's permissions.

You usually need to do both!

AuthN vs AuthZ: a simple example without software

Sometimes jumping right into the technical details makes things feel more complicated than they need to be. Let's look at an example of AuthN and AuthZ in real life.

Imagine you're going through airport security (at least as it worked in the USA throughout the 2010s). If you've done this before, you'll have some sense for what it entails. You'll simultaneously present the security officers with two documents: a valid government-issued photo ID like a driver's license or passport; and an airline-issued boarding pass.

The officer will take a look at the ID, then look at you.

Satisfied that you are who you claim to be, the officer will then look at the boarding pass, which has your name on it. At this point, they're just checking that you have a legitimate ticket -- that you're entitled to board a flight that day.

In this case, you have authenticated using your photo ID. It proves your identity. You have also demonstrated your authorization. You've presented evidence of your permissions (i.e., that you're entitled to board a certain flight).

Things get complicated in software sometimes, but ultimately things work in the same way! A user proves who they are (AuthN) and you check what they're allowed to do (AuthZ). The general principles are the same.

Tesseral for AuthN and AuthZ

If you're building B2B SaaS, you'll need some pretty complicated AuthN and AuthZ features. You'll need to get acquainted with identity federation concepts like SAML SSO and SCIM provisioning. You'll need a bunch of integrations. You'll need some kind of role-based access control.

All of that can be pretty overwhelming to implement yourself.

You can make life easier by abstracting away AuthN and AuthZ with an open source solution like Tesseral, which comes with all of the auth features you need for any scale. It's very straightforward to implement, requiring just a few lines of code; from there, your maintenance burden is massively lighter.