【问题标题】:Which information gets sent in each API request using OIDC使用 OIDC 在每个 API 请求中发送哪些信息
【发布时间】:2017-12-11 23:34:40
【问题描述】:

我正在编写一个 API 后端,我想使用 OpenID Connect (OIDC) 来保护它。我一直在阅读文档,但我仍然有点困惑适用于每个 API 请求的流程。 Open ID Connect 代码流似乎是: 作为一次性过程,我很满意。我的后端 API 在 HTTP 标头中看到授权代码,并向授权服务器发送请求以获取 id 令牌。假设验证成功,请求的数据将在 API 响应中返回。

但是假设同一个用户会向这个 API 发出大量请求,那么后续请求会发生什么?在这种机制中是否创建了某种会话?我会继续收到相同的授权码吗?我是否必须继续将这些反向通道请求发送到授权服务器?

或者我什至应该将 JWT id 令牌作为 cookie 输出?通过这种方式,我可以在未来的请求中返回自包含的 id 令牌,而无需服务器端会话或进一步的往返。

【问题讨论】:

    标签: session openid-connect


    【解决方案1】:

    我一直在阅读文档,但我仍然有点困惑 流程适用于每个 API 请求

    API 不应该遵循 OpenID 连接协议。应该由客户来做。

    我的后端 API 在 HTTP 标头中看到授权代码,并且 向授权服务器发送请求以获取 id 令牌。 假设这验证 OK,请求的数据在 API 中返回 回应。

    授权代码必须由客户端应用程序使用,而不是由 API 端点使用。此外,授权代码绝不能暴露给其他实体。

    您应该使用随 OpenID Connect 发送的 id 令牌来验证来自您的客户端应用程序的最终用户。要访问 API,您应该使用访问令牌。

    API端点做什么?

    我认为这就是你挣扎的地方。您的客户端应用程序应发送有效的访问令牌以访问 API 端点。从 API 端点,您可以使用 OAuth 2.0 自省端点来验证令牌。

    RFC7662 - OAuth 2.0 Token Introspection

    本规范定义了一个允许授权的协议 受保护的资源查询授权服务器以确定 给定令牌的元数据集,由 OAuth 2.0 客户端。

    请注意,OpenID Connect 建立在 OAuth 2.0 之上。这意味着您可以使用 OAuth 2.0 中定义的任何内容,包括自省端点。使用此端点验证访问令牌的有效性。

    如果您需要最终用户详细信息怎么办?

    OpenID Connect 定义了一个用户信息端点

    User info endpoint

    UserInfo 端点是一个 OAuth 2.0 受保护资源,它返回有关经过身份验证的最终用户的声明。为了获得有关最终用户的请求声明,客户端使用通过 OpenID Connect 身份验证获得的访问令牌向 UserInfo 端点发出请求。这些声明通常由一个 JSON 对象表示,该对象包含声明的名称和值对集合。

    在这里,您还可以使用访问令牌从该端点获取用户信息。响应将让您知道该令牌被发给的最终用户。

    根据您的特定 API 要求,您可以进行令牌自省或从用户信息端点获取用户信息。完成后,您可以继续验证会话。如果您需要所有可用信息,您可以同时使用这两个端点。

    或者(而不是会话)您的 API 可以维护访问令牌缓存。这将消除在每个 API 调用中验证令牌的需要。但请注意,令牌有过期时间。如果您选择此解决方案,则必须考虑令牌过期问题。

    p.s - 客户端与资源服务器

    在 OpenID Connect 和 OAuth 2.0 术语中,客户端可以是简单的网页、桌面应用程序,甚至可以是服务器托管的应用程序。

    客户 代表受保护资源请求的应用程序 资源所有者及其授权。 “客户”一词确实 不暗示任何特定的实现特征(例如, 应用程序是否在服务器、桌面或其他设备上执行 设备)。

    获取令牌并使用它们是客户端应用程序的职责。

    另一方面,资源服务器包含受保护的资源,

    资源服务器 托管受保护资源的服务器,能够接受 并使用访问令牌响应受保护的资源请求。

    资源服务器交换它的资源来访问令牌。如果我们将相同的场景与基本身份验证相匹配,访问令牌将替换使用身份验证标头发送的用户名/密码。

    【讨论】:

    • 是的,我认为这有帮助。我一直认为客户端是我的“应用程序”,包括前端和后端。所以我认为与其他回复一致,客户端纯粹是前端 Ember 应用程序。我刚刚意识到我的 IDP 管理界面的登录过程完全遵循这个模型,并且“反向通道”请求实际上只是从浏览器触发的 AJAX 请求。我认为这是让我感到困惑的地方之一。这不是我所说的反向渠道请求!
    • @asc99c 好吧,我添加了一些附加信息。您必须从 OpenID Connect/OAuth 2.0 流中释放您的 API。 API 用于将受保护的资源交换为令牌。通过这种方式,您可以使 API 灵活且可维护。此外,对于浏览器应用程序,您应该使用隐式流 - openid.net/specs/openid-connect-core-1_0.html#ImplicitFlowAuth
    • @asc99c 是的,所以如果您的客户端是浏览器应用程序,那么不应该有反向通道调用。您从授权端点获取令牌。在 OpenID Connect 中,您也将获得 id 令牌。我想你现在已经很清楚了。
    【解决方案2】:

    通常,您会使用 OAuth 2.0 而非 OpenID Connect 来保护(纯)API。访问您的 API 的客户端应获取 OAuth 2.0 访问令牌,为此它可以选择使用 OpenID Connect 来获取该令牌。这完全独立于 API,它只会看到访问令牌。 API(或 OAuth 2.0 术语中的资源服务器)未在您的图表中描述。

    【讨论】:

    • 我使用 OpenID connect 作为一站式身份验证和授权协议,而不是在 OAuth2 之上构建 ad-hoc。 API 由一个后端应用程序提供服务,该应用程序已经有自己的单独接口供我们自己的员工使用,但这不适合互联网部署
    猜你喜欢
    • 1970-01-01
    • 2015-12-04
    • 2018-02-22
    • 1970-01-01
    • 2021-05-03
    • 2020-08-13
    • 2018-08-02
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多