Internet建立在HTTP协议之上,HTTP协议很简单,因为它很受欢迎,但HTTP协议是无状态的(通信平面上的虚拟电路比数据报要昂贵得多),所以人们已经提出了各种方法来跟踪用户。 ,包括cookie /会话机制,令牌,flash跨浏览器cookie,甚至是浏览器指纹。
作者:林宁来源:ThoughtWorks洞察力| 2019-03-27 15: 51收藏分享
在采访一些互联网公司时,采访者经常会问这样一个问题:
“如果禁用浏览器cookie,如何实现用户跟踪和身份验证?”
不幸的是,仍然有大量的候选人回答了问题,无法理解cookie和会话之间的区别。工作中还有一个令人惊讶的现实例子:将本地存储中的用户ID存储为令牌,因为他们声称向后弃用cookie;需要由服务器API提供的移动项目客户端模拟cookie以在浏览器中使用像ajax这样的API。
Internet建立在HTTP协议之上,HTTP协议很简单,因为它很受欢迎,但HTTP协议是无状态的(通信平面上的虚拟电路比数据报要昂贵得多),所以人们已经提出了各种方法来跟踪用户。 ,包括cookie /会话机制,令牌,flash跨浏览器cookie,甚至是浏览器指纹。
隐藏每个地方的用户身份(浏览器指纹技术甚至不需要存储介质)
关于使用弹簧安全等特定技术的信息很多。本文不打算编写框架和代码的特定实现。我们将讨论认证和许可之间的差异,然后介绍业界广泛采用的一些技术,最后讨论如何为API构建选择正确的认证方法。
认证,授权,凭证
首先,身份验证和授权是两个不同的概念。为了使我们的API更安全并且设计清晰,有必要了解身份验证和授权之间的区别。它们在英语中也是不同的词。
身份验证是身份验证,它指的是当前用户的身份。当用户登录时,系统可以跟踪他的身份并根据相应的业务逻辑进行操作。即使用户未登录,大多数系统也会像访客或匿名用户一样跟踪他的身份。认证技术解决了“我是谁?”的问题。授权是不同的。授权是授权。它指的是允许哪种身份访问某些资源,并在获取用户身份后继续检查用户的权限。单个系统授权通常通过身份验证完成,但在开放API的多系统体系结构下,授权可以由不同的系统完成,例如OAuth。授权技术是“我能做什么?”的解决方案。
实施身份验证和授权的基础是需要一种媒介来标记访问者的身份或权利。在现实生活中,每个人都需要身份证才能进入他们的银行账户,结婚并申请养老保险。它是认证证书;在古代的军事活动中,皇帝会给战争将军发布士兵,而下级将军不关心持有士兵的人,只需要执行对应士兵的命令。在Internet世界中,服务器向每个访问者发出会话ID并将其存储在cookie中。这是一种凭证技术。数字凭证还显示在所有方面,SSH登录密钥,JWT令牌,一次性密码等。
用户帐户不一定是存储在数据库中的表。在某些企业IT系统中,对帐户管理和权限有更多要求。因此,帐户技术可以帮助我们以不同方式管理用户帐户,并能够在不同系统之间共享帐户。例如,Microsoft的Active Directory(AD),以及简单目录访问协议(LDAP),甚至是区块链技术。
另一个重要概念是访问控制策略(AC)。如果我们需要将资源的权限划分为非常精细的粒度,我们必须考虑用户的身份来访问受限资源,选择是基于访问控制列表(ACL)还是基于用户角色的访问控制(RBAC)或其他访问控制策略。
在流行的技术和框架中,这些概念不能孤立地实现,因此在实际使用这些技术时,人们经常讨论OAuth2是认证还是授权的概念。为了便于理解,我在本文末尾附上了常用技术和概念的词汇表。下面我将介绍API开发中常用的几种身份验证和授权技术:HTTP Basic AU身份验证,HAMC,OAuth2和凭证技术JWT令牌。
HTTP基本身份验证
您必须使用此方法,但您不一定知道它是什么。不久前,当您访问家庭路由器的管理界面时,您经常会看到一个浏览器弹出窗口,要求您输入用户密码。在此背后,当用户输入用户名和密码时,浏览器会为您执行非常简单的操作:
合并用户名和密码,然后组合base64编码
向编码字符串添加Basic前缀,然后使用名称Authorization设置标题头
API还可以非常简单地提供HTTP基本身份验证身份验证,因此客户端可以通过Base64轻松传输用户名和密码。:
使用冒号连接用户名和密码,例如用户名: abc123456
为防止用户名或密码中的字符超出ASCII代码范围,建议使用UTF-8编码。
对上面的字符串使用Base 64编码,例如dXNlcm5hbWU6YWJjMTIzNDU2
将“Basic + encoded string”添加到HTTP请求标头,即:Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l
这种方法实现起来非常简单,并且在很多场景中使用。当然,缺点是显而易见的。 Base64只能被称为编码,而不是加密(事实上,不需要配置密钥的客户端没有任何可靠的加密,我们依赖于TSL协议)。这种方法的致命弱点是,如果以明文形式传输,编码密码很容易在网络传输中泄漏。如果密码未过期,则只能通过更改密码来修改密码。
HMAC(AK/SK)认证
当我们停靠一些PASS平台和支付平台时,我们将需要预生成访问密钥(AK)和安全密钥(SK),然后通过签名完成身份验证请求,这样可以避免安全密钥的传输,并且在这种情况下,签名只允许使用一次,避免重放攻击。
这种基于AK/SK的认证方法主要通过使用基于散列的消息认证码(基于哈希的消息认证码)来实现,因此有许多地方称为HMAC认证,实际上并不十分准确。 HMAC仅使用具有键值的哈希算法来生成消息摘要,其在设计API时具有不同的实现。
HMAC在认证设计中用作凭证生成算法作为网络通信,避免在网络中传输密码等敏感信息。基本流程如下:
客户端需要在认证服务器中预先设置访问密钥(AK或应用程序ID)和安全密钥(SK)。在调用API时,客户端需要自然地对参数和访问密钥进行排序,并使用安全密钥生成其他参数。
服务器根据预先设置的安全密钥执行相同的摘要计算,并要求结果相同。
请注意,安全密钥无法通过网络传输并存储在不受信任的位置(浏览器等)