Должен ли API-шлюз отвечать за авторизацию? - PullRequest
Новая
       56

Должен ли API-шлюз отвечать за авторизацию?

0 голосов
/ 05 июня 2018

В настоящее время у меня есть монолитное приложение с Java / Spring Boot следующих конечных точек:

  • /login
  • /logout
  • /some-resource

Для доступа к some-resource поток выглядит следующим образом:

  1. Пользователь делает запрос POST к конечной точке /login.Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401.
  2. Пользователи отправляют токен JWT вместе с запросом на /some-resource.Если токен действителен, ресурс возвращается, в противном случае 403.

Теперь я хочу разделить монолит на 2 службы: "AuthServer" и "SomeResourceServer".Наверху будет шлюз API.Я думаю о 2 возможных способах обработки авторизации

Вариант 1

  1. Пользователь делает запрос к /login конечной точке.Шлюз API пересылает его на «AuthServer».Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401. - этот шаг аналогичен
  2. Пользователи отправляют токен JWT вместе с запросом на /some-resource,Шлюз API вызывает «AuthServer» для проверки токена JWT.Если токен действителен, шлюз API вызывает «SomeResourceServer» и возвращает результаты.В противном случае 403.

Опция 2

  1. Пользователь делает запрос к /login конечной точке.Шлюз API пересылает его на «AuthServer».Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401. - этот шаг такой же
  2. Пользователи отправляют токен JWT вместе с запросом на /some-resource,Шлюз API просто перенаправляет запрос в «SomeResourceServer».Затем SomeResourceServer вызывает AuthServer для проверки токена JWT.Если токен действителен, ресурс возвращается, в противном случае 403.

В варианте 1 шлюз API отвечает за обработку авторизации (связь с "AuthServer"), в варианте 2 - связь.делается между серверами.Так какой вариант является более правильным?Есть ли хорошие / плохие практики?Или, может быть, другой способ / вариант?

1 Ответ

0 голосов
/ 06 июня 2018

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

  1. вы намерены сделать все свои ресурсы безопасными.
  2. вы убедитесь, что любой вызов, который достигаетслужба ресурсов находится в безопасной зоне, т. е. запрос не должен поступать непосредственно в службу, поскольку у него не будет средств для аутентификации.
  3. Нет авторизации.Токены JWT также содержат важную информацию о ролях, которые помогают приложению принять решение об авторизации.Если вы можете потерять этот бит информации, это нормально.

Однако у вас есть одно место для обработки аутентификации, и если вы убираете токен из вызова, в зависимости от количества прыжковэтот вызов должен сделать это удаление токена может помочь вам.

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

Это все о компромиссах.Но я предпочитаю второй подход, так как у меня больше свободы.

Сказав это, вам действительно не нужно звонить серверу авторизации для проверки JWT.Токены JWT можно проверить независимо, если у вас есть открытый ключ подписывающего органа.

Также при запросе ресурса, если токен недействителен, код ответа должен быть 401, и если токен действителен, Принципал не авторизован для доступа кресурс, ответ должен быть 403.

Шлюз API IMO не должен иметь ничего общего с авторизацией (может быть, аутентификация), поскольку это то, что определяется сервисом и варьируется от сервиса к сервису и от ресурса к ресурсу идолжны быть оставлены для услуг, чтобы заботиться о.

...