DEV Community

DaNeil C
DaNeil C

Posted on • Edited on

AUTHeNtication VS AUTHoriZation

I decided to write this small post up because I get AUTHeNtication and AUTHoriZyr ation confused a lot and want to help make it more clear for anyone else struggling.


Authentication and authorization are two related words that are often used interchangeably, but mean different things and have very functionality within a system.

Alt Text(4)

Authentication (Auth-N)

Authentication is the act of validating that users are who they claim to be.

Validating authenticity can be accomplished by having something physical like a key card, by having a user login with passwords or 2FA, utilizing Captcha tests, or even biometrics for a user.

Authentication is used in conjunction with authorization usually as it is important to authenticate that a user is who they say they are before giving the authorization.

Authorization (Auth-Z)

Authorization is a process of giving a user permission to access a specific resource(s) or function(s).

Authorization levels are the difference between a general user and an admin user. An admin user will have more abilities that a general user and it is important to authorize the rolls properly to ensure general users don't accidently, or intentionally, harm a system.

Keep in mind that authentication is not 100% needed to gain authorization. This depends on the system and what information/abilities the systems has if it needs different levels of authorization and where authentication is needed.

Think about a blogging platform...
-Everyone should have access to read public posts.
-Users should need to authenticate themselves as users to post a blog and not post as someone else.
-Admins should need a different level of authorization, after they authentication themselves, to monitor the platform, the associated database, and its users activity.
In this case authentication is needed before authorization is given to ensure users can't post a blog as a different user and users can't modify things like admins.


Happy Hacking

References

  1. Security+ cert book
  2. Web Application Hackers Handbook
  3. https://auth0.com/docs/authorization/concepts/authz-and-authn
  4. https://www.ssl2buy.com/wiki/authentication-vs-authorization-whats-the-difference
Please Note that I am still learning. If something that I have stated is incorrect please let me know. I would love to learn more about what I may not understand fully.

Top comments (7)

Collapse
 
talldad profile image
John Angelico

Good, clear distinction - well said.

On authorization, I suggest thinking about admins and support people being NOT authorized to change data or transactions posted by regular users.

In some situations, that level of permission may be appropriate but it's worth thinking about.

I have worked in financial services (as lead user, primary on-site support person, and liaison with software techs) where internally changing data is a serious business. Therefore, the system/s we worked with deliberately precluded making data changes other than via the normal user-facing software.

Collapse
 
sirseanofloxley profile image
Sean Allin Newell

+1 for bepop gif. #classic

The Authentication + Authorization confusion happens to me too, because a lot of people throw around auth and it can be impossible to know which one they mean.

đź‘Źđź‘Ź

Collapse
 
wparad profile image
Warren Parad

I thought it could be valuable to link an analogy to authn versus authz. I pulled it from this article

When speaking about authentication (also called AuthN), think about identity. Authentication tries to answer “is this person who they say they are?” It’s a software equivalent of a passport or national ID check. Or to put it in more realistic terms, authentication is a similar process to that moment when you look at another person’s face to recognize that this is your friend from college and not your annoying second floor neighbor.


On the other hand, authorization (also called AuthZ) is all about permissions. Authorization answers a question “what is this person allowed to do in this space?” You can think of it as your house key or office badge. Can you open your front door? Can your annoying neighbor enter your apartment at will? And more, once in your apartment, who can use the toilet? Who can eat from your secret stash of cookies tucked away in your kitchen cupboard?

Collapse
 
mhsangar profile image
Mario Sánchez García

Always cool to see something simple and useful!

Collapse
 
learttmorina profile image
Leart Morina • Edited

So useful content, I was struggling with this.

Collapse
 
sxync profile image
SaiKumar Immadi

Simple yet useful

Collapse
 
mrachelski profile image
mrachelski

I think that this article did not really cover the important 'why does it matter' question. In practice, for most developers working on a small site using their development framework of choice, there is little reason to distinguish. The framework gives you a working login/identity/RBAC system. Unfortunately, that system is frequently tightly coupled stopping you from separating Authentication from Authorization.

Where this becomes critical is when you are working on larger systems such as that of an enterprise or SaaS application. In this case, it is CRITICAL to separate these concepts. By extracting out Authentication and delegating this to a dedicated system, you avoid having to take on massive problems related to Authentication in your app.
Specifically:

  • how do you ensure departed employees are removed from the system?
  • How do you keep up with the latest in security practices (multi-factor authentication, passkeys, biometrics, hardware keys, etc...)?
  • How do you remove accounts?
  • Who is going to curate the user accounts. Most enterprises require a semi-annual review of accounts to be sure that they are still in use.

All of this should be delegated to a system that will sweat those details. By removing a person from the 'one' Authentication system, all of that stuff happens in one place and thankfully becomes 'not your problem'.

In practice, extracting this out is pretty simple these days with protocols such as OIDC or SAML. Because it is a simple, bounded problem: Make a person prove that they are associated with an identity. Then safely deliver that proof of identity to the authorization system.

Authorization, that is where all the custom stuff happens. This is where your app can define such things as "what can an admin do" that is different than any of the other of millions of apps out there.