Single Sign-On, SSO 单点登录，允许在单次登陆之后可以访问其它相关网站，也就是说，其中的一部分核心功能就是验证用户身份，除了上述的认证，同时也会作为用户的跟踪。

简介 #

一般会通过 login.foobar.com 类似的域名登陆网站，在单次登陆之后，可以免登陆访问本域名下的其它网站，从而可以实现一次登陆全部访问。

当前互联网的大部分功能都是通过 HTTP 协议构建的，但因为 HTTP 协议是无状态的，为了追踪用户提出了多种方法，例如 cookie、session、token、浏览器指纹等等，不同的方法各有优缺点，这里详细介绍。

实现方法 #

目前来说，大致有如下有几种方案：

1. Session，在浏览器保存类似 ID 的信息，敏感信息在服务器分布式共享内存中保存，每次调用时检查。
2. Token，每次请求会带上对应的 Token ，然后直接通过 Token 检查是否合法即可。
3. AK/SK，实际上类似用户名密码，但是用途略有区别。

其中第一种方案，为了防止被破解，一般会在服务端缓存，这样就会依赖一个全局的缓存机制；而后者因为存在时效性，而且信息是保存在 Token 中的，减少了对缓存的依赖，但是无法从服务端主动取消用户登陆。

所以，建议用户登陆使用 Session 机制，而机机鉴权采用 Token 机制。

存储机制 #

上述的会话 ID 信息可以在本地保存，通常有如下的几种方案：

• LocalStorage 除非用户显示清除，否则会一直存在，数据大小一般要求小于 5M 。
• SessionStorage 当浏览器的会话关闭之后数据会被清理。
• Cookies 按照域名保存，用于保存一些标识信息，不能超过 4K 。

Cookies #

安全性 #

处于安全的考虑，有两个属性可以进行设置：A) Secure=true 意味着这个 Cookie 只能通过 https 协议发送；B) HttpOnly=true 该 Cookie 不能通过 document.cookie 类似的 JS 方法打印出 Cookie 的内容。

在 Cookie 中的信息是没有加密的，所以有类似 Secure Cookie 的方案，通过 HMAC 对称加解密算法在 Cookie 中保存一些敏感信息，不过，仍不建议在 Cookie 中保存敏感信息，最好保存在服务端的 Session 信息中。

AK/SK #

通过使用 Access Key ID(AK)/Secret Access Key(SK) 来验证某个请求的发送者身份，在调用 API 时，需要对参数以及 AK 使用 SK 进行签名，生成一个签名信息；服务端会根据 AK 查询到预制的 SK 以相同方式进行签名，并确保一致，防止中间被篡改。

通常会采用 HMAC 作认证，在这一过程中可以避免传输 SK ，而且一般来说签名只会使用一次，可以避免重放攻击。

注意，客户端和服务端需要同时保存 AK/SK ，而且 AK 会在传输过程中使用，所以，需要保证 Secure Key 不能在网络中传输，以及不能在不受信任的位置存放。