Реагировать на несколько поддоменов с помощью jwt - PullRequest
Новая
       91

Реагировать на несколько поддоменов с помощью jwt

2 голосов
/ 28 апреля 2020

Мы хотим разработать несколько разных сервисов (React Apps) с одной и той же базой данных пользователей и Rest API. Некоторые пользователи могут иметь доступ к APP 1, некоторые для APP 2, некоторые для обоих зависят от их роли.

  • Мы решили go для метода с несколькими поддоменами приложений.

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

СТРУКТУРА:

enter image description here

АВТОМАТИЧЕСКИЙ ПОТОК:

enter image description here

В этом потоке есть две основные проблемы, которые помечены как 1 и 2:

  1. Допустим, я go, чтобы войти в приложение и войти в систему, получая accestoken из бэкэнда. Как доставить токен на app1.company.com? следует реагировать на перенаправление входа в систему с токеном в параметре url?

    • локальное хранилище находится в области поддоменов.

    • iframe имеет проблемы с Safari.

    • Пока я не хочу сохранять jwt в файлах cookie, потому что flask REST может обслуживать клиентов, не относящихся к браузеру.

Допустим, пользователь хочет go app2. если мы не можем поделиться токеном из app1 с iframes или любым другим методом, то это приложение должно быть перенаправлено для входа в систему и повторного выполнения процесса как app1, что нам подходит. Но так ли это на самом деле? если токен больше недействителен и мы получаем ошибку из бэкэнда, следует ли нам перенаправить приложение входа в другой субдомен (вставить URL, к которому мы хотим go вернуться после успешного входа в систему)?

  • Могу ли я просто использовать стороннюю службу Open ID Connect?

  • Должен ли я рассмотреть возможность использования микро-интерфейсов для создания всех "приложений" в одном домене?

  • Как "Attlassian" в качестве примера обрабатывает этот процесс?

Чего мне не хватает и как лучше всего решить этот поток?

1 Ответ

1 голос
/ 01 мая 2020

Давайте скажем i go приложению для входа в систему и войдите в систему, получив доступ к бэкэнду. Как доставить токен на app1.company.com?

Проблема в том, что login.company.com доставляет токен в качестве параметра в URL-адресе, поскольку сайт может проверять подлинность маркера путем проверки цифровой подписи или с указанием конечной точки c в центральном домене аутентификации. Вот как openid / oauth2 делает это, используя «неявный» поток, хотя они также позволяют отправлять токен как POST или использовать двухэтапный поток (поток «authorization_code»)

Допустим, пользователь хочет go до app2. если мы не можем поделиться токеном из app1 с iframes или любым другим методом, то это приложение должно быть перенаправлено для входа в систему и повторного выполнения процесса как app1, что нам подходит. Но так ли это на самом деле?

Вы можете разделить токен между доменами, используя внутренний iframe, но в вашем случае я бы рекомендовал каждому домену использовать свой собственный токен.

если токен больше недействителен и мы получаем ошибку из бэкэнда, следует ли нам перенаправить приложение входа в систему в другом поддомене (вставить URL-адрес, к которому мы хотим go вернуться после успешного входа в систему)?

Да, в номере 2) вашего чертежа, просто перенаправьте с app2.company.com на login.company.com и выполните тот же процесс, что и в 1). Вам потребуется какой-то тип повара ie на login.company.com, чтобы избежать повторного запроса учетных данных у пользователя

Могу ли я просто использовать стороннюю службу Open id connect?

Да, вы можете использовать внешнюю службу OpenIdConnect или развернуть на login.company.com сервер OpenIdConnect, такой как IdentityServer или KeyCloak

Должен ли я рассмотреть возможность использования микро-интерфейсов для создания всех «приложений» в том же домене?

Нет необходимости иметь центральный домен аутентификации

Как "Attlassian" в качестве примера обрабатывает этот процесс?

Я точно не знаю, как это делает Attlassian, но в настоящее время большинство веб-сервисов поддерживают OpenIdConnect

...