1) Есть ли документация для конечной точки /oauth2.0/callbackAuthorize?
Да. См. эту ссылку для общих замечаний по проектированию, а затем посмотрите, как работает pac4j .
2) Почему сервер CAS выдает билет в поток OAuth2? Не должен ли он вместо этого выдать токен доступа?
Нет. Потоки кода авторизации выдают AT через конечную точку маркера доступа. Если вам нужны AT с конечной точки авторизации, вам нужно использовать другой тип предоставления. См. OAUTH spe c для получения дополнительной информации.
3) Откуда берется параметр client_name = CasOAuthClient? Сервер CAS пытается выступать в роли клиента OAuth2?
По ссылке выше ,
... почти все протоколы, поддерживаемые CAS действовать с такими же точными намерениями. Данное развертывание CAS оснащено встроенным «плагином», который знает, как говорить на SAML2 и CAS, OAuth2 и CAS или OpenID Connect и CAS или что-либо еще. Правой частью этого уравнения всегда является CAS, если в качестве примера рассмотреть следующий поток аутентификации с клиентским приложением с поддержкой OAuth2:
- В развертывании CAS включен плагин OAuth2.
- Запрос на авторизацию OAuth2 отправляется соответствующей конечной точке CAS.
- Плагин OAuth2 проверяет запрос и транслирует его в запрос аутентификации CAS!
- Запрос аутентификации маршрутизируется в соответствующую конечную точку входа в систему CAS.
- Пользователь аутентифицируется, и CAS направляет поток обратно к плагину OAuth2, выпустив служебный билет для этого плагина.
- Плагин OAuth2 пытается проверить этот билет в получить необходимый профиль пользователя и атрибуты.
- Затем плагин OAuth2 приступает к выдаче правильного ответа OAuth2 путем перевода и преобразования профиля и проверенных утверждений в то, что может понадобиться клиентскому приложению.
Также извлечено из is link :
... все протоколы являются клиентами сервера CAS, которые взаимодействуют с ним по протоколу CAS. Это делается на уровне запросов / браузера, в отличие от внутренних действий через сильно настроенные веб-потоки, которые могут быть связаны друг с другом. Модули протокола, которые существуют в CAS, не предполагают внутренних механизмов потока / механизма аутентификации CAS. Они относятся к нему так же, как к внешнему серверу CAS; единственное отличие состоит в том, что они сидят и живут внутри сервера CAS напрямую, и все же они остаются полностью независимыми от этого факта. Проще говоря, в нашем примере модуль SAML2 в основном говорит: «этот входящий запрос должен быть аутентифицирован. Поэтому я направлю его на сервер CAS для аутентификации, и когда он вернется, я сделаю все возможное ».