Здравствуйте. Вкратце, ситуация такова: имеется приложение, в котором хранится информация о пользователях и их правах доступа для различных проектов (веб-приложений). Собственно процесс авторизации пользователей на этих сервисах предполагается из следующих шагов:
1. Пользователь обращается к сервису.
2. Перенаправляется на центральное приложение для авторизации.
3. Вводит логин и пароль.
4. Центральное приложение создает JWT-токен, в котором содержится уровень доступа пользователя для конкретного проекта (предполагаю, с привязкой по IP, или что-то подобное).
5. Приложение перенаправляет пользователя обратно на этот сервис вместе с токеном.
6. Токен валидируется и кладется в куки пользователю. При последующих запросах к сервису авторизация происходит по токену, хранящемуся в куках, пока срок его действия не истечет.
Собственно у меня вопрос по поводу пятого пункта, а именно каким образом перенаправить пользователя с токеном на сервис. Предполагается, что в дальнейшем в токен может помещаться некая информация о пользователе, поэтому (да и не только) передача токена в строке запроса меня смущает (возможно я не прав). В связи с этим, в голову приходит submit некой формы (POST) с передачей токена в теле запроса, но через редирект я не особо представляю как этот сделать.
Итак, получается мне нужно после успешного логина, рендерить форму (невидимую пользователю), которую автоматически отправлять на клиенте через JS (ну и оставить запасную ссылку, если последний выключен). Почему-то мне все это кажется каким-то велосипедом. Собственно потому и спрашиваю.
А как на счет OAuth2 авторизации? Не думали? Хорошо документированный протокол, которым пользуются все известные сервисы и не задаются вопросами. Как раз решает ваш вопрос. Редиректнулся на центральное приложение, авторизовался, вернулся назад с кодом и далее запросил токен по коду POST запросом. Куда надо сохранил.
В токене у вас в любом случае должна быть вся нужная информация. Например, в виде ID токена по протоколу OpenId Connect. После аутентификации пользователя переадресует на определенный эндпоинт по которому вы создаете для этого пользователя сессию и с которой он потом спокойно ходит по вашему ресурсу
Насчет сессии понял, спасибо за совет, и вправду перемудрил с хранением токена. Еще хотелось бы еще ответ на основной вопрос, не сомнительно ли передавать токен через GET?
angover, нет. вы все-равно обязаны его валидировать, верифицировать откуда пришел запрос, ну и не забываем про SSL шифрование (https), ассиметричное шифрование в подписи токена и все такое. Это вообще минимальные требования к безопасной системе. И да, не забываем что у токена есть срок жизни
Ну это я так понял вы говорите про этап, когда уже клиент предоставляет токен сервису.
А я имел ввиду, скажем так, как заставить клиента этот токен с сервера авторизации "принести" на сервис. И здесь, как упоминал в вопросе, я вижу два варианта, первый это после логина редиректить на а-ля service.com/login?token=123 (далее, из GET он разумеется изымается), или, второй - создавать форму, и передавать его через POST (но тогда прямой редирект я сделать не могу, необходима промежуточная страница).
