Какой тип гранта OAuth2 мне следует использовать?

Question

Я поддерживаю SReview, симпатичное веб-приложение, которое должно выполнять множество фоновых задач, которые потребуются для изменения состояния базы данных.Эти задания требуют большого количества процессорного времени, и их много, поэтому в зависимости от размера установки может оказаться целесообразным, чтобы на нескольких машинах выполнялись эти фоновые задания.Несмотря на это, количество машин, которые имеют доступ к базе данных, довольно ограничено, поэтому в настоящее время я имею их доступ к базе данных напрямую, используя прямое соединение PostgreSQL.

Это работает, но иногда фоновые задания могутнеобходимо запустить где-нибудь на другой стороне враждебной сети, и поэтому может быть менее желательно требовать дополнительного открытого сетевого порта только для доступа к базе данных.Поэтому я думал о реализации своего рода протокола RPC на основе сети (возможно, с JSON) и защиты доступа с помощью OAuth2.Однако я никогда ранее не работал с этим протоколом подробно и мог бы использовать некоторые рекомендации относительно того, какой поток грантов использовать.

Существует два способа предоставления необходимых учетных данных на работающей машинеэти фоновые задания:

1. Диспетчер заданий имеет возможность задавать переменные среды или параметры командной строки для фоновых заданий.Затем они будут переданы машинам, которые фактически выполняют задания таким образом, который можно считать безопасным.Однако это означало бы, что в некоторых случаях сам диспетчер заданий также должен был бы проходить проверку подлинности с помощью OAuth2, предпочтительно таким образом, чтобы его можно было перезапускать по желанию без необходимости повторной проверки подлинности.
2. Какколичество машин, на которых выполняются задания, вероятно, будет довольно ограничено, поэтому должна быть возможность создавать учетные данные для каждой машины.В этом случае, однако, было бы важно иметь возможность запускать несколько сеансов параллельно на машине продажи.

Какой поток грантов лучше всего поддержит любую из этих моделей?

Answer 1

Из обзора вашего сценария становится ясно, что взаимодействия происходят между системой.Нет взаимодействия с конечным пользователем (человеком).

Во-первых, учитывая, что ваши приложения выполняются в защищенной среде (закрытой), они могут рассматриваться как конфиденциальные клиенты. Типы клиентов OAuth 2.0 подробнее об этом.На этом фоне вы можете выдать каждому распределенному компоненту приложения идентификатор клиента и секрет клиента.

Что касается типа предоставления, сначала я приглашаю вас ознакомиться со всеми доступными параметрами.Это можно сделать, перейдя в раздел Получение авторизации .Проще говоря, это объясняет, каким образом приложение может получить токены (особенно токены доступа), которые можно использовать для вызова защищенной конечной точки OAuth 2.0 (в вашем случае конечной точки RPC).

Для вас лучшим типом предоставления будет клиентские полномочия .Он предназначен для клиентов с предварительно установленным доверием к защищенной конечной точке OAuth 2.0.Кроме того, он не требует браузера (пользовательский агент) или конечного пользователя по сравнению с другими типами грантов.

Наконец, вам потребуется использовать сервер авторизации OAuth 2.0.Это позволит регистрировать разных распределенных клиентов и выдавать идентификаторы клиентов, их секреты.И когда клиенту требуется получить токены, он использует конечную точку токена.И каждый клиентский вызов вашей конечной точки RPC будет содержать действительный токен доступа, который вы можете проверить с помощью самоанализа токена (или любого другого желаемого метода).