每个集成了第三方 API 的开发人员都碰到了同一堵墙:文档说 "使用基本授权进行身份验证,"您将密钥和秘密粘贴到请求中,服务器会用平面进行回答 401 Unauthorized and no hinted about why。十分之九的凭据被编码略有错误,错误中没有任何东西可以告诉你,我已经构建并消耗了足够的跨WordPress插件和Laravel后端的API,正是在这上面浪费了令人尴尬的时间,所以我放了一个 基本的作者生成器 上 Toolz.dev that每次都正确构建头,需要检查时解码一个返回,这是它及其背后的方案的指南。
TL;博士: HTTP 基本身份验证将用户名和密码发送为
base64(username:password)在Authorization标头。工具 基本的作者生成器 将用户名和密码转换为精确标头、准备运行的 curl 命令、获取片段和 URL 用户信息表单,并对现有令牌进行解码。它通过 UTF-8 进行编码,以便非 ASCII 凭据得以保存,当用户名包含冒号时发出警告,并完全运行客户端。
什么是 HTTP 基本身份验证?
HTTP 基本身份验证是 Web 定义的最简单的凭据方案,它是在 中指定的 RFC 7617的,它位于通用 HTTP 身份验证框架之上 RFC 7235.想法很小:为了证明你是谁,你发送一个 Authorization header 的值是单词 Basic的、空格,然后用单个冒号连接的用户名和密码的 base64 编码。
具体来说,如果您的用户名是 admin 你的密码是 secret中,客户端形成字符串 admin:secret将其编码为 UTF-8 字节,base64 对这些字节进行编码以获取 YWRtaW46c2VjcmV0,并发送:
Authorization: Basic YWRtaW46c2VjcmV0
That 就是整个方案,没有握手,没有随机数,没有散列,它的简单性正是它得以幸存的原因:两端实现是微不足道的,而对于内部工具、私有注册表、webhooks、无数的api来说,仍然是默认的捕获,而且它是一个很大的捕获,就是编码是完全可逆的,它塑造了你应该如何使用它的一切。
Base64编码和加密一样吗?
不,这是了解 Basic auth 的最重要的事情。 Base64,定义于 RFC 4648,是一种传输编码,其目的是使用一组安全的64个可打印字符来表示二进制或文本数据,因此它通过期望文本的系统发送而幸存下来,它不是密码,它不使用密钥,反转它需要一步就能看到的人 YWRtaW46c2VjcmV0 可以解码回 admin:secret 立即,这就是该工具's解码模式的作用。
Basic 身份验证本身提供零机密性,凭据在清晰中有效发送,仅仅是披着薄薄的伪装,这就是为什么 Basic auth 的一个不可协商规则是它必须只通过 HTTPS TLS 加密整个请求,包括 Authorization header,所以 base64 凭据在传输中受到保护。通过普通的 HTTP 发送基本 auth,并且您已将密码发布给网络路径上的任何人。
我费力地阐述这一点是因为 base64 步骤愚弄人们,让他们认为凭据以某种有意义的方式被扰乱了。事实并非如此。对待 base64 令牌时,您会对原始密码同样小心,因为它们是微不足道的互换的 数据隐私在线工具 guide 涵盖了为什么此工具在您的浏览器而不是服务器上进行编码,对于实时凭据来说,这是全部意义。
Basic auth 标头是如何一步一步构建的?
构造是四个小步骤,如果其中任何一个稍微错误,就会产生一个默默失败的凭据:
- 与冒号连接。 形成字符串
username:password.冒号是分隔符。 - 编码为 UTF-8。 UTF-8 将该字符串转换为字节。这对于任何非 ASCII 字符都很重要。
- Base64- 对字节进行编码。 应用标准 base64 来生成令牌。
- 前缀为
Basic。 最终标头值为Basic接下来是令牌。
的 生成器 do all four,并把完成的头交给你,它还会产生你实际粘贴到终端或代码库中的表单:使用 the 的 curl 命令 -u flag,一个带有显式的卷曲命令 -H 'Authorization: Basic ...' header、取取片段、自身裸露的令牌以及 URL 用户信息表单 https://user:pass@host.不同的任务想要不同的形式,而用手重新打底 64 正是错误蔓延的地方。
为什么用户名比密码更重要?
方案中有一种不对称性,它不断地绊倒人们,它直接来自第一步。凭证在上面被拆分 第一 colon。that 表示用户名不能包含冒号,因为服务器会读取用户名中的第一个冒号作为边界,并将其余部分交给密码字段。相比之下,密码可以包含任意数量的冒号,因为第一个冒号之后的所有内容都是密码。
RFC 7617 直接说明了这一点:用户 ID 不得包含冒号,这很容易在没有注意到的情况下被违反,特别是当用户名本身是像 API 密钥或电子邮件形状的标识符这样的结构化,恰好包含冒号时,生成器会准确地监视这一点,并在用户名包含冒号时警告您,因为生成的凭据会以错误的位置进行拆分来解码,并生成一个 401,让你对原因没有任何线索。
这是表格中的规则,因为它值得明确。
| 场 | 可能含有结肠? | 理由 |
|---|---|---|
| 用户名 | 否 | 第一个冒号是分隔符 |
| 密码 | 是的 | 第一个冒号之后的所有内容都是密码 |
我在野外调试了这个确切的故障,其中一个服务发布了 API "用户名",偶尔包含一个冒号,集成对大多数客户都有效,但神秘地失败了几个工具's 警告本来可以保存当天下午。
UTF-8编码为什么很重要?
All-ASCII用户名和密码,编码步骤是不可见的;每个字符都是一个字节,base64做它的事情,当一个凭证包含一个重音字母,一个非拉丁文字或表情符号的那一刻,字节编码就变得决定性了,RFC 7617推荐UTF-8正是为了让客户端和服务器就这些字符的字节达成一致。
假设一个字符是一个字节或依赖于具有遗留行为的浏览器 API 的朴素编码器将会损坏 café 或 пароль 成错误的字节,而且它产生的base64令牌将无法匹配一个合规服务器从同一个凭据计算出来的结果是另一个静音401,这个生成器用手将凭据编码在utf-8上,所以密码像 café:naïve RFC 7617客户端将发送的字节精确产生,解码侧忠实地反转它,如果你曾经有一个为一个队友工作的凭据,而不是另一个队友,编码不一致的非ASCII字符是主要嫌疑人。
如何解码 Basic auth 令牌?
因为编码是可逆的,所以检查凭据就像生成凭据一样简单。拿后面的一部分 Basic ,base64-对其进行解码,将结果读为utf-8,并在第一个冒号上进行拆分。的 生成器's 解码模式可以做到这一点:粘贴完整的内容 Authorization: Basic ... 线,光秃秃的 Basic ... value,或者只是代币,它会向您显示它携带的用户名和密码。
这确实很有用,而不仅仅是一种好奇心。当您收到工作凭据并被要求在新环境中复制它时,解码会准确地告诉您它编码的用户名和密码,以便您可以正确设置它们。当集成失败时,解码您实际发送的令牌并将其与您的意图进行比较通常是发现错误位置的误区、错误字段或冒号的最快方法。并且它生动地提醒了上面的保密点:如果您可以轻松地解码它,那么任何通过普通 HTTP 拦截它的人都可以。
生成器与其他工具配合的位置
Basic auth 是站点上共享相同客户端、无上传模型的几个凭据和请求工具之一,当您正在检查的令牌是承载令牌而不是 Basic auth 时, JWT 解码器 从 JSON Web 令牌中读取声明。当您需要哈希而不是编码时,对于校验和或密码摘要, 哈希生成器 computes it。当你只是想对任意的 base64 进行编码或解码,而不是专门对一个凭据进行编码或解码时,the base64 转换器 处理一般情况。当您调试请求本身并想知道客户端发送了什么时, 用户代理解析器 读取用户代理标头。
为了更广泛地了解这些请求和响应实用程序如何协同工作,请 web开发人员工具包 roundup 走过一个真实的调试会话,并且 开发人员生产力工具 guide 涵盖组装一组个人。基本的 auth 很少孤立地出现;它通常是您正在尝试工作的请求中的一行。
一个有效的例子:连接 API 集成
让我在我击中的任务中接地这一点。您正在集成第三方服务,其文档称使用 Basic auth 进行身份验证,使用 API 密钥作为用户名和空密码,或者密钥和秘密对。文档向您提供凭据,但不提供标头,并且第一个请求失败。
可靠的路径是显式构建标头并用 curl 测试它,然后再写一行应用程序代码。将密钥和秘密粘贴到 生成器,复制 curl -H form,并针对已知端点运行,如果curl成功,你的代码没有,问题就在你的代码's请求构造,而不是凭据,你刚刚把搜索空间切成两半,如果curl也失败,凭据本身就错了,解码token就准确确认哪个字段关闭了。
WordPress插件中,我经常需要从PHP调用外部API,正确的标头值就是我输入的内容 wp_remote_get 通过 Authorization header 参数。在 Laravel 中,它进入了 withHeaders HTTP客户端上调用,或者我使用框架's withBasicAuth helper,它为我构建了同一个标头,无论哪种方式,从生成器中拥有已知良好的标头值意味着我正在根据我已经证明有效的凭据调试我的请求代码,而不是同时调试两个空密码的情况,即生成器赢得其保留的地方,因为很容易忘记这一点 key: 后冒号是一个不同的、通常是正确的凭据 key 独自一人。
最后一个纪律是安全纪律。不要将生成的标头粘贴到共享文档、票证或聊天中,并且不要通过 HTTPS 以外的任何内容发送 Basic auth。令牌是密码。因为此工具在您的浏览器中进行编码,并且永远不会上传任何内容,因此生成凭据是安全的;之后它所到之处就在您身上。
我应该何时使用 Basic auth,何时不应该使用?
Basic auth 并不是每个作业都适合的工具,知道它适合哪里让你摆脱麻烦,它的强项是简单:对于服务器到服务器的调用、内部工具、私有包注册表、CI 作业以及两端已经互相信任、一切都运行在 HTTPS 上的 Webhook,很难被谈判,没有什么可以刷新的令牌,每个 HTTP 客户端和库都开箱支持,当你控制两边,连接加密后,Basic auth 就是一个完美合理的选择,已经工作了三十年。
its weaknesses up up on the moment you step out that box。因为凭据是按每个请求发送的,单个泄露的日志行或记录标头的代理永久暴露它,旋转它意味着一次性到处更改它。它没有范围的概念,所以基本凭据是全有或全无的:它不能授予只读访问权限或一个小时后过期。并且它在每次调用时都会在电线上放置一个真实的、长寿命的密码,而基于令牌的方案则可以让你分发一个短寿命的、范围狭窄的凭据。
对于面向用户的身份验证,或者任何需要范围、到期或撤销的地方,承载令牌是更好的模型,并且 JWT 解码器 是检查那些的配套工具。一个有用的经验法则: reach for Basic auth for machine to machine 调用您完全控制, 当涉及第三方、浏览器会话或权限边界时, reach for token。下表总结了交易。
| 使用基本授权 | 更喜欢代币 |
|---|---|
| 服务器到服务器 API 调用您控制 | 面向用户的会话 |
| 内部工具和私人登记处 | 范围化或只读访问 |
| CI 工作和 HTTPS 上的网络挂钩 | 必须过期的凭证 |
常见问题
什么是 HTTP 基本身份验证? HTTP Basic Authentication是一个客户端在授权头中每个请求都发送用户名和密码的方案,值是单词Basic后跟用户名的base64编码:password,定义在RFC 7617中,是服务器检查凭据的最简单方法。
Basic auth 标头是如何构建的? 用单个冒号加入用户名和密码,形成用户名:password,将该字符串编码为 UTF-8 字节,base64 对字节进行编码,并将结果前缀为 Basic。最后的标头是 Authorization: Basic 后跟该令牌。
基本身份验证安全吗? HTTPS 才可。Base64 是编码,而不是加密,因此任何能够读取头部的人都可以立即解码密码。Basic auth 本身不提供任何机密性,必须始终通过 TLS 连接发送才能安全。
用户名可以包含冒号吗? No。1冒号把用户名和密码分开,所以用户名中的冒号会被误读为边界,在错误的地方拆分凭证,密码可能包含任意数量的冒号,生成器会警告你如果用户名有一个。
如何解码 Basic auth 令牌? Basic后取base64部分,base64-解码,读成UTF-8文本,结果是用户名:密码,在第一个冒号上分割,将任意Basic auth头粘贴到工具's解码模式,即可瞬间完成。
卷曲等价物是什么? curl -u 用户名:密码 https://example.com do 相同的事情,因为 curl 从 -u 值为你构建了授权:基本标头,工具同时显示那个表单和显式的 -H 标头表单,这样你就可以复制适合哪个。
该工具是否将我的凭据发送到任何地方? No。JavaScript完全在你的浏览器中运行的编码和解码,你的用户名和密码永远不会上传到任何服务器,所以使用真实的,实时的凭据是安全的。
为什么要使用 UTF-8 编码来获取凭据? RFC 7617推荐UTF-8,使非ASCII用户名和密码在客户端和服务器之间一致编码,一个假设ASCII的编码器会损坏重音字母或非拉丁文字,产生服务器无法匹配的令牌。
