DEV Community: Ege Aytin

What is SCIM Provisioning: In-Depth Guide [2024]

Ege Aytin — Tue, 29 Oct 2024 11:08:50 +0000

The ability to outsource and automate repetitive daily tasks is at the core of why SCIM provisioning exists.

In the case of large and medium scale enterprises, when an employee joins a new company for example, they usually require access to all of the necessary tools needed to perform their duties.

This then means that new accounts have to be created with all the right user privileges and packages.

We could flashback to the pandemic when everyone practically went remote and we had to rely on a bunch of software tools to stay productive at work.

Even now, employees of large and medium firms still rely on several different cloud based apps to carry out their daily jobs.

However, we can imagine that when dealing with thousands of users spanning several different cloud based user accounts, this repetitive cycle of handling new cloud identities can easily get complex and untidy if not properly automated. Besides, it could create footprints for security attacks.

What is SCIM provisioning?

One effective way to solve this problem of creating many different user accounts per need is through SCIM provisioning. SCIM provisioning involves setting up an automated workflow that caters to the following needs:

Assigning new user accounts or provisioning users
Updating roles and access levels as needed
Safely removing user identites when they are no longer in use, also known as de-provisioning users.

The System for Cross-domain Identity Management(SCIM) is an open web standard that serves this purpose of providing a way to easily authenticate users of your app across third party services.

How SCIM Works

The SCIM server is a made up of restful API with available endpoints. Information is exchanged over a secure communication protocol. The SCIM client is expected to make a HTTP request call to the server and receive a matching response.

By providing a standardized API and data model, SCIM makes automated user provisioning, de-provisioning and management possible across various clouds apps.

Let's throw more light into the illustration above. We usually have 3 key players involved in the workflow of creating user accounts (otherwise called provisioning) using SCIM standard:

the SCIM Client which is the Identity Service Provider (IdP)
the SCIM service provider
and the cloud apps.

The IdP which has a record of the organizations' user identities initiates requests to the SCIM service provider. Next, the SCIM service provider makes the appropriate changes automatically to all the connected cloud applications.

SCIM defines resources such as User, Group, and ServiceProviderConfig

Each of these resources we just mentioned come with a set of attributes. For example, a User resource includes attributes like userName, emails, displayName, name.

We can also extend the schema contents to include attributes that are specific to our own usecases so it doesn't have to be fixed.

Now, let's have a look at some of the common API operations that can be performed on the SCIM server:

Create: This operation provisions new user and makes a record of their identity on the SCIM data store.
Read: The read operation fetches user identities from the data store.
Update: This make changes to the user identities e.g user changing roles when an employee is promoted.
Delete: The delete operation removes existing resource types from the SCIM data store e.g deleting employee records.

How to implement a custom SCIM Server?

Since SCIM is an open standard, it means we can build our own SCIM server customized to suit specific needs. Once the fundamental ingredients as defined in the specification documents are fulfilled, implementing your customized SCIM server is achievable.

Here is a general overview of the steps to implement your custom SCIM:

Understand the SCIM standard and RFCs
Define your organizational specific requirements identifying which user and group management functionalities you need
Select the technology stack to build your own SCIM variant ensuring it supports Restful API and secure communication protocols
Design your data model making sure it is in line with SCIM's core resource type which are: Users and Group.
Next, implement the core SCIM endpoints based on the specifications.
Implement security. Ensure authentication workflow is secured with OAuth or other means and all exchanges are conducted on HTTPS.
Develop error handling and logging.
Test and proper documentation
Deployment, monitoring and scalability

A minor slack in this custom implementation might open up a window for security mishaps. Thus, most efficient developer teams usually opt for outsourcing this crucial part of the piece.

In the following sections, we will talk in more details about using a third party SCIM services and everything you need to know to make the right choice.

How to Evaluate SCIM providers?

What truly makes the difference is a SCIM provider that fulfills your organizational needs to a considerably large extent. Of course, jumping on just about any shiny new product in the market is not advisable.

Therefore, in this part, we shall talk about the important features you need to look out for when weighing and eventually selecting a SCIM provider to go with.

Key features to look for in SCIM providers

Compatibility with existing systems: You'll want to look out for a provider that makes it easier to plug into your existing company software without breaking it. This ensures to get SCIM up and running without delays.
Ease of integration and deployment: A simplified integration process reduces downtime. This is especially important in a business environment where swift deployment provides a competitive advantage.
Security features and compliance : When selecting a SCIM provider, it is essential to ensure they offer robust security features and are compliant with relevant industry standards and regulations such as GDPR and HIPAA Compliance to name a few.
Scalability and performance: Consider a SCIM provider that can meet the growing needs of your organization or user base.
Customer support and documentation: Timely customer support and well crafted documentation is an indication that the SCIM provider is reliable and ready to assist.

Factors influencing the choice of a SCIM provider

Company size and requirements: A small startup would need to provision less user accounts compared to a medium or large enterprise. So, it's important to pick a SCIM provider with a cost effective package.
Budget and pricing considerations: The allocated amount a company plans to spend on SCIM resources needs to work with the pricing of the chosen SCIM provider.
Specific use cases and industry needs: It's essential to align the features offered by the SCIM provider with your specific industry to know if it can effectively support your organization's identity management requirements.

What are the Top SCIM Providers?

In this section will expand even more into what options exists.

As we take a closer look at the top 5 SCIM providers in the market for 2024, it will help to bear in mind your pressing organizational needs with matching how each provider might possibly fit.

Provider 1. Okta

Okta can be described as an all-in-one identity solution. Users are provisioned using SCIM through the Okta Lifecycle Management (LCM). This ensures that events are triggered at each point whenever any user changes occurs, such as joining or leaving your organization.

Key Features of Okta

Comprehensive identity and access management.
Integrates with a wide range of applications and services allowing for seamless connectivity across different IT environments.
Advanced security features like adaptive multi-factor authentication (MFA) and threat insights.
Lifecycle management to facilitate automatic user provisioning and ensures that data is quickly synchronized as users' come in or leave the organization.
A centralized directory for managing all your user profiles in one place.

Pros

Strong emphasis on security and compliance.
Scalable solution suitable for enterprises of all sizes.
User-friendly interface and extensive support resources.

Cons

Higher cost compared to some competitors.
Complex setup which might require some technical know-how.

Pricing
Okta’s pricing varies based on the specific modules and services used. Basic plans for single sign-on (SSO) start around $2 per user per month, with advanced features and enterprise packages costing significantly more.

Provider 2. WorkOS

WorkOS aims to provide enterprise-grade identity management solutions for your app to help you ship without needing extensive resources or time. It includes a Directory Sync to help you 'build a frictionless user provisioning and deprovisioning workflow for your organization.'

Key Features of WorkOS

Developer-centric with robust APIs and SDKs for backend technologies such as PHP, Python, NodeJS.
Real-time event streaming for provisioning events which gives a better way to update data compared to using webhooks.
A customizable user interface for authentication that supports various authentication types, making it easier for developers to implement secure login flows
Directory Sync for user lifecycle management by syncing with corporate directories like Google Workspace, Azure AD, and more.
Audit logs to maintain regulatory requirements and security standards.

Pros

Easy integration with major identity providers (IdPs) and Human Resources Information System (HRIs).
Flat-rate pricing simplifies budgeting.
Excellent documentation and developer support via Slack.

Cons

Flat-rate pricing may not be cost-effective for smaller organizations.
Limited to the features included in their predefined plans.

Pricing
WorkOS charges $125 per company per month for its SCIM Directory Sync, with discounts for bulk purchases. Custom enterprise plans are also available with additional support and SLAs.

Provider 3. Frontegg

Image credit: Frontegg

Frontegg is built with the goal of modernizing user management for B2B Saas organizations. As shown in the screenshot above, via the admin portal in the dashboard, you can easily set up SCIM provisioning, connect your identity provider and sync data.

Key Features of Frontegg

Full suite of authentication services, including SCIM provisioning.
Advanced security features like behavioral analytics, bot detection, robust encryption and more.
Customizable admin portal where users can manage their profiles, team memberships, roles, and permissions.
Supports a variety of front-end frameworks (React, Angular, Vue, etc.) and provides robust SDKs and APIs for easy integration and customization.
Offers tenant settings, entitlements, fine-grained authorization, and multi-tenancy management, making it suitable for complex organizational structures.

Pros

Strong security features tailored for large tech companies.
Supports a wide range of IdPs.
Self-service configuration through an admin portal.

Cons

May require significant setup knowledge for full utilization.

Pricing
Frontegg’s pricing is primarily based on Monthly Active Users (MAU). Specific pricing details are available upon contacting their sales team, making it less transparent compared to competitors like WorkOS.

Provider 4. Stytch

Stytch offers SCIM provisioning as part of its B2B authentication suite. It facilitates user identity management by providing the relevant SCIM APIs, integrating with the IdP and effecting user changes using webhooks.

Key Features of Stytch

Focus on modern authentication methods like passkeys and biometric auth.
Stytch supports SCIM integration with popular IdPs such as Okta.
Users can enable SCIM provisioning for their existing SAML applications by configuring SCIM connections through the Stytch dashboard or API.
Lightweight and easy-to-integrate solutions.
Implements fine-grained access controls, allowing organizations to define roles and permissions at an organizational level.

Pros

Cost-effective for basic SCIM provisioning needs.
Quick and straightforward integration.
A good fit for startups and smaller businesses.

Cons

Less feature-rich compared to other providers.
Limited support for large-scale enterprise needs.

Pricing
Stytch offers competitive pricing based on MAU, with plans starting at $0.05 per active user per month. They provide a transparent pricing model with additional features available at higher tiers.

Provider 5. OneLogin

OneLogin aims to provide a trusted experience platform with secure, scalable and intelligent experiences.

By integrating SCIM, OneLogin ensures that user data is synchronized and updated in real-time across all connected applications, reducing administrative overhead and enhancing security.

Key Features of OneLogin

Complete access management tools designed to monitor user access within an enterprise IT ecosystem.
Strong integration capabilities with various applications and services.
Advanced and adaptive authentication methods to safeguard user credentials and increase security defenses.
Real-time cloud directory which synchronizes users in your directory to thousands of apps in real-time.
Compliance analysis and reporting to provide audit logs which can be used to generate useful statistics.

Pros

Ease of use and simple integration.
Robust security features, including adaptive authentication.
Scalable for enterprises of various sizes.

Cons

Can be expensive for smaller businesses.
Some users report a steep learning curve for advanced features.

Pricing
OneLogin’s pricing starts at around $2 per user per month for basic SSO and increases with additional features and enterprise requirements.

Comparison table of the top SCIM providers

Factor	Okta	WorkOS	Frontegg	Stytch	OneLogin
Compatibility	Supports a wide range of apps and services	Integrates with major IdPs and HRIS	Broad IdP support and custom integrations	Focused on modern auth methods	Extensive app and service compatibility
Ease of Integration	User-friendly with extensive resources	Developer-centric with robust APIs/SDKs	Self-service admin portal for easy setup	Lightweight and easy to integrate	Easy to integrate
Security Features	Advanced security, adaptive MFA, threat insights	Real-time event streaming, SOC 2 certified	Behavioral analytics, advanced security suite	Basic security features, passkey auth	Adaptive authentication, robust security
Pricing	From $2/user/month, higher for advanced features	$125/company/month, discounts for bulk packages	$0.05/MAU, higher tiers available	Starts at $2/user/month, increases with features	Starts at $4/user/month
Customer Support	Excellent support, including 24/7 availability	Excellent and dedicated support	Excellent support	Great customer support	Good and quick support
Documentation	Excellent, user-friendly documentation	Best-in-class documentation and API references	Good documentation for developers	Extensive and clear documentation	Good documentation for developers

Testimonials from organizations that have benefited from using SCIM

SCIM is rapidly gaining adoption by high tech companies as an effective way of identity management.

For instance, here's what the Director of Product for Indeed, a leading employment website noted :

"Instead of having to jump on a call with the customer, stand by for 30 minutes to redeploy the login app to activate the SSO connection, the Admin Portal allowed the team to consolidate onboarding into just a few, self-serve steps." - Abishek Chhibber, Director of Product, Indeed

How to make the right choice?

In conclusion, we have talked about how SCIM simplifies identity management and ensures productivity as well as how SCIM works.

Most importantly, we have discussed things to consider in choosing a SCIM provider along with recommendations based on specific use cases.

Common pitfalls to avoid during selection process

Choosing a SCIM provider can be a weighty decision. Let's look at some common pitalls engineering teams face.

Overlooking compliance of SCIM providers: The SCIM protocol is an open standard. This means it states some guidelines and rules for implementing it. Meanwhile, different SCIM providers might translate the guidelines in their own way.

Engineering teams wouldn't want to be in a rush rather should make sure to check that the SCIM provider actually follows the standard.

Failure to evaluate compatibility: One common mistake developer teams make is not doing a proper analysis on their existing legacy software to determine if it can easily support SCIM integration. This leads to delay in the overall implementation timeline, risk of server errors and cost implications.
Setting wrong expectations: The SCIM standard is not a one-size-fits-all. Thus, expecting that it will instantly solve all your identity management problems is not the most realistic thing to do. For instance, your IdP (Identity Provider) or SCIM client might not work out of the box with every SCIM service without adding extra customizations here and there. So it's to important to manage expectations.

SCIM Provider recommendations based on specific needs and scenarios

Education Use Case: Managing student, faculty, and staff identities across various systems.

Industry Needs: Scalability, ease of integration, and user-friendly interfaces

Features to Look For:

Scalability: Ability to handle a large number of users and fluctuations in user numbers throughout the academic year.
Ease of Integration: Compatibility with existing educational systems and platforms like LMS (Learning Management Systems).
Self-Service Portals: Enabling students and staff to manage their accounts independently, reducing the administrative burden

SCIM Provider Recommendations
Okta, Frontegg, OneLogin

Healthcare Use Case: Managing access to sensitive patient data and complying with regulations like HIPAA

Industry Needs: High security, stringent compliance, and detailed auditing.

Features to Look For:
HIPAA Compliance: Ensures the SCIM provider follows strict guidelines for protecting health information.

Advanced Security Features: Including encryption, multi-factor authentication (MFA), and automated provisioning/de-provisioning to maintain secure access controls.

Audit Trails: Detailed logging and monitoring to track access and changes to patient data

SCIM Provider Recommendations
Okta, WorkOS, OneLogin

OAuth vs. JWT: Ultimate Comparison

Ege Aytin — Thu, 25 Jul 2024 13:31:49 +0000

One of the most critical decisions in a software development project is selecting security standards. This decisions affects not only the security and performance of your app but also the user experience.

When it comes to web application security, OAuth and JSON Web Tokens (JWT) are the most widely adopted standards.

OAuth and JWT each have different characteristics and purposes, which determine how you use them in your apps.

In this article, we will break down OAuth and JWT and compare their functionalities and use cases.

You will also learn how to use them together to secure web applications. By the end of this article, you will have a clear understanding of when to use each one and how to implement them effectively in your apps.

Understanding OAuth

What is OAuth?

OAuth stands for Open Authorization. It is an authentication protocol that authorizes one application to interact with another on your behalf.

The main goal of OAuth is to allow websites and apps to access a user's information without having the user disclose their passwords. This kind of access is important for making secure apps that work on different platforms.

To further understand OAuth, it's important to grasp the key components involved in the process:

Resource Owner: This is the user that owns the data or resource.
Client: The application requesting access to the user's resource.
Authorization Server: The authorization server sends access tokens to the client after authenticating the user.
Resource Server: This server hosts the resource or data that the client wants to access.

How OAuth Works?

Here's a detailed breakdown of the OAuth flow:

Request Resource: The client asks to access a resource controlled by the user.
Redirect User for Authorization: The client sends the user to the authorization server to begin authorization.
User Consent: The authorization server asks the user to approve the client's request to access their resources.
Provide Consent: The user reviews the request and agrees to it.
Return Authorization Code: After consent, the authorization server redirects the user back to the client with an authorization code.
Exchange Authorization Code for Access Token: The client sends a request to the authorization server to exchange the authorization code for an access token.
Receive Access Token: The authorization server provides the client with an access token.
Request Resource with Access Token: The client uses the access token to request the desired resource from the resource server.
Validate Access Token: The resource server checks the access token to ensure it's valid and has the required permissions.
Provide Resource: If the access token is valid, the resource server gives the requested resource to the client.

OAuth Versions

OAuth has evolved over the years and has two major versions:

OAuth 1.0a: This is the original version. It was secure but hard to use because it needed cryptographic signatures.
OAuth 2.0: This is the more popular version. It's easier to use and more flexible, but it must be implemented carefully to stay secure.

Use Cases of OAuth

OAuth is widely used across various industries and scenarios, including:

Social Media Integration: Letting users login to different services using their social media accounts (e.g., "Log in with Facebook").
API Authorization: Allowing third-party developers to access user data through APIs without needing the user's login details.
Enterprise Applications: Providing secure access to company resources and services from third-party apps.

Examples in the real world include apps like Slack working with Google Drive or fitness trackers connecting with health data platforms.

Understanding JWT (JSON Web Tokens)

What is JWT?

JWT, or JSON Web Token, is a widely used standard for securely transmitting information between parties as a JSON object. This information is secure and can be trusted because it is digitally signed.

The primary goal of JWT is to ensure the integrity and authenticity of the transmitted information. Developers commonly use JWTs to create authentication systems that do not require storing session details, which is known as stateless authentication.

Structure of a JWT

A JWT consists of three parts, which together form the structure of a JWT:

Header
Payload
Signature

Let's break down each structure:

  {
    "alg": "HS256",
    "typ": "JWT"
  }

Header: The header has two parts: the type of token (JWT) and the signing algorithm used, for example, HMAC SHA256 or RSA.
Payload: The payload consists of claims. Claims are statements about an entity, typically the user, along with additional data. There are three types of claims:

* **Registered claims**: These are predefined claims that are not mandatory but recommended, such as `iss` (issuer), `exp` (expiration time), `sub` (subject), and `aud` (audience).
* **Public claims**: Claims that any user can define but should be unique to avoid conflicts.
* **Private claims**: Private claims are custom claims designed to share information between parties who agree to use them.

An example payload might look like this:

  {
    "sub": "1234567890",
    "name": "John Doe",
    "admin": true
  }

This JSON is then encoded using Base64URL to create the second part of the JWT.

Signature: To create the signature, you combine the encoded header and payload with a secret using the specified algorithm from the header and then sign it.

For instance, if you choose to use the HMAC SHA256 algorithm, the signature is created in this manner:

  HMACSHA256(
    base64UrlEncode(header) + "." +
    base64UrlEncode(payload),
    secret)

The output is a JWT as follows:

  header.payload.signature

Example Scenario: User Authentication

Consider a user logging into an application. Here's how JWT can be used to manage the authentication process:

User Login: The user logs in with their credentials (e.g., username and password).
JWT Issuance: After a successful login, the server creates a JWT containing the user's details (claims) and sends it to the client.
Client Storage: The client stores the JWT, typically in local storage or a cookie.
Authenticated Requests: For subsequent requests, the client sends the JWT in the HTTP authorization header.
Token Verification: The server verifies the JWT's signature and checks the claims (e.g., expiration time) to ensure the token is valid.
Access Granted: If the JWT is valid, the server processes the request. Otherwise, it responds with an unauthorized error.

Use Cases of JWT

JWTs have many uses across different scenarios. Some common use cases include:

Authentication: JWTs are often used for user authentication, replacing traditional session management. They offer a way to handle user sessions without storing them.
Information Exchange: JWTs can securely transmit information between parties. Their compact size and URL-safe nature make them well-suited for embedding in URLs, HTTP headers, and other transport methods.
Access Control: JWTs can be used to control access to resources by encoding user roles and permissions in the token, ensuring that only authorized users can access specific resources.

Real-world examples include implementations of single sign-on (SSO), API authentication, and mobile app authentication.

Comparing OAuth and JWT

Key Differences

Purpose and Primary Use Cases: OAuth is used for authorization by allowing third-party apps to access resources securely without sharing sensitive credentials. On the other hand, JWT is used for authentication and for securely exchanging information.
Token Types: OAuth access tokens are opaque and aren't designed for the client to understand; they need validation by the resource server. In contrast, JWTs pack all necessary information within the token itself so they can be verified locally without involving the server.
Complexity and Implementation: OAuth involves multiple steps and interactions between clients, authorization servers, and resource servers. This makes it more complex to implement when compared to JWT.

Pros and Cons

OAuth Advantages

Delegated Access: OAuth's main advantage is that it allows delegated access. This means users can give third-party apps specific permissions without sharing their passwords. OAuth also enhances security by minimizing the risk of exposing user credentials and gives users control over who can access their data.
Granular Permissions: OAuth uses scopes to define what actions an access token can perform. This lets users control the permissions that third-party apps get, ensuring they only have access to what they need.
Refresh Tokens: OAuth can issue refresh tokens, which let apps get new access tokens without needing users to log in again. This improves the user experience by providing continuous access to resources. It also keeps access tokens short-lived, making them less risky if they get compromised.

OAuth Disadvantages

Complexity: The OAuth process has many steps and interactions, which can be tough to implement correctly. Developers need to handle various issues like token expiration and revocation to ensure everything works securely.
Token Management: Managing access and refresh tokens can be complicated, especially with multiple clients and resource servers. Issuing, storing, validating, and revoking tokens requires careful planning.
Server Load: Frequently checking access tokens with the authorization server can slow things down and increase server load. This can affect performance, especially in busy applications where tokens need to be validated often.

JWT Advantages

Stateless Authentication: JWTs enable stateless authentication by including all necessary information within the token. This means servers can check tokens without needing to keep a session state.
Performance: Since JWTs can be checked locally without contacting the server, they can improve performance and reduce delay for client requests. This is helpful in high-traffic environments where reducing server load is important.
Compact and URL-Safe: JWTs are small and can be easily included in URLs, headers, and other transport methods. Their small size and safe encoding make them great for various uses, like API authentication and mobile app sessions.

JWT Disadvantages

Token Size: JWTs can be large because they include claims and a signature, which can increase network usage. This can be a problem in situations with limited bandwidth or when sending tokens often.
Security Risks: Using JWTs securely means following cryptographic principles and best practices carefully. Risks like token leakage, replay attacks, and exposing sensitive data need to be managed with proper token design, encryption, and validation.
No Built-in Revocation: Unlike OAuth, JWTs don't have a built-in way to revoke tokens. Once a JWT is issued, it's valid until it expires, which makes it hard to invalidate tokens immediately if they are compromised or need to be revoked.

How OAuth and JWT Work Together

Integration Scenarios

In many modern applications, OAuth and JWT can be used together. One common setup is using JWTs as OAuth access tokens. In this setup, the authorization server issues a JWT as an access token, which the client then uses to access the resource server.

Here's a detailed example of how this integration works:

Authorization Request: The client application requests authorization from the user to access their resources.
Authorization Grant: The user grants permission, and the client receives an authorization code.
Access Token Request: The client sends the authorization code to the OAuth authorization server.
JWT Issuance: The authorization server generates a JWT as the access token and sends it back to the client.
Resource Request: The client uses the JWT access token to request resources from the resource server.
Token Validation: The resource server validates the JWT by checking its signature and claims, ensuring it is valid and has the necessary permissions.
Resource Response: If the JWT is valid, the resource server processes the request and returns the requested resources to the client.

Benefits of Combining OAuth and JWT

Enhanced Security: Using JWTs as access tokens in OAuth combines their strengths. OAuth provides strong authorization, while JWTs offer a secure and efficient way to send and validate tokens.
Improved Performance: The resource server can check JWTs locally without needing to contact the authorization server, reducing delay and server load.
Interoperability: Using both OAuth and JWT helps different services and apps work together more easily. Many modern APIs and services support both, making it simpler to integrate and secure multiple systems.

Real-World Examples

Several real-world applications use OAuth and JWT together to secure their services. Here are a few examples:

Single Sign-On (SSO): Many enterprise systems use OAuth for SSO, where the authorization server gives out JWTs as access tokens. This lets users log in once and access multiple services without having to log in again.
API Gateway: In microservices setups, an API gateway can use OAuth to authorize clients and issue JWTs as access tokens. The microservices then validate these JWTs locally, leading to a secure and efficient access control.
Mobile and Web Applications: Applications like Google and Facebook use OAuth to authorize third-party apps to access user data. These access tokens, often JWTs, provide an efficient way to manage user sessions and permissions across different platforms.

Choosing the Right Solution

When deciding between OAuth, JWT, or a combination of both for your application, several factors need to be considered. Each technology has its strengths and is suited to different scenarios. Here's a guide to help you choose the right solution based on your requirements.

Factors to Consider

Security Requirements: Think about the security your application needs. If you need detailed access control and want to allow third-party apps to access data, OAuth might be better. If you need a secure way to send user info without keeping session data, JWT is a good choice.
Application Architecture: Consider your app's architecture. For microservices and distributed systems, JWTs are great because they're stateless. OAuth is useful in a centralized setup for handling authorization across different services and platforms.
User Experience and Performance: Consider how your choice affects user experience and performance. JWTs can boost performance by cutting down on server-side checks. However, OAuth offers features like refresh tokens, which can improve user experience by keeping users logged in longer without needing to re-authenticate often.

Recommendations for Different Scenarios

When to Use OAuth

Third-Party Access: If your app needs to let third-party apps access user resources without sharing user credentials, OAuth is the way to go. Examples include logging in with Google, Facebook, or other social media accounts.
Granular Permissions: If your app needs detailed control over permissions with different levels of access, OAuth's scope feature is helpful.
Complex Authorization Workflows: For apps with complex authorization needs, like enterprise systems with multiple roles and permissions, OAuth offers the right framework to manage these securely.

When to Use JWT

Stateless Authentication: If your app needs stateless authentication, where the server can check tokens without keeping session data, JWT is very effective. This approach is common in API authentication and mobile apps.
Single Sign-On (SSO): For SSO, where one login gives access to multiple services, JWTs are useful because they can carry information and be easily validated by different services.
Efficient Information Exchange: When you need a compact, URL-safe way to securely send information between parties, JWTs are a great choice. Their self-contained nature makes sharing and validating info simpler.

When to Combine Both

OAuth with JWT Access Tokens: Combining OAuth with JWT access tokens is a powerful approach for apps needing delegated access and stateless authentication. It blends OAuth's strong authorization with JWT's efficiency and speed.
Microservices Architectures: In microservices setups, using OAuth for initial authorization and issuing JWTs as access tokens lets each microservice check tokens locally. This cuts down on interactions with the authorization server and boosts the overall system performance.
Enhanced Security and Scalability: Using OAuth alongside JWTs enhances security by managing token lifetimes with OAuth's refresh tokens. JWTs also offer a scalable, stateless token validation for each request.

Wrapping Up

In this article, we have explored the differences between OAuth and JWT. Understanding their strengths and use cases is crucial for implementing efficient authentication and authorization mechanisms.

When choosing between OAuth, JWT, or a combination of both, consider your application's specific needs, including security requirements, architecture, user experience, and performance.

By carefully evaluating these factors, you can implement the most appropriate solution to ensure your web apps are both efficient and secure.

How To Build Centralized Authorization System

Ege Aytin — Wed, 24 Jul 2024 15:14:00 +0000

In a centralized authorization, control decisions are managed from one single location and serve the entire application.

Thus, instead of each microservice handling permissions separately, they are designed to check with a central authority to see if someone is allowed to access certain resources or perform specific actions.

What you'll learn:

The primary aim of this piece is to illustrate how you can implement a centralized authorization system while presenting a thorough overview of the subject.

Therefore, in the course of this article, we will cover the following and more;

What a centralized control system entails; how it works, real-world organizations using it, the benefits and tradeoffs of having a central access system in your application and the workflow from an architectural level.
Centralized vs Distributed Authorization Systems and how to effectively decide the most optimal solution with practical use cases
A step by step guide to get started implementing your centralized system using Permify

If you are looking to understand the nooks and cranies of access management systems, then this is for you.

By the end of this piece, you would have gained a full understanding of this topic which will aid you in developing resilient and scalable microservices.

Let's get started!

The Decoupling Authorization Concept

Similar to the idea and essence of separation of concerns when writing code, the decoupling authorization concept falls along that path.

This concept means that our authorization logic is not mingled with the core application code rather it is moved into its own dedicated service or component.

By doing authorization this way, you make the application easier to manage such that updates does not break up the rest of your app.

What is a Centralized Authorization System?

A centralized authorization system establishes a single source of truth for managing all access permissions. This means that all services must be connected to it and communicate as often as needed before they can grant or deny access.

For instance, assume you have a web application that involves different levels of users such as regular users and moderators. A centralized access management makes it possible for you to manage and audit these permissions from one point.

Real world examples where centralized systems are used include companies that provide software infrastructure as a service (IaaS).

They loan their servers to the general public so to say. In order to control and allocate the resources efficiently, a central authorization is used to handle things like user management, protecting customer resources and providing other extra services. We can only imagine what the absence of such a centralized system could lead to– ‘cloud chaos’.

Another case study we’ll consider are software systems that are built to serve the needs of large firms, called enterprise applications. These enterprise systems typically handle big volumes of data across the different departments in an organization. It also needs to accommodate growing needs. Hence, a centralized authorization system is a good fit.

Thus far, we have talked about what a centralized authorization system entails and the problem it solves with real world examples of how organizations use it.

Next, we’ll highlight some of the benefits.

What is Distributed Authorization?

Decentralized or distributed access management involves a structure where control is handled by a number of servers spread across nodes.

In contrast with a centralized pattern, these respective servers are made to cooperate for the purpose of load balancing and are also able to work independently of each other. So they do not need to check with a chief authority before granting permissions.

Strengths and Weaknesses

According to the CAP theorem, a distributed system can only deliver at most two of these: Consistency, Availability and Partition tolerance.

So, this calls for careful consideration of what your application can let go of without any negative consequences to business operations.

With these in mind, let's now weigh the strengths and weaknesses of a centralized and decentralized access management. We'll consider two use cases.

Use case 1: A banking application

For this use case, we may describe the main business requirement as thus:

Availability, reliability: Providing reliable information on financial transactions is necessary to maintain trust and satisfaction.
Security: Safeguarding user accounts and transactions by ensuring the highest level of security possible.
Scalability: As the customer base grows, the application is expected to adapt to this change.

Next, let's see how both authorization systems might compare in meeting these needs in relation to CAP mentioned earlier.

Centralized Authorization Systems

Strengths:
A centralized access management will easily provide consistent and reliable data among the different interfaces that a customer interacts with their banking application because there is only one single source truth.

The central server is often able to achieve high availability of service if it is well designed in a way that authorization requests and responses flow smoothly.

It’s also feasible to implement comprehensive security measures and policies to protect financial transactions and data.

Weaknesses:

When there's a break in transmission, being a single point of failure, the central server is affected leading to a disruption.

A centralized system may struggle or require extra effort to scale as the user base grows.

Decentralized Authorization Systems

Strengths:

Decentralized systems are designed to thrive even when there is a partition because the nodes function independently of one another.

A decentralized system will have higher availability because of the ability to balance the load effectively.

Weaknesses:

Achieving consistency and high security standards across each and every node can be challenging in a decentralized system

Use case 2: A real-time messaging application

For this use case, we can identify our important business needs as:

High availability: Users expect to send and receive messages at any time even during peak periods without downtimes.
Security: They expect their information to be safe and secure even in transmission
Reliability: Users typically expect no delay or lagging.

Centralized Authorization Systems

Strengths:

It’s easy to achieve consistency with a centralized server managing all data and operations

For a small application with sizable requirements, a centralized system will be easier to design, implement and manage.

Weaknesses:

Users that are located far from the central server will experience high latency due to longer network distances which results in slow response times.

There is a single point of failure, which means that when the central server is down, the entire application will be inaccessible.

A centralized system will require more effort to scale as the user base grows.

Decentralized Authorization Systems

Strengths:

There is more room to scale if the user base increases because the workload is shared across different nodes.

With decentralized architecture, data points can be brought closer to the users who are at far locations which can reduce latency and improve user experience and satisfaction rates.

No single point of failure, when one node is down, others pick things up from there and the impact should not be felt.

Weaknesses:

Security is a major concern. Extra effort and financial resources have to be spent to beef up security otherwise it can render the whole application ineffective.

A decentralized architecture is complex and requires solid sync and coordination,
achieving consistency therefore requires constant effort since data needs to be updated frequently in this use case.

How Centralized Authorization Systems Work?

For this section, let’s talk about the nitty gritty of how a centralized system works.

To kick things off, you need to put in your main player in a centralized system, which is the central authorization server. Other microservices will connect to and receive responses from this single server.

To implement this, we need to follow these key steps before anything;

Step I. Identify requirements: Begin by listing the major requirements of your application, the data it will manage and what kind of interactions it will facilitate in day to day processes.

Step II. Design architecture: Based on the needs of the application, map out the architectural plan of your application showing the major components, their interactions, and the flow of data and control.

Step III. Implement Authorization: Decide whether to outsource your authorization service or build from scratch. Follow along as we’ll discuss some incredible benefits of outsourcing in the next few sections.

Step IV. Build microservices: Implement the other core services and business logic of your application.

Step V. Deploy, test and maintain

Great, let’s now take a look at an demo workflow of a centralized architecture.

In the illustration above, our use case is a banking application system.

Here, the client or end-users have their needs met via different provisions such as the web services (online banking portal), mobile app and self service channels.

So within a centralized system, all of these outlets will be connected to a single server behind the scenes.

As shown in the drawing model, we have a Policy Decision Point (PDP) that is responsible for receiving incoming requests and making authorization decisions based on predefined policies and rules.

Now, the PDP works closely with another component known as the Policy Enforcement Point (PEP) which serves as a gateway where endpoint requests hit first, it enforces the decisions sent from the PDP by protecting the app endpoints or resources.

Finally, by application interpolation, developers can make sure that these security and authorization rules are integrated into the core of the application to fulfil the very essence of having it. This means that, for instance, when a user hits a URL /show-document your microservice 'pauses' and places a call over to the policy checkpoint behind the scenes.

As the number of access requests grows however, centralized authorization systems may encounter scalability challenges which could lead to performance issues especially if the authorization service becomes overwhelmed with requests.

The next section will shed more light on these trade-offs for specific use cases which can act like a guide in deciding when centralized management is a fit.

Centralized vs. Distributed Authorization

In this section, we'll talk about a distributed system and discuss more on how it differs from a centralized authorization system.

Weighing these would help you decide which approach suits your application needs making you better prepared to navigate any trade-offs.

Implementing Centralized Authorization Systems with Permify

Permify is an open source service that provides all your authorization needs in one place, a popular choice loved by developers for many reasons.

Thus, delegating your authorization using a service such as Permify ensures that you can get your microservices up and running in good time while having less to worry about.

So, in this section, we will implement a starter centralized access system which you can extend and customize per your application need.

To get started, ensure Docker is running and connect to Permify:

Step I. Connect

In your terminal, type the following command:

docker run -p 3476:3476 -p 3478:3478 ghcr.io/permify/permify serve

You should get a screen showing that Permify service is running.

Step II. Define Authorization Schema

Now, let's model authorization for our second use case mentioned earlier, a real time application where a user can create groups and send messages.

Entites in Permify schema are just like how tables work in a relational database context. It's recommended that you name them similar to your database tables.

We will be using the Permify playground to model our schema.
The complete schema file can be found here

Let's dig in!

entity user {}

entity roles {}

entity message {}

entity chatroom {}

Here, we create 4 entities; user, roles, message, chatroom.

entity roles {
 relation admin @user
}

For the roles entity which would contain privileges, we add a new role to define an admin user.

entity message {
    relation owner @user
    permission create  = owner
}

Next is the message entity. It defines the owner as user and the permission to create a message.

entity chatroom {

    relation parent @roles
    // represents owner of this repository
    relation owner  @user

    // permissions
    permission delete = parent.admin or owner 
}

The chatroom entity links the roles entity as its parent, stating that the user is the owner of the chatroom. Owner and any other admin can delete chatroom.

That's it for our schema.

The Permify playground contains a helpful visualizer tool that shows the schema relationships.

Step III. Connect your schema with Permify authorization service

We have an authorization schema ready. The next thing we'll do is notify Permify server of this schema.

Open up your API design platform and do a POST query to the Write Schema endpoint, supplying the schema we have just created;

localhost:3476/v1/tenants/t1/schemas/write

Make sure to click "Copy" on the Permify Playground to get the string version of your schema.

Great. The above screenshot shows that we have successfully queried the Permify API and received a schema ID back.

Step IV. Store Authorization Data

Permify gives you the ability to store your authorization data in any database of choice and work with it using the Permify DataService.

To do this, we'll send some JSON data to the Write Data API endpoint to add new record which we will then use to perfom access checks.

localhost:3476/v1/tenants/t1/data/write

{
    "metadata": {
        "schema_version": ""
    },
    "tuples": [
        {
            "entity": {
                "type": "chatroom",
                "id": "2"
            },
            "relation": "owner",
            "subject":{
                "type": "user",
                "id": "1",
                "relation": ""
            }
        }
    ]
}

Here, we are assigning a chatroom with id 1 to belong to user with id 4. In other words, the relationship between the user and chatroom is "owner", as defined in our schema.

From our Postman API* screen above, you will notice that Permify returns us a snap token. This feature makes it possible for you to get an up to date results at all times even if your schema later changes.

Step V. Perform authorization checks in your self hosted microservices and receive responses

Now that we have authorization data in place, we are ready to perform checks to and fro.

In essence, your application can now send a request to the authorization service on Permify to verify if a user can be given access to perform the specified action.

Let’s implement this in our demo; We want to verify that a user can delete a chatroom they own.

Make a POST request to the CheckAPI service, include the following JSON in the body section of your request:

localhost:3476/v1/tenants/t1/permissions/check

{
  "metadata": {
    "schema_version": "",
    "snap_token": "",
    "depth": 20
  },
  "entity": {
    "type": "chatroom",
    "id": "2"
  },
  "permission": "delete",
  "subject": {
    "type": "user",
    "id": "1",
    "relation": "owner"
  },
  "context": {
    "tuples": [
      {
        "entity": {
          "type": "chatroom",
          "id": "2"
        },
        "relation": "owner",
        "subject": {
          "type": "user",
          "id": "1",
          "relation": "owner"
        }
      }
    ]
  }
}

The screen above shows a successful check. With this your microservice receives the response CHECK_RESULT_ALLOWED and user can therefore proceed with the required action.

This completes the authorization cycle from our authorization service.

Summary and Conclusion

In this article, we have discussed the types of authorization systems in microservices. Also, we have looked extensively on centralized authorization systems and how it works considering practical use cases.

To solidify our understanding, we have implemented a centralized system in our application using Permify authorization services.

Using the different Permify services, we have gone from constructing a schema to performing access checks in our application. This demonstrates the realism and benefits of outsourcing your authorization needs.

By leveraging the practical knowledge gained from this article, you can implement an efficient centralized authorization system, providing optimal security in your microservices.

Opa Gatekeeper: How To Write Policies For Kubernetes Clusters

Ege Aytin — Thu, 04 Jul 2024 13:37:37 +0000

Due to the presence of tools like kubernetes, it is easier to manage and automate the daily working processes of a microservices environment.

Using policies in your kubernetes will give you maximum control and flexibility especially in areas such as:

Improving the security of your microservices
Active management of limited resources in your cloud infrastructure
Compliance and governance with regulatory laws

By reading this article you will learn:

The benefits of using policies in securing kubernetes environment.
How to set up a system for dispensing policies; how kubernetes and OPA work behind the scenes.
Everything you need to get started writing and running policies within your cluster.

What is Open Policy Agent (OPA)?

Open Policy Agent (OPA) helps us write policy as code using Rego, a declarative language designed specifically for this reason.

With OPA, we can define and enforce policies across various layers of the stack, from kubernetes to microservices.

This approach contributes to consistency, scalability, and agility in managing policies within your kubernetes clusters.

In addition, by using an expressive syntax you can efficiently represent access control rules and complex policy decisions that your organization reaches.

Altogether, this goes a long way to make sure that your kubernetes environment is compliant and secure.

The focus of this article is on writing policies in kubernetes setup.

If you are not familiar with OPA, you can quickly learn more about how it works and implementation details in this article

How OPA And Kubernetes Work Together?

In this section, let us dive a bit more into how you can get Open Policy Agent (OPA) up and running.

Good enough, OPA provides good support for kubernetes as reflected in its documentation so we shall look into how you can integrate it into your kubernetes environment.

But first things first, let's talk about some important components and understand how it works ‘behind the scenes’.

Kubernetes ships with what is called an admission controller. It's a piece of code that acts like a middleman between the kubernetes API itself and any request sent.

Admission controllers can also be used to enforce policies and security measures, making sure that only authorized and properly configured workloads are allowed into the cluster.

They may alter requests to ensure that it is of valid and acceptable form before processing takes place.

So, admission controllers can be of two types: mutating or validating. It's important to understand this aspect as this is where Open Policy Agent (OPA) plugs in.

As to why we need admission controllers in our cluster, the official kubernetes documentation has this to say:

"...a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features you expect..."

In essence, you may choose to use Open Policy Agent (OPA) or write your own custom admission controller, depending on the scope of customizations you are planning to achieve in your kubernetes environment.

What is OPA Gatekeeper?

A kubernetes setup is barely complete without an admission controller. OPA Gatekeeper is one such controller that checks any request coming into the kubernetes API.

Gatekeeper intercepts the request and checks with predefined policies. Based on this check, a request can be denied or granted.

From the illustration above, we see the workflow of how OPA gatekeeper reviews any request that comes into the kubernetes API server.

It also constantly watches for any changes in the elements of the API server such as the pods and services.

So in essence, when you install gatekeeper on kubernetes environment, you can write policies and have them take effect in the cluster.
We will see more of this in a bit.

Writing Policies In Kubernetes Clusters With OPA Gateway

To further understand the benefits and integration scope of OPA gatekeeper in kubernetes, we will cover the following use cases throughout this piece:

This 2-part tutorial will take you step by step through the entire process of how to write and test policies using Open Policy Agent (OPA) in your kubernetes cluster.

In the first part, we'll make use of OPA gatekeeper admission controller to enforce the policies we write, and then, in the second part we shall write our own custom validating controller.

Thus, by the end of this guide you'll have:

Gained knowledge of how OPA policies work within a kubernetes set up
How to write and apply your own policies
A better understanding of the admission controller webhook in Kubernetes; the workflow and how to implement your own validating controller.

Prerequisites

To benefit fully from this practical guide, you need to have the following set up in your local machine:

Ensure you have OPA installed
Minikube : Ensure you have Minikube and a running Kubernates cluster
kubectl: Ensure you have kubectl configured to interact with your cluster.
OPA gatekeeper : Ensure OPA Gatekeeper is installed in your cluster.
Docker and DockerHub account

Let's get right into it.

1. Defining namespaces policies

For this usecase, let's write an OPA policy that states that every namespace create request should have an annotation added to it.

Step I: Create a constraint template file
A ConstraintTemplate defines the structure and logic of the policy. This template will enforce that every namespace must have the team annotation.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredannotations
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredAnnotations
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredannotations

        violation[{"msg": msg}] {
          input.review.kind.kind == "Namespace"
          not input.review.object.metadata.annotations["team"]
          msg := "Namespace must have an annotation 'team'"
        }

Save this YAML to a file named constrainttemplate.yaml then apply it to your cluster:

kubectl apply -f constrainttemplate.yaml

Step II: Create a constraint file

A Constraint uses the ConstraintTemplate to enforce the policy on specific resources—in this case, namespaces.

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredAnnotations
metadata:
  name: require-team-annotation
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]

Save this YAML to a file named constraint.yaml and also apply it to your cluster:

kubectl apply -f constraint.yaml

Step III: Verify the policy

To verify that the policy is working, try creating a namespace without the team annotation. It should be denied.

apiVersion: v1
kind: Namespace
metadata:
  name: demo-namespace

Save this YAML to a file named demo-namespace.yaml and apply it:

kubectl apply -f demo-namespace.yaml

As expected, we get an error response:

Now let's comply with the policy by creating a namespace with the team annotation.

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace
  annotations:
    team: "devops"

Save the above YAML file as test-namespace-with-annotation.yaml and apply it to the cluster.

This time, it creates the namespace successfully.

2. Allocating resources quotas

Next, we want to write a bit more advanced policy that states that namespaces labelled with env:production must have a resource quota applied to them.

Such a policy can be helpful when you want to control or monitor usage of resources and make things more efficient. Let's get started.

Step I: Create the constraint template file

This template will check if namespaces labeled with env: production have a resource quota.

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: k8srequiredresourcequotas
spec:
  crd:
    spec:
      names:
        kind: K8sRequiredResourceQuotas
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequiredresourcequotas

        violation[{"msg": msg}] {
          input.review.kind.kind == "Namespace"
          namespace := input.review.object

          some label_key
          namespace.metadata.labels[label_key] == "production"
          not has_resource_quota(namespace.metadata.name)

          msg := sprintf("Namespace labeled 'env: production' must have a resource quota", [])
        }

        has_resource_quota(namespace_name) {
          some i
          input.review.context.related[i].kind == "ResourceQuota"
          input.review.context.related[i].metadata.namespace == namespace_name
        }

Save this YAML to a file named constrainttemplate.yaml and apply it to your cluster:

kubectl apply -f constrainttemplate.yaml

Step II: Create a constraint file

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredResourceQuotas
metadata:
  name: require-resource-quota-for-production
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]

Save this YAML to a file named constraint.yaml and apply it to your cluster:

kubectl apply -f constraint.yaml

Step III: Verify the policy
To verify that the policy works, let's create a simple test namespace with the production label but without specifying any resource quotas. It should be rejected.

apiVersion: v1
kind: Namespace
metadata:
  name: test-namespace-production-no-quota
  labels:
    env: production

Save this YAML to a file test-namespace-production-no-quota.yaml and apply it:

kubectl apply -f test-namespace-production-no-quota.yaml

As expected, we get an error response when we try to create a namespace, saying that we must assign a quota just like it is stated in our policy file:

Awesome. Let's go ahead and assign a quota for our namespace.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: resource-quota
  namespace: default
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

Save this YAML to a file named resource-quota.yaml and apply it:

kubectl apply -f resource-quota.yaml

After applying as shown above, the namespace creation and quota application is successful.

You can also go further to actually check the assigned quota for the namespace with the command:

kubectl get resourcequotas -n default

Thus far, we have seen how OPA gatekeeper acts as middleman or interceptor whenever we want to perform specific actions in kubernetes.

Let's now move to the final part, which is creating our own custom validation webhook.

3. Writing a custom controller

To begin, create and switch to a seperate folder specifically for this entire drill, you can call it webhook_server.

1. Start the Minikube cluster.
minikube start

2. Write the validating logic for the webhook. We'll write this in Python but it can also be written in any other language of choice.
Create a file app.py and copy the following contents.

from flask import Flask, request, jsonify
import logging

app = Flask(__name__)
logger = logging.getLogger(__name__)

@app.route('/validate', methods=['POST'])
def validate_pod():
    try:
        admission_review = request.get_json()
        pod_spec = admission_review['request']['object']['spec']

        # Add your validation logic here
        # Example: Check if the pod has a specific label
        labels = pod_spec.get('labels', {})
        if 'app' not in labels:
            logger.error("Pod validation failed: Missing 'app' label")
            return jsonify({"response": {"allowed": False, "status": {"reason": "MissingAppLabel"}}}), 200

        # If all validation checks pass
        logger.info("Pod validation succeeded")
        return jsonify({"response": {"allowed": True}}), 200

    except Exception as e:
        logger.exception("An error occurred during pod validation")
        return jsonify({"response": {"allowed": False, "status": {"reason": "InternalServerError"}}}), 500

if __name__ == '__main__':
    # Configure logging
    logging.basicConfig(level=logging.INFO)

    # Start the Flask app
    app.run(host='0.0.0.0', port=8080, debug=False)

3. We need to containerize this webhook server, build and push it to a DockerHub repository.
I. Create a repository on your Dockerhub account.
II. Create a Dockerfile in the folder with the following contents:

touch Dockerfile

FROM python:3.9-slim

WORKDIR /app

COPY requirements.txt .

RUN pip install --no-cache-dir -r requirements.txt

COPY app.py .

CMD [ "python", "app.py" ]

III. Build the image
docker build -t your-username/repository-name:latest .

IV. Push it to DockerHub

 docker login

docker tag <repository-name>:latest your-username/repository-name:latest
docker push your-username/repository-name:latest

Now, the image should be live on Dockerhub. This means we can now use it in our deployment yaml file.

💡Troubleshooting tip: if you experience request denied errors while pushing your docker image to DockerHub, ensure to login to docker on terminal, double check for any typos or mismatch in the image name, repository name and tagname.

4. Generate TLS Certificates. This helps to secure communication between our webhook server and kubernetes. It is a crucial step to pay attention to. If not properly configured, you might end up getting TLS errors down the line.

openssl req -x509 -newkey rsa:4096 -keyout server.key -out server.crt -days 365 -nodes -subj "/CN=pod-validation-webhook.default.svc"

kubectl create secret tls pod-validation-webhook-tls --cert=server.crt --key=server.key -n default

5. Create the deployment YAML file.

touch webhook-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pod-validation-webhook
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pod-validation-webhook
  template:
    metadata:
      labels:
        app: pod-validation-webhook
    spec:
      containers:
      - name: cweb
        image: cannarron/cweb:latest
        ports:
        - containerPort: 8080
        volumeMounts:
        - name: tls-certs
          mountPath: /etc/webhook/certs
          readOnly: true
      volumes:
      - name: tls-certs
        secret:
          secretName: pod-validation-webhook-tls

6. Create a service
We need to create a kubectl service resource to point back to our Python webhook server
touch webhook-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: pod-validation-webhook
spec:
  selector:
    app: pod-validation-webhook
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080

7. Create the validation configuration file.
The validation configuration file is what officially registers our webhook as part of the kubernetes API. In other words, kubernetes will be aware that there's a new middleman that should be called whenever a pod creation request is sent.

touch validating-webhook-config.yaml

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: pod-validation-webhook
webhooks:
  - name: pod.validation.example.com
    clientConfig:
      service:
        name: pod-validation-webhook
        namespace: default
        path: "/validate"
      caBundle: <base64 encoded ca.crt>
    admissionReviewVersions:
      - v1
    sideEffects: None
    timeoutSeconds: 5
    failurePolicy: Fail
    matchPolicy: Equivalent
    rules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]

8. Apply manifest files; Let's apply the deployment, service and validation configuration files YAML we have created in the earlier steps.

kubectl apply -f webhook-deployment.yaml
kubectl apply -f webhook-service.yaml
kubectl apply -f validating-webhook-config.yaml

9. Verify.
Finally if the deployment goes well, then you should see the pod running successfully. And the validation webhook should be active as well
To verify that our validation hook is now active, based on the validation rules set in the webhook, we simply create a test pod without a label which request should be denied.

Summary and Conclusion

In this comprehensive guide, we have talked about using policies in kubernetes to extend its features and add custom enhancements or team preferences. We have also gone through step by step on implementing kubernetes policies with practical usecases.

Using policies in your kubernetes setup is a creative way to fully explore the capabilities within your containerized deployments and make it more secure.

How to Implement Two-Factor Authentication (2FA) in Golang

Ege Aytin — Mon, 01 Jul 2024 13:47:22 +0000

Authentication is crucial for ensuring security and passwords alone are no longer sufficient to protect against unauthorized access. That's where Two-Factor Authentication comes in. By requiring users to provide two forms of identification, such as a password and a temporary code, 2FA significantly reduces the risk of unauthorized access.

In this tutorial, we will explore how to implement Two-Factor Authentication (2FA) in Golang.

Prerequisites

Before you begin implementing Two-Factor Authentication (2FA) in your Golang web application, ensure you have the following prerequisites in place:

Basic knowledge of Golang programming language.
Go development environment set up on your machine.
Familiarity with web development concepts such as HTTP requests and HTML templates.
A text editor or integrated development environment (IDE) for writing and editing Go code.

Let's start with understanding the basics of Two-Factor Authentication and how it works.

Understanding Two-Factor Authentication (2FA)

How 2FA Works

Two-Factor Authentication (2FA) adds an additional layer of security to the traditional username and password login process. It requires users to provide two forms of identification before granting access to their accounts. Let's understand how it works with a real-life scenario:

Online Banking:

Single-Factor Authentication: Imagine logging into your online banking account with just your username and password. While this provides some level of security, it's vulnerable to password theft or hacking.
Two-Factor Authentication (2FA): Now, let's add an additional step. After entering your username and password, instead of immediately gaining access, you receive a one-time code on your smartphone via a text message or a dedicated authentication app.
- Something You Know (Password): Your regular username and password.
- Something You Have (One-Time Code): The one-time code sent to your smartphone.
So, to access your account, you not only need to know your password but also have access to your smartphone to retrieve the one-time code. Even if someone knows your password, they can't log in without also having your smartphone.

What is Time-Based One-Time Passwords (TOTP) ?

Time-Based One-Time Passwords (TOTP) is a common method used for implementing 2FA. TOTP generates a temporary six-digit code that changes every 30 seconds, providing an additional layer of security.

Here's how TOTP works:

Shared Secret: A unique secret key is shared between the user's device and the authentication server.
Time Synchronization: Both the user's device and the server use the current time to generate the one-time password.
Algorithm: TOTP uses a cryptographic algorithm, typically HMAC-SHA1, to generate the one-time password.
Validity Period: Each one-time password is valid for a short period, typically 30 seconds.

For example, when setting up TOTP for a user:

The server generates a secret key and shares it with the user's device.
The user's device uses this secret key along with the current time to generate the six-digit code.
When logging in, the user provides both their regular password and the current six-digit code generated by their device.
The server verifies the code by using the shared secret key and checking its validity within the time window.

Now, that you have basic understanding of 2FA and TOTP. Let's start implementing it in a Golang Web App.

Setting Up Your Golang Environment

To set up your Golang environment for implementing 2FA, follow these steps:

Install Golang: If you haven't already, download and install Golang from the official website: https://golang.org/.
Set Up Your Workspace: Create a directory for your Golang projects. For example:
```
mkdir go-2fa-demo
cd go-2fa-demo
```

Clone the Example Project: Clone the example project provided in this tutorial or create a new Golang project structure similar to the one shown below:

go-2fa-demo/
├── main.go
├── templates/
│   ├── dashboard.html
│   ├── index.html
│   ├── login.html
│   ├── qrcode.html
│   └── validate.html

Install Dependencies: This project uses a third-party library for generating TOTP (Time-Based One-Time Passwords). Install the library using the following command:
```
go get github.com/pquerna/otp/totp
```
Verify Installation: Ensure that your Golang environment is set up correctly by running the example project. Execute the following command in the terminal:
```
go run main.go
```
You should see a message indicating that the server is starting at port 8080.

Once you've completed these steps, your Golang environment will be ready for implementing Two-Factor Authentication in your web application.

Implementing Two-Factor-Authentication in Golang

In this section, we'll walk you through the process of implementing Two-Factor Authentication (2FA) in your Golang web application.

The below project is only for demonstration purposes; in production, the application would require additional security measures and features. The complete code of the project is provided in this GitHub repository.

Step 1: Choosing a 2FA Method

Choosing the right Two-Factor Authentication (2FA) method is crucial for ensuring the security of your application. There are several 2FA methods available, each with its own advantages and considerations. In this tutorial, we'll focus on implementing Time-Based One-Time Passwords (TOTP) using the Google Authenticator app as the authenticator.

Why TOTP?

Time-Based One-Time Passwords (TOTP) is a popular 2FA method widely adopted by many online services. Here's why TOTP is a good choice:

Security: TOTP generates temporary codes that expire after a short period, making them less susceptible to replay attacks.
Offline Capability: TOTP does not require an internet connection for code generation, allowing users to authenticate even when offline.
Standardization: TOTP is standardized under RFC 6238, ensuring compatibility with various authentication apps and libraries.
User-Friendly: TOTP codes are easy to generate and enter, providing a seamless user experience.

Considerations

Before implementing TOTP in your application, consider the following:

User Adoption: Ensure that your users are familiar with TOTP and comfortable using authentication apps like Google Authenticator.
Backup Mechanism: Provide users with backup codes in case they lose access to their authentication device.
Security vs. Convenience: Strike a balance between security and convenience by implementing additional security measures like rate limiting without compromising user experience.

Once you find a 2FA method suitable to your need, you can easily intergrate it to your web app using a library.

Step 2: Integrating 2FA Library

After choosing a 2FA method, the next step is to integrate a third-party library that provides functionality for generating and validating TOTP codes. In our example project, we're using the github.com/pquerna/otp/totp library.

The github.com/pquerna/otp/totp library is a popular choice for implementing TOTP in Golang applications. Here's why it's a preferred option:

Feature-Rich: The library provides comprehensive support for TOTP generation, validation, and customization.
Well-Maintained: Developed and maintained by a reputable author, the library receives regular updates and bug fixes.
Community Support: Being widely used in the Golang ecosystem, the library benefits from a supportive community and extensive documentation.

Installation

To integrate the github.com/pquerna/otp/totp library into your Golang project, use the following command:

go get github.com/pquerna/otp/totp

This command will download and install the library and its dependencies, making it ready for use in your application. Now, we are ready to start implementing the 2FA in our application.

Step 3: Setting Up Routes

Now, the next thing we have to do is set up the routes in our web app to handle the incoming requests. Setting up routes in your Golang web application is crucial for handling different HTTP requests and directing users to the appropriate handlers. In this section, we'll demonstrate how to set up routes in your project using the net/http package.

Importing Required Packages

Before defining routes, ensure you import the necessary packages:

import (
    "net/http"
)

Defining Routes

In the main.go file of your project, define routes using the http.HandleFunc() function. Each route corresponds to a specific URL path and is associated with a handler function that processes requests to that path.

func main() {
    // Define routes
    http.HandleFunc("/", homeHandler)
    http.HandleFunc("/login", loginHandler)
    http.HandleFunc("/dashboard", dashboardHandler)
    http.HandleFunc("/generate-otp", generateOTPHandler)
    http.HandleFunc("/validate-otp", validateOTPHandler)

    // Start the server
    http.ListenAndServe(":8080", nil)
}

In the above code:

http.HandleFunc(): This function registers a handler function for the given pattern (URL path). It takes two arguments: the URL pattern and the handler function to execute when a request matches the pattern.
Routes:
- /: Handles requests to the root URL and directs users to the homepage.
- /login: Handles login requests and processes user authentication.
- /dashboard: Handles requests to access the dashboard after successful authentication.
- /generate-otp: Handles requests to generate a One-Time Password (OTP) for Two-Factor Authentication (2FA).
- /validate-otp: Handles requests to validate the OTP entered by the user during the 2FA setup or login process.

Step 4: Creating Homepage

The homepage serves as the entry point to your web application, providing users with initial information and navigation options. In this section, we'll create the homepage for our Golang web application and set up the corresponding handler function.

Template File

First, create an HTML template file named index.html in the templates directory of your project. This file will define the structure and content of the homepage.

<!-- templates/index.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Go 2FA Demo</title>
    <link rel="stylesheet" href="<https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css>">
</head>
<body>
<div class="container mt-5">
    <h1 class="mb-3">Welcome to the Go 2FA Demo</h1>
    <a href="/login" class="btn btn-primary">Login</a>
</div>
</body>
</html>

Handler Function

Next, define a handler function named homeHandler in your main.go file to render the homepage when users access the root URL.

func homeHandler(w http.ResponseWriter, r *http.Request) {
    // Execute the index.html template
    err := templates.ExecuteTemplate(w, "index.html", nil)
    if err != nil {
        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        return
    }
}

In the above code:

Template File: The index.html template defines the structure of the homepage using HTML markup. It includes a welcome message and a button to navigate to the login page.
Handler Function: The homeHandler function is responsible for handling requests to the root URL ("/"). It executes the index.html template and sends the rendered HTML content as the response.

Step 5: Creating Login Page

The login page is a crucial component of your web application, allowing users to authenticate and access protected resources. In this section, we'll create the login page for our Golang web application and set up the necessary handler function.

Template File

Begin by creating an HTML template file named login.html in the templates directory. This file will define the structure and content of the login page.

<!-- templates/login.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Login</title>
    <link rel="stylesheet" href="<https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css>">
</head>
<body>
<div class="container mt-5">
    <h1 class="mb-3">Login</h1>
    <form action="/login" method="post" class="needs-validation">
        <div class="form-group">
            <label for="username">Username:</label>
            <input type="text" id="username" name="username" class="form-control" required>
        </div>
        <div class="form-group">
            <label for="password">Password:</label>
            <input type="password" id="password" name="password" class="form-control" required>
        </div>
        <button type="submit" class="btn btn-success">Login</button>
    </form>
</div>
</body>
</html>

Handler Function

Next, define a handler function named loginHandler in your main.go file to render the login page and handle user authentication.

func loginHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method == "GET" {
        // Render the login.html template for GET requests
        err := templates.ExecuteTemplate(w, "login.html", nil)
        if err != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            return
        }
        return
    }

    // Handle POST requests for user authentication
    // (Code for handling form submission and user authentication)
}

In the above code:

Template File: The login.html template defines the structure of the login page using HTML markup. It includes form fields for entering the username and password, along with a submit button for initiating the login process.
Handler Function: The loginHandler function is responsible for handling requests to the /login URL path. For GET requests, it renders the login.html template to display the login page. For POST requests, it will handle form submission and user authentication (to be implemented).

Step 6: Handling User Authentication

User authentication is a critical aspect of web applications, ensuring that only authorized users can access protected resources. In this section, we'll implement the logic for handling user authentication in our Golang web application.

Handler Function

In the loginHandler function of your main.go file, implement the logic to authenticate users based on the provided credentials.

func loginHandler(w http.ResponseWriter, r *http.Request) {
    if r.Method == "GET" {
        // Render the login.html template for GET requests
        err := templates.ExecuteTemplate(w, "login.html", nil)
        if err != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
            return
        }
        return
    }

    // For POST requests, parse form data
    if err := r.ParseForm(); err != nil {
        http.Error(w, "Error parsing form", http.StatusBadRequest)
        return
    }

    // Retrieve username and password from the form data
    username := r.Form.Get("username")
    password := r.Form.Get("password")

    // Perform user authentication
    user, ok := users[username]
    if !ok || user.Password != password {
        // If authentication fails, redirect to the login page
        http.Redirect(w, r, "/login", http.StatusFound)
        return
    }

    // If authentication succeeds, redirect to the dashboard
    http.Redirect(w, r, "/dashboard", http.StatusFound)
}

In the above code:

Handler Function: The loginHandler function handles both GET and POST requests to the /login URL path. For GET requests, it renders the login page using the login.html template. For POST requests, it parses the form data to retrieve the username and password entered by the user.
User Authentication: Inside the POST request handling block, the function attempts to authenticate the user based on the provided credentials. It checks if the username exists in the users map and verifies that the password matches the stored password for the user. If authentication fails, the user is redirected back to the login page. If authentication succeeds, the user is redirected to the dashboard.

Step 7: Generating TOTP Secret

Generating a Time-Based One-Time Password (TOTP) secret is the initial step in setting up two-factor authentication (2FA) for your web application. In this section, we'll implement the functionality to generate a TOTP secret for each user.

Handler Function

Create a handler function named generateOTPHandler in your main.go file to handle the generation of TOTP secrets.

func generateOTPHandler(w http.ResponseWriter, r *http.Request) {
    // Retrieve username from the query parameters
    username := r.URL.Query().Get("username")

    // Retrieve user details from the in-memory "database"
    user, ok := users[username]
    if !ok {
        http.Redirect(w, r, "/", http.StatusFound)
        return
    }

    // Generate TOTP secret if not already generated
    if user.Secret == "" {
        secret, err := totp.Generate(totp.GenerateOpts{
            Issuer:      "Go2FADemo",
            AccountName: username,
        })
        if err != nil {
            http.Error(w, "Failed to generate TOTP secret.", http.StatusInternalServerError)
            return
        }
        user.Secret = secret.Secret()
    }

    // Construct the OTP URL for generating QR code
    otpURL := fmt.Sprintf("otpauth://totp/Go2FADemo:%s?secret=%s&issuer=Go2FADemo", username, user.Secret)

    // Prepare data to pass to the template
    data := struct {
        OTPURL   string
        Username string
    }{
        OTPURL:   otpURL,
        Username: username,
    }

    // Render the qrcode.html template with the OTP URL data
    err := templates.ExecuteTemplate(w, "qrcode.html", data)
    if err != nil {
        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        return
    }
}

In the above code:

Handler Function: The generateOTPHandler function handles requests to generate TOTP secrets for users. It retrieves the username from the query parameters, then checks if the user exists in the in-memory "database". If the user exists, it generates a TOTP secret using the totp.Generate function from the otp/totp package. The generated secret is stored in the user's data structure. If the secret is successfully generated, the function constructs an OTP URL for generating a QR code. Finally, it renders the qrcode.html template with the OTP URL data.

Step 8: Displaying QR Code

Displaying a QR code is a convenient way to enable users to set up two-factor authentication (2FA) using authenticator apps. We will create a seperate HTML file to display the QR code in our app.

Template File

Create an HTML template file named qrcode.html in the templates directory. This file will define the structure and content for displaying the QR code.

<!-- templates/qrcode.html -->
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>QR Code</title>
    <link rel="stylesheet" href="<https://stackpath.bootstrapcdn.com/bootstrap/4.5.2/css/bootstrap.min.css>">
</head>
<body>
<div class="container mt-5 text-center">
    <h1 class="mb-3">Scan QR Code with Authenticator App</h1>
    <img src="<https://chart.googleapis.com/chart?cht=qr&chl={{.OTPURL}>}&chs=180x180&choe=UTF-8&chld=L|2" class="img-fluid mb-3" alt="QR Code">
    <form action="/validate-otp" method="get">
        <input type="hidden" name="username" value="{{.Username}}">
        <button type="submit" class="btn btn-primary">I've Scanned the QR Code</button>
    </form>
</div>
</body>
</html>

In the above code:

Template File: The qrcode.html template defines the structure of the page for displaying the QR code. It includes an <img> tag to display the QR code image generated using the Google Chart API. Additionally, it provides a button for users to indicate that they have scanned the QR code with their authenticator app.

Step 9: Validating TOTP Code

Validating the Time-Based One-Time Password (TOTP) code submitted by users is important for ensuring the security of the two-factor authentication (2FA) process. In this section, we'll implement the functionality to validate the TOTP code entered by users.

Handler Function

Create a handler function named validateOTPHandler in your main.go file to handle the validation of TOTP codes.

func validateOTPHandler(w http.ResponseWriter, r *http.Request) {
    switch r.Method {
    case "GET":
        // Retrieve the username from the query parameters
        username := r.URL.Query().Get("username")

        // Render the validate.html template, passing the username to it
        err := templates.ExecuteTemplate(w, "validate.html", struct{ Username string }{Username: username})
        if err != nil {
            http.Error(w, "Internal Server Error", http.StatusInternalServerError)
        }

    case "POST":
        // Parse form data
        if err := r.ParseForm();

    err != nil {
            http.Error(w, "Error parsing form", http.StatusBadRequest)
            return
        }

    // Retrieve username and TOTP code from form data
    username := r.FormValue("username")
    otpCode := r.FormValue("otpCode")

    // Retrieve user details from the in-memory "database"
    user, exists := users[username]
    if !exists {
        http.Error(w, "User does not exist", http.StatusBadRequest)
        return
    }

    // Validate the TOTP code using the TOTP library
    isValid := totp.Validate(otpCode, user.Secret)
    if !isValid {
        // If validation fails, redirect back to the validation page
        http.Redirect(w, r, fmt.Sprintf("/validate-otp?username=%s", username), http.StatusTemporaryRedirect)
        return
    }

    // If validation succeeds, set a session cookie and redirect to the dashboard
    http.SetCookie(w, &http.Cookie{
        Name:   "authenticatedUser",
        Value:  "true",
        Path:   "/",
        MaxAge: 3600, // 1 hour for example
    })
    http.Redirect(w, r, "/dashboard", http.StatusSeeOther)

    default:
        http.Error(w, "Method Not Allowed", http.StatusMethodNotAllowed)
    }
}

In the above code:

Handler Function: The validateOTPHandler function handles both GET and POST requests. When a GET request is received, it retrieves the username from the query parameters and renders the validate.html template, passing the username to it.
When a POST request is received, it parses the form data to retrieve the username and the TOTP code submitted by the user. It then validates the TOTP code using the TOTP library. If the code is valid, it sets a session cookie to indicate successful authentication and redirects the user to the dashboard. If the code is invalid, it redirects the user back to the validation page for another attempt.

Step 10: Dashboard Handler

The dashboard handler is responsible for rendering the dashboard page once a user has successfully authenticated.

Handler Function

Create a handler function named dashboardHandler in your main.go file to handle dashboard requests.

func dashboardHandler(w http.ResponseWriter, r *http.Request) {
    // Retrieve the authenticated user's username from the session cookie
    username, err := r.Cookie("authenticatedUser")
    if err != nil || username.Value == "" {
        // If user is not authenticated, redirect to the homepage
        http.Redirect(w, r, "/", http.StatusFound)
        return
    }

    // Render the dashboard.html template
    err = templates.ExecuteTemplate(w, "dashboard.html", nil)
    if err != nil {
        http.Error(w, "Internal Server Error", http.StatusInternalServerError)
    }
}

In the above code:

Handler Function: The dashboardHandler function retrieves the authenticated user's username from the session cookie. If the user is not authenticated (i.e., the session cookie is not present or expired), it redirects the user to the homepage. If the user is authenticated, it renders the dashboard.html template to display the dashboard page.

Testing Your Two-Factor Authentication (2FA) Implementation

Testing your two-factor authentication (2FA) implementation is essential to ensure its robustness and effectiveness in enhancing security.

Running the Application and Testing

To run the application and test the 2FA implementation, follow these steps:

Run the Application: Start the web server by running the main Go file using the go run command:
```
cd go-2fa-demo
go run main.go
```
Access the Application: Open a web browser and navigate to http://localhost:8080/ to access the application.
Login: Click on the "Login" button to initiate the authentication process.
Enter Credentials: Enter the username and password (e.g., "john" and "password") to proceed.
Generate QR Code: After successful login, a QR code will be generated for TOTP setup.
Scan QR Code: Use a TOTP-compatible authenticator app, such as Google Authenticator, to scan the QR code and set up 2FA for the user account.
Test Authentication: Enter the TOTP code generated by the authenticator app to verify successful authentication.

Google Authenticator

Google Authenticator is a widely used authenticator app that generates TOTP codes for 2FA authentication. It securely stores secrets and generates time-based codes, enhancing security for user accounts.

To set up Google Authenticator:

Install the App: Download and install the Google Authenticator app from the App Store (iOS) or Google Play Store (Android).
Add an Account: Open the app and select "Scan a QR code" or "Manual entry" to add a new account.
Scan QR Code: Use the device's camera to scan the QR code displayed on the application's login page.
Verify Setup: Once scanned, the app will display a six-digit TOTP code that refreshes every 30 seconds. Enter this code into the application to verify the setup.

Best Practices for Two-Factor Authentication (2FA)

Implementing two-factor authentication (2FA) in your Golang web application is an important step towards enhancing security. However, to ensure its effectiveness and usability, it's essential to follow best practices. In this section, we'll discuss key best practices for implementing 2FA.

1. Inform Users About Backup Codes

Educate users about the importance of backup codes and provide mechanisms for generating and securely storing them. Backup codes serve as a fallback option in case primary authentication methods are unavailable.

2. Rate Limiting Authentication Attempts

Implement rate-limiting mechanisms to prevent brute-force attacks and unauthorized access attempts. Limit the number of login attempts within a specific time frame to mitigate the risk of credential stuffing attacks.

3. User Experience Considerations

Prioritize user experience during the 2FA setup and authentication process. Design intuitive interfaces, provide clear instructions, and minimize friction to encourage users to adopt 2FA without frustration.

4. Secure Storage of Secrets

Ensure the secure storage of user secrets and sensitive information related to 2FA. Implement robust encryption and hashing techniques to protect user data from unauthorized access or disclosure.

Conclusion

In this tutorial, we've explored the implementation of two-factor authentication (2FA) in Golang web applications. We started by understanding the concept of 2FA and its significance in enhancing security for web applications.

We discussed the prerequisites for implementing 2FA and provided step-by-step guidance on setting up the Golang environment and integrating a 2FA library into the project. We covered various aspects of 2FA implementation, including generating and storing secrets, handling user authentication, and validating TOTP codes.

Now, you are ready to easily add 2FA in your Golang Web Application. You can find the complete project code in this GitHub Repo.

Fine-Grained Access Control (FGAC): Comprehensive Guidance

Ege Aytin — Wed, 12 Jun 2024 12:07:40 +0000

Securing who can access what under which conditions,also known as authorization, is a crucial part of software systems due to scaled cloud-native environments, distinct and multi-service architectures, never-ending business requirements and so on.

Role Based Access Control (RBAC) is one of the most popular and traditional way to apply access controls in your applications and services.

To give a brief explanation of RBAC, someone is assigned a role and they inherit the permissions associated with that role. For instance, managers might have access to certain files that entry-level employees do not.

The pitfalls of RBAC model is; its coarse-grained, inflexible, and cannot scale.

That's why most companies choose Fine-Grained Access Control over coarse grained RBAC.

This guide is tailored to explain Fine-Grained Access Control (FGAC), highlight its significance, and provide a step-by-step implementation for your applications.

What is Fine-Grained Access Control (FGAC)?

Fine-Grained Access Control is a detailed and nuanced approach to access control within your company's requirements.

Unlike coarse grained access control models that might grant access to large sections of data or functions based on a single factor like roles, fine-grained authorization allows you to specify access rights at a much more specific level, including Attribute-Based Access Control (ABAC) and Relationship-Based Access Control (ReBAC).

This means you can define not just who can access a resource, but under what precise conditions they can do so, including actions like viewing, editing, sharing, or deleting.

Imagine a healthcare application that manages patient records.

With fine-grained authorization, you can set up access controls that reflect the complex needs and privacy requirements of the healthcare industry.

Here’s how it might work:

Doctors: Can view and edit the medical records of their current patients but cannot access records of patients they are not treating. Additionally, they might be allowed to share records with other doctors within the same hospital for consultation, but only if the patient has consented to this sharing.
Nurses: Have view access to patient records but can only edit sections related to nursing care, such as notes on medication administration or patient vitals. Their access is limited to patients they are currently assigned to.
Administrative Staff: Can access patient contact information and billing details but cannot view medical history or notes made by the healthcare professionals.
Patients: Can view their own medical records through a patient portal but cannot make any edits. They may be given the option to share their records with external healthcare providers, but this action requires explicit patient consent and generates an audit trail.

By defining specific access controls for different user roles and conditions, the healthcare application can protect sensitive information, comply with privacy regulations, and ensure that users have the access they need to perform their roles effectively.

Why Companies Should Look for Fine-Grained Access Control?

Here are the compelling reasons why companies should prioritize fine-grained authorization:

Enhanced Security

By defining access with precision, fine-grained authorization minimizes the risk of unauthorized access to sensitive data.

This precision ensures that individuals have access only to the data and functions necessary for their roles, significantly reducing the attack surface for potential cyber threats.

Compliance and Privacy

Many industries are governed by strict regulatory requirements regarding data access and privacy (e.g., GDPR in Europe, HIPAA in healthcare).

Fine-Grained Access Control allows companies to meet these regulations head-on by enforcing access policies that protect personal and sensitive information, thereby avoiding hefty fines and reputational damage.

Operational Flexibility and Efficiency

In the dynamic landscape of business operations, roles and responsibilities can change rapidly.

Fine-Grained Access Control facilitates quick adjustments to access rights, ensuring that employees have the resources they need when they need them, without compromising security. This agility enhances overall operational efficiency and productivity.

Audit and Oversight

Implementing fine-grained authorization enables detailed logging and auditing of access to resources, providing clear visibility into who accessed what and when.

This capability is invaluable for investigating security incidents, monitoring compliance, and refining access controls over time.

How to Build a Fine-Grained Access Control?

In this section, we'll show how to implement Fine-Grained Access Control in our example Golang application

For implementation we'll use Permify, an open source authorization service that enables developers to implement fine-grained access control scenarios easily.

Let's dive deeper into how to use Permify to build a fine-grained authorization system, focusing particularly on the critical testing and validation phase.

Understanding Permify

Permify provides a robust platform for defining, managing, and enforcing fine-grained access controls.

It allows you to specify detailed authorization rules that reflect real-world requirements, ensuring that users only access the resources they are allowed to, in accordance with their permissions to those resources.

Setting Up Permify

Installation: Begin by running Permify as a Docker container. This approach simplifies setup and ensures consistency across environments.
```
docker run -p 3476:3476 -p 3478:3478 ghcr.io/permify/permify serve
```
This command starts the Permify service, making it accessible via its REST and gRPC interfaces.
Verify Installation with Postman: Postman is an effective tool for testing API endpoints. After launching Permify:
Open Postman and create a new request.
Set the request type to GET.
Enter the URL http://localhost:3476/healthz.
Send the request. A successful setup is indicated by a 200 OK response, confirming that Permify is operational.

Modeling Authorization with Permify Schema

The schema is the heart of your authorization system, defining the entities involved and how they relate to each other.

The provided schema example demonstrates a system similar to Google Docs, showcasing entities like user, organization, group, and document, along with their relationships and permissions.

Entities represent the main components of your system.
Relations outline how entities interact, e.g., which user owns a document or is part of a group.
Permissions specify allowed actions based on roles within these relationships.

entity user {}

entity organization {
    relation group @group
    relation document @document
    relation administrator @user @group#direct_member @group#manager
    relation direct_member @user

    permission admin = administrator
    permission member = direct_member or administrator or group.member
}

entity group {
    relation manager @user @group#direct_member @group#manager
    relation direct_member @user @group#direct_member @group#manager

    permission member = direct_member or manager
}

entity document {
    relation org @organization

    relation viewer  @user  @group#direct_member @group#manager
    relation manager @user @group#direct_member @group#manager

    action edit = manager or org.admin
    action view = viewer or manager or org.admin
}

In the schema, the @ symbol denotes the target of a relation (indicating a connection to another entity or a specific relation within an entity), while the # symbol specifies a particular relation within a target entity.

Here's a breakdown of the schema components for clarity:

entity user {}
- Represents individual users in the system.
entity organization
- relation group @group: Links an organization to one or more groups.
- relation document @document: Connects an organization to documents.
- relation administrator @user @group#direct_member @group#manager: Defines administrators of the organization as users who are either direct members of a group or managers within a group.
- relation direct_member @user: Identifies users who are direct members of the organization.
- permission admin = administrator: Grants administrator permissions to users defined as administrators.
- permission member = direct_member or administrator or group.member: Assigns member permissions to users who are either direct members, administrators, or members of a group within the organization.
entity group
- relation manager @user @group#direct_member @group#manager: Specifies the managers of the group, including users who are direct members of the group or designated as group managers.
- relation direct_member @user @group#direct_member @group#manager: Denotes direct members of the group, who can also be group managers.
- permission member = direct_member or manager: Provides member permissions to users who are either direct members or managers of the group.
entity document
- relation org @organization: Associates documents with their respective organizations.
- relation viewer @user @group#direct_member @group#manager: Defines viewers of the document as users who are either direct members or managers of a group.
- relation manager @user @group#direct_member @group#manager: Identifies managers of the document, which includes users who are direct members or managers in a group.
- action edit = manager or org.admin: Allows document editing by either the document's manager or the organization's administrators.
- action view = viewer or manager or org.admin: Permits viewing of the document by viewers, managers, or organization administrators.

Implementing Permify with Go SDK

This section guides you through creating a simple Go application to implement Permify using its Go SDK. We assume that you already have your Permify environment set up and your schema ready.

The following implementation only covers the crucial steps. To access the complete project, including all code, HTML, and CSS files, you can use this GitHub Repo.

Step 1: Initialize the Permify Client

To use the Permify SDK in a Go application, the first step is to establish a connection with the Permify server by initializing a client that communicates with the Permify service.

This involves configuring the client with the endpoint of your Permify server and setting up the transport credentials.

permify_client.go

package main

import (
    "context"
    "log"
    "time"

    v1 "github.com/Permify/permify-go/generated/base/v1"
    permify "github.com/Permify/permify-go/v1"
    "google.golang.org/grpc"
    "google.golang.org/grpc/credentials/insecure"
)

var client *permify.Client

// setupPermifyClient initializes the Permify client and sets up the Permify schema.
func setupPermifyClient() {
    var err error
    // Initialize the Permify client
    client, err = permify.NewClient(
        permify.Config{
            Endpoint: "localhost:3478", // Replace with the actual address of your Permify deployment
        },
        grpc.WithTransportCredentials(insecure.NewCredentials()), // Use insecure credentials for development
    )
    if err != nil {
        log.Fatalf("Failed to create Permify client: %v", err)
    }

    // Setup Permify schema and other configurations
    initPermifySchema()
}

In this code snippet:

We import necessary packages such as context, log, and time for context management, logging, and time-related operations, respectively.
We import the Permify SDK packages v1 and permify.
We import the grpc package for setting up the gRPC connection with the Permify server.
We import credentials/insecure for setting up insecure transport credentials, suitable for development environments.
We define a setupPermifyClient() function that initializes the Permify client and sets up the Permify schema.

This function initializes the Permify client by specifying the endpoint of the Permify server and configuring transport credentials. It also handles any errors that occur during initialization.

Step 2: Define and Write the Schema

Once you've initialized the Permify client, the next step is to define the schema for your application. The schema defines the entities, relationships between them, and the permissions associated with those relationships. Once the schema is defined, it must be written to the Permify service to be enforced.

Schema Definition

The schema is defined using a domain-specific language (DSL) provided by Permify. This DSL allows you to specify entities, relationships, and permissions in a concise and human-readable format. Here's an example schema definition for a basic document management system:

entity user {}
entity organization {
    relation group @group
    relation document @document
    relation administrator @user @group#direct_member @group#manager
    relation direct_member @user
    permission admin = administrator
    permission member = direct_member or administrator or group.member
}
entity group {
    relation manager @user @group#direct_member @group#manager
    relation direct_member @user @group#direct_member @group#manager
    permission member = direct_member or manager
}
entity document {
    relation org @organization
    relation viewer @user @group#direct_member @group#manager
    relation manager @user @group#direct_member @group#manager
    action edit = manager or org.admin
    action view = viewer or manager or org.admin
}

In this schema:

We define four entities: user, organization, group, and document.
Each entity can have relationships with other entities, specified using the relation keyword.
We define permissions (admin and member) for the organization entity based on its relationships with other entities.
The document entity has actions (edit and view) associated with it, with permissions based on the relationships defined in the schema.

Writing the Schema

Once the schema is defined, it must be written to the Permify service using the Permify client. This ensures that the access control rules defined in the schema are enforced by the Permify system. Here's how you can write the schema using the Permify client:

func initPermifySchema() {
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    // Define the schema
    schema := `/* Schema definition goes here */`

    // Write the schema to the Permify service
    sr, err := client.Schema.Write(ctx, &v1.SchemaWriteRequest{
        TenantId: "t1",
        Schema:   schema,
    })
    if err != nil {
        log.Fatalf("Failed to write schema: %v", err)
    }
    schemaVersion = sr.SchemaVersion
    log.Printf("Schema version %s written successfully", schemaVersion)
}

In this code snippet:

We initialize a context with a timeout to ensure that the schema write operation doesn't hang indefinitely.
We define the schema as a string using the DSL provided by Permify.
We use the Permify client to write the schema to the Permify service, specifying the tenant ID and the schema itself.
If the schema write operation is successful, we store the schema version for future reference.

Step 3: Store Relationships and Permissions

Once the schema has been defined and written, the next crucial step is populating the Permify system with specific instances of relationships and permissions according to your schema definitions.

This involves creating data tuples that represent real-world relationships between the entities defined in your schema.

Understanding Relationships and Permissions

In the context of Permify, relationships and permissions are represented as tuples. These tuples articulate the connections between entities (such as a user and a document) and specify the kind of access allowed (e.g., viewing or editing).

This structured format enables Permify to quickly evaluate access requests based on the predefined rules in your schema.

Writing Data Tuples Using the Permify Client

To enforce the access control rules defined in your schema, you need to populate the Permify system with actual data that reflects the relationships in your application.

This is typically done by writing data tuples to Permify after defining your schema. Each tuple represents a specific permission or relationship instance between entities.

Here's how you can write data tuples using the Permify client in Go:

func storeRelationships() {
    ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
    defer cancel()

    // Write relationships between entities
    rr, err := client.Data.Write(ctx, &v1.DataWriteRequest{
        TenantId: "t1",
        Metadata: &v1.DataWriteRequestMetadata{
            SchemaVersion: schemaVersion,
        },
        Tuples: []*v1.Tuple{
            {
                Entity:   &v1.Entity{Type: "document", Id: "1"},
                Relation: "viewer",
                Subject:  &v1.Subject{Type: "user", Id: "user1"},
            },
            {
                Entity:   &v1.Entity{Type: "document", Id: "1"},
                Relation: "manager",
                Subject:  &v1.Subject{Type: "user", Id: "user3"},
            },
            // Add more tuples as needed
        },
    })
    if err != nil {
        log.Fatalf("Failed to write data tuples: %v", err)
    }
    snapToken = rr.SnapToken
    log.Printf("Data tuples written successfully, snapshot token: %s", snapToken)
}

In this code snippet:

We initialize a context with a timeout to ensure that the data write operation doesn't hang indefinitely.
We use the Permify client to write data tuples to the Permify service, specifying the tenant ID, schema version, and the tuples themselves.
Each tuple defines a relationship between entities, such as a user being a viewer or manager of a document.
If the data write operation is successful, we store the snapshot token for future reference.

By storing relationships and permissions in the Permify system, you enable it to enforce the access control rules defined in your schema effectively.

Step 4: Perform Access Checks

After setting up the schema and storing relationships, the next critical step involves performing access checks to determine if a particular user has the necessary permissions to access a specific resource.

This step is pivotal for enforcing the access control rules defined and stored in the Permify system.

Understanding Access Checks

Access checks involve querying the Permify system to evaluate whether a specified subject (e.g., a user) is allowed to perform a certain action (e.g., view or edit) on a resource (e.g., a document) based on the existing relationships and permissions.

These checks enforce your application's security policies in real-time, ensuring that only authorized users can access specific resources.

Implementing Access Checks in the Application

Access checks are typically triggered by user actions that require validation of permissions. For example, when a user attempts to access a protected page or resource, the application queries Permify to confirm whether the access should be allowed.

Below is an example of how to implement an access check using the Permify client in a Go web application:

func checkPermission(username, permission string) bool {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()

    checkResult, err := client.Permission.Check(ctx, &v1.PermissionCheckRequest{
        TenantId: "t1",
        Entity: &v1.Entity{
            Type: "document",
            Id:   "1",
        },
        Permission: permission,
        Subject: &v1.Subject{
            Type: "user",
            Id:   username,
        },
        Metadata: &v1.PermissionCheckRequestMetadata{
            SnapToken:     snapToken,
            SchemaVersion: schemaVersion,
            Depth:         50,
        },
    })
    if err != nil {
        log.Printf("Failed to check permission '%s' for user '%s': %v", permission, username, err)
        return false
    }
    return checkResult.Can == v1.CheckResult_CHECK_RESULT_ALLOWED
}

In this code snippet:

We use the Permify client to perform a permission check, specifying the tenant ID, entity (document), permission, subject (user), and metadata.
The access check result indicates whether the action is allowed (CHECK_RESULT_ALLOWED) or denied.
Proper error handling ensures that any errors encountered during the access check process are appropriately logged.

By implementing access checks in your application using Permify, you can enforce fine-grained access control policies, ensuring that only authorized users can perform specific actions on protected resources.

Step 5: Run the Server and Handle HTTP Requests

Once the Permify client is initialized, and the schema is defined and written to the Permify service, the next step is to run the web server and handle HTTP requests. This involves setting up HTTP routes, handling user authentication, and performing authorization based on the permissions defined in Permify.

Initializing Routes and HTTP Server

In main.go, we initialize the HTTP routes and start the HTTP server:

func main() {
    setupPermifyClient() // Initialize Permify client and setup schema
    setupRoutes()       // Initialize HTTP routes
    log.Println("Server started on :8080")
    log.Fatal(http.ListenAndServe(":8080", nil))
}

The setupPermifyClient() function initializes the Permify client and sets up the schema. The setupRoutes() function initializes all the route handlers defined in handlers.go.

Handling HTTP Requests

In handlers.go, we define HTTP request handlers for different routes:

// setupRoutes initializes all the route handlers
func setupRoutes() {
    http.HandleFunc("/", serveHome)      // Handle requests to the home page
    http.HandleFunc("/login", handleLogin) // Handle user login requests
    http.HandleFunc("/protected", serveProtected) // Handle requests to protected content
}

serveHome: Handles requests to the home page (/). It serves the login page HTML template.
handleLogin: Handles user login requests (/login). It verifies user credentials and sets a session token cookie upon successful login.
serveProtected: Handles requests to protected content (/protected). It checks if the user is authenticated and authorized to access the protected content.

Step 6: Running the Application

To run the application:

Ensure your Permify server is running and accessible at the specified endpoint.
Execute the Go application using:

   go run main.go handlers.go permify_client.go

Navigate to http://localhost:8080 in your web browser to interact with the application.

Using Other SDKs in Production

While this example uses the Go SDK, Permify supports various SDKs suitable for different programming environments. Select the SDK that best fits your production needs to implement these functionalities seamlessly.

How Can You Save Time and Money with Fine-Grained Access Control?

Fine-Grained Access Control offers a powerful way to secure your enterprise while remaining agile. Here’s how it saves time and money:

Reduced Administrative Overhead: Automating access control reduces the need for manual intervention, freeing up your team to focus on other tasks.
Lower Risk of Data Breaches: By ensuring only the right people have access, you reduce the potential costs associated with data breaches.
Increased Productivity: Employees have the access they need when they need it, without unnecessary barriers.

In conclusion, fine-grained access control is not just about securing your enterprise; it’s about enabling it to move faster, more securely, and more efficiently.

By choosing the right authorization model, leveraging tools like Permify, and understanding the balance between granularity and manageability, you can build a robust access control system that scales with your needs.

Implementing Role Based Access Control (RBAC) in Node.js and Express App

Ege Aytin — Wed, 05 Jun 2024 15:54:26 +0000

To ensure that only authorized users can access specific features and data within an application, implementing Role-Based Access Control (RBAC) is essential.

In this article, I will show you how to implement RBAC into a Node.js and Express application using Permify.

Setting Up Node.js Express Project
Implementing RBAC in Node.js and Express App
- Step 1: Designing the RBAC Model With Permify
- Step 2: Setting Up a Permify Local Server with Docker
- Step 3: Initialize Permify Node.js Client
- Step 4: Configure Authorization Model
- Step 5: Creating Access Control Middleware
- Step 6: Securing Routes with RBAC
Testing RBAC Implementation
Conclusion

Setting Up Node.js Express Project

To quickly create an application skeleton for your Express.js project, you can use the express-generator tool.

Follow these steps to get started:

Step 1. Install express-generator:

If you're using Node.js version 8.2.0 or later, you can run the application generator using the npx command:



npx express-generator

For earlier Node versions, you can install the application generator as a global npm package:



npm install -g express-generator

Step 2. Generate Your Express Application:

Once you have express-generator installed, you can create your Express application. Display the command options with the -h option:



express -h

This will show you the available options for generating your Express application.

For example, to create an Express app named permify-rbac-app with the Pug view engine, you can run:



express --view=pug permify-rbac-app

This command will create a folder named permify-rbac-app in the current working directory, along with the necessary files and folders for your Express application.

Step 3. Install Dependencies:

Navigate into your newly created Express application directory:



cd permify-rbac-app

Then, install the project dependencies using npm:



npm install express && npm install @permify-node

Step 4. Start Your Express Application:

On MacOS or Linux, you can start the app with the following command:



DEBUG=permify-rbac-app:* npm start

Step 5. Access Your Application:

Once your Express application is running, you can access it in your browser at http://localhost:3000/.

Directory Structure:

The generated Express application will have the following directory structure:



permify-rbac-app/
├── app.js
├── bin/
│   └── www
├── package.json
├── public/
│   ├── images/
│   ├── javascripts/
│   └── stylesheets/
│       └── style.css
├── routes/
│   ├── index.js
│   └── users.js
└── views/
    ├── error.pug
    ├── index.pug
    └── layout.pug

This structure includes the main application file (app.js), the server configuration (bin/www), routes, views, public assets, and the package.json file with project dependencies.

Now that you have set up our Express.js project, we'll proceed to implement RBAC to our Express application.

Implementing RBAC in Node.js and Express

Implementing Role-Based Access Control (RBAC) in a Node.js and Express application involves several steps. Here's a basic implementation:

Step 1: Designing the RBAC Model with Permify

Permify is an open source authorization service that allows developers to create authorization systems. With Permify you can model your authorization, create central authorization service in your environment and perform access checks from your applications and services.

It does this by providing client SDKs, which you can add into your middleware to send authorization requests, such as access check.

Permify offers a powerful domain-specific language (DSL) to define roles, permissions, and relationships. You can utilize the Permify Playground to experiment and visualize your RBAC model.

For this post, we will develop a simple file-based authorization system where users within your organization can access documents based on their roles.

Different roles such as Admin, Manager, and Employee may have different levels of access to view, edit, or delete files.

Defining Roles and Permissions with Permify DSL

Below is an example Permify DSL schema for our RBAC model:



entity user {} 

entity organization {

    // roles 
    relation admin @user    
    relation member @user    
    relation manager @user    
    relation agent @user  

    // organization files access permissions
    permission view_files = admin or manager or (member not agent)
    permission delete_file = admin 

    // vendor files access permissions
    permission view_vendor_files = admin or manager or agent
    permission delete_vendor_file = agent

}

Roles and Permissions:

Roles: The schema defines roles for the organization entity, including admin, member, manager, and agent. These roles determine the level of access and permissions users have within the organization.
Permissions: Actions such as view_files, edit_files, delete_file, view_vendor_files, edit_vendor_files, and delete_vendor_file define the specific permissions associated with each role. For example, only admins can delete organization files, while managers and members have different levels of access.

Resource Types:

The schema distinguishes between organization files and vendor files, each with its own set of permissions. This allows for granular control over access to different types of resources within the application.

Now that we have our RBAC schema defined, we'll proceed to setting up an Permify Local Server.

Step 2: Setting Up a Permify Local Server with Docker

Docker plays a crucial role in our setup by providing a containerized environment.

This environment is essential for the efficient operation of Permify, which functions as a microservice responsible for all authorization queries.

Now we will cover the steps needed to set up the Permify Server with using Docker Container below:

Run Permify Server with Docker Container

Open a terminal window and run the following command to pull the Permify Server Docker image and start the container: ```sh

sudo docker run -p 3476:3476 -p 3478:3478 ghcr.io/permify/permify serve


This command will download the Permify Server image from the GitHub Container Registry and sets up Permify, our authorization service, with the following default settings:

- The REST API running on port 3476.
- The gRPC Service running on port 3478.
- Authorization data is stored in the computer's memory.

You should see a message similar to this:
```bash


┌────────────────────────────────────────────────────────┐
│                    Permify v0.8.5                      │
│          Fine-grained Authorization Service            │
│                                                        │
│    docs: ............... https://docs.permify.co       │
│    github: .. https://github.com/Permify/permify       │
│    blog: ............... https://permify.co/blog       │
│                                                        │
└────────────────────────────────────────────────────────┘
time=2024-03-22T14:59:09.851Z level=INFO msg="🚀 starting permify service..."
time=2024-03-22T14:59:09.851Z level=ERROR msg="Account ID is not set. Please fill in the Account ID for better support. Get your Account ID from https://permify.co/account"
time=2024-03-22T14:59:09.859Z level=INFO msg="🚀 grpc server successfully started: 3478"
time=2024-03-22T14:59:09.859Z level=INFO msg="🚀 invoker grpc server successfully started: 5000"
time=2024-03-22T14:59:09.867Z level=INFO msg="🚀 http server successfully started: 3476"

Verify Permify Server

Once the container is running, you can verify that Permify Server is running correctly by accessing the health check endpoint. Open Postman and send a GET request to http://localhost:3476/healthz. If Permify Server is running correctly, you should see a response indicating that the service is healthy.

The above image shows that Permify Server is up and running, you can now proceed with integrating it into your Node.js and Express application.

Step 3: Initialize Permify Node.js Client

In this tutorial, we'll use Permify Node Client to control authorization in our application. You can find the list of available endpoints in our Permify Swagger Docs. We'll be using Permify's access control checks to safeguard our endpoints.

Let's initialize our our client,



// create-tenant.js
const permify = require("@permify/permify-node");

const client = new permify.grpc.newClient({
    endpoint: "localhost:3478",
})

Step 4: Configure Authorization Model

Now as our Permify Server running, we need to configure our authorization model to Permify service and then we can ready to perform test access checks.

To configure the authorization model, we'll send the schema we created to Permify using the Permify schema.write method.



//create-schema.js

const permify = require("@permify/permify-node");

const client = new permify.grpc.newClient({
    endpoint: "localhost:3478",
})

client.schema.write({
    tenantId: "t1",
    schema: "entity user {} \n\nentity organization {\n\n    relation admin @user    \n    relation member @user    \n    relation manager @user    \n    relation agent @user  \n\n    action view_files = admin or manager or (member not agent)\n    action edit_files = admin or manager\n    action delete_file = admin\n    action view_vendor_files = admin or manager or agent\n    action edit_vendor_files = admin or agent\n    action delete_vendor_file = agent\n\n} "
}).then((response) => {
    // handle response
    console.log(response)
})

This code above creates a new schema using the Permify library.

It is built to connect to the Permify server running on localhost port 3478 and then calls the write method to define a schema for the specified tenant t1.

The schema defines entities such as user and organization along with their relationships and actions.

Now, let's run this script



node create-schema.js

From the output in screenshot above, you can see that the new schema was successfully configured using Permify Node Js Client.

Hooray! 🥳 We've successfully finished setting up the Permify authorization service. Our API is now up and running with the authorization model configured and ready for use!

In the next step, we will be creating the middleware for access control.

Step 5: Creating Access Control Middleware

Here I will show an example of how we'll develop Express middleware to enforce role-based access control on routes.

You will also learn how to implement Permify access check endpoint in the middleware to verify a user's role and permissions before allowing access to protected resources.



// auth.js

// Import Permify client
const permify = require('@permify/permify-node');

const client = new permify.grpc.newClient({
  endpoint: "localhost:3478",
});

// Middleware function to check user's permissions
const checkPermissions = (permissionType) => {
  return async (req, res, next) => {
    try {
      // Ensure req.params.id exists
      if (!req.params.id) {
        throw new Error('User ID is missing in the request parameters');
      }

      // Convert permissionType to string if necessary
      const permTypeString = String(permissionType);

      // Prepare data for Permify check request
      const checkRes = await client.permission.check({
        tenantId: 't1',
        metadata: {
          schemaVersion: '',
          snapToken: '',
          depth: 20,
        },
        entity: {
          type: 'organization',
          id: "1",
        },
        permission: permTypeString, // Use the converted permissionType
        subject: {
          type: 'user',
          id: req.params.id,
        },
      });

      if (checkRes.can === 1) {
        // If user is authorized
        req.authorized = 'authorized';
        next();
      } else {
        // If user is not authorized
        req.authorized = 'not authorized';
        next();
      }
    } catch (err) {
      console.error('Error checking permissions:', err.message); // Log the actual error message
      res.status(500).send(err.message); // Send the actual error message to the client for debugging purposes
    }
  };
};

module.exports = checkPermissions;

The code above is built with the aim to implement a middleware function, checkPermission by utilizing the Permify library to verify user permissions based on the provided permission type.

When executed it extracts the user ID from the request parameters, converts the permission type to a string if needed, then sends a permission check request using Permify's "permission.check" method to the Permify server. If authorized, it adds "authorized" to the request object; otherwise, it adds "not authorized".

Errors are further logged and returned to the client for debugging purposes.

Next, we'll integrate the middleware that was created above into our Node.js and Express application to enforce Role-Based Access Control (RBAC) and ensure that only authorized users with the appropriate roles and permissions can access specific routes.

Step 6: Securing Routes with RBAC

Now, let's secure our routes using the middleware we've created. We'll apply the checkPermissions middleware to protect various routes in our application.



// app.js

// Import required modules
const express = require('express');
const permify = require("@permify/permify-node");
const authMiddleware = require('./auth'); // Import the auth middleware

// Create Express app
const app = express();

// Define custom middleware to populate userInfo
app.use((req, res, next) => {
  // Simulate user authentication and populate userInfo
  req.userInfo = {
    id: req.params.id // Extract the id from request params
    // Add other user information if required
  };
  next();
});

// Define routes

// Route for '/users/:id' where you want to enforce permission check
app.get('/users/viewFiles/:id', authMiddleware('view_files'), (req, res) => {
  // If middleware allows the request to pass through, handle the route logic here
  if (req.authorized === 'authorized') {
    res.send('You have access to this user route');
  } else {
    res.status(403).send('You are not authorized to access this user resource');
  }
});

// Route for '/admin/deleteVendorFiles/:id' where you want to enforce permission check
app.get('/admin/deleteVendorFiles/:id', authMiddleware('delete_vendor_file'), (req, res) => {
  // If middleware allows the request to pass through, handle the route logic here
  if (req.authorized === 'authorized') {
    res.send('You have access to this admin route');
  } else {
    res.status(403).send('You are not authorized to access this admin resource');
  }
});

// Start the server
const PORT = process.env.PORT || 3000;
app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

This code sets up your Express application on port 3000 where specific routes are protected using a custom middleware called authMiddleware.

This middleware, imported from the auth.js file, integrates with Permify for permission checks. Below are routes being protected by the Middleware;

Routes protected by the authMiddleware:

Route for /users/viewFiles/:id: This route ensures that only users have permission to view files can access this route.
Route for /admin/viewFiles/:id: This route ensures that only admins who have permission to delete vendor files can access this route.

By applying the authMiddleware to these routes, access is restricted based on the permissions granted by Permify.

Let's test our implementation!

Testing RBAC Implementation

Let's say we have a user with userID alice, Let's test to see if alice can access the /users/viewFiles/ API endpoint which is only accessible by admins, managers or members that are not agents as we defined in our schema earlier in this article.

As expected, the UserID alice doesn't have access to this API endpoint, Let's give alice the member role using Permify Nodejs client's data.write method:



// write-relationship.js
const permify = require("@permify/permify-node");

const client = new permify.grpc.newClient({
    endpoint: "localhost:3478",
})

client.data.write({
    tenantId: "t1",
    metadata: {
        schemaVersion: ""
    },
    tuples: [{
        entity: {
            type: "organization",
            id: "1"
        },
        relation: "member",
        subject: {
            type: "user",
            id: "alice"
        }
    }]
}).then((response) => {
    // handle response
    console.log(response)
})

Let's run this code and try visiting the /users/viewFiles/ API endpoint using Postman.

Now, after running the code, Alice can now successfully access the /users/viewFiles/ API endpoint.

Source Code: All the code snippets featured in this article can be found in the corresponding GitHub Repository.

Conclusion

It's important to recognize that authorization isn't a one-time setup; it's an ongoing process.

Therefore, it's imperative to regularly review your model, conduct thorough testing, and adapt it as your application evolves.

This guide serves as a solid foundation for implementing RBAC in your Node.js application.

However, don't hesitate to delve deeper and tailor the RBAC model to precisely fit your unique requirements.

By harnessing the capabilities of Permify, you can streamline permission management and cultivate a resilient and secure application environment.

Implementing Role Based Access Control in SvelteKit

Ege Aytin — Thu, 30 May 2024 11:43:46 +0000

Understanding Role-Based Access Control (RBAC)
Setting Up the SvelteKit Project
Integrating RBAC Configurations and Utilities
- Defining Roles and Permissions
- Implementing RBAC Utility Functions
Dynamic Navigation Based on User Roles
Securing Routes Based on User Roles
Managing Permissions Within Components
Conclusion

Prerequisites

Before you begin, you'll need to have the following prerequisites:

Basic knowledge of SvelteKit: Familiarity with SvelteKit's core concepts, like routing, components, and stores, will be helpful.
Node.js and npm: You'll need to have Node.js and npm (Node Package Manager) installed on your system. If you haven't already, you can download and install them from the official Node.js website.
Git: Ensure you have Git installed on your machine. If not, you can download it from the Git website.

Understanding Role-Based Access Control (RBAC)

RBAC is a security model that organizes user permissions based on their roles within an application.

Each role is associated with a set of permissions, and users are assigned specific roles to determine what they can access.

Roles and Permissions

Roles represent a collection of related permissions that define what a user can do within an application.

For instance, an application might have roles such as Admin, Editor, and Viewer each with different sets of permissions.

Permissions, on the other hand, are specific actions or operations that a user with a particular role can perform.

These can range from viewing and editing data to managing user accounts or system configurations.

Setting Up the SvelteKit Project

Before we start implementing RBAC, we need a SvelteKit project ready to work with.

To keep things simple, we'll use a demo e-commerce project as our starting template. The complete code for this project can be found in this GitHub repository.

To get the starter template, run the following commands:

git clone https://github.com/TropicolX/svelte-rbac-demo.git
cd svelte-rbac-demo
git checkout starter
npm install

The project structure should look like the one below:

Next, let's go over the essential files and directories we'll be working with for the project:

/lib: This directory will contain all our utilities and components.
/routes: Contains all the routes in our application.
- /(protected): This folder contains all our protected routes. Only signed-in users may be able to navigate these routes.
- /login: This is the route to the login page.
- /unauthorized: This is the route we redirect users to when they are unauthorized in accessing a page.
- +layout.svelte: This contains the UI layout and logic that applies to every page.
- +page.svelte: This is our home page route.
hooks.server.js: This file contains all the server-side logic we need to authenticate users when they navigate to a protected route and to redirect them when necessary. It also fetches the user data on the server and stores it in the event.locals object.

Project Overview

To start the project, run the following command in the root directory:

npm run dev

You should see a page like the one below:

Next, let's sign in to the app. Click the "Sign in" button at the top right corner of the page.

You can sign in as either an admin or a customer using the following credentials:

Admin:
- Email: admin@gmail.com
- Password: admin123
Customer:
- Email: john@mail.com
- Password: changeme

After signing in, you will be redirected to the home page and should able to see two new links on the navbar:

Admin link
Profile link

This brings us to the current problem with our e-commerce app: We need to ensure that only admins can access the admin page, and similarly, only customers can access the profile page.

Additionally, we need to ensure that only admins and customers with the required permissions can perform specific actions within their respective pages.

For instance, only an admin with permission to create products should be able to do so on the admin page.

Integrating RBAC Configurations and Utilities

Now that we've set up and familiarized ourselves with the Svelekit project let's begin implementing RBAC in our app. We'll start by defining the roles and permissions within the app.

Defining Roles and Permissions

In the SvelteKit project, create a new file called constants.js in the src directory and add the following code:

// src/constants.js
export const ROLES = {
    ADMIN: "admin",
    CUSTOMER: "customer",
};

export const PERMISSIONS = {
    CREATE_PRODUCTS: "create:products",
    UPDATE_PRODUCTS: "update:products",
    DELETE_PRODUCTS: "delete:products",
    READ_PROFILE: "read:profile",
    UPDATE_PROFILE: "update:profile",
};

In the code above, we defined our app's roles and permission constants.

Next, we need to define the permissions each role has. Navigate to the lib directory and create a rolePermissions.js file with the following code:

// src/lib/rolePermissions.js
import { PERMISSIONS, ROLES } from "../constants";

export const rolePermissions = {
    [ROLES.ADMIN]: [
        PERMISSIONS.CREATE_PRODUCTS,
        PERMISSIONS.UPDATE_PRODUCTS,
        PERMISSIONS.DELETE_PRODUCTS,
    ],
    [ROLES.CUSTOMER]: [PERMISSIONS.READ_PROFILE, PERMISSIONS.UPDATE_PROFILE],
};

The code above sets up each of the roles with specific permissions. We want admin users to be able to create, update, and delete products.

On the other hand, we want customers to be able to read and update their profile details.

Implementing RBAC Utility Functions

Next, let's create some utility functions to check if a user has a certain role or permission. These functions will enforce access control throughout the app.

In the lib directory, create a rbacUtils.js file and add the following code:

// src/lib/rbacUtils.js
import { rolePermissions } from "./rolePermissions";

// Function to check if a user has a specific role
export function checkRole(user, requiredRole) {
    if (!user) {
        return false;
    }

    return user.role === requiredRole;
}

// Function to check if a user has specific permissions
export function checkPermissions(user, requiredPermissions) {
    if (!user) {
        return false;
    }

    const userPermissions = rolePermissions[user.role];
    return userPermissions?.includes(requiredPermissions);
}

// Function to check if a user has both a specific role and permissions
export function checkRoleAndPermissions(
    user,
    requiredRole,
    requiredPermissions
) {
    return (
        checkRole(user, requiredRole) &&
        checkPermissions(user, requiredPermissions)
    );
}

With these configurations in place, we can start integrating RBAC within our app.

The navigation UI is the first area in our app where we'll implement RBAC. We need to ensure that users see only the navigation links relevant to their roles.

Firstly, head over to the +layout.svelte file in the routes folder and add the following code:

<!-- src/routes/+layout.svelte -->
<script>
    ...
    import Loading from "$lib/components/Loading.svelte";
    import { checkRole } from "$lib/rbacUtils";
    import { ROLES } from "../constants";
    import { user, cart, products } from "../stores";
    import "../app.css";

    ...
    $: isAdmin = checkRole($user, ROLES.ADMIN);
    $: isCustomer = checkRole($user, ROLES.CUSTOMER);
</script>

...

Here, we defined two variables, isAdmin and isCustomer, which check if the user is an admin or a customer, respectively. We also used reactive declarations to define the variables so that any changes to the user data, e.g., if the user logs out, will update their values.

Next, let's update our navigation links:

<!-- src/routes/+layout.svelte -->
...

<header
    class="bg-gray-900 text-white py-4 px-6 md:px-12 flex items-center justify-between"
>
    ...
    <nav class="hidden md:flex items-center space-x-6">
        {#if isAdmin}
            <a class="hover:text-gray-300" href="/admin">Admin</a>
        {/if}
        {#if isCustomer}
            <a class="hover:text-gray-300" href="/user">Profile</a>
        {/if}
    </nav>
    ...
</header>

...

Now, the navigation links for the admin and profile pages will be displayed conditionally based on the user's role.

Securing Routes Based on User Roles

In the previous section, we added dynamic client-side navigation based on user roles. However, users may still be able to navigate to unauthorized routes by using the browser navigation. To prevent this, we need to secure the routes directly by adding role-based protection.

We can do this in Svelte by adding a +layout.server.js file in each route to run a server-side load function. The load function will run whenever the user loads the page and will check whether the user has access to the route based on their role. If they are not authorized, they will be redirected to the /unauthorized page.

Let's start by implementing this on the admin page. Head over to the admin directory in the (protected) folder, create a +layout.server.js file with the following code:

// src/routes/(protected)/admin/+layout.server.js
import { redirect } from "@sveltejs/kit";

import { checkRole } from "$lib/rbacUtils";
import { ROLES } from "../../../constants";

/** @type {import('./$types').LayoutServerLoad} */
export function load({ locals }) {
    const user = locals.user;
    const isAdmin = checkRole(user, ROLES.ADMIN);

    if (!isAdmin) {
        redirect(307, "/unauthorized");
    }
}

Now, if a non-admin user attempts to access the admin route, they will be redirected appropriately.

Next, let's secure our user route. Within the (protected) folder, navigate to the user directory and create a +layout.server.js file with the following code:

// src/routes/(protected)/user/+layout.server.js
import { redirect } from "@sveltejs/kit";

import { checkRoleAndPermissions } from "$lib/rbacUtils";
import { PERMISSIONS, ROLES } from "../../../constants";

/** @type {import('./$types').LayoutServerLoad} */
export function load({ locals }) {
    const user = locals.user;
    const isCustomerAndCanViewProfile = checkRoleAndPermissions(
        user,
        ROLES.CUSTOMER,
        PERMISSIONS.READ_PROFILE
    );

    if (!isCustomerAndCanViewProfile) {
        redirect(307, "/unauthorized");
    }
}

Here, we're doing things a bit differently by using the checkRoleAndPermissions function to ensure the user is both a customer and has permission to read a profile before being able to access the profile page.

This function can be helpful in more complex scenarios where a role might have additional or custom permissions different from the default permissions.

Next let's look at how to manage role permissions within components.

Managing Permissions Within Components

Now that we've secured our routes, the next step is to safeguard actions and features within those pages to ensure only users with the necessary permissions can access them.

For instance, you can take three main actions on the admin page:

Create a product
Edit a product
Delete a product

Currently, an admin has the permission to perform all these actions by default. But suppose later in development, a change was made to revoke the create:products permission from the default admin role and to only be given to a select few admins.

In that case, ensuring only those specific admins can create a product becomes crucial.

We can check permissions in our project using the checkPermissions utility function.

For example, in the +page.svelte file in the admin directory, we can add the following code to ensure only admins with create:product permission can access the "Add new product" button:

<!-- src/routes/(protected)/admin/+page.svelte -->
<script>
    import { checkPermissions } from "$lib/rbacUtils";
    import { PERMISSIONS } from "../../../constants";
    import { user, products } from "../../../stores";

    $: canCreateProducts = checkPermissions($user, PERMISSIONS.CREATE_PRODUCTS);
</script>

<div class="container mx-auto px-4 md:px-8 py-12">
    <div class="flex flex-wrap items-center justify-between mb-8">
        <h2 class="text-3xl md:text-4xl font-bold">Admin Dashboard</h2>
        {#if canCreateProducts}
            <button
                class="mt-4 min-[457px]:mt-0 inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50 h-10 px-4 py-2 bg-gray-900 text-white hover:bg-gray-800"
            >
                Add new product
            </button>
        {/if}
    </div>
    ...
</div>

If we remove PERMISSIONS.CREATE_PRODUCTS from the admin permissions in the rolePermissions.js file, we can see the change taking effect:

// src/lib/rolePermissions.js
...

export const rolePermissions = {
    [ROLES.ADMIN]: [
        PERMISSIONS.UPDATE_PRODUCTS,
        PERMISSIONS.DELETE_PRODUCTS,
    ],
    ...
};

Let's take things a step further by securing the edit and delete feature as well:

<!-- src/routes/(protected)/admin/+page.svelte -->
<script>
    ...
    $: canDeleteProducts = checkPermissions($user, PERMISSIONS.DELETE_PRODUCTS);
    $: canUpdateProducts = checkPermissions($user, PERMISSIONS.UPDATE_PRODUCTS);
</script>

...
<tbody class="[&amp;_tr:last-child]:border-0">
    {#each $products as product (product.id)}
        <tr
            class="border-b transition-colors hover:bg-muted/50 data-[state=selected]:bg-muted"
        >
            ...
            <td class="p-4 align-middle [&amp;:has([role=checkbox])]:pr-0">
                <div class="flex items-center space-x-2">
                    {#if canUpdateProducts}
                        <!-- Update button -->
                        <button
                            class="inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50 border border-input bg-background hover:bg-accent hover:text-accent-foreground h-10 w-10"
                        >
                            <svg
                                xmlns="http://www.w3.org/2000/svg"
                                width="24"
                                height="24"
                                viewBox="0 0 24 24"
                                fill="none"
                                stroke="currentColor"
                                stroke-width="2"
                                stroke-linecap="round"
                                stroke-linejoin="round"
                                class="h-4 w-4"
                            >
                                <path
                                    d="M17 3a2.85 2.83 0 1 1 4 4L7.5 20.5 2 22l1.5-5.5Z"
                                ></path>
                            </svg>
                        </button>
                    {/if}

                    {#if canDeleteProducts}
                        <!-- Delete button -->
                        <button
                            class="inline-flex items-center justify-center whitespace-nowrap rounded-md text-sm font-medium ring-offset-background transition-colors focus-visible:outline-none focus-visible:ring-2 focus-visible:ring-ring focus-visible:ring-offset-2 disabled:pointer-events-none disabled:opacity-50 border border-input bg-background hover:bg-accent hover:text-accent-foreground h-10 w-10"
                        >
                            <svg
                                xmlns="http://www.w3.org/2000/svg"
                                width="24"
                                height="24"
                                viewBox="0 0 24 24"
                                fill="none"
                                stroke="currentColor"
                                stroke-width="2"
                                stroke-linecap="round"
                                stroke-linejoin="round"
                                class="h-4 w-4"
                            >
                                <path d="M3 6h18"></path>
                                <path d="M19 6v14c0 1-1 2-2 2H7c-1 0-2-1-2-2V6"
                                ></path>
                                <path d="M8 6V4c0-1 1-2 2-2h4c1 0 2 1 2 2v2"
                                ></path>
                            </svg>
                        </button>
                    {/if}
                </div>
            </td>
        </tr>
    {/each}
</tbody>
...

Next, let's implement the same policy on our profile page. Navigate to the +page.svelte file in the user directory and add the following code:

<!-- src/routes/(protected)/user/+page.svelte -->
<script>
    import { checkPermissions } from "$lib/rbacUtils";
    import { PERMISSIONS } from "../../../constants";
    import { user } from "../../../stores";

    $: canEditProfile = checkPermissions($user, PERMISSIONS.UPDATE_PROFILE);

    let name = $user.name;
    let email = $user.email;
</script>

<div class="h-[calc(100svh-64px)] w-full flex items-center justify-center">
    <div
        class="rounded-lg border bg-card text-card-foreground shadow-sm w-[28rem] max-w-md"
    >
        ...
        <div class="p-6 space-y-4">
            <div class="space-y-2">
                ...
                <input
                    ...
                    disabled={!canEditProfile}
                />
            </div>
            <div class="space-y-2">
                ...
                <input
                    ...
                    disabled={!canEditProfile}
                />
            </div>
            <div class="space-y-2">
                ...
                <input
                    ...
                    disabled={!canEditProfile}
                />
            </div>
            <div class="space-y-2">
                ...
                <input
                    ...
                    disabled={!canEditProfile}
                />
            </div>
        </div>
        <div class="flex items-center p-6">
            <button
                ...
                disabled={!canEditProfile}
            >
                Save
            </button>
        </div>
    </div>
</div>

Here, we use the canEditProfile variable to determine whether the input fields and save button will be disabled. If the value is false, the input fields and submit button will be disabled and vice versa.

And with that, we should have a fully secured e-commerce web app using RBAC!

Conclusion

In this tutorial, we looked at how to implement Role-Based Access Control (RBAC) in Sveltekit applications.

We began by learning about the fundamentals of RBAC, such as roles and permissions and their importance in web development.

We then examined its implementation, which included configuring custom roles and permissions, integrating RBAC utilities, securing routes, and managing permissions within components.

As you continue developing your SvelteKit apps, remember to regularly review and update your RBAC configuration to adapt to changing requirements and mitigate potential security risks.

Additionally, prioritize continual monitoring, logging, and testing to maintain the integrity and effectiveness of your RBAC implementation.

You can find the complete project code in this GitHub Repo.

JWT vs PASETO: New Era of Token-Based Authentication

Ege Aytin — Wed, 22 May 2024 15:33:51 +0000

How Does Token-Based Authentication Work?
What is JWT?
How JWT Works?
Pitfalls Of JWT
What is PASETO (Platform Agnostic Security Token)?
How PASETO Works?
How to Implement JWT or Paseto in Your Project?
Key Differences Between Paseto vs JWT
Choosing Between Paseto and JWT
The Future of Web Tokens
Summing Up

APIs and modern web applications have brought token-based authentication to the forefront of secure authorization methods.

Offering advantages like scalability, statelessness, and enhanced security compared to traditional session-based authentication, tokens have become the preferred choice for developers worldwide.

Among various token-based approaches, JSON Web Token (JWT) has gained widespread popularity because of its simplicity and ease of implementation.

However, concerns surrounding potential vulnerabilities and the need for meticulous implementation have led to the exploration of more robust alternatives.

Paseto (Platform-Agnostic Security Tokens) has emerged as a better solution, directly addressing the shortcomings of JWT.

Designed with a focus on security, Paseto provides a more secure foundation for token-based authentication by mitigating vulnerabilities and enforcing secure defaults.

This article delves into a comprehensive comparison of Paseto and JWT, dissecting their core functionalities, security features, and potential drawbacks.

By analyzing their respective strengths and weaknesses, aiming to equip you with the knowledge to make informed decisions regarding token-based authentication in their projects

How Does Token-Based Authentication Work?

Token-based authentication provides a secure and efficient way to manage user access in modern applications. Unlike traditional session-based methods that rely on server-side storage, token-based systems issue tokens to clients upon successful authentication.

Let's break down the typical flow:

User Login: The user initiates the process by providing their credentials (username and password) to the application.
Authentication: The application validates these credentials against a database or other authentication mechanism, verifying the user's identity.
Token Generation: Upon successful authentication, the application generates a unique, digitally signed token containing relevant user information and permissions. This token acts as a secure representation of the user's identity and access rights.
Token Delivery: The application sends the generated token to the client, usually included in the HTTP response header or body.
Client-Side Storage: Here the client securely stores the received token, often in local storage, session storage, or cookies, for use in subsequent requests.
Resource Requests: When the client needs to access a protected resource, it includes the token in the authorization header of the HTTP request. This signals to the server that the client is attempting to access a restricted area.
Token Verification: When a request with a token is received, the server confirms its validity and integrity by utilizing the corresponding secret key or public key for the token's signing algorithm.
Access Control: Based on the validated token and its embedded permissions, the server determines whether the client has the necessary authorization to access the requested resource. If authorized, the server grants access and fulfills the request. Else, access is denied.

Let's visualize the flow:

A flowchart illustrating the token-based authentication process

What is JWT?

JWT stands for JSON Web Token. It's an open standard (RFC 7519) defining a compact and self-contained method for securely transmitting information between parties as JSON objects.

JWTs are commonly used to verify user identities and granting access to private resources. Also with JWT you can securely share information between applications.

A JWT comprises three parts:

Header: This defines the token type (JWT) and the signing algorithm used. Example,

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload: It contains statements about an entity (typically, the user), and additional data. Example,

{
  "sub": "1234567890",
  "name": "John Doe",
  "iat": 1516239022
}

Signature: This verifies the token's authenticity and integrity. Its created by combining the encoded header, encoded payload, a secret, and the specified signing algorithm. Example (using HMAC SHA256):

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

How JWT Works?

The process involves:

Token Generation: Upon successful user authentication, the server generates a JWT containing user information and permissions. This token is signed using a secret key.
Token Sent to Client: The server sends the JWT to the client, usually within the HTTP response header.
Client Stores Token: The client securely stores the JWT, often in local storage or cookies.
Client Requests Resource: The client includes the JWT in the authorization header for subsequent requests to private resources.
Server Validates Token: The server validates the JWT's signature and expiration time by using the secret key.
Access Granted/Denied: Based on the token validation, the server grants or denies access to the requested resource.

Pitfalls Of JWT

While JWT offers many advantages, it's essential to be aware of potential pitfalls and security concerns that can arise if not implemented properly.

Here are some key issues associated with JWT tokens:

Algorithm Confusion

JWT allows for flexibility in choosing signing algorithms, including the option of "none".

If developers mistakenly set up their applications to accept unsigned tokens, it can make them ineffective and vulnerable. Attackers could exploit this by forging tokens with arbitrary claims.

Key Management Issues

It's security system heavily relies on proper key management. Weak keys or improper storage can compromise the entire system.

A leaked or compromised keys allow attackers to forge tokens or decrypt sensitive information.

Lack of Built-in Revocation

JWTs are stateless, meaning the server doesn't maintain a record of issued tokens.

Revoking tokens before they expire can be a challenge, especially in cases of compromised keys or user logout.

Bypassing Signature Verification

Vulnerabilities in certain JWT libraries and implementations allow for signature verification to be bypassed.

These vulnerabilities could enable attackers to create forged tokens that appear legitimate to the application.

What is PASETO (Platform Agnostic Security Token)?

Paseto, which stands for Platform-Agnostic Security Tokens, is a specification for secure stateless tokens.

It provides a modern and better alternative to JWT, addressing some of its inherent vulnerabilities and emphasizing secure defaults and ease of implementation.

Paseto Structure

Unlike JWT's single, generic structure, Paseto employs a versioned approach with two distinct token purposes:

Local tokens: This is designed for stateful, server-side sessions where the tokens are securely stored on the server-side and associated with a user's session.
Public tokens: This is intended for stateless applications and use cases involving public-key cryptography. These tokens can be securely transmitted and verified without needing server-side storage.

Both local and public tokens share a similar structure, consisting of three parts:

Header: This section identifies the Paseto version and purpose (local or public) along with the specific cryptographic algorithm used.
Payload: Similar to JWT, the payload contains claims representing information about an entity (usually the user) and any additional data relevant to the application.
Footer (optional): The footer can include additional authenticated data, providing extra security and context to the token.

How PASETO Works?

Paseto's core strength lies in its focus on secure defaults and well-defined implementations.

It eliminates the risk of algorithm confusion, a known vulnerability in JWT, by explicitly specifying which cryptographic algorithms should be used for each version and purpose. This approach ensures that developers don't inadvertently choose insecure options.

Local tokens: Typically use symmetric-key cryptography, where the same secret key is used for both encryption and decryption. This makes them suitable for server-side session management, where the server maintains control over the key.
Public tokens: Employ public-key cryptography, involving a public key for encryption and a private key for decryption. This enables secure communication and verification without sharing the secret key.

How to Implement JWT or Paseto in Your Project?

Here's a basic guideline for implementing either JWT or Paseto in your project:

Choose a Library: Select a library for your project. There are several options available for popular languages like Python, Node.js, Java, and Ruby.
Generate a Secret Key: Create a strong and secure secret key to sign and verify tokens. Store it securely. For local tokens, generate a secure secret key. For public tokens, generate a public-private key pair.
Implement Token Generation: Develop a mechanism to generate the token upon successful user authentication, including relevant claims in the payload.
Implement Token Validation: Implement logic on the server-side to validate the token received in requests, verifying the signature and expiration time.
Secure Token Storage: On the client-side, securely store the JWT (e.g., HttpOnly cookies with the Secure flag).
Handle Token Expiration: Implement a strategy to handle expired tokens, such as refresh tokens or requiring re-authentication.
Payload extraction and verification: This steps works only for Paseto, where the payload and verified the to ensure the authenticity and integrity of the information.

Key Differences Between Paseto vs JWT

Structure

Aspect	Paseto	JWT
Approach	Versioned approach with specific purposes (local/public)	Single, generic structure
Components	Header, payload, optional footer	Header, payload, signature
Formatting Rules	Stricter formatting and implementation rules	More flexible, allowing for various algorithms and claims

Security Features

Aspect	Paseto	JWT
Algorithm Confusion	Eliminated by specifying algorithms per version/purpose	Potential vulnerability if "none" algorithm is allowed
Key Management	Promotes better practices by design	Requires careful implementation to avoid vulnerabilities
Revocation	Easier due to versioning and purpose-specific design	Stateless nature makes it challenging; requires additional mechanisms
Configuration Defaults	Enforces secure algorithms and configurations	Allows for potential misconfigurations and vulnerabilities if not implemented carefully

Use Case Scenarios

Token	Paseto	JWT
Local Tokens	Stateful server-side sessions (e.g., traditional web apps)	Can be used for various use cases, including both stateful and stateless applications
Public Tokens	Stateless authentication with public-key cryptography	Suitable for various scenarios but requires careful consideration of security implications

An image showing the structural difference of Paseto and JWT

Choosing Between Paseto and JWT

Both Paseto and JWT offer distinct advantages and disadvantages, making the choice dependent on your specific needs and priorities.

Here are some factors that can influence your decision:

Security Needs

Paseto: If your application demands robust security and protection against common vulnerabilities, then Paseto is probably the best fit for you. Because it is designed to mitigate issues like algorithm confusion and promote better key management practices, ensuring a higher level of security.
JWT: While JWT can be secure when implemented correctly, it necessitates meticulous attention to detail and a thorough understanding of potential pitfalls. Developers must be vigilant in avoiding common misconfiguration and vulnerabilities.

Application Architecture

Paseto: Paseto offers a clear distinction between local and public tokens, catering to different architectural requirements. Local tokens, designed for stateful server-side sessions, are ideal for traditional web applications with session management. Public tokens, geared towards stateless applications and public-key cryptography, align well with microservices and API-driven architectures.
JWT: It's flexible structure accommodates both stateful and stateless applications. However, this flexibility can also lead to ambiguity and potential misuse, if not handled carefully.

Developer Familiarity

Paseto: While Paseto's ecosystem is steadily growing, it might not yet match the breadth and depth of JWT's support. Developers might need to invest additional effort in finding appropriate libraries and understanding Paseto's specific implementations.
JWT: Due to its earlier adoption and widespread usage, JWT benefits from a larger community and readily available libraries, frameworks, and documentation across various programming languages. This makes it easier for developers to find resources and implement JWT within their projects.

Ecosystem Support

Paseto: It's ecosystem is expanding, with libraries and tools becoming increasingly available for popular programming languages. However, it may not yet match the comprehensive support of JWT, particularly for less common languages or frameworks.
JWT: JWT enjoys extensive support across numerous programming languages, frameworks, and libraries. This widespread adoption ensures readily available resources and simplifies integration with existing tools and infrastructure.

The Future of Web Tokens

The web tokens landscape is constantly evolving, driven by advancements in cryptography, changing security threats, and the ever-growing need for secure and efficient authentication mechanisms.

Here are some emerging ideas that may shape the future of web tokens:

Enhanced Security and Cryptography

Quantum-resistant cryptography: With the looming possibility of quantum computers breaking existing cryptographic algorithms, the development and adoption of quantum-resistant algorithms will be crucial for future-proofing web tokens.
Post-quantum cryptography: Research and standardization efforts are underway to develop and integrate post-quantum cryptography algorithms into token-based systems, ensuring long-term security and resilience against quantum threats.

Decentralized Identity and Self-Sovereign Identity (SSI)

Verifiable credentials: With the rise of verifiable credentials, this allows individuals to control and manage their digital identities, which may influence how tokens are used for authentication and authorization.
Decentralized Identifiers (DIDs): This enables decentralized and self-owned identifiers, and could be integrated with token-based systems to enhance privacy and user control over personal data.

Improved Usability and Standardization

Simplified token management: Efforts to streamline token generation, revocation, and renewal processes will improve user experience and developer efficiency.
Standardization of token formats and protocols: Further standardization of token formats and communication protocols will promote interoperability and simplify integration across different platforms and services.

Emerging Token Mechanisms

Macaroons: This offer a more flexible and granular approach to authorization, allowing for delegation and attenuation of access rights.
Token binding: This mechanisms can mitigate token theft and replay attacks, enhancing the security of token-based systems.

Influence on Paseto and JWT

Paseto's focus on security and well-defined use cases positions it well for adoption in environments with high-security requirements and where standardization is valued.

Its versioned approach allows for adaptation and integration of future cryptographic advancements.

JWT's flexibility and widespread adoption may lead to its continued use in various applications. However, its security shortcomings might necessitate additional safeguards and careful implementation practices to mitigate risks.

The future of web tokens will probably involve a combination of existing and emerging mechanisms, each catering to specific needs and security considerations.

Summing Up

In this article, we've highlighted the strengths and weaknesses of each token mechanism, emphasizing the importance of understanding your specific needs and priorities.

While JWT provides simplicity and flexibility, Paseto prioritize security and well-defined use cases.

Evaluating factors such as security requirements, application architecture, and developer familiarity will guide you toward the most suitable option.

Additionally, exploring emerging solutions like Permify, which offers a comprehensive authorization platform with fine-grained access control, can further enhance your application's security and flexibility.

The choice between JWT and Paseto is not a one-size-fits-all answer, but a decision based on your unique context.

Let's keep the conversation going! Join our Discord community to share your thoughts and experiences with JWT, Paseto, and other token mechanisms.

References

JWT Resources:

Paseto Resources:

Further Reading:

Consistent Hashing: An Overview and Implementation in Golang

Ege Aytin — Tue, 07 May 2024 12:48:51 +0000

What Is Hashing?
What Is Consistent Hashing?
What Problem Does Consistent Hashing Solve?
How Consistent Hashing Work?
Where is Consistent Hashing Used?
Implementing Consistent Hashing in Golang
Conclusion

Ever wondered how big tech websites like Netflix, Twitch, Facebook, etc. handle huge amounts of traffic and data without slowing down or crashing? The technique that makes this possible is consistent hashing. As a developer, understanding consistent hashing is a useful skill in your toolbox.

In this tutorial, we'll give you an in-depth overview of consistent hashing and walk you through implementing it in Golang.

What Is Hashing?

Hashing is a technique used to map data of an arbitrary size to data of a fixed size. In simple terms, it maps keys to values. The values are called hash codes or hash values.

A hash function is used to generate the hash code. It takes the key and returns the hash value.
A good hash function has the following properties:

Uniform distribution: It should map keys to hash values uniformly. Each hash value should have an equal chance of being the output of the hash function.
Deterministic: The same key should always map to the same hash value.
Efficiently computable: It should be fast to compute the hash value for any key.

Hashing is used for several purposes, like:

Hash tables: To map keys to values for faster lookups.
Cryptography: For message authentication and digital signatures.
Caching: To map keys to cached data.

What Is Consistent Hashing?

This is a special kind of hashing technique. It maps keys to hash values in a way that the mapping between keys and hash values remains consistent even when the number of hash values changes.

What Problem Does Consistent Hashing Solve?

Consistent hashing solves the problem of caching by randomly mapping data to physical nodes in the cluster. With a regular hash function, adding or removing one node changes the mapping of nearly every key.

Consistent hashing minimizes the number of keys that need to be remapped when a node is added or removed. It is useful in distributed caching and database systems where the number of nodes changes Frequently.

It also solves the problems caused by hash collisions. Hash collisions occur when two keys map to the same hash value. This leads to extra work to handle the collision.

How Consistent Hashing Work?

Hashing is a way of mapping data of arbitrary size to fixed-size values. A hash function takes input data and converts it into a hash value. The hash table stores the data using the hash value as the key.

Distributed hashing is an extension of hashing used in distributed data stores. It allows data to be distributed across multiple nodes.

Image by Abhinav Singh

In consistent hashing, the hash values are arranged in a ring. Each key is mapped to one of the hash values on the ring.

When a hash value is added or removed, only the keys mapped to that hash value are remapped. The other keys remain mapped to the same hash value.

The key's hash value is used to determine which node the data is stored on. As nodes add or remove from the cluster, the mapping of keys to nodes changes. This can require massive data movement.

Each node in the cluster receives one or more points on the ring. The system maps the key to a point on the ring and stores it on the node that contains that point.

When a new node is added, it takes over some points on the ring. Only the keys that map to those points move to the new node. The keys mapped to other points stay where they are.

Similarly, when a node is removed, its points on the ring are taken over by the remaining nodes. But keys mapped to other points are unaffected.

Where is Consistent Hashing Used?

Many real-world applications use consistent hashing to distribute data across a cluster of servers. Some major use cases include:

Distributed caching
Consistent hashing is a popular technique for distributed caching systems like Memcached and Dynamo. In these systems, the caches are distributed across many servers. When a cache miss occurs, consistent hashing is used to determine which server contains the required data. This allows the overall cache to scale to handle more requests.

Distributed storage
Distributed storage systems like Cassandra, DynamoDB, and Voldemort also use consistent hashing. In these systems, data is partitioned across many servers. Consistent hashing is used to map data to the servers that store the data. When new servers are added or removed, consistent hashing minimizes the amount of data that needs to be remapped to different servers.

Load Balancing
Many people commonly use consistent hashing for load balancing in distributed systems. It allows you to add or remove nodes from the cluster without affecting too many keys. With a traditional hash function, adding or removing a node changes the mapping of nearly every key. Consistent hashing minimizes the number of keys that need to be remapped.

Peer-to-Peer Networks
Some peer-to-peer networks use consistent hashing to map nodes to the key space. This allows nodes to join and leave the network with minimal disruption. New nodes can take over responsibility for keys that were previously assigned to nodes that left.

DNS
The domain name system (DNS) uses consistent hashing to map domain names to DNS servers. This fault tolerance is provided by reassigning the keys of a DNS server to other servers with minimal changes if it goes down.

Implementing Consistent Hashing in Golang

To implement consistent hashing in Golang, you'll need to have the following installed

A code editor, VS Code Preferably
Golang
hashicorp/memberlist: go get -u github.com/hashicorp/memberlist
grpc-go: go get -u google.golang.org/grpc
protobuf: go get -u google.golang.org/protobuf/proto

Step 1: Define the Protocol Buffers (proto) file

Before we begin let's define the following terms:

Protocol Buffers (protobuf):
Protocol Buffers, or protobuf, is a data serialization format developed by Google. It offers a language-agnostic way to define data structures, enabling efficient serialization and deserialization across different programming languages.

gRPC:
gRPC, which stands for gRPC Remote Procedure Calls, is an open-source RPC framework, also developed by Google. It uses protobuf as its interface definition language, describing the structure of data exchanged between servers and clients.

Now, create a file named consistency.proto and add the following code:

syntax = "proto3";

package consistency;

service Node {
  rpc GetNodeForRequest (NodeRequest) returns (NodeResponse);
  rpc AddNodeForRequest (NodeRequest) returns (Empty);
  rpc RemoveNodeForRequest (NodeRequest) returns (Empty);
}

message NodeRequest {
  string key = 1;
  string node = 2;
  string ip = 3;
}

message NodeResponse {
  string node = 1;
}

message Empty {}

Run the following command to generate Go files from the proto file:

protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative consistency.proto

This command generates consistency.pb.go and consistency_grpc.pb.go.

Step 2: Implement Consistent Hashing and gRPC Service

Let's break down this step into three parts for better understanding.

Part 1: Initialization and Type Definitions

In this part, we initialize the HashRing struct, which represents the consistent hash ring. The struct includes fields for maintaining nodes, their corresponding IP addresses, keys, and a memberlist for handling membership in the distributed system.

package main

//import these packages
import (
    "context"
    "fmt"
    "hash/crc32"
    "log"
    "net"
    "sort"
    "sync"

    "github.com/hashicorp/memberlist"
    "google.golang.org/grpc"
)

// HashRing represents the consistent hash ring
type HashRing struct {
    sync.RWMutex
    Nodes    []string
    nodeToIP map[string]string
    nodeToKey map[string]uint32
    mlist    *memberlist.Memberlist
}

// NodeService represents the gRPC service for nodes
type NodeService struct {
    HashRing *HashRing
}

HashRing struct: It includes a mutex for thread safety, a slice to keep track of nodes, maps for storing node-to-IP and node-to-key mappings, and a memberlist for handling membership.
NodeService struct: It represents the gRPC service and holds a reference to the HashRing struct.

Part 2: The Functions

Here, we define the functions that perform actions on the hash ring, such as adding nodes, removing nodes, and getting the node responsible for a given key.

// AddNode adds a new node to the hash ring
func (hr *HashRing) AddNode(node string, ip string) {
    hr.Lock()
    defer hr.Unlock()

    if _, ok := hr.nodeToKey[node]; ok {
        return // Node already exists
    }

    key := crc32.ChecksumIEEE([]byte(node))
    hr.nodeToIP[node] = ip
    hr.nodeToKey[node] = key
    hr.Nodes = append(hr.Nodes, node)
    sort.Strings(hr.Nodes)

    // Update memberlist
    _, err := hr.mlist.Join([]string{ip})
    if err != nil {
        log.Fatalf("Failed to join memberlist: %v", err)
    }
}

// RemoveNode removes a node from the hash ring
func (hr *HashRing) RemoveNode(node string) {
    hr.Lock()
    defer hr.Unlock()

    if _, ok := hr.nodeToKey[node]; !ok {
        return // Node does not exist
    }

    delete(hr.nodeToIP, node)
    delete(hr.nodeToKey, node)

    // Remove the node from the slice
    for i := len(hr.Nodes) - 1; i >= 0; i-- {
        if hr.Nodes[i] == node {
            hr.Nodes = append(hr.Nodes[:i], hr.Nodes[i+1:]...)
        }
    }

    // Update memberlist
    _, err := hr.mlist.Leave(10 * memberlist.NodeMetaPreload)
    if err != nil {
        log.Fatalf("Failed to leave memberlist: %v", err)
    }
}

// GetNode returns the node responsible for the given key
func (hr *HashRing) GetNode(key string) string {
    hr.RLock()
    defer hr.RUnlock()

    hash := crc32.ChecksumIEEE([]byte(key))
    index := sort.Search(len(hr.Nodes), func(i int) bool {
        return hr.nodeToKey[hr.Nodes[i]] > hash
    })

    if index == len(hr.Nodes) {
        index = 0
    }

    return hr.Nodes[index]
}

// GetNodeForRequest returns the node responsible for the given gRPC request
func (ns *NodeService) GetNodeForRequest(ctx context.Context, req *NodeRequest) (*NodeResponse, error) {
    node := ns.HashRing.GetNode(req.Key)
    return &NodeResponse{Node: node}, nil
}

// AddNodeForRequest adds a new node for the given gRPC request
func (ns *NodeService) AddNodeForRequest(ctx context.Context, req *NodeRequest) (*Empty, error) {
    ns.HashRing.AddNode(req.Node, req.Ip)
    return &Empty{}, nil
}

// RemoveNodeForRequest removes a node for the given gRPC request
func (ns *NodeService) RemoveNodeForRequest(ctx context.Context, req *NodeRequest) (*Empty, error) {
    ns.HashRing.RemoveNode(req.Node)
    return &Empty{}, nil
}

AddNode, RemoveNode, GetNode: These functions handle modifications to the hash ring.
GetNodeForRequest, AddNodeForRequest, RemoveNodeForRequest: These functions are gRPC service methods for corresponding client requests.

Part 3: The Main Function

This part includes the main function where we set up the memberlist, create the gRPC server, register the service, and start the server.

func main() {
    // Example usage
    hashRing := &HashRing{
        nodeToIP: make(map[string]string),
        nodeToKey: make(map[string]uint32),
    }

    // Create and start memberlist
    config := memberlist.DefaultLocalConfig()
    config.Name = "localhost" // Set a unique name for the node
    list, err := memberlist.Create(config)
    if err != nil {
        log.Fatalf("Failed to create memberlist: %v", err)
    }
    hashRing.mlist = list

    // Create and register gRPC server
    server := grpc.NewServer()
    nodeService := &NodeService{HashRing: hashRing}
    RegisterNodeServer(server, nodeService)

    // Start gRPC server
    listener, err := net.Listen("tcp", ":50051")
    if err != nil {
        log.Fatalf("Failed to listen: %v", err)
    }
    defer listener.Close()

    log.Println("Server listening on :50051")
    if err := server.Serve(listener); err != nil {
        log.Fatalf("Failed to serve: %v", err)
    }
}

Initialization: We create a HashRing instance and configure a memberlist.
Server Setup: We create a gRPC server, register the NodeService, and start listening for connections on port 50051.

Create a file named consistency.go, and add the code snippets of the 3 parts into the file for the complete implementation.

Step 3: Build and Run

Run the following command to build and run the gRPC server:

go run consistency.go

This will start the gRPC server on localhost:50051.

Step 4: Test with a gRPC Client

Create a file named client.go with the following code to test the gRPC server:

In this code, we will add and remove two keys ("key1" and "key2") with corresponding nodes ("Node-A" and "Node-B").

package main

import (
    "context"
    "fmt"
    "log"

    "google.golang.org/grpc"
)

func main() {
    // Connect to the gRPC server
    conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
    if err != nil {
        log.Fatalf("Failed to connect: %v", err)
    }
    defer conn.Close()

    client := NewNodeClient(conn)

    // Add nodes
    client.AddNodeForRequest(context.Background(), &NodeRequest{Node: "Node-A", Ip: "127.0.0.1"})
    client.AddNodeForRequest(context.Background(), &NodeRequest{Node: "Node-B", Ip: "127.0.0.1"})

    // Get node for key1
    key1 := "key1"
    response1, err := client.GetNodeForRequest(context.Background(), &NodeRequest{Key: key1})
    if err != nil {
        log.Fatalf("Error getting node for key1: %v", err)
    }
    fmt.Printf("Key '%s' belongs to Node: %s\n", key1, response1.Node)

    // Remove Node-A
    client.RemoveNodeForRequest(context.Background(), &NodeRequest{Node: "Node-A"})

    // Get node for key2
    key2 := "key2"
    response2, err := client.GetNodeForRequest(context.Background(), &NodeRequest{Key: key2})
    if err != nil {
        log.Fatalf("Error getting node for key2: %v", err)
    }
    fmt.Printf("After removing Node-A, key '%s' belongs to Node: %s\n", key2, response2.Node)
}

After running this code, your output should look like this;

Key 'key1' belongs to Node: Node-A
After removing Node-A, key 'key2' belongs to Node: Node-B

This output indicates the node assignment for each key before and after removing a node. The specific output will depend on the keys and nodes you choose during the execution.

Conclusion

Now you understand the basics of consistent hashing and have built a simple implementation of a consistent hash ring in Golang. Consistent hashing is a clever solution for mapping keys to nodes in a distributed system.

You've seen how it handles node additions and removals gracefully without disrupting the entire mapping. While this was just a basic example, the concepts you learned apply to more complex, real-world systems.

How to Add Firebase Authentication To Your NodeJS App

Ege Aytin — Wed, 01 May 2024 16:48:58 +0000

Security is an absolute must for any application, whether you are building a simple pet project or a potential unicorn startup.

Therefore, it's important to implement robust authentication systems to not only protect user data but also to provide personalized experiences to users.

In most cases, we tend to build authentication systems from scratch; this has been the de facto approach. However, an alternative and often more efficient method is to utilize existing tools and services that are already up to industry standards.

This way, you don't need to worry about the nitty-gritty details of security implementations, but rather, you can focus your efforts on building the core functionality of your apps.

In this tutorial, we'll explore Firebase Authentication and walk you through the step-by-step process of securing Node.js apps by integrating Firebase authentication providers.

Getting Started With Firebase Authentication in Node.js
Step 1: Setting Up Your Firebase Project
Step 2: Configure Firebase Authentication Service
Step 3: Creating A Node.js Project
Step 4: Initializing Firebase in Your Node.js Application
Step 5: Implementing Authentication Features
Step 6: Handling Basic User Authentication Processes
Step 7: Handling Account Management Tasks
Step 8: Defining the API Routes
Testing Authentication Flow
Best Practices When Handling Authentication Using Firebase
Conclusion

Let's get started!

Getting Started With Firebase Authentication in Node.js

Firebase Authentication offers an easy-to-use SDK that simplifies the process of adding authentication features to your Node.js apps. The beauty of this SDK lies in its ability to abstract away complex security implementations, such as password hashing and multi-factor authentication, allowing you to focus on building your application's core functionality.

The SDK supports multiple authentication providers, including email/password combinations, social providers like Google, and more. This ensures that your apps cater to diverse user requirements, enabling them to authenticate with their preferred method.

Prerequisites

Before you get started, make sure you have the following:

Basic knowledge of Node.js and its environment setup. If you don't have Node.js installed on your system, make sure you download and install it from the official Node.js website.

Node.js comes bundled with npm (Node Package Manager)—it will be installed automatically with Node.js. You will use it to install a number of libraries that you use in your project.

After completing the installation process, you can run the following commands on your terminal to check if both Node.js and npm are installed correctly:
```
node --version
npm --version
```
An active Firebase project and familiarity with the Firebase Console. Don't worry too much about this; in the next section, I will walk you through the process of setting up a Firebase project and navigating the Firebase console.
A code editor (VS Code is my go-to IDE), but feel free to use any code editor you're comfortable with.

With these prerequisites in place, you are ready to dive into the project. Let's start by creating a Firebase project.

Step 1: Setting Up Your Firebase Project

To get started, follow these steps to set up a Firebase project:

Head over to Firebase Developer Console homepage, sign in using your Gmail address, and click the Go to Console button to navigate to the console's overview page.
On the console's overview page, click the Create a project button to create a new project. Then, provide a name for your project.
Once the project is successfully created, navigate to the project's overview page. You need to register your application on Firebase to generate API keys.

To register an app, click on the Web icon (highlighted in the image below), provide the app name, and click on the Register app button.
After registering your Node.js app, Firebase will provide your app's configuration object code. This code includes your API keys and other project-specific details.

Copy this configuration object code; you'll need it later when integrating Firebase SDK into your Node.js application.

Great! You've successfully created a new Firebase project and registered a web application within that project. In the next step, you'll learn how to configure Firebase authentication service in the developer console.

Step 2: Configure Firebase Authentication Service

Once you have registered your application on Firebase, the next step is to configure the Firebase Authentication service.

In your project's overview page, select Authentication section, and click on the Get started button.

Firebase Authentication supports multiple authentication providers, for this tutorial however, we will focus on implementing the native email/password provider to secure your Node.js app.

On the authentication settings page, click on the Sign-in method tab, then click the Email/Password provider button.Then, toggle the Enable button.

Make sure to also enable the Email link feature. Later on, we will make use of this feature to implement email verification and password reset functionality for the authentication system of the Node.js app.

To enable Email link feature, toggle the Enable button in the Email link (passwordless sign in) section, and then click Save.

After saving the changes, the status of the email/password provider will change to Enabled.

If you want to add a new provider, simply click the Add new provider button.

Now, with these updates, you are ready to jump into the code and implement the authentication functionality in your Node.js app.

Step 3: Creating A Node.js Project

Now, before you dive into the code, let's go over the objectives. Essentially, we need to build a Node.js authentication API that is powered by Firebase SDK. This means we'll create various routes, along with their handler functions to allow users to register, login, logout, verify their emails, as well as reset their passwords.

Instead of building this functionality from scratch, we will tap into the Firebase email/password provider and the SDK's user authentication methods.

To get started, first, create a folder locally to hold your project files. Then, change the current directory to the project's working directory.

mkdir firebase-auth-node
cd firebase-auth-node

Next, go ahead, and initialize npm to create a package.json file, which will hold the project's dependencies.

npm init --y

Now, you need to install a couple of packages for this project. For the web server, we will create an Express.js app. Go ahead and install Express.js, as well as these additional packages.

npm install express cookie-parser firebase firebase-admin dotenv

The firebase package allows you to access the Firebase SDK for Node.js and its functionalities. We'll also use firebase-admin, which provides a server-side interface for interacting with Firebase services, including Authentication.

Now, go ahead, and open your project folder in your preferred code editor to start development.

Step 4: Initializing Firebase in Your Node.js Application

Let's add the Firebase SDK configurations to your Node.js application. To do that, in your root project folder, create a folder called src, as well as a .env file—this file will hold your application's environment variables.

Inside the src folder, create a new config directory. Inside the config directory, add a new file called firebase.js.

Now, copy and paste the Firebase SDK configuration object code from the Firebase Console to your .env file as follows:

//file : .env 

PORT=5000

FIREBASE_API_KEY=<your-api-key>
FIREBASE_AUTH_DOMAIN=<your-auth-domain>
FIREBASE_PROJECT_ID=<your-project-id>
FIREBASE_STORAGE_BUCKET=<your-storage-bucket>
FIREBASE_MESSAGING_SENDER_ID=<your-messaging-sender-id>
FIREBASE_APP_ID=<your-app-id>

Then, in the config/firebase.js file, include the following code to initialize Firebase in your Node.js (Express) application:

// file: src/config/firebase.js 


require("dotenv").config();
const firebase = require("firebase/app");

const firebaseConfig = {
  apiKey: process.env.FIREBASE_API_KEY,
  authDomain: process.env.FIREBASE_AUTH_DOMAIN,
  projectId: process.env.FIREBASE_PROJECT_ID,
  storageBucket: process.env.FIREBASE_STORAGE_BUCKET,
  messagingSenderId: process.env.FIREBASE_MESSAGING_SENDER_ID,
  appId: process.env.FIREBASE_APP_ID
};

firebase.initializeApp(firebaseConfig);

With this code, you have successfully initialized Firebase SDK in your application. Now, let's create the Express server. In your src directory, create an app.js file, and include the following code:

// file: src/app.js 

const express = require('express');
const cookieParser = require('cookie-parser');
require("dotenv").config();
const PORT = process.env.PORT || 8080;

const app = express();

app.use(express.json())
app.use(cookieParser())

app.get('/', (req, res) => {
    res.send('Hello World');
});

app.listen(PORT, () => {
    console.log(`Listening on port ${PORT}`);
});

Go ahead and start the development server.

node src/app.js

You should see the log output indicating that the server is listening on port 5000.

Awesome! With these changes, you have successfully created an Express application and initialized Firebase in your project to access its features.

Let's proceed to implement the authentication features. We need to define endpoints, as well as their handler functions to manage the authentication functionality.

Step 5: Implementing Authentication Features

There are a few things you need to be aware of about how the Firebase SDK handles authentication. The Firebase SDK provides methods attached to the firebase/auth module to handle various authentication workflows.

Since we're implementing the email/password provider, we'll primarily focus on the methods that allow us to create a new user with an email address and password, log a user in, log them out, and handle user account management tasks such as email verification and password resets.

To access the auth module and its methods, make the following addition to the config/firebase.js file:

// file: src/config/firebase.js 

const { 
  getAuth, 
  createUserWithEmailAndPassword, 
  signInWithEmailAndPassword, 
  signOut, 
  sendEmailVerification, 
  sendPasswordResetEmail

} = require("firebase/auth") ;

Make sure to export them as follows:

// file: src/config/firebase.js 

module.exports = {
  getAuth,
  signInWithEmailAndPassword,
  createUserWithEmailAndPassword,
  signOut,
  sendEmailVerification,
  sendPasswordResetEmail,
  admin
};

Let's start by implementing the handler functions that manage the user authentication processes.

Step 6: Handling Basic User Authentication Processes

You need define controller functions that will manage the requests to register, login, or logout users. To do that, create a controllers folder. Inside this folder, include a new file called firebase-auth-controller.js, and then,First, import the following methods:

// file: src/controllers/firebase-auth-controller.js 

const { 
  getAuth, 
  createUserWithEmailAndPassword, 
  signInWithEmailAndPassword, 
  signOut, 
  sendEmailVerification,
  sendPasswordResetEmail
 } = require('../config/firebase');

Each of the authentication methods takes a number of parameters, including a mandatory auth object that needs to be included and passed alongside the requests. To access this object, go ahead and include this code:

// file: src/controllers/firebase-auth-controller.js 

const auth = getAuth();

This object is essential for authentication methods because it provides a secure and isolated context for each user's authentication state. By passing it alongside the authentication requests to Firebase backend, you ensure that the operations are performed within the correct authentication context, preventing unauthorized access or manipulation of user data.

Now, there are a couple of ways you can define your controller functions. Essentially, it's really important to keep the codebase concise and readable.

In this case, you can opt to create each handler function independently, or alternatively, bundle all related handlers into a class and export the instance itself.

You can then tap into the class methods to access the handler functions. To do that, start by creating the controller's class. Then, define the user registration handler function:

// file: src/controllers/firebase-auth-controller.js 

class FirebaseAuthController {
  registerUser(req, res) {
    const { email, password } = req.body;
    if (!email || !password) {
      return res.status(422).json({
        email: "Email is required",
        password: "Password is required",
      });
    }
    createUserWithEmailAndPassword(auth, email, password)
      .then((userCredential) => {
        sendEmailVerification(auth.currentUser)
          .then(() => {
            res.status(201).json({ message: "Verification email sent! User created successfully!" });
          })
          .catch((error) => {
            console.error(error);
            res.status(500).json({ error: "Error sending email verification" });
          });
      })
      .catch((error) => {
        const errorMessage = error.message || "An error occurred while registering user";
        res.status(500).json({ error: errorMessage });
      });
  }

}

module.exports = new FirebaseAuthController();

To register a user, this code will check for the presence of email and password in the request body.

If provided, it utilizes Firebase's createUserWithEmailAndPassword method to create a new user account( Firebase also provides a dedicated Cloud storage to manage this data—you can view the registered users on the console. Upon successful registration, Firebase's sendEmailVerification method is invoked to send a verification email.

Notice that we are including the email verification within the registration endpoint. There are various approaches to this, especially when you have a client consuming such an API; it all depends on your app's specific requirements.

For instance, a common scenario would be—on the client-side—the user provides their credentials to register, then they get redirected to a new page, or you update a component to render an email verification prompt where the user provides their email.

Then, Firebase handles verification by sending the user a verification link to their email, such as this one:

So, ideally, you can opt to separate the registration handler and email verification handler function, and then, consume them separately as needed.

But in this case, once the user is registered, we immediately tap into the user's authentication data in the response body, and send a verification link to the email address. Once they click that email, they should be verified (this logic is handled by Firebase).

You should also note that by default, when you use the createUserWithEmailAndPassword method, it internally performs a sign-in operation after successfully creating the user.

This behavior is a design choice in Firebase Authentication to maintain consistency and simplicity in the authentication flow. This ensures that the newly created user is authenticated and can immediately access protected resources or perform other actions without the need for an additional log-in step.

Now to handle users sign-in's, within the same class, go ahead and include the following login handler. We'll use the signInWithEmailAndPassword method to allow users to sign in with their credentials:

 // file: src/controllers/firebase-auth-controller.js 

 loginUser(req, res) {
    const { email, password } = req.body;
    if (!email || !password) {
        return res.status(422).json({
            email: "Email is required",
            password: "Password is required",
        });
    }
    signInWithEmailAndPassword(auth, email, password)
        .then((userCredential) => { 
          const idToken = userCredential._tokenResponse.idToken
            if (idToken) {
                res.cookie('access_token', idToken, {
                    httpOnly: true
                });
                res.status(200).json({ message: "User logged in successfully", userCredential });
            } else {
                res.status(500).json({ error: "Internal Server Error" });
            }
        })
        .catch((error) => {
            console.error(error);
            const errorMessage = error.message || "An error occurred while logging in";
            res.status(500).json({ error: errorMessage });
        });
  }

There are a couple of things happening in this code. First, it handles user login by extracting email and password from the request body, ensuring both are provided.

Upon a successful login attempt, it retrieves the user's authentication token (Firebase handles the token creation process by default) from the user object returned in the response body, and stores it in an HTTP-only cookie named access_token.

Why is this important? Well, securing your app's resources is of paramount concern. This means you need to be able to ensure that you only allow access to authenticated and legitimate users.

Firebase SDK's handles JWT token generation, providing you with a variety of tokens, including the access and refresh tokens in the stsTokenManager object in the response body.

In this case, we are setting the idToken, which holds information about the authenticated user, in a cookie. Whenever a user makes subsequent requests, the token will be include in the requests, and you can, through a middleware, access the token and validate it.

However, it's important to note that this is just one way of implementing user authentication and protecting your application's resources. You can further enhance the security of your application by implementing additional measures, such as implementing role-based access control.

Now, to handle the token validation process, you need to define a middleware function that will validate the token.

Firebase provides tools for this, but it requires a service account first—a JSON file containing credentials and information necessary for server-to-server interactions with Firebase services. It will grant your Node.js application access to Firebase's administrative features, including token validation.

To access the service account, head over to your Firebase console, click on the Settings icon in the top-left corner of the developer console, and select Project Settings. Then, select the Service Account tab, and click on Generate new private key.

Copy and paste the downloaded JSON file from the download folder into the src directory of your project, and rename it as follows: FirebaseService.json.

Then. in the config/firebase.js file, include the following code:

// file: src/config/firebase.js

const admin = require('firebase-admin');
const serviceAccount = require("../firebaseService.json");

admin.initializeApp({
  credential: admin.credential.cert(serviceAccount),
});

This code initializes the Firebase Admin SDK in the Node.js app, providing administrative access to Firebase services, using the service account credentials loaded from the JSON file.

This ensures that the application has the necessary privileges to interact with and manage Firebase resources programmatically, including accessing and validating tokens included in subsequent HTTP requests.

Make sure to export the admin instance in your code.
module.exports = {admin};

Now, create the middleware that will validate the tokens. To do that, create a new middleware directory in the src folder, and inside this folder, create a new index.js file, and include the following code:

// file: src/middleware/index.js

const { admin } = require("../config/firebase");
const verifyToken = async (req, res, next) => {
    const idToken = req.cookies.access_token;
    if (!idToken) {
        return res.status(403).json({ error: 'No token provided' });
    }

    try {
      const decodedToken = await admin.auth().verifyIdToken(idToken); 
        req.user = decodedToken;
        next();
    } catch (error) {
        console.error('Error verifying token:', error);
        return res.status(403).json({ error: 'Unauthorized' });
    }
};

module.exports = verifyToken;

This middleware will verify the authenticity of the tokens passed in subsequent requests, ensuring secure access to protected routes. We'll include it in the routes that require authentication.

Finally, include this logout handler to sign out users, and clear the token cookies:

 // file: src/controllers/firebase-auth-controller.js 

logoutUser(req, res) {
    signOut(auth)
      .then(() => {
        res.clearCookie('access_token');
        res.status(200).json({ message: "User logged out successfully" });
      })
      .catch((error) => {
        console.error(error);
        res.status(500).json({ error: "Internal Server Error" });
      });
}

This function will effectively logs out a user, clear their access token cookie, and sends an appropriate response.

Step 7: Handling Account Management Tasks

Now, let's implement a handler function that will allow users to manage and reset their passwords. Firebase will take care of the underlying complexities, from generating the email reset link and sending it, to updating the password.

To do that, include this resetPassword controller in the controllers class:

// file: src/controllers/firebase-auth-controller.js 

resetPassword(req, res){
    const { email } = req.body;
    if (!email ) {
      return res.status(422).json({
        email: "Email is required"
      });
    }
    sendPasswordResetEmail(auth, email)
      .then(() => {
        res.status(200).json({ message: "Password reset email sent successfully!" });
      })
      .catch((error) => {
        console.error(error);
        res.status(500).json({ error: "Internal Server Error" });
      });
  }

The sendPasswordResetEmail method will send a password reset email to the specified email address. Users can then update their update their passwords through Firebase's UI page rendered on the browser.

Step 8: Defining the API Routes

Now, create a new routes folder. Inside this folder, add a new index.js file, and include the following contents:

// file: src/routes/index.js 

const express = require('express');
const router = express.Router();

const firebaseAuthController = require('../controllers/firebase-auth-controller');

router.post('/api/register', firebaseAuthController.registerUser);
router.post('/api/login', firebaseAuthController.loginUser);
router.post('/api/logout', firebaseAuthController.logoutUser);
router.post('/api/reset-password', firebaseAuthController.resetPassword);

module.exports = router;

Then, import the routes object in the app.js file as follows:

// file: src/app.js 

const router = require("./routes");
app.use(router);

Great! Let's proceed to testing your API's authentication functionality.

Testing Authentication Flow

Go ahead and restart the development server.

node src/app.js

There are several testing approaches you can take to ascertain the functionality of the auth API. One way would be to automate the testing using unit tests with tools like Jest and Supertest. Alternatively, you can make use of API clients like Postman or the Thunder Client VS Code extension to test the API.

In this case, we'll make use of Postman to test the various endpoints. For starters, assuming you want to register a new user using their email and password, go ahead and make a POST request and pass these values to this endpoint: http://localhost:5000/api/register.

You should receive a successful registration status message along with the email verification message. Check your inbox for the email, and click the link provided to verify your email address.

The good thing is that Firebase provides default UI pages for such processes. However, depending on your implementation, feel free to customize the pages to match your app's designs.

Now, with the same credentials, make a POST request to the http://localhost:5000/api/login endpoint to test the login endpoint.

Once a user successfully logins with their credentials, a user object with various user-specific information is returned. Assuming they had verified their email after registration, the response will include an emailVerified key with a true value. You can then use this information to allow them to access certain features or resources in your application.

Moreover, once they log in, the access token will be set in the cookies as follows:

Once this is set, it will be automatically included in subsequent requests in the app to access protected resources.

For instance, assuming you want to build a blog and render a list of posts to authenticated users, go ahead, and create a new controllers/post-controller.js file. Then, define the following controller that should return a list of user posts:

// file: src/controllers/post-controller.js

class PostsController {
    getPosts(req, res) {
        const usersPosts = {
            "1": "Post 1",
            "2": "Post 2",
            "3": "Post 3",
        };
        res.send(usersPosts);
    }
}

module.exports = new PostsController();

Next, include this route, along with the verifyToken middleware you created earlier to validate the token passed alongside the requests.

// file: src/routes/index.js 

const verifyToken = require('../middleware');
const PostsController = require('../controllers/posts-controller.js');
router.get('/api/posts', verifyToken, PostsController.getPosts);

This way, once you successfully log in and make a GET request to access the list of posts through this endpoint: http://localhost:5000/api/posts, you should receive the following data as a response:

Remember, this is just a basic implementation. Ideally, the PostsController should be trying to access your app's resources, including data in the database, and return it to the user on the client-side app.

Now, assuming a user wants to reset their password, Firebase's sendPasswordResetEmail takes the auth object and email as parameters, and similar to the email verification method, it sends a password reset email containing a link that allows you to access the password reset UI page.

Click the link provided in the password reset email to access the Firebase default password reset UI page to reset and save the new password.

Note that when you want to update the password using the Firebase Authentication reset password method, you should use the POST HTTP method to send the request, instead of the PATCH method. Ideally, Firebase's reset password flow typically involves the following steps:

The client sends a POST request to a server endpoint (e.g., /api/reset-password) with the user's email address in the request body.
The server receives the request and calls the sendPasswordResetEmail function from the Firebase Authentication SDK, passing the provided email address.

In this flow, the client is not updating a specific resource on the server. Instead, the client is initiating a password reset process by sending a POST request with the user's email address. The server then triggers the Firebase Authentication password reset flow, which is handled entirely by Firebase.

The PATCH method, however, is typically used when you want to update a specific resource on the server, such as a user's profile data or a specific document in a database. However, in the case of the Firebase Authentication reset password method, there is no specific resource being updated on the server side. The server is simply acting as an intermediary to initiate the password reset process with Firebase.

Best Practices When Handling Authentication Using Firebase

When handling authentication using Firebase, it's essential to follow best practices to ensure secure and efficient authentication systems. Here are some key points to consider:

Securing Firebase API keys in Node.js applications is a critical step to maintain the security and integrity of your application.

The recommended approach is to store sensitive information like Firebase API keys and configuration details as environment variables on your server or hosting platform. This prevents these sensitive values from being exposed in your codebase, reducing the risk of accidental leaks or unauthorized access.
Firebase authentication provides a robust and scalable authentication system that supports various authentication providers.

However, it's also essential to implement proper user management practices, such as handling authentication states appropriately in your application, including implementing secure storage mechanisms for user tokens (e.g., encrypted cookies or local storage), as well as handling token refresh when necessary to maintain uninterrupted access for the user.
And when users logout or sessions expire, revoke access tokens to prevent unauthorized use of user accounts.
When handling errors related to authentication and user management, implement proper error handling mechanisms that capture and log errors, while also, displaying user-friendly messages and feedback UI screens to guide users through appropriate steps to resolve issues, as well as provide a great user experience.

Avoid logging raw error messages or stack traces (especially in production), as they may contain sensitive information that could be utilized for malicious purposes.

Furthermore, make sure to implement input validation and sanitization to prevent common security vulnerabilities like SQL injection, cross-site scripting (XSS), and other types of attacks.

Conclusion

In this article, we covered the essential steps to integrate Firebase Authentication into a Node.js application, covering the implementation of user registration, login, logout, and password reset functionality using Firebase Authentication SDK.

If you're interested in learning more about Firebase Authentication and its integration with Node.js, here are some valuable resources:

Firebase authentication documentation.
You can find this project's code in this GitHub repository.

Firebase offers a comprehensive suite of services beyond just Authentication, including Realtime Database, Cloud Firestore, Cloud Functions, and more. We encourage you to explore these services to build scalable, secure, and feature-rich applications.

Policy-Based Access Control (PBAC): A Comprehensive Overview

Ege Aytin — Tue, 16 Apr 2024 14:22:24 +0000

Broken access control, privilege creep and role explosion put all organizations at risk. Long gone are the days when we just had couple roles within an organization, today we’re looking at dozens or even hundreds of different roles. This not only makes the task of managing roles harder but it also puts those organizations at risk.

What Is Policy Based Access Control (PBAC)?
Differences Between ABAC, RBAC, ReBAC and PBAC
Major Strengths of PBAC
PBAC Use Cases And Examples
Conclusion

Modeling and managing user access within systems is more crucial than ever for data security, integrity and compliance.

There are plenty of access control models available on the market today.

Well-known examples include:

Role-Based Access Control (RBAC),
Relationship-Based Access Control (ReBAC),
Attribute-Based Access Control (ABAC).

However, in this piece we're focusing on the PBAC model also known as Policy-Based Access Control and how it differentiates itself these from traditional access control models in terms of scalability, flexibility and security.

What Is Policy Based Access Control (PBAC)?

To put it simply, it is an authorization method which governs access to resources based on policies that reflect an organization's business objectives.

The PBAC model uses both attributes and roles to derive policies, unlike traditional access control frameworks where only roles or attributes are used to derive access rights. This feature makes PBAC a truly powerful and dynamic approach to control parameters.

Powered by Policy As Code (PaC)

Unlike traditionally where policies are manually enforced, not scalable and lack framework for implementation. The PBAC model applies policies in a completely different way.

The PBAC model uses a methodology called policy as code (PaC), meaning that policy can be written directly into code.

It gets rid of the manual work of compliance teams and merges into the code automating its processes along the way. From version control, review and validation, everything is automated from A to Z.

And you’ve guessed it, there are multiple benefits to automating policy management with PaC, here are some of them:

More secure
Helps avoiding human error
Easier to audit
Running test cases is a lot easier
Check and enforcement of policy is automated
Automation = Scalable
Saves times and money
Integrates policy within development
Gives a framework to how policies are to be implemented

Note: A policy can be anything that governs operations and processes within an application or organization using PBAC, this can be a rule, condition or an instruction.

Differences Between ABAC, RBAC, ReBAC and PBAC

To better explain the differences between PBAC and these common access control models, first, we'll give a brief summary of them, then move on to PBAC and the differentiation.

Let's start with Attribute Based Access Control (ABAC).

Attribute-based Access Control (ABAC)

An ABAC model will use attributes derived from a subject, resource or environment to decide if access is granted or not to a resource within a system.

These attributes can be any value which makes this model able to handle complex scenarios.

In this model, authorization is more fine-grained because these attributes can have a dynamic value which can change.

Enabling us to define dynamic authorization rules and behaviors, one example is controlling which action can be performed within a system based on a user’s time, location and IP address.

ABAC models can get quite complex and come with the risk of unwanted behaviors if the values of these attributes aren’t looked after and audited. It is also complex to administrate, it takes longer to learn and become an expert at.

Role-based Access Control (RBAC)

In a RBAC model permissions are defined as actions a user can take on a resource.

These permissions are then grouped into roles and those roles are then assigned to subjects in a system. These subjects can be Users, Groups or Systems.

Roles in this type of model are static making it a lot easier to map and see how they relate to each other.

The RBAC model comes with a downside which is role explosion.

This happens when there are so many authorization scenarios that a large number of roles are required to cover all of them. Which makes the task of managing roles a lot more difficult and in some cases can be a security concern.

One of the downsides of this model is that it takes considerable time to implement because administrators need time to figure out each role and their permissions.

Relationship-based Access Control (ReBAC)

As the name says, this model relies on relationships to derive authorization.

This is done by ascribing relationships between subjects and resources in a system. These relationships can get quite complex when grouping resources. ReBAC is a “policy-as-data” type of model, unlike other models which are “policy-as-code” type.

This type of authorization modeling can be done with other models, but is a lot easier and concise when done with ReBAC because a graph is often used to build this type of model.

It is also a flexible model allowing us to have authorization at a resource level and it also offers a parent-child relationship between subjects and resources.

Policy-based Access Control (PBAC)

PBAC has some key benefits over older frameworks, the key reason is that policies are used to derive authorization by combining both a subject’s tasks and policies using a policy-as-code methodology.

Another key feature which makes it a lot more attractive than other solutions is its simplicity in creating and testing policies. This is great for running audits and being compliant with strict privacy laws in certain jurisdictions.

While a role-based system grants access based on roles, a policy based system grants access based on policies, this offers us a lot of flexibility when managing access permissions. PBAC models are built to scale with an organization’s growth through automation, write once and it takes care of the rest.

Unlike ABAC where rules are written in eXtensible Access Control Markup Language (XACML) or using the Open Policy Agent (OPA) using the Rego language which is often hard to understand for someone without a background in IT.

On the other hand, PBAC providers allow policies to be coded in a plain language format and in some cases using a Graphical User Interface (GUI). Making implementing access control policies easier for management teams by not having to rely on the IT department to make changes every now and then.

Here’s a simple illustration of how a PBAC model would work in a work environment with employees:

Pieces of information and data are the building blocks of a PBAC model, it relies on them to make access decisions. By using existing data it offers a flexible solution to policy building. In terms of clarity PBAC is the winner, it gives administrators a clear view of who has access to what, when and how across all assets within an organization.

Let’s have a deeper look into what makes PBAC so unique.

Major Strengths of PBAC

Dynamic and Flexible

PBAC models are dynamic, meaning that they can take multiple parameters into consideration when granting access and permissions to a user, which enables us to be specific when creating rules.

User attributes (Employee, CEO, CTO)
Resource attributes (File, Database, Network segments)
Action attributes (Login, Read, Write)
Contextual or environmental attributes (Physical Location, Device, Time)

PBAC uses Boolean logic when assessing if access should be granted or not, it does so by processing these attributes in an “if, then” manner which is different from other models.

We can apply rules within a PBAC system in a fully-automated fashion, making it adaptable to changing conditions, such as not allowing an employee to gain access to a system during weekends from his home computer. This gives us more control and enables us to make access decisions in real-time with high-granularity by taking context into consideration.

Policy based systems are dynamic by nature, making them adaptable to an organization's needs, whether it’s a small startup or a full blown enterprise with dozens of departments.

They’re also blazingly fast, as an administrator you have full control over user permissions, you can add, remove or edit permissions to every single user within an organization at the click of your mouse.

Secure and Reliable

As humans we’re prone to errors and this is no exception when it comes to managing policies and access control. Policy management can be automated within a PBAC system removing the need of a human to manually review policies which is great for security.

Another benefit of using the PBAC model is the separation of privileges within an organization where each component is isolated to minimize the risk in the event of a security breach. Take for example a hacker who compromises one segment of a network, they won’t get full access to the rest of the network if privileges are strictly regulated across the network.

PBAC closes the security gaps left open by RBAC and this is done by being proactive with access control security.

Compliant and Consistent

Being compliant today is important when it comes to following regulatory laws in certain jurisdictions. PBAC systems make the task a lot easier for compliance teams to follow legal requirements from data privacy and security laws such as GDPR, HIPAA and CPRA.

PBAC enables us to easily align internal policies with access control by regulating access to sensitive data across an organization or application in a consistent and systematic way.

PBAC Use Cases And Examples

As said earlier, PBAC is extremely dynamic in nature and can adapt to different environments. It can scale with an organization’s growth, if a policy states that “HR can access employee data”, it does not matter if there are a hundred or a thousand employees. The policy still applies and is enforced.

Let’s have a look at real-world examples where PBAC is in action:

Let’s see a simple example of an attorney working in a legal firm, here’s how access control policies in a PBAC system would be applied to him.

User Policy: Allow access to the firm’s main portal.
Resource Policy: Allow access to client files assigned to him.
Action Policy: Allow permission to read and edit files of clients.
Environmental and Contextual Policy: Block access to the firm's portal on Sunday’s and Saturday’s.

Here’s how it would be implemented in Python using the Cedar policy language:

from cedar.client import CedarClient

# Initialize Cedar client
cedar_client = CedarClient(api_key='YOUR_CEDAR_API_KEY_HERE', base_url='CEDAR_API_BASE_URL_HERE')

# User Policy: Allow access to the firm's main portal.
user_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'resource': {
            'portal': 'firm'
        }
    },
    'permission': 'allow'
}

# Resource Policy: Allow access to client files assigned to him.
resource_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'resource': {
            'file_type': 'client'
        }
    },
    'permission': 'allow'
}

# Action Policy: Allow permission to read and edit files of clients.
action_policy = {
    'condition': {
        'user': {
            'role': 'employee'
        },
        'action': {
            'read': True,
            'edit': True
        }
    },
    'permission': 'allow'
}

# Environmental and Contextual Policy: Block access to the firm's portal on Sundays and Saturdays.
contextual_policy = {
    'condition': {
        'day': ['Sunday', 'Saturday'],
        'resource': {
            'portal': 'firm'
        }
    },
    'permission': 'deny'
}

# Add policies to Cedar
cedar_client.add_policy('user_policy', user_policy)
cedar_client.add_policy('resource_policy', resource_policy)
cedar_client.add_policy('action_policy', action_policy)
cedar_client.add_policy('contextual_policy', contextual_policy)

# Here’s how to check access for a user attempting to login into the firm's portal on a Sunday.
user_attributes = {'role': 'employee'}
resource_attributes = {'portal': 'firm'}
day = 'Sunday'

access_permission = cedar_client.check_access(user_attributes, resource_attributes, day)
print("Access permission:", access_permission)

Conclusion

There are multiple access control models out there, all with their pros and cons when it comes to authorization management.

As we’ve seen, some of them require a high level of expertise in access control management to implement, others not.

In this article, we’ve seen the nuts and bolts of each one of them and how they manage and derive access control rulings using either attributes, roles, relationships or policies.

The PBAC model using the policy-as-code approach to define, update and enforce policies helps bridge the gap between the RBAC and ABAC model, offering the best of both worlds.

It fills the gap left by older models, by making management easier and by being preventative and blocking potential doors leading to vulnerabilities.

DEV Community: Ege Aytin

What is SCIM Provisioning: In-Depth Guide [2024]

What is SCIM provisioning?

How SCIM Works

How to implement a custom SCIM Server?

How to Evaluate SCIM providers?

Key features to look for in SCIM providers

Factors influencing the choice of a SCIM provider

What are the Top SCIM Providers?

Comparison table of the top SCIM providers

Testimonials from organizations that have benefited from using SCIM

How to make the right choice?

Common pitfalls to avoid during selection process

SCIM Provider recommendations based on specific needs and scenarios

Related Reading

OAuth vs. JWT: Ultimate Comparison

Understanding OAuth

What is OAuth?

How OAuth Works?

OAuth Versions

Use Cases of OAuth

Understanding JWT (JSON Web Tokens)

What is JWT?

Structure of a JWT

Example Scenario: User Authentication

Use Cases of JWT

Comparing OAuth and JWT

Key Differences

Pros and Cons

OAuth Advantages

OAuth Disadvantages

JWT Advantages

JWT Disadvantages

How OAuth and JWT Work Together

Integration Scenarios

Benefits of Combining OAuth and JWT

Real-World Examples

Choosing the Right Solution

Factors to Consider

Recommendations for Different Scenarios

When to Use OAuth

When to Use JWT

When to Combine Both

Wrapping Up

How To Build Centralized Authorization System

What you'll learn:

The Decoupling Authorization Concept

What is a Centralized Authorization System?

What is Distributed Authorization?

Strengths and Weaknesses

Use case 1: A banking application

Centralized Authorization Systems

Weaknesses:

Decentralized Authorization Systems

Strengths:

Use case 2: A real-time messaging application

Centralized Authorization Systems

Decentralized Authorization Systems

How Centralized Authorization Systems Work?

Centralized vs. Distributed Authorization

Implementing Centralized Authorization Systems with Permify

Summary and Conclusion

Opa Gatekeeper: How To Write Policies For Kubernetes Clusters

What is Open Policy Agent (OPA)?

How OPA And Kubernetes Work Together?

What is OPA Gatekeeper?

Writing Policies In Kubernetes Clusters With OPA Gateway

Prerequisites

1. Defining namespaces policies

2. Allocating resources quotas

3. Writing a custom controller

Summary and Conclusion

How to Implement Two-Factor Authentication (2FA) in Golang

Prerequisites

Understanding Two-Factor Authentication (2FA)

How 2FA Works

What is Time-Based One-Time Passwords (TOTP) ?

Setting Up Your Golang Environment

Implementing Two-Factor-Authentication in Golang

Step 1: Choosing a 2FA Method