OAuth：/oauth/check_token 端点 URI 是标准吗？它与 /introspect 端点有何不同？

Question

我正在考虑将当前使用现已弃用的

spring-security-oauth2

的现有应用程序替换为新的

spring-authorization-server

。我知道两个项目之间的授权没有迁移路径，如下所示：https://github.com/spring-projects/spring-security/wiki/OAuth-2.0-Migration-Guide

无论如何，我正在使用已弃用的

spring-security-oauth2

查看现有应用程序上调用的端点，并且我发现了一个名为

oauth/check_token

的端点：

https://github.com/spring-attic/spring-security-oauth/blob/main/spring-security-oauth2/src/main/java/org/springframework/security/oauth2/provider/endpoint/CheckTokenEndpoint。 java#L77

    @RequestMapping(value = "/oauth/check_token", method = RequestMethod.POST)
    @ResponseBody
    public Map<String, ?> checkToken(@RequestParam("token") String value) {

仔细检查后，这个

oauth/check_token

端点 URI :

• 新版似乎不可用

  spring-authorization-server

• 这个

  oauth/check_token

  端点URI似乎根本不是OAuth2框架中定义的标准。
• 但是，旧版

  oauth/check_token

  的响应负载与

  /introspection

  端点类似/相同，定义如下：https://datatracker.ietf.org/doc/html/rfc7662

所以我的问题是：

• oauth/check_token

  曾经是一个标准吗？我在 RFC 中找不到对此端点的任何引用。
• 如果它不是标准，为什么旧的

  spring-security-oauth2

  没有实现令牌内省 RFC-7662 ？

由于旧项目已被弃用，这个问题似乎无关紧要/没有实际意义。只是想了解其背后的历史。

Answer 1

OAuth（开放授权）是一个授权框架，允许第三方应用程序访问用户的资源而不暴露其凭据。

它定义了用于保护 API 访问的各种端点和机制。

/oauth/check_token 和 /introspect 端点分别与令牌验证和内省相关，但它们的用途略有不同。

/oauth/check_token 端点：

/oauth/check_token 端点不是标准 OAuth 2.0 端点。它是有时由 OAuth 令牌提供商针对特定用例实现的端点。

其主要目的是允许资源服务器（API）检查授权服务器颁发的访问令牌的有效性和状态。

资源服务器可以向此端点发送令牌，以确定它是否仍然有效、尚未过期以及它是否与所需的范围关联。

响应通常包括有关令牌有效性和相关元数据的信息。

/内省端点：

另一方面，/introspect 端点是在 OAuth 2.0 令牌自省 RFC 7662 中定义的，被视为标准 OAuth 2.0 功能。

其主要目的是为资源服务器提供一种标准化方法来内省（检查）OAuth 2.0 令牌的有效性和详细信息。

要使用此端点，资源服务器将令牌作为参数发送到授权服务器的 /introspect 端点。

授权服务器响应有关令牌的有效性、范围、到期时间和可能的其他元数据的信息。

差异：

虽然两个端点都具有相似的令牌验证目的，但主要区别在于标准化。 /introspect 端点在 OAuth 2.0 规范中定义，使其在 OAuth 实现中得到广泛认可和互操作。

另一方面，/oauth/check_token 端点不是标准，并且各个 OAuth 提供商的实现可能有所不同。

/introspect 端点提供了一致且定义良好的方式来验证令牌，而 /oauth/check_token 端点的行为可能因实现而异，从而导致潜在的兼容性问题。

如果您正在开发基于 OAuth 的系统并希望确保兼容性并遵守标准，建议使用 /introspect 端点（如果可用）。

总而言之，/introspect 端点是 OAuth 2.0 规范的标准部分，而 /oauth/check_token 端点不是标准的，并且可能因 OAuth 提供商而异。

选择使用哪个端点应考虑 OAuth 实现的具体要求和兼容性问题。 我的博客