Токен-аутентификация в мобильном банкинге: как это работает

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

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

Механика сессионных токенов: OAuth 2.0 и JWT в мобильных приложениях

OAuth 2.0 — протокол делегированной авторизации. В упрощённом виде он позволяет приложению получать ограниченный доступ к серверным ресурсам, не передавая пароль пользователя каждому внутреннему сервису банка. После аутентификации сервер авторизации выдаёт приложению токен, а тот предъявляется при обращении к API. Это не обязательно зашифрованный набор символов: формат и свойства токена зависят от реализации.

В мобильных приложениях для получения токена часто используют Authorization Code Flow с PKCE — расширением, которое помогает защитить обмен авторизационным кодом. В общих чертах процесс выглядит так:

1. Приложение создаёт случайное проверочное значение и производное от него значение, которое отправляет в запросе авторизации.

2. Пользователь проходит аутентификацию через системный браузер или другой предусмотренный банком интерфейс.

3. Сервер возвращает приложению одноразовый код авторизации.

4. Приложение предъявляет код и исходное проверочное значение, чтобы обменять код на токен.

5. Access token используется для запросов к API. Если выдан refresh token, он может применяться для получения нового access token без повторного ввода учётных данных — в пределах правил банка.

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

Что хранится в JWT и чего его подпись не гарантирует

JWT — один из возможных форматов токена. Обычно в нём есть заголовок, набор утверждений о токене и подпись. Утверждения могут содержать сведения об издателе, получателе и сроке действия, а также другие поля, предусмотренные конкретной системой. Нередко содержимое JWT кодируют в Base64URL. Само по себе такое кодирование не является шифрованием: прочитать содержимое может любой, кто получил токен, если оно не защищено дополнительным механизмом.

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

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

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

Токены могут различаться сроком действия, объёмом полномочий и условиями выдачи. Короткий срок для access token часто уменьшает окно риска при утечке, но сам по себе не предотвращает кражу токена и не гарантирует, что тот привязан к конкретному устройству. Такая привязка возможна в некоторых схемах, но не является общим свойством OAuth-токенов.

Платёжная токенизация: как PAN заменяется динамической криптограммой

Сессионный токен не заменяет номер карты. Для этого существует платёжная токенизация: в определённых платёжных сценариях вместо исходного PAN используется платёжный токен. Он не становится универсальной копией карты для любых операций. Где он применим и как проверяется, определяют платёжная система, эмитент, кошелёк и конкретная реализация.

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

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

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

Важно различать и типы криптограмм и проверочных значений. Термины, встречающиеся в материалах о чиповых платежах, бесконтактных операциях и 3-D Secure, относятся к разным механизмам. Их нельзя считать взаимозаменяемыми только потому, что все они участвуют в проверке платёжной операции. EMVCo публикует спецификации для платёжных технологий, но конкретный набор требований и его редакция зависят от рассматриваемого документа. Требования к многофакторной аутентификации не следует выдавать за требования к платёжной токенизации.

Программные OTP-генераторы и автономная аутентификация

OTP — одноразовый пароль, который используется для подтверждения входа или операции. Один распространённый вариант опирается на счётчик: код формируется с учётом значения, которое меняется по мере использования. Другой, TOTP, учитывает время. В распространённых приложениях-аутентификаторах код обновляется через заданный интервал, но его длина, временной шаг и допустимое окно проверки — параметры конкретной реализации.

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

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

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

Push-аутентификация устроена иначе: приложение получает запрос на подтверждение и предлагает пользователю его принять или отклонить. Иногда подтверждение дополняют биометрией или локальным кодом, иногда используют другой способ разблокировки. Биометрия не является обязательной частью push-аутентификации. Безопасность зависит от того, что именно показывается пользователю, как запрос связан с конкретной операцией и какие проверки выполняет приложение. Если уведомление содержит мало контекста, человеку сложнее заметить неожиданный запрос.

Безопасное хранение ключей: от iOS Keychain до Android StrongBox

Защита сессии в приложении не заканчивается на выдаче токена. Важно, как приложение хранит секреты, когда они доступны и что происходит при блокировке устройства, резервном копировании или удалении приложения. Ни один механизм хранения не даёт одинаковых гарантий на всех устройствах и при любых настройках.

В iOS Keychain служит для хранения небольших секретных данных, однако уровень защиты зависит от выбранного класса доступности и конфигурации. Некоторые параметры ограничивают доступ к данным, например, состоянием блокировки устройства или возможностью переноса при миграции. Secure Enclave может участвовать в защите операций с ключами, если это поддерживают устройство и выбранная схема, но нельзя утверждать, что всё содержимое Keychain всегда зашифровано ключом Secure Enclave. При взломанном устройстве риск также зависит от того, какие именно данные сохранены и как приложение использует платформенные механизмы.

В Android Android Keystore позволяет приложениям работать с криптографическими ключами, не извлекая их напрямую в обычный код. На части устройств ключи могут быть защищены аппаратно через TEE, а некоторые устройства поддерживают StrongBox — отдельную защищённую среду для криптографических операций. Поддержка и уровень изоляции зависят от модели устройства и реализации производителя. Название StrongBox не означает, что любой токен приложения автоматически хранится там: приложение должно использовать доступный механизм подходящим образом.

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

Для сессионных данных также важна минимизация. Приложение может держать access token в памяти и отдельно защищать секрет, нужный для обновления сессии. Но это рекомендация, а не универсальное требование для каждого приложения: решения зависят от архитектуры, возможностей платформы и требований банка. Обновления тоже заслуживают внимания не потому, что каждая новая версия автоматически опасна, а потому, что изменения SDK, зависимостей и конфигурации способны затронуть обработку учётных данных. Принцип оценки обновлений сторонних мобильных сервисов здесь применим и к изменениям компонентов, которым приложение доверяет доступ к чувствительным операциям.

Разграничение рисков: почему блокировка токена не равна блокировке карты

У карты и связанного с ней платёжного токена могут быть разные жизненные циклы и процедуры управления. Поэтому отключение токена в кошельке не обязательно означает блокировку самой карты. И наоборот, блокировка PAN может повлиять на связанные токены, но конкретное поведение зависит от правил эмитента и платёжной системы.

Управление токеном может включать его добавление в кошелёк, временную приостановку, удаление или отзыв. Эти действия выполняются через доступные каналы — например, приложение банка или настройки кошелька. Возможности и последствия различаются: удаление карты из интерфейса кошелька, временная блокировка токена и отзыв токена эмитентом — не обязательно одно и то же действие.

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

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

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

Блокировка токена и блокировка карты — разные действия. Перед тем как отключать всё сразу, важно понять, какой именно доступ нужно остановить и через какой канал это делается.

Токен-аутентификация в мобильном банкинге — не один механизм, а несколько уровней с разными задачами. OAuth-токены помогают управлять доступом приложения к API, платёжная токенизация защищает карточные реквизиты в отдельных сценариях, а OTP и push подтверждают действия пользователя. Риски тоже различаются: сессионный токен может дать доступ в рамках полномочий, утечка секрета OTP — позволить генерировать коды, а компрометация платёжного токена — затронуть конкретный платёжный контур.

Для пользователя практический вывод прост: при подозрительной активности важно назвать банку не просто «токен», а событие — потерян телефон, появился неизвестный сеанс, пришёл неожиданный push-запрос или обнаружена операция в кошельке. Так проще выбрать нужную меру: завершить сессию, отключить способ подтверждения, приостановить платёжный токен или заблокировать карту. У этих действий разные последствия, и именно поэтому токены в банковском приложении нельзя складывать в одну корзину.