为什么 OAuth 设计为具有请求令牌和访问令牌?

发布于 2024-09-16 22:19:41 字数 254 浏览 5 评论 0原文

在 OAuth 协议中,服务使用者将要求用户在服务提供商域中授权请求令牌,然后将请求令牌交换为访问令牌<来自服务提供商。

我想知道为什么 OAuth 被设计为在协议中包含两个令牌。

为什么不在这个过程中只使用一个令牌呢?也就是说,用户将授权令牌,服务使用者将使用令牌从提供者处检索信息。

In the OAuth protocol, a service consumer will ask a user to authorize a request token in the service provider domain, then exchanges the request token for a access token from the service provider.

I'm wondering why OAuth is designed to have two tokens in the protocol.

Why not just use one single token in this process? That is, the user would authorize the token, and the service consumer would retrieve info from the provider with the token.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

过潦 2024-09-23 22:19:41

出于可用性和安全原因。

来自OAuth 初学者指南

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

...虽然主要是 OAuth 规范如何演变的产物,但双令牌设计提供了一些可用性和安全功能,这使得保留在规范中是值得的。 OAuth 在两个渠道上运行:用于与用户互动并请求授权的前端渠道,以及消费者用于直接与服务提供商交互的后端渠道。 通过将访问令牌限制在后台通道,令牌本身对用户是隐藏的。这允许访问令牌携带特殊含义,并且具有比请求授权时向用户公开的前通道请求令牌更大的大小,并且在某些情况下需要手动输入(移动设备或机顶盒) .

===

的骗局

请注意,这个问题是为什么我们必须在 OAuth 中“更改令牌凭据的临时凭据”?

如果初学者指南中的解释不清楚,请阅读@npdoty 的看法

For usability and security reasons.

From the Beginner’s Guide to OAuth:

https://hueniverse.com/beginners-guide-to-oauth-part-iii-security-architecture-e9394f5263b5

... While mostly an artifact of how the OAuth specification evolved, the two-Token design offers some usability and security features which made it worthwhile to stay in the specification. OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provider. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered (mobile device or set-top box).

===

Note that this question is a dupe of

Why must we "change temporary credentials for token credentials" in OAuth?

If the explanation from the Beginner’s Guide isn't clear, then go read @npdoty's take on it .

娇纵 2024-09-23 22:19:41

来自官方 OAuth 1.0 指南

OAuth 协议使网站或
应用程序(消费者)访问
来自 Web 服务的受保护资源
(服务提供商)通过 API,无需
要求用户披露他们的
服务提供商凭据
消费者。更一般地说,OAuth
创建一个可自由实现的
API通用方法
身份验证。

一个示例用例允许
打印服务 Printer.example.com
(消费者),访问私有
存储在 photos.example.net 上的照片
(服务提供商)没有
要求用户提供他们的
photos.example.net 凭证
Printer.example.com。

OAuth 不需要特定用户
界面或交互模式,也不
它是否指定服务提供商如何
对用户进行身份验证,使
协议非常适合案例
身份验证凭据在哪里
消费者无法使用,例如
使用 OpenID。

OAuth 旨在统一体验和
委托网络的实施
服务认证变成单一的,
社区驱动的协议。开放认证
建立在现有协议和最佳协议的基础上
已独立实践
由各种网站实施。一个
开放标准,得到大型和
小型提供商同样提倡
一致且值得信赖的体验
应用程序开发人员和
这些应用程序的用户。

总而言之,用户基本上为 OAuth 请求令牌提供用户名和密码。您向想要使用 OAuth 连接到某些内容的服务提供请求令牌,他们会收到访问令牌。这使得服务永远不会看到/使用用户名和密码。

From The Official OAuth 1.0 Guide

The OAuth protocol enables websites or
applications (Consumers) to access
Protected Resources from a web service
(Service Provider) via an API, without
requiring Users to disclose their
Service Provider credentials to the
Consumers. More generally, OAuth
creates a freely-implementable and
generic methodology for API
authentication.

An example use case is allowing
printing service printer.example.com
(the Consumer), to access private
photos stored on photos.example.net
(the Service Provider) without
requiring Users to provide their
photos.example.net credentials to
printer.example.com.

OAuth does not require a specific user
interface or interaction pattern, nor
does it specify how Service Providers
authenticate Users, making the
protocol ideally suited for cases
where authentication credentials are
unavailable to the Consumer, such as
with OpenID.

OAuth aims to unify the experience and
implementation of delegated web
service authentication into a single,
community-driven protocol. OAuth
builds on existing protocols and best
practices that have been independently
implemented by various websites. An
open standard, supported by large and
small providers alike, promotes a
consistent and trusted experience for
both application developers and the
users of those applications.

To sum up what that said basically the user gives a username and password to for an OAuth request token. You give the service that wants to connect to something using OAuth the request token and they receive the access token. This makes it so that the service never sees/uses the username and password.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文