Loading...
System Design and AI Engineering, by Roni Das. 980 interactive lessons.
Start LearningIntermediate · Security Architecture
You log in once, at one trusted login service, and then open many separate apps without typing a password again. Each app trusts a signed message from the login service instead of keeping its own passwords.
In short
Single sign-on (SSO) means you log in once, at one trusted login service, and then open many separate apps without typing a password again. The login service is called the identity provider (IdP). Each app trusts a short, signed message from the IdP that says who you are. Signed means stamped in a way only the IdP can make, so nobody can fake it. No app ever sees or stores your password.
In short
Single sign-on (SSO) means you log in once, at one trusted login service, and then open many separate apps without typing a password again. The login service is called the identity provider (IdP). Each app trusts a short, signed message from the IdP that says who you are. Signed means stamped in a way only the IdP can make, so nobody can fake it. No app ever sees or stores your password.
Learn it in the course
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Single Sign-On across a run of lessons, not one page. These 4 alone are about 64 minutes of step-by-step reading, every one with a quiz.
How single sign-on works between the user, the identity provider and the app. Compares SAML, OIDC and CAS, with a SAML login flow diagram.
How identity federation lets people log in across organizations with one account. Compares SAML and OpenID Connect, and hub-and-spoke vs mesh.
Security Assertion Markup Language, the XML-based protocol that powers enterprise single sign-on and identity federation.
How OAuth 2.0 lets an app use your data without your password. Covers the four roles, grant types, the authorization code flow, PKCE and common risks.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with Single Sign-On (SSO)pay once,
yours for life
Think of a big office building. You show your ID card once at the front desk. After that, the guard at each floor does not ask for your card again. They trust the badge the front desk gave you. Single sign-on works the same way for software.
Without SSO, every app has its own login page and its own list of passwords. A person who uses Slack, GitHub, Salesforce and a staff website run by the HR (people) team has four passwords to remember. The company has four places to remove that person when they leave.
With SSO, there is one login service. It is called the identity provider, or IdP. Okta, Microsoft Entra ID and Google Workspace are common IdPs. Each app that trusts it is called a service provider, or SP. You prove who you are to the IdP once. The apps then ask the IdP, not you.
The 'single' in the name is about the person: one login, many apps. It does not mean one password stored in many apps. The apps hold no password at all.
Here is what happens the first time you open an app in the morning, and then a second app later. A browser redirect means the app sends your browser to another web address, so you never type that address yourself.
So the trick that makes SSO work is the IdP's own session cookie. The apps each keep their own short session. The IdP keeps the long one.
A protocol is an agreed format for the messages in steps 1 to 5. Two protocols cover most SSO today.
Whichever protocol you use, the app must check the signed message properly. For OIDC, the specification lists the checks. The issuer (iss, who made the token) must exactly match the IdP the app expects. The app's own client ID, its name at the IdP, must be in the audience (aud, who the token is for). The signature must be valid. The token must not be past its expiry time (exp). And if the app sent a nonce, a random one-time value, in its request, the same nonce must come back. Skipping the audience check is a classic bug. It lets a token made for one app be used to log in to another.
OAuth 2.0 on its own is not SSO. OAuth gives an app permission to call an API on your behalf, for example to read your calendar. OIDC adds the missing piece: a signed statement of who you are. See OAuth and JWT.
The good side is clear. People have one strong password and MFA instead of many weak ones. Help-desk calls about forgotten passwords drop. Most important, when someone leaves, IT turns off one account at the IdP and every app locks them out at once.
That last part often goes together with SCIM (System for Cross-domain Identity Management), an internet standard numbered RFC 7644. SCIM is a standard API (a way for one program to ask another to do something) that the IdP uses to create, update and delete user accounts inside each app. The HR system tells the IdP that a person joined or left. The IdP tells every app. So access is added and removed in one place.
The cost is that the IdP becomes very important. Three things follow from that.
Interviewers ask about SSO in two ways. Sometimes it is the whole question: "design login for a company with 200 internal apps". More often it is a follow-up inside a bigger design: "how do enterprise customers log in to your SaaS product?" SaaS means software people use over the internet and pay for as a service.
A strong answer names the parts (IdP, SP, the signed message), picks a protocol for a reason (OIDC for a new web app, SAML because the customer's IdP requires it), says what the app checks on every token, and covers the hard parts: creating and removing accounts with SCIM, the IdP as a single point of failure (one part whose failure stops everything), and logout. Saying "we just use OAuth" is the common weak answer, because OAuth alone does not say who the user is.
If two companies are involved, for example your customers log in with their own company's IdP, the word for that is identity federation. SSO is what the person feels. Federation is the trust between the two systems that makes it possible.
The SSO lesson in the System Design course goes further, with the full SAML login flow, the session lifecycle, and how much one stolen login can reach.
Okta
A widely used identity provider for workforce SSO. Speaks SAML and OIDC, and pushes accounts into apps with SCIM.
Google Workspace acts as an IdP for company apps, and Sign in with Google uses OpenID Connect.
Microsoft Entra ID
Microsoft's identity provider (formerly Azure Active Directory), used for SSO into Microsoft 365 and thousands of other apps.
Salesforce
A typical service provider: it accepts SAML assertions from a company IdP so staff never get a separate Salesforce password.
Slack
Supports SAML SSO on its business plans, so a workspace can force every member to log in through the company IdP.
Single sign-on means you log in once, at one login service, and then open many apps without typing a password again. The login service is called the identity provider. Each app trusts a signed message from it that says who you are, so the apps never see your password.
When you open an app, it sends your browser to the identity provider. You log in there once, usually with a password and MFA. The identity provider sends your browser back with a signed message, and the app checks the signature and lets you in. When you open a second app, the identity provider finds its own cookie, so it sends a new signed message without asking you again.
SSO is about logging in once to many apps. OAuth 2.0 is about giving an app permission to call an API for you, such as reading your calendar. OAuth alone does not tell an app who you are. OpenID Connect adds a signed ID token on top of OAuth, and that is what makes OAuth-based SSO work.
Use OpenID Connect for new web and mobile apps: it uses JSON tokens and is simpler to build with. Support SAML when your enterprise customers' identity providers require it, which is still common for business software. Many products support both.
It is usually more secure than many separate passwords, because people use one strong password with MFA, and access can be removed everywhere at once. The risk is concentration: one stolen login opens every app, and an outage of the identity provider blocks new logins. Strong MFA, short sessions and a watched emergency account address these.
Checked against these on .
Identity Federation
Two separate organisations or systems agree to trust each other's logins, so a person or a program proven at one is accepted at the other without a second account or a stored password.
OAuth
An authorization framework that lets users grant third-party apps limited access to their accounts without sharing passwords. Powers 'Sign in with Google.'
JWT
JSON Web Token: a compact, self-contained token for transmitting claims between parties. The server can verify it without a database lookup.
Session
A way to maintain state across multiple HTTP requests. The server stores data about a user and gives them a session ID (usually in a cookie).
Zero Trust
A security model that never trusts any request by default, even from inside the network. Every request must be authenticated, authorized, and encrypted regardless of origin.
Throttling
Slowing down the rate of processing requests instead of rejecting them outright. The gentler cousin of rate limiting.
This page explains the idea. The "Single Sign-On (SSO)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Single Sign-On (SSO) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about Single Sign-On (SSO) in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
