JWT или сессионное печенье для API как для веб-, так и для мобильного приложения?

В последние пару дней я читал всё, что мог, на эту тему, и не могу решить, какой будет лучший подход.

Единственными требованиями являются:

• Мне нужно знать пользователей, которые вошли в систему, и все их сессии, чтобы пользователь мог видеть список с этой информацией и иметь возможность закрыть любую сессию по своему выбору.

• Обе приложения должны использовать одни и те же конечные точки REST API.

Сначала я использовал сессионные файлы cookie и вызывал API с параметром setCredentials=true, но я обнаружил, что мобильные приложения обрабатывают файлы cookie по-другому, и я не имею контроля над этим (например, они удаляются по ряду причин до истечения срока). Я подумал о том, чтобы сохранить файл cookie в локальном хранилище и добавлять его к каждому запросу, но я не могу получить доступ к файлу cookie ни в каком виде, потому что httpOnly установлен в true. Решением было бы установить httpOnly в false, но в этом случае я подставляю файл cookie и не уверен, какие меры безопасности мне следует принять, чтобы защитить его от кражи или подделки.

Другим решением было бы использовать JWT и хранить его в веб/локальном хранилище. Я также сохранил бы в таблице каждый все еще действующий токен (хэшированный с использованием алгоритма паролей), чтобы получить список вошедших пользователей и их сессий, и другую таблицу для недействительных токенов на случай, если пользователь решит завершить конкретную сессию / изменит пароль / и т. д. Но снова я не уверен в мерах безопасности, которые мне следует использовать с этим подходом. Должен ли я также зашифровать токен? Я думал о том, чтобы добавить к нему данные об устройстве, которое запрашивает токен, чтобы всегда проверять, что устройство, которое запрашивало токен, является тем, кто его использует. Что еще мне следует сделать, чтобы защитить этот токен?

Если я правильно реализую любой из этих вариантов, какой из них будет более безопасным как для веба, так и для мобильного?

Прежде чем перейти к деталям, я скажу, что как сессионные файлы cookie, так и JWT работают для вашего случая, и оба являются безопасными если реализованы правильно. Лично я бы выбрал JWT лишь потому, что с ним легче получить актуальную информацию или готовые решения.

JWT

JWT действительно предназначались для безгосударственной авторизации, но вы все равно можете использовать их для сессий. Вам стоит обратить внимание на использование модели токенов доступа/обновления, где вы отслеживаете активные токены обновления в вашей базе данных.

Что касается шифрования, то есть две основные реализации стандарта JWT, а именно JWS (подписанный токен) и JWE (подписанный, затем зашифрованный токен). Что вам следует иметь в виду, так это то, что подпись подписанного токена уже обеспечивает целостность токена. Вы бы реализовали JWE, только если передаете чувствительную информацию в токене, которую хотите скрыть от клиента. Тем не менее, сам по себе JWT не решает проблемы атак типа “человек посередине”, поэтому помните о необходимости использования SSL при передаче токена.

Хранение токена будет отличаться между вашим веб-приложением и мобильным нативным приложением. Для мобильных приложений вам следует хранить их в Keychain/Keystore ОС (скорее всего, через обертку), которая предназначена для этой цели. А вот где хранить JWT в браузере, с другой стороны, остается довольно спорной темой, так как хранение в webstorage (sessionStorage/localStorage) уязвимо для атак XSS, в то время как хранение внутри cookie уязвимо для CSRF.

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

Сессионные файлы cookies

Не зная деталей вашего мобильного приложения, трудно сказать, но из моего опыта, если вы используете механизмы CookieManager/NSHTTPCookieStorage, предоставляемые Google/iOS, не должно быть проблемы с удалением файлов cookie, о которых вы упомянули.

Хранение файлов cookie в браузере потребует от вас защиты от CSRF. То, какую защиту вам следует использовать, будет сильно зависеть от вашей конкретной серверной реализации и ограничений. Я думаю, вам следует ознакомиться с материалами на OWASP или задать более конкретный вопрос.

Я возобновляю старую тему, чтобы предложить, что для веб-приложений вы должны хранить JWT в cookie, чтобы избежать неприятностей при его передаче вручную.

Для локального хранения на устройстве убедитесь, что как мобильное, так и веб-приложения извлекают JWT из API, чтобы сохранить метод шифрования скрытым на мобильной стороне.

В веб-приложении вы можете управлять этим на стороне сервера для повышения безопасности.

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

Риск с файлами cookie заключается в том, что они отправляются с каждым HTTP-запросом на ваш домен, даже если он происходит от поддельного клиента. Это называется CSRF. Если у вас нет какой-либо защиты от CSRF, избегайте файлов cookie и используйте локальное хранилище.

Конечно, если вы не можете доверять всему вашему клиентскому коду, вам потребуется другое решение.

Также, если вы используете HTTPS, идентификаторы сессий, как файлы cookie, так и отправки форм, будут зашифрованы.