Нам всем нравится, что нативные приложения просят вас войти в систему только один раз, а затем запоминают вас, пока вы не скажете им, что хотите выйти. К сожалению, Интернет не всегда работает таким образом.
Теперь, когда устройства, особенно мобильные устройства, стали более персонализированными, а все больше сайтов отправляют весь трафик через HTTPS, что снижает риск кражи токенов, веб-сайтам следует пересмотреть свою политику в отношении недолговечных файлов cookie и перейти на более удобные для пользователя долгоживущие сеансы.
Однако даже если вы хотите , чтобы сеанс длился дольше, некоторые веб-сайты не проверяют аутентификацию пользователя при каждом запросе (другими словами, невозможно отозвать файл cookie сеанса после его создания). Обычно это приводит к коротким сеансам, когда пользователю приходится часто входить в систему, чтобы его аутентификация могла быть повторно подтверждена, что позволяет таким вещам, как смена пароля, аннулировать существующие сеансы через известный промежуток времени.
Если вы используете такой подход, у нас есть техническое решение, которое может помочь вам автоматически повторно проверить файл cookie аутентификации без сохранения состояния. Он работает за счет наличия вторичного долгоживущего токена, который можно использовать для обновления существующего кратковременного файла cookie аутентификации. Использование нового шаблона сервисного работника позволяет нам регулярно «регистрироваться» с помощью долгоживущего токена, проверять аутентификацию пользователя (например, проверять, не изменили ли они недавно свои пароли или иным образом не отозвали сеанс) и повторно выпустить новый недолговечный файл cookie аутентификации.
Практическое предложение по переходу на безопасные длительные сеансы в Интернете.
Отсюда в этом посте описывается новая техника, которую мы предлагаем, и которую мы называем 2-Cookie-Handoff (2CH) . Мы надеемся использовать эту статью, чтобы услышать отзывы сообщества о том, кажется ли этот подход положительным, и если да, то поработать с отраслью над документированием лучших практик использования 2CH.
Сервис-воркеры — это новая технология, поддерживаемая несколькими браузерами, такими как Chrome, Firefox, Opera и скоро появившаяся в Edge . Они позволяют перехватывать все сетевые запросы с вашего сайта через общую точку кода на клиенте, не изменяя существующие страницы. Это позволяет вам настроить «2CH-работника» для вошедших в систему пользователей, который может перехватывать все сетевые запросы, которые делает ваша страница, и выполнять замену токенов, как это делают мобильные приложения.
Большую часть времени на вашем сервере уже есть конечная точка, используемая мобильными приложениями для получения нового кратковременного токена, обычно с использованием протокола OAuth. Чтобы включить описанный выше шаблон в Интернете, эту конечную точку просто необходимо обновить, чтобы она понимала, когда она вызывается сервисным работником, а затем вернуть новый кратковременный файл cookie сеанса, отформатированный так, как уже ожидают другие страницы сайта. .
Если на вашем сервере еще нет такой конечной точки, он может создать ее только для управления сеансами браузера.
![Последовательность передачи двух файлов cookie](https://developer.chrome.com/static/blog/2-cookie-handoff/image/the-2-cookie-handoff-sequ-0b6ed8bf3c1d8.png?authuser=4&hl=ru)
Шаблон с двумя токенами для сервисных работников довольно близко соответствует шаблону OAuth 2.0: если вы уже запустили конечную точку токена OAuth, то вы, вероятно, сможете повторно использовать его с сервисными работниками для вашей веб-аутентификации.
Вам также может быть интересно, что произойдет, если пользователь зайдет в браузер, который не поддерживает сервис-воркеров. Если вы примените описанный выше подход, они просто не почувствуют никакой разницы и продолжат проводить короткие сеансы.
Мы опубликовали пример клиента и бэкэнда . Мы надеемся, что вы попробуете это сами и ответите на опрос об управлении сеансами .
,Нам всем нравится, что нативные приложения просят вас войти в систему только один раз, а затем запоминают вас, пока вы не скажете им, что хотите выйти. К сожалению, Интернет не всегда работает таким образом.
Теперь, когда устройства, особенно мобильные устройства, стали более персонализированными, а все больше сайтов отправляют весь трафик через HTTPS, что снижает риск кражи токенов, веб-сайтам следует пересмотреть свою политику использования недолговечных файлов cookie и перейти на более удобные для пользователя долгоживущие сеансы.
Однако даже если вы хотите , чтобы сеанс длился дольше, некоторые веб-сайты не проверяют аутентификацию пользователя при каждом запросе (другими словами, невозможно отозвать файл cookie сеанса после его создания). Обычно это приводит к коротким сеансам, когда пользователю приходится часто входить в систему, чтобы его аутентификация могла быть подтверждена повторно, что позволяет таким вещам, как смена пароля, аннулировать существующие сеансы через известный промежуток времени.
Если вы используете такой подход, у нас есть техническое решение, которое может помочь вам автоматически повторно проверить файл cookie аутентификации без сохранения состояния. Он работает за счет наличия вторичного долгоживущего токена, который можно использовать для обновления существующего кратковременного файла cookie аутентификации. Использование нового шаблона сервисного работника позволяет нам регулярно «регистрироваться» с помощью долгоживущего токена, проверять аутентификацию пользователя (например, проверять, не изменили ли они недавно свои пароли или иным образом не отозвали сеанс) и повторно выпустить новый недолговечный файл cookie аутентификации.
Практическое предложение по переходу на безопасные длительные сеансы в Интернете.
Отсюда в этом посте описывается новая техника, которую мы предлагаем, и которую мы называем 2-Cookie-Handoff (2CH) . Мы надеемся использовать эту статью, чтобы услышать отзывы сообщества о том, кажется ли этот подход положительным, и если да, то поработать с отраслью над документированием лучших практик использования 2CH.
Сервис-воркеры — это новая технология, поддерживаемая несколькими браузерами, такими как Chrome, Firefox, Opera и скоро появившаяся в Edge . Они позволяют перехватывать все сетевые запросы с вашего сайта через общую точку кода на клиенте, не изменяя существующие страницы. Это позволяет вам настроить «2CH-работника» для вошедших в систему пользователей, который может перехватывать все сетевые запросы, которые делает ваша страница, и выполнять замену токенов, как это делают мобильные приложения.
Большую часть времени на вашем сервере уже есть конечная точка, используемая мобильными приложениями для получения нового кратковременного токена, обычно с использованием протокола OAuth. Чтобы включить описанный выше шаблон в Интернете, эту конечную точку просто необходимо обновить, чтобы она понимала, когда она вызывается сервисным работником, а затем вернуть новый кратковременный файл cookie сеанса, отформатированный так, как уже ожидают другие страницы сайта. .
Если на вашем сервере еще нет такой конечной точки, он может создать ее только для управления сеансами браузера.
![Последовательность передачи двух файлов cookie](https://developer.chrome.com/static/blog/2-cookie-handoff/image/the-2-cookie-handoff-sequ-0b6ed8bf3c1d8.png?authuser=4&hl=ru)
Шаблон с двумя токенами для сервисных работников довольно близко соответствует шаблону OAuth 2.0: если вы уже запустили конечную точку токена OAuth, то вы, вероятно, сможете повторно использовать его с сервисными работниками для вашей веб-аутентификации.
Вам также может быть интересно, что произойдет, если пользователь зайдет в браузер, который не поддерживает сервис-воркеров. Если вы примените описанный выше подход, они просто не почувствуют никакой разницы и продолжат проводить короткие сеансы.
Мы опубликовали пример клиента и бэкэнда . Мы надеемся, что вы попробуете это сами и ответите на опрос об управлении сеансами .