身份验证与授权的区别

身份验证建立正在执行操作的是谁或什么

身份验证用来建立对某个声明身份的信心，或验证与主体关联的凭证。 NIST 身份验证定义 涵盖了多个场景下的身份验证。主体可以是一个人、一个应用程序，或一个服务账号，而不仅仅是人类用户。

API key 通常根据提供方的模型标识一个调用应用或账号。浏览器会话 cookie 可以代表一个已登录用户。仅仅因为某个值可以让服务器识别调用方，就不应把该值描述为完整的权限策略。

作为一个实用示例，设想一个内部报表服务，它接受一个服务凭证。接受该凭证可以确认请求来自报表应用。这并不能确定该应用可以读取哪个客户数据集。以安全的诊断形式记录被识别的主体，同时不要在日志和共享工件中记录实际凭证。

授权对资源上的一个操作进行评估

授权决定在适用策略下，主体是否可以执行一个被请求的操作。 NIST 授权定义 描述了访问的授予与评估。一个有用的决策包括主体、操作、资源以及任何相关上下文。

对于一个项目 API，读取项目、编辑其设置以及删除它是不同的操作。一个用户可能被允许读取一个项目、编辑另一个项目。仅有角色名称并不能解释结果，除非该角色被映射到正确的资源范围和操作。

使对象所有权显式化。如果一个端点接收到项目标识符，应解析该项目并针对该对象评估访问权限，而不是只检查调用方是否已登录。一个可预测的标识符绝不应充当权限边界。对公开项目数据的导出、附件和后台作业应用同样的规则。

凭证、会话与令牌是声明的载体

凭证或令牌携带系统要评估的信息或证明；它的存在并不能解决所有访问决策。持有者凭证需要特别注意，因为仅凭持有即可被使用。 OAuth bearer-token specification 定义了这种安全模型，并描述了与令牌相关的错误情况。

保持身份验证方案彼此独立。需要在特定请求头中提供原始密钥的 API，并不会自动变成使用 OAuth bearer token 的端点。接受 token 参数的浏览器连接，其传输层面与在 REST 请求头中发送的请求是不同的。请使用针对特定服务所记录的身份验证方法。

同时要区分认证与加密。TLS 保护的是传输过程中的通信，而认证和授权则在应用程序边界上管理身份与访问控制。一个合法的加密连接仍然可能承载未通过认证的请求，或者承载一个虽已识别身份但无权执行该操作的请求。

对每个相关请求强制执行权限

应在服务器边界对所请求资源和操作强制实施访问控制。 OWASP 授权指南 建议采用最小权限、默认拒绝，并在每个请求上验证权限。这些原则有助于防止遗漏的检查意外变成授权。

客户端界面可以为了可用性而反映权限，但隐藏控件并不能阻止直接请求。当操作通过网页界面、API、计划任务或导出程序到达时，应用相同的策略。后台处理同样需要记录在案的身份和范围。

对于多租户应用程序，要直接测试租户之间的边界。在一个工作区中具有编辑访问权限的用户，不应仅通过更改标识符就获得另一个工作区中的同等访问权限。将被拒绝的请求保留在测试集中，包括那些针对确实存在但属于其他主体的对象的请求。

凭证轮换和权限变更具有不同影响

凭证轮换会替换用于验证调用方身份的证明。权限变更会修改已被识别的调用方可以执行的操作。这两种操作解决的是不同的问题，并且根据具体实现方式的不同，它们对正在运行的会话或应用程序的影响也可能不同。

如果某个密钥被暴露，从文件中将其删除并不会使该凭证失效。请使用提供方可用的失效处理流程，并通过经批准的机密存储分发替换密钥。如果用户变更了角色，请更新授权策略，并了解活动会话或已缓存的决策在何时能观察到这一变更。

在运行记录中保留哪些应用程序使用了某个凭据，但不要在该记录中存储机密本身。这有助于在轮换期间识别受影响的部署。同样，记录某个后台作业依赖于哪些权限授予。当身份、资源范围和部署配置彼此可区分时，相比之下，一条笼统的“访问不再生效”的消息要容易得多进行排查。

将区分应用于无抓取连接

Scrapeless API 密钥用于对发往 Scrapeless 的请求进行身份验证，而产品访问权限和请求有效性仍需要单独评估。 Scrapeless API 密钥处理 说明区分了传输方式，并解释了为何已接受的密钥并不能证明每个产品请求都会成功。

为 无痕代理浏览器将包含凭据的连接 URL 视为机密。在记录该 URL 或共享诊断信息之前，请先编辑（隐藏）敏感值。遵循所选浏览器客户端文档中记录的连接方法，而不是假定每个 API 都使用相同的请求头或令牌语法。

这种区分同样适用于目标网站。调用基础设施服务的权限并不等同于通过该服务访问其上所有资源的权限。应将收集行为限制在预期的授权范围内。 API 身份验证概览 提供了更多背景信息，以及当前 Scrapeless 定价 属于能力和预算规划范畴，而不是身份验证。

在更改资源策略之前诊断身份

访问调查应确定是哪个组件做出了决策，以及它识别的是哪一个身份。检查预期凭据是否通过文档化的方案到达了预期的服务。检查经过编辑处理的响应和关联标识符，而不是发布包含机密信息的标头或连接 URL。

一旦身份得到确认，检查所请求的操作和资源范围。核实所有权、角色分配以及任何情境性限制。不要仅仅为了消除错误而授予广泛的管理访问权限。当适合进行变更时，狭义的诊断应引导出狭义的策略调整。

将失败用例与成功请求一并保留。测试缺失凭证、无效凭证、具备合法身份但缺少所需访问权限的调用方，以及拥有预期权限的调用方。这些情形可以展示身份验证和授权是否被分别强制执行。它们还能为支持团队提供一套具体的表达方式，用来解释二者的区别，而无需暴露敏感的策略细节。

结论

身份验证与授权之间的区别在于：前者是识别调用方，后者是允许执行特定操作。务必对凭据保密，在每一个相关边界上强制执行范围限定的权限，并像有意验证成功结果一样有意地测试被拒绝的结果。清晰的诊断应标明主体和资源上的决策，而不暴露用于进行身份验证的具体材料。

参考资料

• 获取并保护 Scrapeless API 密钥
• Scrapeless Agent Browser
• API 身份与凭证概念