进入我的职业范围了，简单说说。

SSO 的意思是 Single Sign-On ，这里的 Single 既有“一次”的意思，也有“一点”的意思。

对个人应用来说，一般是为了“一次”，就是只需输入一次账号密码，就可以在多处畅游了。

对企业应用来说，更多是为了“一点”，也就是集中管理。员工离职以后，企业关联的所有服务就都不能用了。

在一个 SSO 系统里，分为 ID Provider 和 Service Provider 两个角色，简称 IDP 和 SP 。IDP 就是负责提供登录信息的，SP 就是登录信息的消费者。

当 SP 需要用户通过 SSO 登录时，就把用户发到 IDP ，IDP 处理完了再把用户发回来，顺便带回登录信息。主流实现有 OAuth2 和 SAML 两种，流程都是上面这样。SAML 还允许 IDP 带着登录信息把用户直接发到 SP ，无需 SP-IDP-SP 这样跳来跳去，所以深受企业用户喜爱。但 SAML 是基于证书的，技术实现比 OAuth2 复杂得多，所以一般个人网站都用 OAuth2 。

最常见的 SSO 就是各种社交登录，以 Google 为例，流程如下：

1 、SP 把用户 redirect 到 Google （带着 SP 的信息）
2 、用户登录 Google （如果已登陆，这一步可以跳过）
3 、Google 把用户 redirect 回 SP （带着一个 code ）
4 、SP 用这个 code 在后台向 Google 换取用户的信息（唯一 ID 、email 之类的）
5 、SP 根据从 Google 获得的用户信息让用户使用服务。

注意：这里没有提及任何 cookie 、session 之类的词汇，因为怎么使用从 Google 获取的用户信息是 SP 自己的事。这些信息存在哪里、怎么存、怎么过期，全看你的需要。

当用户跳到你的另一个应用时，你可以再来一遍上述流程。一般这是个静默流程，因为用户已经登陆 Google 了，在用户看来就是几个白页跳转了几下，就进入正常使用的页面了。