Как энергосбережение на Android мешало Seamless-авторизации

Значимый прорыв формирует отрасль ИИ: KutcyiNV 16 минут назад Как энергосбережение на Android мешало Seamless-авторизации Средний 10 мин 643 Блог компании Банки. ру Android * Разработка мобильных приложений * Kotlin * Сетевые технологии * Кейс Всем привет! Я Никита, тимлид команды Android в Банки.

Недавно, внедряя в приложение новую фичу, мы столкнулись с тем, что она в упор отказывалась работать – но только на Android. Мы дебажили ее полторы недели, перепробовали все возможные варианты и закошмарили всех доступных операторов связи, прежде чем узнали, что все дело было… в энергосбережении. Бизнес захотел SeamlessОднажды к нам пришел бизнес с такой задачей: пользователь вводит номер телефона – и он уже авторизован, без SMS-кодов, пушей и подтверждений.

Технические детали

Выглядит как магия, но на самом деле это фича, которая называется Seamless-авторизация. Не буду долго томить, вот как это выглядит у нас:Под капотом – HTTP Header Enrichment (HHE): сетевой шлюз мобильного оператора (PGW в LTE-сети) перехватывает HTTP-запросы и инжектирует заголовки – X-MSISDN (номер телефона), X-IMSI и другие идентификаторы абонента. За счет этого целевой сервер получает номер без каких-либо действий пользователя.

HHE работает только по HTTP и только через мобильную сеть. HTTPS-трафик зашифрован TLS – оператор не может модифицировать заголовки, а WiFi-трафик идет напрямую через провайдера, минуя PGW оператора – инжекция невозможна. Контекст: как у нас устроена авторизацияВ нашем приложении два пути авторизации: нативная (внутри приложения) и SSO – через браузер, который открывается в внутреннем браузере Custom Tab.

Seamless должен был работать только в рамках SSO-флоу. Приложение выбирает браузер с поддержкой Custom Tabs – чаще всего это Chrome, но на устройствах без Chrome (например, Huawei) используется другой подходящий браузер, поддерживающий технологию. Пользователь попадает в браузер, проходит авторизацию, его редиректит обратно в приложение.

Отраслевые последствия

В этом процессе пять участников: приложение, Custom Tab (ActiveTab), KeyCloak, MobileId и HheUri оператора. Приложение открывает Custom Tab со страницей авторизации, передавая stateПользователь вводит номер телефонаKeyCloak отправляет запрос к оператору Mobile ID, получает одноразовую ссылку hhe_uriПараллельно приложение начинает лонг-поллинг KeyCloak – POST-запрос с тем же state, ожидая получить ссылкуПолучив ссылку – приложение делает GET запрос на полученный hhe_uri оператораОператор идентифицирует абонента по Header EnrichmentПодтверждение летит обратно: оператор уведомляет наш backend об успехе → сервис авторизации успешно завершает процесс по флоу → пользователь авторизованСхема работы seamless-авторизацииНо это если совсем кратко. Если интересно узнать больше про то, как у нас работает SSO-авторизация, то мои коллеги написали про нее отдельную статью.

Проблемы на Android и трудности дебагаРазработка шла параллельно на iOS и Android. И если на iOS все работало более-менее стабильно, то на Android вылезали постоянные ошибки.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.