Многие соцсети позволяют создавать приложения и через API получать данные пользователей, поэтому их использует для быстрой регистрации и авторизации на сайтах. Как проходит аутентификация, рассмотрим на примере VK:
- На сайте, пользователь нажимает на ссылку «Войти», открывается страница VK, где он разрешит приложению доступ к своим данным.
- После подтверждения браузер пользователя будет перенаправлен по адресу, указанному при открытии диалога авторизации. К URL добавляется GET-параметр с кодом авторизации.
- Скрипт выполняет ответный запрос с полученным кодом и ключом приложения для получения access_token .
- Полученный в ответе access_token , скрипт использует для запроса к данным пользователя.
Регистрация приложения
Для начала нужно создать приложение на странице https://vk.com/editapp?act=create
В меню «Платформа» нужно указать – сайт, заполнить поля «адрес сайта» и «основной домен».
ЧТО ТАКОЕ OAUTH 2.0?
В настройках видим ID приложения и защищённый ключ, также нужно убедится что приложение включено и видно всем.
Ссылка для входа
Сформируем и выведем ссылку по которой пользователь даст разрешение на запрошенные действия.
В redirect_uri указываем скрипт-обработчик, туда придет секретный код. В параметре state можно передать URL текущей страницы, чтобы вернуть пользователя обратно. При переходе по ссылке откроется страница:
Получение данных
После того как пользователь дал разрешение, он возвращается на redirect_uri , к URL добавляются GET-параметры:
https://example.com/oauth-vk.php?code=1234567890 ‘Защищённый ключ’, ‘redirect_uri’ => ‘https://example.com/oauth-vk.php’, ‘code’ => $_GET[‘code’] ); // Получение access_token $data = file_get_contents(‘https://oauth.vk.com/access_token?’ . urldecode(http_build_query($params))); $data = json_decode($data, true); if (!empty($data[‘access_token’])) < // Получили email $email = $data[’email’]; // Получим данные пользователя $params = array( ‘v’ =>’5.81′, ‘uids’ => $data[‘user_id’], ‘access_token’ => $data[‘access_token’], ‘fields’ => ‘photo_big’, ); $info = file_get_contents(‘https://api.vk.com/method/users.get?’ . urldecode(http_build_query($params))); $info = json_decode($info, true); echo $email; print_r($info); > >
Полученные данные пользователя
Далее все завит от реализации сайта, пользователя можно добавить в БД или обновить его данные и авторизовать в системе.
Источник: snipp.ru
Как это работает: вход на сайты через соцсети
Часто на сайтах вам могут предложить войти с помощью Google, Facebook или ВКонтакте. Если у вас есть аккаунт в одном из этих сервисов, вам не нужно будет регистрироваться с нуля: заполнять имя, почту и ставить свою фотографию — всё это будет сделано автоматически. Разберёмся, как это работает и насколько это безопасно.
Как работает OAuth 2 — введение (просто и понятно)
Это история о технологии OAuth2.
Для чего это нужно
Каждый сайт заинтересован в новых посетителях, потому что им можно потом продать платную подписку или показать рекламу. Поэтому сайтам выгодно, чтобы регистрация была как можно проще, в идеале — по нажатию одной кнопки (а то и вообще без регистрации). Если пользователи должны регистрироваться вручную и вводить все свои данные, есть шанс, что они отвалятся.
Параллельно с этим в интернете есть сервисы, которыми пользуются все: Яндекс, Гугл, фейсбук или Вконтакте. Почему бы не брать данные о пользователе с этих сервисов?
Для этого и придумали OAuth.
OAuth — это как договор между сайтами
Яндекс, Гугл или любой другой сервис, который разрешает пользоваться своим пропуском, должны принять единый протокол обмена данных. Если по-простому, то они должны договориться:
«Мы даём друг другу данные вот в таком формате, мы принимаем их в этом формате, мы друг другу доверяем».
Эти договорённости закрепили в едином стандарте авторизации — OAuth. В нём написано, как выдавать пропуска, как их проверять и что делать в разных случаях.
Как работает единая авторизация
Для пользователя всё выглядит просто: нажал «Войти через Яндекс», подтвердил Яндексу своё желание войти на нужный сайт, и всё — вы уже зарегистрировались на новом сайте и можете им пользоваться. Но что происходит под капотом?
Когда посетитель, например, сайта о программировании, нажимает «Войти через Яндекс», этот сайт отправляет в Яндекс запрос и говорит: «Тут кто-то хочет войти на мой сайт через ваш сервис, можете разобраться?»:
Когда Яндекс получает такой запрос, ему нужно понять, что за посетитель пришёл на сайт и есть ли у него аккаунт Яндекса. Для этого он показывает всплывающее окно, где посетитель может войти в свой Яндекс-аккаунт. Это нужно, чтобы сервис понимал, на чьё имя выдавать пропуск для сайта. Если пользователь уже залогинен в Яндексе, его сразу узнают.
Как только посетитель вводит свой логин и пароль, Яндекс узнаёт его и спрашивает, доверяет ли он этому сайту о программировании и может ли Яндекс поделиться с сайтом данными о его имени и почте:
Дальше Яндекс отдаёт ваши данные сайту, он вас узнаёт, и готово:
Насколько это безопасно
Каждый сайт, который использует OAuth, сам определяет, какие данные о пользователе они хотят увидеть. Например, одному сайту достаточно знать ваше имя и почту, а другому хочется скачать вашу фотографию и узнать дату рождения.
Когда вы будете входить через OAuth, сервис вам скажет: «Вот какие данные у меня запрашивают. Давать доступ?». Когда вы разрешите доступ, эти данные перейдут на сайт. Откажетесь — не перейдут.
✅ Сайты, которые используют OAuth, не смогут прочитать вашу почту или личные сообщения. Но есть и другие технологии — например приложения в социальных сетях, — и уже они могут делать гораздо больше.
✅ Через OAuth нельзя отправить сообщения от вашего имени или сделать пост в вашей ленте новостей. Но, опять же, если это не OAuth, а отдельное приложение для фейсбука или VK, то возможно и такое. Помните все эти игры, которые постят от имени игроков «Я собрал капусту на своей ферме»? Вот это они.
✅ Через OAuth точно не передаётся ваш пароль от Яндекса, Гугла и других сервисов. Сервисы хранят пароли в зашифрованном виде, поэтому даже при всём желании не смогли бы его передать.
Можно ли этому доверять?
Скорее нет, чем да. С OAuth есть проблема: вы никогда не знаете, действительно ли это OAuth или это хакеры сделали штуку, похожую на OAuth, которая хочет украсть ваш пароль. На всякий случай вот техника безопасности:
⚠️ Во всех важных сервисах включайте двухфакторную авторизацию: чтобы не только вводить пароль, но и получать СМС.
⚠️ Если сервис поддерживает приложение-аутентификатор — используйте его. Например, в Яндексе есть «Ключ», а в Гугле — Authenticator. Это специальные приложения, которые создают дополнительный слой защиты поверх вашего логина и пароля.
⚠️ Если вы только что пользовались сервисами Яндекса или Гугла и тут вас просят вновь ввести логин и пароль — закройте эту страницу. Яндекс и Гугл помнят вас и не попросят пароль лишний раз.
Источник: thecode.media
OAuth 2.0 простым и понятным языком
На хабре уже писали про OAuth 1.0, но понятного объяснения того, что такое OAuth 2.0 не было. Ниже я расскажу, в чем отличия и преимущества OAuth 2.0 и, как его лучше использовать на сайтах, в мобильных и desktop-приложениях.
Что такое OAuth 2.0
OAuth 2.0 — протокол авторизации, позволяющий выдать одному сервису (приложению) права на доступ к ресурсам пользователя на другом сервисе. Протокол избавляет от необходимости доверять приложению логин и пароль, а также позволяет выдавать ограниченный набор прав, а не все сразу.
Чем отличаются OpenID и OAuth
Не смотря на то, что объяснений на эту тему уже было много, она по-прежнему вызывает некоторое непонимание.
OpenID предназначен для аутентификации — то есть для того, чтобы понять, что этот конкретный пользователь является тем, кем представляется. Например, с помощью OpenID некий сервис Ололо может понять, что зашедший туда пользователь, это именно Рома Новиков с Mail.Ru. При следующей аутентификации Ололо сможет его опять узнать и понять, что, это тот же Рома, что и в прошлый раз.
OAuth же является протоколом авторизации, то есть позволяет выдать права на действия, которые сам Ололо сможет производить в Mail.Ru от лица Ромы. При этом Рома после авторизации может вообще не участвовать в процессе выполнения действий, например, Ололо сможет самостоятельно заливать фотографии на Ромин аккаунт.
Как работает OAuth 2.0
Как и первая версия, OAuth 2.0 основан на использовании базовых веб-технологий: HTTP-запросах, редиректах и т. п. Поэтому использование OAuth возможно на любой платформе с доступом к интернету и браузеру: на сайтах, в мобильных и desktop-приложениях, плагинах для браузеров…
Ключевое отличие от OAuth 1.0 — простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации.
- получение авторизации
- обращение к защищенным ресурсам
- авторизация для приложений, имеющих серверную часть (чаще всего, это сайты и веб-приложения)
- авторизация для полностью клиентских приложений (мобильные и desktop-приложения)
- авторизация по логину и паролю
- восстановление предыдущей авторизации
Авторизация для приложений, имеющих серверную часть
- Редирект на страницу авторизации
- На странице авторизации у пользователя запрашивается подтверждение выдачи прав
- В случае согласия пользователя, браузер редиректится на URL, указанный при открытии страницы авторизации, с добавлением в GET-параметры специального ключа — authorization code
- Сервер приложения выполняет POST-запрос с полученным authorization code в качестве параметра. В результате этого запроса возвращается access token
Это самый сложный вариант авторизации, но только он позволяет сервису однозначно установить приложение, обращающееся за авторизацией (это происходит при коммуникации между серверами на последнем шаге). Во всех остальных вариантах авторизация происходит полностью на клиенте и по понятным причинам возможна маскировка одного приложения под другое. Это стоит учитывать при внедрении OAuth-аутентификации в API сервисов.
Пример
Здесь и далее примеры приводятся для API Mail.Ru, но логика одинаковая для всех сервисов, меняются только адреса страниц авторизации. Обратите внимание, что запросы надо делать по HTTPS.
Редиректим браузер пользователя на страницу авторизации:
> GET /oauth/authorize?response_type=code redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 HTTP/1.1 > Host: connect.mail.ru
Здесь и далее, client_id и client_secret — значения, полученные при регистрации приложения на платформе.
После того, как пользователь выдаст права, происходит редирект на указанный redirect_uri:
Обратите внимание, если вы реализуете логин на сайте с помощью OAuth, то рекомендуется в redirect_uri добавлять уникальный для каждого пользователя идентификатор для предотвращения CSRF-атак (в примере это 123). При получении кода надо проверить, что этот идентификатор не изменился и соответствует текущему пользователю.
Используем полученный code для получения access_token, выполняя запрос с сервера:
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=authorization_codeclient_secret=deadbeef redirect_uri=http%3A%2F%2Fexample.com%2Fcb%2F123 < HTTP/1.1 200 OK < Content-Type: application/json
Обратите внимание, что в последнем запросе используется client_secret, который в данном случае хранится на сервере приложения, и подтверждает, что запрос не подделан.
В результате последнего запроса получаем сам ключ доступа (access_token), время его «протухания GET /platform/api?oauth_token=SlAV32hkKGformat=json sig=. HTTP/1.1 > Host: appsmail.ru
Авторизация полностью клиентских приложений
- Открытие встроенного браузера со страницей авторизации
- У пользователя запрашивается подтверждение выдачи прав
- В случае согласия пользователя, браузер редиректится на страницу-заглушку во фрагменте (после #) URL которой добавляется access token
- Приложение перехватывает редирект и получает access token из адреса страницы
Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token.
Пример
Открываем браузер со страницей авторизации:
> GET /oauth/authorize?response_type=token Host: connect.mail.ru
После того, как пользователь выдаст права, происходит редирект на стандартную страницу-заглушку, для Mail.Ru это connect.mail.ru/oauth/success.html:
Приложение должно перехватить последний редирект, получить из адреса acess_token и использовать его для обращения к защищенным ресурсам.
Авторизация по логину и паролю
Авторизация по логину и паролю представляет простой POST-запрос, в результате которого возвращается access token. Такая схема не представляет из себя ничего нового, но вставлена в стандарт для общности и рекомендуется к применению только, когда другие варианты авторизации не доступны.
Пример
Восстановление предыдущей авторизации
Обычно, access token имеет ограниченный срок годности. Это может быть полезно, например, если он передается по открытым каналам. Чтобы не заставлять пользователя проходить авторизацию после истечения срока действия access token’а, во всех перечисленных выше вариантах, в дополнение к access token’у может возвращаться еще refresh token. По нему можно получить access token с помощью HTTP-запроса, аналогично авторизации по логину и паролю.
Пример
> POST /oauth/token HTTP/1.1 > Host: connect.mail.ru > Content-Type: application/x-www-form-urlencoded > > grant_type=refresh_tokenclient_secret=deadbeef HTTP/1.1 200 OK < Content-Type: application/json
Минусы OAuth 2.0
Во всей этой красоте есть и ложка дегтя, куда без нее?
OAuth 2.0 — развивающийся стандарт. Это значит, что спецификация еще не устоялась и постоянно меняется, иногда довольно заметно. Так, что если вы решили поддержать стандарт прямо сейчас, приготовьтесь к тому, что его поддержку придется подпиливать по мере изменения спецификации. С другой стороны, это также значит, что вы можете поучаствовать в процессе написания стандарта и внести в него свои идеи.
Безопасность OAuth 2.0 во многом основана на SSL. Это сильно упрощает жизнь разработчикам, но требует дополнительных вычислительных ресурсов и администрирования. Это может быть существенным вопросом в высоко нагруженных проектах.
OAuth — простой стандарт авторизации, основанный на базовых принципах интернета, что делает возможным применение авторизации практически на любой платформе. Стандарт имеет поддержку крупнейших площадок и очевидно, что его популярность будет только расти. Если вы задумались об API для вашего сервиса, то авторизация с использованием OAuth 2.0 — хороший выбор.
Со своей стороны, мы внедрили OAuth 2.0 в API Mail.Ru и, теперь, вы можете использовать возможности протокола для реализации любых клиентов и сервисов, интегрированных с Mail.Ru.
Ссылки
- Текущая версия драфта стандарта OAuth 2.0
- Официальный сайт OAuth
- Рабочая группа по выработке стандарта (архивы)
- Документация по реализации OAuth 2.0 в Mail.Ru
Источник: habr.com