Токен не активен что это

Идентификационный токен и токен доступа: в чем разница?

«Давайте воспользуемся токеном для защиты вызова API. Что мне использовать: ID-токен или Access токен? ID токен мне кажется предпочтительнее. В конце концов, если я знаю, кто является пользователем, я могу принимать более обоснованные решения об авторизации, верно?» Вам когда-нибудь приходилось приводить подобные аргументы? Выбор, основанный на интуиции, может оказаться хорошим, но то, что кажется интуитивным, не всегда верно. В случае ID и Access токенов, имеющих ясные и четко определенные цели, пользоваться ими нужно, исходя из этих соображений. Использование неправильного токена может привести к тому, что ваше решение будет небезопасным. «Что в конце концов изменится? Это всего лишь токены. Я могу использовать их по своему усмотрению. Что такого плохого может случиться?» Давайте подробнее рассмотрим эти два типа токенов, чтобы лучше понять их роль в процессах аутентификации и авторизации.

Что такое идентификационный токен?

ID токен — это артефакт, подтверждающий, что пользователь прошел аутентификацию. Он был представлен OpenID Connect (OIDC), открытым стандартом аутентификации, используемым многими системами идентификации такими, как Google, Facebook и, конечно же, Auth0. Ознакомьтесь с этим документом для получения дополнительных сведений об OpenID Connect. Давайте кратко рассмотрим проблему, которую призван решить OIDC. Рассмотрим следующую схему: Здесь пользователь со своим браузером аутентифицируется через провайдер OpenID и получает доступ к веб-приложению. Результатом процесса аутентификации на основе OpenID Connect является ID токен, который передается приложению в качестве доказательства того, что пользователь прошел аутентификацию. Подтверждение аутентификации пользователя это всего лишь базовое представление об ID токене. Рассмотрим это подробнее. Идентификационный токен JSON Web Token (JWT) — стандартный формат, который позволяет вашему приложению легко проверить его содержимое и убедиться, что оно исходит от ожидаемого эмитента и что никто другой его не менял. Если вы хотите узнать больше о JWT, посмотрите «The JWT Handbook». Проще говоря, пример ID токена выглядит так: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwOi8vbXktZG9tYWluLmF1dGgwLmNvbSIsInN1YiI6
ImF1dGgwfDEyMzQ1NiIsImF1ZCI6IjEyMzRhYmNkZWYiLCJleHAiOjEzMTEyODE5NzAsImlhdCI6MTMxMTI4MDk3MCwibm
FtZSI6IkphbmUgRG 9lIiwiZ2l2ZW5fbmFtZSI6IkphbmUiLCJmYW1pbHlfbmFtZSI6IkRvZSJ9 Конечно, просто «на глазок» это не прочесть, поэтому вам нужно расшифровать его, чтобы увидеть, какой контент содержит JWT. Между прочим, ID токен не зашифрован, а закодирован только в Base 64. Вы можете использовать одну из множества доступных библиотек для его декодирования или самостоятельно проверить его с помощью сайта jwt.io. Не вдаваясь в подробности, соответствующая информация, содержащаяся в указанном выше ID токене, выглядит следующим образом: < "iss": "http://my-domain.auth0.com", "sub": "auth0|123456", "aud": "1234abcdef", "exp": 1311281970, "iat": 1311280970, "name": "Jane Doe", "given_name": "Jane", "family_name": "Doe" >Эти свойства JSON называются «claims (заявки)», и они представляют собой заявления о пользователе и самом токене. Заявки о пользователе позволяют определить его личность. Фактически, спецификации OpenID Connect не требуют, чтобы ID токен содержал заявку о пользователе. В своей минимальной структуре он содержит данные только для аутентификации. Одним из важных требований является «aud» заявка. Оно определяет получателя, то есть веб-приложение, которое должно быть конечным получателем токена. В случае с использованием ID токена, значением «aud» будет Client ID приложения, которое должно использовать токен. Запомните это небольшое уточнение об ограничении целевой информационной системы, поскольку оно поможет вам лучше понять, как в дальнейшем им правильно пользоваться. Идентификационный токен может содержать дополнительную информацию о пользователе: адрес его электронной почты, фотографию, день рождения и т. д. Наконец, возможно, самое важное: ID токен подписывает эмитент своим закрытым ключом. Для вас это гарантия происхождения токена и того, что он не был подделан. Это можно проверить, используя открытый ключ эмитента. Здорово! Теперь вы знаете, что такое идентификационный токен. Но что вы можете с ним делать? Во-первых, он демонстрирует, что пользователь был аутентифицирован организацией, которой вы доверяете (провайдер OpenID), и поэтому вы можете доверять его личным данным. Кроме того, ваше приложение может персонализировать взаимодействие с пользователями, используя данные о пользователе, включенные в ID токен. Например, вы можете показать имя в пользовательском интерфейсе или отобразить сообщение «С наилучшими пожеланиями» в день рождения. Самое интересное в том, что вам не нужно делать дополнительных запросов, поэтому вы можете немного повысить производительность своего приложения.

Что такое токен доступа?

Теперь, когда вы знаете, что такое идентификационный токен, давайте попробуем понять, что такое Access токен. Начнем с описания сценария, в который вписывается токен доступа: На схеме выше клиентское приложение хочет получить доступ к ресурсу, например API или чему-либо еще, что защищено от несанкционированного доступа. Два других элемента на этой диаграмме — это пользователь, который является владельцем ресурса, и сервер авторизации. В этом сценарии Access токен является артефактом, позволяющим клиентскому приложению получить доступ к ресурсу пользователя. Он выдается сервером авторизации после успешной аутентификации пользователя и получения его согласия. В контексте OAuth 2 Access токен позволяет клиентскому приложению получать доступ к определенному ресурсу для выполнения определенных действий от имени пользователя. Что известно как сценарий делегированной авторизации: пользователь делегирует клиентскому приложению доступ к ресурсу от своего имени. Это значит, например, что вы можете от своего имени разрешить приложению LinkedIn доступ к API Twitter для перекрестной публикации на обеих социальных платформах. Заметьте, что вы разрешаете LinkedIn только публиковать свои сообщения в Twitter. Вы не разрешаете ему удалять их, изменять данные вашего профиля или делать что-то еще. Это ограничение очень важно в сценарии делегированной авторизации и достигается с помощью областей действия, или scopes. Области действия — это механизм, позволяющий пользователю авторизовать стороннее приложение для выполнения только определенных операций. Конечно, API, получающий Access токен, должен получить подтверждение, что это в самом деле действительный токен, выпущенный сервером авторизации, которому он доверяет, и принимать решения об авторизации на основе связанной с ним информации. Другими словами, API должен каким-то образом использовать этот токен, чтобы авторизовать клиентское приложение для выполнения желаемой операции с ресурсом. Как следует использовать Access токен для принятия решений об авторизации, зависит от многих факторов: общей архитектуры системы, формата токена и т. д. Например, токен доступа может быть ключом, который позволяет API извлекать необходимую информацию из базы данных, совместно используемую с сервером авторизации, или может напрямую содержать необходимую информацию в закодированном формате. Это значит, что понимание того, как получить необходимую информацию для принятия решений об авторизации, является соглашением между сервером авторизации и сервером ресурсов, то есть API. В спецификации OAuth 2 ничего не говорится о формате Access токена. Это может быть строка в любом формате. Распространенным форматом, используемым для токенов доступа, является JWT, и на данный момент этот стандарт в разработке. Однако это не значит, что Access токены должны быть именно в этом формате. Хорошо! Теперь вы знаете, что такое ID-токен и Access токен. Итак, вы готовы использовать их, не боясь ошибиться. Но подождите. Мне кажется, вы не уверены. Возможно, вам нужна другая информация. Ok. Итак, давайте посмотрим, для чего эти токены не подходят.

Для чего НЕ подходит ID-токен?

Одна из наиболее распространенных ошибок, допускаемых разработчиками при использовании идентификационного токена — это использование его для вызова API. Как сказано выше, ID токен доказывает, что пользователь прошел аутентификацию. В собственном сценарии, то есть в сценарии, в котором клиент и API контролируются вами, вы можете решить, что ваш идентификационный токен подходит для принятия решений об авторизации и, возможно, все, что вам нужно знать — это личность пользователя. Однако даже в этом сценарии безопасность вашего приложения, состоящего из клиента и API, может быть под угрозой. Фактически, не существует механизма, который привязывает ID токен к каналу клиентского API. Если злоумышленнику удастся украсть вашу «личность», он может использовать ее для вызова вашего API как законного клиента. С другой стороны, для Acces токена существует набор методов, известных как ограничение отправителя (sender constraint), которые позволяют привязать токен доступа к определенному отправителю. Это гарантия того, что даже если злоумышленник украдет Access токен, он не сможет использовать его для доступа к вашему API, поскольку токен привязан к клиенту, который изначально его запросил. В сценарии делегированной авторизации, когда сторонний клиент хочет вызвать ваш API, нельзя использовать ID токен для вызова API. Помимо отсутствия механизмов привязки к клиенту есть несколько других причин, по которым этого не следует делать. Если ваш API принимает ID токен в качестве токена авторизации, вы сначала игнорируете предполагаемого получателя, указанного в aud (audience claim). В этом утверждении говорится, что он предназначен для вашего клиентского приложения, а не для сервера ресурсов (т. е. API). Можно подумать, что это всего лишь формальность, но такой подход может повлечь за собой риски для безопасности. Прежде всего, кроме прочих проверок, ваш API не должен принимать токен, который для него не предназначен. Если это произойдет, его безопасность окажется под угрозой. Фактически, если вашему API все равно, предназначен ли для него токен, для доступа к нему может быть использован ID токен, украденный из любого клиентского приложения, может быть использован для доступа к вашему API. Разумеется, для предотвращения несанкционированного доступа, проверка aud — это всего лишь одна из проверок, которую должен выполнять ваш API. Кроме того, вашему идентификатору не будут предоставлены области действия (да, это еще одна боль). Как было сказано ранее, области позволяют пользователю ограничивать операции, которые ваше клиентское приложение может выполнять от их имени. Эти области связаны с Access токеном, чтобы ваш API знал, что может делать клиентское приложение, а что нет. Если ваше клиентское приложение использует ID токен для вызова API, вы игнорируете эту функцию и потенциально разрешаете приложению выполнять действия, не авторизованные пользователем.

Для чего НЕ подходит Access токен?

Что касается Access токена, то он был задуман, чтобы продемонстрировать, что вы авторизованы для доступа к ресурсу, например, для вызова API. Ваше клиентское приложение должно использовать его только с этой целью. Другими словами, Access токен не должен проверяться клиентским приложением. Он предназначен для сервера ресурсов, и клиентское приложение должно обрабатывать Access токены как непрозрачные строки, то есть строки без определенного значения. Даже если вам известен формат Access токена, не следует пытаться интерпретировать его содержимое в клиентском приложении. Как уже говорилось, формат Access токена — это соглашение между сервером авторизации и сервером ресурсов, и клиентское приложение не должно вмешиваться. Подумайте, что может случиться, если однажды формат Access токена изменится. Если ваш клиентский код (client code) проверял этот Access токен, в этом случае он будет тотчас сломан.

Краткий обзор

Путаница с использованием ID и Access токенов очень распространена, и, возможно, трудно понять различия между ними. Может быть, это в основном связано с отсутствием четкого понимания различных целей каждого артефакта, определенных в спецификациях OAuth и OpenID Connect. Кроме того, понимание сценариев, в которых изначально должны были действовать эти артефакты, играет важную роль в предотвращении путаницы при их использовании. Тем не менее, я надеюсь, что теперь эта тема немного прояснилась. В иллюстрации кратко изложено то, что можно и чего нельзя делать с ID и Access токенами: Переведено со статьи, полный текст доступен по ссылке.

Токен авторизации на примере JSON WEB Token

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

Введение

Начнем с того, что важно уметь различать следующие два понятия: аутентификации и авторизации. Именно с помощью этих терминов почти все клиент-серверные приложения основывают разделение прав доступа в своих сервисах.

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

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

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

Еще одно небольшое введение

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

Формальное определение

Приступим наконец к работе самого токена. Как я сказал ранее в качестве токенов наиболее часто рассматривают JSON Web Tokens (JWT) и хотя реализации бывают разные, но токены JWT превратились в некий стандарт, именно поэтому будем рассматривать именно на его примере.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON.

Фактически это просто строка символов (закодированная и подписанная определенными алгоритмами) с некоторой структурой, содержащая полезные данные пользователя, например ID, имя, уровень доступа и так далее. И эта строчка передается клиентом приложению при каждом запросе, когда есть необходимость идентифицировать и понять кто прислал этот запрос.

Принцип работы

Рассмотрим принцип работы клиент серверных приложений, работающих с помощью JWT. Первым делом пользователь проходит аутентификацию, конечно же если не делал этого ранее и в этом есть необходимость, а именно, например, вводит свой логин и пароль. Далее приложение выдаст ему 2 токена: access token и refresh token (для чего нужен второй мы обсудим ниже, сейчас речь идет именно об access token). Пользователь тем или иным способом сохраняет его себе, например, в локальном хранилище или в хранилище сессий. Затем, когда пользователь делает запрос к API приложения он добавляет полученный ранее access token. И наконец наше приложение, получив данный запрос с токеном, проверяет что данный токен действительный (об этой проверке, опять же, ниже), вычитывает полезные данные, которые помогут идентифицировать пользователя и проверить, что он имеет право на запрашиваемые ресурсы. Таким нехитрым образом происходит основная логика работы с JSON Web Tokens.

Структура токена

Пришло время обсудить структуру токена и тем самым лучше разобраться в его работе. Первое что следует отметить, что JWT токен состоит из трех частей, разделенных через точку:

1. Заголовок (header)
2. Полезные данные (playload)
3. Подпись (signature)

Рассмотрим каждую часть по подробнее.

Заголовок

Это первая часть токена. Она служит прежде всего для хранения информации о токене, которая должна рассказать о том, как нам прочитать дальнейшие данные, передаваемые JWT. Заголовок представлен в виде JSON объекта, закодированного в Base64-URL Например:

Если раскодировать данную строку получим:

Заголовок содержит два главных поля: alg и typ. Поле typ служит для информации о типе токена, но как я уже упоминал ранее, что JWT превратился в некий стандарт, то это поле перестало нести особый смысл и служит скорее для целей будущего, если вдруг появится улучшенная версия алгоритма JWT(2.0), которая заменит JWT. Поле alg задает алгоритм шифрования. Обязательный для поддержки всеми реализациями является алгоритм HMAC с использованием SHA-256, или же, как он обозначен в заголовке, HS256. Для работы с этим алгоритмом нужен один секретный ключ, конкретный механизм работы рассмотрим ниже. Для справки можно также отметить, что существует и асимметричный алгоритм, который можно использовать в JWT, например, RS256. Для работы с ним требуется два ключа — открытый и закрытый. Но в данной статье рассмотрим работу с одним закрытым ключом.

Полезные данные

Перейдем наконец к полезным данным. Опять же — это JSON объект, который для удобства и безопасности передачи представляется строкой, закодированной в base64. Наглядный пример полезных данных (playload) токена может быть представлен следующей строкой:

Что в JSON формате представляет собой:

Именно здесь хранится вся полезная информация. Для данной части нет обязательных полей, из наиболее часто встречаемых можно отметить следующие:

iss — используется для указания приложения, из которого отправляется токен.

user_id — для идентификации пользователя в нашем приложении, кому принадлежит токен.

Одной из самых важных характеристик любого токена является время его жизни, которое может быть задано полем exp. По нему происходит проверка, актуален ли токен еще (что происходит, когда токен перестает быть актуальным можно узнать ниже). Как я уже упоминал, токен может помочь с проблемой авторизации, именно в полезных данных мы можем добавить свои поля, которые будут отражать возможности взаимодействия пользователя с нашим приложением. Например, мы можем добавить поле is_admin или же is_preferUser, где можем указать имеет ли пользователь права на те или иные действия, и при каждом новом запросе с легкостью проверять, не противоречат ли запрашиваемые действия с разрешенными. Ну а что же делать, если попробовать изменить токен и указать, например, что мы являемся администраторами, хотя таковыми никогда не были. Здесь мы плавно можем перейти к третьей и заключительной части нашего JWT.

Подпись

На данный момент мы поняли, что пока токен никак не защищен и не зашифрован, и любой может изменить его и тем самым нарушается вообще весь смысл аутентификации. Эту проблему призвана решить последняя часть токена — а именно сигнатура (подпись). Происходит следующее: наше приложение при прохождении пользователем процедуры подтверждения, что он тот за кого себя выдает, генерирует этот самый токен, определяет поля, которые нужны, записывает туда данные, которые характеризуют данного пользователя, а дальше с помощью заранее выбранного алгоритма (который отмечается в заголовке в поле alg токена), например HMAC-SHA256, и с помощью своего приватного ключа (или некой секретной фразы, которая находится только на серверах приложения) все данные токена подписываются. И затем сформированная подпись добавляется, также в формате base64, в конец токена. Таким образом наш итоговый токен представляет собой закодированную и подписанную строку. И далее при каждом новом запросе к API нашего приложения, сервер с помощью своего секретного ключа сможет проверить эту подпись и тем самым убедиться, что токен не был изменен. Эта проверка представляет собой похожую на подпись операцию, а именно, получив токен при новом запросе, он вынимает заголовок и полезные данные, затем подписывает их своим секретным ключом, и затем идет просто сравнение двух получившихся строк. Таким нехитрым способом, если не скомпроментировать секретный ключ, мы всегда можем знать, что перед нами все еще наш %user_name% с четко отведенными ему правами.

Время жизни токена и Refresh Token

Теперь плавно перейдем к следующему вопросу — времени жизни токена, и сопутствующей этой теме refresh token. Мы помним, что одно из важнейших свойств токена — это время его жизни. И оно совсем недолговечное, а именно 10-30 минут. Может возникнуть вопрос: а зачем такое короткое время жизни, ведь тогда придется каждый раз заново создавать новый токен, а это лишняя нагрузка на приложения. А ответ достаточно очевидный, который включает в себя и одновременно ответ на вопрос: а что делать если токен был перехвачен. Действительно, если токен был перехвачен, то это большая беда, так как злоумышленник получает доступ к приложению от имени нашего %user_name%, но так как access token является короткоживущим, то это происходит лишь на недолгий период. А дальше этот токен уже является не валидным. И именно чтобы обновить и получить новый access token нужен refresh token. Как мы знаем (или если забыли можем снова прочитать в начале) пользователь после процесса аутентификацию получает оба этих токена. И теперь по истечении времени жизни access token мы отсылаем в приложение refresh token и в ответ получаем снова два новых токена, опять же один многоразовый, но ограниченный по времени — токен доступа, а второй одноразовый, но долгоживущий — токен обновления. Время жизни refresh token вполне может измеряться месяцами, что достаточно для активного пользователя, но в случае если и этот токен окажется не валидным, то пользователю следует заново пройти идентификацию и аутентификацию, и он снова получит два токена. И весь механизм работы повторится.

Заключение

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

Полезные ссылки

1. 5 Easy Steps to Understanding JSON Web Tokens (JWT)
2. JWT — как безопасный способ аутентификации и передачи данных
3. Securing React Redux Apps With JWT Tokens
4. Зачем нужен Refresh Token, если есть Access Token?

Что означает ошибка «CSRF токен истек»

Если вы столкнулись с ошибкой «истек CSRF-токен» — читайте нашу статью. Из неё вы узнаете, как работает CSRF-token защита, и что делать, если CSRF токен истек.

Что такое CSRF

CSRF (англ. cross-site request forgery) — это межсайтовая подделка запроса. Это атака, которой может подвергаться любой веб-ресурс или веб-приложение. В первую очередь это касается сайтов, которые используют cookies, сертификаты авторизации и браузерную аутентификацию. В результате атаки страдают клиенты и репутация ресурса.

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

Как работает CSRF-атака

Злоумышленник может использовать фишинговую ссылку — это наиболее распространенный способ обмана. В этом случае атака работает по следующей схеме:

1. Злоумышленник создаёт поддельную страницу, очень похожую на оригинальную, и встраивает её в сайт.
2. Пользователь переходит с одной страницы сайта на другую (например, на страницу оплаты) и вместо реальной страницы попадает на поддельную.
3. Пользователь совершает действие на странице, например, оплачивает товар или вводит данные авторизации.
4. Информация или денежные средства вместо оригинального сервера уходят на сервер мошенника.

CSRF-атаки случаются из-за того, что без специальных настроек сервер не может с точностью в 100% определить, кто именно выполняет действия со стороны пользователя. Он не может проверить, действительно ли на кнопку «оплатить» нажал тот пользователь, который изначально открыл страницу с оплатой. Хакеры активно используют этот люфт в безопасности HTTP-запросов и применяют вредоносные скрипты. Однако от атаки можно защититься с помощью CSRF-токенов.

Что такое CSRF-token и как он работает

В общем понимании токен — это механизм, который позволяет идентифицировать пользователя или конкретную сессию для безопасного обмена информацией и доступа к информационным ресурсам. Токены помогают проверить личность пользователя (например, клиента, который онлайн получает доступ к банковскому счёту). Их используют как вместо пароля, так и вместе с ним. Токен — это в каком-то смысле электронный ключ.

CSRF-token — это максимально простой и результативный способ защиты сайта от CSRF-мошенников. Он работает так: сервер создаёт случайный ключ (он же токен) и отправляет его браузеру клиента. Когда браузер запрашивает у сервера информацию, сервер, прежде чем дать ответ, требует показать ключ и проверяет его достоверность. Если токен совпадает, сессия продолжается, а если нет — прерывается. Токен действителен только одну сессию — с новой сессией он обновляется.

Чтобы получить ответ от сервера, используются разные методы запроса. Условно они делятся на две категории: те, которые не изменяют состояние сервера (GET, TRACE, HEAD), и те, которые изменяют (PUT, PATCH, POST и DELETE). Последние имеют большую CSRF-уязвимость и поэтому должны быть защищены в первую очередь.

При создании и использовании токена должны соблюдаться следующие условия:

• нахождение в скрытом параметре;
• генерация с помощью генератора псевдослучайных чисел;
• ограниченное время жизни (одна сессия);
• уникальность для каждой транзакции;
• устойчивый к подбору размер (в битах);
• невозможно переиспользовать.

Типы токенов

Существует три основных типа токенов по способу генерации:

1. Synchronizer Tokens или Anti-CSRF (токены синхронизации). В этом случае инициатором ключа выступает сервер — на нём хранится исходная шифровка. Когда браузер обращается к серверу и предъявляет ему ключ, сервер сравнивает его с исходником и в зависимости от результата продолжает или прерывает сессию.
2. Double Submit Cookie (двойная отправка куки). При этом способе токен нигде не хранится. Когда браузер обращается к серверу впервые за сессию, сервер генерирует и передаёт ему ключ в двух формах: через куки и в одном из параметров ответа. При следующих обращениях браузера сервер дважды проверяет правильность ключа — в параметрах и в куках.
3. Encrypted Token (зашифрованный токен). Этот способ предполагает, что ключом шифруется какая-то часть информации о клиенте, которая содержится в браузере. При первом запросе браузера сервер получает информацию о пользователе, зашифровывает её и передаёт браузеру токен. При следующем взаимодействии сервер расшифровывает токен и сверяет информацию.

Помимо токенов, для защиты используется флаг Same-Site (большинство браузеров его поддерживает). Он работает напрямую для cookies и позволяет помечать куки конкретного домена. Сервер проверяет, содержатся ли нужные пометки в куках страницы, с которых происходит оплата или вносятся изменения. Если пометок нет — сессия прекращается.

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

«Истек срок действия токена» или «CSRF-значение недопустимо»: что это значит и что делать

Даже при авторизации на сайтах, для которых настроена защита от атак, можно встретить следующие варианты сообщения об ошибке: «Недопустимое CSRF-значение»/«CSRF-токены не совпадают» или «Token expired» (в переводе — срок действия токена истек). Сообщение может отображаться как на английском, так и на русском. Пример ошибки при авторизации на сайте Рег.ру:

Обычно ошибка возникает по двум основным причинам:

• сервер некорректно сгенерировал токен;
• срок токена истек — пользователь долго не совершал никаких действий на странице.

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

Иногда ошибка возникает из-за расширений защиты конфиденциальности или плагинов блокировки рекламы (например, Ghostery, UBlock Origin, Blur), которые настроены у пользователя. В этом случае можно отключить расширение. Также можно добавить сайт, на котором появилось сообщение, в список доверенных сайтов.

На примере сайта Рег.ру покажем, что для этого нужно:

в Google Chrome

1. Откройте настройки Chrome:

1. В списке слева выберите Конфиденциальность и безопасность, а затем Файлы cookie и другие данные сайтов.
2. Внизу страницы откройте Сайты, которые всегда могут использовать файлы cookie и кликните Добавить.
3. Введите «[.]www.reg.ru» и нажмите Добавить*.
4. Нажмите Все файлы cookie и данные сайта и удалите все записи, которые связаны с сайтом reg.ru.
5. Перезагрузите браузер и выполните операцию повторно.

в Яндекс.Браузер

1. Откройте настройки браузера Яндекс:

1. Перейдите на Сайты — Расширенные.
2. Кликните Настройки… для первого параметра в списке. Затем на вкладке «Разрешена» введите www.reg.ru и кликните Добавить.
3. Добавьте адрес сайта для всех параметров списка по аналогии.

1. Откройте настройки Safari комбинацией Cmd + , (⌘,).
2. Перейдите на вкладку Конфиденциальность и проверьте, что в пункте «Файлы cookie и данные веб-сайтов» не выбрано «Блокировать все файлы cookie». Если это так, снимите настройки.
3. Кликните Управление данными веб-сайтов и удалите все записи, которые относятся к www.reg.ru.
4. Перезагрузите браузер и выполните операцию повторно.

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

Заключение

Успешная атака CSRF позволяет хакеру действовать на сайте от имени другого зарегистрированного посетителя. Чтобы мошенник не добрался до конфиденциальных данных, для сайта нужно настроить один из типов CSRF-токенов. Токены позволяют серверу и браузеру безопасно обмениваться информацией в течение сессии. Однако даже на безопасных сайтах можно столкнуться с ошибкой «токен CSRF истек». В этом нет ничего страшного. Чтобы возобновить подключение, достаточно обновить страницу браузера.

Помогла ли вам статья?

Спасибо за оценку. Рады помочь ��

Поставщики идентификационных данных: Что такое аутентификация на основе токенов?

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

Как работает аутентификация на основе токенов?

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

Аутентификация на основе токенов работает, предоставляя серверу второй высоконадежный способ проверки личности пользователя и подлинности запроса.

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

В чем преимущества аутентификации на основе токенов?

Аутентификация на основе токенов предоставляет множество преимуществ для нескольких заинтересованных сторон.

• Повышенное удобство пользователя. Вместо того чтобы повторно вводить учетные данные и проходить повторную аутентификацию каждый раз, когда пользователь возвращается в систему, в приложение или на веб-страницу, он сохраняет беспрепятственный доступ до тех пор, пока токен остается действительным (как правило, до тех пор, пока сеанс не завершится выходом из системы или закрытием программы).
• Повышенная цифровая безопасность. Аутентификация на основе токенов создает еще один уровень безопасности поверх традиционной парольной или серверной аутентификации. Токены, как правило, гораздо труднее украсть, взломать или иным образом скомпрометировать, чем пароль.
• Административный контроль. Аутентификация на основе токенов обеспечивает администраторам гораздо более детальный контроль и видимость каждого действия пользователя и транзакции.
• Меньшая техническая нагрузка. Поскольку создание токена может быть полностью отделено от его проверки, проверку может проводить вспомогательная служба, например предоставляемая решением Entrust по управлению доступом и идентификационными данными. Это значительно снижает нагрузку на внутренние серверы и устройства.

Что такое токен доступа?

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

Аппаратные токены

Аппаратные токены — это небольшие физические устройства, которые пользователи предъявляют для получения доступа к ресурсу. Аппаратные токены могут быть подключенными (например, USB, смарт-карта, брелоки одноразовых паролей) или бесконтактными (например, токены Bluetooth). Эти токены пользователь носит с собой. На ранних этапах развития аутентификации на основе токенов (читайте: до появления смартфонов) можно было пользоваться только аппаратными токенами. Однако аппаратные токены сравнительно дороги, могут быть потеряны или украдены и, как следствие, часто требуют более значительной ИТ-поддержки.

Программные токены

Программные токены, также называемые отключенными токенами, являются поистине бесконтактными и могут использоваться для аутентификации независимо от местонахождения. Наиболее распространенными примерами программных токенов в настоящее время являются мобильные приложения, которые используют смартфоны для двухфакторной аутентификации (2FA), многофакторной аутентификации (MFA) или веб-токенов JSON. Токены программного обеспечения все чаще выбирают для аутентификации на основе токенов, поскольку они обеспечивают такие преимущества, как снижение расходов, повышение удобства пользования, снижение вероятности потери или кражи и меньший риск атак через посредника.

Что такое веб-токены с открытым исходным кодом или веб-токены JSON?

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

Компоненты веб-токена с открытым исходным кодом или веб-токена JSON

Веб-токен JSON состоит из трех отдельных частей.

• Заголовок. Тип токена и алгоритм шифрования.
• Полезная нагрузка. Учетные данные аутентификации для данного ресурса.
• Подпись. Криптографический ключ для проверки подлинности полезной нагрузки.

Как реализовать аутентификацию на основе токенов?

Реализация протокола аутентификации на основе токенов состоит из пяти ключевых шагов:

1. Запрос. Пользователь вводит учетные данные для входа.
2. Проверка. Сервер проверяет учетные данные пользователя.
3. Отправка токенов. Сервер генерирует маркер, который будет действителен в течение заданного периода.
4. Хранение. Токен хранится в веб-браузере пользователя для дальнейшего использования.
5. Истечение срока действия. Токен остается активным в течение заданного периода.

Когда рекомендуется аутентификация на основе токенов?

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

• Системы и ресурсы, которые часто предоставляют временный доступ. Если ваша база пользователей сильно отличается в зависимости от дня или времени, традиционный протокол предоставления и последующего аннулирования временного доступа пользователей может быть чрезмерно трудоемким, дорогостоящим и технологически сложным. Токены могут обеспечить динамичное, гибкое, экономичное решение для безопасного и бесперебойного временного доступа.
• Системы и ресурсы, требующие детального контроля доступа. Если нужен гораздо более детализированный контроль доступа, например для предоставления доступа к определенным частям документа либо определенных прав на редактирование или использование, парольная аутентификация не подойдет. Аутентификация на основе токенов идеально подходит для намного более тонкой настройки привилегий и более детального административного контроля.
• Системы и ресурсы, подверженные высокому риску взлома или компрометации. Если цифровой ресурс содержит конфиденциальную, ценную или защищенную информацию, аутентификация на основе токенов обеспечивает значительно более высокий уровень надежности по сравнению с аутентификацией на основе паролей.
• Строго регулируемые системы и ресурсы. Продолжение предыдущего пункта: если цифровой ресурс содержит конфиденциальную информацию, которая защищена требованиями обеспечения конфиденциальности данных или другими нормами, скорее всего, согласно этим нормам аутентификация не должна ограничиваться простыми паролями. При правильной настройке аутентификация на основе токенов может соответствовать нормативно-правовым требованиям для высоконадежной защиты.

Передовые методы высоконадежной аутентификации на основе токенов

Хотя аутентификация на основе токенов, несомненно, является большим шагом вперед по сравнению с традиционной аутентификацией на основе паролей, токен по-прежнему считается «токеном на предъявителя», то есть доступ предоставляется тому, кто владеет токеном. Это означает, что даже программные токены, например мобильные приложения, по-прежнему могут быть украдены или скомпрометированы. Если злоумышленник владеет токеном, он может использовать его для получения несанкционированного доступа к защищенным ресурсам и информации. Для защиты от остаточного риска компрометации и взлома важно создать программу аутентификации на основе токенов с учетом перечисленных ниже рекомендаций.

• Сохранение конфиденциальности токена. Пользователи должны обращаться с токеном (аппаратным или программным) так же, как с любыми секретными учетными данными. Это означает, что он должен храниться безопасно и надежно, никогда не передаваться и предоставляться только проверенным сервисам, чтобы предотвратить потерю или кражу.
• Упрощение полезной нагрузки токена. Токены предназначены для использования минимального объема информации для аутентификации пользователя. Они закодированы, однако злоумышленники могут легко их декодировать. По этой причине никогда не помещайте конфиденциальную или защищенную информацию в полезную нагрузку токена и старайтесь свести к минимуму запросы к полезной нагрузке. Это также поможет повысить скорость и производительность.
• Определение срока действия токена и его отзыв. Как правило, срок действия токена истекает автоматически, когда пользователь выходит из системы или полностью закрывает программу. Но по сути при отсутствии этого триггера окончания сеанса срок действия подписанного токена ничем не ограничен. Для защиты от компрометации необходимо установить срок действия по умолчанию для всех токенов и иметь протокол для отзыва токенов в случае необходимости.
• Систематическое использование HTTPS-соединений. При использовании небезопасных соединений невероятно просто перехватить и украсть токены во время передачи. При отправке токенов на сервер проверки и получении токенов от него всегда используйте HTTPS-соединения.
• Добавление дополнительных уровней безопасности. В зависимости от ваших требований безопасности может потребоваться добавить дополнительные протоколы безопасности и аутентификации поверх базовой аутентификации на основе токенов. Например, в некоторых случаях добавляют вторую систему проверки токенов, цель которой — гарантировать создание всех токенов на правильном сервере.

• Связаться с отделом продаж
• Связаться со службой поддержки
• Найти местоположение