常见的登录验证方式
Cookie+Session登录1. Cookie+Session实现流程2. Cookie+Session存在的问题
Token登录认证1. Token机制实现流程2. Token机制特色3. Token的生成方式
SSO单点登录1. SSO机制实现流程2. SSO单点登录退出
OAuth第三方登录
登录是每个网站中常常用到的功能，在页面上输入自己的账号密码，敲一下回车键，即可完成登录，但是其中背后的登录原理值得深入探究，今天就来介绍几种常用的登录方式。
Cookie+Session登录
HTTP是一种无状态的协议，客户端每次发送请求时，首先要和服务端创建一个连接，在请求完成之后会断开这个连接。这种方式能够节省传输时占用的连接资源，但同时也存在一个问题：每次请求都是独立的，服务器没法判断本次请求和上一次请求是否来自同一个用户，进而也没法判断用户的登录状态。
为了解决HTTP无状态的问题，Lou等在1994年的时候，推出了Cookie。
Cookie是服务端发送给客户端的一段特殊信息，这些信息以文本的方式存放在客户端，客户端每次向服务端发送请求时都会带上这些特殊信息。
有了Cookie之后，服务端就可以获取到客户端传递过来的信息，若是需要对信息进行验证，还需要经过Session。
客户端请求服务端，服务端会为此次请求开辟一块内存区域，这就是Session对象。
有了Cookie和Session之后，我们就能够进行登录认证了。
1. Cookie+Session实现流程
Cookie+Session的登录方式是最经典的一种登录方式，如今仍有大量企业在用。 用户首次登录时：
先访问a.com/login，输入账号密码登录。服务器验证密码无误后，会建立SessionId，并将它保存起来。服务端响应这个HTTP请求，并经过Set-Cookie头信息，将SessionId写入Cookie中。浏览器会根据Set-Cookie中的信息，自动将SessionId存储在cookie中。
服务端的SessionId可能存放在不少地方，如内存、文件、数据库等。
第一次登录完成之后，后续的访问就能够直接使用Cookie进行身份验证了：
用户访问a.com/page页面时，会自动带上第一次登录时写入的Cookie。服务端对比Cookie中的SessionId和保存在服务端的SessionId是否一致。若是一致，则身份验证成功。
2. Cookie+Session存在的问题
虽然这种使用Cookie+Session的方式完成了登录验证，但仍然存在一些问题：
因为服务端需要对接大量的客户端，就需要存放大量的SessionId，会导致服务端压力过大。若服务端是一个集群，需要将SessionId同步到每一台机器上，无形中增长了服务端维护成本。因为SessionId存放在Cookie中，因此没法避免CSRF攻击。
CSRF攻击是一种利用用户在目标网站上已认证的会话执行非预期操作的攻击方式。攻击者通过欺骗用户使其在受信任的网站上执行恶意操作，如转账、修改账户信息等。常见的CSRF攻击方式，如下： 1、直接链接方式，攻击者通过诱使用户点击恶意链接，向目标网站发送伪造请求。当用户点击链接时，浏览器会自动发送包含用户认证信息的请求，从而执行攻击者指定的操作。 2、图片/资源引用方式，攻击者将恶意请求嵌入到图片、脚本或其他资源引用中，并将其插入到受信任网站的页面。当用户访问页面时，浏览器会自动加载并发送恶意请求。 3、表单提交方式，攻击者创建一个包含恶意请求的表单，并将其隐藏在一个看似正常的页面中。当用户在该页面上执行某些操作（如点击按钮）时，浏览器会自动提交表单，从而执行攻击者指定的操作。
Token登录认证
为了解决Session+Cookie机制暴露出的诸多问题，我们可使用Token的登录方式。
Token是服务端生成的一串字符串，以作为客户端请求的一个令牌。当第一次登录后，服务端会生成一个Token并返回给客户端，客户端后续访问时，只要携带这个Token就能完成认证。
1. Token机制实现流程
用户首次登录时：
用户访问a.com/login，输入账号密码，并点击登录。服务端验证账号密码无误，建立Token。服务端将Token返回给客户端，由客户端自由保存。
后续访问页面时：
用户访问a.com/page时，带上第一次登录时获取的Token。服务端验证Token，有效则身份验证成功。
2. Token机制特色
根据上述流程，分析Token机制的优缺点：
服务端不需要存放Token，因此不会对服务端形成压力，即便是服务器集群，也不需要增长维护成本。Token能够存放在前端任何地方，能够不保存在Cookie中，提高了页面安全性。Token下发之后，只要在生效时间内，就一直生效，若服务端想要收回此Token权限，并不容易。
3. Token的生成方式
最常见的Token生成方式是使用JWT，即Json Web Token，它采用一种简洁的，自包含的方法，用于通讯双方之间以JSON对象的形式安全的传递信息。
之前说到使用Token后，服务端不会存储Token，那么如何判断客户端发过来的Toekn是否合法有效呢？答案就在Toekn字符串中，其实Token并非一段杂乱无章的字符串，是经过多种算法拼接组合而成的字符串，下面分析一下其组成：
JWT算法主要分为3个部分：header（头信息）、playload（消息体）、signature（签名）header部分指定了该JWT使用的签名算法。playload代表了JWT的意图。signatrue部分为JWT的签名，主要为了让JWT不能被随意篡改。
有了Token之后，登录方式已经变得很高效。
SSO单点登录
单点登录指在公司内部搭建的一个公共认证中心，公司下的全部产品登录均可以在认证中心完成，一个产品在认证中心登录之后，再去访问另外一个产品，能够不用再次登录，便获取登录状态。
1. SSO机制实现流程
用户首次访问时，需要在认证中心登录：
用户访问网站a.com/pageA页面。因为没有登录，会重定向到认证中心，并带上回调地址www.sso.com?return_uri=a.com/pageA，以便登录后直接进入对应页面。用户在认证中心输入账号密码，提交登录。认证中心验证账号密码有效，后重定向到a.com?ticket=123，带上授权码ticket，并将认证中心sso.com的登录态写入Cookie。在a.com服务器上，拿着ticket向认证中心确认，授权码ticket真实有效。验证成功后，服务器将登录信息写入Cookie（此时客户端有两个Cookie，分别存有a.com和sso.com的登录态信息）
认证中心完成登录后，继续访问a.com的其余页面，由于此时a.com已经存了Cookie信息，服务端直接认证成功。 如果要访问认证中心已存的b.com的页面，由于认证中心存在以前登录过的Cookie，也就不用再输入账号密码，直接返回第四步，下发ticket给b.com即可。
2. SSO单点登录退出
完成单点登录后，在同一套认证中心管理下，多个产品能够共享登录状态，但是还有一个问题：在一个产品中退出了登录状态，怎么让其余产品也退出登录？
原理并不难，回过头来看第5步，每个产品在向认证中心验证ticket时，能够顺带将本身的退出登录api发送到认证中心。当某个产品c.com退出登录时：
清空c.com中的登录态Cookie。请求认证中心sso.com中的退出api认证中心遍历下发过ticket的全部产品，并调用对应的退出api，完成退出。
OAuth第三方登录
除了上述的认证方式，也可以引入第三方厂家提供的登录服务。如微博、微信、QQ等提供的登录认证接口，均能实现登录过程。