Authentication and Authorization Boundaries | Java Backend Developer Master Program

1. Learning Outcomes#

इस chapter के बाद आप:

Authentication और Authorization के बीच का स्पष्ट अंतर समझ पाएँगे।
समझ पाएँगे कि access decision लेने से पहले identity establish करना क्यों आवश्यक है।
Client, Gateway, Service और Data Store के बीच Trust Boundaries पहचान पाएँगे।
Session-Based और Token-Based Authentication को system-design level पर compare कर पाएँगे।
Distributed systems में Access Token की भूमिका समझ पाएँगे।
Roles, Permissions और Role-Based Access Control यानी RBAC का basic design समझ पाएँगे।
समझ पाएँगे कि protected resource का final Authorization check किस service में होना चाहिए।
Client-side authorization checks पर security के लिए भरोसा क्यों नहीं किया जा सकता, यह समझ पाएँगे।
Service-to-Service Authentication और user identity propagation का high-level flow समझ पाएँगे।
Users, services और data access पर Least Privilege लागू करने का कारण समझ पाएँगे।
Authentication expiry, reauthentication और expired credentials का व्यवहार समझ पाएँगे।
Authentication tokens और requests में sensitive information रखने के risks पहचान पाएँगे।
Authentication failure और Authorization failure को अलग-अलग पहचान पाएँगे।
Centralized Identity Provider को external security dependency के रूप में समझ पाएँगे।
Security, usability, scalability और operational complexity के बीच trade-offs evaluate कर पाएँगे।

2. सबसे पहले एक सरल स्थिति समझें#

मान लीजिए किसी company के office में आप प्रवेश करना चाहते हैं।

Gate पर security guard आपका ID card देखता है।

वह यह verify कर रहा है कि आप कौन हैं।

यह Authentication जैसा है।

लेकिन office में प्रवेश मिल जाने के बाद भी आप Finance department की confidential room में automatically नहीं जा सकते।

वहाँ दूसरा सवाल आता है:

आपको उस room में जाने की permission है या नहीं?

यह Authorization जैसा है।

Software system में भी यही fundamental separation बहुत महत्वपूर्ण है:

Authentication पहचान स्थापित करता है।

Authorization उस पहचान को क्या करने की अनुमति है, यह तय करता है।

Key Idea

पहले system को भरोसेमंद तरीके से पता होना चाहिए कि request किस identity से आई है। उसके बाद ही meaningful Authorization decision लिया जा सकता है।

3. Authentication#

English Definition

Authentication is the process of verifying that an entity is who it claims to be.

सरल भाषा में, Authentication का अर्थ है:

"आप कौन हैं?" इस claim को verify करना।

यह entity कोई human user हो सकती है।

यह कोई mobile application, backend service, scheduled job या दूसरी machine identity भी हो सकती है।

उदाहरण के लिए user कहता है:

I am user 4821.

System तुरंत इस statement पर भरोसा नहीं करता।

पहले वह किसी trusted authentication mechanism के माध्यम से यह identity establish करता है।

Successful Authentication के बाद system के पास कम-से-कम एक trustworthy identity होती है।

उदाहरण:

User ID
Service identity
Application identity
Authenticated session
Verified token identity

Authentication अपने आप यह नहीं बताता कि identity को कौन-सा action allowed है।

वह अगला काम Authorization का है।

4. Authorization#

English Definition

Authorization is the process of deciding what an authenticated identity is allowed to access or perform.

Authorization का सरल अर्थ है:

"इस identity को क्या करने दिया जाए?"

मान लीजिए Rahul successfully authenticated है।

इससे केवल यह साबित हुआ कि system Rahul की identity स्वीकार करता है।

अब Authorization तय कर सकता है:

क्या Rahul orders देख सकता है?
क्या Rahul दूसरे customer का order देख सकता है?
क्या Rahul refund approve कर सकता है?
क्या Rahul admin configuration बदल सकता है?

इसलिए:

Authenticated होना और Authorized होना अलग बातें हैं।

एक authenticated user किसी particular operation के लिए unauthorized हो सकता है।

नीचे basic decision flow देखें:

Visual Diagram80%

Rendering diagram…

इस flow में सबसे महत्वपूर्ण observation यह है कि Authorization meaningful तभी बनता है जब request की identity trusted हो।

Remember

Authentication और Authorization को एक ही check मानना system-design mistake है। दोनों related हैं, लेकिन उनका purpose अलग है।

5. Identity Establishment Authorization से पहले क्यों आवश्यक है#

English Definition

Identity establishment is the process of creating a trusted association between a request and the user, service, or workload making that request.

मान लीजिए request में केवल यह field भेजी गई:

userId = 1005

अगर backend इस value को बिना verification के trusted identity मान ले, तो attacker इसे बदलकर:

userId = 1006

कर सकता है।

इसलिए request में user का नाम या ID मौजूद होना ही Authentication नहीं है।

System को यह establish करना पड़ता है कि identity trusted mechanism से आई है।

Trusted identity establishment के बाद Authorization logic कह सकता है:

user 1005 may read resource 1005

लेकिन बिना Authentication के कोई भी caller स्वयं को 1005 बता सकता था।

इसलिए practical order सामान्यतः यह होता है:

Visual Diagram80%

Rendering diagram…

Authentication context में system-design level पर कुछ information हो सकती है:

authenticated subject identity
service identity
tenant identity
Authentication strength
relevant roles or permissions
credential expiry
token audience

हर system में सभी fields आवश्यक नहीं होते।

Principle अधिक महत्वपूर्ण है:

Authorization untrusted client-provided identity पर आधारित नहीं होना चाहिए।

6. Trust Boundary#

English Definition

A trust boundary is a point where data, identity, or control crosses from one trust level or security domain into another.

Trust Boundary को सरल तरीके से समझें।

जहाँ भी request एक security zone से दूसरे zone में जाती है, वहाँ blindly trust नहीं करना चाहिए।

Typical distributed system में flow ऐसा हो सकता है:

Visual Diagram80%

Rendering diagram…

यह केवल network flow नहीं है।

हर arrow security perspective से एक important boundary हो सकता है।

Client से Gateway#

Client सामान्यतः user-controlled environment है।

Browser, mobile app या external API caller को trusted backend component नहीं माना जाता।

Client request को manipulate किया जा सकता है।

इसलिए Gateway को authentication credentials और request structure verify करने पड़ सकते हैं।

Gateway से Backend Service#

Gateway trusted infrastructure का हिस्सा हो सकता है।

फिर भी backend service को केवल यह सोचकर blindly trust नहीं करना चाहिए:

"Request internal network से आई है, इसलिए safe होगी।"

Backend service को यह जानना चाहिए:

caller कौन है
request किस authenticated user के behalf पर है
identity information trusted source से आई है या नहीं
इस operation के लिए authorization कहाँ enforce होगा

Service से Service#

एक service दूसरी service को call करती है।

यहाँ एक नया important प्रश्न आता है:

Calling service की identity क्या है?

केवल IP address या internal hostname को strong identity मानना पर्याप्त नहीं है।

Service से Database#

Database भी protected resource है।

Application service को database में केवल उतनी permissions मिलनी चाहिए जितनी उसके काम के लिए आवश्यक हैं।

उदाहरण के लिए read-only reporting service को पूरे production database पर unrestricted write permission नहीं मिलनी चाहिए।

Trust boundaries को इस तरह summarize किया जा सकता है:

Boundary	क्या verify करना महत्वपूर्ण है	मुख्य risk
Client → Gateway	User/app identity, credential validity	Client request manipulation
Gateway → Service	Trusted identity context, caller authenticity	Forged internal identity
Service → Service	Service identity, required user context	Unauthorized lateral access
Service → Data Store	Service account permissions	Excessive data access
Service → External Identity Provider	Provider availability and authenticity	Authentication dependency failure

Key Idea

"Internal" का अर्थ automatically "trusted" नहीं होता। Trust स्पष्ट rules और verified identity से बनता है।

7. Session-Based Authentication#

English Definition

Session-based authentication stores authentication state on the server side and gives the client a session identifier used to locate that state.

Session-based design में successful login के बाद server authentication state create कर सकता है।

Client को एक session identifier मिलता है।

अगली request में client session identifier भेजता है।

Server उस identifier की सहायता से session state खोजता है।

एक simplified flow देखें:

Visual Diagram80%

Rendering diagram…

यहाँ session identifier स्वयं पूरा user profile नहीं होना चाहिए।

वह server-side authentication state को reference करता है।

Session-Based Design की मुख्य characteristics#

Server-side state:
Authentication state server या shared session store में रखी जाती है।

Revocation सरल हो सकती है:
Session invalidate करने पर subsequent requests reject की जा सकती हैं।

Distributed deployment में shared session strategy चाहिए:
अगर कई application instances हैं, तो session state accessible रखने के लिए centralized/shared session storage की आवश्यकता हो सकती है।

Session store dependency बन सकती है:
हर request पर session lookup architecture और latency को प्रभावित कर सकता है।

Remember

Session-based architecture का अर्थ यह नहीं कि system scale नहीं कर सकता। Shared session stores और distributed architectures इसे scale कर सकते हैं, लेकिन state management एक design concern बनता है।

8. Token-Based Authentication#

English Definition

Token-based authentication uses a credential called a token to represent or reference authenticated identity and authorized access information.

Token-based design में client request के साथ token भेज सकता है।

Token का purpose यह prove करना है कि trusted authority ने किसी identity या access grant को establish किया है।

Token के प्रकार अलग हो सकते हैं।

कुछ tokens self-contained होते हैं।

कुछ केवल server-side authorization state का opaque reference होते हैं।

इसलिए:

Token-based Authentication को केवल JWT के साथ equate नहीं करना चाहिए।

एक common high-level flow यह हो सकता है:

Visual Diagram80%

Rendering diagram…

इस diagram का अर्थ यह नहीं कि हर token validation के लिए हर request पर Identity Provider call करना ही पड़ेगा।

कुछ designs local verification करते हैं।

कुछ designs centralized introspection करते हैं।

यह architecture और token model पर निर्भर करता है।

9. Session और Token को सही तरीके से compare करना#

Session और Token को "पुराना बनाम नया" या "bad बनाम good" की तरह compare नहीं करना चाहिए।

दोनों अलग trade-offs देते हैं।

Design Concern	Session-Based	Token-Based
Authentication state	मुख्य state server-side	Token identity/access information carry या reference कर सकता है
Client credential	Session identifier	Access token
Revocation	Central session invalidation अपेक्षाकृत direct हो सकती है	Token type और validation model पर निर्भर
Horizontal scaling	Shared/session strategy आवश्यक हो सकती है	Local validation कुछ architectures में scaling आसान कर सकती है
Per-request dependency	Session store lookup हो सकता है	Local validation या IdP/introspection dependency हो सकती है
Credential size	Session ID अक्सर छोटा	Tokens बड़े हो सकते हैं
Leakage impact	Stolen session ID dangerous है	Stolen valid token भी dangerous है
Operational complexity	Session lifecycle manage करना पड़ता है	Key, expiry, token validation और propagation manage करना पड़ सकता है

Common Mistake

"Token-based system पूरी तरह stateless होता है" यह हमेशा सही नहीं है। Identity Provider, token lifecycle, revocation information, user state और authorization data फिर भी stateful components पर निर्भर कर सकते हैं।

10. Access Token#

English Definition

An access token is a credential presented to a protected resource to obtain access according to the permissions associated with that token.

Access Token को digital permission pass जैसा समझ सकते हैं।

लेकिन यह pass बहुत carefully handle करना पड़ता है।

Access Token में या उसके पीछे सामान्यतः यह information relevant हो सकती है:

किस identity के लिए token issue हुआ
token किस resource या audience के लिए है
token की validity कितनी है
relevant permissions या scopes
token किस authority ने issue किया

Protected service को केवल यह नहीं देखना चाहिए कि:

"Token मौजूद है।"

वह token की trustworthiness और applicability भी verify करता है।

High-level checks में architecture के अनुसार शामिल हो सकते हैं:

token valid है या नहीं
token expired तो नहीं
trusted issuer से आया है या नहीं
intended audience सही है या नहीं
required permission available है या नहीं

Warning

Token possession को unlimited trust में convert नहीं करना चाहिए। Token को केवल उसके intended purpose, audience और lifetime के भीतर स्वीकार करना चाहिए।

11. Roles और Permissions#

Permission#

English Definition

A permission represents approval to perform a specific action on a resource or resource category.

Permission सामान्यतः action को represent करती है।

उदाहरण:

order.read
order.cancel
refund.create
user.manage

Permission जितनी specific होगी, authorization policy उतनी स्पष्ट हो सकती है।

Role#

English Definition

A role is a named grouping of permissions assigned to users or services according to their responsibilities.

Role permissions का logical collection है।

उदाहरण:

SupportAgent

के पास permissions हो सकती हैं:

ticket.read
ticket.comment

लेकिन उसे:

payroll.modify
database.admin

जैसी permissions नहीं मिलनी चाहिए।

12. Role-Based Access Control#

English Definition

Role-Based Access Control, or RBAC, is an authorization model in which permissions are assigned to roles and identities receive permissions through their assigned roles.

RBAC का mental model:

Visual Diagram80%

Rendering diagram…

मान लीजिए:

Amit → SupportAgent → ticket.read

तो Amit को ticket.read permission role के माध्यम से मिलती है।

RBAC का benefit यह है कि हजारों users को individual permissions manually देने की आवश्यकता कम हो सकती है।

लेकिन role design खराब होने पर problem हो सकती है।

उदाहरण:

हर powerful permission को एक giant ADMIN role में डाल देना।

फिर users को convenience के लिए ADMIN देना।

ऐसी design Least Privilege को कमजोर करती है।

13. Authorization Protected Resource की Owner Service में क्यों होना चाहिए#

यह system design का बहुत important principle है।

मान लीजिए architecture है:

Visual Diagram80%

Rendering diagram…

Gateway check कर सकता है:

user authenticated है या नहीं
obvious role requirement satisfy होती है या नहीं
malformed token reject करना है या नहीं

लेकिन Order Service को पता है:

requested order कौन-सा है
order किस customer का है
order की current state क्या है
operation business rules के अनुसार allowed है या नहीं

मान लीजिए authenticated customer के पास generic order.read permission है।

लेकिन request है:

GET /orders/7821

यह order किसी दूसरे customer का है।

Gateway को resource ownership data पता न हो सकता है।

Order Service को पता है।

इसलिए final resource-specific Authorization decision Order Service में enforce होना चाहिए।

Key Idea

Gateway coarse-grained security checks कर सकता है, लेकिन protected resource की owner service को final resource-aware Authorization enforce करना चाहिए।

यह defense-in-depth भी देता है।

अगर कोई request Gateway के expected path को bypass कर दे, तब भी owning service unauthorized operation reject कर सकती है।

14. Client-Side Authorization Security Boundary नहीं है#

Frontend application user experience improve करने के लिए buttons hide कर सकती है।

उदाहरण:

Ordinary user के लिए Delete User button दिखाई न देना अच्छा UX है।

लेकिन यह backend security नहीं है।

Attacker frontend UI को bypass कर सकता है।

वह direct HTTP request बना सकता है।

Browser developer tools, scripts, API clients या modified applications से request भेजी जा सकती है।

इसलिए:

Client-side checks convenience के लिए हैं।

Server-side checks security के लिए mandatory हैं।

Warning

"Button hidden है, इसलिए operation secure है" एक dangerous assumption है।

Backend protected operation पर Authorization independently enforce करेगा।

15. Service-to-Service Identity#

English Definition

Service-to-service identity is a verifiable identity assigned to a workload or service so another service can authenticate the caller.

Microservices architecture में केवल end user की identity पर्याप्त नहीं होती।

Service B को यह भी जानना पड़ सकता है कि उसे call करने वाली service कौन-सी है।

मान लीजिए:

Order Service → Payment Service

Payment Service को केवल इसलिए request trust नहीं करनी चाहिए क्योंकि request private network से आई।

Order Service की workload identity verify की जा सकती है।

High-level mechanisms में architecture के अनुसार शामिल हो सकते हैं:

workload identity
short-lived service credentials
mutual TLS
service-issued tokens

यह chapter इन mechanisms की implementation detail में नहीं जाता।

यहाँ important principle है:

Machine callers को भी identity चाहिए।

16. User Identity और Service Identity दोनों महत्वपूर्ण हो सकते हैं#

मान लीजिए customer order cancel करता है।

Flow है:

Visual Diagram80%

Rendering diagram…

यहाँ दो अलग identities हैं।

User identity: operation किस user ने शुरू किया।

Service identity: Payment Service को call कौन कर रहा है।

इन दोनों को mix नहीं करना चाहिए।

Payment Service को यह पता होना चाहिए कि request trusted Order Service से आई है।

अगर downstream authorization के लिए user context आवश्यक है, तो केवल आवश्यक verified user context propagate किया जाना चाहिए।

17. User Identity Safely Propagate करना#

English Definition

Identity propagation is the controlled transfer of trusted identity context across service boundaries.

Distributed system में एक service को downstream service तक user context भेजना पड़ सकता है।

लेकिन unsafe तरीका होगा:

Client द्वारा भेजा गया arbitrary userId उठाकर सभी services में trusted header की तरह forward करना।

Safe design में identity context trusted authentication step से आता है।

फिर services तय करती हैं:

कौन-सी identity information downstream service को चाहिए
information किस trusted channel से आएगी
receiving service caller authenticity कैसे verify करेगी
original user credential को forward करना आवश्यक है या नहीं

Key Idea

"User identity propagate करना" और "user का original credential हर service में forward करना" एक ही बात नहीं हैं।

हर downstream service को original end-user token देना हमेशा necessary या desirable नहीं होता।

कई architectures में service-specific credentials या controlled internal identity assertions बेहतर trust boundary देते हैं।

18. Least Privilege#

English Definition

Least privilege is the principle of granting an identity only the minimum access required to perform its intended task.

Least Privilege केवल users के लिए नहीं है।

यह पूरे system पर लागू होता है।

User Level#

Customer को केवल customer actions की permissions।

Support user को केवल support-related access।

Administrator को भी केवल required administrative capabilities।

Service Level#

Order Service को केवल वही downstream APIs access करनी चाहिए जो उसके काम के लिए आवश्यक हैं।

Database Level#

Application database account को unrestricted superuser access नहीं देना चाहिए।

Token Level#

Token को unnecessary permissions, audiences या long lifetime नहीं देना चाहिए।

Operational Level#

Background job को production administration permissions केवल convenience के लिए नहीं मिलनी चाहिए।

Least Privilege का benefit simple है:

अगर कोई account, token या service compromise हो जाए, तो attacker की possible reach कम रहती है।

19. Authentication Expiration#

Authentication हमेशा forever valid नहीं रहनी चाहिए।

Credentials और sessions की lifetime security design का हिस्सा है।

Session Expiration#

Session में policies हो सकती हैं:

idle timeout
absolute expiration
manual logout
administrative invalidation

Access Token Expiration#

Access token सामान्यतः finite lifetime के लिए valid होना चाहिए।

Expired token को protected resource valid credential की तरह accept नहीं करना चाहिए।

Reauthentication#

English Definition

Reauthentication is the process of requiring an identity to authenticate again when previous authentication is no longer sufficient or valid.

Reauthentication useful हो सकती है जब:

authentication expired हो
account security state बदल गई हो
highly sensitive operation perform हो
risk level बढ़ गया हो

उदाहरण के लिए सामान्य page browsing के लिए existing authenticated session acceptable हो सकता है।

लेकिन highly sensitive action से पहले stronger or recent authentication माँगी जा सकती है।

Key Idea

बहुत long-lived credentials usability बढ़ा सकते हैं, लेकिन stolen credential का risk window भी बढ़ा सकते हैं।

20. Sensitive Information Authentication Token में क्यों नहीं डालनी चाहिए#

Token secure-looking string हो सकता है।

इसका अर्थ यह नहीं कि उसके अंदर की सारी information secret है।

विशेष रूप से कई self-contained token formats में payload readable हो सकती है।

Digital signature data की integrity और issuer authenticity verify करने में मदद कर सकती है।

Signature अपने आप encryption नहीं है।

इसलिए token में unnecessarily यह information नहीं रखनी चाहिए:

password
private encryption keys
payment card secrets
database credentials
unnecessary personal information
internal secrets

Access token स्वयं भी sensitive credential है।

इसलिए उसे:

logs में casually record नहीं करना चाहिए
error messages में expose नहीं करना चाहिए
analytics events में copy नहीं करना चाहिए
URL query parameters में unnecessarily रखना नहीं चाहिए

Warning

"Token signed है, इसलिए token के अंदर का data confidential है" यह assumption गलत हो सकता है।

21. Requests में Sensitive Information#

Authentication-related request design करते समय भी sensitive information minimize करनी चाहिए।

विशेष रूप से avoid करें:

passwords in URLs
tokens in URLs when safer transport locations are available
secrets in diagnostic messages
full credentials in application logs
unnecessary identity attributes in every downstream request

System को केवल वही security context propagate करना चाहिए जिसकी वास्तव में आवश्यकता है।

यह security और privacy दोनों improve करता है।

22. Authentication Failure और Authorization Failure#

दो failures देखने में similar लग सकते हैं, लेकिन उनका meaning अलग है।

Authentication Failure#

Caller की valid identity establish नहीं हुई।

Common causes:

credential missing
token invalid
token expired
session invalid
credential verification failed

HTTP APIs में यह स्थिति सामान्यतः 401 Unauthorized response से associated होती है, हालांकि नाम historical कारणों से थोड़ा confusing है।

Conceptually इसका अर्थ है:

Valid Authentication required है।

Authorization Failure#

Caller authenticated है।

लेकिन requested action allowed नहीं है।

उदाहरण:

Authenticated customer admin-only operation call करता है।

HTTP APIs में यह स्थिति सामान्यतः 403 Forbidden से associated होती है।

Conceptually इसका अर्थ है:

Identity known है, लेकिन access allowed नहीं है।

Comparison:

Situation	Authentication	Authorization	Typical Result
Token missing	Failed	Evaluate नहीं किया जा सकता	Authentication failure
Token expired	Failed	Trusted identity unavailable	Authentication failure
Valid customer reads own order	Passed	Passed	Allow
Valid customer reads another user's protected order	Passed	Failed	Authorization failure
Valid support agent attempts admin configuration	Passed	Failed	Authorization failure

कुछ security-sensitive systems resource existence hide करने के लिए externally different response strategy चुन सकते हैं।

लेकिन design thinking में Authentication failure और Authorization failure को अलग concepts के रूप में समझना आवश्यक है।

23. Centralized Identity Provider#

English Definition

A centralized identity provider is a trusted security system responsible for establishing identities and issuing or validating authentication credentials for applications and services.

Large distributed system में प्रत्येक service अपना independent login system बनाए, तो security difficult हो सकती है।

इसलिए organizations centralized Identity Provider यानी IdP use कर सकती हैं।

High-level architecture:

Visual Diagram80%

Rendering diagram…

Centralized IdP के फायदे हो सकते हैं:

consistent authentication policy
centralized account management
shared login experience
credential lifecycle management
common security controls

लेकिन इसके साथ important architectural implication आता है:

Identity Provider critical external security dependency बन सकता है।

अगर Identity Provider unavailable हो जाए, तो:

new logins fail हो सकते हैं
credential validation प्रभावित हो सकती है
reauthentication fail हो सकती है
कुछ existing authenticated traffic architecture के अनुसार continue कर सकता है

इसलिए IdP integration में reliability design भी आवश्यक है।

24. Identity Provider Failure को कैसे सोचें#

Simple system design में कुछ questions हमेशा consider करें:

क्या हर API request को IdP के साथ synchronous network call करना पड़ता है?
क्या token locally validate हो सकता है?
validation keys या metadata safely cache किए जा सकते हैं?
IdP unavailable होने पर existing sessions का क्या होगा?
new authentication failure कैसे handle होगा?
stale authorization data कितनी देर acceptable है?

एक universal answer नहीं है।

Correct choice security requirements और token/session model पर depend करती है।

Key Idea

Centralization consistency देती है, लेकिन dependency concentration भी पैदा करती है।

25. Gateway कहाँ useful है#

API Gateway authentication architecture में useful control point हो सकता है।

Gateway:

malformed credentials reject कर सकता है
common Authentication validation कर सकता है
rate limits apply कर सकता है
verified identity context establish कर सकता है
obvious coarse-grained policies लागू कर सकता है

लेकिन Gateway को पूरे Authorization model का single source of truth बनाना risky हो सकता है।

Resource-specific business rules owning service में होते हैं।

उदाहरण:

Gateway जान सकता है कि user के पास order.read permission है।

Order Service जानता है कि requested order वास्तव में उसी user का है या नहीं।

इसलिए layered approach अक्सर अधिक robust होती है।

26. End-to-End Example#

अब पूरी architecture को एक साथ समझते हैं।

मान लीजिए e-commerce system है।

Customer अपने order का refund request भेजता है।

Architecture में:

Client
Identity Provider
API Gateway
Order Service
Payment Service
Databases

हैं।

Flow:

Visual Diagram80%

Rendering diagram…

अब प्रत्येक step का meaning देखें।

Step 1 — User Authentication#

Identity Provider customer की identity establish करता है।

Step 2 — Credential Issued#

Client को usable authentication credential मिलता है।

Step 3 — Gateway Authentication Validation#

Gateway invalid या expired credential reject कर सकता है।

Step 4 — Trusted Identity Context#

Gateway trusted user context Order Service तक पहुँचाता है।

यह client के arbitrary user ID से अलग है।

Step 5 — Resource Data Load#

Order Service order ownership और state load करता है।

Step 6 — Final Authorization#

Order Service decide करता है:

user को order access allowed है या नहीं
order उसी customer का है या नहीं
refund operation current state में allowed है या नहीं

Step 7 — Service-to-Service Authentication#

Order Service Payment Service को call करता है।

Payment Service caller service की identity establish करता है।

Step 8 — Least Privilege#

Payment Service को केवल refund-related permission देने वाली service identity उपयोग की जा सकती है।

Step 9 — Result#

Operation केवल सभी relevant trust checks pass होने के बाद complete होता है।

यह architecture Authentication और Authorization को अलग रखता है, लेकिन दोनों को एक coordinated security flow में जोड़ता है।

27. Security, Usability, Scalability और Complexity Trade-Offs#

Security design में कोई भी decision free नहीं होता।

Short Credential Lifetime#

Security benefit:
Stolen credential का useful lifetime कम।

Usability cost:
User को अधिक बार reauthentication की आवश्यकता पड़ सकती है।

Operational cost:
Credential renewal और expiry handling अधिक complex हो सकती है।

Long Credential Lifetime#

Usability benefit:
Frequent login कम।

Security cost:
Stolen credential अधिक समय तक useful रह सकता है।

Centralized Session Store#

Benefit:
Central revocation और session control सरल हो सकता है।

Cost:
Shared store latency, availability और scaling concern बन सकता है।

Locally Validated Tokens#

Benefit:
Backend services हर request पर central session lookup avoid कर सकती हैं।

Cost:
Revocation और stale claims handling अधिक difficult हो सकती है।

Fine-Grained Permissions#

Benefit:
Least Privilege बेहतर।

Cost:
Policy model, administration और testing अधिक complex।

Very Coarse Roles#

Benefit:
Simple management।

Cost:
Users और services को unnecessary permissions मिलने का risk।

Centralized Identity Provider#

Benefit:
Consistent Authentication।

Cost:
Critical dependency concentration।

System design interview में mature answer अक्सर "यह हमेशा best है" नहीं होता।

Mature answer होता है:

"इस option का benefit यह है, लेकिन इसके साथ यह trade-off आता है।"

28. Common Design Mistakes#

Authentication को Authorization समझ लेना#

Valid login का अर्थ unlimited access नहीं है।

Gateway check के बाद service में Authorization छोड़ देना#

Gateway resource ownership या complete business context नहीं जान सकता।

Client-side UI को security control मानना#

Hidden button attacker को direct API request भेजने से नहीं रोकता।

Internal network को automatically trusted मानना#

Compromised service या misconfiguration internal traffic को dangerous बना सकती है।

हर downstream service को original user credential forward करना#

यह credential exposure surface बढ़ा सकता है।

केवल required verified identity context propagate करें।

Giant Admin Role बनाना#

Convenience के लिए broad permissions देना Least Privilege को कमजोर करता है।

Token में secrets डालना#

Signed token encrypted होना जरूरी नहीं है।

बहुत long-lived credentials#

Credential theft की स्थिति में attack window बढ़ जाती है।

Authorization केवल Role check तक सीमित रखना#

कई operations में resource ownership, tenant, state या business rule भी महत्वपूर्ण होता है।

Identity Provider dependency ignore करना#

Authentication system की outage पूरी application availability को प्रभावित कर सकती है।

29. Interview Perspective#

Interview में इस topic पर strong explanation में सामान्यतः ये ideas स्पष्ट होने चाहिए:

Authentication identity verify करता है।
Authorization allowed actions decide करता है।
Identity establishment Authorization से पहले होना चाहिए।
Client एक untrusted boundary है।
Gateway useful security layer है, लेकिन final resource Authorization owning service में होना चाहिए।
Session-based और token-based approaches दोनों valid हैं और trade-offs रखते हैं।
Token-based system automatically stateless नहीं होता।
Access tokens credentials हैं और carefully protected होने चाहिए।
Client-side Authorization केवल UX control है।
Services को भी verifiable identity चाहिए।
User identity और service identity अलग concepts हैं।
Least Privilege users, services, tokens और databases सभी पर लागू होता है।
Expiry security control है।
Authentication failure और Authorization failure अलग होते हैं।
Centralized IdP consistency देता है लेकिन dependency भी बनता है।
Good security architecture हमेशा usability, scalability और operational complexity को भी consider करती है।

Interview Point

केवल "JWT use करेंगे" कहना Authentication architecture का complete answer नहीं है। Interviewer अक्सर identity establishment, trust boundaries, validation, Authorization ownership, expiry, service identity और trade-offs समझना चाहता है।

30. Recap#

इस chapter से सबसे महत्वपूर्ण बातें:

Authentication बताता है कि caller कौन है।
Authorization तय करता है कि caller क्या कर सकता है।
Trusted identity establish हुए बिना Authorization पर भरोसा नहीं किया जा सकता।
हर important service boundary पर trust दोबारा evaluate करना पड़ सकता है।
Session और Token दोनों authentication architectures valid हो सकते हैं।
Access Token unlimited permission नहीं है।
Roles permissions को group कर सकते हैं।
RBAC Authorization organize करने का एक common तरीका है।
Final resource-aware Authorization protected resource की owner service में होना चाहिए।
Frontend security enforcement का final स्थान नहीं है।
Service-to-Service calls में machine identity भी आवश्यक है।
User identity और service identity अलग-अलग security contexts हैं।
Least Privilege compromise का impact कम करता है।
Expired Authentication को valid access में silently convert नहीं करना चाहिए।
Authentication credentials और tokens को sensitive data की तरह protect करना चाहिए।
Authentication failure और Authorization failure अलग हैं।
Centralized Identity Provider powerful है, लेकिन critical dependency भी हो सकता है।
Security design में convenience, scale और operational complexity के trade-offs हमेशा मौजूद रहते हैं।

Summary

Secure distributed system केवल login screen से secure नहीं बनता। सही security design identity establish करता है, हर trust boundary को समझता है, resource के पास Authorization enforce करता है, users और services दोनों को minimum required privilege देता है, और authentication infrastructure की failure conditions को भी design का हिस्सा मानता है।

Printing is unavailable

1. Learning Outcomes#

2. सबसे पहले एक सरल स्थिति समझें#

3. Authentication#

4. Authorization#

5. Identity Establishment Authorization से पहले क्यों आवश्यक है#

6. Trust Boundary#

Client से Gateway#

Gateway से Backend Service#

Service से Service#

Service से Database#

7. Session-Based Authentication#

Session-Based Design की मुख्य characteristics#

8. Token-Based Authentication#

9. Session और Token को सही तरीके से compare करना#

10. Access Token#

11. Roles और Permissions#

Permission#

Role#

12. Role-Based Access Control#

13. Authorization Protected Resource की Owner Service में क्यों होना चाहिए#

14. Client-Side Authorization Security Boundary नहीं है#

15. Service-to-Service Identity#

16. User Identity और Service Identity दोनों महत्वपूर्ण हो सकते हैं#

17. User Identity Safely Propagate करना#

18. Least Privilege#

User Level#

Service Level#

Database Level#

Token Level#

Operational Level#

19. Authentication Expiration#

Session Expiration#

Access Token Expiration#

Reauthentication#

20. Sensitive Information Authentication Token में क्यों नहीं डालनी चाहिए#

21. Requests में Sensitive Information#

22. Authentication Failure और Authorization Failure#

Authentication Failure#

Authorization Failure#

23. Centralized Identity Provider#

24. Identity Provider Failure को कैसे सोचें#

25. Gateway कहाँ useful है#

26. End-to-End Example#

Step 1 — User Authentication#

Step 2 — Credential Issued#

Step 3 — Gateway Authentication Validation#

Step 4 — Trusted Identity Context#

Step 5 — Resource Data Load#

Step 6 — Final Authorization#

Step 7 — Service-to-Service Authentication#

Step 8 — Least Privilege#

Step 9 — Result#

27. Security, Usability, Scalability और Complexity Trade-Offs#

Short Credential Lifetime#

Long Credential Lifetime#

Centralized Session Store#

Locally Validated Tokens#

Fine-Grained Permissions#

Very Coarse Roles#

Centralized Identity Provider#

28. Common Design Mistakes#

Authentication को Authorization समझ लेना#

Gateway check के बाद service में Authorization छोड़ देना#

Client-side UI को security control मानना#

Internal network को automatically trusted मानना#

हर downstream service को original user credential forward करना#

Giant Admin Role बनाना#

Token में secrets डालना#

बहुत long-lived credentials#

Authorization केवल Role check तक सीमित रखना#

Identity Provider dependency ignore करना#

29. Interview Perspective#

30. Recap#