小白如何建网站,wordpress oday,输入关键词搜索,wordpress官方安装主题什么是OAuth 2.0 OAuth 2.0是一个已被广泛采用的委托授权框架#xff0c;已经存在了很多年#xff0c;并且似乎已经存在。 如果您不熟悉OAuth 2.0的基本概念#xff0c;可以使用 川崎孝彦写的优秀文章 。 这只是OAuth 2.0各方的简要提醒#xff1a; 资源所有者–受保护资… 什么是OAuth 2.0 OAuth 2.0是一个已被广泛采用的委托授权框架已经存在了很多年并且似乎已经存在。 如果您不熟悉OAuth 2.0的基本概念可以使用 川崎孝彦写的优秀文章 。 这只是OAuth 2.0各方的简要提醒 资源所有者–受保护资源的所有者例如用户 客户端–想要访问受保护资源的应用程序例如服务器端Web应用程序或单页应用程序SPA 授权服务器–发行令牌的服务器 资源服务器–管理资源所有者的受保护数据的服务器 让我们浏览每个OAuth 2.0流程并讨论其用法。 客户证书授予 这是最简单的流程。 它允许客户端使用其客户端ID和客户端密钥请求访问令牌。 两者都安全地保存在客户端并在授权服务器中注册。 第一步客户端将HTTP请求发送到授权服务器包括其客户端ID和客户端密钥例如在Authorization标头中。 该请求也可以包括所请求的范围。 在响应中授权服务器发送访问令牌。 客户端使用访问令牌来调用资源服务器。 什么时候使用 如您所见没有用户参与。 建议使用“客户端凭据授予”来进行计算机到计算机的授权。 通常一个受信任的服务将调用另一个服务。 授权码授予 最常用的流程专门为可以维护其客户端机密性的服务器端应用程序而设计。 这是基于重定向的流之一。 客户端通过将资源所有者的用户代理重定向到授权服务器来启动流程。 客户端包括其客户端ID请求的范围和重定向URI。 资源所有者通过授予客户端请求的权限来授权客户端。 授权服务器将用户代理重定向回客户端使用来自点1的重定向URI。 重定向URI包含一个临时授权码作为查询参数。 客户端从授权服务器请求访问令牌。 该请求包括在上一步中收到的客户端ID客户端密码和授权代码。 如果所有内容均有效则授权服务器将返回访问令牌并可选地返回刷新令牌。 客户端使用访问令牌代表资源所有者调用资源服务器。 为什么我们需要其他授权码 为什么我们不能直接请求访问令牌 为什么首先要引入授权码 事实证明主要目标是分离公开给客户和用户代理的信息。 请注意访问令牌根本不会通过浏览器。 从客户端服务器端应用程序使用 通过用户代理转发的授权码。 浏览器有什么问题 OAuth 2.0不需要客户端服务器支持HTTPS。 因此从技术上讲可能存在无法通过SSL重定向到客户端服务器的问题。 如果发生这种情况则通过明文发送授权码。 如果有人拦截了它那么没有Client Secret还是没有用。 但是如果您直接通过HTTP发送访问令牌则可能会遭到破坏。 什么时候使用 如前所述建议对服务器端Web应用程序使用此流程。 但是近年来这种流程的变体也已用于单页和移动应用程序。 单页应用 对于单页应用程序唯一的区别是客户端SPA没有客户端密钥。 由于SPA在浏览器中运行并且其源代码是公开的因此无法在浏览器端对客户端机密保密。 这就是在上图的第4步中将授权代码交换为访问令牌而不发送客户端密钥的原因。 原生移动应用 与SPA类似本机移动应用程序被认为是公共的而不是机密的客户端。 这就是客户端机密不应该存储在移动设备中因此在请求访问令牌时不发送的原因。 没有在移动设备中实现没有客户端密钥的授权代码流可能会存在一些安全问题。 这样的问题之一是授权码可能会被攻击者拦截并交换为访问令牌。 为了减轻这种风险有一种称为代码交换证明密钥PKCE的技术。 对于每个授权请求客户端都必须创建一个称为Code Verifier的随机密钥。 授权代码请求中包含其称为Code Challenge的哈希版本。 授权服务器应将此代码质询与其生成的授权代码相关联。 稍后当为访问令牌交换授权码时客户端会将代码验证程序作为查询参数。 除了验证标准参数外授权服务器还应使用先前收到的Code Challenge验证Code Verifier。 客户端移动应用打开带有授权请求的浏览器。 授权请求包括客户端ID请求的范围重定向URI和代码质询。 授权请求发送到身份验证服务器 资源所有者授权客户。 结果授权码被返回给用户代理。 授权码被传递给客户端。 客户端应用程序将授权代码和代码验证程序以及重定向URI和客户端ID发送到授权服务器。 授权服务器将代码验证程序的哈希值与先前发送的代码质询进行比较。 如果它们匹配则将授权代码交换为访问令牌以及可选的刷新令牌 客户端使用访问令牌代表资源所有者调用资源服务器。 另外 当前的最佳实践是仅使用外部用户代理而不是嵌入式Web视图来发送对授权码的请求。 隐性补助金 它类似于“授权代码授予”但是它完全跳过了“授权代码”步骤。 客户端直接请求访问令牌而无需授权码。 此外不涉及“客户机密”。 在隐式授予中不使用刷新令牌。 重要的是要提到访问令牌以散列片段的形式在3xx重定向中返回并且永远不会从浏览器发送。 什么时候使用 它最初设计为SPA的流程。 它依赖于浏览器可能无法在其他环境中安全地实现。 但是如前所述对于SPA近年来越来越多的组织已经朝着没有客户机密而不是隐式流的授权代码流发展。 资源所有者密码凭证授予 在此流程中资源所有者将其凭据直接提交到客户端应用程序。 客户端应用程序使用该凭据直接将它们交换为访问令牌以及可选的刷新令牌。 与客户端凭据类似它不是基于重定向的流程。 资源所有者将其凭据提交到客户端应用程序。 客户端将凭据转发到授权服务器。 授权服务器返回访问令牌以及可选的刷新令牌 客户端使用访问令牌代表资源所有者调用资源服务器。 什么时候使用 资源所有者和客户端应用程序之间是否高度信任。 建议仅在无法进行其他处理时才使用它。 现在设备流扩展可以涵盖资源所有者密码凭证授予的大多数原始用例。 设备流程 这是OAuth 2.0中新增的扩展流用于覆盖设备具有Internet连接但没有浏览器或输入文字输入能力受限例如电视的情况。 在此流程中设备要求用户使用浏览器例如智能手机在设备上打开特定的URL以便进行授权。 摘要 以下是设计为在给定场景中使用的流程的快速摘要 服务器到服务器客户端凭据流 服务器端应用程序授权代码流 SPA没有客户端机密或隐式流的授权代码流 移动设备PKCE的授权码流 没有浏览器的设备设备流 翻译自: https://www.javacodegeeks.com/2019/01/right-flow-job-oauth-2-0-flow-should-use.html
