Как работает OAuth 2.0 и OpenID Connect. Access token что это?

Доброе утро, дорогой читатель. В этой статье я попытаюсь рассказать об одном из самых популярных (на сегодняшний день) типов авторизации в различных клиент-серверных приложениях — токене авторизации. Но токен авторизации представлен наиболее популярным JSON Web Token или JWT.

OAuth 2: введение в протокол авторизации

В данной статье описаны механизмы, методы и примеры использования этой технологии.

OAuth 2 — это протокол авторизации, предназначенный для организации доступа пользователя к ресурсам или учетных данных к другому сервису для клиентских приложений. Клиентские приложения — это веб-приложения, приложения для мобильных телефонов и настольных компьютеров. Среди сервисов — mail.ru, GitHub, Bitbucket и др. Сторонние разработчики приложений используют этот протокол.

Мы сталкиваемся с этим протоколом, когда:

• авторизуемся на сторонних площадках через аккаунты соцсетей;
• устанавливаем себе на мобильное устройство приложение, взаимодействующее с нашими данными в облачных сервисах типа Google или Яндекс;
• используем сторонние приложения (боты в Telegram и других мессенджерах) для уведомлений и пр.

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

Различия протоколов OpenID и OAuth 2

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

Для аутентификации пользователя OpenID использует идентификатор учетной записи у провайдера, а OAuth — ключи авторизации (токены) с заранее определенным сроком действия и правами доступа.

Используемые роли в OAuth 2

В рамках описанного протокола выделяются следующие типы ролей:

• владелец (пользователь): авторизует клиентское приложение на доступ к данным своего аккаунта;
• сервер ресурсов/API: здесь располагаются данные пользовательских аккаунтов, а также бизнес-логика авторизации, отвечающая за выдачу новых OAuth-токенов и проверку их подлинности при обращении клиентских приложений к ресурсам. Целесообразно объединять эти роли, так как физически это один сервис;
• клиентское приложение: собственно сервис, которому пользователь делегирует права доступа к своим данным на сервере ресурсов. Пользователь должен авторизовать приложение, а со стороны сервера API оно должно получить подтверждение в виде ключа (токена) доступа.

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

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

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

В первые дни существования Facebook пользователям приходилось указывать имя пользователя и пароль учетной записи Gmail, чтобы отправить приглашения своим контактам. У этого подхода была серьезная проблема: имя пользователя и пароль давали полный доступ к сервису. Именно поэтому был разработан стандарт OAuth.

С помощью этого стандарта вы позволяете приложению считывать данные или изменять l

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

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

Дело в том, что клиент должен каким-то образом получить токен доступа от сервера авторизации. Существует четыре способа сделать это, которые мы рассмотрим ниже. С помощью этого access_token клиент может получать определенные данные в запросах к серверу ресурсов.

• Владелец ресурса.
• Клиент.
• Сервер ресурсов.
• Авторизационный сервер.

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

Вернемся к основной схеме. Сервер авторизации должен знать о каждом клиенте, который обращается к нему с запросом. Это означает, что каждый клиент должен быть зарегистрирован. При регистрации клиента мы получаем client_id и client_secret и должны передавать каждому запросу как минимум client_id.

Не все клиенты могут гарантировать client_secret, поэтому не все клиенты имеют его. Например, SPA без бэкенда, теоретически вы можете получить все оттуда.

Возможна динамическая регистрация клиентов: RFC 7591 и RFC 7592.

Всего существует 4 варианта:

Стандарт не запрещает вам объединить Сервер ресурсов и Авторизационный сервер

Базовая схема протокола

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

curl —request POST \ —url ‘https://YOUR_DOMAIN/oauth/token’ \ —header ‘content-type: application/x-www-form-urlencoded’ \ -данные_тип_гранта=

клиентские_учетные_данные

\ —data client_id=YOUR_CLIENT_ID \ —data client_secret=YOUR_CLIENT_SECRET \ —data audience=YOUR_API_IDENTIFIER

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

3. API 1 может взаимодействовать с API 2.

curl —request GET \ —url https://api2.com/api \ —header ‘authorisation: Bearer ACCESS_TOKEN’ \ —header ‘content-type: application/json’

Способы получения Access Token

4. API 2 получает запрос access_token и вызывает сервер авторизации для проверки валидности переданного токена (RFC 7662).

• По авторизационному коду (Authorization Code Grand). Самый сложный и самый надежный способ.
• Неявно (Implicit)
• По логину и паролю пользователя (Resource Owner Password Credential). Только для безопасных клиентов, заслуживающих полного доверия.
• По данным клиента (Client Credentials). Получаем токен по client_id и client_secret .

Client Credentials

Такое расположение не рекомендуется! Это не рекомендуется!

1. API 1 идет в авторизационный сервер передает туда client_id и client_secret .

В случае OIDC также существует стандартный метод, с помощью которого клиент может запросить дополнительную информацию о пользователе у сервера аутентификации, например, адрес электронной почты, используя access_token.Прежде чем мы рассмотрим сам токен авторизации, следует упомянуть, для каких целей он будет использоваться. Поскольку мы знаем, что почти весь Интернет так или иначе построен на протоколе HTTP (или его старшем брате HTTPS), и что он не отслеживает состояние, т.е. при каждом HTTP-запросе он не знает, что было раньше, он только передает запросы, возникает следующая проблема: если аутентификация пользователя осуществляется с помощью имени пользователя и пароля, то при каждом последующем запросе наше приложение не знает, тот ли это человек, и поэтому ему приходится каждый раз вводить новый логин. Решением этой проблемы является токен и, в частности, его наиболее популярная реализация - JSON Web Tokens (JWT). Помимо проблемы аутентификации, токен также решает другую важную проблему авторизации (разграничение действий, разрешенных конкретному пользователю). Как решить эту проблему, мы узнаем позже, когда начнем анализировать структуру лексем.Теперь перейдем к функциональности самого токена. Как упоминалось ранее, в качестве маркеров чаще всего используются JSON Web Tokens (JWT), и хотя реализации могут быть разными, JWT-токены стали стандартом, поэтому мы рассмотрим их в качестве примера.

JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания маркеров доступа на основе JSON.

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

Давайте рассмотрим, как клиент-серверное приложение работает с JWT. Во-первых, пользователь должен аутентифицироваться, если он этого еще не сделал и необходимо ввести, например, имя пользователя и пароль. Затем приложение выдает ему 2 токена: токен доступа и токен обновления (зачем ему нужен последний, объясняется ниже, сейчас мы говорим о токене доступа). Пользователь хранит их каким-либо образом, например, в локальной памяти или в памяти сеанса. Затем, когда пользователь делает запрос к API приложения, он добавляет маркер доступа, полученный ранее. И, наконец, после получения запроса с маркером наше приложение проверяет, действителен ли этот маркер (относительно этого

Заголовок содержит два основных поля: alg и typ. Поле typ предназначено для информации о типе токена, но поскольку я уже упоминал, что JWT стал своего рода стандартом, это поле больше не имеет особого значения и предназначено скорее для будущих целей, на случай, если появится более совершенная версия алгоритма JWT(2.0) и заменит JWT. Поле alg указывает алгоритм шифрования. Обязательным для всех реализаций является алгоритм HMAC, использующий SHA-256 или, как указано в заголовке, HS256. Этот алгоритм требует одного секретного ключа; точный механизм объясняется ниже. Следует отметить, что существует асимметричный алгоритм, который может быть использован в JWT, например RS256. Для этого требуется два ключа, один открытый и один закрытый. Однако в этой статье мы рассмотрим работу с закрытым ключом.

Resource Owner Password Credential

Наконец, перейдем к полезным данным. Опять же, это объект JSON, представленный строкой в кодировке base64 для удобства и безопасности передачи. Иллюстративный пример полезных данных (playload) токена может быть представлен следующей строкой:

1. Владелец ресурсов передает свой логин и пароль Клиенту.
2. Клиент отправляет Авторизационному серверу логин и пароль клиента, а так же свой client_id и client_secret .

Что представляет собой формат JSON:Здесь хранится вся полезная информация. Для этой части нет обязательных полей, наиболее распространенными являются следующие.iss - используется для идентификации приложения, из которого отправляется токен.

user_id — используется для идентификации пользователя приложения, которому принадлежит токен.

Authorization Code Grand

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

В этот момент мы поняли, что хотя токен не защищен и не зашифрован, любой может изменить его и тем самым нарушить всю концепцию аутентификации. Эта проблема решается с помощью последней части токена, а именно подписи. Когда пользователь подтверждает, что он тот, за кого себя выдает, приложение генерирует этот токен, определяет необходимые поля, берет туда данные, характеризующие пользователя, и, используя заранее выбранный алгоритм (указанный в заголовке в поле alg token), например, HMAC-SHA256, и используя свой закрытый ключ (или секретный набор, хранящийся только на серверах приложения), подписывает все данные в токене. Затем сгенерированная подпись, также в формате base64, добавляется к концу токена. Таким образом, результирующий токен представляет собой закодированную и подписанную строку. Если кто-то затем сделает запрос к API нашего приложения, сервер сможет проверить эту подпись с помощью своего секретного ключа и таким образом убедиться, что токен не был подделан. Эта проверка представляет собой процесс, подобный подписи, поэтому, когда он получает маркер в новом запросе, он извлекает заголовок и полезную нагрузку, затем подписывает их своим секретным ключом, а затем просто сравнивает две получившиеся строки. Таким простым способом, если мы не взломаем секретный ключ, мы всегда можем знать, что %username% все еще перед нами, с четко назначенными привилегиями.

Мы рассмотрели наиболее распространенные способы получения access_token для работы с API Вконтакте.

Еще одно небольшое введение

Если у вас возникли проблемы с работой access_token с API Вконтакте, напишите в комментариях или мне в Telegram.

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

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

Преимущества протокола OAuth 2.0 заключаются в следующем:

Принцип работы

Среди недостатков:

Структура токена

Ets

1. Заголовок (header)
2. Полезные данные (playload)
3. Подпись (signature)

Заголовок

Полезные данные

Подпись

Как получить ключ доступа приложения

• Переходим в раздел управления приложениями: https://vk.com/apps?act=manage
• Нажимаем “Создать приложение”
• Заполняем данные:

• Переходим в “Настройки приложения” где видим сервисный ключ доступа

Зачем нужен refresh токен?

Преимущества и недостатки OAuth 2.0

• Обращение к ресурсам происходит по HTTP/HTTPS с указанием токена в заголовках. Это позволяет использовать OAuth практически в любых решения: мобильных и десктоп-приложениях, сайтах и даже в плагинах для браузеров.
• Возможность авторизации пользователя.
• Популярность — большинство компаний используют его в своих API.
• Простота реализации и большое количество литературы.
• Наличие готовых решений, которые можно изменять под свои нужды.

• Нет единого установленного формата, вследствие чего на каждый сервис нужно иметь отдельную реализацию.
• При аутентификации иногда приходится делать дополнительные запросы для получения даже минимальной информации о пользователе. Решается использованием jwt -токена, но далеко не все сервисы его поддерживают.
• При краже токена у злоумышленника на какое-то время появляется доступ к защищенным данным. Для минимизации данного варианта можно использовать токен с подписью.

Итоги