Я попытаюсь объяснить мою точку зрения:
Вариант 1 :
Я понимаю, что прежде всего вам необходимо войти на сервер идентификации с помощью учетные данные пользователя, а затем создать повар ie. Я бы не рекомендовал этот вариант, во-первых, потому что, как я вижу, вы не проверяете cook ie, и он содержит идентификатор пользователя, который распространяется на серверы, поэтому пользователь может изменить идентификатор пользователя, чтобы получить информацию о других пользователях. , И во-вторых, потому что этот подход заставляет вас иметь политику повара ie
Вариант 3 :
Как я вижу, в этом варианте вы выполняете вход на каждом приложении. Так что, если в будущем у вас появятся другие приложения, вам нужно будет реализовать страницу входа и logi c в каждом из них.
Вариант 2 :
Я думаю, что это лучший из них, но я бы внес изменения. Прежде всего, это хороший вариант иметь шлюз API, который решает такие перекрестные проблемы, как аутентификация / авторизация, общение с сервером идентификации для запроса токенов доступа и попытки вызова сервисов. При этом у вас будет уникальная точка входа в систему, и шлюз сможет проверять разрешения (области) для выполнения действий, требуемых пользователем, поэтому сервисам не придется об этом заботиться. Единственное, что я хотел бы изменить - это проверка в каждой из служб. Поскольку природа токенов JWT, он будет содержать всю информацию, необходимую для валидации (время истечения срока действия, издатель, аудитория и т. Д. c), поэтому эта валидация не понадобится. И чтобы избежать возможности манипулирования, лучший подход состоит в том, чтобы подписать токен доверенным сертификатом и позволить шлюзу проверить целостность, поэтому, когда токен достигает сервисов, вы уверены, что это действительный пользователь с соответствующими правами на выполнение действие