思想 Web 应用中的身份验证手艺

登录工程:现代 Web 应用的典型身份验证需求

2017/02/18 · 基础技术 ·
WEB,
登录,
身份验证

本文作者: 伯乐在线 –
ThoughtWorks
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

朋友就职于某大型互联网公司。前不久,在闲聊间我问他日常工作的内容,他说他所在部门只负责一件事,即用户与登录。

金沙js333娱乐场 1

而他的具体工作则是为各个业务子网站提供友好的登录部件(Widget),从而统一整个网站群的登录体验,同时也能令业务开发者不用花费额外的精力去关注用户鉴权。这很有趣。

可以看出,在一个现代Web应用中,围绕“登录”这一需求,俨然已经衍生出了一个新的工程。不管是我们面临的需求,还是解决这些需求所运用的方法与工具,都已经超出了传统Web应用身份验证技术的范畴。

在之前一篇文章中,我聊到传统Web应用中的身份验证技术,文章中列出的一些方法在之前很长一段时间内,为满足大量的Web应用中身份验证的需求提供了思路。在这篇文章里,我将简要介绍现代Web应用中几种典型的身份验证需求。

与第三方集成:迎接更多用户

“即得”是一个开放式文档共享应用,特点是“无需登录,即传即得”,它利用长时间有效的Cookie来标识用户,从而免除了人们使用应用之前必须注册登录的繁琐步骤。

这种做法的风险是,如果用户有及时清理浏览器Cookie的习惯,那很可能导致用户再一次登陆时不再被识别。不过从这样一个小例子中,却容易看出登录的真正作用,就是Web应用识别用户的过程,当下次同一个用户再次使用时,Web应用就能够知道“这就是上次来过的那个用户”。

如果识别用户这一需求能够在不需要用户注册的前提下搞定,岂不两全齐美?基于第三方身份提供方的接口来识别已经在其他平台注册的用户,并将其转化为自己应用中的用户,这种方式完全可行,并且大量的开发人员已经有了丰富的实践。

从 2010
年开始就有不少的大型互联网公司开始推出开放平台服务,让第三方应用通过Web接口与这些互联网服务交互,从而为他们提供更丰富多彩的功能。在这个过程中,一些应用不为这些平台提供扩展,却巧辟蹊径地利用了这些开放平台的身份识别接口来免除新用户注册的过程,从而为自己的产品快速导入用户。不少网站都提供“使用微博账号登录”功能,相信读者一定体验过。

金沙js333娱乐场 2

(图片来自:http://bit.ly/2kFi3e8)

如果你的应用需要向第三方提供用户,那么我们的角色就由“从上下文中读取用户身份”变成了“向上下文中写入用户身份”了。如果你正好有过与各互联网公司开放平台的接口打交道的经历,这时候,你就可以体验一把提供开放、安全上下文的挑战了。如果……你的平台既希望让其他平台的用户能够平滑接入,又希望向其他平台公开自己的用户,那可能是另一番更有趣的挑战。这个过程,也可以作为生物验证之外的另一种间接消除密码的实践方式吧。

登录,现在实实在在地成为了一个独立的工程。尤其在形态多样的基于Web的应用,以及这些Web应用本身所依赖的各色后端服务快速生长的过程中,各种鉴权需求随之而来。如何在保障各个环节中安全的同时,又为用户提供良好的体验,成为一个挑战。

另外,个人信息泄露的事件频繁被曝光,它们导致的社会问题也开始被更多人关注和重视,作为IT系统支撑者的工程师们有责任了解事关安全的基础知识,并掌握必要的技能去保护用户数据和企业利益。

我会在接下来的文章中介绍解决典型登录需求的具体技术方案,以及相关领域的安全实践常识。


更多精彩洞见,请关注微信公众号:思特沃克

简单实用的登录技术

对于互联网Web应用来说,不采用Basic或Digest鉴权的理由主要有两个:

  1. 不能接受在每个请求中发送用户名和密码凭据
  2. 需要在服务器端对密码进行不可逆的加密

因此,互联网Web应用开发已经形成了一个基本的实践模式,能够在服务端对密码强加密之后存储,并且尽量减少鉴权过程中对凭据的传输。其过程如下图所示:

金沙js333娱乐场 3

这一过程的原理很简单,专门发送一个鉴权请求,只在这个请求头中包含原始用户名和密码凭据,经服务器验证合法之后,由服务器发给一个会话标识(Session
ID),客户端将会话标识存储在 Cookie
中,服务器记录会话标识与经过验证的用户的对应关系;后续客户端使用会话标识、而不是原始凭据去与服务器交互,服务器读取到会话标识后从自身的会话存储中读取已在第一个鉴权请求中验证过的用户身份。为了保护用户的原始凭据在传输中的安全,只需要为第一个鉴权请求构建安全连接支持。

服务端的代码包含首次鉴权和后续检查并授权访问的过程:

IUser _user_; if( validateLogin( nameFromReq, pwdFromReq, out _user
_)){ Session[“CurrentUser”] = _user_; }

1
2
3
4
5
IUser _user_;  
if( validateLogin( nameFromReq, pwdFromReq, out _user _)){  
  Session["CurrentUser"] = _user_;  
}
 

(首次鉴权)

IUser _user_ = Session[“CurrentUser”] as IUser; if( _user_ == null
){ Response.Redirect( “/login?return_uri=” + Request.Url.ToString() );
return; }

1
2
3
4
5
6
7
IUser _user_ = Session["CurrentUser"] as IUser;  
if( _user_ == null ){  
     Response.Redirect( "/login?return_uri=" +
     Request.Url.ToString() );  
     return;  
}
 

(后续检查并拒绝未识别的用户)

类似这样的技术简易方便,容易操作,因此大量被运用于很多互联网Web应用中。它在客户端和传输凭据过程中几乎没有做特殊处理,所以在这两个环节尤其要注意对用户凭据的保护。不过,随着我们对系统的要求越来越复杂,这样简易的实现方式也有一些明显的不足。比如,如果不加以封装,很容易出现在服务器应用程序代码中出现大量对用户身份的重复检查、错误的重定向等;不过最明显的问题可能是对服务器会话存储的依赖,服务器程序的会话存储往往在服务器程序重启之后丢失,因此可能会导致用户突然被登出的情况。虽然可以引入单独的会话存储程序来避免这类问题,但引入一个新的中间件就会增加系统的复杂性。

形式多样的鉴权

考虑这样一个场景:我们在电脑上登录了微软账号,电脑里的“邮件”应用能够自动同步邮件;我们登录Web版本的Outlook邮件服务,如果在邮件里发现了重要的工作安排,将其添加到日历中,很快电脑里的“日历”应用便能够将这些日程显示到Windows桌面上。

金沙js333娱乐场 4

这个场景包含了多个鉴权过程。至少涉及了对Web版本Outlook服务的鉴权,也涉及了对离线版本的邮件应用的鉴权。要能够支持同一批用户既能够在浏览器中登录,又能够在移动端或本地应用登录(例如
Windows UWP 应用程序),就需要开发出能够为两种应用程序服务的鉴权体系。

在浏览器里,我们通常假设用户不信任浏览器,用户通过与服务器建立的临时浏览器会话完成操作。会话开始时,用户被重定向到特定页面进行登录。登录完成后,用户通过持续与服务器交互来延续临时会话的时长;一旦用户一段时间不与服务器交互,则他的会话很快就会过期(被服务器强制登出)。

在移动应用中,情况有所不同。相对来说,安装在移动设备中的应用程序更受用户信任,移动设备本身的安全性也比浏览器更好。另一方面,将用户重定向到一个网页去登录的做法,并不能提供很好的用户体验——更重要的是,用户在使用移动设备时,时间是碎片化的。我们无法要求用户必须在特定时间内完成操作,也就基本没有会话的概念:我们需要找到一种能够安全地在设备中相对持久地存储用户凭据的方法,并且Web应用服务器可能需要配合这种方式来完成鉴权。此外,移动设备也不是绝对安全的,一旦设备丢失,将给用户带来安全风险。所以需要在服务器端提供一种机制来取消已登录设备的访问权限。

金沙js333娱乐场 5(图片来自:

单点登录:还是需要精心设计

以前,一般只有大型网站、向用户提供多种服务的时候(比如,网易公司运营网易门户和网易邮箱等多种服务),才会有单点登录的迫切需求。但在现代化Web系统中,无论是从业务的多元化还是从架构的服务化来考虑,对服务的划分都更细致了。

从整个企业的业务模式(例如网易门户和网易邮箱),到某项业务的具体流程(例如京东订单和京东支付),再到某个流程中的具体步骤(例如短信验证与支付扣款),“服务”这一概念越来越轻量级,于是人们不得创造了“微服务”这个新的品类词汇来拓展认知空间。

金沙js333娱乐场 6

(图片来自:http://cargocollective.com/)

在这整个的演变过程中,出于安全的需要,身份验证的需求都是一直存在的,而且粒度越来越细。以前我们更关注用户在多个子站点的统一登录体验,现在我们还需要关注用户在多个子流程中的统一登录体验,以及在多个步骤中的统一登录体验。而这些流程和步骤,很可能是独立的Web系统(微服务),也有可能是一个用户界面(独立应用),还有可能是一个第三方系统(接口集成)。

可以说,单点登录的需求有增无减,只不过当开发者对这种模式已经习以为常,不再意识到这也是一个能够专门讨论的话题。

总结

本文简要总结了在传统Web应用中,被广泛使用的几种典型用户登录时的鉴权处理流程。总体来说,在单体
Web
应用中,身份验证过程并不复杂,只要稍加管理,可以较轻松地解决用户鉴权的问题。但在传统
Web
应用中,为了解决单点登录的需求,人们也尝试了多种方式,最终仍然只有使用一些较复杂的方案才能较好地解决问题。

在现代化 Web
应用中,围绕登录这一需求,俨然已经衍生出了一个新的工程。“登录工程”
并不简单,在后续篇目中将会介绍现代化 Web 应用的典型需求及解决方法。

1 赞 4 收藏
评论

双因子鉴权:增强型登录过程

上一节中提到的“从属”关系不光可以帮助用户判断自己是否注册过一个网站,也可以帮助网站在忘记密码时进行临时认证,从而帮助用户完成新密码的设置。如果将这种从属关系用于正常登录过程中的进一步验证,就构成了双因子鉴权。

双因子鉴权要求用户在登录过程中提供两种形式不同的凭据,只有两种验证都成功才能继续操作。现代化Web应用正在越来越多地使用这种增强型验证方式来保护关键操作的安全性。例如,查看和修改个人信息,以及修改登录密码等。

相信不少人还记得QQ密码保护问题的机制,它使得盗号者即使盗取了QQ密码,在不知道密码保护问题的情况下,也无法修改现有密码,让账号拥有者得以及时挽回损失。

双因子的原理在于:两种验证因子性质不一致,冒用身份者同时获得用户这两种信息的机率十分低,从而能有效地保护账号的安全。在QQ密码保护的例子里,密码是一种每次登录时都会使用的固定文本、相对容易被盗;而密码保护问题却是不怎么频繁设置和更改的、隐秘的、个人关联性极强的,不容易被盗。

金沙js333娱乐场 7(图片来自:

现代化Web应用形式多样,设备种类繁多,场景复杂多变,而为了更好地保护用户账号的安全,很多应用开始将双因子验证作为登录过程中的鉴权步骤。而为了兼具安全和便利的特点,一些应用还要求运用一些优化策略以提高用户体验。比如,仅在用户在新的设备上登录、一段时间未登录之后的再次登录、在不常用的地点登录、修改联系信息和密码、转移账户资产等关键操作时要求双因子鉴权。

在之前一篇文章中,我聊到传统Web应用中的身份验证技术,文章中列出的一些方法将在未来很长一段时间内,为满足大量的Web应用中身份验证的需求提供了思路。在这篇文章里,我将简要介绍现代Web应用中几种典型的身份验证需求。

传统Web应用中身份验证最佳实践

上文提到的简单实用的登录技术已经可以帮助建立对用户身份验证的基本图景,在一些简单的应用场景中已经足够满足需求了。然而,用户鉴权就是有那种“你可以有很多种方法,就是不怎么优雅”
的问题。

最佳实践指的是那些经过了大量验证、被证明有用的方法。而用户鉴权的最佳实践就是使用自包含的、含有加密内容的
Cookie
作为替代凭据。其鉴权过程与上文所提到基于会话标识的技术没有什么区别,而主要区别在于不再颁发会话标识,取而代之的是一个代表身份的、经过加密的
“身份 Cookie”。

金沙js333娱乐场 8

  1. 只在鉴权请求中发送一次用户名和密码凭据
  2. 成功凭据之后,由服务器生成代表用户身份的 Cookie,发送给客户端
  3. 客户端在后续请求中携带上一步中收到的 “身份 Cookie”
  4. 服务器解密”身份 Cookie”,并对需要访问的资源予以授权

这样,我们消除了对服务器会话存储的依赖,Cookie本身就有有效期的概念,因此顺便能够轻松提供“记住登录状态”的功能。

另外,由于解密Cookie、既而检查用户身份的操作相对繁琐,工程师不得不考虑对其抽取专门的服务,最终采用了面向切面的模式对身份验证的过程进行了封装,而开发时只需要使用一些特性标注(Attribute
Annotation)对特定资源予以标记,即可轻松完成身份验证预处理。

单点登录:还是需要精心设计

以前,一般只有大型网站、向用户提供多种服务的时候(比如,网易公司运营网易门户和网易邮箱等多种服务),才会有单点登录的迫切需求。但在现代化Web系统中,无论是从业务的多元化还是从架构的服务化来考虑,对服务的划分都更细致了。

从整个企业的业务模式(例如网易门户和网易邮箱),到某项业务的具体流程(例如京东订单和京东支付),再到某个流程中的具体步骤(例如短信验证与支付扣款),“服务”这一概念越来越轻量级,于是人们不得不创造了“微服务”这个新的品类词汇来拓展认知空间。

金沙js333娱乐场 9(图片来自:

在这整个的演变过程中,出于安全的需要,身份验证的需求都是一直存在的,而且粒度越来越细。以前我们更关注用户在多个子站点的统一登录体验,现在我们还需要关注用户在多个子流程中的统一登录体验,以及在多个步骤中的统一登录体验。而这些流程和步骤,很可能是独立的Web系统(微服务),也有可能是一个用户界面(独立应用),还有可能是一个第三方系统(接口集成)。

可以说,单点登录的需求有增无减,只不过当开发者对这种模式已经习以为常,不再意识到这也是一个能够专门讨论的话题。

形式多样的鉴权

考虑这样一个场景:我们在电脑上登录了微软账号,就可以使用Outlook邮件服务了,同时电脑里的“邮件”应用能够自动同步邮件;我们登录Web版本的Outlook邮件服务,如果在邮件里发现了重要的工作安排,将其添加到日历中,很快电脑里的“日历”应用便能够将这些日程显示到Windows桌面上。

金沙js333娱乐场 10

这个场景包含了多个鉴权过程。至少涉及了对Web版本Outlook服务的鉴权,也涉及了对离线版本的邮件应用的鉴权。要能够支持同一批用户既能够在浏览器中登录,又能够在移动端或本地应用登录(例如
Windows UWP 应用程序),就需要开发出能够为两种应用程序服务的鉴权体系。

在浏览器里,我们通常假设用户不信任浏览器,用户通过与服务器建立的临时浏览器会话完成操作。会话开始时,用户被重定向到特定页面进行登录。登录完成后,用户通过持续与服务器交互来延续临时会话的时长;一旦用户一段时间不与服务器交互,则他的会话很快就会过期(被服务器强制登出)。

在移动应用中,情况有所不同。相对来说,安装在移动设备中的应用程序更受用户信任,移动设备本身的安全性也比浏览器更好。另一方面,将用户重定向到一个网页去登录的做法,并不能提供很好的用户体验——更重要的是,用户在使用移动设备时,时间是碎片化的。我们无法要求用户必须在特定时间内完成操作,也就基本没有会话的概念:我们需要找到一种能够安全地在设备中相对持久地存储用户凭据的方法,并且Web应用服务器可能需要配合这种方式来完成鉴权。此外,移动设备也不是绝对安全的,一旦设备丢失,将给用户带来安全风险。所以需要在服务器端提供一种机制来取消已登录设备的访问权限。

金沙js333娱乐场 11

(图片来自:http://docs.identityserver.io/en/release/intro/big\_picture.html)

传统 Web 应用中的身份验证技术

2016/12/13 · 基础技术 ·
WEB,
身份验证

本文作者: 金沙js333娱乐场,伯乐在线 –
ThoughtWorks
。未经作者许可,禁止转载!
欢迎加入伯乐在线 专栏作者。

标题中的 “传统Web应用”
这一说法并没有什么官方定义,只是为了与“现代化Web应用”做比较而自拟的一个概念。所谓“现代化Web应用”指的是那些基于分布式架构思想设计的,面向多个端提供稳定可靠的高可用服务,并且在需要时能够横向扩展的Web应用。相对而言,传统Web应用则主要是直接面向PC用户的Web应用程序,采用单体架构较多,也可能在内部采用SOA的分布式运算技术。

一直以来,传统Web应用为构成互联网发挥了重要作用。因此传统Web应用中的身份验证技术经过几代的发展,已经解决了不少实际问题,并最终沉淀了一些实践模式。

金沙js333娱乐场 12

在讲述多种身份鉴权技术之前,要强调一点:在构建互联网Web应用过程中,无论使用哪种技术,在传输用户名和密码时,请一定要采用安全连接模式。因为无论采用何种鉴权模型,都无法保护用户凭据在传输过程中不被窃取。

发表评论

电子邮件地址不会被公开。 必填项已用*标注