Apereo CAS OAuth2：/callbackAuthorize 端点的目的是什么？

Question

此观察与 CAS 5.3.9 和 https://apereo.github.io/cas/5.3.x/installation/OAuth-OpenId-Authentication.html 下的文档有关

没有提到 /callbackAuthorize 端点，但我在授权代码流的实现中看到了这一点。以下是请求序列（我们假设用户已经通过 CAS 身份验证）：

REQ: GET https://localhost:8145/api/profile（我的应用程序的受保护端点）

RESP：302，位置：https://cas-server:8443/cas/oauth2.0/authorize?response_type=code&client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf

请求：GET（以上网址）

RESP：302，位置：https://cas-server:8443/cas/login?service=https%3A%2F%2F172.16.238.10%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Dclient1%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A8145%252Fcallback%253Fstate%253Dcsrf%26response_type%3Dcode%26client_name%3DCasOAuthClient

请求：GET（以上网址）

RESP：302，位置：https://cas-server:8443/cas/oauth2.0/callbackAuthorize?client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf&response_type=code&client_name=CasOAuthClient&ticket=eyJhbGciOiJIUzUxMiJ9.ZXlKNmFYQWlPaUpFUlVZaUxDSmhiR2NpT2lKa2FYSWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLi5RdURKNXBJZ21zOU1LcldqSmwxMk5BLnRXb3FrSEFIRzcyY2M3U3k4cm9fR0VCS05feThtVjREazBYNU81NVNVY3g0NEFlby1Kc2R3NGszNUM3X1dDVkwuM01Pd3c5ci1mVS1QelROWDVIZkJSUQ%3D%3D.b4rotud6-2s3tOU21-Y0xclwVkVEioTLhiyRhi5VotNfjzt5vKoM2Ix9Hy_OW9KSpuGMqWsBbFOtR9K2B8E6dw&lang=de

请求：GET（以上网址）

RESP：500，内部服务器错误（cas 服务器日志显示 SSL 握手异常，可能服务器试图访问他在信任库中没有证书的 URL）

我的问题：

1) /oauth2.0/callbackAuthorize 端点是否有任何文档？

2) 为什么 CAS 服务器在 OAuth2 流中发出票证？他不应该生成访问令牌吗？

3) 参数 client_name=CasOAuthClient 来自哪里？ CAS 服务器是否尝试充当 OAuth2 客户端？

Answer 1

1) /oauth2.0/callbackAuthorize 端点是否有任何文档？

是的。有关一般设计说明，请参阅 this link，然后查看 pac4j 的工作原理。

2) 为什么 CAS 服务器在 OAuth2 流中发出票证？他不应该生成访问令牌吗？

没有。授权代码流通过访问令牌端点发出 AT。如果您需要来自授权端点的 AT，则需要使用不同的授权类型。有关更多信息，请参阅 OAUTH 规范。

3) 参数 client_name=CasOAuthClient 来自哪里？ CAS 服务器是否尝试充当 OAuth2 客户端？

来自above link，

...几乎所有 CAS 支持的协议都以相同的意图运行。给定的 CAS 部署配备了一个嵌入式“插件”，它知道如何使用 SAML2 和 CAS、OAuth2 和 CAS，或 OpenID Connect 和 CAS 或其他什么。例如，当您考虑以下启用 OAuth2 的客户端应用程序的身份验证流程时，该等式的右侧始终是 CAS：

• CAS 部署已开启 OAuth2 插件。
• 向相关的 CAS 端点提交 OAuth2 授权请求。
• OAuth2 插件验证请求并将其转换为 CAS 身份验证请求！
• 身份验证请求被路由到相关的 CAS 登录端点。
• 用户进行身份验证，然后 CAS 将流程路由回 OAuth2 插件，并为插件颁发了服务票证。
• OAuth2 插件会尝试验证该票证以检索必要的用户配置文件和属性。
• 然后，OAuth2 插件通过将配置文件和经过验证的断言转换和转换为客户端应用程序可能需要的内容，继续发出正确的 OAuth2 响应。

另外，提取from this link：

...所有协议都是 CAS 服务器的客户端，它们使用 CAS 协议与之交互。这是在请求/浏览器级别完成的，而不是通过高度定制的 web 流在内部做事，这样会相互纠缠。 CAS 中存在的协议模块对 CAS 身份验证流程/引擎的内部内部工作进行零假设。他们像对待外部 CAS 服务器一样对待它；唯一的区别是，他们直接坐在 CAS 服务器中，但他们仍然完全不知道这一事实。简单地说，在我们的示例中，SAML2 模块基本上说：“这个传入的请求需要经过身份验证。因此，我会将其路由到 CAS 服务器进行身份验证，当它返回时，我会尽我所能”。