DEV Community: Space Blocks

Understanding the Difference Between Authentication and Authorization

Robin-Manuel Thiel — Thu, 09 May 2024 07:29:00 +0000

In the realm of software development, particularly in the context of security, two terms that often come up are "authentication" and "authorization." While they sound similar and are often used interchangeably, they serve distinct purposes in ensuring the security and integrity of software systems. Let's delve into the specifics of each and explore how they differ, along with some technologies commonly used to implement them.

Authentication: Who Are You?

Authentication is the process of verifying the identity of a user or entity attempting to access a system or resource. In simpler terms, authentication answers the question, "Who are you?" This process typically involves the user providing some form of credentials, such as a username and password, biometric data, security tokens, or digital certificates. The system then validates these credentials against stored records to determine whether the user is who they claim to be.

Technologies for Authentication:

Username and Password: This is the most common form of authentication, where users provide a unique username and a corresponding password.
Biometric Authentication: With advancements in technology, biometric authentication methods such as fingerprint scanning, facial recognition, iris scanning, and voice recognition are becoming increasingly popular for user authentication.
Security Tokens: Security tokens, such as smart cards or hardware tokens, generate one-time passwords or cryptographic keys that users must provide along with their other credentials.
OAuth 2.0: OAuth is an open-standard authorization protocol that allows users to access resources from one website using their credentials from another website or service without exposing their password. It is commonly used for granting third-party applications limited access to a user's resources without exposing their credentials.
Passwordless Authentication: Passwordless authentication eliminates the need for traditional passwords and relies on alternative methods such as magic links sent via email, SMS-based one-time passcodes (OTPs), or authentication apps. This approach enhances security and user experience by reducing the risk of password-related attacks such as phishing and credential stuffing, while also simplifying the login process for users.

Authorization: What Are You Allowed to Do?

Authorization, on the other hand, comes into play after authentication and determines what actions an authenticated user or entity is permitted to perform within the system. Authorization answers the question, "What are you allowed to do?" It involves defining and enforcing access controls based on the user's identity, role, or other attributes.

Authorization mechanisms specify the level of access granted to users for various resources or functionalities within the system. This could include read-only access, write access, administrative privileges, or custom permissions tailored to specific roles or individuals.

Technologies for Authorization:

OAuth 2.0: While OAuth is primarily an authentication protocol, it also has provisions for authorization through the use of access tokens. OAuth 2.0 enables third-party applications to access resources on behalf of a user with their consent, following a predefined authorization flow. Read, why Access Tokens are not sufficient for fine-grained access control.
Role-Based Access Control (RBAC): RBAC is a widely used authorization model that assigns permissions to roles rather than individual users. Users are then assigned one or more roles that determine their access rights within the system. RBAC simplifies access management by grouping users based on their job functions or responsibilities. This is, what Space Blocks Permissions is doing for fine-grained access control.
Attribute-Based Access Control (ABAC): ABAC defines access controls based on attributes associated with the user, the resource being accessed, and the environment. Policies are defined using attributes such as user roles, location, time of access, and other contextual information to make access decisions dynamically.
Access Control Lists (ACLs): ACLs are a mechanism for defining and enforcing access controls on individual resources. They specify which users or groups are granted access to a particular resource and what operations they are allowed to perform.

Don't build Authentication or Authorization yourself!

Implementing both, Authentication and Authorization on your own can be challenging and complex. You want to make sure, to follow all security requirements for storing user-passwords, for example.

This is, why most developers rely on external tools for Authentication and others for Authorization, which can then be included into their apps. Space Blocks Permissions is a system to integrate fine-grained access control quickly into your apps with a few lines of code, so developers can focus on their core business. If you need to add permissions to your app, give it a try with the free Developer Tier.

Conclusion

In summary, while authentication verifies the identity of users or entities accessing a system, authorization determines what actions they are allowed to perform once authenticated. Understanding the distinction between these two concepts is crucial for designing secure and robust software systems. By implementing appropriate authentication and authorization mechanisms using technologies such as those mentioned above, developers can ensure that their applications remain secure, and only authorized users have access to sensitive resources.

Google Zanzibar implementations

Robin-Manuel Thiel — Wed, 08 May 2024 05:22:00 +0000

Authentication is hard. Implementing fine-grained access control is even harder. Whoever tried to build a sophisticated authentication system themselves knows that. And those who didn't are well advised by not trying to. Proper Authentication is so hard, that 2020 Google published a research paper about the numerous challenges and complexity they faced when implementing a global permission system for YouTube, Google Drive and Google Photos. This research paper is called "Zanzibar".

What the paper is lacking are implementation details. And since its release, some brave developers tried to implement an Authentication system along Google's findings. Here is a list of Google Zanzibar implementations:

1. Space Blocks Permissions

Space Blocks has built the most complete implementation of the Google Zanzibar research paper. It supports hierarchical permission trees, inheritance of access rights and custom roles. It can be hosted on your own servers or in the Space Blocks Cloud, where it provides high-availability and short response times.

Pros:

Completeness: Most complete and feature-rich Zanzibar implementation.
Easy to integrate: Permissions checks are integrated with a few lines of code.
GUI: Graphical Editor for designing and visualizing permission trees.‍
Low Learning Curve: No proprietary modeling language. ****

Cons:

SDK Availability: Only for .NET, JavaScript and React. Other platforms need to use the REST-API
Additional API endpoint required: Your backend might need to implement additional API endpoints for your frontend

2. OpenFGA

Auth0’s OpenFGA project focuses on delivering a universal authorization system. The name stands for “Fine Grained Authorization,” emphasizing a granular approach to modeling authorization that can handle diverse use cases. It is owned by the Cloud Native Foundation.

Pros:

Granularity: Allows fine-grained control over permissions, catering to complex authorization scenarios.
Open-Source Community: Community contributions and improvements are encouraged.
Performance: OpenFGA aims for reliability and performance.

Cons:

Missing Features: Operation for Listing all items a user has access to is incomplete
Steep Learning Curve: Understanding the modeling language schema may require some effort.

‍

3. ORY Keto

An open-source implementation of the Google Zanzibar paper exists in the form of the ****ORY Keto project. The first working version was released, aiming to bring the concepts from the paper to practical use. It can be employed to manage permissions and roles in various applications and websites.

Pros:

Open-Source Community: Being open source, it benefits from community contributions and improvements.
Fast and Efficient: ORY Keto aims for high performance, ensuring rapid decision-making.

Cons:

Steep Learning Curve: The granular permission language might require some learning and understanding.

4. Permify

Permify is another open-source authorization service for creating and managing scalable authorization systems using fine-grained permissions. It draws inspiration from Google’s Zanzibar paper and offers various binding and crafting options, allowing engineers to work with performant, observable, and secure permission systems.

Pros:

Integration: Integrates into many Identity Providers like Okta and Azure Active Directory
Granularity: Allows fine-grained control over permissions, catering to complex authorization scenarios.
Open-Source Community: Benefits from community contributions.

Cons:

Steep Learning Curve: Understanding the modeling schema may require effort.

What is a JWT and why is it not sufficient for fine-grained access control

Robin-Manuel Thiel — Tue, 07 May 2024 08:46:00 +0000

While JWT (JSON Web Tokens) and session-based authentication mechanisms are robust tools for authenticating users and managing sessions, they fall short when it comes to fine-grained access control (FGA), which is where Space Blocks Permissions come into play.

Authentication vs. Authorization

In the realm of securing digital systems, two fundamental concepts often come into play: authentication and authorization. While authentication verifies the identity of a user, authorization dictates what actions they are allowed to perform within a system. So authentication is answering the question of whom the user is. Authorization answers the question of what the user is allowed to do.

How does JWT work?

JWT (JSON Web Token) is a digitally signed JSON document, which includes information about the current user. It usually gets issued to the user by the identity provider, after a user signed in successfully. With every request, the user then sends the JWT to the backend, which can then verify its authenticity at the identity provider and, in case of a positive outcome, decide to let the user do, what they want to do.

The information about the user in the JWT’s payload are called claims. The JWT Standard defines official claims, that a token can have, but any identity provider can also add custom claims. A JWT can hold any kind of information, but usually, you can find the following claims:

iss (issuer): Issuer of the JWT
sub (subject): Subject of the JWT (the user)
aud (audience): Recipient for which the JWT is intended
scope (scope): Actions for which the JWT is intended
exp (expiration time): Time after which the JWT expires
nbf (not before time): Time before which the JWT must not be accepted for processing
iat (issued at time): Time at which the JWT was issued; can be used to determine the age of the JWT

When it comes to authorization (checking, what a user is allowed to do), the aud (audience) and scope (scope) claims of a JWT are interesting.

By checking the audience, a backend service can check, if a caller, that presents a certain token should be allowed to communicate with a specific backend or service (the audiences).

When defining APIs, developers often add scopes like read:secrets or write:secrets to their routes. Depending on how the user acquired the Access Token and which permissions that user has, different scopes are listed in a JWTs claims. Backend services can check these scopes against the ones they defined as required for their APIs, to decide if a user is allowed to call a certain API method or not.

Why JWTs are insufficient for fine-grained access control

As you might have noticed in the example above, JWT claims like audience and scope can only be used to check, if a user can call a certain API method or interact with a certain service at all. It’s all or nothing. The read:secrets scope either allows a user to read secrets in your application or not.

The reality often looks different. In most applications, where users collaborate with and share resources among each other, they have different permissions on different resources. A user might have read and write permissions to all of their own folders, but only read permissions to those that got shared by a teammate. Some permissions can also imply access to other resources without explicitly mentioning them. Read access to a folder usually also implies access to the files and sub-folder within the shared folder.

JWTs are great and have their place in the authorization space, but should only be used to determine if a user should be let into a system and how far. When it comes to fine-grained access control on resource level, a more sophisticated approach like Space Blocks Permissions is needed.

Permissions as a Service with Space Blocks

With the Space Blocks Permissions service, you can offload the burden of managing permissions, roles, groups and inheritance to our Permissions as a Service system and focus on your core project. You can define the structure of your resources and their relationships, define permissions for them, create roles and then just let us know, whenever permissions got assigned or changed.

Your backend can still use JWT for basic authentication, but can check the Space Blocks API for fine-grained access control, once a user got let into your system.

You can integrate Space Blocks into your backend code with a few lines of code and completely for free in the Developer Tier.