DEV Community: Sohil Lalakiya

Front-Channel vs Back-Channel Logout in OpenID Connect (OIDC)

Sohil Lalakiya — Thu, 26 Mar 2026 18:57:34 +0000

In modern authentication systems built on OpenID Connect (OIDC), we implement Single Sign-On (SSO) correctly, but we do not focus enough on the logout part. However, managing sessions across relying parties is just as important as the login itself.

Logout is not just about ending a session in one application — it is about complete session termination across all relying parties (RPs).

OIDC provides two standardized logout implementation mechanisms:

Front-Channel Logout (OpenID Connect Front-Channel Logout 1.0)
Back-Channel Logout (OpenID Connect Back-Channel Logout 1.0)

Both are official specifications designed to solve the single logout problem, and understanding the differences between them is critical for building a secure SSO system.

(1) Front-Channel Logout

Front-Channel Logout is defined in the OpenID Connect Front-Channel Logout 1.0 specification. It is a browser-based logout mechanism.

How it works:

User or RP initiates logout
RP redirects the user to the IdP’s end_session_endpoint with an ID token
IdP validates the ID token and clears its session
IdP loads the registered logout URLs of all RPs using the browser (typically via hidden iframes)

Key characteristics:

Uses the user agent (browser) as the communication medium
Relies on HTTP redirects/iframes
Requires a registered front-channel logout URL

Pros:

Easy to implement
No backend-to-backend communication needed

Cons:

Logout is not guaranteed because iframes can fail or be blocked

(2) Back-Channel Logout

Back-Channel Logout is a server-to-server logout mechanism.

How it works:

User or RP initiates logout
IdP validates the user's session
IdP generates a signed logout token (JWT) and sends it to each RP
RP validates the token and terminates the user session

Key characteristics:

Uses HTTP POST (server-to-server communication)
Requires a back-channel logout URI
The logout token is a JWT and contains the following claims:

iss (Issuer)
sub (Subject / User)
aud (Client ID)
sid (Session)
events (contains logout event claim)

Pros:

Not affected by browser restrictions and works even if the browser is closed
Logout delivery is guaranteed

Cons:

Slightly complex to implement

When should you use each?

Use Front-Channel Logout when:

You have a simple application ecosystem
Quick implementation is needed
Security is not critical

Use Back-Channel Logout when:

You are building an enterprise-grade system
Security is critical
You need guaranteed logout

PKCE Explained: Securing the OAuth 2.0 Authorization Code Flow

Sohil Lalakiya — Sun, 08 Mar 2026 15:17:03 +0000

Proof Key for Code Exchange (PKCE)

PKCE stands for Proof Key for Code Exchange. It is a security extension for the OAuth 2.0 Authorization Code Flow that protects the authorization code from interception attacks. As the name suggests, PKCE is used to secure the authorization code exchange during the OAuth authentication flow.

PKCE is primarily designed for public clients such as mobile applications and single-page applications (SPAs), which cannot securely store a client secret.

Why is it needed?

In the traditional OAuth 2.0 Authorization Code Flow:

The application requests an authorization code.
The authorization server returns the authorization code.
The application exchanges the authorization code for tokens using its client credentials (client_id and optionally client_secret).

The Problem

In the above flow, the problem is that public clients do not have a client secret. An attacker may intercept the authorization code from the redirect URI (for example through a malicious application or browser interception) and use it to obtain tokens.

PKCE prevents this attack by binding the authorization request to the token exchange request using a one-time cryptographic secret.

How PKCE works

The following diagram illustrates the OAuth 2.0 Authorization Code Flow with PKCE.

The Client application generates code_verifier and code_challenge.

code_verifier: A secure random string known only to the client application.
code_challenge: Derived from the code_verifier. It can either be the plain value of code_verifier, or the SHA256 hash of the code_verifier encoded using Base64URL (recommended method S256).

The code_challenge is sent to the authorization server in the initial authorization request. The authorization server stores the code_challenge and later verifies it during the token exchange.

Let's understand this with an example

Imagine a scenario where:

Your application URL: https://myapp.com
Your authorization server URL: https://authserver.com

Endpoints

Authorization Endpoint: https://authserver.com/authorize
Token Endpoint: https://authserver.com/token
Redirect URI: https://myapp.com/callback

Step 1: The application generates the code_verifier and code_challenge

code_verifier dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
code_challenge BASE64URL_ENCODE(SHA256(code_verifier))

Example code_challenge: E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM

Step 2: Construct the authorization URL

Construct the URL with code_challenge, code_challenge_method, and other required parameters (state, nonce, client_id, etc.) and redirect the user.

Example: https://authserver.com/authorize?client_id=myclient&response_type=code&redirect_uri=https://myapp.com/callback&scope=openidprofile&state=xyz&nonce=abc&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM&code_challenge_method=S256

Step 3: Server Storage and Redirect

The authorization server stores the code_challenge and redirects the user to the application callback URL with a temporary authorization code.

This code is used to exchange tokens, but to exchange it, the client must provide the code_verifier. Therefore, even if an attacker steals the authorization code from the URL, they cannot exchange it for tokens without the correct code_verifier.

Step 4: Token Request

The client application sends a token request with the authorization code and the original code_verifier.

Step 5: Verification

The authorization server matches the code_verifier with the stored code_challenge:
BASE64URL(SHA256(code_verifier)) == stored code_challenge

If they match, the authorization server issues the tokens. Otherwise, the request is rejected.

Conclusion

PKCE is a powerful extension to the OAuth 2.0 Authorization Code Flow that significantly enhances security, especially for public clients such as mobile applications and single-page applications (SPAs).

In modern application development, PKCE is considered a best practice for all OAuth clients, including confidential clients, because it adds an extra layer of protection against authorization code interception attacks.

Making Authentication Seamless: How SSO Works in Modern Systems

Sohil Lalakiya — Thu, 02 Oct 2025 15:31:22 +0000

Overview

In today's digital world, we use many applications in our day-to-day life, and remembering different usernames and passwords for each one is painful.

This is where Single Sign-On (SSO) comes into the picture.

SSO allows users to enter their credentials only once and then access multiple applications without having to re-enter credentials.

What is Single Sign-On (SSO)?

Single Sign-On is an authentication process that allows users to access multiple applications without being asked for credentials repeatedly.

Example: If you log in to Google once, you automatically get access to YouTube, Gmail, Google Drive, and other apps without logging in to each one separately.

Why Do We Need SSO?

User Experience: One login grants access to multiple systems
Stronger Security: Centralized authentication allows stronger controls
Reduced IT Burden: Easier user management from a central Identity Provider
Compliance & Monitoring: Centralized login activity helps with audits

Key Players in SSO

Component	Description
User	The person who accesses applications
Service Provider (SP)	The application the user wants to access (e.g., YouTube, Gmail, Google Drive)
Identity Provider (IdP)	The trusted authentication system that verifies the user's identity (e.g., Google Identity, Keycloak)
Authentication Protocol	The rules that define how the SP and IdP communicate (e.g., SAML, OAuth2, OIDC)

How Does SSO Work? (Step by Step)

Let's imagine you want to log in to Google Drive using SSO.

1. User tries to access Google Drive

Google Drive does not authenticate you directly.

2. Redirect to Identity Provider (IdP)

The IdP is now responsible for checking your credentials.

3. Authentication at the IdP

The IdP checks its session
If you are not already authenticated, it will ask for your email and password
Once authenticated, the IdP confirms your identity

4. Issue Token

The IdP generates a token for the user and sends it back.

5. Token Verification

The Service Provider verifies the token. If valid, you get access to the application.

Technical View: Full Token Exchange Flow

Since SSO can use different protocols (SAML, OAuth2, OIDC), the most modern and common is OIDC, which is built on top of OAuth2.

This guide explains the Authorization Code Flow with PKCE, which is the standard for web and mobile apps.

Step 1: User Accesses Application (Service Provider)

The user visits: https://myapp.com and clicks Login with SSO.

Step 2: Redirect to Identity Provider

The Service Provider redirects the user to the IdP with parameters:

client_id → unique ID of the app registered in IdP
redirect_uri → where IdP should send the response
scope → requested information (profile, email, openid)
response_type=code → authorization code flow
state → CSRF protection token
code_challenge → PKCE for security

Step 3: Authentication at the IdP

The browser shows the IdP login screen
The user enters username, password, maybe MFA
The IdP validates credentials → user authenticated

Step 4: Authorization Code Issued

After successful login, the IdP does not issue a token directly.

Instead, it generates an Authorization Code and sends the user back:

https://myapp.com/callback?code=AUTH_CODE&state=xyz

Now, the Service Provider makes a secure POST request to the IdP's Token Endpoint with:

client_id
redirect_uri (must match original)
grant_type=authorization_code
code=AUTH_CODE
code_verifier (PKCE check)

The IdP verifies the code and PKCE challenge. If valid → issues tokens.

Step 5: Tokens Issued

The IdP responds with:

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR...",
  "id_token": "eyJhbGciOiJSUzI1NiIsInR...",
  "refresh_token": "0d1f...xyz",
  "token_type": "Bearer",
  "expires_in": 3600
}

The Service Provider then validates:

Signature (using IdP's public key)
Expiry (exp)
Audience (aud) matches the app
Issuer (iss) matches the IdP

If valid → the Service Provider creates a session.

🔑 Final Thoughts

So, this is how SSO works — simple and seamless for the user, but under the hood it's powered by cryptography, tokens, and strict validation.

🔐 Breaking Down Identity, Authentication, Authorization & SSO

Sohil Lalakiya — Wed, 17 Sep 2025 18:12:41 +0000

In this article you will get to know about the identity system and I will help you understand the basic fundamental concepts of the identity system.

At the end of this article you will get the answers to the following questions:

What is identity?
What is authentication and authorization?
What is access control?
What are tokens?
What is SSO?

Now first let's start by understanding what identity is.

🆔 What is Identity?

Identity refers to the unique representation of a person or system within the digital ecosystem.

For example: In real life your identity includes your name, fingerprint, photo ID, and in the digital world your identity includes your username, email, and user ID.

Identity also includes some attributes which are known as identity attributes or claims. This is extra information about the user, for example: name, role, department, etc.

Now let's talk about authentication and authorization.

🔐 What is Authentication?

Authentication is a type of process for verifying who the user is.

For example: you enter your email and password, and before entering the system, the system will first compare the password with your email to verify if it is really you or not.

In the modern world, system authentication also includes OTP, biometrics, social login, etc.

🛡️ What is Authorization?

Authorization is the process of verifying what a user is allowed to do after the user is authenticated.

For example: after login, the system will check whether you are allowed to access and change user data or if you can just read the user data.

If you want to understand in simple terms:
Authentication is like a passport at the airport, and authorization will decide whether you sit in business class or economy.

🏢 What is Identity Provider (IdP)?

An identity provider is a service that manages user identities and handles authentication.

IdP stores user credentials and uses them for authentication. After authentication, it issues tokens for service provider applications.

Examples of IdPs: Google, Okta, Keycloak, etc.

🎯 What is Access Control?

Access control means controlling what users are allowed to do within the system.

There are many types of access control available, but here we have two main types:

RBAC - Role Based Access Control
ABAC - Attribute Based Access Control

RBAC: In role-based access control, permissions are based on the user's role.

For example:

admin role → can delete user
editor role → can edit and read user
viewer role → can only view user

ABAC: In attribute-based access control, permissions are based on the user's attributes, resources, and environment.

For example: Allow user if user's department is HR and resource type is employee data and action is view.

🎫 What are Tokens?

Tokens are digital objects that are used for authentication and authorization. Usually tokens are JWT-based (JSON Web Token).

There are mainly 3 types of tokens:

Access Tokens
Refresh Tokens
ID Tokens

Access Token: It is used to access protected APIs or resources. It is valid for a short time and contains permissions (roles) and user ID.

Refresh Token: This is a long-lived token and it is used for getting new access tokens when needed.

ID Token: It contains claims about the authenticated user.

🚪 What is SSO?

SSO stands for Single Sign-On. It is an authentication method that allows users to log in once and access multiple applications without re-login.

For example: you log in to your Google account and now you can access YouTube, Gmail, and Google Drive.

⚙️ How Does SSO Work?

Here all apps trust the same identity provider. So when you start an application, first it redirects the user to the IdP, but the IdP will declare the user to be verified and authenticated. Then the app will issue the token and let the user in.

🎯 Conclusion

Understanding identity and access control is fundamental for building secure digital systems. These concepts—identity, authentication, authorization, access control, tokens, and SSO—work together to ensure the right users have the right access to the right resources at the right time. Mastering these basics will help you design better, more secure applications.

Why react deprecated react-react-app ?

Sohil Lalakiya — Mon, 07 Apr 2025 04:15:00 +0000

🚨 Sunset of Create-React-App: A New Era for React Developers Begins

It's an emotional moment for all React developers and the entire React community — React has officially deprecated create-react-app (CRA) for new applications.

If you try to use create-react-app for your new projects now, you'll likely encounter an error.

According to the official React documentation and GitHub repositories, create-react-app is no longer recommended.

❓ Why Did React Deprecate Create-React-App?

create-react-app (CRA) played a major role in the React ecosystem for many years. With a single command, developers could scaffold a fully working project with:

Hot Module Replacement (HMR)
Local development server
Babel and Webpack pre-configured

However, as the needs of modern web applications grew, CRA started to fall short in key areas like:

🚀 Server-side rendering (SSR)
🔐 Authentication
📦 Code splitting
🌐 Routing
🔄 Data fetching

To achieve these features, developers often had to rely on third-party libraries, making CRA less relevant for production-ready applications.

So, to keep pace with the modern requirements, React has moved on from CRA and is encouraging developers to adopt frameworks or build tools that are better suited for complex apps.

🔄 What's Next?

React now recommends two paths for new projects or for migrating existing ones:

🧭 Option 1: Migrate to a Framework

React recommends using full-featured frameworks that support SSR and Single Page Applications (SPA) out of the box.

Here are the top suggestions:

Next.js – The most popular React framework with built-in SSR, routing, image optimization, and more.
React Router Framework – Focused on routing, now expanding to support more features.
Expo (for React Native) – A powerful toolset for building cross-platform mobile apps using React.

🛠️ Option 2: Migrate to a Build Tool

If you want more control and prefer custom setups, React recommends these modern build tools:

Vite – Lightning-fast development server with support for hot module replacement and fast builds.
Parcel – Zero-config bundler with out-of-the-box support for many features.
Rsbuild – A newer bundler optimized for performance and customization.

🚚 How to Migrate Your Existing CRA App?

You can migrate by:

Choosing a framework like Next.js
Or setting up your app manually with Vite, Parcel, or Rsbuild
Gradually moving over features like routing, state management, and build scripts

🎉 Conclusion

The deprecation of create-react-app marks the end of an era, but also the beginning of a more modern, flexible, and powerful React ecosystem.

React continues to evolve, and it's exciting to see where it's heading. Embrace the change, try out new tools, and build even better apps!

Happy Learning! 🚀

Just Deployed My Text Encryption Decryption Tool

Sohil Lalakiya — Thu, 03 Apr 2025 01:26:00 +0000

"Encryption tools are already available on the internet, but for simplicity and my own use, I built one myself!" 🔐

I have multiple accounts across different platforms, and each account has a unique password. Remembering all of them is tough! 😵💫

Earlier, I used a Google Sheet to store my passwords, but I realized that if I ever lost access to it, my passwords could be exposed. That’s when I thought—why not store them in an encrypted format instead of plain text?

To solve this problem, I built a Text Encryption & Decryption Tool using React.js and Crypto-JS. Now, I can securely encrypt my passwords before storing them anywhere! 🚀

🔹 Key Features:
✅ Supports multiple encryption algorithms

✅ Secure key-based encryption & decryption

✅ Easy-to-use interface with copy-to-clipboard functionality

✅ No server-side data storage—everything runs locally

🔧 Tech Stack: React.js, Crypto-JS, Parcel

💡 This project helped me dive deeper into cryptography and front-end security. If you also struggle with managing passwords securely.

give it a try: 🔗 Live Demo: https://encrypt-my-password.netlify.app

Github: https://github.com/sohillalakiya/password_security

Would love to hear your thoughts! Have you ever built something just to simplify your own life? 😃

ReactJS #CryptoJS #WebSecurity #Encryption #Coding #WebDevelopment 🚀

React micro-frontend architecture for your next project

Sohil Lalakiya — Fri, 28 Mar 2025 03:29:53 +0000

React Micro Frontend Architecture

Welcome to the React Micro Frontend Architecture project!

What is Micro Frontend?

Micro Frontend is an architectural style where a single frontend application is split into smaller, independently deployable micro-applications. This allows teams to work on different parts of a project separately while ensuring modularity and scalability.

Why Use Micro Frontend?

Independent deployment of frontend apps
Improved scalability & maintainability
Better team collaboration
Technology agnostic (each micro-app can use different tech stacks)

Source Code

The full source code is available on my Github Repo. Feel free to explore and customize it!

Project Structure

 react-microfrontend-project
 ├──  host-app (Main container app)
 ├──  micro-app-1 (First micro-frontend)
 ├──  micro-app-2 (Second micro-frontend)
 ├──  README.md

How to Run This Project

Follow these steps to get the project up and running:

1. Clone the Repository

 git clone https://github.com/your-username/react-microfrontend.git
 cd react-microfrontend-project

2. Install Dependencies

For each app (host-app, micro-app-1, micro-app-2), run:

 cd host-app  # or micro-app-1, micro-app-2
 npm install

3. Start the Applications

Run the following commands in separate terminals:

 cd host-app && npm start
 cd micro-app-1 && npm start
 cd micro-app-2 && npm start

Each application will start on a different port (e.g., localhost:3000, localhost:3001, localhost:3002) and for more refer Readme.md file.

Data Sharing Between Apps

The host-app acts as the main container and loads both micro-apps dynamically.
Micro-apps can communicate with each other using props, events, or a global state management system (like Redux or Zustand).
Example: Micro-app-1 sends data to Micro-app-2 via the host-app.

Understanding The Difference Between Caret(^) and Tilde(~) In Your React or Node Project

Sohil Lalakiya — Tue, 04 Mar 2025 03:35:29 +0000

🎯 Understanding ^ (Caret) and ~ (Tilde) in package.json

While working with a Node.js or React project, you may have seen ^ (caret) and ~ (tilde) symbols in your package.json file under the dependencies section. These symbols define how the version of dependencies is handled when updating packages.

📌 Let’s understand the version structure first.

For example, if you specify:

"express": "~4.17.1"

It means dependency follow this version structure:

🔴 Major version (4): Introduces breaking changes.
🟠 Minor version (17): Adds new features and solves compatibility issues.
🟢 Patch version (1): Includes bug fixes and security updates.

❓ What are the Caret (^) and Tilde (~) symbols ?

🚀 Caret sign (^):

The caret symbol will allow you to update the latest minor version without updating the major version.

For example, if you specify:

"react": "^19.0.2"

Now your version can update to any newer version up to 19.X.X but it will not update to 20.0.0 or higher.

✅ For example valid updates can be: 19.8.7 or 19.9.0 and so on.
❌ Invalid updates can be : 20.0.1 or 21.0.9 and so on.

📌 This is the default behavior of packages when you install packages using npm install package_name.

🎯 Tilde (~):

The tilde symbol will allow you to update the latest patch version without updating the minor version.

For example, if you specify:

"react": "~19.0.2"

Now your version can update to any newer version up to 19.0.X but it will not update to 19.1.0 or higher.

-✅ For example valid updates can be: 19.0.7 or 19.0.3 and so on.
-❌ Invalid updates can be : 19.1.1 or 19.2.9 and so on.

🤔 Which one is good for you ?

✅ Caret (^) : use caret if you want to allow minor updates that introduce new features while maintaining backward compatibility.
🛠️ Tilde (~) : use tilde if you want to allow just patch updates that introduce security and bug fixes.
🔒Locking the exact version: you can also go with "react": "19.0.0" (without use of tilde or caret) and it will lock the version updates so in future you can’t get any updates of your package.

Happy Learning 🚀😊!!!

In React why do we need state variable when we have local variable ?

Sohil Lalakiya — Sun, 02 Mar 2025 07:07:41 +0000

So as a React developer, it is important to understand the significance of state variables in React development. React requires state variables as it does not keep track of local variables, so when you attempt to modify them, React does not re-render the DOM.

In React, state is a JavaScript object that stores data that can be modified over time. When the state of a component changes, React updates the UI to reflect the new state. The setState() method is a built-in method in React that is used to update the state of a component.

React keeps track of changes made to state variables. When a change is detected, React automatically re-renders the DOM tree using a process called reconciliation. The reconciliation process uses a diff algorithm to determine the most efficient way to make changes to the DOM tree, ensuring that updates to the UI are fast and efficient.

The primary advantage of using state variables is that they enable the efficient management of complex and dynamic user interfaces. By using state variables to manage the state of a component, the user interface remains responsive and up-to-date with user input.

Thank You!

Why you should not use INDEX as KEY in React ?

Sohil Lalakiya — Sun, 02 Mar 2025 07:00:10 +0000

In React, the key attribute is used by the framework to uniquely identify DOM elements in a list. If a key is not specified, React may have difficulty in efficiently updating the list when new elements are added or existing ones are removed.

When a new item is added to a list, or an item is removed from the middle, the order of the remaining items may change. If the keys are not properly updated, React may wrongly assume that the DOM element represents the same component as before, even though this is not the case.

This can result in incorrect rendering or unexpected behaviour, and can even lead to performance issues. Therefore, it is important to use unique keys that can accurately identify each item in the list, especially when dealing with dynamic lists that are subject to frequent updates.

Thank You!