Что нужно знать об OAuth2 и входе через Facebook

1. Об авторе Зак Гроссбарт - инженер, дизайнер и автор. Он старший технический сотрудник и облачный...
2. Basic Auth
3. Хранить секреты в секрете
4. OAuth2
5. Как работает OAuth2
6. Это все о жетонах
7. Использование OAuth2 в вашем приложении
8. Кому ты доверяешь?
9. Выбор поставщика OAuth2
10. Чего не хватает в OAuth2
11. OAuth2 управляет миром

Об авторе

Зак Гроссбарт - инженер, дизайнер и автор. Он старший технический сотрудник и облачный архитектор в IBM. Он создает облачный пользовательский интерфейс IBM ... Подробнее о Заке ...

OAuth2 позволяет пользователям легко заходить в ваше приложение, не нужно запоминать пароль для каждого веб-сайта и доверять вашей безопасности. OAuth2 доминирует в отрасли, поскольку нет другого протокола безопасности, который был бы близок к принятию OAuth2.

Если вам интересно, что такое OAuth2, это протокол, который позволяет любому войти в систему со своей учетной записью Facebook. Он включает кнопку «Войти через Facebook» в приложениях и на веб-сайтах повсюду.

В этой статье показано, как работает «Войти через Facebook», и объяснен протокол, стоящий за всем этим. Вы узнаете, почему вы хотите войти в систему через Facebook, Google, Microsoft или одну из многих других компаний, которые поддерживают OAuth2.

В этой статье показано, как работает «Войти через Facebook», и объяснен протокол, стоящий за всем этим. Вы узнаете, почему вы хотите войти в систему через Facebook, Google, Microsoft или одну из многих других компаний, которые поддерживают OAuth2.

Мы рассмотрим два примера: почему Spotify использует Facebook для входа в мобильное приложение Spotify и почему Quora использует Google и Facebook для входа на его веб-сайт.

Дальнейшее чтение на SmashingMag:

До OAuth2

OAuth2 выиграл битву стандартов несколько лет назад. Это единственный протокол аутентификации, поддерживаемый основными поставщиками. Google рекомендует OAuth2 для всех своих API, а API Graph Facebook поддерживает только OAuth2.

Лучший способ понять OAuth2 - посмотреть, что было до него и почему нам нужно что-то другое. Все началось с Basic Auth.

Basic Auth

Схемы аутентификации фокусируются на двух ключевых вопросах: кто вы? И можете ли вы доказать это?

Наиболее распространенный способ задать эти два вопроса - с помощью имени пользователя и пароля. Имя пользователя говорит, кто вы, и пароль доказывает это.

Basic Auth была первой схемой веб-аутентификации. Звучит смешно, но «Базовая аутентификация» была его настоящим названием в спецификации, впервые опубликованной в 1999 году

Обычная аутентификация позволяет веб-серверам запрашивать эти учетные данные таким образом, чтобы их понимали браузеры. Сервер возвращает HTTP-код ответа 401 (что означает, что требуется аутентификация) и добавляет к ответу специальный заголовок с именем WWW-Authenticate со специальным значением Basic.

Когда браузер видит этот код ответа и этот заголовок, он показывает всплывающее диалоговое окно входа в систему:

Диалог входа в систему Basic Auth

Большая часть о Basic Auth заключается в его простоте. Вам не нужно писать экран входа в систему. Браузер обрабатывает все это и просто отправляет имя пользователя и пароль на сервер. Это также дает браузеру возможность специально обрабатывать пароль, будь то запоминание его для пользователя, получение его от стороннего плагина или получение учетных данных пользователя из их операционной системы.

Недостатком является то, что вы не можете контролировать внешний вид экрана входа в систему. Это означает, что вы не можете стилизовать его или добавить новые функции, такие как ссылка «Забыли пароль?» Или возможность создать новую учетную запись. Если вы хотите больше настроек, вам нужно написать пользовательскую форму для входа.

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

Некоторые веб-сайты, такие как WordPress, используют простую форму для экрана входа в систему:

Экран входа в WordPress

LinkedIn позволяет пользователям войти в систему или создать учетную запись на той же странице, не переходя на другую часть сайта:

Экран входа в LinkedIn ( Посмотреть большую версию )

Вход в систему на основе форм очень популярен, но имеет серьезную фундаментальную проблему: пользователи должны сообщить веб-сайту свой пароль.

Хранить секреты в секрете

В кругах безопасности мы называем пароль секретом. Это часть информации, которая есть только у вас, и доказывает, что вы есть вы. Секрет также может быть не просто паролем; мы поговорим об этом чуть позже.

Веб-сайт может принять все меры безопасности в мире, но если пользователь поделится своим паролем, то эта безопасность исчезнет. Хакеры взломали сайт Gawker в 2010 году, разоблачив пароли многих пользователей. Хотя это было проблемой для Гоукера, проблема не остановилась на этом. Большинство людей повторно используют пароли, поэтому хакеры взяли утечку данных из Gawker и попытались войти на более важные веб-сайты, такие как Gmail, Facebook и eBay. Любой, кто использовал пароль Gawker для более важных вещей, потерял намного больше, чем последние слухи о сексуальной ленте Халка Хогана.

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

Вторая половина проблемы - безопасное хранение паролей.

Когда кто-то входит в ваше приложение, вам необходимо подтвердить его пароль, а это значит, что вам нужна копия для его проверки. Вы можете хранить все имена пользователей и пароли в базе данных где-нибудь, но теперь вы рискуете потерять эти пароли или получить взломанный. Лучшая практика заключается в использовании хэш-функция например, один из SHA-2 функции. Эта функция шифрует данные таким образом, что вы никогда не сможете получить их обратно, но вы можете повторить шифрование: «мой пароль» будет хэшировать что-то вроде bb14292d91c6d0920a5536bb41f3a50f66351b7b9d94c804dfce8a96ca1051f2 каждый раз.

А теперь мы в высокой траве: я рассказываю вам, как реализовать криптографические протоколы. Далее мне придется объяснить, как добавить поваренная соль к вашим данным и какие учебники читать о нападениях "человек посередине". Все, что вы хотели сделать, это написать приложение, и теперь вы должны стать экспертом по безопасности. Нам нужно сделать шаг назад.

OAuth2

Вы, вероятно, не эксперт по безопасности. Даже если бы вы были, я бы не стал доверять вам свой пароль. OAuth2 дает вам лучший способ.

В качестве примера я использую Spotify на своем iPad. Я плачу компании 10 долларов в месяц за прослушивание музыки. Spotify дает мне доступ только на трех устройствах, поэтому мне нужен пароль, чтобы никто другой не использовал мою учетную запись. Моя учетная запись Spotify не является большой проблемой безопасности. Взлом не будет концом света, но у компании есть моя кредитная карта, поэтому я хочу убедиться, что я в безопасности.

Я почти никогда не захожу в Spotify, поэтому я не хочу создавать другую учетную запись и должен помнить другой пароль. Spotify дает мне лучший вариант:

Spotify экран входа с опцией «Войти через Facebook» ( Посмотреть большую версию )

Я могу использовать свою учетную запись Facebook для входа в систему. Когда я нажимаю эту кнопку, Spotify отправляет меня на facebook.com, и я вхожу туда. Это может показаться мелочью, но это самый важный шаг всего процесса.

Экран входа в Facebook для Spotify ( Посмотреть большую версию )

Программисты Spotify, возможно, сами написали форму входа и затем отправили мое имя пользователя и пароль в Facebook с помощью внутреннего API, но есть две серьезные причины, по которым я не хочу, чтобы они это делали:

• Я не доверяю Spotify с моим паролем Facebook. Я использую Facebook, чтобы общаться с друзьями, и я не хочу, чтобы меня взломали. Я не верю, что Spotify будет правильно обрабатывать пароль. Я также не верю, что это позволит избежать соблазна сделать что-то смешное с этим. Может быть, он попытается сохранить его, чтобы использовать его позже. Возможно, в нем есть ошибка, которая записывает его в файл где-то перед отправкой в ​​Facebook, так что хакер может получить его. Простите, Spotify; Я просто не доверчивый.
• Я не хочу позволять Spotify делать все. Я хочу, чтобы Spotify играл музыку. Я не хочу, чтобы он публиковался на стенах моих друзей, когда я слушаю Spice Girls. Я также не хочу, чтобы он загружал мой список друзей и заставлял их присоединиться к Spotify. Если бы я дал Spotify свой пароль на Facebook, он мог войти как я на Facebook; это могло сделать все, что я мог сделать.

Есть также две серьезные причины, по которым Spotify не хочет этого делать:

• У меня есть несколько вариантов входа в Facebook . Я могу войти в систему под своим именем пользователя и паролем или войти в систему с помощью приложения Facebook. Я также могу восстановить свой пароль из Facebook или получить помощь, которую Spotify не может мне дать. Если бы я просто дал Spotify свой пароль, я бы не получил ни одного из этих вариантов.
• Мой секрет не может быть паролем. , Пароль - это достаточный уровень безопасности для моей учетной записи Spotify в размере 10 долларов США в месяц, но этого может быть недостаточно для моего банка или чего-то еще более важного. Есть много других секретов, которые я мог бы предоставить: у меня может быть смарт-карта или я живу в фильме «Миссия невыполнима» и использую сканер сетчатки глаза.

Я не в фильме «Миссия невыполнима», но в реальном мире многие компании используют двухфакторную аутентификацию, такую ​​как пароль плюс что-то еще. Самый распространенный способ - использовать свой телефон. Когда вы хотите войти, компания отправляет вам текст со специальным кодом, который длится несколько минут; затем вы вводите код или используете приложение для его ввода.

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

Facebook не единственный поставщик OAuth2. Когда я вхожу в Quora с моей учетной записью Google, Google сообщает мне, что Quora хотела бы сделать, и спрашивает, все ли в порядке:

Диалог шага 2 для процесса Google и Quora OAuth2

Я мог бы позволить Quora просматривать мой адрес электронной почты и основные данные профиля, но я не хочу, чтобы он управлял моими контактами. OAuth2 показывает мне весь доступ, который хочет Quora, позволяя мне выбирать то, к чему я даю доступ.

Таковы преимущества OAuth2. Посмотрим, как это работает.

Как работает OAuth2

Facebook, Google и большинство других поставщиков OAuth2 относятся к нативным клиентам иначе, чем к веб-клиентам. Родные клиенты считаются более безопасными, и они получают токены и обновляют токены, которые могут храниться месяцами. Веб-клиенты получают намного более короткие токены, которые обычно истекают, когда пользователь закрывает браузер или не нажимает на веб-сайт некоторое время.

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

Для входа в OAuth2 необходимо выполнить следующие общие шаги:

1. Пользователь пытается сделать что-то, что требует аутентификации. Это может быть так же просто, как открыть приложение или нажать кнопку «Войти».
2. Приложение или веб-сайт определяет, что пользователь еще не вошел в систему, и запускает процесс входа. Это делается путем открытия веб-страницы и отправки ее по специальному URL-адресу в Facebook, Google или на любом другом веб-сайте, предоставляющем ваш OAuth2.

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

Наряду с URL-адресом входа провайдера необходимо отправить некоторые параметры URL-адреса, которые сообщают провайдеру, кто вы и что вы хотите сделать:

• client_id Это сообщает провайдеру OAuth2, какое у вас приложение. Вам необходимо заранее зарегистрировать свое приложение, чтобы получить идентификатор клиента.
• redirect_uri Это говорит провайдеру, куда вы хотите пойти, когда закончите. Для веб-сайта это может быть возвращение на главную страницу; нативное приложение может перейти на страницу, которая закрывает веб-представление.
• response_type Это сообщает провайдеру, что вы хотите вернуть. Обычно это значение является токеном, чтобы указать, что вы хотите токен доступа, или кодом, чтобы указать, что вам нужен код доступа. Поставщики также могут расширить это значение для предоставления других типов данных.
• область действия. Это сообщает провайдеру, к чему ваше приложение хочет получить доступ. Так Google узнает, что Quora запрашивает доступ для управления вашими контактами. У каждого провайдера свой набор областей.

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

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

Это все о жетонах

Когда процесс завершится, провайдер предоставит вам токен и тип токена. Существует два типа токенов: токены доступа и токены обновления. Тип вашего клиента будет определять, какие типы токенов вам разрешено запрашивать.

Когда я захожу в свое приложение Spotify, я могу оставаться в системе в течение нескольких месяцев, поскольку предполагается, что мой телефон используется только мной. Facebook доверяет приложению Spotify для управления токенами, и я верю, что приложение Spotify не теряет токены.

Когда время доступа к токену истекает (обычно через один-два часа), Spotify может использовать токен обновления, чтобы получить новый.

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

Использование OAuth2 в веб-приложении работает аналогично. Вместо использования веб-представления вы можете открыть запрос входа OAuth2 во фрейме, в фрейме или в отдельном окне. Вы также можете открыть его на текущей странице, но это может привести к потере всех состояний приложения JavaScript, когда кто-то должен будет войти в систему.

Когда я вхожу в Quora с помощью моего веб-браузера, я не получаю токен обновления. Они хотят, чтобы токен отключился, и предложили мне снова войти в систему, когда я выйду из браузера или даже просто уйду на обед. Ненадежные клиенты не могут обновить токен, поскольку им нельзя доверять для хранения важного токена обновления. Это более безопасно, но менее удобно, потому что они предложат вам войти снова гораздо чаще.

Использование OAuth2 в вашем приложении

Теперь вы знаете, как работает OAuth2, но, вероятно, вы не хотите реализовывать свой собственный клиент OAuth2. Вы можете прочитать всю 75-страничную страницу. Спецификация OAuth 2.0 если у вас проблемы со сном, но вам это не нужно. Для вас есть несколько замечательных библиотек.

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 и как он работает. Сделайте умный выбор того, кому можно доверять, прекратите читать статьи о безопасном хранении зашифрованных паролей и тратьте больше времени на написание своего удивительного приложения.