Как предоставить OAuth через сервисы? - PullRequest
0 голосов
/ 20 сентября 2018

У меня есть 3 службы (в действительности гораздо больше):

  1. Служба авторизации (использует OAuth 2.0)
  2. Служба веб-интерфейса
  3. Служба ресурсов

и клиент (веб-браузер).

Я храню session_id, access_token и refersh_token в файлах cookie веб-браузера пользователя.Пользователь заходит в сервис авторизации, авторизуется и получает эти токены.После того, как его веб-браузер перенаправлен на Frontend.
Службы Frontend и Resource не могут проверять токены, потому что они ничего об этом не знают, поэтому они должны сделать запрос к службе Auth.
Текущие сценарии:
Пользователь (веб-браузер) отправляет запрос в службу Frontend, Frontend отправляет запрос в службу аутентификации для проверки access_token.Если он недействителен, веб-интерфейс отправляет запрос на обновление токена с помощью refresh_token.
Если веб-интерфейсу необходим доступ к службе ресурсов для обработки запроса, тогда внешний интерфейс отправляет свои client_id и access_token службе ресурсов.Служба ресурсов также отправляет запрос в службу аутентификации для проверки access_token.

Мои мысли верны?Или у него более простая схема?
PS Все сервисы используют архитектуру RESTful.

1 Ответ

0 голосов
/ 20 сентября 2018

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

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

Существуют способы, с помощью которых вы можете пропустить этот вызов серверу авторизации и при этом проверить святостьтокен без явного вызова.Одним из способов является использование JWT.Эти токены подписаны провайдером Auth, и ваши сервисы имеют ключи, которые могут помочь вам проверить, изменен ли токен, и сам токен содержит всю информацию, необходимую для обеспечения его действительности, такую ​​как срок действия, предполагаемая аудитория, клиенты, роли и т. д.

При входе в систему вы получаете AT и RT.AT может передаваться в нисходящий поток для аутентификации и авторизации, а RT может использоваться после истечения срока действия AT.Вам нужно только поговорить с провайдером аутентификации во время входа в систему и когда вам необходимо обновить токен.

Вы можете прочитать больше о JWT OAuth2.0 с JWT и OIDC, чтобы получить больше информации об этом

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