Если пользователь проходит проверку подлинности через OpenID Connect на клиенте и запускает длительный запрос на стороне сервера, как сервер может сохранить токен доступа действительным, если операция занимает больше времени, чем срок действия токена доступа?
У нас есть набор приложений, состоящий из нескольких серверных серверных приложений (обычно доступ к которым осуществляется через REST, HTTP и / или WebDAV), нескольких веб-интерфейсных приложений и нескольких клиентских (т.е. настольных) приложений. Мы уже поддерживаем схемы проверки подлинности Basic и Kerberos / Negotiate и в настоящее время добавляем поддержку OpenID Connect.
К нашим серверным приложениям обычно обращаются веб-интерфейс и клиентские приложения, другие серверные серверные приложения и сторонние пользовательские приложения, когда наше программное обеспечение интегрировано в их систему. В настоящее время мы передаем токены доступа OpenID по схеме Bearer в бэкэнд-приложения.
В типичном сценарии пользователь (прошедший проверку подлинности на локальном клиенте или в веб-интерфейсе) запускает серверную операцию, которая может выполняться несколько минут, часов, дней или даже недель. Эта операция обращается к другим бэкэндам от имени пользователя, например, серверная файловая система на основе Web-DAV для доступа к дополнительным данным. Всем бэкэнд-приложениям требуется информация аутентификации пользователя для предоставления доступа и доступа к дополнительным данным пользователя для авторизации (например, только для предоставления доступа к собственным файлам пользователя).
Очевидно, это означает, что токен доступа, предоставленный исходным внутренним вызовом, может истечь до завершения операции. Поэтому серверу нужен способ обновить токен доступа без взаимодействия с пользователем. Наш код уже может сделать это, если ему известен токен обновления пользователя (используя токен обновления, идентификатор и секретный ключ приложения для доступа к конечной точке токена OIDC).
Но как мы можем "правильно" передать токен обновления на сервер?
Клиент имеет (потенциально) полный набор токенов идентификатора, доступа и обновления. Но из того, что я понимаю, схема Bearer ожидает, что переданный токен является токеном доступа. Здесь важна совместимость, поскольку к нашим внутренним приложениям могут также обращаться сторонние клиентские приложения. Предполагая, что получение токена обновления в серверное приложение является правильным подходом, мы все равно должны поддерживать ситуации, когда вызывающая сторона может предоставить только токен доступа (с очевидными последствиями того, что в этих случаях длительные операции не будут выполняться). возможность доступа к другим внутренним службам от имени пользователя).
Я мог бы представить, что сервер принимает либо токен доступа, либо токен обновления через Bearer. Но из того, что я понимаю, единственный «аргумент», который клиент может передать с правильным заголовком аутентификации Bearer, представляет собой одну строку в кодировке Base64, то есть токен (доступа). Здесь клиент может передать токен доступа или обновить, но я не вижу, как сервер мог бы определить, что это такое, насколько мне известно, оба типа токенов непрозрачны.
Я понимаю, что первоначальная идея заключается в том, чтобы серверные операции были недолговечными, поэтому ответственность за поддержание маркера доступа в актуальном состоянии лежит на клиенте. Но, конечно, мы не можем быть первыми, кому действительно нужно объединить OIDC с длительными операциями на стороне сервера. Есть ли приемлемый способ передачи токена обновления на сервер или, альтернативно, совершенно другой подход, который мне не хватает?