Введение в OAuth 2

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

Данное руководство ознакомит вас с ролями OAuth 2, типами авторизации, с потоками и случаями использования OAuth 2.

Роли OAuth

В OAuth существует четыре роли:

  1. Владелец ресурса
  2. Клиент
  3. Сервер ресурсов
  4. Сервер авторизации

Рассмотрим каждую роль подробнее.

Владелец ресурса: пользователь

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

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

Сервер ресурсов и авторизации: API

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

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

Клиент: приложение

Клиент – это приложение, которое  хочет получить доступ к аккаунту пользователя. Прежде чем оно сможет сделать это, пользователь должен авторизоваться в приложении, а API должен подтвердить авторизацию.

Потоки протокола

Роли OAuth взаимодействуют между собой следующим образом:

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

Регистрация приложения

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

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

ID и секретный ключ клиента

После регистрации приложения сервис предоставит вам учётные данные приложения, которые можно найти в поле client identifier и client secret. Client ID – это общедоступная строка, которая используется API сервиса для определения приложения; также с её помощью создаются URL-ы авторизации. Client Secret позволяет API сервиса подтвердить подлинность приложения, когда оно запрашивает доступ к аккаунту пользователя. Эти конфиденциальные данные хранятся между приложением и API.

Полномочия авторизации

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

  1. Код подтверждения: используется в приложениях серверной стороны.
  2. Неявный доступ: используется в веб-и мобильных приложениях (приложениях, которые работают на устройстве пользователя).
  3. Предоставление клиенту пароля: применяется в заведомо безопасных приложениях (например, в принадлежащих сервису приложениях).
  4. Клиентские полномочия: доступ к API приложения.

Код подтверждения

Код подтверждения – самый распространённый тип полномочий, оптимизированный для приложений серверной стороны, в которых исходный код закрыт, а Client Secret недоступен посторонним. Этот поток основан на редиректе, а это означает, что приложение должно иметь возможность взаимодействовать с агентом пользователя (т.е. веб-браузером пользователя) и получать коды авторизации API, которые направляются через агента пользователя.

Поток с кодом подтверждения выглядит так:

  1. Пользователь получает ссылку на код подтверждения.
  2. Пользователь авторизуется. Кликая по ссылке, пользователь подтверждает подлинность данных. Если предоставленные данные неправильные, пользователю будет отказано в авторизации.
  3. Приложение получает код подтверждения. Сервис перенаправляет агента пользователя к URI, который был указан при регистрации клиента, вместе с кодом подтверждения.
  4. Приложение запрашивает токен доступа у API, предоставляя код подтверждения и данные об авторизации, включая client secret.
  5. Приложение получает токен доступа, если авторизация валидна.

 Поток неявного доступа

Поток неявного доступа используется мобильными приложениями или веб-приложениями, где конфиденциальность client secret гарантировать нельзя. Этот поток также основан на редиректе, но токен доступа получает агент пользователя, после чего он передаётся приложению. Таким образом он может быть виден пользователю или другим приложениям на устройстве пользователя. Кроме того, этот поток не выполняет проверку подлинности приложения, для этого используется URI (который был зарегистрирован в сервисе).

При неявном доступе токены обновления не поддерживаются.

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

  1. Пользователь получает ссылку неявного доступа, которая запрашивает токен у API.
  2. Пользователь проходит авторизацию, кликнув по ссылке. Если пользователь не может авторизоваться, ему будет отказано в доступе.
  3. Агент пользователя получает токен доступа и Redirect URI.
  4. Агент пользователя следует Redirect URI.
  5. Приложение отправляет сценарий извлечения токена доступа. Приложение возвращает веб-страницу со сценарием, который может извлечь токен доступа из Redirect URI.
  6. Приложение получает токен доступа. Авторизация завершена.

Предоставление клиенту пароля

Данный тип подразумевает, что пользователь передаёт учётные данные непосредственно приложению, которое с их помощью получает токен доступа. Этот тип должен поддерживаться только на сервере авторизации. Кроме того, его следует использовать только в случае, если приложению можно доверять (например, оно принадлежит сервису или операционной системе пользователя).

Получив учётные данные пользователя, приложение запрашивает токен доступа у сервера авторизации. Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.

Клиентские полномочия

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

Приложение запрашивает токен доступа, отправляя свои учетные данные, client ID и client secret. . Если учётные данные правильные, сервер авторизации предоставит токен доступа. Авторизация завершена.

Использование токенов доступа

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

Если токен валидный, API обрабатывает запрос. Если токен недействителен, API выдаст ошибку invalid_request.

Поток с обновляемым токеном

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

Теперь вы знакомы с основами OAuth 2.

Tags: ,

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