Является ли плохой практикой ставить дополнительные требования для авторизации

Я хочу реализовать уровень авторизации в своем проекте микросервисов. У меня есть 3 микросервиса: обслуживание клиентов, рабочее пространство и облачный сервис. Поэтому, если клиент хочет создать облачный экземпляр, он будет создавать от имени рабочего пространства, что означает, что облачный экземпляр будет принадлежать рабочему пространству вместо него, а также он может пригласить другого клиента в рабочее пространство и иметь доступ к облачному экземпляру. . Структура данных может выглядеть так.

// workspace
{
 "workspaceId": "ws-123",
 "customers": ["customer-123", "customer-456"]
}

// cloud-instance
{
 "cloudId": "cloud-123",
 "workspaceId: "ws-123"
}

Я хочу реализовать логику авторизации, которая проверяет, есть ли у пользователя доступ к определенному облачному экземпляру. Для этого мне нужно иметь workspaceId где-то еще в моем объекте аутентификации. Одна вещь, о которой я могу думать, это поместить workspaceId в утверждения jwt, чтобы мой jwt мог выглядеть так.

header.{ ..., workspaceId: ["ws-123"] }.signature

но недостатком этого решения является то, что утверждение workspaceId не будет обновлено до тех пор, пока не будет обновлен токен.

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

const hasAccess = (customerId, workspaceId_on_cloud_instance) => {
   let actual_workspaceId_that_he_has = workspace_service_exposed_api.findWorkspaceByCustomerId(customerId)
   return actual_workspaceId_that_he_has == workspaceId_on_cloud_instance
}

но этот подход будет в значительной степени полагаться на службу рабочей области, если служба рабочей области не работает, тогда другая служба вообще не может обработать запрос, поскольку у нее нет доступа к рабочему пространству.

Итак, ИМХО, я бы предпочел 1-й вариант, так как я использую oauth2.0, и токен будет обновляться каждые 30 секунд, но это плохая практика? Интересно, есть ли лучшее решение.

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
В настоящее время производительность загрузки веб-сайта имеет решающее значение не только для удобства пользователей, но и для ранжирования в...
Безумие обратных вызовов в javascript [JS]
Безумие обратных вызовов в javascript [JS]
Здравствуйте! Юный падаван 🚀. Присоединяйся ко мне, чтобы разобраться в одной из самых запутанных концепций, когда вы начинаете изучать мир...
Система управления парковками с использованием HTML, CSS и JavaScript
Система управления парковками с использованием HTML, CSS и JavaScript
Веб-сайт по управлению парковками был создан с использованием HTML, CSS и JavaScript. Это простой сайт, ничего вычурного. Основная цель -...
JavaScript Вопросы с множественным выбором и ответы
JavaScript Вопросы с множественным выбором и ответы
Если вы ищете платформу, которая предоставляет вам бесплатный тест JavaScript MCQ (Multiple Choice Questions With Answers) для оценки ваших знаний,...
1
0
73
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Имея 3 микросервиса, вы не можете реализовать функциональность, предполагая, что один сервис не работает. У меня такое ощущение, что срок жизни токена доступа также определяется на основе этого ограничения - иметь актуальные данные в токене. Как я правильно понимаю, в худшем случае еще и ~30 сек. задержка, связанная с обновлением workspaceId в полезной нагрузке токена.

Заявка на токен будет меняться только тогда, когда вы приглашаете или удаляете человека из рабочей области, поэтому эта служба должна работать в любом случае. Я бы использовал второе решение с более длительным сроком жизни токена, чтобы не генерировать его так часто.

Другим решением является создание нового токена каждый раз, когда изменяется рабочая область. Вы можете рассматривать добавление/удаление в рабочую область как бизнес-логику, которая делает токен недействительным, но, вероятно, в этом случае также требуется связь со службой рабочей области.

Если вы боитесь, что микросервис выйдет из строя или у вас возникнут проблемы со связью, возможно, вам стоит больше сосредоточиться на инфраструктуре приложения или выбрать новое решение, основанное на монолитном приложении.

И вернемся к вопросу из заголовка - добавление любого пользовательского утверждения в полезную нагрузку токена является стандартным подходом.

Другие вопросы по теме