登录系统
首先，我们要为“登录”做一个简要的定义，令后续的讲述更准确。之前的两篇文章有意无意地混淆了“登录”与“身份验证”的说法，因为在本篇之前，不少“传统Web应用”都将对身份的识别看作整个登录的过程，很少出现像企业应用环境中那样复杂的情景和需求。但从之前的文章中我们看到，现代Web应用对身份验证相关的需求已经向复杂化发展了。
我们有必要重新认识一下登录系统。登录指的是从识别用户身份，到允许用户访问其权限相应的资源的过程。举个例子，在网上买好了票之后去影院观影的过程就是一个典型的登录过程：我们先去取票机，输入验证码取票；接着拿到票去影厅检票进入。取票的过程即身份验证，它能够证明我们拥有这张票；而后面检票的过程，则是授权访问的过程。之所以要分成这两个过程，最直接的原因还是业务形态本身具有复杂性——如果观景过程是免费匿名的，也就免去了这些过程。
在登录的过程中，“鉴权”与“授权”是两个最关键的过程。接下来要介绍的一些技术和实践，也包含在这两个方面中。虽然现代Web应用的登录需求比较复杂，但只要处理好了鉴权和授权两个方面，其余各个方面的问题也将迎刃而解。在现代Web应用的登录工程实践中，需要结合传统Web应用的典型实践，以及一些新的思路，才能既解决好登录需求，又能符合Web的轻量级架构思路。
解析常见的登录场景
在简单的Web系统中，典型的鉴权也就是要求用户输入并比对用户名和密码的过程，而授权则是确保会话Cookie存在。而在稍微复杂的Web系统中，则需要考虑多种鉴权方式，以及多种授权场景。上一篇文章中所述的“多种登录方式”和“双因子鉴权”就是多种鉴权方式的例子。有经验的人经常调侃说，只要理解了鉴权与授权，就能清晰地理解登录系统了。不光如此，这也是安全登录系统的基础所在。
鉴权的形式丰富多彩，有传统的用户名密码对、客户端证书，有人们越来越熟悉的第三方登录、手机验证，以及新兴的扫码和指纹等方式，它们都能用于对用户的身份进行识别。在成功识别用户之后，在用户访问资源或执行操作之前，我们还需要对用户的操作进行授权。
在一些特别简单的情形中——用户一经识别，就可以无限制地访问资源、执行所有操作——系统直接对所有“已登录的人”放行。比如高速公路收费站，只要车辆有合法的号牌即可放行，不需要给驾驶员发一张用于指示“允许行驶的方向或时间”的票据。除了这类特别简单的情形之外，授权更多时候是比较复杂的工作。
在单一的传统Web应用中，授权的过程通常由会话Cookie来完成——只要服务器发现浏览器携带了对应的Cookie，即允许用户访问资源、执行操作。而在浏览器之外，例如在Web API调用、移动应用和富 Web 应用等场景中，要提供安全又不失灵活的授权方式，就需要借助令牌技术。
令牌
令牌是一个在各种介绍登录技术的文章中常被提及的概念，也是现代Web应用系统中非常关键的技术。令牌是一个非常简单的概念，它指的是在用户通过身份验证之后，为用户分配的一个临时凭证。在系统内部，各个子系统只需要以统一的方式正确识别和处理这个凭证即可完成对用户的访问和操作进行授权。在上文所提到的例子中，电影票就是一个典型的令牌。影厅门口的工作人员只需要确认来客手持印有对应场次的电影票即视为合法访问，而不需要理会客户是从何种渠道取得了电影票（比如自行购买、朋友赠予等），电影票在本场次范围内可以持续使用（比如可以中场出去休息等）、过期作废。通过电影票这样一个简单的令牌机制，电影票的出售渠道可以丰富多样，检票人员的工作却仍然简单轻松。
从这个例子也可以看出令牌并非什么神奇的机制，只是一种很常见的做法。还记得第一篇文章中所述的“自包含的Cookie”吗？那实际上就是一个令牌而已，而且在令牌中写有关于有效性的内容——正如一个电影票上会写明场次与影厅编号一样。可见，在Web安全系统中引入令牌的做法，有着与传统场合一样的妙用。在安全系统中，令牌经常用于包含安全上下文信息，例如被识别的用户信息、令牌的颁发来源、令牌本身的有效期等。另外，在必要时可以由系统废止令牌，在它下次被使用用于访问、操作时，用户被禁止。
由于令牌有这些特殊的妙用，因此安全行业对令牌标准的制定工作一直没有停止过。在现代化Web系统的演进过程中，流行的方式是选用基于Web技术的“简单”的技术来代替相对复杂、重量级的技术。典型地，比如使用JSON-RPC或REST接口代替了SOAP格式的服务调用，用微服务架构代替了SOA架构等等。而适用于Web技术的令牌标准就是Json Web Token（JWT），它规范了一种基于JSON的令牌的简单格式，可用于安全地封装安全上下文信息。
OAuth 2、Open ID Connect
令牌在广为使用的OAuth技术中被采用来完成授权的过程。OAuth是一种开放的授权模型，它规定了一种供资源拥有方与消费方之间简单又直观的交互方法，即从消费方向资源拥有方发起使用AccessToken（访问令牌）签名的HTTP请求。这种方式让消费方应用在无需（也无法）获得用户凭据的情况下，只要用户完成鉴权过程并同意消费方以自己的身份调用数据和操作，消费方就可以获得能够完成功能的访问令牌。OAuth简单的流程和自由的编程模型让它很好地满足了开放平台场景中授权第三方应用使用用户数据的需求。不少互联网公司建设开放平台，将它们的用户在其平台上的数据以 API 的形式开放给第三方应用来使用，从而让用户享受更丰富的服务。
OAuth在各个开放平台的成功使用，令更多开发者了解到它，并被它简单明确的流程所吸引。此外，OAuth协议规定的是授权模型，并不规定访问令牌的数据格式，也不限制在整个登录过程中需要使用的鉴权方法。人们很快发现，只要对OAuth进行合适的利用即可将其用于各种自有系统中的场景。例如，将 Web 服务视作资源拥有方，而将富Web应用或者移动应用视作消费方应用，就与开放平台的场景完全吻合。
另一个大量实践的场景是基于OAuth的单点登录。OAuth并没有对鉴权的部分做规定，也不要求在握手交互过程中包含用户的身份信息，因此它并不适合作为单点登录系统来使用。然而，由于OAuth的流程中隐含了鉴权的步骤，因而仍然有不少开发者将这一鉴权的步骤用作单点登录系统，这也俨然衍生成为一种实践模式。更有人将这个实践进行了标准化，它就是Open ID Connect——基于OAuth的身份上下文协议，通过它即可以JWT的形式安全地在多个应用中共享用户身份。接下来，只要让鉴权服务器支持较长的会话时间，就可以利用OAuth为多个业务系统提供单点登录功能了。
我们还没有讨论OAuth对鉴权系统的影响。实际上，OAuth对鉴权系统没有影响，在它的框架内，只是假设已经存在了一种可用于识别用户的有效机制，而这种机制具体是怎么工作的，OAuth并不关心。因此我们既可以使用用户名密码（大多数开放平台提供商都是这种方式），也可以使用扫码登录来识别用户，更可以提供诸如“记住密码”，或者双因子验证等其他功能。
汇总
上面罗列了大量术语和解释，那么具体到一个典型的Web系统中，又应该如何对安全系统进行设计呢？综合这些技术，从端到云，从Web门户到内部服务，本文给出如下架构方案建议：
推荐为整个应用的所有系统、子系统都部署全程的HTTPS，如果出于性能和成本考虑做不到，那么至少要保证在用户或设备直接访问的Web应用中全程使用HTTPS。
用不同的系统分别用作身份和登录，以及业务服务。当用户登录成功之后，使用OpenID Connect向业务系统颁发JWT格式的访问令牌和身份信息。如果需要，登录系统可以提供多种登录方式，或者双因子登录等增强功能。作为安全令牌服务（STS），它还负责颁发、刷新、验证和取消令牌的操作。在身份验证的整个流程的每一个步骤，都使用OAuth及JWT中内置的机制来验证数据的来源方是可信的：登录系统要确保登录请求来自受认可的业务应用，而业务在获得令牌之后也需要验证令牌的有效性。
在Web页面应用中，应该申请时效较短的令牌。将获取到的令牌向客户端页面中以httponly的方式写入会话Cookie，以用于后续请求的授权；在后绪请求到达时，验证请求中所携带的令牌，并延长其时效。基于JWT自包含的特性，辅以完备的签名认证，Web 应用无需额外地维护会话状态。
在富客户端Web应用（单页应用），或者移动端、客户端应用中，可按照应用业务形态申请时效较长的令牌，或者用较短时效的令牌、配合专用的刷新令牌使用。
在Web应用的子系统之间，调用其他子服务时，可灵活使用“应用程序身份”（如果该服务完全不直接对用户提供调用），或者将用户传入的令牌直接传递到受调用的服务，以这种方式进行授权。各个业务系统可结合基于角色的访问控制（RBAC）开发自有专用权限系统。
作为工程师，我们不免会考虑，既然登录系统的需求可能如此复杂，而大家面临的需求在很多时候又是如此类似，那么有没有什么现成（Out of Box）的解决方案呢？自然是有的。IdentityServer是一个完整的开发框架，提供了普通登录到OAuth和Open ID Connect的完整实现；Open AM是一个开源的单点登录与访问管理软件平台；而Microsoft Azure AD和AWS IAM则是公有云上的身份服务。几乎在各个层次都有现成的方案可用。使用现成的产品和服务，能够极大地缩减开发成本，尤其为创业团队快速构建产品和灵活变化提供更有力的保障。
本文简单解释了登录过程中所涉及的基本原理，以及现代Web应用中用于身份验证的几种实用技术，希望为您在开发身份验证系统时提供帮助。现代Web应用的身份验证需求多变，应用本身的结构也比传统的Web应用更复杂，需要架构师在明确了登录系统的基本原理的基础之上，灵活利用各项技术的优势，恰到好处地解决问题。
