# Single sign-on

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/single-sign-on

## Quick definition

Single sign-on (SSO) lets you log in one time and then use many different apps or websites without having to enter your username and password again. It works by having one central system that confirms who you are and then shares that confirmation with other services. This makes logging in faster and reduces the need to remember many different passwords.

## Simple meaning

Think of single sign-on like a master key for a large office building. When you enter the building, you show your ID badge at the front desk just once. After that, you can walk into any office, conference room, or break room without showing your badge again. The front desk has already verified who you are, and everyone inside the building trusts that verification. In the digital world, this is exactly how SSO works. You log in to one main service, often called an identity provider, and that service gives you a kind of digital pass. When you then try to open another application, like your email or a project management tool, that application checks with the identity provider to see if you already have a valid pass. If you do, it lets you in without asking for your password again. This is much easier than having separate usernames and passwords for every single app you use. For example, if your company uses Microsoft 365, you might log in to your computer in the morning with your work email and password. Once you are logged in, you can open Outlook, Teams, SharePoint, and other Microsoft apps without typing your password again for each one. The Microsoft identity system acts as the front desk that trusts you for the rest of the day. The biggest benefit is convenience, but there is also a security advantage. With SSO, you only need to remember one strong password instead of many weak ones. And if your account is ever compromised, the IT team can disable that single account, which immediately blocks access to all connected applications. This is much faster than having to change passwords on every separate system. However, it also means that if your one main account is stolen, the attacker can get into everything. That is why SSO is usually combined with other security measures like multi-factor authentication. Overall, SSO simplifies the login experience and helps organizations manage user access more centrally and securely.

## Technical definition

Single sign-on (SSO) is an authentication process that enables a user to access multiple independent software systems by authenticating once through a central identity provider (IdP). The core principle is that the IdP issues a security token or assertion after successful authentication, which is then presented to each service provider (SP) the user tries to access. The SP validates the token with the IdP and grants access without requiring the user to re-enter credentials. This relies on established standards and protocols to ensure interoperability and security.

The most common protocols used in modern SSO implementations are Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and OAuth 2.0. SAML is an XML-based protocol often used in enterprise environments, particularly for web applications. The IdP signs a SAML assertion containing the user's identity attributes and sends it to the SP. The SP verifies the signature and allows access. OpenID Connect, built on top of OAuth 2.0, is more modern and commonly used in cloud and mobile applications. It uses JSON Web Tokens (JWTs) to transmit identity information, which are easier to handle in modern web development. OAuth 2.0 itself is primarily an authorization framework, not authentication, but it is often used together with OpenID Connect to both authenticate the user and authorize access to resources.

From an architectural perspective, SSO involves several components. The identity provider is the central authentication server that stores user credentials and authenticates users. The service provider is the application or system that relies on the IdP for authentication. The token or assertion acts as proof of authentication. There is also a session management component that tracks the user's authenticated state. In many implementations, the IdP creates a session cookie on the user's browser or device, which is used to recognize the user when they attempt to access other SPs. This session can have a configurable lifetime, after which the user must re-authenticate.

Active Directory Federation Services (AD FS) is a Microsoft implementation that enables SSO for on-premises environments, allowing users to authenticate once against Active Directory and access federated applications. Azure Active Directory (Azure AD), now called Microsoft Entra ID, provides cloud-based SSO for Microsoft and third-party SaaS applications. In a typical flow, a user navigates to a resource like a partner portal. The portal redirects the user to Azure AD for authentication. After successful login, Azure AD redirects back to the portal with a security token. The portal validates the token and grants access. For subsequent applications, the browser already has a session with Azure AD, so the redirect happens silently without password re-entry.

Kerberos is another protocol that enables SSO within Windows domains. When a user logs into a Windows domain-joined computer, the domain controller issues a ticket-granting ticket (TGT). The TGT can then be used to request service tickets for network resources like file servers or printers without further authentication. This is seamless and transparent to the user.

Security considerations are critical. The IdP becomes a high-value target because compromising it compromises all connected systems. Therefore, SSO should always be paired with multi-factor authentication (MFA). Token lifetime must be carefully managed, and proper logout mechanisms must be implemented to ensure all sessions are terminated across SPs. Misconfiguration of trust relationships or SSL certificates can also introduce vulnerabilities. Federated SSO across organizations requires mutual trust and careful exchange of metadata.

## Real-life example

Imagine you work in a large hospital complex. The complex has many separate buildings: the main hospital, a research wing, a pharmacy, a staff cafeteria, and a fitness center. Normally, if you wanted to visit each building, you would need a separate key card for each one. The main hospital requires a blue badge, the research wing needs a red badge, the pharmacy uses a yellow badge, and so on. You could easily lose track of which badge goes where, and losing one badge would mean someone else could access that particular building. Now imagine the hospital introduces a new system. At the front gate, there is a central security check. You show your employee ID and a fingerprint scan once. The security guard then gives you a single universal wristband with a unique barcode. That wristband works at every door in the entire complex. When you walk up to the research wing, you scan your wristband. The door reader checks with the central security system and sees that you are authenticated. The door opens. You do not need a separate badge for the pharmacy, cafeteria, or fitness center. The wristband is your single sign-on token. If you are ever fired or leave the job, the security guard simply deactivates your wristband at the central system. That single action locks you out of every building at once. There is no need to collect five different badges. This is exactly how digital SSO works. The front gate security is the identity provider. The wristband is the security token. The doors to each building are the service providers. And the central security system that checks the wristband is the trust relationship between the IdP and SPs. The convenience is obvious, but the security benefit is also huge. If your wristband is lost or stolen, you report to the front gate, and they immediately invalidate it, preventing anyone from using it to access any building.

## Why it matters

Single sign-on matters because it directly impacts user productivity and organizational security in very practical ways. In any IT environment, users typically need to access several applications every day, such as email, customer relationship management (CRM) software, human resources portals, file storage systems, and collaboration tools. Without SSO, users would have to log into each of these separately. That might mean remembering five, ten, or even more different passwords. Many people respond to this burden by choosing weak passwords that are easy to remember, reusing the same password across many sites, or writing passwords on sticky notes. These behaviors create serious security vulnerabilities. SSO reduces this problem by requiring only one strong password. It also makes multi-factor authentication easier to implement, because you only need to protect one login point rather than dozens.

From the IT administrator viewpoint, SSO centralizes user management. When an employee joins the organization, the administrator creates one account in the identity provider. The user then automatically gains access to all provisioned applications. When an employee leaves, the administrator disables that single account, and access to everything is revoked immediately. This is much faster and less error-prone than manually deactivating accounts across multiple systems. It also simplifies compliance and auditing, because all authentication events are logged in one place rather than being scattered across different application logs.

SSO also supports better governance. Organizations can enforce consistent password policies, session timeouts, and MFA requirements across all applications from a central point. This ensures that every application benefits from the same security posture, even if that application was not originally designed with strong authentication. For example, an older legacy application that only supports basic authentication can be placed behind an SSO gateway that requires modern authentication methods. This extends the life of legacy systems without sacrificing security.

In cloud and hybrid environments, SSO is essential for enabling seamless access to SaaS applications. Many organizations use hundreds of different cloud apps, and managing separate credentials for each is not feasible. SSO federates identity across organizational boundaries, allowing external partners or customers to access resources using their own identity providers. This is the foundation of business-to-business (B2B) and business-to-consumer (B2C) identity scenarios. Overall, SSO is not just a convenience; it is a cornerstone of modern identity and access management that reduces friction for users and provides stronger, centralized security control.

## Why it matters in exams

Single sign-on is a fundamental concept in several Microsoft certification exams, particularly MS-900 (Microsoft 365 Fundamentals), Azure Fundamentals (AZ-900), and SC-900 (Microsoft Security, Compliance, and Identity Fundamentals). In these exams, understanding SSO is critical because it appears in multiple objectives and question types. For MS-900, SSO is part of the 'Describe cloud concepts' and 'Describe Microsoft 365 security and compliance capabilities' domains. You may be asked to explain how SSO works in Microsoft 365, identify the benefits of using Azure AD for SSO, or differentiate between SSO and federated identity. Questions often present a business scenario where a company wants to reduce password fatigue or improve security, and you must choose SSO as the appropriate solution. Azure Fundamentals (AZ-900) covers SSO under the 'Describe identity, governance, privacy, and compliance features' section. You will need to understand that Azure AD provides SSO capabilities for cloud and on-premises applications. Expect scenario-based questions where a company uses multiple SaaS applications, and you must recommend Azure AD SSO as the solution to streamline user access. SC-900 dives deeper into identity and access management. SSO is a core topic in the 'Describe the capabilities of Microsoft Identity' domain. Here, you might be asked about the relationship between SSO and MFA, how conditional access policies interact with SSO, or the role of federation (like AD FS) in enabling SSO. Some questions may require you to know the difference between SSO, federated identity, and password hash synchronization. Question types include multiple choice, case studies, and yes/no statements. You might see a question like, 'A user logs into Microsoft Teams and then accesses SharePoint without being prompted for credentials again. What is this an example of?' The correct answer would be single sign-on. Another common pattern is a scenario where an organization wants to enable SSO for third-party SaaS applications. You could be asked which Azure AD feature to use. The answer is enterprise application integration with SSO. Or you may be asked about protocols, such as which protocol is commonly used for SSO (SAML or OpenID Connect). For security-focused exam sections, you might need to identify that SSO can be risky if the primary account is compromised, so it should be paired with MFA. Understanding SSO also helps answer questions about identity synchronization, since Azure AD Connect is often used to enable SSO for hybrid environments. Overall, mastering SSO will help you answer questions about user authentication, access management, security best practices, and cloud identity architecture in these exams.

## How it appears in exam questions

Questions about single sign-on appear in several distinct patterns across the Microsoft fundamentals exams. The most common pattern is the scenario-based recognition question. The exam will describe a situation, and you must identify that SSO is the relevant concept. For example, a question might say, 'An organization has 50 employees who use Microsoft 365, a third-party expense reporting app, and an internal help desk system. After implementing a solution, users only need to log in once in the morning to access all three applications. Which solution was implemented?' The correct answer is single sign-on. Distractors might include multi-factor authentication, password reset, or conditional access. You need to know that SSO specifically addresses the need to authenticate once and access multiple resources.

Another question pattern involves differentiating SSO from related concepts like federated identity or password hash synchronization. A question might present a scenario where two separate organizations want to allow their users to access each other's applications using their own corporate credentials. This describes federation, not simple SSO. The exam may ask which technology enables this cross-organization trust. Understanding the nuance helps you choose the correct answer. Similarly, you might be asked which feature of Azure AD allows users to sign in using their on-premises Active Directory credentials while accessing cloud apps. The answer is Azure AD Connect with password hash synchronization and seamless SSO.

Troubleshooting-style questions are less common in fundamentals exams but do appear. For example, an organization has enabled SSO but users are still being prompted for credentials every time they switch applications. The question might ask what could be the cause. Options could include incorrect token lifetime configuration, the application not being configured for SSO, or the user's browser blocking cookies. You need to know that SSO relies on session cookies issued by the identity provider. If cookies are cleared or blocked, the SSO session is lost, and users will see repeated login prompts.

Configuration scenario questions might ask how to configure an application for SSO in Azure AD. A question could list steps and ask which one is incorrect. For instance, 'An administrator wants to configure SSO for a SAML-based application. They register the application in Azure AD, upload the SAML metadata, and set the user attribute mapping. Which step is missing?' The missing step could be assigning users or groups to the application. Without assignment, users cannot access the app even if SSO is configured.

Finally, security-related questions may ask you to identify a risk of SSO. For example, 'What is a potential disadvantage of implementing single sign-on?' The correct answer is that if the primary account is compromised, all connected resources are accessible. This tests your understanding that SSO centralizes the authentication risk. Always remember that SSO makes the identity provider a high-value target, so it should be protected with MFA and strict conditional access policies.

## Example scenario

Contoso, Ltd. is a mid-sized company with 200 employees. They currently use separate logins for each application. Employees have a username and password for their email system, a different set of credentials for the company's project management tool, another for the human resources portal, and yet another for the customer database. The IT help desk receives an average of 15 password reset requests per day. Employees often write down passwords on sticky notes or use simple passwords that are easy to guess. The company wants to improve security and user convenience. The IT manager proposes implementing single sign-on using Microsoft Entra ID (formerly Azure AD). First, the company sets up Microsoft Entra ID as the central identity provider. They create user accounts for all 200 employees and configure MFA for extra security. Then, they integrate each of their applications as service providers. For cloud apps like the project management tool, they configure SAML-based SSO. For the on-premises HR portal, they set up an application proxy with SSO. For the older customer database that does not support modern protocols, they place it behind a web application firewall that supports SSO. Once the configuration is complete, employees start their day by logging into Windows with their Microsoft Entra ID credentials. From then on, whenever they open any of the integrated applications, they are automatically authenticated. They never see a login prompt. The help desk reports a 90% reduction in password reset calls. Employees no longer need to remember multiple passwords, and the company enforces strong password policies and MFA through the central identity provider. If a user leaves the company, IT simply disables the single Microsoft Entra ID account. Within minutes, the user loses access to all applications, even the legacy systems. This scenario illustrates how SSO simplifies daily operations, strengthens security, and streamlines user lifecycle management in a practical corporate environment.

## Common mistakes

- **Mistake:** Thinking that SSO is the same as multi-factor authentication (MFA).
  - Why it is wrong: SSO and MFA solve different problems. SSO allows one login to access many apps, while MFA adds an extra layer of security by requiring a second verification factor. They are often used together but are not the same thing.
  - Fix: Understand that SSO is about convenience and central authentication, while MFA is about stronger security. An SSO solution can (and should) use MFA to protect the single login point.
- **Mistake:** Believing that SSO eliminates the need for passwords entirely.
  - Why it is wrong: SSO still requires at least one initial authentication event, which usually involves a password (plus other factors if MFA is used). It reduces the number of times you enter a password, not the need for passwords altogether.
  - Fix: Remember that SSO reduces password fatigue but does not remove the need for a strong, unique password for the identity provider account.
- **Mistake:** Confusing SSO with federated identity.
  - Why it is wrong: Federated identity is a broader concept that involves establishing trust between separate organizations, allowing users from one organization to access resources in another using their home credentials. SSO can operate within a single organization without federation.
  - Fix: Think of SSO as a single authentication event that works across multiple apps within the same trust boundary. Federation is when that trust boundary extends across companies.
- **Mistake:** Assuming that all applications will automatically support SSO without configuration.
  - Why it is wrong: Applications must be specifically configured to trust the identity provider and to accept its tokens. Legacy applications may not support modern SSO protocols at all and may require additional gateways or proxies.
  - Fix: Always verify that each application can be integrated with the chosen SSO solution. Understand that some apps may need custom configuration or middleware to enable SSO.

## Exam trap

{"trap":"An exam question states: 'A company implements single sign-on. What is the main security advantage of this implementation?' A tempting incorrect answer is 'It eliminates the risk of phishing because users never see a login screen.'","why_learners_choose_it":"Learners might think that if users are automatically authenticated without entering credentials, there is no opportunity for phishing attacks that steal usernames and passwords. This seems logical on the surface.","how_to_avoid_it":"Remember that SSO does not eliminate all security risks, including phishing. Phishing attacks can still target the initial login screen, steal the SSO session token, or use redirects to fake identity provider pages. The real security advantage of SSO is reducing password fatigue and centralizing security controls, not eliminating phishing."}

## Commonly confused with

- **Single sign-on vs Federated identity:** Single sign-on lets a user authenticate once and access multiple apps within the same organization. Federated identity extends this trust across separate organizations. For example, a Contoso employee can access a Partners application using their Contoso credentials. Federation establishes trust relationships between the identity providers of different companies. (Example: A user logs into their own company network and can then access a partner's cloud app without a second login. This is federation, not just SSO.)
- **Single sign-on vs Password hash synchronization:** Password hash synchronization is a feature that syncs password hashes from on-premises Active Directory to Azure AD. It enables SSO because users can use the same password for cloud resources, but it is not SSO itself. SSO is the user experience of not being prompted again after the first login. Password hash sync is one of several methods to make that experience possible. (Example: Password hash sync makes sure the password in the cloud matches the on-premises password, so the user does not need to manage two different passwords. SSO then uses that to skip repeated login prompts.)
- **Single sign-on vs Conditional access:** Conditional access is a policy engine that evaluates signals (user, device, location, risk level) before granting access. It is not an authentication method but a decision layer that can block or require MFA during an SSO session. You can have SSO without conditional access, and conditional access without SSO, but they are commonly used together. (Example: A user with SSO might normally not need to enter a password again. But if they are logging in from an untrusted network, conditional access can require MFA before proceeding.)

## Step-by-step breakdown

1. **User initiates access to a service provider** — The user opens a browser or application that is protected by SSO. For example, they click a link to access a company expense reporting tool. The application is configured as a service provider that relies on an external identity provider for authentication.
2. **Service provider redirects to identity provider** — Since the user does not have an active session with the service provider, the application redirects (or sends an authentication request) to the identity provider. The redirect includes information about the requested resource and a unique identifier for the application.
3. **Identity provider checks for existing session** — The identity provider looks for a session cookie or token that was issued during a previous successful authentication. If a valid session exists, the identity provider skips the credential prompt. If not, the user is asked to enter their username and password, and possibly perform MFA.
4. **Identity provider authenticates user and issues token** — After successful authentication, the identity provider generates a security token. This token contains claims about the user (such as username, email, group memberships) and is digitally signed to prevent tampering. The token is then sent back to the service provider.
5. **Service provider validates the token** — The service provider receives the token and validates its signature using the identity provider's public key. It also checks that the token has not expired and that it was issued for the correct application. If valid, the service provider creates a local session for the user.
6. **User gains access to the service** — With the local session established, the user can now use the application. When the user later accesses another SSO-enabled application, the same process repeats, but because the identity provider already has a valid session for the user, steps 3 and 4 happen automatically without user interaction.

## Practical mini-lesson

In a real-world IT environment, implementing single sign-on requires careful planning and an understanding of both the organization's applications and the identity provider's capabilities. The first step is to choose an identity provider. For Microsoft-centric environments, Azure AD (Microsoft Entra ID) is the natural choice. It supports a wide variety of applications, from Microsoft 365 services to thousands of pre-integrated SaaS apps in the Azure AD gallery. For on-premises applications, you might use Active Directory Federation Services (AD FS) or Azure AD Application Proxy.

Once the identity provider is selected, you need to inventory all applications that users access. Classify each application by its authentication capabilities. Some will support SAML or OpenID Connect natively. Others might support only form-based authentication or integrated Windows authentication. For legacy applications that do not support modern protocols, you might need to use a gateway solution like Azure AD Application Proxy with password vaulting, or a third-party identity provider that offers legacy protocol support. You also need to consider whether the application is cloud-based, on-premises, or hosted by a partner.

Configuration typically involves registering each application in the identity provider. This creates a trust relationship. For SAML applications, you exchange metadata between the identity provider and the service provider. The metadata includes endpoints, certificates, and signing keys. For OpenID Connect, you register a redirect URI and obtain a client ID and secret. User assignment is another critical step. You must decide which users or groups can access each application. This can be done manually or through dynamic group membership rules based on attributes like department or job role.

Session management is a key operational consideration. The identity provider's session lifetime determines how long a user can roam between applications without re-authentication. A session that lasts too long increases risk if the device is compromised. A session that is too short frustrates users. Many organizations set a session timeout of 8 hours to cover a standard workday, with a requirement for MFA re-authentication after 1 hour. You can also configure location-based or risk-based conditional access policies that trigger additional controls.

Common issues that professionals face include token expiry mismatches, incorrect claim mappings, and certificate renewal errors. For example, if a user's group membership changes, the token might not reflect the update until the user logs out and back in. This can delay access to resources that rely on group claims. Another frequent problem is that the browser blocks third-party cookies, which can break SSO flows that rely on cookies from the identity provider. Administrators must educate users not to clear cookies unnecessarily, and they should test SSO in different browsers.

Finally, monitoring and auditing are essential. Use the identity provider's sign-in logs to track successful and failed SSO attempts, unusual locations, and device compliance. This data helps troubleshoot issues and detect potential security threats. Professionals should also regularly test the SSO flow, especially after configuration changes or certificate renewals. Practically, SSO is not a set-and-forget solution; it requires ongoing maintenance and governance to remain secure and functional.

## Memory tip

One key, many doors. Remember SSO as one login that unlocks all your apps.

## FAQ

**Is single sign-on the same as 'remember my password' in a browser?**

No. Browser password saving stores credentials locally and auto-fills them, but the actual authentication still happens each time you log in. SSO uses a central token that is validated by the identity provider across all applications, so you do not actually submit credentials for each app.

**What happens if the identity provider goes down? Can I still access my apps?**

If the identity provider is unavailable and your local session with the service provider has not expired, you may still be able to access that specific application. But once the local session expires or you need to authenticate to a new service, you will be locked out until the identity provider is restored.

**Does SSO work on mobile devices?**

Yes. Mobile apps can use SSO through protocols like OpenID Connect. For example, Microsoft Authenticator can provide SSO across Microsoft mobile apps on iOS and Android using broker authentication.

**Can SSO be used for applications that are not web-based?**

Yes, but it requires additional configuration. Desktop applications can use integrated Windows authentication or Kerberos. Legacy applications may need an application proxy or gateway that handles the SSO flow on their behalf.

**Is it safe to allow users to stay logged in all day with SSO?**

It depends on the security posture. Many organizations allow a full-day session with MFA at the start. However, if a device is stolen, the session might still be active. Using conditional access policies that require MFA on risky sign-ins can reduce the risk.

**How do I troubleshoot why SSO is not working for a specific application?**

Start by checking the user's session status in the identity provider's audit logs. Verify that the application is properly registered and that the user is assigned. Check for certificate expiry, incorrect redirect URLs, and browser cookie settings. Also ensure that the application's token acceptance settings match what the identity provider sends.

## Summary

Single sign-on (SSO) is a foundational identity concept that allows a user to authenticate once and then access multiple applications without re-entering credentials. It works by having a central identity provider issue a security token that is trusted by all connected service providers. This reduces password fatigue, simplifies user management for IT, and enables consistent security policies across the organization. For learners preparing for MS-900, AZ-900, and SC-900 exams, understanding SSO is essential. You need to know the definition, how it differs from federation and password hash sync, and its relationship with MFA and conditional access. Common exam questions include scenario-based recognition, configuration steps, and security considerations. A key exam trap is confusing SSO with eliminating all security risks, when in fact it concentrates risk on the single identity provider account, making MFA a necessary companion. In practice, professionals must know how to select an identity provider, integrate various application types, manage session lifetimes, and troubleshoot common issues like token mismatches and cookie problems. SSO is not a one-time setup; it requires ongoing monitoring and policy adjustment to stay secure. Ultimately, mastering SSO will help you answer identity-related questions confidently and provide a strong foundation for understanding Microsoft's identity and access management solutions.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/single-sign-on