Что такое OAuth 2.0

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

История возникновения

История возникновения OAuth тесно связана с именем канадского инженера-программиста Блейна Кука. Разрабатывая совместно с Крисом Мессиной протокол OpenID для сервиса микроблогов Twitter в ноябре 2006 года, он вынужден был искать методы его использования для взаимодействия с Twitter API без необходимости предоставлять пароль. 4 декабря 2007 года была утверждена первая версия OAuth 1.0. Проект развивался, и в 2010 году появился протокол OAuth 2.0, а в октябре 2012 года он был опубликован в качестве релиза RFC 67491. Огромное количество интернет-сервисов, таких как Google, Twitter, Apple и других предполагало множество учетных записей с пользовательскими логинами и паролями. Необходимость упрощения процесса аутентификации стала основной целью проекта.

Роли в OAuth 2.0

Рассмотрим четыре основные роли выполняющие разные функции:

• владелец (Resource Owner) — как правило, пользователь, предоставляющий доступ к своим данным;
• клиент (Client) — приложение, запрашивающее от имени пользователя эти данные (мобильное, веб-приложение и другие);
• сервер ресурсов (Resource Server) — сервер хранения защищенных пользовательских данных;
• сервер авторизации (Authorization Server) — в его задачи входят аутентификация владельца и выдача токенов доступа.

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

Как работает OAuth 2.0

Постараемся наглядно описать общий принцип работы OAuth 2.0.

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

Области действия

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

Примеры областей включают:

• read — разрешение на чтение данных пользователя (например, доступ к чтению списка контактов);
• write — разрешение на запись (один из вариантов — запись файлов в облачное хранилище);
• profile — доступ к профилю пользователя;
• email — доступ к адресу электронной почты.

Использование областей:

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

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

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

Токены и код авторизации в OAuth 2.0

Для предоставления доступа в OAuth 2.0 используются токены, а для обеспечения безопасности процесса авторизации — код авторизации.

Процесс авторизации с использованием кода происходит следующим образом:

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

В протоколе OAuth 2.0 ключи, используемые приложениями для выполнения запросов к серверу ресурсов от имени пользователя, называются токенами доступа. Они служат для авторизации приложения-клиента на доступ к определенным частям данных пользователя.

Примеры токенов:

• токен авторизации (Authorization Code) служит для обмена на токен доступа;
• токен доступа (Access Token) предоставляет доступ к ресурсам и имеет короткий жизненный цикл;
• токен обновления (Refresh Token) долгосрочный токен, используемый для получения нового токена доступа без повторной аутентификации.

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

Примеры грантов:

• авторизационный код (Authorization Code) используется для веб-приложений, запущенных на веб-сервере;
• имплицитный поток (Implicit Flow) — для клиентских приложений (например, SPA);
• парольный грант (Password Grant) — не рекомендуется из-за соображений безопасности.

Аспекты конфиденциальности:

• Для клиентского приложения токен доступа представляет собой непрозрачную строку. Приложение использует ее в HTTP-запросах к серверу ресурсов, но оно не обязано понимать его смысл. Проверка и валидирование токена обеспечивается сервером ресурсов.
• Как во время передачи, так и в хранилище токены доступа должны оставаться конфиденциальными. Только сервер ресурсов, сервер авторизации и приложение-клиент могут взаимодействовать с токеном.
• Использовать токен доступа можно только через защищенное HTTPS-соединение. Передача по незашифрованному каналу создает опасность его перехвата.

Отличие OAuth 2.0 от OpenID

Протоколы OAuth 2.0 и OpenID имеют схожие аспекты, что нередко вызывает путаницу у разработчиков. Но выполняют они при этом разные функции.

Рассмотрим их характерные отличия.

Назначение OpenID

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

Назначение OAuth 2.0

Авторизация — разрешение доступа к ресурсам для сторонних приложений без необходимости передачи пароля пользователя. Однако в некоторых случаях (например, Google API12) протокол OAuth 2.0 также может быть использован для аутентификации.

В завершение статьи стоит упомянуть и о расширении OAuth 2.0 — OpenID Connect (OIDC). OpenID Connect представляет собой комбинацию функций OpenID 2.0, OpenID Attribute Exchange 1.0 и OAuth 2.0. Возможности OAuth 2.0 интегрированы непосредственно в сам протокол. Таким образом он сочетает в себе как авторизацию, так и аутентификацию.