DEV Community: amit17rajput

Micro Frontends

amit17rajput — Thu, 15 Jun 2023 10:38:35 +0000

Angular Micro Frontends?

Angular Micro Frontends refers to an architectural pattern, involving the breaking down of a large Angular web application into small, independent, and deployable micro-applications with every micro-application being responsible for handling its own set of features.

The Angular Miocrofrontend architecture brings various benefits for the developers and product owners such as:

1. Multiple Tech Stacks can be used simultaneously
2. Easy to Add/Update/Remove Code
3. No code Sharing
4. Single Page Applications or SPA look alike
5. Easier Application Maintenance
6. Improved Code Organization
7. Simplified Development Process
8. Efficient Debugging
9. Better Team Co-ordination
10. Enhanced Flexibility

Angular Micro frontend Architecture vs Traditional architecture

How Microfrontend architecture is different from traditional architecture let us take a few instances:

Repository

In Traditional Architecture, the Application’s all Code/Modules/Pages/Functionality are kept/committed within a single Repository, While in Angular Micro Frontend Architecture it is not needed to keep all Code / Modules/Pages/Functionality within a same Repository.

Technology
In a Traditional Architecture, all the Code / Modules/Pages/Functionality mostly shares the same technology i.e., Angular/PHP/JAVA/C#, etc. But for Micro Frontend Architecture this is not required anymore i.e., Page 1 can be of Angular, Page 2 Code can be of C#, etc.

When the Application becomes larger, the initial loading time of the application also increases, and the ‘Waiting’ scenario does not give a good impression to the end user.

Implement the Micro Frontend Angular Architecture

Iframe

The iframe is used to load nested /independent web pages along with the parent webpage.
It is an HTML element and by specifying the desired URL in the tag we can load a different webpage and implement the Microfrontend Architecture
As Iframe has its context and sharing data with a parent or other webpage becomes more difficult and all operation needs to be done using Global context and Objects i.e ‘Window ‘object of the browser and that makes the application more vulnerable.

NGINX

NGINX is an Open-Source web server created for modern web applications to provide high performance and easy to maintain the routing of different applications if all applications are on the Same server.
Based on the Config provided on file for matching route and landing page, The NGINX process the request.
As the Config file is a text file only, it’s easy to add/update and remove the mapping of route and landing page details

Third-party Libraries

Many libraries are there to implement Angular Micro Frontend Architecture, below are the some of popular libraries:

Single-SPA
Module-federation
FrintJS

This library does not need to change existing code Or logic, It needs some wrapping code/config to enable Microfrontend Architecture.

The Step-by-Step Guide to Implementing Angular Micro Frontend Architecture

From the different ways we discussed above, we will use ‘single-spa’ the popular and easy-to-implement library. Below is the Traditional / Existing Code structure that has different department-wise codes and is released independently and accessed via different URLs i.e
test1.mydomain.com / test2.mydoamin.com / test3.mydomain.com

Step 1: Create Root / Wrapper Application

Install the Package:
npm install create-single-spa <-global>
Run the below Command with Options at the root of the repository level:
create-single-spa

Here we are creating a wrapper application that will represent/wrap all different domain applications under a single Base URL, here we have used the “single-spa root config” option as the project already exists and we need to create only a wrapper.

Note: This command will install node modules as well.
The output of the above command will be:

One “root” folder will be created with some files that look like kind of config files along with common Angular files like tsconfig,package.json, etc.
Let’s understand Each file in brief:
bacancy-root-config.ts
All the desired applications must be registered here along with their path (same as router config file of Angular module)
The “index.ejs“ file loads this config file.

OAuth vs JWT : What is the Different

amit17rajput — Wed, 14 Jun 2023 12:53:13 +0000

*What Is JWT? *

_JSON Web Tokens (JWT) are an open industry standard for sharing information between two entities, typically a client (the front end of an application) and a server (the back end of an application).
A JWT contains a JSON object with information that needs to be shared. Additionally, each JWT is cryptographically signed, so that clients or malicious parties cannot modify JSON content (also known as JWT claims).

*What Is OAuth? *

_Open Authorization (OAuth) is an open standard for token-based authentication over public networks.
OAuth allows third-party services such as Facebook and Google to use end-user account information without exposing the user’s account credentials to a third party.
It acts as an intermediary on behalf of end users, providing access tokens to third-party services authorized to share certain account information. The process of obtaining a token is called the authorization flow.

Advantage of JWT token:

WT is preferred over any other authentication method because of certain distinct benefits it presents. These tokens are self-contained and don’t ask for any effort to collect info about the user.
Saves Developer efforts for database query generation or server authentication for every request. This saves a huge deal of time and effort.
JWTs are popular for better security and reliability that comes from their digitally signed nature.
No explicit signing is allowed or needed, no outside source like a hacker or another client can access them.
Using JWT asks for less digital storage space. They have generated servers and then forwarded them to the client who further stores them alongside attaching them to each most recent request.
For verification, the job is easy with JWT as it won’t ask for extensive searching of the database.

Structure of JWT tokens: Header, Payload, Signature

In case of environment that requires partial information transformation to any unverified user.
In situation demands client-side information verification at the payload.
For API and server-to-server authorization.
JWT is best used whenever you want to transmit some information to an untrusted client, in such a way that that client can verify the information contained in the payload themselves.

Open Authorization (OAuth):

The Protocol is known for allowing secured user authorization. Nothing like API or service, as OAuth is a globally-recognized standard which anyone throughout the world can use. Functional over HTTPS, it works wonderfully with servers, APIs, devices, and access-token-based applications.
With the help of OAuth, apps can decide how to allow secure and controlled access to a use for a client app. It’s widely used in Java-based, web, mobile, and browser-based app development.
OAuth 2.0 is the latest version of OAuth that works both ways, as a protocol and as a framework. It has fixed the bottleneck of early OAuth versions and promotes interoperability.

*Advantages of OAuth: *

One of the useful things about OAuth is that it enables you to delegate account access in a secure way without sharing credentials. Instead of credentials, OAuth relies on access tokens.
Highly preferred and standardized authorization protocols.
Compatible with most authentication services.
Due to compatibility, the users will have ample OAuth plug-ins and feature options.
It makes client library testing in multiple languages and frameworks possible.
It’s best for code decoupling as the appl code isn’t hampered during auth code processing.
It’s a highly secured protocol that has been tested extensively.

JWT Vs OAuth:

JWT is mainly used for APIs while OAuth can be used for web, browser, API, and various apps or resources.
JWT defines a token format while OAuth deals in defining authorization protocols.
JWT is simple and easy to learn from the initial stage while OAuth is complex.
OAuth uses both client-side and server-side storage while JWT must use only client-side storage.
JWT has limited scope and use cases. OAuth is highly flexible and can be easily used in a wide range of situations.
Both can be used together for improved authentication. They are compatible with each other and work together towards secured data transmission.

JWT (JSON Web Token) authentication

amit17rajput — Tue, 13 Jun 2023 07:17:01 +0000

REST APIs are great because they are logically simple. They don’t keep complex states in memory, and they deal with resources instead of loose, unconnected functions, making their entire business logic cohesive.

However, due to the nature and mechanics underlying ‘REST APIs, securing them is not always straightforward’. What happens after the user submits their credentials? You can’t keep a state on your server side to signal when a user has logged in on their subsequent requests, so how can you know that they’ve done so correctly?

In this article, we’ll cover one very powerful yet simple way to secure a REST API using JSON Web Tokens (JWT), reviewing some best practices and implementing an example. Let’s get started!

What is a JWT?
JSON Web Token structure
How to use JWT to authenticate a REST API
Securing a secret API: Example

What is a JWT?
JWT stands for JSON Web Token. It is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWTs are commonly used for authentication and authorization purposes in web applications and APIs.

A JWT consists of three parts:

Header: Contains metadata about the type of token and the signing algorithm used. It typically includes the token type (JWT) and the signing algorithm used, such as HMAC, RSA, or ECDSA.

Payload: Contains the claims or statements about the user or entity being authenticated. Claims are represented as key-value pairs and can include standard claims (such as issuer, expiration time, subject, audience, etc.) as well as custom claims (additional information specific to your application).

Signature: The signature is created by combining the encoded header, encoded payload, and a secret key known only to the server. The signature ensures the integrity of the token and allows the server to verify its authenticity.

JWT Process Diagram

The process of using JWTs typically involves the following steps:

Authentication: Upon successful authentication, the server generates a JWT and signs it with a secret key.

Token Issuance: The server sends the JWT back to the client, usually as a response to a login request. The client then stores the JWT securely (e.g., in local storage, cookies, or other client-side storage mechanisms).

Token Usage: The client includes the JWT in subsequent requests to the server by adding it to the request headers (e.g., Authorization header) or as a query parameter.

Token Verification: On the server side, each incoming request is checked for the presence of a JWT. The server verifies the token's signature using the secret key to ensure its authenticity and integrity.

Access Control: After verifying the JWT, the server extracts the claims from the payload and performs authorization checks to determine if the user has the necessary permissions to access the requested resource.

structure

To use JWT for authenticating a REST API, you can follow these steps:

Set up a JWT library: Choose a JWT library suitable for your programming language or framework. Install the library and any dependencies required.
Generate a secret key: Create a secret key that will be used to sign and verify JWTs. This key should be kept secure and not shared publicly.
User authentication: Implement a user authentication mechanism in your application. This could involve storing user credentials securely (such as hashed passwords) and providing a login endpoint for users to authenticate.
Generate JWT upon successful authentication: When a user successfully logs in, generate a JWT containing the necessary claims (e.g., user ID, role, expiration time, etc.). Sign the JWT using the secret key.
Protect API endpoints: Add authentication middleware or filters to protect your API endpoints. This middleware should validate the JWT included in the request's authorization header or query parameter.
Verify JWT signature: On each incoming API request, extract the JWT from the request header or query parameter. Verify the JWT's signature using the secret key. If the signature is invalid, reject the request.
Extract JWT claims: Once the JWT signature is verified, extract the claims from the JWT payload. These claims might include user ID, role, or any other relevant information.
Implement authorization checks: Use the extracted claims to perform authorization checks and ensure that the user has the necessary permissions to access the requested resource. This could involve checking roles, scopes, or any other authorization criteria.
Handling token expiration: If the JWT has an expiration time, handle token expiration properly. If a token has expired, return an appropriate response or provide a mechanism for users to refresh their tokens.
Revoking tokens (optional): If you need the ability to revoke tokens (e.g., for implementing logout functionality), you can maintain a token blacklist or use token revocation mechanisms provided by some JWT libraries.

Workflow of JWT

By leveraging JWTs, you can achieve stateless authentication, eliminate the need for session storage, and scale your application effectively. However, it's important to follow best practices for token handling, keep the secret key secure, and thoroughly test your implementation to ensure its security and reliability.