首页 文章

OAuth2.0和OpenID Connect令人困惑

提问于
浏览 次
3

我对使用OAuth 2.0作为授权方法和使用OpenID Connect作为身份验证方法感到困惑 .

根据我的知识 OAuth 2.0 只是一种授权方法 . 换句话说，这是请求ACCESS_TOKEN并接收此ACCESS_TOKEN的过程，如下图中黄色椭圆所示:(简化）

enter image description here

在OAuth 2.0客户端从授权服务器检索ACCESS_TOKEN之前，此服务器应验证用户是否允许它，这是OAuth 2.0不关心的身份验证过程 .

当OpenID Connect包含在混合中时，它也允许使用身份验证方法，但据我所知，OpenID Connect只是在JWT令牌中添加了一个“声明”，其中包含有关使用该服务的用户的信息，如：电子邮件，名称和其他 .

我的问题是：

  • 为什么不忽略OpenID Connect，只需在OAuth 2.0中添加更多"claims"以获取有关用户的信息？

  • 我对流程的描述是否正确？

oauth-2.0 openid-connect

3 回答

  • 3

    @sdoxee答案正确解释了事情 . 但我正在为OP的理解添加更多信息 .

    目前，许多身份提供商（例如： - Azure AD）发布基于JWT的访问令牌 . 这些JWT访问令牌确实包含有关最终用户的声明以及与JWT相关的验证详细信息（例如： - 令牌到期） . 以下是Azure AD O Auth 2 success response的链接，它将访问令牌突出显示为JWT . 另外，请参阅JWT claims以了解他们如何解释声明 . 样品如下，

    family_name：用户的姓氏或姓氏 . 应用程序可以显示此值 . given_name：用户的名字 . 应用程序可以显示此值 .

    可以考虑对访问令牌中存在的声明进行身份验证，但这并不符合协议 . 主要是声明和信息将是特定于实施者的 . 此外，通过协议定义，这两个令牌（access和id）有两个不同的受众 . ID令牌用于客户端，用于验证和身份验证 . 访问令牌适用于OAuth 2受保护的 endpoints .

    再次，当@sdoxee突出显示时，请在正确的位置使用正确的协议 . 在访问令牌中声明并不一定意味着您应该使用它们进行身份验证 .

    回复于
  • 3

    我不知道你的方法是否有效，但你可以完全自由地推出自己的身份验证 . 毕竟，这就是Facebook，GitHub和许多其他人通过定制oauth2所做的事情 . 最终有如此多的oauth2“身份验证”方法，如果你想改变你的提供者，它永远不会即插即用 . 我相信这就是为什么引入OpenID连接 - 这是一种连接和推理身份验证的常用方法，同时构建了已 Build 的oauth2模式以进行授权 . 使用OpenID连接或不...但如果你不这样做，你将重新发明轮子 .

    回复于
  • 1

    OpenID Connect不仅仅是“在JWT令牌中添加声明”，而且：

    • 它引入了一个全新的令牌（ id_token ），其语义与OAuth 2.0 access_token 完全不同，而且客户端理解的标准化格式与客户不透明的 access_token 相反 .

    • 它"twists"客户端的角色，现在成为令牌的"audience"（或：预期收件人）（即 id_token ），而 access_token 的受众仍然是远程实体（也称为资源服务器），而客户端只是"presenter"后者

    第二项是OAuth 2.0和OpenID Connect之间混淆的主要原因 .

    回复于

相关问题