Настройка авторизации через Google

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

Эта статья расскажет как интегрировать авторизацию через аккаунт Google на свой сайт.


Исходные файлы

Для этого, прежде всего, необходимо создать свой клиентский ID (ClientID), секретный ключ (ClientSecret) и ключ разработчика API.

Для этого перейдите на https://code.google.com/apis/console/

Нажимаем на кнопку Create project…

И переходим на страницу создания проекта:

Далее нажимаем первую красную кнопку [Create New CLIENT ID].

Выбираем Web Application (Предполагая, что вы будете использовать это для веб-приложений) и заполняем URL ниже Authorized Javascript origins и Authorized redirect URI и жмем кнопку Create Client ID

Теперь клиентский ID и секретный ключ зарегистрированы.

Далее необходимо создать ключ разработчика API. Нажимаем Create New Key:

В открывшемся окне нажимаем Browser key:

Введите адрес вашего сайта и нажмите Create.

Ключ разработчика API сгенерирован.

После того как вы сделали это, давайте посмотрим в сторону кода.

У нас есть файл google_verification.php, который содержит информацию о сгенерированных ключах и библиотека Google Client Libary for PHP (папка src) загруженная с https://code.google.com/p/google-api-php-client/downloads/list

Затем у нас есть файл index.php, взаимодействующий с Google Client Library и генерирующий информацию об авторизованном пользователе.

В этой статье мы не будем описывать взаимодействие с базой данных, т.к. это очень просто. В исходниках есть комментарии которые помогут Вам разобраться что к чему. Удачи!

Обновлено: Март 6, 2014

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

Немного истории

OAuth 1.0
OAuth возник еще в ноябре 2006, когда Блейн Кук занимался разработкой реализации OpenID для Твиттера. Вместе с Крисом Мессиной, Блейн искал путь к использованию OpenID для доступа к Twitter API без предоставления сервису пароля. Сотрудничая с одним из разработчиков OpenID Девидом Рекордоном, Кук провел анализ функциональности OpenID  и протоколов авторизации, таких как  Yahoo! BBAuth, Google AuthSub, Flickr Auth. Был сделан вывод, что необходим новый открытый протокол. Так, в апреле 2007 года образовалась группа разработчиков, которые занялись его созданием. В группе приняли участие сотрудники компаний  AOL и Google. Финальную версию протокола OAuth 1.0 была представлена 4 декабря 2007 года, а в 2008 году начались работы по стандартизации протокола.

OAuth 2.0
В 2010 году началась работа над новой версией протокола OAuth 2.0. Главной целью новой версии – упрощение разработки клиентский приложений.

Отличие OAuth от OpenID

Мнение, что OAuth – это расширение протокола OpenID, ошибочно. Хотя OpenID и OAuth имеют много общего, OAuth является протоколом самостоятельным и никак не связанным с OpenID.

OAuth – это протокол авторизации, позволяющий предоставлять права на использование какого-либо ресурса.

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

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

Схема работы OAuth

Например, пользователь  хочет распечатать свои фото, которые загружены на сайт  foto.primer.ru с помощью сервиса печати print.primer.ru

  • Клиент с помощью HTTPS протокола отправляет на сервис запрос с содержанием идентификатора клиента, метку времени, адрес обратного вызова, по которому нужно будет вернуть токен, тип цифровой подписи и, непосредственно, саму цифровую подпись
  • Сервер подтверждает запрос и отвечает клиенту токеном доступа и частью разделенного секрета.
  • Клиент осуществляет передачу токена владельцу ресурсов и для прохождения авторизации перенаправляет токен на сервер.
  • Сервер получает токен и запрашивает логин и пароль. Если аутентификация прошла успешна, то просит подтверждения доступа к ресурсам, после чего пользователь перенаправляется сервером к клиенту
  • Клиент передает серверу токен при помощи TLS  протокола и запрашивает доступ к ресурсам
  • Сервер подтверждает запрос и отвечает клиенту новым токеном доступа.
  • Клиент использует новый токен для обращения к серверу за ресурсами
  • Сервер подтверждает и предоставляет ресурсы.

Весь список терминов →

Как вы, наверное, знаете, вопрос описывает наиболее распространенный (и, как правило, более безопасный) поток OAuth «Код авторизации» . Чтобы быть ясным, здесь приближение шагов в этом потоке:

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

До шага 2 все происходит на стороне клиента. Но на шаге 3 мне нужно иметь client_id и client_secret. Я не думаю, что это хорошая идея хранить эти значения на стороне клиента. Означает ли это, что мне нужно иметь серверный сервер, который имеет эти два значения [?]

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

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

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

и мой backend должен преобразовать CODE123 в TOKEN123 и передать его стороне клиента?

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

Однако на данный момент клиентское приложение (и пользователь этого клиента) отвечает за безопасность токена доступа. В зависимости от требований безопасности нашего приложения мы можем захотеть добавить слой для защиты этого токена доступа от клиента.

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

Чтобы сделать запросы API от имени пользователя более безопасными, клиентское приложение может отправлять запросы на наш сервер, что, в свою очередь, использует токен доступа, который он получил, чтобы взаимодействовать с сторонним API. При такой настройке клиенту не нужно знать значение токена доступа.

Чтобы повысить производительность, мы, скорее всего, захотим кэшировать токен доступа на сервере для последующих вызовов API в течение всего срока его службы. Мы также можем зашифровать токены, если мы храним их в базе данных приложений &mdash, точно так же, как мы будем использовать пароли &mdash, поэтому токены не могут быть легко использованы в случае нарушения данных.

ответ дан Cy Rossignol 21 нояб. '17 в 9:42

источникподелиться

Инструкция по созданию собственного приложения для авторизации через Google+.

1. В ПУ (Главная » Пользователи » Авторизация через социальные сети) активируем чекбокс “Использовать собственное приложение” и щелкаем по кнопке “Создать собственное приложение”:

2. Авторизуемся в Google+ и создаем приложение: https://console.developers.google.com/project.

Щелкаем по кнопке “Create Project”:

3. В открывшемся окошке указываем имя приложения (любое или предложенное системой) (1), id приложения (генерируется системой, можно указать свое) (2).

Щелкаем по кнопке Создать (3):

4. Ожидаем активацию приложения (появление зеленой иконки):

5. Далее открываем вкладку APIs & auth / Credentials:

Щелкаем по кнопке Create new Client ID:

В появившемся окошке:

1 — активируем пункт Web application,
2 — Вставляем адрес сайта. (!) Важно. Если к сайту прикреплен домен, то необходимо указывать доменное имя и, соответсвенно, приложение уже создается для домена. То есть, такое приложение не будет работать для первоначального адреса (стандартный домен сайта).

Копируем Callback URI с ПУ (см. шаг 1) и вставляем в создаваемое приложение (3).

Щелкаем по кнопке Create Client ID (4).

6. Копируем Client ID и Client Secret:

7. Вставляем полученные данные в ПУ в соответствующие поля и сохраняем:

Готово! Мы создали и настроили наше приложение!

Ваши вопросы вы можете задавать в комментариях.


Рейтинг: 2  (помогла ли Вам эта инструкция: да / нет)          Просмотров: 7025          Комментариев:

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

Если мы не включили в этот список какую-то новую библиотеку, которая вам нравится, поделитесь ею в коментариях 🙂


Requests for PHP

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

Rinvex Country

Rinvex Country — это PHP-пакет, который позволяет разработчикам получать детальную информацию о странах со всего мира. Имея под рукой больше 50 методов, вы можете узнать площадь Анголы, валюту Кипра, самоназвание Намибии или даже имя Финлядии, используемое в FIFA. Есть куча доступной информации, причем источники вполне надежны.

Botman

Это PHP-библиотека для разработки ботов для мессенджеров. Работает с самыми популярными платформами сообщений, а именно Facebook Messenger, Slack, Telegram, WeChat и другими. Также имеется готовый шаблон проекта на Laravel.

Charts

Этот пакет для Laravel позволяет генерировать настраиваемые графики из различных наборов данных. Он работает как PHP-обертка для нескольких встроенных JavaScript-библиотек графиков, предоставляя возможность создать всевозможные диаграммы, измерители, полосы загрузки, используя один единственный инструмент.

Swap

Swap позволяет получить курсы валют из различных сервисов, таких как Fixer, Google и Yahoo. Ответы на запросы могут быть без проблем закэшированы и получены позднее. Эта библиотека также доступна в виде пакета Laravel.

Math PHP

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

Эта библиотека модульна, имеет простой API и не требует никаких сторонних зависимостей.

PHPUnit

PHPUnit — это продвинутый фреймворк для тестирования, который дает возможность командам разработчиков тщательно тестировать свой код. Unit-тесты написаны в виде объектно-ориентированных standalone классов с помощью многочисленных методов для обработки значений, зависимостей и т.д. Также предоставляется простой консольный интерфейс для запуска тестов и вывода отчетов.

Atoum

Менее известный фреймворк для тестирования, которым нам тоже захотелось поделиться. Atoum предлагает установку в один шаг и относительно простой рабочий процесс, сохраняя при этом массу замечательных возможностей. Он содержит средства создания фиктивных данных, подстановки значений. Так же есть командный интерфейс, который может запустить несколько параллельных тестов.

Simple Regex Language

PHP-реализация Simple Regex Language — более понятного для человека языка для написания регулярных выражений. Библиотека имеет множество методов, которые могут быть вызваны цепочкой, формирующие читабельные и понятные RegEx-правила. У этой библиотеки также есть реализации на JavaScript и Python.

Stash

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

PHP VCR

Аналог популярной библиотеки на Ruby для тестирования взаимодействия с HTTP. PHP VCR записывает HTTP-запросы и хранит их в "кассетах", которые могут быть воспроизведены позже. Также доступен набор средств для тестирования, делая возможным детальное инспектирование и сравнение записей.

OAuth 2.0 Server

Эта библиотека дает возможность без проблем настроить OAuth 2.0 сервер и установить все уровни аутентификации необходимые для защиты вашего API.

Она полностью соответствует стандартам и поддерживает все права, определенные в протоколе OAuth. Кстати, Laravel Passport разработан на основе OAuth 2.0 Server.

Imagine

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

MINI

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

AWS SDK

Официальная библиотека для работы с веб-сервисами Amazon (AWS). SDK позволяет подключиться к AWS любому проекту на PHP и подключиться ко всем доступным сервисам. Также есть обертка для Laravel, которую можно найти здесь.

Purl

Легковесная библиотека для работы с URL. C Purl вы можете получать данные из URL-адресов, манипулировать запросами, проверять строки на соответствие URL и многое другое.

Daux.io

Генаратор сайтов документаций, на основе структуры папок и Markdown-файлов. Daux.io включает подсветку синтаксиса, 4 темы оформления, навигацию с ЧПУ и многое другое.

Dompdf

Dompdf — это генератор PDF, который использует обычную разметку HTML и конвертирует ее в  файлы. Эта библиотека понимает большинство CSS-правил, которые могут быть встроены прямо в разметку или подключаться из стороннего файла.

// указываем неймспейс use Dompdf\Dompdf;

// создаем объект и передаем разметку $dompdf = new Dompdf(); $dompdf->loadHtml('hello world');

// (Не обязательно) Устанавливаем размер листа и ориентацию $dompdf->setPaper('A4', 'landscape');

// Сгенерировать PDF $dompdf->render();

// Вывести сгенерированный результат в браузер $dompdf->stream();

Instaphp

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

printf('', $item['images']['low_resolution']['url']);

Latitude

Библиотека без зависимостей для создания SQL-запросов с помощью методов, которые могут быть вызваны цепочкой. Она поддерживает большинство типов запросов и работает с MySQL, Postgres, SQL Server и другими базами данных. Также есть хелперы для экранирования символов, что позоволяет избежать SQL-инъекции.

Статью перевел aziev. Оригинал на Tutorialzine.com доступен по ссылке.

Добавить комментарий

Закрыть меню