Скажем авторизованный юзер находится в системе, и хочет запустить один из модулей системы, которая реализована как отдельная SPA приложение. Т.е. необходимо перенаправить его по-сути на другой URL, где она живет, но с токеном, который уже есть у пользователя. Самый очевидный способ это передать его в URL по типу https://myspa.com?accessToken=egdkdj... но передача в таком виде опасна, т.к. через урл он может легко утечь к хакерам. Какие есть способы сделать это может в теле запроса, хэдерах или еще как?
Здравствуйте, Stalker., Вы писали:
S>Скажем авторизованный юзер находится в системе, и хочет запустить один из модулей системы, которая реализована как отдельная SPA приложение. Т.е. необходимо перенаправить его по-сути на другой URL, где она живет, но с токеном, который уже есть у пользователя. Самый очевидный способ это передать его в URL по типу https://myspa.com?accessToken=egdkdj... но передача в таком виде опасна, т.к. через урл он может легко утечь к хакерам. Какие есть способы сделать это может в теле запроса, хэдерах или еще как?
и тело и хидеры также утекут к хакерам легко.
Так что шифруй
Здравствуйте, paradoks, Вы писали:
P>и тело и хидеры также утекут к хакерам легко.
И все таки URL-ы оседают в логах, практически по умолчанию, чего не случается с хидерами.
По команде пользователя (щелчку по ссылке) система А, в которой аутентифицирован пользователь, связывается с системой Б, куда он хочет получить доступ, напрямую, т.е. мимо пользователя, и говорит, что пользователь хочет получить доступ. В ответ система Б генерит одноразовый входной билет с ограниченным временем жизни (в простейшем случае случайное число) и передает его системе А, после чего система А редиректит пользователя в систему Б с этим входным билетом (www.systemB.ru/login.php?token=12345. После входа пользователя в систему Б с таким билетом пользователь аутентифицируется в Б, а билет уничтожается. Также билет уничтожается в случае, если не был использован в течении, скажем, 10 секунд после генерации.
Теоретически это, конечно, отламывается — если злоумышленник сможет не позволить пользователю войти в течении 10 секунд, а сам использует этот билет с другого компьютера. Но это уже будет не хак, а целая войсковая операция
Можно усилить защиту, если система А вместе с ID пользователя будет отправлять системе Б его фингерпринт (комбинация из IP-адреса, ОС, разрешения экрана и т.п.), а Б будет проверять эту информацию при входе пользователя.
Еще сильнее усилить безопасность без изменения условий задачи, как мне кажется, нельзя.
Здравствуйте, Stalker., Вы писали:
S>Скажем авторизованный юзер находится в системе, и хочет запустить один из модулей системы, которая реализована как отдельная SPA приложение. Т.е. необходимо перенаправить его по-сути на другой URL, где она живет, но с токеном, который уже есть у пользователя. Самый очевидный способ это передать его в URL по типу https://myspa.com?accessToken=egdkdj... но передача в таком виде опасна, т.к. через урл он может легко утечь к хакерам. Какие есть способы сделать это может в теле запроса, хэдерах или еще как?
Самый очевидный это иметь сервис аунтетификации и оба приложения будут спрашивать статус у него. Все секреты юзер передает только ему а остальные приложения получают у этого сервиса все что надо.
Смотри так же https://oauth.net/2/
Здравствуйте, sushko, Вы писали:
S>По команде пользователя (щелчку по ссылке) система А, в которой аутентифицирован пользователь, связывается с системой Б, куда он хочет получить доступ, напрямую, т.е. мимо пользователя, и говорит, что пользователь хочет получить доступ. В ответ система Б генерит одноразовый входной билет с ограниченным временем жизни (в простейшем случае случайное число) и передает его системе А, после чего система А редиректит пользователя в систему Б с этим входным билетом (www.systemB.ru/login.php?token=12345.
Насчет одноразового токена это правильно только не надо именно по нему аутентифицировать. Это только id запроса на аутентификацию. То есть система Б,в которой пользователь еще не аутентифицирован, говорит пользователю — вот тебе токен иди с ним в А скажи ей кто ты и возвращайся. А запоминает, приходил пользователь с токеном, он и он юзер1. Пользователь возвращается в Б, говорит готово, вот токен который мне дали. Б спрашивает у А инфу по этому токену. Воровать токен смысла нет особого, он привязан к сессии пользователя в Б.
Сессию понятно тоже надо защищать но это другая история.
Здравствуйте, GarryIV, Вы писали:
GIV>Насчет одноразового токена это правильно только не надо именно по нему аутентифицировать. Это только id запроса на аутентификацию. То есть система Б,в которой пользователь еще не аутентифицирован, говорит пользователю — вот тебе токен иди с ним в А скажи ей кто ты и возвращайся. А запоминает, приходил пользователь с токеном, он и он юзер1. Пользователь возвращается в Б, говорит готово, вот токен который мне дали. Б спрашивает у А инфу по этому токену. Воровать токен смысла нет особого, он привязан к сессии пользователя в Б.
Ваша история не соответствует условиям задачи: Пользователь УЖЕ аутентифицирован на А к моменту начала работы, ему на А с токеном ходить незачем.
Я недавно решал похожую задачу — при переходе генерируется токен, в котором зашифрован user id, ip address и timestamp. Простая реализация и, имхо, достаточно хорошая безопасность. История, логи и тд не помогут, т.к. токен уже давно истечёт, а если кто-то там в реалтайме перехватывает, тут уже всё перехватят (ну и, возможно, даже в этом случае проверка ip address поможет). Никаких сложных схем городить не надо, тупо зашифровал AES-ом и всё, полностью stateless система получается.
Вообще по идее никаких проблем переходить через POST нет. Просто делай не ссылку, а форму с action на другом сайте. Браузеру особой разницы нет.
Здравствуйте, sushko, Вы писали: GIV>>Насчет одноразового токена это правильно только не надо именно по нему аутентифицировать. Это только id запроса на аутентификацию. То есть система Б,в которой пользователь еще не аутентифицирован, говорит пользователю — вот тебе токен иди с ним в А скажи ей кто ты и возвращайся. А запоминает, приходил пользователь с токеном, он и он юзер1. Пользователь возвращается в Б, говорит готово, вот токен который мне дали. Б спрашивает у А инфу по этому токену. Воровать токен смысла нет особого, он привязан к сессии пользователя в Б. S>Ваша история не соответствует условиям задачи: Пользователь УЖЕ аутентифицирован на А к моменту начала работы, ему на А с токеном ходить незачем.
Все так, Б просит пользователя аутентифицироваться в А. Так как юзер в А уже аутентифицирован он будет просто перенаправлен обратно в Б. Токен нужен, именно по нему потом Б проверят факт аутентификации.
Почитай как SSO делается.
Здравствуйте, sushko, Вы писали:
S>По команде пользователя (щелчку по ссылке) система А, в которой аутентифицирован пользователь, связывается с системой Б, куда он хочет получить доступ, напрямую, т.е. мимо пользователя, и говорит, что пользователь хочет получить доступ. В ответ система Б генерит одноразовый входной билет с ограниченным временем жизни (в простейшем случае случайное число) и передает его системе А, после чего система А редиректит пользователя в систему Б с этим входным билетом (www.systemB.ru/login.php?token=12345. После входа пользователя в систему Б с таким билетом пользователь аутентифицируется в Б, а билет уничтожается. Также билет уничтожается в случае, если не был использован в течении, скажем, 10 секунд после генерации.
это похоже на реализацию OAuth с авторизационным кодом, проблема в том, что в OAuth просто код авторизации не считается надежным, там клиент еще дополнительно отсылает секрет, таким образом гарантируя что токен хочет получить именно тот, кто сделал изначальный редайрект.
Здравствуйте, GarryIV, Вы писали:
GIV>Насчет одноразового токена это правильно только не надо именно по нему аутентифицировать. Это только id запроса на аутентификацию. То есть система Б,в которой пользователь еще не аутентифицирован, говорит пользователю — вот тебе токен иди с ним в А скажи ей кто ты и возвращайся. А запоминает, приходил пользователь с токеном, он и он юзер1. Пользователь возвращается в Б, говорит готово, вот токен который мне дали. Б спрашивает у А инфу по этому токену. Воровать токен смысла нет особого, он привязан к сессии пользователя в Б.
тут ничего не понял. Система Б генерит код, который передается в А? На каком основании А знает что запрос от Б лигитимный? Это может быть запрос от хакера
Здравствуйте, Stalker., Вы писали:
GIV>>Насчет одноразового токена это правильно только не надо именно по нему аутентифицировать. Это только id запроса на аутентификацию. То есть система Б,в которой пользователь еще не аутентифицирован, говорит пользователю — вот тебе токен иди с ним в А скажи ей кто ты и возвращайся. А запоминает, приходил пользователь с токеном, он и он юзер1. Пользователь возвращается в Б, говорит готово, вот токен который мне дали. Б спрашивает у А инфу по этому токену. Воровать токен смысла нет особого, он привязан к сессии пользователя в Б.
S>тут ничего не понял. Система Б генерит код, который передается в А? На каком основании А знает что запрос от Б лигитимный? Это может быть запрос от хакера
Ну положим от хакера. Дальше что?
С блекджеком и женщинами это вырастает в OAuth2. Я только за, сразу его советовал.
