Forem: mohanapraneswaran

Application server vs Web server

mohanapraneswaran — Tue, 20 Aug 2024 03:34:31 +0000

The topic I’m writing about is quite common, and most people are already familiar with it. So, why am I writing this blog? The reason is simple: understanding these concepts was challenging when I was a beginner in web development. As a newbie to Nginx and other web servers, I often found myself confused. Every article I read would say that Nginx is a web server and that WildFly (which I encountered while working with Keycloak) is an application server. But back then, understanding the difference between the two wasn't as easy as it seems now.

In this blog, I aim to explain the difference between application servers and web servers in a beginner-friendly way, based on my own learning experiences.

Server

Before knowing about web servers and application servers, let’s first understand what a server is. A server is another machine or program that provides functionality and services to other devices or programs(known as a client). For example, when you want to read this blog, you click the link in your browser. Your browser then calls the URL, which the DNS (Domain Name System) translates into the IP address of the machine where this website is hosted. That machine then returns the content of this blog to your browser. In this scenario, that machine is called a server.

Web server

A web server is a type of server that delivers web page content such as HTML, CSS, JavaScript, and images using HTTP protocols. When you click a link in your browser, your request is sent to a web server, which processes the request and returns the requested content. Web servers are primarily designed to serve static content. However, static content alone isn't sufficient for many modern applications. Often, we need to process requests and generate dynamic content based on user interactions or data. In such cases, the web server works in conjunction with an application server to process the request and deliver the appropriate dynamic content.

Some of the most widely used modern web servers in the industry include Nginx, Apache HTTP server, and Microsoft IIS.

Application server

An application server is designed to handle business logic and serve dynamic content by interacting with various hardware components such as databases. When a web server needs data to fulfill a request, it interacts with the application server to retrieve that data. The application server acts as middleware between the web server and the underlying resources.

Some of the most widely used modern application servers in the industry include WebSphere, WildFly, and GlassFish.

Example

When you want to read this blog, you first connect to the web server. The web server serves the static content like HTML, CSS, and JavaScript. However, it doesn’t have dynamic content, such as the data of this blog post. To retrieve that data, the web server calls the application server. The application server then interacts with the database to get the necessary data and returns it to the web server. Finally, the web server compiles the full page, combining static and dynamic content, and sends it back to the user.

Major differences

Feature	Web Server	Application Server
Primary Function	Serves static content (HTML, CSS, JavaScript, images)	Serves dynamic content by executing application logic and interacting with databases or other resources
Example Use Case	Delivering a simple website with static pages	Delivering a complex web application that requires user-specific data or real-time processing
Interaction	Handles HTTP requests and responses directly	Processes business logic and communicates with databases, web services, and other resources
Examples	Apache HTTP Server, Nginx, Microsoft IIS	Apache Tomcat, WildFly, GlassFish, IBM WebSphere, Oracle WebLogic
Support for Protocols	Primarily HTTP/HTTPS	Supports a variety of protocols (HTTP, SOAP, REST, RMI, etc.) for communication between applications and services
Configuration	Configured to handle static file serving, URL routing, and caching	Configured to manage application deployment, transaction handling, and resource pooling

Conclusion

Both application servers and web servers are essential components of modern web development. In recent times, many of the tasks traditionally handled by application servers have been managed by frameworks, but it's still crucial to understand how both types of servers work. I hope this provided a simple and clear introduction to the roles of web servers and application servers.

Beyond JWT: Unlocking PASETO for Secure Token Management

mohanapraneswaran — Sun, 07 Jul 2024 10:59:46 +0000

In today's web world, secure connections are essential. JWT (JSON Web Tokens) is widely used for token-based authentication to verify requests, but it has its own disadvantages. New types of token authentication methods are emerging, and one of them is PASETO (Platform-Agnostic Security Tokens). In this article, we will first explore what JWT is and the issues associated with it. Then, we will introduce PASETO, highlighting its differences from JWT. Additionally, we will discuss the different types of PASETO tokens and provide a step-by-step guide on how to generate and validate them.

What is JWT?

JSON Web Token (JWT) is a compact, URL-safe way to transfer information between two parties. It contains three parts: a header, a payload, and a signature. The header includes the token type and signing algorithm, the payload contains details about the user and token like issuer, expiry time, user id, other claims, and the signature verifies the token's authenticity. JWTs are commonly used in authentication systems, where a server generates a token after a user logs in, and the client uses this token to access protected resources. It is a base64 encoded string.

Problems In JWT

1. Widely Misused:

Weak Signing Algorithms: JWT offers a variety of signing algorithms, some of which are known to be vulnerable. Developers may mistakenly choose a weak algorithm, leading to security risks.

2. Signing Algorithm:

None Algorithm: JWT allows for using "none" as the signing algorithm, effectively disabling signature verification. This can lead to vulnerabilities where attackers can forge or tamper with JWT tokens.

What is PASETO?

PASETO (Platform-Agnostic Security Tokens) is a modern security token format designed to be safer and more straightforward than JSON Web Tokens (JWT). Developed by Scott Arciszewski, PASETO addresses security issues inherent to JWT while promoting simplicity and robustness.

PASETO structure:

v1.local.1_5gaMPojdToeX6Kc6CV751PlwowSrvMUYuVAApH5HOdEh3MSCf3fQ6xsf1_zSprLvcDqUxXZIjNbaaQfpz12d9kmoM8p8oVG5wI-n_4Xghh29eJoVm2kuJ9K4seOBRNWugwqVTTSCwHuJyAM-sWD9sCOIYCrUAa0VR4Z5_XIRbCxvN4xU3aplUoRpZUssFYkxdKWgr3DXc6nD1CkrcE40wUhOk-jGVI7-QSp4_JDcceV7RYigr5q4KFKHRfI65Oznh4ucRAQw

The first section of the PASETO is the protocol version (v1). This tells you what version of the PASETO standard is being used. At the time of writing, there are two versions(v1 and v2) of the PASETO standard.

The second section of the PASETO is the purpose (local). PASETO only defines two purposes for tokens: local or public. I’ll expand on these later. For now, just know that the local purpose is the one I’m demonstrating here.

The third section of the PASETO defines the actual token contents, also known as the payload. It contains details about users and the token itself, such as claims, issuer, and other relevant information.

Uses for PASETO:

you can use PASETOs for two different purposes: symmetric (aka local) and asymmetric (aka public).

Local (Symmetric Encryption)

Local PASETOs are created and encrypted using a secret key, which functions like a long password. If anyone obtains the local PASETO token, they cannot extract any useful information from it without the secret key. As long as the secret key remains secure, the PASETO is safe even if shared publicly.

Use Case: You can use local PASETOs to verify one web service with another. For instance, a microservice architecture where an internal service needs to authenticate requests to another internal service can benefit from using local PASETOs. By encrypting the token with a shared secret key, only the intended service can decrypt and validate the token, ensuring secure communication between services.

Public (Asymmetric Encryption)

Public PASETOs use a pair of public and private keys for encryption. The private key is used to sign the token, and the public key is used to verify its authenticity. This method ensures that the token can be verified by anyone with the public key but only signed by the private key.

Use Case: Public PASETOs are ideal for scenarios where you need to ensure that a token's authenticity can be verified by multiple parties without exposing the private key. For example, in a distributed system where different clients need to validate the token's authenticity, public PASETOs provide a secure solution. Only the server with the private key can sign the token, but any client with the public key can verify it, maintaining the token's integrity and trustworthiness.

Difference between JWT and PASETOs:

PASETO in Quarkus

To create and use PASETO in a Quarkus project, follow these steps. This example uses Gradle as the build tool, but you can also use Maven if you prefer.

1. Create a Quarkus Project

First, create a new Quarkus project. You can do this using the Quarkus CLI or through the Quarkus website.

2. Add Dependencies

Add the following dependencies to your build.gradle file. For Maven users, search for the corresponding dependencies in the Maven repository and add them to your pom.xml.

    implementation 'dev.paseto:jpaseto-api:0.7.0'
    implementation 'dev.paseto:jpaseto-impl:0.7.0'
    implementation 'dev.paseto:jpaseto-jackson:0.7.0'
    implementation 'dev.paseto:jpaseto-bouncy-castle:0.7.0'

3. Implement PASETO Creation

package com.grootan;

import dev.paseto.jpaseto.Pasetos;
import dev.paseto.jpaseto.lang.Keys;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

import javax.crypto.SecretKey;
import java.time.Instant;
import java.time.temporal.ChronoUnit;
import java.util.Random;

@Path("/token/create")
public class CreateTokenService {

    public static final SecretKey SHARED_SECRET = Keys.secretKey();
    @GET
    @Produces(MediaType.TEXT_PLAIN)
    public String createToken() {
        Instant now = Instant.now();

        String token = Pasetos.V1.LOCAL.builder()
                .setSharedSecret(SHARED_SECRET)
                .setIssuedAt(now)
                .setExpiration(now.plus(1, ChronoUnit.HOURS))
                .setAudience("blog")
                .setIssuer("https://ezto.io/")
                .claim("1d20", new Random().nextInt(20) + 1)
                .compact();

        return token;
    }
}

A PASETO token is then created using the Pasetos.V1.LOCAL.builder(). The following claims and properties are set on the token:

setSharedSecret(SHARED_SECRET): Sets the shared secret key used for encryption.
setIssuedAt(now): Sets the issued-at timestamp to the current time.
setExpiration(now.plus(1, ChronoUnit.HOURS)): Sets the expiration time to one hour from now.
setAudience("blog"): Sets the audience claim to "blog".
setIssuer("https://ezto.io/"): Sets the issuer claim to the specified URL.
claim("1d20", new Random().nextInt(20) + 1): Adds a custom claim, simulating a random dice roll between 1 and 20.

The compact() method finalizes the token creation process, returning the token as a string.

You can make get request to this API to get your PASETO.

4. Implement PASETO Verification:

package com.grootan;

import dev.paseto.jpaseto.Paseto;
import dev.paseto.jpaseto.PasetoParser;
import dev.paseto.jpaseto.Pasetos;
import dev.paseto.jpaseto.Version;
import dev.paseto.jpaseto.lang.Keys;
import jakarta.ws.rs.POST;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

import java.security.KeyPair;

import static com.grootan.CreateTokenService.SHARED_SECRET;

@Path("/token/verify")
public class VerifyTokenService {

    private static final KeyPair KEY_PAIR = Keys.keyPairFor(Version.V1);

    @POST
    @Produces(MediaType.TEXT_PLAIN)
    public String verifyToken(String token) {
        PasetoParser parser = Pasetos.parserBuilder()
                .setSharedSecret(SHARED_SECRET)
                .setPublicKey(KEY_PAIR.getPublic())
                .requireAudience("blog")
                .requireIssuer("https://ezto.io/")
                .build();

        Paseto result = parser.parse(token);
        return result.getClaims().getIssuer();
    }
}

PasetoParser is built using the Pasetos.parserBuilder() method. The parser is configured with:

setSharedSecret(SHARED_SECRET): The shared secret key used for symmetric encryption.
setPublicKey(KEY_PAIR.getPublic()): The public key used for asymmetric encryption.
requireAudience("blog"): A requirement that the token must have the audience "blog".
requireIssuer("https://ezto.io/"): A requirement that the token must have the issuer "https://ezto.io/". The token is parsed using the parser.parse(token) method, which returns a Paseto object. If the token is valid, this method returns the issuer claim from the token.

You can make a post request with the token to this API to verify your PASETO.

Limitations of PASETO

While PASETO (Platform-Agnostic Security Tokens) offers several improvements over JWT (JSON Web Tokens), it also has its own set of limitations. Here are some key limitations to consider:

Reusability:

Not reusable: PASETOs are meant to be single-use tokens and do not have protections against replay attacks. If an attacker intercepts a valid PASETO, they could reuse it to make multiple valid requests, which is not the intended use of PASETOs.

Ecosystem:

Not Mature: The ecosystem around PASETO is not as mature as JWT’s. There are fewer implementations and integrations available for various programming languages and frameworks.
Limited Documentation: Compared to JWT, there is less documentation, tutorials, and examples available for PASETO, which can hinder learning and adoption.

Learning Curve:

New Concepts: For developers familiar with JWT, PASETO introduces new concepts and a different approach to security tokens. This can require additional learning and adjustment.
Complexity: Understanding and correctly implementing the PASETO specification can be more complex for developers new to it.

Interoperability:

Compatibility: Since JWT is more widely adopted, many systems and services are built around JWT. This can make interoperability with existing systems challenging if they do not support PASETO.
Tooling and Infrastructure: Existing tools, middleware, and infrastructure might not support PASETO, requiring additional effort to integrate or replace these components.

Algorithm Support:

Fixed Algorithms: PASETO uses fixed algorithms for each version (e.g., AES-256-GCM for local tokens in v1). While this increases security by reducing the risk of weak algorithms, it also limits flexibility for developers who might need different algorithm choices for specific use cases.
Version Constraints: PASETO versions (v1, v2, etc.) have strict rules about which algorithms can be used, which might not suit all cryptographic needs.

Specification Evolution:

Standard Maturity: As PASETO is relatively new, its specification is still evolving. Future changes to the specification could introduce breaking changes or require updates to existing implementations.

Conclusion

Both JWT and PASETO have their own advantages and disadvantages. As new authentication methods continue to emerge, developers will have more alternatives to explore. It is important for us to stay informed about these options and carefully evaluate which method best suits our application's needs. By understanding the strengths and weaknesses of JWT and PASETO, we can make more informed decisions to enhance the security and efficiency of our applications.

Secure Quarkus application with ezto

mohanapraneswaran — Sun, 24 Mar 2024 14:30:26 +0000

In this blog, we will learn how to create a secured API using Quarkus, Java, and ezto auth

Authentication and Authorization

Authentication:

Authentication is the process of verifying the identity of a user or system. It ensures that the user or system is who they claim to be before granting access to resources or functionalities. Think of authentication as confirming your identity to gain access to a system or application.

Imagine you work in an office building with a security entrance. Before you can enter the office and access your workspace, you need to prove that you're an employee by presenting your ID card to the security guard. In this scenario:

The office building represents the system or resource you want to access.
Your ID card represents your credentials, similar to a username and password.
Presenting your ID card to the security guard is the process of authentication.
If the security guard verifies that your ID card is valid and belongs to you, you are authenticated, and you're allowed to enter the office.

Authorization:

Authorization, is about determining what actions or resources a user or system is allowed to access after authentication. It involves verifying the permissions and privileges associated with the authenticated identity. Authorization controls what you can do or see within a system or application based on your role or level of access.

Now, let's say there are different areas within the office building, each with restricted access based on your job role. Before you can enter certain areas, the security guard checks your ID card to see if you're authorized to enter those areas. In this scenario:

The restricted areas represent the authorization rules.
Your authorization level, determined by your job role, is encoded on your ID card.
The security guard checks your ID card to verify your authorization.
Once your authorization is confirmed, you're allowed to enter the specific areas you're authorized for, but not others.

In summary, authentication verifies your identity (presenting your ID card), while authorization determines what you're allowed to access (which areas of the office you're allowed to enter based on your job role).

What is ezto auth?

ezto auth, as an IAM solution, encompasses both CIAM (Customer Identity and Access Management) and WIAM (Workforce Identity and Access Management) functionalities. For CIAM, ezto auth provides seamless customer authentication, enhancing user experience and security in digital interactions. In WIAM, ezto auth streamlines workforce identity verification and access management, enabling organizations to efficiently manage employee access to resources while ensuring compliance and security standards.
For more information about ezto, visit the ezto Auth page. Explore the features and benefits of ezto auth, including user management, role-based access control, and secure authentication methods.

Create Authentication flow in ezto auth

1. Create Your Workspace

Start by setting up your workspace in ezto auth. Just visit this page for simple instructions.

2. Craft Your Application

Next, create an application within ezto auth to manage authentication. Visit this page for a straightforward guide. You can use the default authentication flow or customize it to suit your needs.

Enable the 'Confidential' option for your application in Ezto. This option signifies that the application requires client authentication using a client ID and client secret. After enabling 'Confidential', copy both the App ID and App Secret provided by Ezto. We will utilize these credentials later in this blog for authentication purposes

3. Create user and role

Create admin, and user(this will be available by default) roles in ezto auth, Refer this page for create a role
Create a user and assign the admin role to that user. Refer this page for create and assign role for user.
And create another user with user role.
Verify users by confirming their email through the verification link provided via email.

4. Trigger Authentication Flow

Once your application is set up, click "try" to trigger the authentication process. This generates a special link users can use to verify their identity. It's as simple as clicking a button!

5. Get Your Access Token

Use that link to trigger the authentication flow, they'll be asked for their username and password(default authentication flow). After successful authentication, they'll be redirected to Ezto's debugger page, where an access token is generated. We will use that token in later this blog

Authorization in a Quarkus API

1.Initializing Your Quarkus Project

Visit code.quarkus.io to begin your Quarkus project. This site helps you set up your Quarkus application and find useful extensions.
Choose the build tool that convenient for you(In this blog we will use Maven)
Search for the "quarkus-resteasy-reactive","quarkus-oidc" dependency and add them to your project. These dependencies enable you to use RESTful web services and OpenID Connect for authentication in your Quarkus application.
Click "Generate your application", it will create a zip of your project, download, extract, and open it in IntelliJ

2. Developing API Endpoints

In this section, we'll dive into implementing authorization in our Quarkus API using role-based access control (RBAC).

Go to your project, set up a new API endpoint accessible at "/api/user". Name the endpoint class "UsersResource". This endpoint will only be accessible to users with the "user" role.

package org.sample.blog.resource;

import jakarta.annotation.security.RolesAllowed;
import jakarta.inject.Inject;
import jakarta.ws.rs.*;

import org.jboss.resteasy.reactive.NoCache;
import io.quarkus.security.identity.SecurityIdentity;

@Path("/api/user")
public class UsersResource {

    @Inject
    SecurityIdentity securityIdentity;

    @GET
    @RolesAllowed("user")
    @NoCache
    public String user() {
        return "user";
    }
}

Create a new API endpoint accessible at "/api/admin" and name the class "AdminResource". This endpoint will only be accessible to users with the "admin" role.

package org.sample.blog.resource;

import jakarta.annotation.security.RolesAllowed;
import jakarta.ws.rs.GET;
import jakarta.ws.rs.Path;
import jakarta.ws.rs.Produces;
import jakarta.ws.rs.core.MediaType;

@Path("/api/admin")
public class AdminResource {

    @GET
    @RolesAllowed("admin")
    @Produces(MediaType.TEXT_PLAIN)
    public String admin() {
        return "admin";
    }
}

We define security constraints using annotations such as @RolesAllowed("user") and @RolesAllowed("admin"). These annotations specify which user roles are allowed to access certain API endpoints.
Go to the 'resources/application.properties' file in your project to add the necessary configuration settings

# Set the base URL of the OpenID Connect (OIDC) server
quarkus.oidc.auth-server-url=https://<your-workspace>.eztoauth.com/auth/realms/<your-workspace>

# Set a client ID to identify the application (copied from application settings)
quarkus.oidc.client-id=<your-app-id-that>

# Set the client secret, used by the client_secret_basic authentication method
quarkus.oidc.credentials.secret=<your-app-secret>

# Define permissions for authenticated users
quarkus.http.auth.permission.authenticated.paths=/*
quarkus.http.auth.permission.authenticated.policy=authenticated

Explanation:

quarkus.oidc.auth-server-url: This property sets the base URL of the OIDC server. It specifies the location where authentication requests should be sent.
quarkus.oidc.client-id: This property sets a client ID that uniquely identifies your application to the OIDC server. It's used during the authentication process to identify the client.
quarkus.oidc.credentials.secret: This property sets the client secret, which is a confidential value shared between the client and the OIDC server. It's used to authenticate the client to the server.
quarkus.http.auth.permission.authenticated.paths: This property defines the paths that should be protected and require authentication. In this case, all paths (represented by '/*') are protected.
quarkus.http.auth.permission.authenticated.policy: This property specifies the policy to apply to the protected paths. The 'authenticated' policy ensures that only authenticated users can access the protected paths.

Ensure to replace "your-workspace", "your-app-id", and "your-app-secret" with the appropriate values for your application.

3. Testing Authentication Flow

For build and run your qurkus application run below comment(if you use maven)

./mvnw quarkus:dev --debug

Hit Endpoints without Authentication:

Start by attempting to access the endpoints http://localhost:8080/api/user or http://localhost:8080/api/admin in Postman. You will receive a "401 Unauthorized" status because you don't have a valid authentication token.
Trigger Authentication Flow:
- Go to your ezto auth application and copy the provided authentication URL.
- Paste the URL into your browser's address bar and trigger the authentication flow.
- Log in using a user who has the "user" role (not the admin role). This will generate an authentication token.
Access User Endpoint:
- Copy the generated authentication token.
- Use this token to hit the http://localhost:8080/api/user endpoint in Postman. You should receive a successful response.
Access Admin Endpoint:
- Attempt to access the http://localhost:8080/api/admin endpoint using the same token. You will receive a "403 Forbidden" response because the user does not have the necessary permissions to access this endpoint.
Repeat the Process with Admin Role:
- Repeat the process with a user who has admin privileges in your Ezto application.
- Generate a new authentication token for this user.
- Use the token to access both the http://localhost:8080/api/user and http://localhost:8080/api/admin endpoints in Postman.

By following these steps, you can verify that your authentication flow is functioning correctly, and access to endpoints is properly restricted based on user roles.

Conclusion:

In this blog post, we explored how to create a secure API using Quarkus, Java, and ezto auth. By leveraging ezto auth's authentication and authorization capabilities, we ensure that our APIs are protected and accessible only to authorized users.

Ezto auth simplifies the authentication process, offering robust features such as role-based access control and secure client authentication. With ezto auth, developers can streamline user management, enhance security, and ensure compliance with industry standards.

By integrating ezto auth with Quarkus, developers can accelerate the development of secure APIs while focusing on building innovative solutions. Whether you're developing internal tools or customer-facing applications, ezto provides the flexibility and scalability needed to succeed in today's digital landscape.

Unlock the full potential of your applications with Ezto - the trusted choice for authentication and access management.