Oauth аутентификация в приложении flask / хабр

Абстрактное описание протокола

Теперь, когда у нас есть представление о ролях, используемых в OAuth, рассмотрим диаграмму их взаимодействия друг с другом.

Рассмотрим описание последовательности шагов на этой диаграмме:

  1. Приложение запрашивает у пользователя авторизацию на доступ к серверу ресурсов.
  2. Если пользователь авторизует запрос, приложение получает разрешение на авторизацию (authorization grant).
  3. Приложение запрашивает авторизационный токен у сервера авторизации (API) путём предоставления информации о самом себе и разрешении на авторизацию от пользователя.
  4. Если подлинность приложения подтверждена и разрешение на авторизацию действительно, сервер авторизации (API) создаёт токен доступа для приложения. Процесс авторизации завершён.
  5. Приложение запрашивает ресурс у сервера ресурсов (API), предоставляя при этом токен доступа для аутентификации.
  6. Если токен действителен, сервер ресурсов (API) предоставляет запрашиваемый ресурс приложению.

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

Краткое введение в oauth

Лучший способ представить OAuth — перечислить список событий, которые происходят во время входа:

Client credentials

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

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

Client id и secret

Задолго до того, как вы разрешили Terrible Pun of the Day получить доступ к контактам, Client и Authorization Server установили рабочие отношения. Authorization Server сгенерировал Client ID и Client Secret (иногда их называют

App IDApp Secret

) и отправил их Client’у для дальнейшего взаимодействия в рамках OAuth.

OAuth аутентификация в приложении Flask / Хабр
«— Привет! Я хотел бы работать с тобой! — Да не вопрос! Вот твои Client ID и Secret!»

Название намекает, что Client Secret должен держаться в тайне, чтобы его знали только Client и Authorization Server. Ведь именно с его помощь Authorization Server подтверждает истинность Client’а.

Id token — это jwt

ID Token

— это особым образом отформатированная строка символов, известная как JSON Web Token или JWT

(иногда токены JWT произносят как «jots»)

. Сторонним наблюдателям JWT может показаться непонятной абракадаброй, однако

Client

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

ID Token

‘а, наличие попыток вмешательства в JWT. Данные внутри

ID Token

‘а называются

заявками[claims]

В случае OIDC также имеется стандартный способ, с помощью которого Client может запросить дополнительную информацию о личности [identity] от Authorization Server’а, например, адрес электронной почты, используя Access Token.

Implicit grant

Теперь у нас сайт без бэкенда – SPA.

Oauth 2.0 – хороший, плохой, злой…

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

Например, вы могли бы использовать веб-приложение (скажем, от Нью-Йорк Таймс) для импорта интересных статей в ваш Facebook или Твиттер. Или вы могли бы использовать приложение для iPhone Quora, с помощью которого пользователи могут получать доступ к доске ваших новостей на том же Facebook или Google .

Его можно настроить с учетом данных вашего профиля: добавлять / приглашать к Quora пользователей, которые находятся в вашем списке друзей. Вопрос в том, как эти приложения получают доступ к вашему аккаунту Facebook, Twitter или Google , а особенно к конфиденциальной информации?

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

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

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

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

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

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

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

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

  • Ресурс владельца: приложение, которое способно предоставлять доступ к защищенному ресурсу. Как правило, конечным пользователям;
  • Клиент: приложение, которое отправляет запросы к защищенному ресурсу от имени его владельца и с его разрешения. Это могут быть серверные, мобильные или настольные приложения;
  • Сервер ресурса: сервер защищенного ресурса, способный принимать и отвечать на запросы к ресурсу;
  • Авторизация на сервере: выдача сервером клиенту грантов / маркеров доступа после успешной аутентификации у ресурса владельца и получения от него разрешения;
  • Маркер доступа: маркеры доступа к учетным данным, которые клиент предоставляет серверу ресурса для получения возможности использовать защищенные ресурсы. Обычно это строка параметров, определяющих границы доступа, продолжительности сессии и другие атрибуты. Она также может содержать данные для прохождения авторизации в той или иной форме;
  • Обновление маркера: Хотя это и не предусмотрено по умолчанию, маркеры доступа в идеале должны иметь срок действия (сессии), который может составлять от нескольких минут до нескольких часов. Как только время действия маркера доступа истекло, клиент может запросить сервер об авторизации и выдаче нового маркера доступа с помощью обновления маркера.

Главным недостатком OAuth 1.0 была слишком большая сложность данной версии.

На самом деле никаких особых проблем не было! Twitter по-прежнему отлично работает с OAuth 1.0 и просто добавил еще и поддержку версии 2.0. OAuth 1.0 был хорошо продуманной версией фреймворка, которая обеспечивала надежный обмен закрытой информацией, и это делало возможным обмен секретной информацией без подключения SSL.

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

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

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

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

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

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

  • Поток веб-сервера: Обеспечивает использование гранта кода авторизации. Он представляет собой поток, основанный на принципе перенаправлений, для которого необходимо взаимодействие с агентом конечного пользователя.

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

  • Поток имен пользователей и паролей: Используется только в случае, когда наличествует высокая степень доверия между клиентом и ресурсом владельца, в то время как прочие потоки не в состоянии решить поставленную задачу. Он предполагает передачу клиенту полномочий владельца ресурса.

    В качестве примера клиента для такого рода взаимодействий можно привести операционную систему устройства или приложение с обширными правами доступа. Он также может использоваться для переноса существующих клиентов через протокол HTTP или схемы Digest Authentication в OAuth путем преобразования записанных учетных данных в маркер доступа;

  • Поток утверждения: Ваш клиент может выдавать утверждение, например SAML утверждения, взамен на предоставленный маркер доступа;
  • Поток идентификационной информации клиента: OAuth используется в основном для делегированного доступа, но бывают случаи, когда клиент является одновременно и владельцем ресурса или уже ему были предоставлены права доступа сверх обычных потоков OAuth . Здесь просто происходит обмен предоставленных идентификационных данных клиента на маркер доступа.

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

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

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

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

Клиент от имени владельца ресурса инициирует поток путем перенаправления к конечной точке авторизации, используя при этом: параметр response_type в качестве кода; идентификатор клиента, который был получен в процессе регистрации клиента; URL-адрес перенаправления; запрошенный объем полномочий (опционально) и текущее состояние (если требуется).

Чтобы получить более наглядное представление о том, как осуществляется весь процесс, на скриншоте ниже графически представлено, как будет выглядеть обработка стандартного запроса / ответа:

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

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

Как это показано на рисунке ниже:

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

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

Запрос на получение доступа к закрытым ресурсам с использованием маркеров доступа.

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

При этом в заголовке Authorization запроса прилагается маркер доступа. В качестве примера CURL-запроса на получение в блог данных с Google Blogger API с учетом идентификатора может послужить следующий код:

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

Имейте в виду, что выделение маркера доступа требуется только при двустороннем взаимодействии. В результате чего отправляется запрос:

Затем сервер ресурса проверяет передаваемые данные (маркер доступа) и в случае успешной проверки, отправляет запрашиваемую информацию.

Данные примеры иллюстрируют принципы работы OAuth2.0 Playground. Подобным образом, как правило, реализуется взаимодействие данной версии с Google.

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

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

К нему прилагаются идентификатор клиента и секретный код, а также параметр grant_type в качестве refresh_token.

В ответ сервер авторизации отправляет пакет с новым значением маркера.

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

Хороший (положительный момент).

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

Плохой (негативные моменты).

Неотточенные элементы версии OAuth 2.0 могут привести к тому, что большое количество решений по его внедрению будут несовместимы друг с другом.

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

  • Взаимодействие: Добавление слишком большого количества обновлений и расширений привело к тому, что некоторые компоненты просто несовместимы друг с другом. Это значит, что вы не можете написать универсальный код с использованием Endpoint Discovery, и быть уверенным, что он подойдет для взаимодействия с различными сервисами.

    На самом деле вам придется писать отдельные фрагменты кода под Facebook, Google, Salesforce и так далее. Данный момент даже признан в спецификации версии;

  • Ограниченный срок действия маркеров: Данная версия фреймворка не обеспечивает бессрочный период действия всех маркеров, которые были выданы.

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

  • Безопасность: В данной версии всего лишь «рекомендовано» использование протоколов SSL / TLS при отправке маркеров в виде обычного текста по сети.

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

Было перепробовано порядка 31 черновой версии фреймворка, в ходе чего также был смещен ведущий автор / разработчик Эран Хаммер, прежде чем новая версия, наконец, увидела свет. Эран настаивал на том, что в данной спецификации реализован «плохой протокол и она нежизнеспособна вследствие еще тысячи огрех».

По его словам, использование маркеров «на предъявителя» (отправка маркеров по SSL без подписи их или любой другой верификации) вместо сигнатур пользователей (или MAC-маркеров), которые использовались в OAuth 1.0 – это неудачное решение. Это, по его словам, результат предпочтения интересов предпринимателей интересам веб-сообщества.

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

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

Однако с каждым новым внедрением для больших сервисов (Google, Twitter, Facebook, Salesforce, Foursquare, Github и т.д.) OAuth становится все популярнее.

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

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

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

Дамы и господа, встречайте: oauth 2.0

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

[permission]

(или

согласия[consent]

) часто называют

авторизацией[authorization]

или даже

делегированной авторизацией[delegated authorization]

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

В качестве примера представим, что вы обнаружили сайт с названием «Неудачный каламбур дня» [Terrible Pun of the Day] и решили зарегистрироваться на нем, чтобы ежедневно получать каламбуры в виде текстовых сообщений на телефон. Сайт вам очень понравился, и вы решили поделиться им со всеми знакомыми. Ведь жуткие каламбурчики нравятся всем, не так ли?

OAuth аутентификация в приложении Flask / Хабр
«Неудачный каламбур дня: Слышали о парне, который потерял левую половину тела? Теперь он всегда прав!» (перевод примерный, т.к. в оригинале своя игра слов — прим. перев.)

Понятно, что писать каждому человеку из контакт-листа не вариант. И, если вы хотя бы чуточку похожи на меня, то пойдете на всё, чтобы избежать лишней работы. Благо Terrible Pun of the Day может сам пригласить всех ваших друзей! Для этого лишь нужно открыть ему доступ к электронной почте контактов — сайт сам отправит им приглашения (OAuth рулит)!

Зачем нужен authorization code

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

Дело в том, что это безопаснее. Канал между приложениями (клиентом и сервером ресурсов) безопасный (back сhannel). А канал запросов, проходящих через браузер (front channel), — нет.

Код авторизации проходит через браузер: он возвращается в url при перенаправлении обратно на клиент. Для обращения к ресурсам прошедший через браузер код авторизации не очень подходит.

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

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

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

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

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

Минусы

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

Но это ещё не всё… пожалуйста, поприветствуйте openid connect!

OAuth 2.0 разработан только для

авторизации

— для предоставления доступа к данным и функциям от одного приложения другому.

Обновление токена доступа

После истечения срока действия токена доступа все запросы к API с его использованием будут возвращать ошибку “Invalid Token Error”. Если при создании токена доступа был создан и токен для обновления токена доступа (refresh token), последний может быть использован для получения нового токена доступа от авторизационного сервера.

Ниже представлен пример POST-запроса, использующего токен для обновления токена доступа для получения нового токена доступа:

Поток oauth

Только что мы прошли через то, что обычно называют

потоком[flow]

OAuth. В нашем примере этот поток состоит из видимых шагов, а также из нескольких невидимых шагов, в рамках которых два сервиса договариваются о безопасном обмене информацией. В предыдущем примере с Terrible Pun of the Day используется наиболее распространенный поток OAuth 2.0, известный как поток «с кодом авторизации»

[«authorization code» flow]

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

  • Resource Owner:

    OAuth аутентификация в приложении Flask / Хабр

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

  • Client:

    OAuth аутентификация в приложении Flask / Хабр

    Приложение (например, сервис Terrible Pun of the Day), которое хочет получить доступ или выполнить определенные действия от имени Resource Owner‘а.

  • Authorization Server:

    OAuth аутентификация в приложении Flask / Хабр

    Приложение, которое знает Resource Owner‘а и в котором у Resource Owner‘а уже есть учетная запись.

  • Resource Server:

    OAuth аутентификация в приложении Flask / Хабр

    Программный интерфейс приложения (API) или сервис, которым Client хочет воспользоваться от имени Resource Owner‘а.

  • Redirect URI:

    OAuth аутентификация в приложении Flask / Хабр

    Ссылка, по которой Authorization Server перенаправит Resource Owner‘а после предоставления разрешения Client‘у. Иногда ее называют «Возвратным URL» («Callback URL»).

  • Response Type:

    OAuth аутентификация в приложении Flask / Хабр

    Тип информации, которую ожидает получить Client. Самым распространенным Response Type‘ом является код, то есть Client рассчитывает получить Authorization Code.

  • Scope:

    OAuth аутентификация в приложении Flask / Хабр

    Это подробное описание разрешений, которые требуются Client‘у, такие как доступ к данным или выполнение определенных действий.

  • Consent:

    OAuth аутентификация в приложении Flask / Хабр

    Authorization Server берет Scopes, запрашиваемые Client‘ом, и спрашивает у Resource Owner‘а, готов ли тот предоставить Client‘у соответствующие разрешения.

  • Client ID:

    OAuth аутентификация в приложении Flask / Хабр

    Этот ID используется для идентификации Client‘а на Authorization Server‘е.

  • Client Secret:

    OAuth аутентификация в приложении Flask / Хабр

    Это пароль, который известен только Client‘у и Authorization Server‘у. Он позволяет им конфиденциально обмениваться информацией.

  • Authorization Code:

    OAuth аутентификация в приложении Flask / Хабр

    Временный код с небольшим периодом действия, который Client предоставляет Authorization Server‘у в обмен на Access Token.

  • Access Token:

    OAuth аутентификация в приложении Flask / Хабр

    Ключ, который клиент будет использовать для связи с Resource Server‘ом. Этакий бейдж или ключ-карта, предоставляющий Client‘у разрешения на запрос данных или выполнение действий на Resource Server‘е от вашего имени.

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

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

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

Из плюсов протокола OAuth 2.0 можно выделить следующее:

Из минусов:

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

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

Ниже представлен пример запроса к API с использованием curl. Обратите внимание, что он содержит токен доступа:

Пример реализации протокола на php

Рассмотрим живой пример проекта клиент-серверного стороннего приложения, взаимодействующего по API с сервисом Google Таблицы.

Процесс с учётными данными владельца ресурса

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

Процесс с учётными данными клиента

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

Различия протоколов openid и oauth 2

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

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

Разрешение на авторизацию

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

  • Код авторизации (Authorization Code): используется с серверными приложениями (server-side applications).
  • Неявный (Implicit): используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
  • Учётные данные владельца ресурса (Resource Owner Password Credentials): используются доверенными приложениями, например приложениями, которые являются частью самого сервиса.
  • Учётные данные клиента (Client Credentials): используются при доступе приложения к API.

Далее мы рассмотрим эти типы разрешения на авторизацию, примеры их использования.

Реализация oauth

Для Python существует несколько клиентских пакетов OAuth. В этом примере я решил использовать Rauth. Однако, даже при использовании пакета OAuth существует множество аспектов проверки подлинности провайдерами, что затрудняет задачу.

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

По этой причине я решил реализовать слой абстракции поверх Rauth, так что приложение Flask может быть написано в общем виде. Ниже представлен простой базовый класс, в котором будут написаны конкретные реализации провайдера:

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

Перед тем, как начать использовать OAuth в вашем приложении, вам необходимо зарегистрировать своё приложения в сервисе. Это делается путём регистрации в разделе “developer” или “API” сайта сервиса, где вам необходимо предоставить следующую информацию (возможно, включая некоторые детали о вашем приложении):

  • Название приложения
  • Сайт приложения
  • Redirect URL или callback URL

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

Роли oauth

OAuth определяет четыре роли:

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

Далее мы рассмотрим каждую из ролей.

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

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

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

Способы получения access token

Всего есть 4 способа:

Тип разрешения на авторизацию: учётные данные клиента

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

Фаза авторизации oauth

Когда пользователь нажимает ссылку «Вход в систему с …» для инициирования аутентификации OAuth, вызов следует по такому маршруту:

Фаза обратного вызова callback oauth

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

Шаг 1: ссылка для неявной авторизации

При неявном типа разрешения на авторизацию пользователю предоставляется ссылка, запрашивающая токен у API. Эта ссылка выглядит почти так же, как ссылка для предыдущего способа (с кодом авторизации), за исключением того, что запрашивается токен вместо кода (обратите внимание на response type “token”):

Шаг 1: ссылка с кодом авторизации

Сначала пользователю предоставляется ссылка следующего вида:

Шаг 3: пользовательский агент получает токен доступа с uri перенаправления

Если пользователь выбирает “Авторизовать приложение”, сервис перенаправляет пользовательский агент по URI пренправления приложения и включает в URI фрагмент, содержащий токен доступа. Это выглядит примерно вот так:

Шаг 4: пользовательский агент следует по uri перенаправления

Пользовательский агент следует по URI перенаправления, сохраняя при этом токен доступа.

Шаг 5: приложение выполняет скрипт извлечения токена доступа

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

Шаг 5: приложение получает токен доступа

Если авторизация прошла успешно, API возвращает токен доступа (а также, опционально, токен для обновления токена доступа – refresh token). Весь ответ сервера может выглядеть следующим образом:

Шаг 6: токен доступа передаётся приложению

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

Теперь приложение авторизовано! Оно может использовать токен для доступа к пользовательскому аккаунту через API сервиса с заданными ограничениями доступа до тех пор, пока не истечёт срок действия токена или токен не будет отозван.

Итоги

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

В целом, OAuth 2.0 исправляет недостатки OAuth 1.0, но имеет ряд своих недостатков. На данный момент он все еще находится в развитии. Следующая ожидаемая версия стандарта — OAuth 2.1.

Похожее:  PHP: Using cURL with Basic HTTP Authentication.

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *