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 anyo...
For further actions, you may consider blocking this person and/or reporting abuse
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.
+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.
👏👏
I thought it could be valuable to link an analogy to authn versus authz. I pulled it from this article
Always cool to see something simple and useful!
So useful content, I was struggling with this.
Simple yet useful
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:
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.