第三方登录方案对比

第三方登录方案对比

1第三方登录介绍

随着web2.0时代的爆发，为了迎合大众的需求，各式各样的网站如雨后春笋般成立。这样导致的结果是每个人拥有的账号越来越多，用户遗忘账号或密码越来越频繁，网站必须赢得用户足够多的青睐，才能获得新用户的注册。而解决的方法只有两个，一个取决于用户，让用户每次都用与以前注册相同的账号密码注册，但这样显然有非常大的安全隐患的，因为用户很难相信一个刚接触的网站，不放心使用以前相同的用户名和密码，而且一旦一个网站的用户系统崩溃，以前注册的账号将会面临巨大的风险，因此，这个方法不太可靠。第二个方法就是网站提供一个第三方登录的方式给新注册用户，即从第三方网站直接获取信息作为本次注册需要提供的信息，但不能保存用户在第三方网站的账号密码，否则会重蹈第一个方案的覆辙，这样的好处非常多，不仅可以加快用户注册的速度，而且用户在使用本网站时还能与第三方网站互动。对于第二种方法，业界成熟的做法是使用OAuth2.0协议来交换用户信息，它在用户与网站之间添加一层授权层，使用户的账号密码与网站隔离。然而，OAuth2.0并非能适用于所有场景，它也有其不足和缺陷，因此，本文将提出一个全新的第三方登录方案——zstouth。

在本论文中，第2章将介绍OAuth2.0协议的原理和分析该协议的不足；第3章将提出本文的第三方登录方案，并分析该方案如何确保用户登录的安全；第4章将对比两种方案的差异与分析各自适用场景；第5章是本文的总结。

2OAuth2.0

2.1OAuth2.0介绍

在下文中，本文把需要使用其他网站账号注册的网站称作注册网站，其他系统称作第三方网站。

OAuth（Open A uthorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，注册网站无需知道用户在第三方网站的账号及密码，就可获取

到用户的授权信息，并且这是安全的。

OAuth2.0是基于OAuth1.0开发的授权协议，它比OAuth1.0少了一个步骤，但在实践中变得更加安全可靠和高效，由于其简便安全开放的性质，近年来受到众多开发者和网站的青睐和追捧。

2.2OAuth2.0原理

介绍OAuth2.0原理前，首先解释OAuth2.0中的名词。

1.Third--‐party a pplication：第三方应用程序，即本文中的注册网站。

2.HTTP service：HTTP服务提供商，即本文中的第三方网站，简称"服务提

供商"。

3.Resource O wner：资源所有者，即本文中的"用户"（user）。

https://www.360docs.net/doc/fa10662042.html,er A gent：用户代理，本文中就是指浏览器。

5.Authorization server：认证服务器，即服务提供商专门用来处理认证的服

务器。

6.Resource server：资源服务器，即服务提供商存放用户生成的资源的服务

器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。

OAuth2.0原理流程图如图 1所示，取自RFC 6749：

图 1 O Auth2.0原理流程

图 1流程中各步骤解释如下：

（A） 注册网站引导用户至第三方网站的资源服务器，请求授权。

（B） 用户登录第三方网站，并确认授权于注册网站，资源服务器给予注册网站授权码（Authorization C ode）。

（C） 注册网站向第三方网站的认证服务器请求口令（Access T oken），把上一步获得的授权码作为请求参数。

（D） 认证服务器验证授权码和时效，正确无误后把口令发放给注册网站。

（E） 注册网站再一步向资源服务器请求用户资源，把上一步获得的口令作为请求参数。

（F） 资源服务器验证口令和时效，正确无误后把用户受保护的资源返回给注册网站。

2.3OAuth2.0缺点与适用场景

1.非绑定token，在OAuth1.0中，注册网站需要获取第三方网站的信息时，

需要提供口令凭证（Access Token和Access Token Secret）和客户凭证

（App k ey和App S ecret），但OAuth2.0放弃了客户凭证和签名机制，注

册网站只需提供Access T oken即可获取用户在第三发系统中受保护的资

源，因此，Access Token一旦在传输过程中被监听截取，用户信息将岌

岌可危。

2.即使Access T oken加密，攻击者仍然可以使用重放请求用户信息的手段，

获取到用户受保护的信息。

3.授权页面出现假冒钓鱼页面时，用户可能会泄露第三方网站的账户信息，

后果将更加严重。

4.OAuth2.0明显偏向于保护第三方网站的用户信息，第三方网站如果希望

提供用户信息，需要搭建资源服务器和认证服务器，并且遵循OAuth2.0

协议标准，成本较高。

5.在OAuth2.0中，第三方网站与其他需要用户信息的注册网站之间的关系

是一对多的关系，OAuth2.0是一个开放的平台，任何注册网站只要与第

三方网站相互信任，就可以获取用户信息，然而，这种平台不适用于一

对一合作关系的网站间用户信息的传递。

3zstouth方案

假设有一个图书馆项目，该项目需要提供用户一个可以利用第三方网站的账号登录的功能，例如国家图书馆的账号，以此与国家图书馆合作，导入国家图书馆的用户。但该功能要求不能偏向于国家图书馆，安全性需要本项目来保证，而且国家图书馆等第三方网站也不打算搭建OAuth2.0所需的服务器，因为不仅成本太高，而且这些第三方网站只需与该图书馆合作。基于以上的原因，本项目需要提供一套服务让第三方网站放心提供用户信息。

3.1zstouth设计目标

根据OAuth2.0的不足，本论文提出的zstouch方案的设计目标包括：

1)防止登录回调地址的重放攻击，即防止黑客窃听到用户成功登录后的回调

地址后，直接使用该地址伪装用户登录，修改用户的资料。

2)登录成功前，需要验证该用户是否刚刚在第三方网站登录，防止攻击者冒

充第三方网站的用户注册或登录。

3)第三方网站确定与本项目合作前，需要提供正确地登录地址和验证用户已

登录的接口，确定后，图书馆将发放公钥，以后传输用户信息时，使用该

公钥加密。一方面防止图书馆跳转到假冒的第三方登录地址，另一方面防

止用户信息在传递时被攻击者窃听。

3.2zstouth登录流程

zstouth方案的流程图如图 2所示：

图 2 第三方登录流程

图 2中各步骤解释如下：

1.用户在浏览图书馆系统中的任意一个页面（如book.html）时均可登录，

均可选择使用第三方账号登录。

2.获取第三方网站提供的登录地址，然后把用户导向该地址，并把回调地

址和登录前所在地址（即book.html）作为请求参数。

3.用户进入第三方网站的登录页面。

4.用户输入用户名和密码登录，若登录成功跳转到第5步，失败则跳转到

第3步。

5.用户查看图书馆的权限，确认是否授权，授权成功跳转到第6步，失败

则跳转到第1步。

6.第三方网站返回回调地址前需要从图书馆系统获取login_token，该

login_token是与用户和第三方网站绑定，保存在图书馆系统，并且是一

次性，登录一次结束后即无效。

7.第三方网站将导向图书馆登录成功后的回调地址，并把login_token、加

密后的用户信息和登录前所在地址（book.html）作为参数。

8.图书馆系统检查参数中的login_token，匹配成功后跳转到第9步，并把

该login_token删除，失败则跳转到第1步。

9.验证用户是否在约定的时间内登录成功第三方网站，验证成功后跳转到

第10步，失败则跳转到第1步。

10.用户使用第三方账号登录成功，用户将从回调地址跳转到登录前地址

（book.html）。

3.3zstouth方案分析

从zstouth方案的流程图中可以看出，该方案确保登录安全性一共有三个方面：

1.使用一次性login_token防止攻击者的重放攻击。即使攻击者窃听到第三方

网站登录成功回调图书馆系统的URL，他也不可以二次使用该URL冒充用

户登录，因为login_token保存在图书馆系统中，一旦验证成功就会被删除

或失效。

2.验证用户是否已登录以防止攻击者冒充用户申请login_token，然后登录图

书馆系统。因为即使攻击者知道第三方网站存在某位用户，但由于

login_token里包含登录时间，由第三方网站申请时提供，所以当验证用户

是否已登录时，会要求第三方对比login_token和系统中用户的登录时间，

一致才能登录图书馆系统。这样一来，可以确保该用户确实在第三方网站

登录后导向图书馆系统的。

3.加密传输的用户信息防止泄露。第三方网站向图书馆系统提供登录地址和

验证用户已登录的接口后会获得图书馆系统的公钥，然后在传输用户信息

前使用该公钥加密，确保只有图书馆系统才能解开用户信息。

4第三方登录方案对比

通过第3章关于zstouth方案的描述，可以看出该方案中图书馆系统和第三方

网站是一种平等的地位，因为方案中不仅确保了用户信息的安全，而且防止了攻击者冒充用户登录图书馆系统。然而，该方案也并不能适用所有第三方登录的场景，因为该方案中图书馆系统与第三方网站之间是一对多的关系，而在OAuth2.0中则是多对一的关系，而且该方案要求图书馆系统需要维护login_token集合，增加了图书馆系统的负担。

综上所述，OAuth2.0适用于刚成立的小网站，希望通过导入支持OAuth2.0的网站的用户来扩展自己的用户群，虽然其安全性方面仍存在不足，但由于其高效性和开放性，目前大部分社交网站均支持OAuth2.0协议，这对刚成立的网站是件好事，因为只需实现OAuth2.0定义的客户端部分，就能适配各大网站，成本相当低。然而，对于安全性要求较高，希望通过自身网站维护其安全性，而且第三方网站不需要和许多其他网站合作的情况，本文所提出的第三方登录方案显然更为适合。除此之外，OAuth2.0和zstouth方案中，注册网站（图书馆系统）与第三方网站交互的次数都是3，效率总体相差不大。

5总结

针对第三方登录方案，本文首先介绍了OAuth2.0协议的原理和不足，然后革命性地提出zstouth的方案，在保证登录效率的基础上，弥补了OAuth2.0安全性的不足，最后通过对比两种第三方登录的方案，分析各自的应用场景。

本文所提出的第三方登录方案，已经集成并运行在某图书馆系统中，受到了用户和第三方网站的一致认同。