OAuth 2 и управление многопользовательскими токенами доступа на стороне сервера

Question

У меня есть серверное приложение (реализовано в GO), которое выбирает пользовательских данных из внешнего API. ( пользовательских данных хранится сторонними компаниями и они предоставляют API для доступа к нему .) У меня фактически есть два типа пользователей. Один из них - пациенты, а другой - врач. Доктор актер здесь отвечает за мониторинг данных пациента. Таким образом, поток,

1. Пациенты (1..n) авторизуют серверное приложение, используя поток маркеров доступа OAuth2.
2. Сервер регулярно извлекает данные пациента через API и сохраняет данные пациента в локальной базе данных
3. Врач может проверить любые данные пациента в любое время, которые были сохранены в локальной базе данных

Шаг 1 легкий. Реализуя поток грантов OAuth2, я могу получить access_token и refresh_token для каждого пользователя. Допустим, у меня есть 100 пациентов. Я предполагаю, что могу получить актуальный access_token, используя refresh_token, без повторного взаимодействия с пациентом.

Вопрос в том, После того, как пациент авторизовал приложение, мне нужно где-то хранить его access_token и refresh_token, чтобы каждый раз, когда сервер запускает запланированное задание для получения данных пациента, сервер мог получить доступ к внешнему API с помощью действительный токен. Какой здесь общий подход? Должен ли я хранить access_token и refresh_token в моей пользовательской таблице и использовать их при необходимости?

Поскольку у меня n пациентов (n токенов) и сервер может извлекать внешний API в любое время, мне нужно найти последовательный способ поддержки этого сценария.

См. Прилагаемую диаграмму для визуализации.

Спасибо

Answer 1

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

Вы должны хранить токен обновления. Хранить ли токены доступа и время их истечения (из ответа /token конечной точки), зависит от того, как часто вы выбираете данные пациента. Если период запланированной задачи превышает срок действия маркеров доступа, вам не нужно хранить их в постоянном хранилище. В противном случае вы можете хранить их вместе с маркером обновления.

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

Просто для пояснения, используемый вами поток называется Предоставление кода авторизации .