Authentication and Authorization in Microservices
Last updated: October 15, 2025 Read in fullscreen view
Recommended for you
- 21 Nov 2025
Top 8 Cloud Transformation Companies in USA in 2026 30/48 - 09 Oct 2022 Rapid Application Development Case Study - TIGO Consulting 23/570
- 05 Jul 2020 What is Sustaining Software Engineering? 14/1188
- 20 Mar 2022 What is a Multi-Model Database? Pros and Cons? 11/1063
- 12 Oct 2022 14 Common Reasons Software Projects Fail (And How To Avoid Them) 10/504
- 01 Mar 2023 What is Unit Testing? Pros and cons of Unit Testing? 8/355
- 30 Jan 2022 What Does a Sustaining Engineer Do? 7/554
- 13 Oct 2021 Outsourcing Software Development: MVP, Proof of Concept (POC) and Prototyping. Which is better? 6/424
- 28 Jul 2022 POC, Prototypes, Pilots and MVP: What Are the Differences? 6/606
- 31 Aug 2022 What are the best practices for software contract negotiations? 5/215
- 05 Mar 2021 How do you minimize risks when you outsource software development? 5/317
- 07 Oct 2025 Case Study: Using the “Messaging House” Framework to Build a Digital Transformation Roadmap 5/45
- 31 Dec 2021 What is a Data Pipeline? 4/187
- 12 Dec 2021 Zero Sum Games Agile vs. Waterfall Project Management Methods 4/374
- 04 Oct 2022 Which ERP implementation strategy is right for your business? 4/278
- 08 Jan 2024 Ask Experts: Explicitation/Implicitation and Elicitation; two commonly used but barely unraveled concepts 4/275
- 01 Dec 2023 Laws of Project Management 3/249
- 05 Sep 2023 The Cold Start Problem: How to Start and Scale Network Effects 3/167
- 22 Sep 2022 Why is it important to have a “single point of contact (SPoC)” on an IT project? 3/843
- 18 Jul 2021 How To Ramp Up An Offshore Software Development Team Quickly 3/516
- 04 Oct 2021 Product Validation: The Key to Developing the Best Product Possible 2/295
- 28 Oct 2022 Build Operate Transfer (B.O.T) Model in Software Outsourcing 2/361
- 01 May 2024 Warren Buffett’s Golden Rule for Digital Transformation: Avoiding Tech Overload 2/188
- 17 Mar 2025 Integrating Salesforce with Yardi: A Guide to Achieving Success in Real Estate Business 2/141
- 08 Feb 2024 Case Study: How and why I built Japan Dev? 2/196
- 12 Aug 2024 Understanding Google Analytics in Mumbai: A Beginner's Guide 1/84
- 12 Aug 2024 Creately: A Versatile Tool for Visual Thinkers 1/112
- 25 Apr 2021 What is outstaffing? 1/229
- 13 Nov 2021 What Is Bleeding Edge Technology? Are bleeding edge technologies cheaper? 1/454
- 19 Oct 2021 Software development life cycles /628
- 03 Jul 2022 What is the difference between Project Proposal and Software Requirements Specification (SRS) in software engineering? /955
- 09 Jun 2022 Case Study: PRODUCT LAUNCH WITH AGILE METHODOLOGY /286
- 10 Apr 2022 What is predictive analytics? Why it matters? /167
- 06 Mar 2024 [SemRush] What Are LSI Keywords & Why They Don‘t Matter /131
- 31 Jul 2025 Top WooCommerce Pre-Order Plugins with Countdown & Discounts /70
- 15 Aug 2025 Quantum Technology: Global Challenges and Opportunities for Innovators /56
- 01 Mar 2024 (AI) Artificial Intelligence Terms Every Beginner Should Know /280
Authored by Hoa Nguyen
Authentication (answering the question “Who are you?”) and authorization (answering the question “What are you allowed to do?”) are essential components of any system. However, the way you apply them depends heavily on the growth stage of your company. If you implement everything too strictly at the beginning, it can slow down development. But if you delay too long, you risk security vulnerabilities and potential attacks.
For e-commerce companies such as Shopee, Alibaba, etc., these risks are tangible — especially in systems that involve payments, virtual currency, coupons, gift cards, and other sensitive services.
Starting from a Monolith
Most e-commerce companies began with a monolithic architecture, where authentication and authorization were typically managed by a centralized module. After logging in, each user was assigned a unique session ID for identification. The client stored this session ID as a cookie and included it in every request.
When the Session ID was received, the server identified the user and checked their access permissions, allowing them to stay logged in without re-entering credentials.
While sessions and cookies still work today, modern applications — especially Hybrid Apps or Single Page Applications (SPAs) — often need to communicate with multiple back-end systems. As a result, a session and cookie from one server might not be usable on another.
The Microservices Challenge
In a microservices architecture, the system is divided into smaller services, each handling specific business functions. Each of these services still requires authentication and authorization. If handled the same way as in a monolithic architecture, several problems arise:
- Each service needs to perform its own authentication and authorization. Even if the same library is reused, maintaining it across multiple languages and platforms is expensive.
- Services should focus on their own business logic — adding security logic slows development and increases complexity.
- Services communicate primarily via RESTful APIs over HTTP. Traditional server-side sessions (stateful) make horizontal scaling difficult.
- Services can be accessed by multiple clients: users, devices, third-party apps, cron jobs, or even other services. Managing identity and access across these varied contexts is complex.
Below are several approaches and techniques that e-commerce companies began as a adopted to solve these challenges.
Identity Management
Using JWT
JWT (JSON Web Token) is an open standard token format used to exchange information in HTTP requests. JWTs are cryptographically signed, providing trust and authenticity. Compared to sessions, JWTs offer several benefits:
- Stateless — no need to store data on the server.
- Easier to scale and extend.
- Better performance — the server reads the information directly from the request instead of querying storage or a database.
When the Session ID was received, the server identified the user and checked their access permissions, allowing them to stay logged in without re-entering credentials.
While sessions and cookies still work today, modern applications — especially Hybrid Apps or Single Page Applications (SPAs) — often need to communicate with multiple back-end systems. As a result, a session and cookie from one server might not be usable on another.
RSA Encryption for JWT
JWT signatures can be generated using HMAC or RSA encryption:
- HMAC: Both the issuer and the verifier share the same secret key for signing and verification.
- RSA: Uses a key pair — the issuer signs with a private key, and the verifier checks with a public key.
With HMAC, both sides share the secret key, so the verifier could theoretically issue new tokens. RSA prevents this since only the issuer holds the private key. Therefore, RSA offers stronger security when tokens are shared across multiple systems.
Opaque Tokens for Better Session Control
An Opaque Token (stateful token) contains no user data — it’s just a random string that requires a validation service to look up the details.
{"access_token": "c2hr8Jgp5jBn-TY7E14HRuO37hEK1o_IOfDzbnZEO-o.zwh2f8SPiLKbcMbrD_DSgOTd3FIfQ8ch2bYSFi8NwbY","expires_in": 3599,"token_type": "bearer"}
In contrast, a Transparent Token (stateless token), like JWT, contains encoded user information and can be verified without calling a central service.
| Criterion | Opaque Token | Transparent Token (e.g., JWT) |
|---|---|---|
| Speed | Poor, because the token must be validated through the authentication server. | Fast, only a secret key is needed (for signature verification). |
| Data Exposure | Does not expose sensitive information within the token content. | Information within the token content can be viewed (only Base64 encoded). |
| Validity Check | Every token must be checked by the authentication server. | The token is valid until it expires (can be verified locally). |
- Transparent tokens are faster and simpler, not dependent on a central server.
- Opaque tokens offer better control over sessions, e.g., forcing logout from all devices.
OAuth 2.0
Tokens are issued through OAuth 2.0, the most widely used authentication protocol today. It allows a third-party service or application to act on behalf of a user and access their resources securely.
OAuth 2.0 is an open standard with comprehensive documentation and multi-language libraries, making it easy to implement and integrate.
Authentication and Authorization Architecture
Once identity and communication protocols are defined, the next question is:
At most e-commerce companies, both new and legacy systems coexist. Therefore, there are two main approaches to implementing access control.
Authentication and Authorization via API Gateway or BFF
All requests go through an API Gateway or BFF (Backend for Frontend) — an edge service tailored for each application (iOS, Android, Web Admin, etc.).
Here’s how it works:
- The API Gateway requires every request to include a valid token.
- If the token is a JWT (OpenID Connect), the gateway validates it using its signature, claims, and issuer.
- If the token is opaque, the gateway introspects it, exchanges it for a JWT, and forwards it to internal services.
- The Gateway or BFF checks authorization policies via a central Authorization Server.
- Internal microservices can skip authentication, trusting requests inside the internal network.
This approach simplifies setup but leaves a security gap between internal services, as they can freely communicate. Network-level rules can help but can’t fully enforce fine-grained permissions.
Authentication and Authorization at the Service Level
In this model, each service (except certain exceptions) is designed to expose APIs that can serve both internal and external consumers.
A service built for internal use today might later be opened to partners or third-party developers. This gives each team full autonomy over their resources — defining who can access them and to what extent.
The key enabler here is the IAM (Identity and Access Management) service, which maintains all identities (users, services, commands) and their access control policies.
Although this increases complexity — since each service needs middleware to communicate with IAM — it gives services full control and flexibility, enabling faster development and easier client access without needing an extra BFF layer.
Access Control Models
As business needs evolve, access rules become more complex. Let’s review the main access control models:
Access Control List (ACL)
| Title (Role) | Owner Control | Promote Version | Modify Content | View Content | View Props | Publish |
|---|---|---|---|---|---|---|
| Administrator | x | x | x | x | x | x |
| John | x | x | x | x | ||
| Finance Admins | x | x | x | x | x | x |
| Finance Manager | x | x | x | |||
| Finance Reviewers | x | x |
An ACL defines permissions in a matrix of users and actions (like Linux file permissions). While simple for small systems, it becomes unmanageable at scale — hence it’s rarely used in modern large systems.
Role-Based Access Control (RBAC)
RBAC links users → roles → permissions.
For example, an Administrator role may inherit all permissions from a Manager. This hierarchical structure reduces complexity compared to ACLs.
RBAC is widely used and effective but falls short for contextual permissions, such as allowing only the creator to edit a resource or differentiating users across multiple tenants.
Policy-Based Access Control (PBAC)
PBAC is derived from Attribute-Based Access Control (ABAC).
It defines rules (policies) based on attributes — key-value pairs like Department = Marketing. This allows fine-grained, context-aware permissions suitable for complex business rules.
Policies are expressed in XACML (eXtensible Access Control Markup Language) and usually define four components:
- Subject (who)
- Action (what)
- Resource (which resource)
- Effect (allow or deny)
Example:
{ "subjects": ["user:john"], "effect": "allow", "actions": ["catalog:delete"], "resources": ["product:john-leman"] } You can extend this policy:
{ "subjects": ["user:john", "user:katy"], "effect": "allow", "actions": ["catalog:delete", "catalog:update"], "resources": ["product:john-leman", "product:john-doe"] } Key Advantages of PBAC
-
Priority rules
-
If no policy matches → request is denied.
-
If at least one allow and no deny policy → request is granted.
-
If any deny policy exists → request is denied.
-
-
Regular Expressions
{ "subjects": ["user:<.*>"], "effect": "allow", "actions": ["catalog:read"], "resources": ["product:<.*>"] }→ Grants read access to all users for all products.
-
Conditional Rules
{ "subjects": ["user:ken"], "actions": ["catalog:delete", "catalog:update"], "effect": "allow", "resources": ["products:<.*>"], "conditions": { "IpAddress": {"addresses": ["192.168.0.0/16"]} } }→ Allows access only from specific IP ranges.
Conclusion
As systems and business logic expand, each service must be self-authenticated — regardless of whether it’s internal or external. This enables teams to integrate seamlessly while maintaining autonomy.
A unified, scalable authentication and authorization model must be stable, optimized, and high-performance — ensuring security without slowing innovation.
Explore more on these topics
Guest Blogging: The Definitive Guide
Top Trending Topics
Share This
Link copied!
Recently Updated News