Что нужно знать об OAuth2 и входе через Facebook
Опубликовано: 2022-03-10Если вам интересно, что такое OAuth2, это протокол, который позволяет любому войти в систему со своей учетной записью Facebook. Он активирует кнопку «Войти через Facebook» в приложениях и на веб-сайтах повсюду.
В этой статье показано, как работает «Войти через Facebook», и объясняется протокол, лежащий в основе всего этого. Вы узнаете, почему вы хотите войти в систему через Facebook, Google, Microsoft или одну из многих других компаний, поддерживающих OAuth2.
В этой статье показано, как работает «Войти через Facebook», и объясняется протокол, лежащий в основе всего этого. Вы узнаете, почему вы хотите войти в систему через Facebook, Google, Microsoft или одну из многих других компаний, поддерживающих OAuth2.
Мы рассмотрим два примера: почему Spotify использует Facebook, чтобы позволить вам войти в мобильное приложение Spotify, и почему Quora использует Google и Facebook, чтобы позволить вам войти на свой веб-сайт.
Дальнейшее чтение на SmashingMag:
- Четыре способа создания мобильного приложения
- Как создавать честные пользовательские интерфейсы и помогать пользователям принимать более взвешенные решения
- Поддержание популярности вашего приложения для Android после запуска
- Плейлисты Spotify для поддержки ваших сеансов кодирования и дизайна
До OAuth2
OAuth2 выиграл битву за стандарты несколько лет назад. Это единственный протокол аутентификации, поддерживаемый основными поставщиками. Google рекомендует OAuth2 для всех своих API, а Graph API Facebook поддерживает только OAuth2.
Лучший способ понять OAuth2 — посмотреть, что было до него и почему нам нужно было что-то другое. Все началось с Basic Auth.
Базовая аутентификация
Схемы аутентификации сосредоточены на двух ключевых вопросах: Кто вы? И можете ли вы это доказать?
Наиболее распространенный способ задать эти два вопроса — ввести имя пользователя и пароль. Имя пользователя говорит, кто вы, а пароль подтверждает это.
Basic Auth была первой схемой веб-аутентификации. Звучит смешно, но в спецификации, впервые опубликованной в 1999 году, на самом деле она называлась «Базовая аутентификация».
Базовая аутентификация позволяет веб-серверам запрашивать эти учетные данные так, как их понимают браузеры. Сервер возвращает код ответа HTTP 401
(что означает, что требуется аутентификация) и добавляет к ответу специальный заголовок с именем WWW-Authenticate
со специальным значением Basic
.
Когда браузер видит этот код ответа и этот заголовок, он показывает всплывающее диалоговое окно входа в систему:
Отличительной особенностью Basic Auth является его простота. Вам не нужно писать экран входа в систему. Браузер обрабатывает все это и просто отправляет имя пользователя и пароль на сервер. Это также дает браузеру возможность специально обрабатывать пароль, запоминая его для пользователя, получая его из стороннего плагина или получая учетные данные пользователя из своей операционной системы.
Недостатком является то, что вы не можете контролировать внешний вид экрана входа в систему. Это означает, что вы не можете стилизовать его или добавить новые функции, такие как «Забыли пароль?» ссылка или возможность создать новую учетную запись. Если вы хотите больше настроек, вам придется написать собственную форму входа в систему.
Пользовательские формы входа
Пользовательские формы входа в систему дают вам полный контроль, который вы можете пожелать. Вы пишете HTML-форму и запрашиваете учетные данные. Затем вы отправляете форму и обрабатываете вход в систему любым удобным для вас способом. Вы получаете полный контроль: вы можете стилизовать его, запросить дополнительную информацию или добавить дополнительные ссылки.
Некоторые веб-сайты, такие как WordPress, используют простую форму для экрана входа в систему:
LinkedIn позволяет пользователям входить в систему или создавать учетную запись на той же странице, не переходя в другую часть веб-сайта:
Вход через форму очень популярен, но у него есть одна фундаментальная проблема: пользователи должны сообщать веб-сайту свой пароль.
Хранить секреты в секрете
В кругах безопасности мы называем пароль секретом. Это часть информации, которая есть только у вас и доказывает, что вы — это вы. Секрет также может быть больше, чем просто пароль; мы поговорим об этом немного позже.
Веб-сайт может принять все меры безопасности в мире, но если пользователь делится своим паролем, то эта безопасность исчезает. Хакеры взломали веб-сайт Gawker в 2010 году, раскрыв пароли многих пользователей. Хотя это было проблемой для Gawker, на этом проблема не остановилась. Большинство людей повторно используют пароли, поэтому хакеры взяли просочившиеся данные из Gawker и попытались войти на более важные веб-сайты, такие как Gmail, Facebook и eBay. Любой, кто использовал пароль Gawker для более важных вещей, потерял гораздо больше, чем последние сплетни о секс-видео Халка Хогана.
Убедиться, что ваши пользователи не используют пароль для нескольких учетных записей повторно, — это первая половина проблемы, и это невозможно. Пока людям приходится создавать разные учетные записи по всему Интернету, они будут повторно использовать свои пароли.
Вторая половина проблемы заключается в безопасном хранении паролей.
Когда кто-то входит в ваше приложение, вам нужно подтвердить его пароль, а это значит, что вам нужна копия для проверки. Вы могли бы хранить все имена пользователей и пароли где-то в базе данных, но теперь вы рискуете потерять эти пароли или быть взломанными. Лучше всего использовать хеш-функцию, например одну из функций SHA-2. Эта функция шифрует данные таким образом, что вы никогда не сможете их вернуть, но вы можете воспроизвести шифрование: «мой пароль» каждый раз будет хешироваться примерно как bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2
.
А теперь мы в высокой траве: я рассказываю вам, как реализовать криптографические протоколы. Далее мне придется объяснить, как добавить соль к вашим данным и какие учебники читать по атакам «человек посередине». Все, что вы хотели сделать, это написать приложение, и теперь вам нужно стать экспертом по безопасности. Нам нужно отступить.
OAuth2
Вы, наверное, не специалист по безопасности. Даже если и так, я бы все равно не доверил тебе свой пароль. OAuth2 дает вам лучший способ.
Например, я использую Spotify на своем iPad. Я плачу компании 10 долларов в месяц за прослушивание музыки. Spotify дает мне доступ только к трем устройствам, поэтому мне нужен пароль, чтобы убедиться, что никто другой не использует мою учетную запись. Моя учетная запись Spotify не представляет большой проблемы с безопасностью. Взлом не будет концом света, но у компании есть моя кредитная карта, поэтому я хочу убедиться, что я в безопасности.
Я почти никогда не захожу в Spotify, поэтому я не хочу создавать еще одну учетную запись и должен помнить другой пароль. Spotify дает мне лучший вариант:
Я могу использовать свою учетную запись Facebook для входа в систему. Когда я нажимаю эту кнопку, Spotify отправляет меня на facebook.com, и я вхожу там. Это может показаться мелочью, но это самый важный шаг во всем процессе.
Программисты Spotify могли сами написать форму для входа, а затем отправить мое имя пользователя и пароль в Facebook с помощью внутреннего API, но есть две серьезные причины, по которым я не хочу, чтобы они это делали:
- Я не доверяю Spotify свой пароль от Facebook. Я использую Facebook для общения с друзьями и не хочу, чтобы меня взломали. Я не верю, что Spotify правильно обработает пароль. Я также не верю, что он избежит искушения сделать с ним что-нибудь смешное. Возможно, он попытается сохранить его, чтобы использовать позже. Возможно, в нем есть ошибка, которая записывает его в файл где-то перед отправкой в Facebook, чтобы хакер мог его перехватить. Прости, Спотифай; Я просто не доверчивый человек.
- Я не хочу, чтобы Spotify делал все. Я хочу, чтобы Spotify воспроизводил музыку. Я не хочу, чтобы это публиковалось на стенах моих друзей, когда я слушаю Spice Girls. Я также не хочу, чтобы он загружал список моих друзей и заставлял их присоединяться к Spotify. Если бы я дал Spotify свой пароль Facebook, он мог бы войти в систему как я на Facebook; это могло сделать все, что я мог сделать.
Есть также две серьезные причины, по которым Spotify не хочет этого делать:
- У Facebook есть несколько вариантов входа в систему. . Я могу либо войти со своим именем пользователя и паролем, либо войти с помощью приложения Facebook. Я также могу восстановить свой пароль от Facebook или получить помощь, которую Spotify не может мне предоставить. Если бы я просто дал Spotify свой пароль, у меня не было бы ни одной из этих опций.
- Мой секрет может быть не паролем. . Пароля достаточно для защиты моей учетной записи Spotify за 10 долларов в месяц, но его может быть недостаточно для моего банка или чего-то еще более важного. Есть много других секретов, которые я мог бы раскрыть: у меня может быть смарт-карта, или я могу жить в фильме «Миссия невыполнима» и использовать сканер сетчатки глаза.
Я не в фильме «Миссия невыполнима», но в реальном мире многие компании используют двухфакторную аутентификацию, например пароль плюс что-то еще. Самый распространенный способ — использовать телефон. Когда вы хотите войти в систему, компания отправляет вам текст со специальным кодом, который действует в течение нескольких минут; затем вы вводите код или используете приложение для его ввода.
Теперь компания уверена, что никто не сможет войти в ваш аккаунт без вашего телефона. Если кто-то украдет ваш пароль, он все равно не сможет войти в систему. Пока вы не потеряете свой телефон, все в безопасности.
Facebook — не единственный поставщик OAuth2. Когда я вхожу в Quora со своей учетной записью Google, Google сообщает мне, что Quora хотела бы сделать, и спрашивает, все ли в порядке:
Я могу согласиться с тем, что Quora может просматривать мой адрес электронной почты и основные данные моего профиля, но я не хочу, чтобы он управлял моими контактами. OAuth2 показывает мне весь доступ, который хочет Quora, позволяя мне выбирать, к чему я предоставляю доступ.
Итак, это преимущества OAuth2. Давайте посмотрим, как это работает.
Как работает OAuth2
Facebook, Google и большинство других провайдеров OAuth2 относятся к собственным клиентам иначе, чем к веб-клиентам. Собственные клиенты считаются более безопасными, и они получают токены и токены обновления, которые могут длиться месяцами. Веб-клиенты получают гораздо более короткие токены, срок действия которых обычно истекает, когда пользователь закрывает браузер или какое-то время не нажимал на веб-сайт.
В обоих случаях процесс входа одинаков. Разница в том, как часто пользователю нужно его проходить.
Для входа в систему OAuth2 выполните следующие общие шаги:
- Пользователь пытается сделать что-то, что требует аутентификации. Это может быть так же просто, как открыть приложение или нажать кнопку «Войти».
- Приложение или веб-сайт определяет, что пользователь еще не вошел в систему, и запускает процесс входа. Он делает это, открывая веб-страницу и отправляя ее на специальный URL-адрес в Facebook, Google или любом другом веб-сайте, предоставляющем ваш OAuth2.
Открытие нового окна браузера для провайдера OAuth2 — важный шаг. Это то, что позволяет провайдерам показывать свои собственные формы входа в систему и запрашивать у каждого пользователя любую необходимую информацию для входа в систему. Большинство приложений делают это с помощью встроенного веб-представления.
Наряду с URL-адресом для входа в систему провайдера вам необходимо отправить некоторые параметры URL-адреса, которые сообщают провайдеру, кто вы и что вы хотите сделать:
-
client_id
Это сообщает поставщику OAuth2, что представляет собой ваше приложение. Вам нужно будет зарегистрировать свое приложение заранее, чтобы получить идентификатор клиента. -
redirect_uri
Это сообщает провайдеру, куда вы хотите перейти, когда закончите. Для веб-сайта это может быть возвращение на главную страницу; собственное приложение может перейти на страницу, которая закрывает веб-представление. -
response_type
Это сообщает провайдеру, что вы хотите получить в ответ. Обычно это значение либоtoken
, чтобы указать, что вам нужен токен доступа, либоcode
, чтобы указать, что вам нужен код доступа. Поставщики также могут расширить это значение для предоставления других типов данных. -
scope
Это сообщает провайдеру, к чему ваше приложение хочет получить доступ. Так Google узнает, что Quora запрашивает доступ для управления вашими контактами. У каждого провайдера свой набор областей.
Есть дополнительные поля, которые могут повысить безопасность или помочь с кэшированием. Некоторые провайдеры также могут добавлять дополнительные поля, но эти четыре являются важными.
Как только ваше приложение открывает веб-представление, провайдер вступает во владение. Они могут просто запросить простое имя пользователя и пароль или могут представить несколько экранов с запросом чего угодно, от имени вашего любимого учителя до девичьей фамилии вашей матери. Это все зависит от них. Важно то, что когда провайдер закончит работу, он перенаправит вас обратно и даст вам токен.
Все дело в токенах
Когда процесс завершится, провайдер предоставит вам токен и тип токена. Существует два типа токенов: токены доступа и токены обновления. Тип вашего клиента будет определять, какие типы токенов вам разрешено запрашивать.
Когда я вхожу в свое приложение Spotify, я могу оставаться в системе в течение нескольких месяцев, потому что предполагается, что мой телефон используется только мной. Facebook доверяет приложению Spotify управление токенами, и я верю, что приложение Spotify не потеряет токены.
Когда срок действия токена доступа истекает (обычно через один-два часа), Spotify может использовать токен обновления, чтобы получить новый.
Жетон обновления действует в течение нескольких месяцев. Таким образом, мне нужно заходить на свой телефон всего несколько раз в год. Недостатком является то, что если я потеряю этот токен обновления, кто-то другой может использовать мою учетную запись в течение нескольких месяцев. Токен обновления настолько важен, что iOS предоставляет цепочку ключей для токенов, где она обеспечивает их безопасное шифрование и хранение.
Использование OAuth2 в веб-приложении работает точно так же. Вместо использования веб-представления вы можете открыть запрос на вход OAuth2 во фрейме, iframe или отдельном окне. Вы также можете открыть его на текущей странице, но это приведет к потере всего состояния приложения JavaScript всякий раз, когда кому-то нужно войти в систему.
Когда я вхожу в Quora с помощью своего веб-браузера, я не получаю токен обновления. Они хотят, чтобы срок действия токена истек, и предлагали мне снова войти в систему, когда я выхожу из браузера или даже просто ухожу на обед. Ненадежные клиенты не могут обновить маркер, поскольку им нельзя доверять хранение важного маркера обновления. Это более безопасно, но менее удобно, потому что они будут предлагать вам снова войти в систему гораздо чаще.
Использование OAuth2 в вашем приложении
Теперь вы знаете, как работает OAuth2, но, вероятно, не захотите реализовывать собственный клиент OAuth2. Вы можете прочитать всю спецификацию OAuth 2.0 на 75 страницах, если у вас проблемы со сном, но вам это не нужно. Для вас есть несколько замечательных библиотек.
iOS имеет встроенную поддержку OAuth2. У Коррины Крич есть очень полезный учебник по использованию OAuth 2.0 со Swift. В нем рассказывается, как получить токен, как интегрировать представления в ваше приложение и где хранить ваши токены.
Android также имеет встроенную поддержку OAuth2. Должен признаться, что я не так хорошо знаком с ним, потому что я сосредоточен на iOS, но в документации есть несколько хороших разделов, чтобы показать вам примеры и некоторые библиотеки с открытым исходным кодом, чтобы сделать его еще проще.
В JavaScript нет встроенной поддержки OAuth2, но есть клиенты для всех основных библиотек JavaScript. React полностью поддерживает OAuth2. AngularJS имеет стороннюю поддержку OAuth2.0 для многих проектов. Я даже написал один из них.
Если у вас есть клиент OAuth2, вам нужно будет выбрать поставщика.
Кому вы доверяете?
Большое предположение здесь заключается в том, что я доверяю Facebook больше, чем Spotify. У меня нет для этого веских причин. Facebook не обнародует информацию о своей внутренней безопасности, и у меня нет хорошего способа ее проверить. Как и Spotify. Отсутствуют Consumer Reports для безопасности OAuth2. Я в основном доверяю Facebook, потому что он больше. Я доверяю Facebook, потому что доверяют другие люди.
Я также больше доверяю Facebook каждый раз, когда нажимаю кнопку «Войти через Facebook». Если Facebook потеряет мой пароль, хакеры получат доступ не только к моей учетной записи Facebook, но и к моей учетной записи Spotify и к любому другому сервису, в который я вошел с помощью своей учетной записи Facebook. Положительным моментом является то, что есть только одно место, где мне нужно сбросить пароль, чтобы решить проблему.
Мне не нужно доверять Facebook, но я должен доверять кому-то. Кто-то должен подтвердить мою подлинность. Мне нужно выбрать поставщика, которому я доверяю.
Выбор провайдера OAuth2
В Википедии есть список провайдеров OAuth, но большинство из них вас не волнует. Крупнейшие из них — Facebook и Google. Вы также можете посмотреть на Amazon или Microsoft.
Все четыре из них большие и легко интегрируются. Facebook предоставляет инструкции по регистрации приложения. У Google есть аналогичные шаги. Основная идея заключается в том, что вы создаете учетную запись разработчика, а затем создаете идентификатор приложения. Затем поставщик предоставляет вам идентификатор клиента, который вы можете использовать для выполнения запросов.
Вы также можете выбрать несколько провайдеров. Quora позволяет авторизоваться через Facebook или Google; поскольку они оба используют OAuth2, вы можете использовать один и тот же код для обоих.
Чего не хватает OAuth2
OAuth2 очень хорошо решает сложную проблему, но ему не хватает нескольких вещей:
- Стандарт не совсем стандарт. Мне никогда не удавалось написать ни одного клиента OAuth2, который мог бы входить как в Facebook, так и в Google без нескольких операторов
if
. Каждый интерпретирует спецификацию по-своему, и у каждого из них есть небольшие отличия в деталях. У них также всегда разные представления о том, какие объемы предоставлять. Использование библиотеки для интеграции с OAuth2 очень помогает решить эту проблему, но она никогда не будет на 100 % прозрачна в коде вашего приложения. - Выйти сложно. . Каждое приложение или веб-сайт, использующие OAuth2, имеют кнопку выхода из системы, но большинство просто забудет токены, не аннулировав их. Приложение забудет обо всех ваших текущих токенах и позволит кому-то еще войти в систему, но ваши токены все еще действительны. Если хакер украл ваш токен, он все равно сможет использовать его и войти под вашим именем.
Существует отдельная спецификация для признания недействительными токенов OAuth2, но многие крупные провайдеры не приняли ее. OAuth2 не предоставляет возможности восстановления, если хакер получит ваш токен обновления; даже если вы можете удалить свою локальную копию токена, он все равно останется у хакера. Многие провайдеры предоставляют вам возможность приостановить действие вашей учетной записи, но стандартного способа сделать это нет.
В защиту OAuth2 скажу, что это сложная проблема, поскольку многие провайдеры используют криптографию с открытым ключом для создания токенов без сохранения состояния. Это означает, что сервер не помнит созданные им токены, поэтому он не сможет их забыть позже.
Другая серьезная проблема с OAuth2 заключается в том, что вы зависите от своего провайдера. Когда Facebook выходит из строя, кнопка «Войти через Facebook» в вашем приложении тоже не работает. Если Google решит начать взимать с вас плату за поддержку OAuth2 или потребует, чтобы вы делились с ним своей прибылью, вы ничего не сможете сделать. Это обоюдоострый меч доверия провайдеру: они многое делают для вас, но они контролируют ваших пользователей.
OAuth2 правит миром
Даже с парой недостающих функций и большой зависимостью OAuth2 по-прежнему остается отличным выбором. Это позволяет пользователям легко входить в ваше приложение, не помнить пароль для каждого веб-сайта и доверять вашей безопасности. OAuth2 — очень популярный выбор. Он доминирует в отрасли. Ни один другой протокол безопасности не сравнится с OAuth2.
Теперь вы знаете, откуда взялся OAuth2 и как он работает. Сделайте разумный выбор в отношении того, кому доверять, перестаньте читать статьи о безопасном хранении зашифрованных паролей и уделите больше времени написанию своего замечательного приложения.