Где хранить токены

Как хранить токены?

Есть вариант хранить токены в базе данных, но нужно будет запускать крон, на удаления устаревших токенов. Плюс ко всему скорость доступа к базе данных ниже чем к memcache или redis (правдe пишу?).

Если бы это был просто сайт, то можно было бы хранить в сессии, а так я разрабатываю api. Соответственно нету куков, к которой привязать сессию.

Как быть? я склоняюсь к тому, чтобы хранить в redis. Плюсы, минусы?

pisipu
24.03.16 22:00:36 MSK

Если чисто токены хранить типа key = value то минусов в redis не вижу.

И ещё, токены токенами, а жить они сколько будут и какова максимальная частота запросов на обновления токена для данного id будет разрешена?

redis отдаёт быстро, но если будут миллиарды токенов и разрешено бесконечное в сутки колличество обновлений то тут хз.

Dron ★★★★★
( 24.03.16 22:12:22 MSK )
Последнее исправление: Dron 24.03.16 22:15:58 MSK (всего исправлений: 1)

Ответ на: комментарий от Dron 24.03.16 22:12:22 MSK

хорошо, еще одно: в каком формате их хранить? Редис хранит в формате ключ = значения. Ключ может быть один, а мне нужно для каждого пользователя отдельно.

То есть я не могу хранить как token = 3jfj43u34tj34jg433. 343rggw Нужно хранить как token = 3jfj43u34tj34jg433. 343rggw

Вот где взять это id? Или пусть id будет 3jfj43u34tj34jg433. 343rggw? Тогда ключ будет слишком большой — ничего страшного?

pisipu
( 24.03.16 22:28:15 MSK ) автор топика
Ответ на: комментарий от pisipu 24.03.16 22:28:15 MSK

Тогда получай ключ конкатенацией — token:id скажем. Или используй HASH’и, если id для одного токена не будет слишком много.

Suntechnic ★★★★★
( 25.03.16 02:05:30 MSK )

Плюс ко всему скорость доступа к базе данных ниже чем к memcache или redis (правдe пишу?).

Нет, ты можешь хранить все в памяти и дальше будешь терять только несколько мс оверхеда в pgsql/mysql на разбор твоего запроса.

Как быть? я склоняюсь к тому, чтобы хранить в redis. Плюсы, минусы?

Лучше в zookeeper если у тебя что-то более или менее распределенное.

Защита JWT для аутентификации, httpOnly cookies, CSRF-токены

Часто говорят: Не храните токены в локальном хранилище (или хранилище сессий). Если какой-либо сторонний скрипт, который вы включаете в свою страницу, будет взломан, он сможет получить доступ ко всем токенам ваших пользователей.

localStorage действительно небезопасен. Но если не в localStorage, то где хранить токены пользователя?

Некоторые добавляют: JWT нужно хранить внутри httpOnly cookie — особого типа cookie, который отправляется только в HTTP-запросах к серверу и никогда не доступен (как для чтения, так и для записи) из JavaScript, запущенного в браузере.

Хорошая идея. Смотрим раздел использования HTTP cookies в MDN , чтобы узнать, что такое httpOnly cookie. httpOnly — это атрибут, добавляемый к cookies, который делает их недоступными на стороне клиента.

Хорошо. Как хранить JWT в куках httpOnly? Поиск в Google выдал эту статью Райана Ченки .

Он говорит, что существует два варианта безопасного хранения JWT:

1. Память браузера (состояние React) — супербезопасно. Однако, если пользователь обновит браузер, JWT будет потерян, и вход потребуется снова. Не лучший пользовательский опыт.
2. httpOnly cookie.

Конечная точка логина должена сгенерировать JWT и сохранить его в cookie:

res.cookie('token', token, < httpOnly: true >);

token предварительно генерируется в коде библиотекой (например jsonwebtoken ). httpOnly: true — это как раз то, что делает cookie невидимым для клиента. Когда httpOnly был установлен на false , мы можем получить доступ к содержимому куки в консоли с помощью document.cookie . Установка httpOnly: true предотвращает это.

Проблема в том, что клиент и сервер могут работать на разных портах, к примеру на localhost:3000 и localhost:5000 при разработке. Не существует такого понятия, как кросс-доменные куки — куки могут быть установлены только в том же домене, что и сервер. Как это обойти?

Если создать своего клиента с помощью Create-React-App, то мы можем использовать проксирование . Можно добавить например «proxy»: «http://localhost:4000» в package.json, таким образом мы ставим URL для API, к которому необходимо делать вызовы. Теперь путь будет относительным (т.е. вместо $/auth/login мы используем /auth/login ), этого достаточно.

После этого ответы от сервера станут приходить с заголовком Set-cookie , и можно будет увидеть Cookie в Chrome Dev Tools.

Как говорит Райан, Теперь, когда JWT находится в cookie, он будет автоматически отправляться API при любом обращении к нему. Так браузер ведет себя по умолчанию.

Следующий вопрос: как защитить маршруты, когда маркер хранится в cookie?

По определению, куки httpOnly не могут быть доступны клиенту, так как же мы можем защитить маршруты после того, как пользователь вошел в систему? Кто-то предложил идею в этом вопросе на StackOverflow . По сути, вы продолжаете генерировать httpOnly: true cookie, содержащий токен, и генерируете еще один, httpOnly: false , на этот раз без конфиденциальной информации, который только информирует о том, что пользователь вошел в систему. Следуя этой логике, вам даже не нужен cookie: получив успешный ответ API на вход, вы можете сохранить loggedIn: true в localStorage .

Итак, вы можете проверить куки httpOnly: false (или localStorage) и определить, вошел ли пользователь в систему или нет. Если нет, перенаправить на страницу авторизации.

А как получить доступ к cookie в React?

Конечно, есть два пути: воспользоваться библиотекой (например js-cookie ) или сделать это самостоятельно.

Ок, нам необходимо защитить маршруты, чтобы доступ к ним могли получить только те пользователи, которые вошли в систему (у которых cookie isLoggedIn имеет значение true ).

Думаю, многие понимают как создать , можно почитать статью Тайлера МакГинниса , она идеально подходит в качестве пошагового руководства.

const PrivateRoute = (< render: Component, . rest >) => ( render= Cookie.get('isLoggedIn') === 'true' ? ( /> ) : ( ) > /> );

Можно использовать PrivateRoute для защиты своего роута:

 ( shortUrl= setShortUrl= /> )> />

render: Component изнально был component: Component , потому что именно такой синтаксис пишут в туториалах. Однако это не работает, и может ввести в ступор. Можно прочитать этот ответ и понять, что ключ должен соответствовать атрибуту, который вы передаете в Route. Так, если вы передаете component= , то Private Route должен иметь component: Component . Если мой маршрут имеет render= , приватный маршрут должен иметь render: Component .

Следующий вопрос: как выйти из системы?

Поскольку cookie с маркером имеет значение httpOnly: true , он не будет доступен на клиенте, поэтому нам нужно, чтобы сервер удалил его. Как кто-то указал в этом вопросе на StackOverflow , вы можете обновить cookie на стороне сервера, просто оставив его пустым или забив его каким-нибудь мусором, также стоит не забыть поставить прошедшую дату экспирации.

В итоге, получаем на сервере что-то вроде:

res.cookie('token', 'deleted', < httpOnly: true >); res.cookie('isLoggedIn', false);

Есть что-то еще?

Боюсь, что да. Райан говорит о добавлении защиты от подделки межсайтовых запросов и добавлении анти-CSRF токена.

Что такое атака Cross Site Request Forgery

Здесь можно почитать на эту тему. Смысл таков: злоумышленник создает HTTP-запрос к некоторому сервису (например, к вашему счету в ebank), который спрятан внутри вредоносного сайта. Вас могут обманом заманить на этот сайт, и этот сайт может отправить HTTP-запрос. Суть атаки в том, что, поскольку вы аутентифицированы, вместе с запросом передаются куки аутентификации, и для сервера запрос является валидным.

Как известно, существуют меры защиты, которые должен предпринять сервер для защиты от этих атак: строгая политика CORS (при необходимости разрешая запросы только от определенных источников) и CSRF-токены.

Что такое токен CSRF

Здесь и здесь можно прочитать про этот токен. CSRF-токен на стороне сервера можно сгенерировать с помощью библиотеки csurf , и, после передачи клиенту в поле ответа, он устанавливается в качестве заголовка к каждому AJAX-запросу, который вы делаете к вашему серверу. Вы должны генерировать маркер как можно раньше в вашем приложении на сервере, потому что проверка CSRF происходит в middleware, которое размещается как можно раньше на сервере. Рекомендуют делать это следующим образом:

1. useEffect в React App обращается к серверу для получения CSRF-токена по определенному пути. Этот токен генерируется библиотекой (например csurf ).
2. Токен возвращается в поле ответа, а секретная часть, для проверки того что токен не был подделан, возвращается в виде cookie. Первый должен быть установлен в качестве заголовка к каждому последующему AJAX-запросу с помощью axios.default.headers.post[‘X-CSRF-Token] ‘. Второй должен быть возвращен клиенту как httpOnly и securecookie . Отправляется это дело в заголовке Set-cookie , и куки должны быть добавлены в каждый последующий запрос клиента.

Вроде все, но есть еще одна проблема. Предлагается создать конечную точку (endpoint), которая отправляет токен клиенту. Однако, если вы перейдете на страницу npm библиотеки csurf , там есть заголовок со ссылкой на эту страницу: Понимание CSRF, раздел о CSRF-токенах . Они говорят Не создавайте маршрут /csrf только для того, чтобы получить токен, и особенно не поддерживайте CORS на этом маршруте!

Очевидно, многие задаются этим вопросом — см. примеры здесь или здесь . У каждого программиста, похоже, есть свой способ. Многие согласны с тем, что не существует идеального решения.

Есть интересная статья Харлина Манна, где он объясняет, как снизить риски при использовании куки для хранения JWT, советую почитать.

Однако это еще не все!

И Райан , и Харлин говорят, что самым безопасным методом является хранение JWT в памяти и использование маркеров обновления.

Если есть возможность, храните JWT в состоянии приложения и обновляйте их либо через центральный сервер авторизации, либо с помощью refresh-токен в cookie.

LocalStorage vs Cookies: все, что нужно знать о безопасном хранении токенов JWT во Front-End

В переводе статьи LocalStorage vs Cookies: All You Need To Know About Storing JWT Tokens Securely in The Front-End, опубликованном webdevblog.ru, даются рекомендации по хранению и использованию JWT-токенов. Если кратко резюмировать статью, то в ней рекомендуется полученные от бекенда access токены хранить в приложение, а refresh токены — в куках. А вот если хотите узнать, почему именно такие рекомендации — читайте статью.

Токены JWT замечательны, но как их надежно хранить на фронтенде? Мы рассмотрим плюсы и минусы LocalStorage и cookie для хранения JWT.

Краткий обзор Access token и Refresh token

Токены доступа (Access token) обычно являются недолговечными токенами JWT, подписанными сервером и включенными в каждый HTTP-запрос к серверу для авторизации запроса.

Токены обновления (Refresh token) обычно представляют собой долговечные зашифрованные токенами JWT, хранящиеся в базе данных, которые используются для получения нового токена доступа по истечении срока его действия.

Где лучше хранить свои токены?

Существует два распространенных способа хранения токенов: в localStorage и в cookie. Есть много споров о том, какой из них лучше, но большинство людей склоняются к cookie из-за большей безопасности.

Давайте рассмотрим это сравнение чуть более подробнее.

Local Storage

Плюсы: Это удобно.

• Это чистый JavaScript и с ним удобней работать. Если у вас нет бэкэнда и вы полагаетесь на стороннее API, вы не всегда сможете установить определенные cookie для вашего приложения.
• Работает с API-интерфейсами, которые требуют, чтобы вы поместили свой токен доступа в заголовок запроса, типа такого Authorization Bearer $ .

Минусы: Такой способ уязвим к XSS атакам.

Атака XSS происходит, когда злоумышленник может запустить свой скрипт JavaScript на вашем сайте во время посещения его другим пользователем. Это означает, что злоумышленник сможет получит доступ к токену доступа, который вы сохранили в localStorage.

Cookies

Плюсы: Файл cookie может быть не доступен через JavaScript, поэтому он не так уязвим для атак XSS, как localStorage.

• Если вы используете флаги httpOnly, то cookie будут не доступны из JavaScript. Это означает, что даже если злоумышленник сможет запустить JS на сайте, он не сможет прочитать ваш токен доступа.
• Cookie автоматически отправляется в каждом HTTP-запросе на ваш сервер.

Минусы: В зависимости от варианта использования иногда вы не сможете хранить свои токены в файлах cookie..

• Размер файлов cookie ограничен 4 КБ, поэтому, если вы используете большие токены JWT, сохранение в файле cookie станет не возможным.
• Существуют сценарии, когда вы не можете использовать cookie напрямую для доступа к серверному API. Например когда требуется наличие токена в заголовке запроса.

Кратко о XSS атаках

Итак мы уже сказали что local storage уязвим, так как он легко доступен с помощью JavaScript, и злоумышленник может получить access token и использовать его. Однако, хотя cookie с httpOnly недоступны из JavaScript, это не означает, что с помощью cookie вы полностью защищены от XSS атак.

Если злоумышленник может запустить JavaScript в вашем приложении, он все равно сможет отправить HTTP-запрос на ваш сервер получив таким образом все токены. Но для злоумышленника это менее удобно, потому что он не сможет прочитать содержимое токена, хотя это и не всегда нужно.

Cookies и CSRF Атаки

CSRF Attack — это атака, которая позволяет сделать запрос от имени пользователя но без его ведома. Например, если веб-сайт принимает запрос на изменение электронной почты через такой запрос:POST /email/change HTTP/1.1Host: site.comContent-Type: application/x-www-form-urlencodedContent-Length: 50Cookie: session=abcdefghijklmnopqrstuemail=myemail.example.com

То злоумышленник может легко создать форму на вредоносном веб-сайте, которая отправит POST запрос на https://site.com/email/change со скрытым полем электронной почты, и cookie с токенами будут автоматически включены в этот запрос.

Однако это можно легко исправить, используя флаг cookie sameSite и добавив anti-CSRF token.

Вывод

Хотя куки все еще имеют некоторые уязвимости, они предпочтительнее по сравнению с localStorage, когда их применение возможно. И вот почему?

• Как localStorage, так и cookie уязвимы для атак XSS, но злоумышленнику сложнее выполнить эту атаку, когда вы используете cookie с httpOnly.
• Cookie уязвимы для атак CSRF, но их вероятность можно уменьшить с помощью флага sameSite и токенов защиты от CSRF (anti-CSRF tokens).
• Вы все еще можете использовать cookie, даже если вам нужно использовать заголовок Authorization: Bearer или ваш JWT больше 4 КБ. Это также согласуется с рекомендацией сообщества OWASP:

Итак, как мне использовать куки для сохранения моих токенов OAuth 2.0?

Напомним, вот несколько способов хранения ваших токенов:

• Вариант 1: Хранение Access Token в localStorage: но это выбор уязвим к XSS атакам.
• Вариант 2: Хранение Access Token в cookie с httpOnly: но этот выбор будет уязвим к CSRF атакам, хотя его можно уменьшить, что лучше чем XSS.
• Вариант 3: Хранение Refresh Token в cookie c httpOnly: это будет безопасно от CSRF атак, и немного лучше от XSS.

Мы рассмотрим, Вариант 3, так как он предлагает лучшие преимущества из трех вариантов.

Сохранять Access Token в памяти приложения а Refresh Token в cookie.

Шаг 1: Пользователь получает Access Token и Refresh Token когда проходит аутентификацию.

После аутентификации пользователя Сервер авторизации отдает пользователю access_token и refresh_token. Access_token может быть включен в тело ответа, refresh_token должен быть включен только в cookie.

Свойства токена в cookie:

• Используйте флаг httpOnly, чтобы из JavaScript не было возможности прочитать его.
• Используйте флаг secure = true, чтобы его можно было отправлять только через HTTPS.
• По возможности используйте флаг SameSite = strict, чтобы предотвратить CSRF атаки. Но это можно использовать только в том случае, если у сервера авторизации тот же домен, что и у клиентского приложения. Если это не так, ваш Сервер авторизации должен установить нужные заголовки CORS в серверной части или использовать другие методы, чтобы гарантировать, что запрос на обновление токена может быть выполнен только авторизованными веб-сайтами.

Шаг 2: Сохраните Access Token в памяти

Хранение токена в памяти означает, что вы поместили этот токен доступа в соответствующую переменную в своем приложение. Да, это означает, что access token исчезнет, если пользователь переключит вкладки или обновит страницу. Вот зачем у нас есть refresh token.

Шаг 3: Обновляйте access token, используя refresh token

Когда access token token пропадет или срок его действия истечет, используйте серверное API для получения нового токена используя refresh token, который был сохранен в cookie в шаге 1, и будет включен в каждый запрос (то есть сервер получит его через cookie ). После получения нового access token сможете использовать его для своих запросов API.

Это означает, что ваш токен JWT может быть больше 4 КБ, и вы также можете поместить его в заголовок авторизации.

Заключение

Если вы создаете механизм авторизации для своего веб-сайта или мобильного приложения, эти статьи могут помочь:

• What On Earth Is OAuth? A Super Simple Intro to OAuth 2.0, Access Tokens, and How to Implement it in your Site
• Passwordless Login with Email and JSON Web Token (JWT) Authentication using Next.js
• Here’s How to Integrate Cotter’s Magic Link to Your Webflow Site in Less Than 15 minutes!

Локальное хранилище или куки? Безопасное хранение JWT на клиенте

JWT (JSON Web Token) — это замечательный стандарт, основанный на формате JSON, позволяющий создавать токены доступа, обычно используемые для аутентификации в клиент-серверных приложениях. При использовании этих токенов возникает вопрос о том, как безопасно хранить их во фронтенд-части приложения. Этот вопрос нужно решить сразу же после того, как токен сгенерирован на сервере и передан клиентской части приложения.

Материал, перевод которого мы сегодня публикуем, посвящён разбору плюсов и минусов использования локального хранилища браузера ( localStorage ) и куки-файлов для хранения JWT.

Виды токенов

• Токены доступа (access tokens) обычно представляют собой короткоживущие JWT, подписанные сервером. Они включаются в каждый HTTP-запрос, выполняемый клиентом к серверу. Токены используются для авторизации запросов.
• Токены обновления (refresh tokens) обычно представлены долгоживущими токенами, хранящимися в базе данных и используемыми для получения нового токена доступа при истечении срока действия предыдущего токена.

Где именно следует хранить токены на клиенте?

Существует 2 распространённых способа хранения токенов на клиенте: локальное хранилище браузера и куки-файлы. О том, какой способ лучше, много спорят. Большинство людей склоняется в сторону куки-файлов из-за их лучшей защищённости.

Давайте сравним локальное хранилище и куки-файлы. Наше сравнение основано, преимущественно, на этом материале и на комментариях к нему.

Локальное хранилище

▍Преимущества

Основное преимущество локального хранилища заключается в том, что им удобно пользоваться.

• Работа с локальным хранилищем организована очень удобно, тут используется чистый JavaScript. Если у вашего приложения нет бэкенда, и вы полагаетесь на чужие API, не всегда можно запросить у этих API установку особых куки-файлов для вашего сайта.
• Используя локальное хранилище, удобно работать с API, которые требуют размещать токен доступа в заголовок запроса. Например — так: Authorization Bearer $ .

▍Недостатки

Главный недостаток локального хранилища — это его уязвимость к XSS-атакам.

• При выполнении XSS-атаки злоумышленник может запустить свой JavaScript-код на вашем сайте. Это означает, что атакующий может получить доступ к токену доступа, сохранённому в localStorage .
• Источником XSS-атаки может быть сторонний JavaScript-код, включённый в состав вашего сайта. Это может быть что-то вроде React, Vue, jQuery, скрипта Google Analytics и так далее. В современных условиях почти невозможно разработать сайт, в состав которого не входят библиотеки сторонних разработчиков.

Куки-файлы

▍Преимущества

Главное преимущество куки-файлов заключается в том, что они недоступны из JavaScript. В результате они не так уязвимы к XSS-атакам, как локальное хранилище.

• Если вы используете флаг HttpOnly и защищённые куки-файлы, это означает, что из JavaScript нельзя получить доступ к этим файлам. То есть, если даже атакующий сможет запустить свой код на вашей странице, ему не удастся прочитать токен доступа из куки-файла.
• Куки автоматически отправляются в каждом HTTP-запросе к серверу.

▍Недостатки

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

• Размер куки-файлов ограничен 4 Кб. Поэтому, если вы используете большие JWT, хранение их в куки-файлах вам не подойдёт.
• Существуют сценарии, при реализации которых вы не можете передавать куки своему API-серверу. Возможно и то, что какой-то API требует размещения токена в заголовке Authorization . В таком случае вы не сможете хранить токены в куки-файлах.

XSS-атаки

Локальное хранилище уязвимо к XSS-атакам из-за того, что с ним очень легко работать, используя JavaScript. Поэтому злоумышленник может получить доступ к токену и воспользоваться им в своих интересах. Однако, хотя HttpOnly-куки и недостижимы из JavaScript, это не означает, что вы, используя куки, защищены от XSS-атак, направленных на кражу токена доступа.

Если атакующий может запускать свой JS-код в вашем приложении, это значит, что он может просто отправить вашему серверу запрос, а токен будет включён в этот запрос автоматически. Такая схема работы просто не так удобна для атакующего, так как он не может прочитать содержимое токена. Но подобное нужно атакующим нечасто. Кроме того, при такой схеме работы злоумышленнику может быть выгоднее атаковать сервер, пользуясь компьютером жертвы, а не собственным.

Куки-файлы и CSRF-атаки

CSRF-атаки — это атаки, в ходе которых пользователя каким-то образом принуждают к выполнению особого запроса. Например, сайт принимает запросы на изменение адреса электронной почты:

POST /email/change HTTP/1.1 Host: site.com Content-Type: application/x-www-form-urlencoded Content-Length: 50 Cookie: session=abcdefghijklmnopqrstu email=myemail.example.com 

В такой ситуации атакующий может создать форму со скрытым полем для ввода адреса электронной почты, которая отправляет POST-запрос на https://site.com/email/change . При этом сессионные куки автоматически будут включены в такой запрос.

Правда, от этой угрозы можно легко защититься, использовав атрибут SameSite в заголовке ответа и анти-CSRF токены.

Промежуточные итоги

Хотя и куки-файлы не отличаются полной неуязвимостью к атакам, для хранения токенов лучше всего, всегда, когда это возможно, выбирать именно их, а не localStorage . Почему?

• И локальное хранилище, и куки уязвимы к XSS-атакам, но злоумышленнику будет сложнее совершить атаку в том случае, если используются HttpOnly-куки.
• Куки уязвимы к CSRF-атакам, но риск таких атак можно смягчить, используя атрибут SameSite и анти-CSRF токены.

Использование куки-файлов для хранения токенов OAuth 2.0

Давайте кратко перечислим способы хранения токенов:

• Способ 1: хранение токенов в локальном хранилище. Этот способ подвержен XSS-атакам.
• Способ 2: хранение токенов в HttpOnly-куки. Этот способ подвержен CSRF-атакам, но риск подобных атак может быть смягчён. От XSS-атак этот вариант хранения токенов защищён немного лучше первого.
• Способ 3: хранение токенов обновления в HttpOnly-куки, а токенов доступа — в памяти. Этот способ хранения токенов безопаснее в плане CSRF-атак и немного лучше защищён от XSS-атак.

Почему хранение токена обновления в HttpOnly-куки безопаснее с точки зрения CSRF-атак?

Злоумышленник может создать форму, которая обращается к /refresh_token . В ответ на этот запрос возвращается новый токен доступа. Но атакующий не может прочитать ответ в том случае, если он использует HTML-форму. Для того чтобы не дать атакующему успешно выполнять fetch- или AJAX-запросы и читать ответы, нужно, чтобы CORS-политика сервера авторизации была бы настроена правильно, а именно — так, чтобы сервер не реагировал бы на запросы от неавторизованных веб-сайтов.

Как всё это настроить?

Шаг 1: возврат токена доступа и токена обновления при аутентификации пользователя

После того, как пользователь аутентифицируется, сервер аутентификации возвращает access_token (токен доступа) и refresh_token (токен обновления). Токен доступа будет включён в тело ответа, а токен обновления — в куки.

Вот что нужно использовать для настройки куки-файлов, предназначенных для хранения токенов обновления:

• Флаг HttpOnly — чтобы не дать прочесть токен из JavaScript.
• Флаг secure=true , что приведёт к тому, что данные будут передаваться только по HTTPS.
• Флаг SameSite=strict нужно использовать всегда, когда это возможно, что позволит защититься от CSRF-атак. Этот подход может использоваться только в том случае, если сервер авторизации относится к тому же сайту, что и фронтенд системы. Если это не так, тогда сервер авторизации должен устанавливать CORS-заголовки на бэкенде, или использовать другие методы для того чтобы убедиться в том, что запрос с токеном обновления может быть выполнен только авторизованным веб-сайтом.

Шаг 2: сохранение токена доступа в памяти

Хранение токена доступа в памяти означает, что токен, в коде фронтенда, записывают в переменную. Это, конечно, означает, что токен будет утерян в том случае, если пользователь закроет вкладку, на которой открыт сайт, или обновит страницу. Именно поэтому у нас имеется токен обновления.

Шаг 3: получение нового токена доступа с использованием токена обновления

Если токен доступа оказывается утраченным или недействительным, нужно обратиться к конечной точке /refresh_token . При этом токен обновления, который, на шаге 1, был сохранён в куки-файле, будет включён в запрос. После этого вы получите новый токен доступа, который сможете использовать для выполнения запросов к API.

Всё это значит, что JWT могут быть больше 4 Кб, и то, что их можно помещать в заголовок Authorization .

Итоги

То, о чём мы тут рассказали, должно дать вам базовую информацию о хранении JWT на клиенте, и о том, как сделать ваш проект безопаснее.

Как вы храните JWT на клиенте?

• безопасность
• разработка