Single Sign-On

This entry has no runnable specimen; the organisation names and domains in the illustration are fictional. Before shipping, confirm assertion handling against the cited specification and verify the fallback when the provider is unavailable.

{
  "states": [
    "signed-out",
    "redirecting",
    "signed-in",
    "error"
  ],
  "a11y": [
    "Both the hop and the return produce page-title changes a screen reader can notice",
    "Failure is explained in words rather than by an error code alone"
  ],
  "motion": "The hop needs no animation, and waiting is covered by a textual status"
}

{
  "id": "single-sign-on",
  "type": "interaction",
  "name": {
    "zh": "单点登录",
    "en": "Single Sign-On"
  },
  "aliases": [
    "SSO",
    "Federated Login",
    "联合登录",
    "统一身份登录"
  ],
  "granularity": "flow",
  "intents": [
    "configure",
    "protect-privacy"
  ],
  "tags": [
    "sign-in",
    "identity",
    "federation",
    "enterprise",
    "credential"
  ],
  "definition": "Trading one sign-in at an identity provider for access to several independent applications: the user authenticates once and each application admits them on the assertion the provider issues, instead of each keeping its own credential.",
  "boundary": "Single sign-on settles where authentication happens, not what may be done — authorisation and permissions still belong to each application, and a successful sign-in is not a right to act. It is also not typing the same username and password in several places, which is same-sign-on; true single sign-on does not ask the user to present authentication factors again. This entry covers the shape and trade-offs of the flow in an interface, not the choice of protocol; assertion formats and security requirements belong to the cited specification.",
  "signature": [
    "The user enters credentials at the identity provider rather than inside each application",
    "Entering a second application does not ask for authentication factors again",
    "Applications hold no password and accept only the assertion the provider issues"
  ],
  "when": [
    "One group of users needs access to several systems maintained by different teams",
    "The organisation needs one place to revoke access, as when someone leaves",
    "Reducing the exposure that comes from every application storing its own passwords"
  ],
  "when_not": [
    "Sign-in is centralised with no plan for the identity provider being unavailable",
    "It replaces an authorisation decision so that signing in is treated as the right to act",
    "A consumer product makes third-party identity the only entrance, excluding people who do not use that platform"
  ],
  "tradeoff": "Centralising authentication cuts both the credentials users must remember and the secrets applications must keep, at the cost of concentrating risk: when the provider is unavailable every application closes at once, and a stolen credential reaches further.",
  "comparison": {
    "focus": "Trading one authentication for access to several applications",
    "mechanism": "The identity provider issues an assertion that each application admits on",
    "cost": "Both risk and availability concentrate at the provider"
  },
  "sources": [
    {
      "id": "sso-wikipedia",
      "title": "Wikipedia · Single sign-on",
      "url": "https://en.wikipedia.org/wiki/Single_sign-on",
      "claim": "The article defines single sign-on as an authentication scheme that allows a user to log in with a single ID to any of several related yet independent software systems, notes that true single sign-on lets the user log in once and access services without re-entering authentication factors, and distinguishes it explicitly from same-sign-on, which merely shares one set of credentials. This entry paraphrases the definition and the boundary from it.",
      "checkedAt": "2026-09-16",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260916*/https://en.wikipedia.org/wiki/Single_sign-on",
        "status": "unconfirmed",
        "checkedAt": "2026-09-16T17:33:38.705Z",
        "error": "status-request-failed",
        "jobId": "spn2-89a789828b03ffa4707051f0708c4ef22e54362a"
      }
    },
    {
      "id": "sso-nist-63c",
      "title": "NIST SP 800-63C-4 · Digital Identity Guidelines: Federation and Assertions",
      "url": "https://pages.nist.gov/800-63-4/sp800-63c.html",
      "claim": "The guideline explains that federation lets a credential service provider supply authentication attributes to several separately administered relying parties so that the subscriber need not hold or maintain separate authenticators at each one, and notes that this process is sometimes known as single sign-on; it also states that federation is generally the preferred approach when the relying party and the subscriber account are not administered together under a common security domain. This entry paraphrases the mechanism and the applicable situations from it.",
      "checkedAt": "2026-09-16",
      "archive": {
        "lookupUrl": "https://web.archive.org/web/20260916*/https://pages.nist.gov/800-63-4/sp800-63c.html",
        "status": "available",
        "checkedAt": "2026-09-16T17:33:39.848Z",
        "jobId": "spn2-2e760c4e5af898f66d90dc9428b2f7cf9731fdc1",
        "url": "https://web.archive.org/web/20260916173404/https://pages.nist.gov/800-63-4/sp800-63c.html",
        "timestamp": "20260916173404"
      }
    }
  ],
  "relations": [
    {
      "target": "privacy-by-design",
      "kind": "composes_with",
      "condition": "The identity provider passes user attributes to the applications it serves",
      "reason": "Federated sign-in carries attributes such as name and email along with it; only what the application actually needs should be passed, and the user should be able to see what was.",
      "basis": "editorial"
    },
    {
      "target": "visibility-of-system-status",
      "kind": "composes_with",
      "condition": "The sign-in journey hops between several domains",
      "reason": "Users are taken to an unfamiliar domain and back, so at every point they must be able to tell which step they are on and whom they are authenticating to.",
      "basis": "editorial"
    },
    {
      "target": "inclusive-design",
      "kind": "conflicts_when",
      "condition": "A consumer product makes one third-party identity the only way in",
      "reason": "Binding the only entrance to one platform excludes people who do not use it, cannot use it, or have lost their account there.",
      "basis": "editorial"
    }
  ],
  "rules": [
    {
      "when": "The product makes single sign-on its main way in",
      "instruction": "Prepare an explanation and a way to get help for when the provider is unavailable, instead of showing only a failure page.",
      "strength": "must",
      "basis": "editorial"
    },
    {
      "when": "The flow sends the user to another domain",
      "instruction": "Say where the user is going and why before the hop, and confirm on return that the identity is established; do not make the hop silent.",
      "strength": "recommend",
      "basis": "editorial"
    }
  ],
  "behavior": {
    "states": [
      "signed-out",
      "redirecting",
      "signed-in",
      "error"
    ],
    "a11y": [
      "Both the hop and the return produce page-title changes a screen reader can notice",
      "Failure is explained in words rather than by an error code alone"
    ],
    "motion": "The hop needs no animation, and waiting is covered by a textual status"
  },
  "demo": null,
  "version": "0.1.0",
  "editorialStatus": "drafted",
  "requirements": [],
  "demoCapabilities": [],
  "implementationNote": "This entry has no runnable specimen; the organisation names and domains in the illustration are fictional. Before shipping, confirm assertion handling against the cited specification and verify the fallback when the provider is unavailable.",
  "image": {
    "src": "/images/single-sign-on.webp",
    "alt": "A flow sketch: a fictional identity provider sign-in card on the left, an arrow from it to three fictional application windows side by side on the right, each holding only grey placeholder content bars to show they all admit on the same sign-in."
  },
  "searchTerms": [
    "登录",
    "身份",
    "联合认证",
    "企业",
    "凭据"
  ]
}