Кажется, что в настройке реализован тип предоставления кода авторизации OAuth2.0.В терминологии OAuth2.0 сервер, на котором размещена страница входа, называется «сервером авторизации», сервер, на котором размещен API или любой веб-сайт, требующий аутентификации, называется «сервером ресурсов», а приложение, пытающееся использовать API, называется «клиентом».
Теперь, если «Клиент» действует от имени пользователя (учитывая, что конечный пользователь хочет войти в веб-приложение), описанная вами установка является правильной.Можно использовать любой из типа предоставления кода авторизации, типа неявного предоставления и типа предоставления пароля владельца ресурса, и каждый из них будет перенаправлять пользователя на страницу входа, как вы упомянули выше.
Но когда «Клиент»не действует от имени какого-либо отдельного пользователя (например, пакетное задание), так как в вашем случае, тип использования, который будет использоваться, является типом разрешения Client Credential.Здесь перенаправление на страницу входа не произойдет.Вместо этого «клиент» будет напрямую связываться с «сервером авторизации» с помощью идентификатора клиента и секрета клиента, а «сервер авторизации» возвращает код доступа.Клиент может связываться с API в «сервере ресурсов» с помощью кода доступа (может быть через cookie).
Подробные сведения см. В описании типа предоставления учетных данных клиента в спецификации RFC 6749 OAuth2.0.