Использование OAuth 2.0 в микросервисной архитектуре¶

Oauth 2.0

Последовательность событий для API-клиента выглядит так.

1. Клиент делает запрос, предоставляя свои учетные данные в процессе HTTP-аутентификации.
2. API-шлюз делает запрос типа OAuth 2.0 Password Grant к серверу аутентификации.
3. Сервер аутентификации проверяет учетные данные API-клиента и возвращает токены доступа и обновления.
4. API-шлюз включает токен доступа в запросы, которые он отправляет сервисам. Сервис проверяет токен доступа и использует его для авторизации запроса.

API-шлюз, основанный на OAuth 2.0, может задействовать токен доступа в качестве токена сеанса, чтобы аутентифицировать клиентов сеансового типа.

Последовательность событий выглядит так.

1. Клиент, требующий входа в систему, передает шлюзу свои учетные данные методом POST.
2. Объект LoginHandler API-шлюза направляет запрос на выдачу пароля серверу аутентификации.
3. Сервер аутентификации проверяет учетные данные клиента и возвращает токены доступа и обновления.
4. Шлюз возвращаеттокены доступа и обновления клиенту, например в виде cookie.
5. Клиент включает токены доступа и обновления в запросы, которые делает к API-шлюзу.
6. Перехватчик аутентификации сеанса шлюза проверяет токен доступа и включает его в запросы к сервисам.

Если токен доступа просрочен, API-шлюз получает новый токен, выполняя запрос типа OAuth 2.0 Refresh Grant и указывая токен обновления. Если токен обновления не был просрочен или отозван, сервер авторизации возвращает новый токен доступа, а шлюз передает его сервисам и возвращает клиенту.
Важное преимущество OAuth 2.0 в том, что это устоявшийся стандарт безопасности, и можно использовать готовый сервер аутентификации

Комментарии

Комментарии