Blockchain Based Authentication and
Authorisation in Microservices
Architecture
Under the guidance of
B. Sri Varuna Saradhi (20011P0503) Dr. K. SHAHU CHATRAPATI
Professor of CSE Department
JNTUH-UCESTH
AGENDA
● Abstract
● Problem Statement
● Literature Survey
● WorkFlow
● Blockchain Approach – Registration & Policy
● Blockchain Approach – Runtime Flow
● Result
● Conclusion
Abstract
Microservice architectures offer modularity and independent scaling.
However, they typically rely on centralized authentication and authorization mechanisms:
● OAuth/OIDC servers.
● Complex mTLS certificate meshes.
These centralized trust anchors are single points of failure:
● If compromised or failed, it can impact all services in the architecture.
This project proposes a solution:
● Decentralized, blockchain-backed security layer.
● Smart contracts replace the central authority.
● Provides tamper-evident and trustless authorization logic.
Enhances resilience, transparency, and eliminates centralized trust dependency.
Problem Statement
Many micro-service systems still use a central server (like OAuth or mTLS) to check who is
allowed to access what. If that server fails or is hacked, all service-to-service communication
is at risk. As more services are added, managing certificates becomes slow and complex.
Another problem is that these services run on cloud servers (like AWS or Google Cloud),
which the cloud provider controls. A powerful insider could see or change data without
anyone knowing.
Problem: Build a system that doesn’t rely on a central server, works even if the cloud is not
trusted, keeps records safely, and proves every request came from a secure, verified
environment.
Literature Survey
OAuth 2.0
OAuth 2 is an authorization frameworkwhich tells how you authorize a user to access a resource from
your resource server with a token. OAuth 2.0 has 4 different roles in this process:
1. Resource Owner: Resource owner is the user, who authorizes an application to access their account.
2. Client: Client is the application, which is used by the user to get resources from the resource server.
3. Authorization Server: Authorization server will issue access tokens by authenticating the user and
obtain authorization grant.
4. Resource Server: The resource server hosts the protected user accounts and provides the resources
when authenticated.
OAuth 2.O
Literature Survey
mTLS (mutual Transport Layer Security)
1. mTLS (mutual TLS) ensures secure, encrypted communication between microservices by
requiring both parties to present and validate TLS certificates, enabling strong mutual
authentication.
2. It eliminates the need for passwords or tokens by using certificates as the sole source of identity,
simplifying authentication and reducing management overhead.
3. Once certificates are exchanged and validated during the handshake, a secure communication
channel is established, protecting data from tampering, eavesdropping, and unauthorized access.
mTLS (mutual Transport Layer Security)
Workflow
Blockchain Approach – Registration & Policy
We deploy the smart-contract on the Ethereum Sepolia test network.
Sepolia is public, easy to monitor with a block explorer, and has very low transaction fees.
How a micro-service joins
1. The service creates a key-pair (public / private key).
2. It calls serviceRegistration(name).
3. The contract saves three items: service name, unique ID, public key.
4. A ServiceRegistered event is broadcast so every other component can learn the new ID.
How access rules are stored
The contract keeps a simple table inside each service record: action → allowed / not allowed.
Example actions: readOrder, writeOrder, updateProfile.
Blockchain Approach – Registration & Policy
Adding or changing a rule
The service owner calls defineAccessPolicy(serviceName, action, allowed).
The contract updates the table and emits an AccessPolicyChanged event.
Only these occasional updates need a blockchain transaction; everyday read-only checks do not.
Fast look-ups during runtime
A lightweight listener (written in [Link]) watches the events and stores the latest IDs and rules in memory.
When one service wants to call another, it can verify the rule instantly without hitting the blockchain each time.
Result
– Every micro-service is recorded on an open ledger, so no one can secretly add or remove identities.
– Access rules are transparent and tamper-evident, yet quick to check during normal operation.
Blockchain Approach – Runtime Flow
● Build & sign the request
The caller collects calleeID, action, dataHash → runs keccak256 → signs the digest with its
private key using [Link].
● Send to callee
Caller posts a message containing { callerID, calleeID, action, dataHash, signature } to the
callee micro-service.
● Smart-contract check
Callee uses the Alchemy API to call verifyAndGrantAccess(...).
• Contract confirms the signature matches the caller’s public key.
• Contract looks up the stored rule for that action.
• Returns true / false and emits an AccessDecision event.
Blockchain Approach – Runtime Flow
● Local cache update
Callee stores the verified result in an in-memory cache so repeated requests from the same
caller/action can be approved in milliseconds without another on-chain query.
● Enforce decision
• If true 👉 callee runs business logic and replies normally.
• If false 👉 callee sends HTTP 403 Forbidden.
● Immutable audit trail
Each AccessDecision event is written to the blockchain, giving a permanent, tamper-evident
record of who requested what and whether it was allowed.
Result
Result
Conclusion
● Achieved: a fully decentralised, tamper-proof authentication + authorisation layer
for micro-services.
● Benefits: removes the single point of failure and cuts certificate-management
effort by roughly 50 %.
● Next moves:
• Shift to Layer-2 or permissioned chains to reduce delay.
• Add zero-knowledge proofs for privacy-friendly policy checks.
• Develop a Kubernetes operator for automatic service registration and policy
updates.
THANK YOU
