3

为什么在另一个基于 OAuth 的协议上使用提议的OpenID OAuth 扩展?

发现似乎不是一个功能。尽管消费者只需要一个声明的标识符来启动身份验证过程,但任何授权仍然需要消费者知道访问令牌 URL、签名方法,并与提供者共享密钥/秘密。

一个好处是有一种特定的方式来请求特定的授权,即身份验证请求的 openid.oauth.scope 参数。这样做的一个具体好处是,仅为消费者的利益而没有可验证令牌的身份验证是免费定义的,并且可以在无需担心跟踪未完成令牌或它们可能需要的资源的情况下执行。

是否有用于指定要请求的范围的替代方法的示例,可能在 OpenID 发现中使用某些东西?或者这可以在 OAuth 过程之前通过某种 REST 导航有效地处理,其中通过解释从众所周知的 URL 开始的超文本来发现特定于所需范围的几个请求令牌 URL 之一?

我正在研究具有多个授权范围的委托身份验证和授权系统,其中范围与不同的交互相关。换句话说,消费者需要告诉提供者哪些范围应该呈现给用户以进行授权。

4

1 回答 1

6

与标准 OAuth 相比,OpenID+OAuth 扩展确实只有一个显着优势:

如果您需要对用户进行身份验证访问用户的私人数据,并且OpenID 提供者恰好也是 OAuth 服务提供者(用户使用保存其私人数据的同一服务进行身份验证),那么该扩展将帮助用户刚刚一个重定向到 OP+SP 而不是两个单独的。对于用户来说,这是一个巨大的可用性胜利——如果他碰巧使用他的 SP 进行身份验证。

支持扩展的风险在于充分支持 OP 和 SP 不是同一实体的用户(您不想说您将支持扩展,然后无意中锁定了 OP 不是其 SP 的用户)。

记住你真正需要知道的。如果您只想访问用户的私人数据,但并不真正关心与您交互的用户是谁,请仅使用 OAuth。例如,如果您只是下载他的照片以提供照片打印服务,或者如果您已经为该用户提供了非 OpenID 帐户,则用户没有理由通过 OpenID 放弃他的身份。

于 2009-09-04T21:36:54.587 回答