Skip to content

Instantly share code, notes, and snippets.

@zmts
Last active March 27, 2024 08:12
Star You must be signed in to star a gist
Save zmts/802dc9c3510d79fd40f9dc38a12bccfc to your computer and use it in GitHub Desktop.
Про токены, JSON Web Tokens (JWT), аутентификацию и авторизацию. Token-Based Authentication

Про токены, JSON Web Tokens (JWT), аутентификацию и авторизацию. Token-Based Authentication

Last major update: 25.08.2020

  • Что такое авторизация/аутентификация
  • Где хранить токены
  • Как ставить куки ?
  • Процесс логина
  • Процесс рефреш токенов
  • Кража токенов/Механизм контроля токенов
  • Зачем все это ? JWT vs Cookie sessions

Основа:

Аутентификация(authentication, от греч. αὐθεντικός [authentikos] – реальный, подлинный; от αὐθέντης [authentes] – автор) - это процесс проверки учётных данных пользователя (логин/пароль). Проверка подлинности пользователя путём сравнения введённого им логина/пароля с данными сохранёнными в базе данных.

Авторизация(authorization — разрешение, уполномочивание) - это проверка прав пользователя на доступ к определенным ресурсам.

Например, после аутентификации юзер sasha получает право обращаться и получать от ресурса "super.com/vip" некие данные. Во время обращения юзера sasha к ресурсу vip система авторизации проверит имеет ли право юзер обращаться к этому ресурсу (проще говоря переходить по неким разрешенным ссылкам)

  1. Юзер c емайлом sasha_gmail.com успешно прошел аутентификацию
  2. Сервер посмотрел в БД какая роль у юзера
  3. Сервер сгенерил юзеру токен с указанной ролью
  4. Юзер заходит на некий ресурс используя полученный токен
  5. Сервер смотрит на права(роль) юзера в токене и соответственно пропускает или отсекает запрос

Собственно п.5 и есть процесс авторизации.

Дабы не путаться с понятиями Authentication/Authorization можно использовать псевдонимы checkPassword/checkAccess(я так сделал в своей API)

JSON Web Token (JWT) — содержит три блока, разделенных точками: заголовок(header), набор полей (payload) и сигнатуру. Первые два блока представлены в JSON-формате и дополнительно закодированы в формат base64. Набор полей содержит произвольные пары имя/значения, притом стандарт JWT определяет несколько зарезервированных имен (iss, aud, exp и другие). Сигнатура может генерироваться при помощи и симметричных алгоритмов шифрования, и асимметричных. Кроме того, существует отдельный стандарт, отписывающий формат зашифрованного JWT-токена.

Пример подписанного JWT токена (после декодирования 1 и 2 блоков):

{ alg: "HS256", typ: "JWT" }.{ iss: "auth.myservice.com", aud: "myservice.com", exp: 1435937883, userName: "John Smith", userRole: "Admin" }.S9Zs/8/uEGGTVVtLggFTizCsMtwOJnRhjaQ2BMUQhcY

Токены предоставляют собой средство авторизации для каждого запроса от клиента к серверу. Токены(и соответственно сигнатура токена) генерируются на сервере основываясь на секретном ключе(который хранится на сервере) и payload'e. Токен в итоге хранится на клиенте и используется при необходимости авторизации какого-либо запроса. Такое решение отлично подходит при разработке SPA.

При попытке хакером подменить данные в header'ре или payload'е, токен станет не валидным, поскольку сигнатура не будет соответствовать изначальным значениям. А возможность сгенерировать новую сигнатуру у хакера отсутствует, поскольку секретный ключ для зашифровки лежит на сервере.

access token - используется для авторизации запросов и хранения дополнительной информации о пользователе (аля user_id, user_role или еще что либо, эту информацию также называет payload). Все поля в payload это свободный набор полей необходимый для реализации вашей частной бизнес логики. То бишь user_id и user_role не являются требованием и представляют собой исключительно частный случай. Сам токен храним не в localStorage как это обычно делают, а в памяти клиентского приложения (что приводит к необходимости при каждом обновлении странички браузера запрашивать новую пару токенов).

refresh token - выдается сервером по результам успешной аутентификации и используется для получения новой пары access/refresh токенов. Храним исключительно в httpOnly куке.

Каждый токен имеет свой срок жизни, например access: 30 мин, refresh: 60 дней

Поскольку токены(а данном случае access) это не зашифрованная информация крайне не рекомендуется хранить в них какую либо sensitive data (passwords, payment credentials, etc...)

Роль рефреш токенов и зачем их хранить в БД. Рефреш на сервере хранится для учета доступа и инвалидации краденых токенов. Таким образом сервер наверняка знает о клиентах которым стоит доверять(кому позволено авторизоваться). Если не хранить рефреш токен в БД то велика вероятность того что токены будут бесконтрольно гулять по рукам злоумышленников. Для отслеживания которых нам придется заводить черный список и периодически чистить его от просроченных. В место этого мы храним лимитированный список белых токенов для каждого юзера отдельно и в случае кражи у нас уже есть механизм противодействия(описано ниже).

Как ставить куки ?

Для того что бы refreshToken кука была успешно уставленна и отправлена браузером, адреса эндпоинтов аутентификации(/api/auth/login, /api/auth/refresh-tokens, /api/auth/logout) должны располагася в доменном пространстве сайта. Тоесть для домена super.com на сервере ставим куку с такими опциями:

{
    domain: '.super.com',
    path: '/api/auth'
}

Таким образом кука установится в браузер и прийдет на все эндпоинты по адресу super.com/api/auth/<any-path>

Если у нас монолит и за аутентификацию отвечает один и тот-же API, тут проблем не должно быть. Но если за аутентификацию отвечает отдельный микросервис, прячем его средствами nginx по выше указанному пути (super.com/api/auth).

# пример настройки nginx конфига(только основые настройки)
server {
    listen 80;
    server_name super.com;
    # SPA/Front-end
    location / {
        try_files $uri /index.html;
        root /var/www/frontend/dist;
        index index.html;
    }
    # Main API
    location /api {
        proxy_pass http://111.111.111.111:7000;
    }
    # Auth API
    location /api/auth {
        proxy_redirect http://222.222.222.222:7000   /auth/;
        proxy_pass http://222.222.222.222:7000;
    }
}

Логин, создание сессии/токенов (api/auth/login):

  1. Пользователь логинится в приложении, передавая логин/пароль и fingerprint браузера (ну или некий иной уникальный идентификатор устройства если это не браузер)
  2. Сервер проверят подлинность логина/пароля
  3. В случае удачи создает и записывает сессию в БД { userId: uuid, refreshToken: uuid, expiresIn: int, fingerprint: string, ... } (схема таблицы ниже)
  4. Создает access token
  5. Отправляет клиенту access и refresh token uuid (взятый из выше созданной сессии)
Set-Cookie: refreshToken='c84f18a2-c6c7-4850-be15-93f9cbaef3b3'; HttpOnly // для браузера
{
  body: { 
    accessToken: 'eyJhbGciOiJIUzUxMiIsI...',
    refreshToken: 'c84f18a2-c6c7-4850-be15-93f9cbaef3b3' // для мобильных приложений
  }
}
  1. Клиент сохраняет токены(access в памяти приложения, refresh сетится как кука автоматом)

На что нужно обратить внимание при установке refresh куки:

  • maxAge куки ставим равную expiresIn из выше созданной сессии
  • В path ставим корневой роут auth контроллера (/api/auth) это важно, таким образом токен получат только те хендлеры которым он нужен(/api/auth/logout и /api/auth/rerfesh-tokens), остальные обойдутся(нечего зря почём отправлять sensitive data).

Стоит заметить, что процесс добавления сессии в таблицу должен имеет свои меры безопасности. При добавлении стоит проверять сколько рефреш-сессий всего есть у юзера и, если их слишком много или юзер конектится одновременно из нескольких подсетей, стоит предпринять меры. Имплементируя данную проверку, я проверяю только что бы юзер имел максимум до 5 одновременных рефреш-сессий максимум, и при попытке установить следующую удаляю предыдущие. Все остальные проверки на ваше усмотрение в зависимости от задачи.

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

Перед каждым запросом клиент предварительно проверяет время жизни access token'а (да берем expiresIn прямо из JWT в клиентском приложении) и если оно истекло шлет запрос на обновление токенов. Для большей уверенности можем обновлять токены на несколько секунд раньше. То есть кейс когда API получит истекший access токен практически исключен.

Что такое fingerprint ? Это инструмент отслеживания браузера вне зависимости от желания пользователя быть идентифицированным. Это хеш сгенерированный js'ом на базе неких уникальных параметров/компонентов браузера. Преимущество fingerprint'a в том что он нигде персистентно не хранится и генерируется только в момент логина и рефреша.

В случае если клиент не браузер, а мобильное приложение, в качестве fingerprint используем любую уникальную строку(тот же uuid) персистентно хранящуюся на устройстве.

Рефреш токенов (api/auth/refresh-tokens):

Для использования возможности аутентификации на более чем одном девайсе необходимо хранить все рефреш токены по каждому юзеру. Я храню это список в PostgreSQL таблице(а надо бы в Redis'е). В процессе каждого логина создается запись с IP/Fingerprint и другой мета информацией, так званая рефреш-сессия.

CREATE TABLE refreshSessions (
    "id" SERIAL PRIMARY KEY,
    "userId" uuid REFERENCES users(id) ON DELETE CASCADE,
    "refreshToken" uuid NOT NULL,
    "ua" character varying(200) NOT NULL, /* user-agent */
    "fingerprint" character varying(200) NOT NULL,
    "ip" character varying(15) NOT NULL,
    "expiresIn" bigint NOT NULL,
    "createdAt" timestamp with time zone NOT NULL DEFAULT now()
);
  1. Клиент(фронтенд) проверяет перед запросом не истекло ли время жизни access token'на
  2. Если истекло клиент делает запрос на POST auth/refresh-tokens { fingerprint: string } в body и соответственно refreshToken куку.
  3. Сервер получает запись рефреш-сессии по UUID'у рефреш токена
  4. Сохраняет текущую рефреш-сессию в переменную и удаляет ее из таблицы
  5. Проверяет текущую рефреш-сессию:
    1. Не истекло ли время жизни
    2. На соответствие старого fingerprint'a полученного из текущей рефреш-сессии с новым полученным из тела запроса
  6. В случае негативного результата бросает ошибку TOKEN_EXPIRED/INVALID_REFRESH_SESSION
  7. В случае успеха создает новую рефреш-сессию и записывает ее в БД
  8. Создает access token
  9. Отправляет клиенту access и refresh token uuid (взятый из выше созданной рефреш-сессии)
Set-Cookie: refreshToken='c84f18a2-c6c7-4850-be15-93f9cbaef3b3'; HttpOnly // для браузера
{
  body: { 
    accessToken: 'eyJhbGciOiJIUzUxMiIsI...',
    refreshToken: 'c84f18a2-c6c7-4850-be15-93f9cbaef3b3' // для мобильных приложений
  }
}

Tip: Для отправки запроса с куками для axios есть опция { withCredentials: true }

Ключевой момент:

В момент рефреша то есть обновления access token'a обновляются ОБА токена. Но как же refresh token может сам себя обновить, он ведь создается только после успешной аутентификации ? refresh token в момент рефреша сравнивает себя с тем refresh token'ом который лежит в БД и вслучае успеха, а также если у него не истек срок, система рефрешит токены.

Вопрос зачем refresh token'y срок жизни, если он обновляется каждый раз при обновлении access token'a ? Это сделано на случай, если юзер будет в офлайне более 60 дней, тогда придется заново вбить логин/пароль.

Logout (api/auth/logout)

  1. Front-end делает кол POST: api/auth/logout c refreshToken в куке или бади (лучше в куки)
  2. Front-end удаляет локально сохраненный в памяти accessToken
  3. Back-end удаляет запись из таблицы refreshSessions по refreshToken

accessToken умирает по истечению строка его жизни. Руками банить, удалять, хранить accessToken не нужно, это нарушает всю суть эксесс токена.

В случае кражи access токена и refresh куки:

  1. Хакер воспользовался access token'ом
  2. Закончилось время жизни access token'на
  3. Клиент хакера отправляет refresh token и fingerprint
  4. Сервер смотрит fingerprint хакера
  5. Сервер не находит fingerprint хакера в рефреш-сессии и удаляет ее из БД
  6. Сервер логирует попытку несанкционированного обновления токенов
  7. Сервер перенаправляет хакера на станицу логина. Хакер идет лесом
  8. Юзер пробует зайти на сервер >> обнаруживается что refresh token отсутствует
  9. Сервер перенаправляет юзера на форму аутентификации
  10. Юзер вводит логин/пароль

В случае кражи access токена, refresh куки и fingerprint'а:

Стащить все авторизационные данные это не из легких задач, но все же допустим этот кейс как крайний и наиболее неудобный с точки зрения UX (без примера в кодовой базе supra-api-nodejs).

Предложу несколько вариантов решения данной проблемы:

  • Хранить IP или Subnet залогиненного клиента
  1. Хакер воспользовался access token'ом
  2. Закончилось время жизни access token'на
  3. Хакер отправляет refresh куку и fingerprint
  4. Сервер проверяет IP хакера, хакер идет лесом

UX минус: нужно логинится с каждого нового IP.

  • Удалять все сессии в случае если refresh токен не найден
  1. Хакер воспользовался access token'ом
  2. Закончилось время жизни access token'на
  3. Хакер отправляет refresh куку и fingerprint
  4. На сервере создается новый refresh токен ("от хакера")
  5. Хакер получает новую пару токенов
  6. Юзер пробует отправить запрос на сервер >> обнаруживается что refresh токен не валиден
  7. Сервер удаляет все сессии юзера, в последствии чего хакер больше не сможет обновлять access токен
  8. Сервер создает новую сессию для пользователя

UX минус: в каждом случае когда сервер не будет находить рефреш токен - будут сбрасиватся все сессии юзера на всех устройствах.

Зачем все это ? JWT vs Cookie sessions

Зачем этот весь геморой ? Почему не юзать старые добрые cookie sessions ? Чем не угодили куки ?

  • Куки подвержены CSRF: https://habr.com/ru/company/oleg-bunin/blog/412855 https://www.youtube.com/watch?v=x5AuK_IbJlg
  • Нативыным приложениям для сматфонов удобнее работать с токенами. Да есть хаки для работы с куки, но это не нативная поддержка
  • Куки в микросерисной архитектуре использовать не вариант. Напомню зачастую микросервисы раскиданы на разных доменах, а куки не поддерживают кросc-доменные запросы
  • В микросерисной архитектуре JWT позволяет каждому сервису независимо от сервера авторизации верифицировать access токен (через публичный ключ)
  • При использовании cookie sessions программист зачастую надеется на то, что предоставил фреймворк и оставляет как есть
  • При использовании jwt мы видим проблему с безопасностью и стараемся предусмотреть механизмы контроля в случае каржи авторизационных данных. При использовании cookie сессий программист зачастую даже не задумывается что сессия может быть скомпрометирована
  • На каждом запросе использование JWT избавляет бекенд от одного запроса в БД(или кеш) за данными пользователя(userId, email, etc.)

В итоге:

  • access токены храним исключительно в памяти клиентского приложения. Не в глобально доступной переменной аля window.accessToken а в замыкании
  • refresh токен храним исключительно в httpOnly куке
  • Механизмы контроля при угоне sensitive data в наличии
  • Взяли лучшее из обеих технологий, максимально обезопасились от CSRF/XSS
  • Добавьте в компанию ко всему CSP заголовки и SameSite=Strict флаг для кук и ждите прихода злодеев

p.s. Каждой задаче свой подход. Юзайте в небольших/средних монолитах cookie sessions и не парьтесь. Ну или на ваш вкус :)


Имплементация:

Front-end:

Back-end:

Info:

And why JWT is bad


Комментарии периодически подчищаются

@pantuchy
Copy link

pantuchy commented Jun 9, 2022

Очень хорошая статья, спасибо!

Еще как вариант, можно генерить fingerprint на сервере, из мета заголовков запроса (sec-ch-ua, user-agent, accept-language и т.д.).

Алгоритм:

  1. генерим fingerprint при логине на сервере (хеш от мета заголовков)
  2. записываем fingerprint в payload accessToken
  3. записываем fingerprint в базу рядом с refreshToken
  4. как только клиент присылает accessToken, выдергиваем из него fingerprint и сравниваем с хешем от мета заголовков текущего запроса. Если совпадает - авторизуем, иначе отправляем на логин
  5. как только клиент обновляет refreshToken, достаем fingerprint из базы и сравниваем с хешем от мета заголовков текущего запроса
    Если совпадает - возвращаем следующую пару токенов, иначе удаляем refreshToken из базы и отправляем на логин

Плюсы:

  1. accessToken теперь просто так угнать не получится. Злоумышленнику нужно иметь в точности такую же систему, или же подделать заголовки (что менее очевидно, нежели, если fingerprint передавать в body, как в вашем примере)
  2. поскольку fingerprint генерится на сервере, клиент ничего про него не знает. Соответственно, злоумышленник не сможет его перехватить

Более подробно можно почитать здесь: https://g-booking.medium.com/jwt-fingerprint-tokens-af56215bb19a

Благодарю, очень полезная статья.

@leviskay
Copy link

leviskay commented Oct 1, 2022

Добрый день. А как быть с SSR? Прокидывать куки в одну и другую сторону при refresh или делать refresh только на клиенте?

@Devoter
Copy link

Devoter commented Oct 1, 2022

Добрый день. А как быть с SSR? Прокидывать куки в одну и другую сторону при refresh или делать refresh только на клиенте?

Хранить куки только на клиенте, а сервер фронта использовать как middleware, то есть подставлять в запросы куки с клиента и в случае ошибки авторизации отправлять ошибку на клиента - пусть разбирается.

@reslear
Copy link

reslear commented Nov 4, 2022

Очень хорошая статья, спасибо!

Еще как вариант, можно генерить fingerprint на сервере, из мета заголовков запроса (sec-ch-ua, user-agent, accept-language и т.д.).

Алгоритм:

  1. генерим fingerprint при логине на сервере (хеш от мета заголовков)
  2. записываем fingerprint в payload accessToken
  3. записываем fingerprint в базу рядом с refreshToken
  4. как только клиент присылает accessToken, выдергиваем из него fingerprint и сравниваем с хешем от мета заголовков текущего запроса. Если совпадает - авторизуем, иначе отправляем на логин
  5. как только клиент обновляет refreshToken, достаем fingerprint из базы и сравниваем с хешем от мета заголовков текущего запроса
    Если совпадает - возвращаем следующую пару токенов, иначе удаляем refreshToken из базы и отправляем на логин

Плюсы:

  1. accessToken теперь просто так угнать не получится. Злоумышленнику нужно иметь в точности такую же систему, или же подделать заголовки (что менее очевидно, нежели, если fingerprint передавать в body, как в вашем примере)
  2. поскольку fingerprint генерится на сервере, клиент ничего про него не знает. Соответственно, злоумышленник не сможет его перехватить

Более подробно можно почитать здесь: https://g-booking.medium.com/jwt-fingerprint-tokens-af56215bb19a

а вот это похоже на реализацию для express - https://github.com/yusukeshib/express-fingerprint

@reslear
Copy link

reslear commented Nov 4, 2022

В мобильном приложении access token храним в памяти приложения, так при выгрузке приложения из памяти, или перезагрузке access token теряется. А refresh token храним либо в текстовом файле в директории приложения, либо в SQLite базе данных которое использует ваше приложения. В первом случае, доступ к файлу будет иметь только ваше приложение, если только нет ROOT, во втором случае SQLite имеет возможность шифрования данных. По деректория для IOS можно почитать тут https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html При первом запуске приложения или при рестарте проверяем наличие refresh token - а в текстовом файле, или в бд приложения, если он есть, то пытаемся получить access token. При успешном получении открываем главный интерфейс приложения, при отсутствии refresh token открываем интерфейс аутентификации/регистрации.

так можно и https://developer.apple.com/documentation/foundation/userdefaults для ios или https://developer.android.com/reference/android/content/SharedPreferences android
или общую https://capacitorjs.com/docs/apis/preferences

@MakStashkevich
Copy link

Я не до конца уловил идею с fingerprint, если мы отправляем его в теле запроса, значит его можно легко перехватить. А если его можно перехватить, значит что он есть, что его нету, разницы не особо много.

Объясните, почему в статье предлагается делать лишние проверки и махинации, как на беке, так и на фронте с fingerprint'ом? Я в упор не понимаю...

@reslear
Copy link

reslear commented Nov 25, 2022

@MakStashkevich можно еще хэшировать токены и проверять хэш как предлагают тут, можно еще что-то придумать во всяком случае либо это требуется по политике безопасности или это уменьшает шансы, по факту сам jwt может иметь эксплоиты, поэтому все на ваше усмотрение)

@oonsamyi
Copy link

Я не до конца уловил идею с fingerprint, если мы отправляем его в теле запроса, значит его можно легко перехватить. А если его можно перехватить, значит что он есть, что его нету, разницы не особо много.

Объясните, почему в статье предлагается делать лишние проверки и махинации, как на беке, так и на фронте с fingerprint'ом? Я в упор не понимаю...

На фронте генерить фингерпринт и передавать на бек не целесообразно
А вот на беке на основе юзер агента и геолокации по айпи (geoip-lite в помощь) - самое то

Выше скидывали пакет https://github.com/yusukeshib/express-fingerprint, который этим занимается

@JoCat
Copy link

JoCat commented Dec 12, 2022

Как можно обезопасить пользователя в этот период жизни access_token'a? Довольно маловероятная ситуация что токен украли и тут же смогли им воспользоваться, но все же. Если refresh_token можно отозвать (удалить из БД) то access_token ревокнуть никак нельзя (в бд не хранится ведь).

Можно. Например, access token может хранить в payload id сессии, этот id добавляем в black list на время жизни превышающее время жизни access token, при каждом запросе проверяем список. Другой вариант - хранить все сессии в том же редисе и проверять на соответствие сессии, правда, тогда это уже совсем ничем не будет отличаться от классической схемы.

Я решил это так: при logout записываю accessToken в редиску в blacklist с ttl на оставшееся время действия токена, а при запросах проверяю наличие токена в blacklist. Если он есть - не даю дальше пройти. Решение конечно спорное, мб имеет смысл сохранять токены в памяти приложения, чтобы не лезть лишний раз в редиску. Но тогда придётся самому реализовывать ttl и кэширование в какой-нибудь файлик, чтобы не терять чёрный список в случае рестарта приложения.

@neverovski
Copy link

neverovski commented Dec 16, 2022

Как можно обезопасить пользователя в этот период жизни access_token'a? Довольно маловероятная ситуация что токен украли и тут же смогли им воспользоваться, но все же. Если refresh_token можно отозвать (удалить из БД) то access_token ревокнуть никак нельзя (в бд не хранится ведь).

Можно. Например, access token может хранить в payload id сессии, этот id добавляем в black list на время жизни превышающее время жизни access token, при каждом запросе проверяем список. Другой вариант - хранить все сессии в том же редисе и проверять на соответствие сессии, правда, тогда это уже совсем ничем не будет отличаться от классической схемы.

Я решил это так: при logout записываю accessToken в редиску в blacklist с ttl на оставшееся время действия токена, а при запросах проверяю наличие токена в blacklist. Если он есть - не даю дальше пройти. Решение конечно спорное, мб имеет смысл сохранять токены в памяти приложения, чтобы не лезть лишний раз в редиску. Но тогда придётся самому реализовывать ttl и кэширование в какой-нибудь файлик, чтобы не терять чёрный список в случае рестарта приложения.

Как по мне, хорошее решение хранить id сессии в редисе и при запросе проверять валидность токена, нет ли его в blacklist. Ну и плюс по возможности делать срок действия access token как можно меньше

@JoCat
Copy link

JoCat commented Dec 16, 2022

Как по мне, хорошее решение хранить id сессии в редисе и при запросе проверять валидность токена, нет ли его в blacklist. Ну и плюс по возможности делать срок действия access token как можно меньше

Ну у меня по сути так же, только нет сессий и id как таковых, я храню сами токены и при запросах проверяю их валидность и нет ли их в blacklist

@fesor
Copy link

fesor commented Jan 25, 2023

Добавлю пару ссылок. Часть в "And why JWT is bad" и это плохой заголовок. "Why JWT bad for session".

For years we talked about the dangers of using cookies for authentication of API calls for frontend applications. Access token were the future. Except that they turned out to not be. With modern browsers being more strict with cookies and the challenge of keeping a browser environment secure it turns out that cookies actually is the future after all.

Я не к тому что бы не юзать JWT, у него есть свои кейсы

  • использование эксес токенов в docker registry - достаточно удачный протокол для того что бы делегировать авторизацию третьей стороне. Похожий подход можно применять много для чего, при условии короткоживущих (а то и одноразовых для одной операции) токенов можно сделать и безопасно и не привязывать решение к конкретной реализации аутентификации и авторизации
  • схема с рефреш токенами в целом подходит для кейсов общения серверов где рефреш токены можно хранить безопасно. Всякие oauth и прочее.
  • OpenID для сессий с куками, access token для приложения. Но это больше в сторону необходимости SSO федерации и т.д.
  • по сути то где хорошо ложатся всякие HMAC (в том числе за счет стандартов типа jwkset и прочего в комбинации с ассиметричной криптографией)

@fls-dev
Copy link

fls-dev commented Mar 3, 2023

Хорошая статья, второй раз ее нахожу, в поисках чтобы еще придумать с авторизацией в новых проектах)
Доходчиво и понятно расписано, автору респект!

@surebrec
Copy link

surebrec commented Apr 7, 2023

дак JWT это все-таки аутентификация или авторизация? или и то и другое? я так понимаю, аутентификация уже произошла, когда токен создался. и дальше мы, прикрепляя токен, просто подтверждаем право на доступ к чему-то (хотя сам токен может не содержать никаких ролей, а только UserID)

@leviskay
Copy link

leviskay commented Apr 8, 2023

дак JWT это все-таки аутентификация или авторизация? или и то и другое? я так понимаю, аутентификация уже произошла, когда токен создался. и дальше мы, прикрепляя токен, просто подтверждаем право на доступ к чему-то (хотя сам токен может не содержать никаких ролей, а только UserID)

@surebrec , Использование токенов - это по прежнему аутентификация. Просто до этого для аутентификации использовалась связка логин/пароль, так как ей может обладать только определенный человек. Теперь же используется токен, которым тоже может обладать только кто-то конкретный. Всего лишь способ аутентификации.

@oroojtatiev
Copy link

При хранении токена в памяти приложения, токен будет теряться по обновлению страницы.
Ребята пишут про передачу ID токена клиенту. Возникает вопрос:
У redis нет ID записи, когда мы записываем refreshToken в redis. Прибегать к рандомно генерированным ID?

ОК, допустим передали tokenId при аутентификации, этот tokenId фронтенд ведь тоже должен хранить где то в localStorage, чтобы не потерять. Но это опять приведет к уязвимости

@reslear
Copy link

reslear commented Jun 26, 2023

При хранении токена в памяти приложения, токен будет теряться по обновлению страницы. Ребята пишут про передачу ID токена клиенту. Возникает вопрос: У redis нет ID записи, когда мы записываем refreshToken в redis. Прибегать к рандомно генерированным ID?

ОК, допустим передали tokenId при аутентификации, этот tokenId фронтенд ведь тоже должен хранить где то в localStorage, чтобы не потерять. Но это опять приведет к уязвимости

  1. в этом то и прикол что токен должен каждый раз когда теряется из памяти, через refresh получать новый access и даже в новых запросах если уже expired делать форк и ещё один запрос на получение нового access (супер готовое решение для axios https://github.com/Flyrell/axios-auth-refresh ).
  2. в Redis, да генерируй UUID, можно и сессию конкретному пользователю сделать с его ключами вот пример на одном из моих проектов

Screenshot 2023-06-26 at 15 45 10

  1. Да должен но не access, а refresh, поэтому в статье есть пункт по дополнительным мерам безопасности в идеале использовать cookies, но к сожалению не очень юзабельно с capacitor ionic (хотя я ещё не пробовал https://capacitorjs.com/docs/apis/cookies ) В целом по поводу уязвимостей если попадется какой нибуть хацкер то ничего не поможет, а это покрывает как минимум 94% кейсов.

@oroojtatiev
Copy link

oroojtatiev commented Jun 26, 2023

@reslear

  1. В принципе, верно, даже у Google Firebase Authorization реализован такой же подход: каждый раз запускается метод getIdToken(forceRefresh) при обновлении страницы (и accessToken каждый раз записывать в память на клиенте). Просто гугл не генерит новый токен, если он не истек (Returns the current token if it has not expired. Otherwise, this will refresh the token and return a new one)

  2. По-ходу refreshTokenId из сессии фронтенд может доставать медотодом sessionStorage.getItem('whoami')?
    Сессия ведь встраивается в браузер в Application -> Session Storage. Этот айди думаю нужно отправлять в запросе рефреша, чтобы бек знал какой именно refreshToken следует обновить.
    Да токен ID можно вообще вроде хранить в самом jwt токене и потом тупо декодить его вместе с expirationAt на фронте

  3. RefreshToken не в localStorage хранить, а в Cookies sameSite, по статье

  4. Правильно ли я понимаю, что в редисе следует хранить список accessToken-ов с пометкой на их актуальность, а также хранить refreshToken на их актуальность тоже?
    И при logout и accessToken и refreshToken делать в редисе не валидными (добавлять в черный список).

@reslear
Copy link

reslear commented Jun 26, 2023

@reslear

  1. В принципе, верно, даже у Google Firebase Authorization реализован такой же подход: каждый раз запускается метод getIdToken(forceRefresh) при обновлении страницы (и accessToken каждый раз записывать в память на клиенте). Просто гугл не генерит новый токен, если он не истек (Returns the current token if it has not expired. Otherwise, this will refresh the token and return a new one)
  2. По-ходу refreshTokenId из сессии фронтенд может доставать медотодом sessionStorage.getItem('whoami')?
    Сессия ведь встраивается в браузер в Application -> Session Storage. Этот айди думаю нужно отправлять в запросе рефреша, чтобы бек знал какой именно refreshToken следует обновить.
    Да токен ID можно вообще вроде хранить в самом jwt токене и потом тупо декодить его вместе с expirationAt на фронте
  3. RefreshToken не в localStorage хранить, а в Cookies sameSite, по статье
  4. Правильно ли я понимаю, что в редисе следует хранить список accessToken-ов с пометкой на их актуальность, а также хранить refreshToken на их актуальность тоже?
    И при logout и accessToken и refreshToken делать в редисе не валидными (добавлять в черный список).
  1. Я думал об этом, но мне показалось проще удалять сесию и ставить на неё на всякий случай EX, и при logout просто удалять эти сессии, потом проверка нет сесси нет входа, но это не уместно если тебе нужно как телеграме/инст/vk - log сессий где когда с каго устройства и ручная кнопка удаления, тогда да - маркер.

@zardan4
Copy link

zardan4 commented Aug 6, 2023

If anyone is interested, I tried to make a scheme for this article. I'm not guru in creating something like this, but I did it to better understand JWT concept.
Link: https://gist.github.com/zardan4/48c00e31e732f465ca34173b703ff1a6

@reslear
Copy link

reslear commented Sep 29, 2023

кстати жаль что я уже все реализовал как потом нашел готовое решение https://github.com/lucia-auth/lucia

@Miskler
Copy link

Miskler commented Dec 10, 2023

Огромное уважение автору! Мало что есть по этой теме, тем более так структурированно(

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

Скажите. А как жить с таким подходом, если позволяется работа с более чем одной вкладкой? Ведь access token хранится в памяти и у каждой страницы он свой (так будет получаться) + при refresh-е токенов мы сам refresh token тоже обновляем, но с ним проблем +- не будет ибо он в куке лежит и его браузер синхронизирует. Но вопрос с access token-ом остается. Ведь в него вшивается refresh token, что бы находить сессию в бд и если refresh token обновился (и выдали новый access), то старый access token со старым refresh-ем уже не прокатит.

@zmts
Copy link
Author

zmts commented Jan 9, 2024

@Tsyklop Я храню refresh токен в пейлоаде access токена для необходимости обеспечить инвалидацию акксес токена в том случае если рефтокен(по которому акксес был выдан) был удален.

  1. Если у вас сервис не так требователен к безопасности удалите рефтокен из ексеса и возможно если данные не секретные по положите их в пейлоад еккеса
  2. Или как вариант положите все что нужно в access токен и зашифруйте его еще раз каким-то аля aes-256-cbc алгоритмом
  • Для обоих вариантов увеличьте количество одновременных сессий

@Devoter
Copy link

Devoter commented Jan 9, 2024

@zmts А в чем безопасность? Разве смысл не в том, чтобы refresh токен передавать только в момент обновления access токен? Да и время жизни refresh токена должно быть больше. Подпись JWT не обеспечивает безопасности и шифрования, она лишь обеспечивает возможность проверки корректности токена.

@Devoter
Copy link

Devoter commented Jan 9, 2024

@zmts Все равно странно. Access и refresh выдаются вместе, а не один от другого. Должен быть какой-то приватный ключ (общий для всех пользователей или отдельный для каждого), по которому генерируются токены. Причем, при обновлении access токена выдаётся и новый refresh. Понятно, что реализации разными могут быть - это здесь и обсуждается. Также можно добавлять в список вручную отозванных токенов банально по времени валидации и пользователю, тогда не придется хранить список сессий на сервере. То есть, прилетает запрос, смотрим начало действия и время жизни токена и сверяемся с базой отозванных токенов, можно ещё какой-нибудь уникальный идентификатор добавлять, дабы можно было инвалидировать отдельные устройства пользования, но тут уже детали.

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

@zmts Не совсем понял. То бишь что бы данный подход работал с несколькими вкладками, то нужно допустить несколько сессия с одинаковым fingerprint-ом? Если 10 вкладок открыл - 10 записей? особенность в том что refresh токен общий для всех. И это проблема. Ведь в бд храним refresh token.

@LuchkinDS
Copy link

@Tsyklop а как у вас обычная сессия работает, для каждой вкладки отдельная? токен хранится не памяти, а в localStorage или в куке.

@berdos1989
Copy link

berdos1989 commented Jan 9, 2024

Я храню refresh токен в пейлоаде access токена

@zmts

Зачем? Чтобы если кто то получит твой access token он получит и refresh token? Зачем тогда вообще иметь 2 токена? хватит 1 access.

Присоединюсь к вопросам @Devoter

Вообще вы ребята куда то не туда свернули. Храните токен в куки http only (защитит от xss) и не придумываете глупости)
Топ уязвимость это все равно использование секретного ключа "secret" для подписи hmac256)

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

@LuchkinDS refresh токен хранится в куке, а access токен в памяти. Даже если хранить в localStorage проблемы нескольких вкладок это не решает.

@Devoter
Copy link

Devoter commented Jan 9, 2024

@Tsyklop Решали подобный вопрос в рамках приложения. Если токены не в куках, то хранили токены в local storage. Нужно делать немного нетривиально. Добавляем в обработку запросов перехват ошибки 401 и проверяем - совпадают ли текущие токены с токенами в local storage. Если нет - берём оттуда и пробуем заново, если да - делаем refresh-запрос и обновляем данные в local storage. Казалось бы, все просто, но нужно как-то синхронизировать это дело между вкладками. И здесь на помощь приходить очередь из обещаний. Если получили ошибку 401, то вызываем функцию-перехватчик, назовем ее refresh. В ней проверяем длину очереди, если очередь пуста, то создаем создаём промис с запросом на обновление токенов и кладём ждуна в очередь. По кончанию запроса данные обновляются в local storege. Очередь должна быть обернута в промис. Таким образом, если послали несколько запросов подряд и получили ошибку, то рефреш выполнится только один раз, остальнве запросы на вкладке будут ждать результата. Можно, конечно, класть перед запросом в тот же local storage какой-нибудь флаг а-ля refreshing, но с учётом крайне низкой вероятности того, что запрос refresh будет выполняться одновременно на нескольких вкладках, этими заморочками можно пренебречь. Также не стоит забывать и о том, что в случае неудачного рефреша нужно всё-таки выполнить разлогинивание. В сухом остатке становится очевидно, что реализовывать JWT в браузере через куки для разных доменов гораздо проще и веселесее, чем вручную разруливатт все возможные варианты коллизий при обработке множества запросов во множестве вкладок. А вот для приложения (мобильного, к примеру), ручное хранение токенов на уровне клиента как раз удобно.

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

@LuchkinDS До этого не парился по этому поводу. Но ввели вход с одного устройства и теперь надо парится.

@zmts
Copy link
Author

zmts commented Jan 9, 2024

Я храню refresh токен в пейлоаде access токена

@zmts

Зачем? Чтобы если кто то получит твой access token он получит и refresh token? Зачем тогда вообще иметь 2 токена? хватит 1 access.

Все правильно говорите. Я сделал это для решения проблемы с инвалидацией акксес токена. Решение не фонтан, но проблему закрыло + не зря я написал юзать aes-256-cbc в дополнение

@zmts
Copy link
Author

zmts commented Jan 9, 2024

Даже если хранить в localStorage проблемы нескольких вкладок это не решает.

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

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

@Devoter А у вас при refresh запросе сам refresh token оставался старым или создавался новый? Очень сложно такую логику понять со слов. Код бы облегчил задачу.

Но я вот смотрю в сторону одного токена (jwt или нет) в куку httpOnly. Это универсально для любого кол-ва вкладок. Но вот вопрос в обновлении такой куки - при каких условиях? можно (и нужно мне кажется) использовать fingerprint (или аналог). Но в плане безопасности меня настараживает что если токен угонят из кук - то это доступ к приложению без проблем вообще.

@Devoter
Copy link

Devoter commented Jan 9, 2024

@zmts А в чем небезопасность-то? local storage не шарится между сайтами, да, в рамках одного сайта разные вкладки будут иметь доступ к общему хранилищу, так в том и смысл. О какой безопасности мы говорим, если значения хранятся на клиенте? Вы хотите изолировать каждую из вкладок одного сайта, создавая отдельную сессию под каждую? Если так, что это какой-то крайне специфичный кейс, так как лично я часто разные страницы одного сайта в рамках одной сессии в разных вкладках открываю.

@Tsyklop При реыреше возвращается новая пара, но refresh отдельно не инвалидировался на сервере, варианты реализации для сервера я описал выше. Смысл был как раз показать - насколько муторно разруливать подобные вещи браузерным JS. Для примера потребуется целый проект написать демонстрационный, может, руки и дойдут когда - тогда у ну ссылку на хабр, но как по мне - лучше написать пример реализации через две http-only куки.

Если использовать только одну печеньку, то смысла в JWT и нет, это обычная сессия с автопродлением, которую нужно хранить в базе и как-то иметь возможность отзывать, в противном случае, разовый перехват токена становится большой проблемой, о чем вы сами и написали. Мое мнение такое: для приложений используем пару токенов, передаваемых в теле запроса или в заголовке, управляемых приложением, а в браузере - http-only куки, и пусть он сам разруливает между вкладками.

@Tsyklop
Copy link

Tsyklop commented Jan 9, 2024

@Devoter Две куки это access и refresh токены (jwt)?

@fls-dev
Copy link

fls-dev commented Jan 9, 2024

@Devoter Две куки это access и refresh токены (jwt)?

Вообще обычно так и делают, только как правило refresh только для определенного url фиксируется и уже на стороне сервера проверяется.
А про одно печенье слышал только для защиты от CSRF

@Devoter
Copy link

Devoter commented Jan 10, 2024

@Tsyklop все так. Причем, как сказали выше, refresh фиксируется для отдельного url или домена/поддомене, таким образом, он не отправляется вместе с access при каждом запросе, а лишь при refresh-запросе.

@neverovski
Copy link

@Tsyklop все так. Причем, как сказали выше, refresh фиксируется для отдельного url или домена/поддомене, таким образом, он не отправляется вместе с access при каждом запросе, а лишь при refresh-запросе.

Так же реализовываю, как описали выше. Делаю две куки access и refresh токен, refresh выпускается только для одного url и со значением httpOnly. А для мобилки передаем access и refresh в теле запроса

@zakirovio
Copy link

добрый день. почему в таблице с рефреш сессией добавляется refreshToken в виде uuid, а не сам refresh_token в виде последовательности ASCII?

@khokm
Copy link

khokm commented Mar 23, 2024

@zakirovio нет необходимости хранить в базе весь токен, со всеми его заголовками, payload и подписью - достаточно хранить его идентификатор.

@khokm
Copy link

khokm commented Mar 23, 2024

@Devoter если интересно, проблему с одновременными запросами на Refresh я решаю так:
В базе добавили поле prevRefreshToken и prevRefreshExpiredAt . При выполнении рефреша сюда записывается предыдущий UUID, выглядит это как-то так:

UPDATE session 
SET refreshToken = {newRefreshToken},
prevRefreshToken = {currentRefreshToken}
prevRefreshExpiredAt = {currentDate + 1 minute}
WHERE
refreshToken = {currentRefreshToken}

UPDATE прошел? Отвечаем 200 и возвращаем новую пару токенов - клиент их получит и сохранит.
UPDATE не прошел? Выполняем такой запрос:

SELECT 1 FROM session 
WHERE
prevRefreshToken = {currentRefreshToken}
prevRefreshExpiredAt > {curDate}

Если ОК, то возвращаем просто 204. Клиент здесь просто ничего не делает.
А вот если даже этот запрос не прошел - то только тогда уже 401.

Подводя итог: при отправке 3 одновременных запросов на рефреш:
Первый - получит новые токены;
Второй, третий - не получат ничего

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment