We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Security Architecture
Free preview: the first 2 parts of this 5-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Security Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
A consulting firm works with 15 client companies. Each client has their own internal tools: project trackers, document portals, billing systems. Without federation, the consulting firm's 200 employees would need separate accounts in each client's system. That is 3,000 accounts to manage. When a consultant leaves the firm, someone needs to disable 15 accounts across 15 different systems. Miss one, and a former employee retains access to client data.
Identity federation eliminates this by establishing trust between identity providers. The consulting firm maintains one identity provider. Each client's system trusts that provider. When a consultant accesses a client portal, the client system redirects to the firm's IdP. The consultant authenticates there, and the IdP sends back an assertion: "This is Alice, she's a Senior Consultant, and we vouch for her." The client system trusts the assertion and grants access without creating a local account.
One identity, many systems, across organizational boundaries. When Alice leaves the firm, disabling her account in one place revokes access everywhere.
Three protocols dominate identity federation. The choice depends on your ecosystem and the era in which your partners built their systems.
SAML 2.0 (2005) uses XML-based assertions transported via browser redirects and form POSTs. It remains dominant in enterprise B2B scenarios because Okta, Azure AD, PingFederate, and ADFS all speak SAML fluently. Every enterprise SaaS product (Salesforce, Workday, ServiceNow) supports it. The downside: XML parsing is verbose and has a history of security bugs (XML signature wrapping attacks).
OpenID Connect (2014) layers identity on top of OAuth 2.0 using JSON/. It is the modern choice for new applications. Compact tokens, native mobile support, simpler implementation. Google, Microsoft, Apple, and GitHub all provide OIDC. For new consumer-facing or modern enterprise apps, OIDC is the right default.
WS-Federation is Microsoft's older standard. It predates SAML 2.0 and is still used in legacy Active Directory Federation Services (ADFS) deployments. If your partners run ADFS from 2010, you may need to support WS-Fed. For anything else, treat it as legacy.