Прим. перев.: В этом замечательном материале компании Okta просто и наглядно рассказывается о принципах работы OAuth и OIDC (OpenID Connect). Эти знания будут полезны разработчикам, системным администраторам и даже «обычным пользователям» популярных веб-приложений, которые скорее всего тоже обмениваются конфиденциальными данными с другими сервисами.
В «каменном веке» интернета делиться информацией между сервисами было легко. Вы просто давали свой логин и пароль от одного сервиса другому, чтобы тот вошел в вашу учетную запись и получил любую необходимую ему информацию.
«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*
Жуть! Никто и никогда не должен требовать от пользователя поделиться логином и паролем, его учётными данными, с другим сервисом. Нет никакой гарантии, что организация, стоящая за этим сервисом, будет хранить данные в безопасности и не соберет больше персональной информации, чем нужно. Это может показаться дикостью, но некоторые приложения до сих пор применяют подобную практику!
Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).
Между прочим, это руководство также доступно в формате видео:
OAuth 2.0 — это стандарт безопасности, позволяющий одному приложению получить разрешение на доступ к информации в другом приложении. Последовательность действий для выдачи разрешения [permission] (или согласия [consent]) часто называют авторизацией [authorization] или даже делегированной авторизацией [delegated authorization]. С помощью этого стандарта вы позволяете приложению считать данные или использовать функции другого приложения от вашего имени, не сообщая ему свой пароль. Класс!
В качестве примера представим, что вы обнаружили сайт с названием «Неудачный каламбур дня» [Terrible Pun of the Day] и решили зарегистрироваться на нем, чтобы ежедневно получать каламбуры в виде текстовых сообщений на телефон. Сайт вам очень понравился, и вы решили поделиться им со всеми знакомыми. Ведь жуткие каламбурчики нравятся всем, не так ли?
«Неудачный каламбур дня: Слышали о парне, который потерял левую половину тела? Теперь он всегда прав!» (перевод примерный, т.к. в оригинале своя игра слов — прим. перев.)
Понятно, что писать каждому человеку из контакт-листа не вариант. И, если вы хотя бы чуточку похожи на меня, то пойдете на всё, чтобы избежать лишней работы. Благо Terrible Pun of the Day может сам пригласить всех ваших друзей! Для этого лишь нужно открыть ему доступ к электронной почте контактов — сайт сам отправит им приглашения (OAuth рулит)!
«Все любят каламбуры! — Уже залогинились? — Хотите открыть доступ сайту Terrible Pun of the Day к списку контактов? — Спасибо! Теперь мы каждый день будем слать напоминания всем, кого вы знаете, до скончания веков! Вы самый лучший друг!»
В случае, если вы передумаете, приложения, использующие OAuth, также предоставляют способ аннулировать доступ. Решив, что вы больше не желаете делиться контактами с Terrible Pun of the Day, вы можете перейти на сайт почты и удалить сайт с каламбурами из списка авторизованных приложений.
Только что мы прошли через то, что обычно называют потоком [flow] OAuth. В нашем примере этот поток состоит из видимых шагов, а также из нескольких невидимых шагов, в рамках которых два сервиса договариваются о безопасном обмене информацией. В предыдущем примере с Terrible Pun of the Day используется наиболее распространенный поток OAuth 2.0, известный как поток «с кодом авторизации» [«authorization code» flow].
Прежде чем углубиться в подробности работы OAuth, давайте поговорим о значении некоторых терминов:
Примечание: иногда Authorization Server и Resource Server являются одним и тем же сервером. Однако в некоторых случаях это могут быть разные серверы, даже не принадлежащие к одной организации. Например, Authorization Server может быть сторонним сервисом, которому доверяет Resource Server.
Теперь, когда мы ознакомились с основными понятиями OAuth 2.0, давайте вернемся к нашему примеру и подробно рассмотрим, что происходит в потоке OAuth.
Задолго до того, как вы разрешили Terrible Pun of the Day получить доступ к контактам, Client и Authorization Server установили рабочие отношения. Authorization Server сгенерировал Client ID и Client Secret (иногда их называют App ID и App Secret) и отправил их Client'у для дальнейшего взаимодействия в рамках OAuth.
«— Привет! Я хотел бы работать с тобой! — Да не вопрос! Вот твои Client ID и Secret!»
Название намекает, что Client Secret должен держаться в тайне, чтобы его знали только Client и Authorization Server. Ведь именно с его помощь Authorization Server подтверждает истинность Client'а.
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись. Организацию логин-сессии часто называют аутентификацией [authentication], а информацию о пользователе, вошедшем в систему (т.е. о Resource Owner'е), — личными данными [identity]. Если Authorization Server поддерживает OIDC, его иногда называют поставщиком личных данных [identity provider], поскольку он предоставляет Client'у информацию о Resource Owner'е.
OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO). Например, приложение может поддерживать SSO-интеграцию с социальными сетями, такими как Facebook или Twitter, позволяя пользователям использовать учётную запись, которая у них уже имеется и которую они предпочитают использовать.
Поток (flow) OpenID Connect выглядит так же, как и в случае OAuth. Единственная разница в том, что в первичном запросе используемый конкретный scope —
Так же, как и в потоке OAuth, Access Token в OpenID Connect — это некое значение, не понятное Client'у. С точки зрения Client'а Access Token представляет некую строку из символов, которая передается вместе с каждым запросом к Resource Server'у, а тот определяет, действителен ли токен. ID Token представляет собой совсем иное.
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 2.0 и OpenID Connect:
Как обычно, не стесняйтесь комментировать. Чтобы быть в курсе наших последних новинок, подписывайтесь на Twitter и YouTube компании Okta для разработчиков!
Читайте также в нашем блоге:
В «каменном веке» интернета делиться информацией между сервисами было легко. Вы просто давали свой логин и пароль от одного сервиса другому, чтобы тот вошел в вашу учетную запись и получил любую необходимую ему информацию.
«Предоставьте свою банковскую учётку». — «Обещаем, что с паролем и деньгами все будет в порядке. Вот прям честно-пречестно!» *хи-хи*
Жуть! Никто и никогда не должен требовать от пользователя поделиться логином и паролем, его учётными данными, с другим сервисом. Нет никакой гарантии, что организация, стоящая за этим сервисом, будет хранить данные в безопасности и не соберет больше персональной информации, чем нужно. Это может показаться дикостью, но некоторые приложения до сих пор применяют подобную практику!
Сегодня имеется единый стандарт, позволяющий одному сервису безопасно воспользоваться данными другого. К сожалению, подобные стандарты используют массу жаргонизмов и терминов, что усложняет их понимание. Цель этого материала — с помощью простых иллюстраций объяснить, как они работают (Думаете, что мои рисунки напоминают детскую мазню? Ну и ладно!).
Между прочим, это руководство также доступно в формате видео:
Дамы и господа, встречайте: OAuth 2.0
OAuth 2.0 — это стандарт безопасности, позволяющий одному приложению получить разрешение на доступ к информации в другом приложении. Последовательность действий для выдачи разрешения [permission] (или согласия [consent]) часто называют авторизацией [authorization] или даже делегированной авторизацией [delegated authorization]. С помощью этого стандарта вы позволяете приложению считать данные или использовать функции другого приложения от вашего имени, не сообщая ему свой пароль. Класс!
В качестве примера представим, что вы обнаружили сайт с названием «Неудачный каламбур дня» [Terrible Pun of the Day] и решили зарегистрироваться на нем, чтобы ежедневно получать каламбуры в виде текстовых сообщений на телефон. Сайт вам очень понравился, и вы решили поделиться им со всеми знакомыми. Ведь жуткие каламбурчики нравятся всем, не так ли?
«Неудачный каламбур дня: Слышали о парне, который потерял левую половину тела? Теперь он всегда прав!» (перевод примерный, т.к. в оригинале своя игра слов — прим. перев.)
Понятно, что писать каждому человеку из контакт-листа не вариант. И, если вы хотя бы чуточку похожи на меня, то пойдете на всё, чтобы избежать лишней работы. Благо Terrible Pun of the Day может сам пригласить всех ваших друзей! Для этого лишь нужно открыть ему доступ к электронной почте контактов — сайт сам отправит им приглашения (OAuth рулит)!
«Все любят каламбуры! — Уже залогинились? — Хотите открыть доступ сайту Terrible Pun of the Day к списку контактов? — Спасибо! Теперь мы каждый день будем слать напоминания всем, кого вы знаете, до скончания веков! Вы самый лучший друг!»
- Выберите свой сервис электронной почты.
- При необходимости перейдите на сайт почты и войдите в учетную запись.
- Дайте разрешение сайту Terrible Pun of the Day на доступ к контактам.
- Вернитесь на сайт 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:
Ссылка, по которой Authorization Server перенаправит Resource Owner'а после предоставления разрешения Client'у. Иногда ее называют «Возвратным URL» («Callback URL»). - Response Type:
Тип информации, которую ожидает получить Client. Самым распространенным Response Type'ом является код, то есть Client рассчитывает получить Authorization Code. - 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:
Ключ, который клиент будет использовать для связи с Resource Server'ом. Этакий бейдж или ключ-карта, предоставляющий Client'у разрешения на запрос данных или выполнение действий на Resource Server'е от вашего имени.
Примечание: иногда Authorization Server и Resource Server являются одним и тем же сервером. Однако в некоторых случаях это могут быть разные серверы, даже не принадлежащие к одной организации. Например, Authorization Server может быть сторонним сервисом, которому доверяет Resource Server.
Теперь, когда мы ознакомились с основными понятиями OAuth 2.0, давайте вернемся к нашему примеру и подробно рассмотрим, что происходит в потоке OAuth.
- Вы, Resource Owner, желаете предоставить сервису Terrible Pun of the Day (Client'у) доступ к своим контактам, чтобы тот мог разослать приглашения всем вашим друзьям.
- Client перенаправляет браузер на страницу Authorization Server'а и включает в запрос Client ID, Redirect URI, Response Type и одно или несколько Scopes (разрешений), которые ему необходимы.
- Authorization Server проверяет вас, при необходимости запрашивая логин и пароль.
- Authorization Server выводит форму Consent (подтверждения) с перечнем всех Scopes, запрашиваемых Client'ом. Вы соглашаетесь или отказываетесь.
- Authorization Server перенаправляет вас на сайт Client'а, используя Redirect URI вместе с Authorization Code (кодом авторизации).
- Client напрямую связывается с Authorization Server'ом (в обход браузера Resource Owner'а) и безопасно отправляет Client ID, Client Secret и Authorization Code.
- Authorization Server проверяет данные и отвечает с Access Token'ом (токеном доступа).
- Теперь 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!»
Название намекает, что Client Secret должен держаться в тайне, чтобы его знали только Client и Authorization Server. Ведь именно с его помощь Authorization Server подтверждает истинность Client'а.
Но это ещё не всё… Пожалуйста, поприветствуйте OpenID Connect!
OAuth 2.0 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись. Организацию логин-сессии часто называют аутентификацией [authentication], а информацию о пользователе, вошедшем в систему (т.е. о Resource Owner'е), — личными данными [identity]. Если Authorization Server поддерживает OIDC, его иногда называют поставщиком личных данных [identity provider], поскольку он предоставляет Client'у информацию о Resource Owner'е.
OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO). Например, приложение может поддерживать SSO-интеграцию с социальными сетями, такими как Facebook или Twitter, позволяя пользователям использовать учётную запись, которая у них уже имеется и которую они предпочитают использовать.
Поток (flow) OpenID Connect выглядит так же, как и в случае OAuth. Единственная разница в том, что в первичном запросе используемый конкретный scope —
openid, — а Client в итоге получает как Access Token, так и ID Token.Так же, как и в потоке OAuth, Access Token в OpenID Connect — это некое значение, не понятное Client'у. С точки зрения Client'а Access Token представляет некую строку из символов, которая передается вместе с каждым запросом к Resource Server'у, а тот определяет, действителен ли токен. 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:
- What the Heck is OAuth?
- Nobody Cares About OAuth or OpenID Connect
- Implement the OAuth 2.0 Authorization Code with PKCE Flow
- What is the OAuth 2.0 Grant Type?
- OAuth 2.0 From the Command Line
- Build a Secure Node.js App with SQL Server
Как обычно, не стесняйтесь комментировать. Чтобы быть в курсе наших последних новинок, подписывайтесь на Twitter и YouTube компании Okta для разработчиков!
P.S. от переводчика
Читайте также в нашем блоге:
stgunholy
Отличная статья! Спасибо