开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

Oauth -使用pkce的授权码流-使用本地主机作为redirect_uri的安全含义

OAuth是一种开放标准的授权协议，用于授权第三方应用访问用户在某个服务提供商上的资源，而无需将用户的用户名和密码提供给第三方应用。它通过令牌（Token）的方式来实现授权，提供了一种安全且可靠的方式来进行用户身份验证和授权。

使用PKCE（Proof Key for Code Exchange）的授权码流是OAuth 2.0中的一种授权方式，用于增强授权码流程的安全性。它主要用于移动应用或单页应用等无法安全保存客户端密钥的场景。PKCE通过在授权请求中添加一个随机生成的Code Verifier，并在授权码交换过程中进行验证，防止授权码被截获后被恶意使用。

使用本地主机作为redirect_uri的安全含义是为了防止授权码泄露。在OAuth的授权码流程中，redirect_uri用于接收授权码和令牌等信息。使用本地主机作为redirect_uri可以确保授权码只能被本地应用接收，防止授权码被中间人攻击截获。

总结起来，使用PKCE的授权码流结合本地主机作为redirect_uri的安全含义是为了增强OAuth授权流程的安全性，防止授权码泄露和中间人攻击。这种方式适用于移动应用或单页应用等无法安全保存客户端密钥的场景。

腾讯云提供了一系列与OAuth相关的产品和服务，例如腾讯云API网关、腾讯云身份认证服务等，可以帮助开发者实现安全可靠的OAuth授权流程。具体产品介绍和相关链接可以参考腾讯云的官方文档：

腾讯云API网关：提供了全面的API管理和安全控制能力，可用于保护和管理OAuth授权接口。详细信息请参考：腾讯云API网关产品介绍
腾讯云身份认证服务：提供了身份认证和授权管理的解决方案，可以帮助开发者实现OAuth授权流程中的用户认证和授权管理。详细信息请参考：腾讯云身份认证服务产品介绍

相关搜索:GCIP -使用基于OIDC的外部提供程序启用授权码授予流 msal-angular包是否支持使用PKCE的授权代码流？PHP OAUTH2 "error":"invalid_grant"，“error_description”：“该客户端应用程序不能使用指定的授权码。”SSH到使用授权码作为第二步验证的跳转服务器使用Django从本地主机获取AuthException的谷歌OAuth身份验证使用Identitity4和OidcClient的授权码流的netstandard示例使用pkce的安全asp.net核心3.1授权码流使用现有Spring引导应用程序的Oauth2.0授权代码流在openId授权码流中使用最新版本的片名DLL自动兑换代码(授权码)如何使用ServiceStack构建安全的api作为OAuth2.0的资源服务器？

相关搜索:

页面内容是否对你有帮助？

有帮助

没帮助

相关·内容

从0开始构建一个Oauth2 Server服务构建服务器端应用程序

授权代码流提供了一些优于其他授权类型的好处。当用户授权该应用程序时，他们将被重定向回 URL 中带有临时代码的应用程序。应用程序将该代码交换为访问令牌。...您可以使用授权码做的唯一一件事就是发出获取访问令牌的请求。 OAuth 安全直到 2019 年，OAuth 2.0 规范只建议对移动和 JavaScript 应用程序使用PKCE扩展。...redirect_uri（可选）这redirect_uri可能是可选的，具体取决于 API，但强烈建议使用。这是您希望在授权完成后将用户重定向到的 URL。...当用户被重定向回您的应用程序时，您作为状态包含的任何值也将包含在重定向中。这使您的应用程序有机会在用户被定向到授权服务器和再次返回之间持久保存数据，例如使用状态参数作为会话密钥。...PKCE 验证者如果服务支持 Web 服务器应用程序的 PKCE，则客户端在交换授权代码时也需要包含后续 PKCE 参数。同样，请参阅单页应用程序和移动应用程序以获取使用 PKCE 扩展的完整示例。

2173 0

OAuth 2.1 带来了哪些变化

⚡ 推荐使用 Authorization Code + PKCE 根据 OAuth 2.0 安全最佳实践(Security Best Current Practices) 2.1.1 章节[1] 授权码...(Authorization Code) 模式大家都很熟悉了,也是最安全的授权流程, 那 PKCE 又是什么呢?...(client_secret), 所以在此之前, 对于公开的客户端, 只能使用隐式模式和密码模式, PKCE 就是为了解决这个问题而出现的, 另外它也可以防范授权码拦截攻击, 实际上它的原理是客户端提供一个自创建的证明给授权服务器...因为 OAuth 2.1 已经不支持第一方应用授权！现在您可以考虑使用 Authorization Code + PKCE 替换之前的密码授权模式。...的授权码流程中, 需要设置一个回调地址 redirect_uri, 如下 https://www.authorization-server.com/oauth2/authorize?

1.2K3 0

OAuth 详解什么是OAuth 2.0 隐式流, 已经不推荐了吗？

值得注意的是，与授权码流程相比，隐式流程一直被视为一种妥协。例如，规范没有提供在隐式流中返回刷新令牌的机制，因为它被认为太不安全而不允许这样做。...该规范还建议通过隐式流程发布的访问令牌的生命周期短，范围有限。 OAuth 授权代码流程更好既然可以从浏览器使用授权代码流，我们还有一个关于 JavaScript 应用程序的问题需要处理。...本机应用程序也无法安全地使用客户端密码。OAuth 工作组在几年前通过对授权代码流程的 PKCE 扩展解决了这个问题。...现有应用程序的 OAuth 2.0 隐式流程这里要记住的重要一点是，在隐式流中没有发现新的漏洞。如果您有一个使用隐式流程的现有应用程序，并不是说您的应用程序在发布此新指南后突然变得不安全。...授权代码流是否使基于浏览器的应用程序完全安全？不幸的是，没有完美的安全性。尤其是在浏览器中，应用程序总是有很多种可能受到gongji的方式。

2384 0

「应用安全」OAuth和OpenID Connect的全面比较

使用OAuth隐式授权类型的Web客户端必须仅使用https方案注册URL作为redirect_uris;他们不能使用localhost作为主机名。...本机客户端必须仅使用自定义URI方案或URL使用http：scheme注册redirect_uris，并使用localhost作为主机名。...授权服务器应该使用自定义方案拒绝授权请求，或者如果不存在所需的PKCE参数，则将环回IP作为重定向URI的一部分，返回PKCE [RFC7636]第4.4.1节中定义的错误消息。...因此，实现代码中没有任何有趣的内容。需要注意的是，想要支持PKCE的授权服务器必须将code_challenge和code_challenge_method的列添加到存储授权码的数据库表中。...一种是生成一个由43-128个字母组成的随机码验证器，使用代码验证器和代码质询方法（plain或S256）计算代码质询，并包括计算出的代码质询和代码质询方法作为值授权请求中的code_challenge

2.4K6 0

OAuth 2.0 扩展协议之 PKCE

Code + PKCE，这也是最佳实践，PKCE 最初是为移动设备应用和本地应用创建的，主要是为了减少公共客户端的授权码拦截攻击。...在经过一段时间之后， PKCE 扩展协议推出，就是为了解决公开客户端的授权安全问题。...授权码拦截攻击上面是OAuth 2.0 授权码模式的完整流程，授权码拦截攻击就是图中的C步骤发生的，也就是授权服务器返回给客户端授权码的时候，这么多步骤中为什么 C 步骤是不安全的呢?...在 OAuth 2.0 核心规范中，要求授权服务器的 anthorize endpoint 和 token endpoint 必须使用 TLS（安全传输层协议）保护，但是授权服务器携带授权码code...PKCE 协议流程 PKCE 协议本身是对 OAuth 2.0 的扩展，它和之前的授权码流程大体上是一致的，区别在于，在向授权服务器的 authorize endpoint 请求时，需要额外的

1.4K2 0

从0开始构建一个Oauth2Server服务构建服务器端应用程序

构建服务器端应用程序以下分步示例说明了将授权代码流与 PKCE 结合使用。...开始高级概述是这样的：使用应用程序的客户端 ID、重定向 URL、状态和 PKCE 代码质询参数创建登录链接用户看到授权提示并批准请求使用授权码将用户重定向回应用程序的服务器该应用程序交换访问令牌的授权代码...用户体验与注意事项为了确保授权码授予的安全，授权页面必须出现在用户熟悉的 Web 浏览器中，不得嵌入 iframe 弹出窗口或移动应用程序的嵌入式浏览器中。...如果应用程序想要使用授权码授予但不能保护其秘密（即本机移动应用程序或单页 JavaScript 应用程序），则在发出请求以交换授权码以获取访问令牌时不需要客户端秘密，并且还必须使用 PKCE。...但是，某些服务仍然不支持 PKCE，因此可能无法从单页应用程序本身执行授权流程，并且客户端 JavaScript 代码可能需要具有执行 OAuth 的配套服务器端组件流动代替。

1702 0

OAuth 详解什么是 OAuth 2.0 授权码授权类型？

什么是 OAuth 2.0 授权码授权类型？...在 OAuth 2.0 中，术语“授权类型”是指应用程序获取访问令牌的方式。OAuth 2.0 定义了几种授权类型，包括授权代码流。OAuth 2.0 扩展还可以定义新的授权类型。...每种授权类型都针对特定用例进行了优化，无论是网络应用程序、本机应用程序、无法启动网络浏览器的设备，还是服务器到服务器的应用程序。授权码流程Web 和移动应用程序使用授权码授权类型。...此代码的生命周期相对较短，通常会持续 1 到 10 分钟，具体取决于 OAuth 服务。将授权码交换为访问令牌我们即将结束流程。现在应用程序有了授权代码，它可以使用它来获取访问令牌。...如果您在移动应用程序或无法存储客户端机密的任何其他类型的应用程序中使用授权代码流，那么您还应该使用 PKCE 扩展，它可以防止授权代码可能被攻击的其他攻击拦截。

2K3 0

开发中需要知道的相关知识点:什么是 OAuth 2.0 授权码授权类型？

OAuth 详解什么是 OAuth 2.0 授权码授权类型？授权代码授权类型可能是您将遇到的最常见的 OAuth 2.0 授权类型。...在 OAuth 2.0 中，术语“授权类型”是指应用程序获取访问令牌的方式。OAuth 2.0 定义了几种授权类型，包括授权代码流。OAuth 2.0 扩展还可以定义新的授权类型。...每种授权类型都针对特定用例进行了优化，无论是网络应用程序、本机应用程序、无法启动网络浏览器的设备，还是服务器到服务器的应用程序。授权码流程 Web 和移动应用程序使用授权码授权类型。...应用程序应检查重定向中的状态是否与它最初设置的状态相匹配。这可以防止 CSRF 和其他相关安全。是code授权服务器生成的授权码。...如果您在移动应用程序或无法存储客户端机密的任何其他类型的应用程序中使用授权代码流，那么您还应该使用 PKCE 扩展，它可以防止授权代码可能被拦截。

2277 0

从0开始构建一个Oauth2Server服务单页应用

由于浏览器可以使用整个源代码，因此它们无法维护客户端机密的机密性，因此这些应用程序不使用机密。因为他们不能使用客户端密码，所以最好的选择是使用 PKCE 扩展来保护重定向中的授权代码。...您的应用应该将状态与其在初始请求中创建的状态进行比较。这有助于确保您只交换您请求的授权码，防止者使用任意或窃取的授权码重定向到您的回调 URL。...为了让单页应用程序使用授权代码流，它必须能够向授权服务器发出 POST 请求。这意味着如果授权服务器在不同的域中，服务器将需要支持适当的 CORS 标头。...如果支持 CORS 标头不是一个选项，则该服务可能会改用隐式流。在任何情况下，对于隐式流程和没有秘密的授权代码流程，服务器必须要求注册重定向 URL 以维护流程的安全性。...如果授权服务器希望允许 JavaScript 应用程序使用刷新令牌，那么它们还必须遵循“ OAuth 2.0 安全最佳当前实践”和“基于浏览器的应用程序的 OAuth 2.0 ”中概述的最佳实践，这是

1843 0

从0开始构建一个Oauth2Server服务移动和本机应用程序

因此，移动应用程序还必须使用不需要客户端密码的 OAuth 流程。当前的最佳做法是将授权流程与 PKCE 一起使用，同时启动外部浏览器，以确保本机应用程序无法修改浏览器窗口或检查内容。...如果服务不提供自己的抽象，而您必须直接使用它们的 OAuth 2.0 端点，本节介绍如何使用授权代码流和 PKCE 来与 API 交互。...您将为授权请求使用相同的参数，如服务器端应用程序中所述，包括 PKCE 参数。生成的重定向将包含临时授权代码，应用程序将使用该代码从其本机代码交换访问令牌。...该链接应构建为服务授权端点的完整 URL。客户端首先创建所谓的 PKCE“代码验证器”。这是一个加密随机字符串，使用字符A-Z、a-z、0-9和标点字符-....相反，如果用户已经在其浏览器中登录到授权服务器，则使用适当的安全浏览器 API 将为用户提供绕过在应用程序中输入其凭据的机会。

1803 0

Golang 如何实现一个 Oauth2 客户端程序

) 授权码流程 Web 和移动应用程序使用授权码授权类型。...具有以下步骤：应用程序打开浏览器请求发送到 OAuth 服务器用户看到授权提示并批准应用程序的请求授权成功后将用户重定向回应用程序并携带授权码应用程序携带访问令牌交换授权代码获得用户的许可 OAuth...应用程序应检查重定向中的状态是否与它最初设置的状态相匹配。这可以防止 CSRF 和其他相关安全。 code是授权服务器生成的授权码。...此代码的生命周期相对较短，通常会持续 1 到 10 分钟,有的 Oauth 服务只允许使用一次就会失效. 具体取决于 OAuth 服务。使用授权码交换为访问令牌我们即将结束流程。...如果您在移动应用程序或无法存储客户端机密的任何其他类型的应用程序中使用授权代码流，那么您还应该使用 PKCE 扩展，它可以防止授权代码可能的安全问题。

4024 0

从0开始构建一个Oauth2Server服务授权响应

授权码响应如果请求有效且用户同意授权请求，授权服务器将生成授权代码并将用户重定向回应用程序，将授权代码和应用程序的“状态”值添加到重定向 URL。生成授权码授权码必须在发出后不久过期。...client_id– 请求此代码的客户端 ID（或其他客户端标识符） redirect_uri– 使用的重定向 URL。...由于与拦截 HTTPS 请求相比，Attack者可以通过更多方式从 HTTP 重定向中窃取数据，因此与授权代码流相比，使用此选项的风险更大。...这提供了更高级别的安全性，因为授权服务器现在可以更加确信它不会将访问令牌泄露给Attack者。...由于这些原因以及OAuth 2.0 for Browser-Based Apps中的更多记录，建议不再使用隐式流。错误响应有两种不同类型的错误需要处理。第一种错误是开发人员在创建授权请求时做错了。

1645 0

.NET 云原生架构师训练营（Identity Server）--学习笔记

refresh token 授权许可 grant_type grant_type 授权方式授权前置条件使用通信信道说明 authorization_code/PKCE 授权码模式授权码前端/...授权码模式 007.jpg 第三方应用首先向服务提供商申请 client_id 应用唯一标识、Client_secret 密钥，用于后续获取令牌时提供身份校验申请授权码：此时要提供预分配好的 client_id...标识来源，提供 scope 标识要申请的权限，提供 redirect_uri 标识授权完毕后要回跳的第三方应用链接第一次 302 重定向：认证服务器展示登录授权页第二次 302 重定向：在用户提交授权...，认证服务器认证成功后，会分配授权码 code，并重定向回第三方应用的 redirect_uri （建议第三方应用要根据当前用户会话生成随机且唯一的 state 参数，并且收到授权码时先进行校验，避免...的不足之处 OIDC 概念 OAuth2.0 的不足之处 OAuth2.0 中的 access_token 就是酒店的房卡，谁都可以拥有房卡，有房卡就可以打开酒店的门，但是房卡上并没有当前使用房卡的用户信息

7382 0

Spring OAuth2

不过 PKCE 作为一种增强协议可以搭配 OAuth2 组合使用以提高整体安全性。...授权码模式和密码模式我们先来看授权码模式和密码模式之间的比较，大家知道，授权码模式是 OAuth2 体系安全性最高的模式，密码模式与其相比，主要差别是少了一层用户确认授权的动作，缺乏这一动作就导致在授权阶段...明确资源所有者的含义后，再根据前文的分析，毫无疑问：如果 PAPS 的 demo 应用是第三方的不可信应用，则应该采用授权码模式；如果是第一方可信应用，则可以采用密码模式，当然不怕麻烦也可以用授权码模式...此流程有两项重大变化：一是加入网关使得整个流程复杂了一些；二是网关以内使用 JWT 作为令牌。关于这两点的解读，本文不再赘述，感兴趣的同学可以参阅本人早前的文章《微服务架构下的统一身份认证和授权》。...授权码模式是最严格的，密码模式次之，客户端模式最差，因此一般情况下，授权码模式的令牌可以给其他模式使用，密码模式令牌可以给客户端模式使用，客户端模式只能自己使用。

2.3K0 0

【One by One系列】IdentityServer4（四）授权码流程

接下来我们介绍新内容,OAuth2.0叫做授权码(authorization code)，在OpenID Connect中则属于OpenId Connect Flow，称为授权码流程(Authorization...申请一个授权码，然后再用授权码获取token。...code=AUTHORIZATION_CODE “重定向至redirect_uri，且会在uri后增加授权码 ” 3.后端请求oauth/token?...，IdentityServer4是带有PKCE支持的授权码模式，后续我们会讲到，先让我们实践一下，感受一下。...cookie记录本地登录用户 options.DefaultChallengeScheme=oidc:需要用户登录，将使用OpenID Connect协议 AddCookie:添加cookies的处理器

1.9K2 0

浏览器中存储访问令牌的最佳实践

当前的最佳实践建议通过“授权码流”这一方式来获取访问令牌: 授权码流是一个两步流程，首先从用户那里收集一个授权许可——授权码，然后应用程序在后台通道中用授权码交换访问令牌。...然而，代码交换的证明密钥(Proof Key for Code Exchange， PKCE)提供了一种方法来确保公开客户端的授权码流的安全性。...为了减轻与授权码相关的风险，在使用授权码流时，始终应用PKCE。浏览器威胁跨站请求伪造(CSRF) 在跨站请求伪造(CSRF)攻击中，恶意行为者会欺骗用户通过浏览器无意中执行恶意请求。...该模式引入了一个后端组件，能够发出带有加密令牌和上述必要属性的cookie。后端组件的责任是: 作为OAuth客户端与授权服务器交互，启动用户认证并获取令牌。...它由两部分组成: OAuth代理，它处理OAuth流以从授权服务器获取令牌。 OAuth代理，它拦截对API的所有请求并将cookie转换为令牌。

1531 0

Spring OAuth2

不过 PKCE 作为一种增强协议可以搭配 OAuth2 组合使用以提高整体安全性。...授权码模式和密码模式我们先来看授权码模式和密码模式之间的比较，大家知道，授权码模式是 OAuth2 体系安全性最高的模式，密码模式与其相比，主要差别是少了一层用户确认授权的动作，缺乏这一动作就导致在授权阶段...明确资源所有者的含义后，再根据前文的分析，毫无疑问：如果 PAPS 的 demo 应用是第三方的不可信应用，则应该采用授权码模式；如果是第一方可信应用，则可以采用密码模式，当然不怕麻烦也可以用授权码模式...此流程有两项重大变化：一是加入网关使得整个流程复杂了一些；二是网关以内使用 JWT 作为令牌。关于这两点的解读，本文不再赘述，感兴趣的同学可以参阅本人早前的文章《微服务架构下的统一身份认证和授权》。...授权码模式是最严格的，密码模式次之，客户端模式最差，因此一般情况下，授权码模式的令牌可以给其他模式使用，密码模式令牌可以给客户端模式使用，客户端模式只能自己使用。

1.9K7 4

OAuth 2.1 的进化之路

不断进化的 OAuth 2.0 在 OAuth 2.0 核心规范 (RFC 6749)中, 定义了四种授权类型：授权码、隐式、密码和客户端凭据, 如下: 相信大家都很熟悉, 在 OAuth 2.0 中...,最安全也是使用最普遍的就是授权码模式, 而对于本地应用，移动应用来说, 通常会使用隐式和密码授权, 这两种本身就是不安全的, 因为这些属于公开的客户端, 本身没有能力保护客户端机密, 但是当时并没有其它好的方案...为了解决 OAuth 2.0 对公开客户端的授权安全问题, PKCE （RFC 6379）协议应运而生, 全称是 Proof Key for Code Exchange，PKCE 的原理是, 对于公共的客户端...后来，"OAuth 2.0 for Native Apps"（RFC 8252）规范发布，推荐原生应用也使用授权码 + PKCE。...在 OAuth 2.0 安全最佳实践（Security BCP）中, 弃用了隐式和密码授权，并且推荐所有的客户端都应该使用 Authorization Code + PKCE 的组合。

6452 0

从0开始构建一个Oauth2Server服务 AccessToken

资源服务器需要了解访问令牌的含义以及如何验证它，但应用程序永远不会关心理解访问令牌的含义。访问令牌在传输和存储过程中必须保密。唯一应该看到访问令牌的各方是应用程序本身、授权服务器和资源服务器。...redirect_uri（可能需要）如果重定向 URI 包含在初始授权请求中，则服务也必须在令牌请求中要求它。令牌请求中的重定向 URI 必须与生成授权代码时使用的重定向 URI 完全匹配。...或者，授权服务器可以使用 HTTP Basic Auth。从技术上讲，该规范允许授权服务器支持任何形式的客户端身份验证，并提到公钥/私钥对作为一个选项。...安全注意事项防止replay attack 如果多次使用授权代码，授权服务器必须拒绝后续请求。如果授权代码存储在数据库中，这很容易实现，因为它们可以简单地标记为已使用。...该流程不应在实践中使用。最新的OAuth 2.0 Security Best Current Practice规范实际上建议不要完全使用密码授权，并且在 OAuth 2.1 更新中将其删除。

2125 0

从五个方面入手，保障微服务应用安全

2.2 基于登录的客户端作为访问者，使用授权码许可 2.2.1 Web 应用 OAuth2.0 协议中提出前端单页Web应用可以用简单许可模式，但简单许可模式有些局限性，令牌到期就需要重新登录授权，不支持令牌刷新...本场景以微服务架构中常见的前后端分离Web应用作为示例，前端是单页应用，网关作为Web后台是服务提供端应用功能入口，也可作为OAuth2.0的客户端，让前端Web应用能借助网关实现授权码交换。...授权码上图为OAuth2.0规范标准流程图，结合此场景对应OAuth2.0中的角色，用户是资源所有者、浏览器为用户代理、网关作为被授权的客户端、IAM则为授权服务器。...基于上述风险和问题，移动App基于授权码获取访问令牌的流程需要进行优化解决，rfc规范中建议的实现方案是移动App授权流程采用使用带有PKCE支持的授权码模式。...经过PKCE改进的授权码、访问令牌交换过程示意图如下： ?

2.6K2 0

点击加载更多

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭