另外在多个业务系统中，还可能会共用用户的基本资料和偏好设置等数据。比如，类似于邮件地址这样的资料，它可以作为登录凭据，也可以作为一个基本的联系方式。如果用户在一个子系统设置了偏好语言，其他子系统则直接使用该设置即可。这样，开发一个“用户”系统的想法也就应运而生了。由于与用户的状态等基础信息的关系很紧密，登录与用户系统之间的集成是很自然的，将登录子系统直接作为这个用户系统的一部分也不失为一种不错的实践。

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

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

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

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

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

　　（图片来自：

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

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

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