Хабрахабр

[Перевод] Иллюстрированное руководство по OAuth и OpenID Connect

Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.

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

— «Обещаем, что с паролем и деньгами все будет в порядке.
«Предоставьте свою банковскую учётку». Вот прям честно-пречестно!» *хи-хи*

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

К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. Ну и ладно!). Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню?

Между прочим, это руководство также доступно в формате видео:

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

OAuth 2.0 — это стандарт безопасности, позволяющий одному приложению получить разрешение на доступ к информации в другом приложении. Последовательность действий для выдачи разрешения [permission] (или согласия [consent]) часто называют авторизацией [authorization] или даже делегированной авторизацией [delegated authorization]. С помощью этого стандарта вы позволяете приложению считать данные или использовать функции другого приложения от вашего имени, не сообщая ему свой пароль. Класс!

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

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

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

— Уже залогинились?
«Все любят каламбуры! — Спасибо! — Хотите открыть доступ сайту Terrible Pun of the Day к списку контактов? Вы самый лучший друг!» Теперь мы каждый день будем слать напоминания всем, кого вы знаете, до скончания веков!

  1. Выберите свой сервис электронной почты.
  2. При необходимости перейдите на сайт почты и войдите в учетную запись.
  3. Дайте разрешение сайту Terrible Pun of the Day на доступ к контактам.
  4. Вернитесь на сайт Terrible Pun of the Day.

В случае, если вы передумаете, приложения, использующие OAuth, также предоставляют способ аннулировать доступ. Решив, что вы больше не желаете делиться контактами с Terrible Pun of the Day, вы можете перейти на сайт почты и удалить сайт с каламбурами из списка авторизованных приложений.

Поток OAuth

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

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

  • Resource Owner:

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

  • Client:

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

  • Authorization Server:

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

  • Resource Server:

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

  • Redirect URI:

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

  • Response Type:

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

  • Scope:

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

  • Consent:

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

  • Client ID:

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

  • Client Secret:

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

  • Authorization Code:

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

  • Access Token:

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

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

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

  1. Вы, Resource Owner, желаете предоставить сервису Terrible Pun of the Day (Client'у) доступ к своим контактам, чтобы тот мог разослать приглашения всем вашим друзьям.
  2. Client перенаправляет браузер на страницу Authorization Server'а и включает в запрос Client ID, Redirect URI, Response Type и одно или несколько Scopes (разрешений), которые ему необходимы.
  3. Authorization Server проверяет вас, при необходимости запрашивая логин и пароль.
  4. Authorization Server выводит форму Consent (подтверждения) с перечнем всех Scopes, запрашиваемых Client'ом. Вы соглашаетесь или отказываетесь.
  5. Authorization Server перенаправляет вас на сайт Client'а, используя Redirect URI вместе с Authorization Code (кодом авторизации).
  6. Client напрямую связывается с Authorization Server'ом (в обход браузера Resource Owner'а) и безопасно отправляет Client ID, Client Secret и Authorization Code.
  7. Authorization Server проверяет данные и отвечает с Access Token'ом (токеном доступа).
  8. Теперь Client может использовать Access Token для отправки запроса на Resource Server с целью получить список контактов.

Client ID и Secret

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

Я хотел бы работать с тобой!
«— Привет! Вот твои Client ID и Secret!» — Да не вопрос!

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

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

OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись. Организацию логин-сессии часто называют аутентификацией [authentication], а информацию о пользователе, вошедшем в систему (т.е. о Resource Owner'е), — личными данными [identity]. Если Authorization Server поддерживает OIDC, его иногда называют поставщиком личных данных [identity provider], поскольку он предоставляет Client'у информацию о Resource Owner'е.

Например, приложение может поддерживать SSO-интеграцию с социальными сетями, такими как Facebook или Twitter, позволяя пользователям использовать учётную запись, которая у них уже имеется и которую они предпочитают использовать. OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO).

Единственная разница в том, что в первичном запросе используемый конкретный scope — openid, — а Client в итоге получает как Access Token, так и ID Token. Поток (flow) OpenID Connect выглядит так же, как и в случае OAuth.

С точки зрения ClientAccess Token представляет некую строку из символов, которая передается вместе с каждым запросом к Resource Server'у, а тот определяет, действителен ли токен. Так же, как и в потоке OAuth, Access Token в OpenID Connect — это некое значение, не понятное Client'у. ID Token представляет собой совсем иное.

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.

Дополнительные сведения об OAuth и OIDC

Итак, мы вкратце рассмотрели принципы работы OAuth и OIDC. Готовы копнуть глубже? Вот дополнительные ресурсы, которые помогут узнать больше об OAuth 2.0 и OpenID Connect:
Как обычно, не стесняйтесь комментировать. Чтобы быть в курсе наших последних новинок, подписывайтесь на Twitter и YouTube компании Okta для разработчиков!

P.S. от переводчика

Читайте также в нашем блоге:

Теги
Показать больше

Похожие статьи

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

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

Кнопка «Наверх»
Закрыть