Authentication vs. Authorization: What's the Difference?

Welcome aboard, tech enthusiasts! In today’s digital world, there’s no such thing as being too secure. With data breaches making headlines, it’s high time we pull up our socks and look at security essentials.

So, what’s all the hullabaloo about authentication vs. authorization?

Well, let’s break it down.

These two A’s are like the Batman and Robin of security protocols. They work hand in glove to protect the Batcave (read: your data). Hang tight, as we’re about to get down and dirty with these two superheroes.

Authentication is not just a fancy word; it’s the gatekeeper. It’s the process of verifying the identity of a user, device, or system.

Once past the gates, what can you access? That's where authorization comes in. Authorization is the process of determining what permissions (or rights) or resources an authenticated user is permitted to access within an application. It's the butler inside the mansion who guides you around.

There are several layers to consider when we talk about authorization.

User-level Authorization. This is the basic layer. Once a user is authenticated, user-level authorization decides what resources a user has access to. This could be based on the user's role, group membership, or individual user permissions.

Role-based Authorization (RBAC). Permissions are not given directly to individual users. Instead, they're given roles (like admin, user, manager, avengers, etc.), and users are assigned to these roles. This is a widespread way to handle authorization in large systems (and eCommerce platforms) as it streamlines management.

Attribute-based Access Control (ABAC). This goes a step further than RBAC. In addition to roles, access is also controlled based on other attributes, such as the time of day, the user's location, the type of device being used, and more.

Policy-based Authorization. The decision to grant or deny access is made by analyzing a collection of rules or guidelines known as policies. These policies can be altered and updated on the fly, giving the system the flexibility to adapt to changing circumstances. This approach is typically favored in intricate systems where the requirements for access control can fluctuate quickly or require fine-tuning.

Contextual Authorization. Based on context, the same user might have different permissions based on factors like location, time of day, or the device being used.

Claims-based Authorization can be thought of as properties of an entity. A claim could be a user's age, and the system could use this claim to decide whether the user can access age-restricted content.

Permissions-based Authorization. This takes user-level authorization a step further. Rather than assigning permissions to individual users, permissions are defined for particular actions or resources within the system. Users are then granted these permissions either directly or through their roles. For example, read permission might be defined for specific content, which can be granted to any user or role that needs to be able to read that content.

Often, several layers will be combined in a single system to provide the necessary level of control and flexibility. It's also important to note that these layers are not strict or exclusive categories, and many systems use concepts from several layers to achieve their authorization needs.

A token can be signed; what does that mean? It means that another system vouches for it (or provides it), so you can trust it without asking that system.

A Digital Signature is a cryptographic technique used to validate the authenticity and integrity of a message, software, or digital document. It's the digital equivalent of a handwritten signature or stamped seal, offering far more inherent security. Digital signatures are based on public key cryptography, also known as asymmetric cryptography.

When a digital signature is created, a mathematical algorithm generates a pair of keys (private and public). The private key is kept secret by the owner and used to sign the digital document. The public key, available to everyone, is used to verify the signature. Digital signatures detect unauthorized modifications to data and authenticate the signatory's identity. They provide proof of originality and integrity, meaning the data has not been tampered with since it was signed.

Was it unclear? Remember: with signature: the data has not been tampered with since it was signed.

This brings us back to the elegance of JWT Tokens. Interestingly, a JWT Token isn't encrypted. The server signs it. The server utilizes its private key to sign the token, and its public key can then be used to verify the token's validity. If the token's signature is verified with the public key, you can trust it.

Note: This process can also be executed using symmetric keys, but asymmetric key cryptography provides higher security in most contexts.

One thing to remember here is that if your private or symmetric key is breached, anyone can generate Tokens. To avoid man-in-the-middle attacks, mechanisms called Certificate Authorities involve a third-party system. If you want to know more about Signature and the relationship between Certificate Authority (CA), check how HTTPS works!

Authentication and authorization might seem like two peas in a pod, but they're more like yin and yang. They complement each other; authentication is the first hurdle, and authorization is the second. Authentication validates identities, and authorization defines privileges. They're like bread and butter – good on their own but even better together.

Their symbiosis ensures that users only access the resources they're allowed to, thus preserving the system's integrity and security.

No rose without a thorn! Let's talk about the risks involved with authentication and authorization.

The risks are not the same based on your choice and the authentication system you are using. If you are using Login and Password, you expose yourself to brute force attacks. Using JWT tokens, you need to ensure the secrecy of the keys you're using and, if possible, use a Certificate Authority-like mechanism (to avoid man in the middle attack).

In general, you will also be exposed to Phishing Attacks, Credentials Stuffing, Social Engineering, etc., which is probably why more and more systems are using Multi-Factor Authentication (MFA).

The concept is simple: You keep your authentication mechanism as secure as possible but add layers on top of it. The aim is to create a layered defense so that if one factor is compromised, an attacker still has at least one more barrier to breach before successfully breaking into the target.

You can use different frameworks for Authentication and Authorization. You may remember LDAP or Kerberos or have seen OpenID Connect (OIDC), an identity layer on top of OAuth 2.0.

We will focus on OAuth 2.0 and SAML here, which are the most popular.

There's no one-size-fits-all solution. Depending on the use case, you have to pick the right tools for your needs. Of course, we can't list them all here, so let's use Crystallize as an example.

We call the App: (https://app.crystallize.com) to authenticate in our system. You can use:

• Magick Link
• Facebook Connect
• Google Connect
• GitHub Connect

Your browser is furnished with a session that provides seamless access to the PIM API from the user interface.

To retrieve data from the Catalog API (or other APIs), tokens can be generated. These tokens serve as keys to unlock user access, following the Role-Based Access Control (RBAC) model. Currently, tokens are assigned to specific users, but we're expanding to offer tokens based on roles soon.

While we're well-equipped to handle many use cases with the current setup, we continually aim for improvement. We're anticipating the implementation of OAuth 2.0 soon, which will allow other applications to access data on behalf of users. Though possible today, adhering to a standard protocol like OAuth 2.0 will enhance this feature.

And to achieve even greater compatibility with enterprise requirements, we plan to integrate SAML and SCIM. With the imminent release of the Role & Permissions feature, our customers will be one step closer to synchronizing their users and groups with our users and roles.

We've opted for a JWT token for the Webhooks, Crystallize Apps (injectable iframes), and Frontend previews. This token is included with the payloads and URLs and signed using a key specific to your tenant. You can regenerate this key if needed, such as in cases where the key might have been compromised.

Don’t let your guard down! Here are common pitfalls and how to dodge them.

• Password policies: Loose lips sink ships, and weak passwords breach data. Keep them complex and surely not in plain text!
• Salt: use a salt per user and, if possible, in another storage.
• Monitor: Audit traces are a common security standard that is easy to implement.
• Key rotation: if possible, rotate your keys
• Tokens (or Session IDs): keep them secret at all costs
• JWT Token: don’t put sensitive information there; it’s not encrypted. Don’t solely rely on the content of the claims to authorize. Make it possible to revoke the claims.
• Multi-tenancy key: provide a key for your tenant, and don’t keep a global key for all of them.
• HTTPS: in 2023, it’s a requirement and will improve SEO too!

There you have it, folks, a deep dive into authentication vs. authorization. It’s clear as day that these two are the pillars of security in the digital realm. Just like you wouldn’t open your front door, don’t leave your data unprotected.

So, whether you’re a business owner, a developer, or just someone who doesn’t want their data floating around like confetti, make sure you put these superheroes to work.

Remember, with significant data comes great responsibility. Authentication vs. Authorization are not just buzzwords; they're your knights in shining armor in this wild west of the internet. Stay vigilant and choose your tools wisely.

And hey, don’t forget to keep an eye on the horizon because the future of authentication and authorization is as exciting as it gets. Until next time, stay safe out there!