【问题标题】:Is it OK to share unencrypted ID tokens?可以共享未加密的 ID 令牌吗?
【发布时间】:2016-08-02 08:24:48
【问题描述】:

假设我有两台服务器,A 和 B。用户代理只会连接到 A(以及连接到 OpenID 提供程序,以便对 A 进行身份验证和授权)。信任 B 并仅通过 HTTPS 与 B 对话的 A 是否可以将其从 OpenID 提供者的令牌端点收到的(未加密的)ID 令牌传递给 B?

这是为了让 A 可以代表经过身份验证的用户调用 B 上的操作,由 ID 令牌表示。 B 应该能够验证用户确实已通过身份验证与 A 一起工作(通过检查 ID 令牌的 aud 受众值,以及 ID 令牌的签名以确保它没有被篡改,例如通过A)。

这被认为是好的做法吗?还是应该以其他方式完成?

另外,在这种情况下,A 是否应该在请求 ID 令牌时,将 B 的 client-id 添加到 aud 列表中?似乎这就是它的好处,尽管我不明白这一点 - 或者实际上 OpenID 授权端点会向最终用户显示受众(但肯定不是客户端 ID,这对最终用户没有任何意义)征得他们的同意?

【问题讨论】:

    标签: oauth-2.0 single-sign-on openid-connect


    【解决方案1】:

    这听起来像是一个 OAuth 用例,其中用户将使用 OpenID Connect 登录到 RP A,但随后 A 使用作为 OpenID Connect 流的一部分提供的访问令牌代表用户调用 B。

    无需传递 ID 令牌并执行诸如共享 aud 标识符甚至客户端密码之类的尴尬事情。 B 可以检查访问令牌以了解用户以及 A 是否具有适当的“范围”(权限)来调用 B。

    共享 ID 令牌不是一个好习惯,因为它们是为特定接收者准备的。

    通过在身份验证请求中包含额外请求的范围,在 OpenID Connect 流中接收到的访问令牌不仅可以与 userinfo 端点相关联。

    【讨论】:

    • B 只能使用访问令牌从 UserInfo 端点获取用户数据。但是,我希望 B 能够通过查看从 A 发送到 B 的数据来验证用户的身份,并验证用户是否同意,而无需信任 B,也无需与 OpenID 提供者进一步交互。因此,我希望将身份验证和授权详细信息从 A 发送到 B,并且这些详细信息应由 OpenID 提供者签名以供 B 验证。我会看看我是否可以修改原来的问题。
    • 访问令牌可用于调用其他 API,而不仅仅是用户信息端点,方法是让客户端请求其他范围
    • 我的错误印象是,身份验证令牌只是一些不透明的标识符,可以在 OpenID 提供者 UserInfo 端点交换实际数据,但是在完成我的作业后,身份验证令牌 a) 包含同意声明和 b) 由 OpenID 提供者签名。这就是我所需要的!我终于明白你的回答了。
    • 次要更正:身份验证令牌可能是不透明的 - 客户端应该认为它是不透明的 - 但 it does not have to be: a) The access token is an identifier that is hard to guess [...] b) The access token self-contains the authorisation information in a manner that can be verified, e.g. by encoding the authorisation information along with a signature into the token.。这个决定是由令牌端点做出的——在我的情况下,它在我的控制之下。
    • 同时我figured 我也可以将任意数据放入 ID 令牌中。我想知道,从安全和技术的角度来看,将我的授权数据放入 ID 令牌还是 Access 令牌有什么区别?
    猜你喜欢
    • 2014-07-11
    • 2017-10-27
    • 2015-04-05
    • 2021-02-19
    • 1970-01-01
    • 2020-05-02
    • 2021-06-19
    • 2016-12-17
    • 1970-01-01
    相关资源
    最近更新 更多