登录工程：现代Web应用中的身份验证技术(2)

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应用更复杂，需要架构师在明确了登录系统的基本原理的基础之上，灵活利用各项技术的优势，恰到好处地解决问题。

登录工程：现代Web应用中的身份验证技术(2)
文章转载链接：http://zmt.designcto.com/index.html/2002.html
想了解更多资讯欢迎进入自媒体联盟官方媒体，自媒体联盟涵盖网络自媒体,网络新媒体,自媒体网站,新媒体网站,媒体发布,媒体投放,媒体平台！