Аутентификация через другие сайты

Резюме

Аутентификация через другие сайты производится с помощью механизма OAuth 2, обеспечивающего надежную защиту передаваемых данных с помощью шифрования, при этом пароль видит только сайт-провайдер (например, Google), но не сайт-клиент (например, matamune.ru). Единственный риск для пользователя – риск недобросовестности сайта-клиента, который может запросить дополнительную информацию (например, телефон из Facebook) и сдать ее на сторону.

Подробно о главном

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

Вот как это выглядит на Кинопоиске

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

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

Но сообразительные товарищи на далеком Западе придумали решение: а давайте мы все зарегистрируемся где-нибудь на Google, скажем, а на все остальные сайты будем заходить через него. Одна пара логин/пароль, не надо думать о безопасности – красота.

Собственно, это и есть идея OpenID: есть набор больших сайтов, которым доверяют пользователи и сайты поменьше. Сайты поменьше разрешают своим пользователям логиниться через большие сайты, и получают информацию о пользователе уже от них (такую, как логин или адрес электронной почты). Маленький сайт при этом не видит пароля пользователя (там вообще для входа через другой ресурс должна быть только кнопка, и больше ничего – вот пример того, как это работает у меня).

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

1. Владелец сайта заходит в Google и регистрирует там свой сайт, получая Client Id и Client Secret. Первый – это просто идентификатор его сайта, по которому Google будет его опознавать, второй – ключ для шифрования запросов через OAuth. На этом этапе также задается список адресов на сайте, на которые провайдер будет перенаправлять пользователя после аутентификации: это делается, чтобы не было такого, что пользователь дал разрешение на получение своих данных одному сайту, а ушла информация совсем на другой.

2. Пользователь открывает сайт-клиент и жмет кнопку входа через сайт-провайдер.

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

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

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

6. С помощью данного ключа, в зависимости от настроек сайта, сайт-клиент может либо один раз запросить у сайта-провайдера информацию о пользователе, либо делать это несколько раз в течение часа, например.

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

Отметим, все манипуляции с паролем происходят на сайте провайдера, и пароль вообще ни в каком виде никуда не передается.

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

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

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

Сейчас этой проблемы нет и для пользователя, если есть такая возможность, причин не использовать вход через другие сайты нет – надо только следить, на что вы даете разрешение. Все проблемы и заморочки лежат на стороне разработчика сайта-клиента, потому что многие сайты не следуют стандарту OpenID Connect, а внедряют собственные варианты использования OAuth, но сегодня не о проблемах разработчиков.

Логиньтесь на здоровье.

Также в разделе:

Промышленные системы или почему глючит Facebook
Резервное копирование данных – полный разбор
Изучение японского – источники

Опубликовано: 24.02.2016

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


(c) Александр Кирко, 2016