Я хочу реализовать уровень авторизации в своем проекте микросервисов. У меня есть 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 секунд, но это плохая практика? Интересно, есть ли лучшее решение.
Имея 3 микросервиса, вы не можете реализовать функциональность, предполагая, что один сервис не работает. У меня такое ощущение, что срок жизни токена доступа также определяется на основе этого ограничения - иметь актуальные данные в токене. Как я правильно понимаю, в худшем случае еще и ~30 сек. задержка, связанная с обновлением workspaceId в полезной нагрузке токена.
Заявка на токен будет меняться только тогда, когда вы приглашаете или удаляете человека из рабочей области, поэтому эта служба должна работать в любом случае. Я бы использовал второе решение с более длительным сроком жизни токена, чтобы не генерировать его так часто.
Другим решением является создание нового токена каждый раз, когда изменяется рабочая область. Вы можете рассматривать добавление/удаление в рабочую область как бизнес-логику, которая делает токен недействительным, но, вероятно, в этом случае также требуется связь со службой рабочей области.
Если вы боитесь, что микросервис выйдет из строя или у вас возникнут проблемы со связью, возможно, вам стоит больше сосредоточиться на инфраструктуре приложения или выбрать новое решение, основанное на монолитном приложении.
И вернемся к вопросу из заголовка - добавление любого пользовательского утверждения в полезную нагрузку токена является стандартным подходом.