1.Cookie + Session 登录
Cookie/Session认证机制就是为一次请求认证在服务端创建一个Session对象，同时在客户端的浏览器端创建了一个Cookie对象；通过客户端带上来Cookie对象来与服务器端的session对象匹配来实现状态管理的。默认的，当我们关闭浏览器的时候，cookie会被删除。但可以通过修改cookie 的expire time使cookie在一定时间内有效。
缺点：
虽然这种方式完成了用户的身份验证，但是也存在一定问题：
维护成本高： 如果服务器端是一个集群，为了同步登录态，需要将 SessionId 同步到每一台机器上，无形中增加了服务器端维护成本。
服务器压力增大：通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
CSRF跨站伪造请求攻击：session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。可以添加csrf_token处理。
扩展性不强：如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。
手机请求不支持：Cookie不支持手机端访问的
2. Token 登录
为了解决问题1，出现了这个
Token 是服务端生成的一串字符串，以作为客户端请求的一个令牌。当第一次登录后，服务器会生成一个 Token 并返回给客户端，客户端后续访问时，只需带上这个 Token 即可完成身份认证。
登录机制：
登录时,客户端通过用户名与密码请求登录
服务端收到请求去验证用户名与密码
验证通过，服务端会签发一个带签名的Token，再把这个Token以响应发给客户端
客户端收到Token,存储到本地,如Cookie、SessionStorage、LocalStorage
客户端每次像服务器请求API接口时候，都要带上Token
服务端收到请求，验证Token，如果通过就返回数据，否则提示报错信息
特点：
无状态、可扩展：在客户端存储的Tokens是无状态的，并且能够被扩展。基于这种无状态和不存储Session信息，负载负载均衡器能够将用户信息从一个服务传到其他服务器上。
安全性：请求中发送token而不再是发送cookie能够防止CSRF(跨站请求伪造)。即使在客户端使用cookie存储token，cookie也仅仅是一个存储机制而不是用于认证。不将信息存储在Session中，少了对session操作。
时效： Token 下发之后，只要在生效时间之内，就一直有效，如果服务器端想收回此 Token 的权限，并不容易。如果失效，就会重新进行登录验证，服务器端会返回状态码401需要注意的是，前端每次路由跳转时，需要判断本地内存中有无 token ，没有则跳转到登录页。有则请求获取用户信息，改变登录状态。
3.SSO 单点登录
单点登录（Single Sign On），简称为 SSO，是目前比较流行的企业业务整合的解决方案之一。SSO的定义是在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。
SSO一般都需要一个独立的认证中心（passport），子系统的登录均得通过passport，子系统本身将不参与登录操作，当一个系统成功登录以后，passport将会颁发一个令牌给各个子系统，子系统可以拿着令牌会获取各自的受保护资源，为了减少频繁认证，各个子系统在被passport授权以后，会建立一个局部会话，在一定时间内可以无需再次向passport发起认证。
特点：
简化管理
提高用户的效率
提高开发人员的效率
用户不再被多次登录困扰，也不需要记住多个 ID 和 密码。
SSO 为开发人员提供了一个通用的身份验证框架。 实际上，如果 SSO 机制是独立的，那么开发人员就完全不需要为身份验证操心。
如果应用程序加入了单点登录协议，管理用户帐号的负担就会减轻。简化的程度取决于应用程序，因为 SSO 只处理身份验证。所以，应用程序可能仍然需要设置用户的属性（比如访问特权）。
缺点：
CPU开销较大：在并发量比较高的情况下，如果许多线程反复尝试更新某一个变量，却又一直更新不成功，循环往复，会给CPU带来很大的压力。
安全隐患 ：因为只需要登录一次，所有的授权的应用系统都可以访问，可能导致一些很重要的信息泄露。
不利于重构 ： 因为涉及到的系统很多，要重构必须要兼容所有的系统，可能很耗时
4.OAuth 第三方登录
第三方登录，实质就是 OAuth 授权。用户想要登录 A 网站，A 网站让用户提供第三方网站的数据，证明自己的身份。获取第三方网站的身份数据，就需要 OAuth 授权。
OAuth 是 Open Authorization 的简写，它为用户资源的授权提供了一个安全又简易的标准。与以往的授权方式不同之处是 OAuth的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此 OAuth是安全的。
OAuth 本身不存在一个标准的实现，后端开发者自己根据实际的需求和标准的规定实现。其步骤一般如下：
第三方要求用户给予授权
用户同意授权
根据上一步获得的授权，第三方向认证服务器请求令牌（token）
认证服务器对授权进行认证，确认无误后发放令牌
第三方使用令牌向资源服务器请求资源
资源服务器使用令牌向认证服务器确认令牌的正确性，确认无误后提供资源
5. 对比
对于这 4 种常见的登录方式，它们的使用场景如下：
Cookie + Session ：适合于简单的后端架构，需开发人员自己处理好安全问题。
Token ：方案对后端压力小，适合大型分布式的后端架构，但已分发出去的 token ，如果想收回权限，就不是很方便了。
SSO ：单点登录，适用于中大型企业，想要统一内部所有产品的登录方式。
OAuth 第三方登录：简单易用，对用户和开发者都友好，但第三方平台很多，需要选择合适自己的第三方登录平台。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
