Должен ли шлюз API отвечать за авторизацию?
В настоящее время у меня есть монолитное приложение с Java / Spring Boot со следующими конечными точками:
/login/logout/some-resource
Чтобы получить доступ к some-resource, выполните следующие действия:
- Пользователь делает запрос
POSTк конечной точке/login. Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401. - Пользователь отправляет токен JWT вместе с запросом на
/some-resource. Если токен действителен, ресурс возвращается, в противном случае - 403.
Теперь я хочу разделить монолит на 2 службы: «AuthServer» и «SomeResourceServer». Сверху будет шлюз API. Я думаю о 2 возможных способах авторизации
Опция 1
- Пользователь делает запрос к конечной точке
/login. Шлюз API пересылает его на «AuthServer». Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401. - Этот шаг такой же - Пользователь отправляет токен JWT вместе с запросом на
/some-resource. Шлюз API вызывает «AuthServer» для проверки токена JWT. Если токен действителен, шлюз API вызывает SomeResourceServer и возвращает результаты. В противном случае 403.
Вариант 2
- Пользователь делает запрос к конечной точке
/login. Шлюз API пересылает его на «AuthServer». Если учетные данные верны, в заголовке возвращается токен JWT, в противном случае - 401. - Этот шаг такой же - Пользователь отправляет токен JWT вместе с запросом на
/some-resource. Шлюз API просто перенаправляет запрос на SomeResourceServer. Затем SomeResourceServer вызывает AuthServer для проверки токена JWT. Если токен действителен, ресурс возвращается, в противном случае - 403.
В варианте 1 шлюз API отвечает за авторизацию (связь с «AuthServer»), в варианте 2 связь осуществляется между серверами. Так какой вариант более правильный? Есть ли хорошие / плохие практики? А может другой способ / вариант?
Ответы 1
Вы можете отключить аутентификацию на шлюзе, и в этом нет ничего плохого. На шлюзе есть небольшие накладные расходы, и это не будет проблемой, если
- вы намерены обезопасить все свои ресурсы.
- вы убедитесь, что любой вызов, который достигает службы ресурсов, происходит из безопасной зоны, т.е. запрос не должен поступать напрямую в службу, поскольку у него не будет никаких средств для аутентификации.
- Нет авторизации. Токены JWT также содержат важную информацию о ролях, которые помогают приложению принимать решение об авторизации. Если вы можете потерять эту информацию, то ничего страшного.
Однако у вас есть одно место для обработки аутентификации, и если вы удалите токен из вызова, в зависимости от количества переходов, которые этот вызов должен сделать, это удаление токена может вам помочь.
С другой стороны, вариант II дает вам свободу в том, что все ваши услуги защищены индивидуально. Если вы хотите, чтобы некоторые ресурсы какой-либо службы были доступны анонимно, вы также можете получить это. У вас также есть контроль над битом авторизации.
Все дело в компромиссах. Но я предпочитаю второй подход, так как у меня больше свободы.
Сказав это, вам действительно не нужно вызывать сервер аутентификации для проверки JWT. Токены JWT можно проверить независимо, если у вас есть открытый ключ авторизации подписи.
Также при запросе ресурса, если токен недействителен, код ответа должен быть 401, а если токен действителен. Принципал не авторизован для доступа к ресурсу, ответ должен быть 403.
API-шлюз IMO не должен иметь ничего общего с авторизацией (может быть аутентификация), поскольку это то, что решается службой и варьируется от службы к службе и от ресурса к ресурсу и должно быть оставлено на попечение служб.
Существует два типа токена доступа к токену и токена обновления. AT недолговечен, и мы можем передавать его независимо, проверяя только с помощью открытого ключа. Сценарии выхода из системы можно обрабатывать с помощью токена обновления. т.е. AT не будет обновляться после выхода из системы. Если ваше приложение может жить с тем минимальным временем, в течение которого AT должен быть в живых, я думаю, вы можете избежать вызова сервера. Говоря о ролях, они тоже могут быть частью токена. Никто не может его изменить. С точки зрения микросервисов, повторный вызов auth server снова может быть серьезным недостатком, и именно здесь JWT сияет. Но все дело в компромиссах.
Большое спасибо за объяснение! Теперь мне стало понятнее. Еще одна вещь, не могли бы вы поделиться в своем ответе ссылками на учебники / статьи по этой теме? Я считаю, что это будет очень полезно, еще раз спасибо :)
У меня нет какого-либо документа, которым я мог бы поделиться прямо сейчас, но я предлагаю узнать больше о JWT и OIDC (это то, что я использовал)
Спасибо за полезную информацию! Что касается проверки токенов JWT независимо, я думаю, что это зависит от того, какую проверку вы хотите сделать, например, если вы хотите проверить, был ли токен создан перед проверкой пароля или был ли токен недействителен (с запросом выхода), В этом В некоторых случаях я бы сказал, что запрос к Auth-серверу будет лучше. Также имеет смысл проверить токен с помощью Auth-сервера, если вы объедините этот запрос с получением роли. Как вы думаете?