Руководство по OAuth 2.0 для новичков

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

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

Введение в OAuth

Позвольте мне объяснить это на примере повседневной жизни.

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

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

На сегодняшний день у OAuth есть две версии: OAuth 1.0 и OAuth 2.0.

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

Роли

OAuth определяет четыре роли, подробности каждой из которых приведены ниже.

Владелец ресурса

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

Клиент

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

Сервер ресурсов

Сервер, к которому осуществляется доступ для получения защищенной информации пользователя.

Сервер авторизации

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

Типы грантов

Фактический поток протокола зависит от типа предоставления. Грант - это способ получить токен доступа. Ниже приведены четыре типа грантов:

Код авторизации

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

Учетные данные для пароля владельца ресурса

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

Неявный

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

Учетные данные клиента

Это похоже на учетные данные пароля владельца ресурса. Здесь клиент обменивается идентификатором клиента и секретом, чтобы получить токен доступа.

Еще несколько терминов,

Код авторизации

Код, полученный клиентским приложением для получения токена доступа

Токен доступа

Используется в качестве учетных данных для подтверждения серверу API ресурсов, что носитель аутентифицирован и авторизован.

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

Последовательность кода авторизации

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

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

Шаг 1. Зарегистрируйте приложение

Первоначально ваше приложение должно быть зарегистрировано на портале разработчиков Google, чтобы получить идентификатор и секрет клиента.

1) Создайте проект в консоли разработчика Google

2) Включите Google Drive API

3) Нажмите кнопку создания учетных данных.

4) Заполните отображаемую форму, указав необходимые данные.

5) После отправки запрошенных выше данных будут сгенерированы учетные данные клиента.

Идентификатор клиента

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

Секрет клиента

Получается при регистрации клиентского приложения в целях проверки, но не подлежит разглашению.

URI перенаправления

Если сервер авторизации перенаправляет браузер / пользовательский агент после генерации кода авторизации.

Шаг 2: демонстрация встроенного приложения

Это начальная страница из веб-приложения

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

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

4. После согласия пользователь будет перенаправлен на следующую страницу клиентского приложения, которая указана в URI перенаправления вместе с токеном доступа. Внутри приложение получило токен, отправив код авторизации.

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