Привет, меня зовут Артём. Я без малого четверть века работаю в IT. За это время у меня как-то сама собой сформировалась так называемая «аура тестировщика». Зачастую мне не приходится прилагать каких бы то ни было усилий, чтобы натыкаться на недоработки, ошибки проектирования и вполне себе конкретные баги в различных продуктах. Это касается не только IT но и повседневных вещей.

Сегодня я хочу рассказать о своём видении причин недопустимости повсеместного SSO с завязкой на номер телефона. Рассказать я хочу не с точки зрения безопасности (атаки с угоном номера и т. д.), а на примере банальной ситуации с которой я столкнулся лично и которую из-за ошибки проектирования невозможно решить никаким приемлемым способом.

Много лет пользовался услугами известной сети аптек Еаптека. Все было хорошо и удобно. Удобный профиль история заказов и рекомендации. Но тут случилось страшное... Их купил Sber и стал бездумно тащить к ним свою экосистему. В том числе и пресловутый SberID.

Одним прекрасным днём я как обычно захожу в свой профиль на Еаптеке по номеру телефона, но вместо привычного окошка авторизации выскакивает авторизация в SberID. Окей... думаю я и авторизуюсь. Но дальше испытываю некоторый диссонанс. В моей учётной записи не мои персональные данные. Не мои, но понятные мне. При этом история заказов и адреса доставки мои. Начинаю изучать вопрос и пытать техподдержку Еаптеки. Выясняю, что теперь персональные данные в профиле берутся исключительно из SberID. Потому что они теперь Sberapteka. Но это пол беды. Чтобы отредактировать данные в профиле теперь надо идти в отделение Sber’а. Дескать «где открывали карточку туда и идите (тм)». Потому что функционал редактирования данных профиля эффективные менеджеры благополучно решили выпилить. Но вот заковыка в том, что у меня нет карточки Sber’а и лично я не являюсь клиентом Sber’a. Но при этом клиентом Sber’а является мой близкий родственник не имеющий телефона. И персональные данные в профиле Еаптеки теперь именно этого родственника, просто потому, что у него указан мой номер в качестве контактного.

Ни одного приемлемого варианта решения этой проблемы мне предложить так и не смогли. Либо «покупайте другой номер» (я пользуюсь этим номером больше 20 лет и менять его естественно не намерен), либо меняйте данные в базе Sber’а, что по понятным причинам дичь несусветная. Казалось бы ситуация не стоит выеденного яйца, но из-за применения SSO она по сути не разрешима ни одним адекватным образом.

А всего-то стоило оставить возможность авторизации старым способом помимо SberID. Или дать возможность привязать / авторизовываться по SberID, не затирая молча уже имеющиеся в профиле персональные данные.

Даже безотносительно моего, не самого очевидного с точки зрения проектирования, пользовательского сценария есть ведь ещё банальная история с перепродажей номеров операторами...

Комментарии (17)


  1. scome
    03.12.2024 15:32

    В эту же копилку. Для ипотеки мне нужно было открыть эскроу счет в Сбере. Лет 5-6 назад был их клиентом и имел карту, сейчас же нет ничего - ни карт, ни приложения, ни личного кабинета.

    Раньше для открытия такого счета было достаточно зайти в офис банка с паспортом и потратить 15 минут времени.

    Сейчас:

    1. Прийти в офис

    2. Обновить личные данные (они устарели)

    3. Выслушать все вариации доступных карт

    4. Оформить карту

    5. Установить личный кабинет на свой айфон через их учетку айклауда

    6. Зайти в личный кабинет и подписать наконец документы.


    1. linux_art Автор
      03.12.2024 15:32

      Охъ... жесть какая...


    1. salnicoff
      03.12.2024 15:32

      А послать на три буквы копро-менеджера и подписать документы на бумаге своей рукой теперь уж нельзя? Просто очень хочется оценить уровень деградации Сберкассы...


    1. linux_art Автор
      03.12.2024 15:32

      Кстати интересно, а если вообще не иметь телефона, как такой сценарий должен выглядеть? :-/ Между 4 и 5 шагом добавится шаг "Купите телефон и оформите сим карту"? :-/


  1. Myz17
    03.12.2024 15:32

    SSO совершенно непричём, вы сами дали свой номер "левому" человеку для привязки его аккаунта. Если при этом номер был подтверждён, например кодом из СМС, то виноваты вы. Если его просто привязали без всякого подтверждения (сомнительно), то просчёт Сбера.


    1. linux_art Автор
      03.12.2024 15:32

      Во-первых не левому. Во-вторых не давал, а регистрировал человека по генеральной доверенности.


  1. MrAlone
    03.12.2024 15:32

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


    1. linux_art Автор
      03.12.2024 15:32

      SSO в данном случае при чём. Смысл в том, что если его тащить во все сервисы бездумно - могут быть неожиданные коллизии.


      1. MrAlone
        03.12.2024 15:32

        Не может быть коллизий, если всё правильно сделано. Номера телефонов/мэйлы должны быть авторизованы. Указал номер телефона? Будь добр код из смс. Нет? И опять же, это вообще не про SSO!


        1. linux_art Автор
          03.12.2024 15:32

          Есть две системы. Есть два различных пользователя. В рамках каждой системы данные пользователь + номер валидны. Но при введении SSO в двух системах получаем коллизию. Почему в данной схеме SSO не при чём?


          1. MrAlone
            03.12.2024 15:32

            Это прикол такой? В двух разных системах при использовании SSO должны быть одни и те же данные, так как используется один источник данных. Это аксиома! Если у Сбер во время объединения двух разных баз случилось, что:
            а) они в одной базе не проверяли валидность телефонов/мэйлов/ещё чего-то
            б) после объединения случились коллизии
            то это полностью косяк Сбера, но никак не принципов SSO.


            1. inkelyad
              03.12.2024 15:32

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

              Статья как бы про то, что не надо было вводить SSO. Ничего бы страшного не случилось, если бы это и дальше были две разные учетки.

              А проблема возникла от того, что его ввели.


            1. linux_art Автор
              03.12.2024 15:32

              Так речь именно об этом. Не о том что SSO плохо само по себе. А о том, что его внедряют бездумно :)


          1. outlingo
            03.12.2024 15:32

            Почему в данной схеме SSO не при чём?

            Потому, что объединение учетных записей было сделано по неправильному ключу. Это проблема не SSO, а исключительно в квалификации и добросовестности того, того проектировал и внедрял SSO в соединяемых сервисах. "Убивает не оружие, убивают придурки с автоматами - как вон те двое" (c)


            1. linux_art Автор
              03.12.2024 15:32

              Так об этом и речь. Именно по этому заголовок содержит слова "бездумно использовать SSO" :)


        1. DarthVictor
          03.12.2024 15:32

          Не может быть коллизий, если всё правильно сделано.

          Если.


    1. inkelyad
      03.12.2024 15:32

      SSO вообще не об этом.

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


      1. linux_art Автор
        03.12.2024 15:32

        Именно.


  1. orefkov
    03.12.2024 15:32

    SSO для меня, как C++ника, означает "small string optimization". Всё-таки хорошо бы в начале статьи хотя бы вкратце описывать, что имеется ввиду.


    1. linux_art Автор
      03.12.2024 15:32

      Приму к сведению. Это мой первый опыт написания статьи на хабр. Поэтому так коряво получилось :)